From stian at redhat.com  Mon Sep  1 05:16:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 1 Sep 2014 05:16:30 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0 RC 2 Released
In-Reply-To: <1881583534.41838523.1409562982226.JavaMail.zimbra@redhat.com>
Message-ID: <81922133.41838537.1409562990332.JavaMail.zimbra@redhat.com>

This will be the last release candidate before we release 1.0 final in just two weeks! So, there?s no new exiting features in this release, only a few bug fixes.


From stian at redhat.com  Mon Sep  1 09:43:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 1 Sep 2014 09:43:33 -0400 (EDT)
Subject: [keycloak-dev] Federating AWS Login at Netflix with OneLogin
In-Reply-To: <1844332108.41960508.1409578926228.JavaMail.zimbra@redhat.com>
Message-ID: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>

Interesting article on using SAML with AWS:

  http://www.onelogin.com/blog/amazon-aws-iam-identity-management-saml-federation/

Made me think that when we add SAML we should make sure it works with some external cloud services. Same goes for OpenID Connect, we need to make sure we're compliant enough that it works with 3rd party services and client libraries.

From bburke at redhat.com  Mon Sep  1 13:20:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Sep 2014 13:20:43 -0400
Subject: [keycloak-dev] Federating AWS Login at Netflix with OneLogin
In-Reply-To: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>
References: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>
Message-ID: <5404AAEB.1030800@redhat.com>

All this integration needs to be the focus for 1.1.  NO more cool 
features.  Time to do the nasty work.

On 9/1/2014 9:43 AM, Stian Thorgersen wrote:
> Interesting article on using SAML with AWS:
>
>    http://www.onelogin.com/blog/amazon-aws-iam-identity-management-saml-federation/
>
> Made me think that when we add SAML we should make sure it works with some external cloud services. Same goes for OpenID Connect, we need to make sure we're compliant enough that it works with 3rd party services and client libraries.
> _______________________________________________
> 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 Sep  2 03:14:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 03:14:48 -0400 (EDT)
Subject: [keycloak-dev] Federating AWS Login at Netflix with OneLogin
In-Reply-To: <5404AAEB.1030800@redhat.com>
References: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>
	<5404AAEB.1030800@redhat.com>
Message-ID: <1310420345.42201108.1409642088379.JavaMail.zimbra@redhat.com>

There's a few more key features that we'll need asap:

* TOTP SPI - including support for admins to register hardware tokens with users
* Internationalization - login and account, admin can come later (if at all?)
* Clustering

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 1 September, 2014 7:20:43 PM
> Subject: Re: [keycloak-dev] Federating AWS Login at Netflix with OneLogin
> 
> All this integration needs to be the focus for 1.1.  NO more cool
> features.  Time to do the nasty work.
> 
> On 9/1/2014 9:43 AM, Stian Thorgersen wrote:
> > Interesting article on using SAML with AWS:
> >
> >    http://www.onelogin.com/blog/amazon-aws-iam-identity-management-saml-federation/
> >
> > Made me think that when we add SAML we should make sure it works with some
> > external cloud services. Same goes for OpenID Connect, we need to make
> > sure we're compliant enough that it works with 3rd party services and
> > client libraries.
> > _______________________________________________
> > 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  Tue Sep  2 03:18:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 02 Sep 2014 09:18:07 +0200
Subject: [keycloak-dev] Federating AWS Login at Netflix with OneLogin
In-Reply-To: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>
References: <470411195.41960836.1409579013763.JavaMail.zimbra@redhat.com>
Message-ID: <54056F2F.4010901@redhat.com>

On 1.9.2014 15:43, Stian Thorgersen wrote:
> Interesting article on using SAML with AWS:
>
>    http://www.onelogin.com/blog/amazon-aws-iam-identity-management-saml-federation/
>
> Made me think that when we add SAML we should make sure it works with some external cloud services. Same goes for OpenID Connect, we need to make sure we're compliant enough that it works with 3rd party services and client libraries.
+1

When I worked on SAML integration with portal some time ago, I've tested 
and added the integration with Google Apps and Salesforce into 
picketlink 
http://docs.jboss.org/picketlink/2/latest/reference/html/sect-3rd_party_integration.html 
. Not sure which other 3rd party providers are supported and tested by 
picketlink though, but likely there are more. For example there is 
thread on security-dev from today that  login works with OpenAM too, but 
seems that user has some issue with logout though.

Marek


From stian at redhat.com  Tue Sep  2 08:09:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 08:09:06 -0400 (EDT)
Subject: [keycloak-dev] Update docs to inherit project version from
	keycloak-parent
Message-ID: <1470774136.42412361.1409659746182.JavaMail.zimbra@redhat.com>

I've updated the docs to use keycloak-parent as parent and use templated version in docs. This allows changing the version everywhere with "mvn version:set" in the root.

From gcardoso at redhat.com  Tue Sep  2 08:54:54 2014
From: gcardoso at redhat.com (Gabriel Cardoso)
Date: Tue, 2 Sep 2014 09:54:54 -0300
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.0 RC 2 Released
In-Reply-To: <81922133.41838537.1409562990332.JavaMail.zimbra@redhat.com>
References: <81922133.41838537.1409562990332.JavaMail.zimbra@redhat.com>
Message-ID: <5AA89C84-188C-4F50-A03B-5517C297C443@redhat.com>

How about some UI review / polishing?

Free service :)

On Sep 1, 2014, at 6:16 AM, Stian Thorgersen <stian at redhat.com> wrote:

> This will be the last release candidate before we release 1.0 final in just two weeks! So, there?s no new exiting features in this release, only a few bug fixes.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

---
Gabriel Cardoso
User Experience Designer @ Red Hat

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

From bburke at redhat.com  Tue Sep  2 09:02:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 09:02:56 -0400
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.0 RC 2 Released
In-Reply-To: <5AA89C84-188C-4F50-A03B-5517C297C443@redhat.com>
References: <81922133.41838537.1409562990332.JavaMail.zimbra@redhat.com>
	<5AA89C84-188C-4F50-A03B-5517C297C443@redhat.com>
Message-ID: <5405C000.6040500@redhat.com>

NO MORE UI CHANGES!

I am doing screencast tutorials this week.

On 9/2/2014 8:54 AM, Gabriel Cardoso wrote:
> How about some UI review / polishing?
>
> Free service :)
>
> On Sep 1, 2014, at 6:16 AM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>> This will be the last release candidate before we release 1.0 final in
>> just two weeks! So, there?s no new exiting features in this release,
>> only a few bug fixes.
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> ---
> 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  Tue Sep  2 09:05:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 09:05:36 -0400
Subject: [keycloak-dev] prep for 1.0.Final
Message-ID: <5405C0A0.5020007@redhat.com>

Please no more UI changes or distribution directory structure changes. 
I am re-doing screencasts and don't want these screencasts to be 
obsolete as soon as we do them.

We should shy away from API or DB schema changes.  It would be cool if 
documentation could be reviewed/expanded/improved while we wait to see 
if any bugs filter in from RC.

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

From alarik at zwift.com  Tue Sep  2 09:41:22 2014
From: alarik at zwift.com (Alarik Myrin)
Date: Tue, 2 Sep 2014 09:41:22 -0400
Subject: [keycloak-dev] 1.0-rc-2 git tag
Message-ID: <CAKTx7M5jEsRDytnHFEmxt_EKK86ZsOGn6tKRhJ=-Nk7YDM-LpA@mail.gmail.com>

Was 1.0-rc-2 tagged in git?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140902/05508f4e/attachment.html 

From stian at redhat.com  Tue Sep  2 09:56:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 09:56:58 -0400 (EDT)
Subject: [keycloak-dev] 1.0-rc-2 git tag
In-Reply-To: <CAKTx7M5jEsRDytnHFEmxt_EKK86ZsOGn6tKRhJ=-Nk7YDM-LpA@mail.gmail.com>
References: <CAKTx7M5jEsRDytnHFEmxt_EKK86ZsOGn6tKRhJ=-Nk7YDM-LpA@mail.gmail.com>
Message-ID: <2085988266.42504583.1409666218865.JavaMail.zimbra@redhat.com>

https://github.com/keycloak/keycloak/tree/1.0-rc-2

----- Original Message -----
> From: "Alarik Myrin" <alarik at zwift.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 3:41:22 PM
> Subject: [keycloak-dev] 1.0-rc-2 git tag
> 
> Was 1.0-rc-2 tagged in git?
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From alarik at zwift.com  Tue Sep  2 10:06:27 2014
From: alarik at zwift.com (Alarik Myrin)
Date: Tue, 2 Sep 2014 10:06:27 -0400
Subject: [keycloak-dev] 1.0-rc-2 git tag
In-Reply-To: <2085988266.42504583.1409666218865.JavaMail.zimbra@redhat.com>
References: <CAKTx7M5jEsRDytnHFEmxt_EKK86ZsOGn6tKRhJ=-Nk7YDM-LpA@mail.gmail.com>
	<2085988266.42504583.1409666218865.JavaMail.zimbra@redhat.com>
Message-ID: <CAKTx7M6Qrw8D5NekP2ewp5S8GNq0pb8AZgbjFyn5UwMKDz_bNA@mail.gmail.com>

Sorry, my bad.  I needed to run git fetch --tags




On Tue, Sep 2, 2014 at 9:56 AM, Stian Thorgersen <stian at redhat.com> wrote:

> https://github.com/keycloak/keycloak/tree/1.0-rc-2
>
> ----- Original Message -----
> > From: "Alarik Myrin" <alarik at zwift.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 September, 2014 3:41:22 PM
> > Subject: [keycloak-dev] 1.0-rc-2 git tag
> >
> > Was 1.0-rc-2 tagged in git?
> >
> > _______________________________________________
> > 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/20140902/e0263ef9/attachment.html 

From bburke at redhat.com  Tue Sep  2 10:24:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 10:24:09 -0400
Subject: [keycloak-dev] AccoutTest.viewLog randomly fails
Message-ID: <5405D309.80602@redhat.com>

AccountTest.viewLog:403 expected:<[login]> but was:<[register]>

This happens to me a lot and I can't figure out why.  It only happens in 
a full build.  I can't replicate it in IDE, or if I run testsuite alone.

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

From stian at redhat.com  Tue Sep  2 10:38:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 10:38:38 -0400 (EDT)
Subject: [keycloak-dev] prep for 1.0.Final
In-Reply-To: <5405C0A0.5020007@redhat.com>
References: <5405C0A0.5020007@redhat.com>
Message-ID: <268101091.42548004.1409668718713.JavaMail.zimbra@redhat.com>

Sure - would also be nice if everyone could send a mail to the ml before doing a large change to a section of the docs

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 3:05:36 PM
> Subject: [keycloak-dev] prep for 1.0.Final
> 
> Please no more UI changes or distribution directory structure changes.
> I am re-doing screencasts and don't want these screencasts to be
> obsolete as soon as we do them.
> 
> We should shy away from API or DB schema changes.  It would be cool if
> documentation could be reviewed/expanded/improved while we wait to see
> if any bugs filter in from RC.
> 
> --
> 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 Sep  2 10:53:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 10:53:17 -0400 (EDT)
Subject: [keycloak-dev] AccoutTest.viewLog randomly fails
In-Reply-To: <5405D309.80602@redhat.com>
References: <5405D309.80602@redhat.com>
Message-ID: <1508839612.42556290.1409669597147.JavaMail.zimbra@redhat.com>

I bet it's caused by the tests running so quickly that the register and login events have the same timestamp. 

The events it's checking against are held in a list by the test itself, so they will be ordered chronological, while the events showing on the account log page will be sorted by time (and events with the same time could easily swap around).

I'll fix the test tomorrow morning!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 4:24:09 PM
> Subject: [keycloak-dev] AccoutTest.viewLog randomly fails
> 
> AccountTest.viewLog:403 expected:<[login]> but was:<[register]>
> 
> This happens to me a lot and I can't figure out why.  It only happens in
> a full build.  I can't replicate it in IDE, or if I run testsuite alone.
> 
> --
> 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 Sep  2 11:01:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Sep 2014 11:01:25 -0400 (EDT)
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <3048668.42556881.1409669633743.JavaMail.zimbra@redhat.com>
Message-ID: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>

This has already been written, but I wanted to start a blank thread so we can discuss features going into 1.1.

In priority order, the features we'll need for 1.1 seems to be:

* SAML
* OpenID Connect interoperability - test with 3rd party services and client libraries
* Clustering - realm and user cache invalidation + distributed user sessions
* Internationalization support for login and account management
* TOTP improvements - we need a SPI to be able to add more multifactor authentication mechanisms, as well as support for admins to register totp tokens on behalf of users (hardware tokens)

From bburke at redhat.com  Tue Sep  2 11:34:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 11:34:28 -0400
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
Message-ID: <5405E384.8050609@redhat.com>

I put them in my opinion of priority order

* Clustering
* SAML
* Uberfire Integration (BRMS)
* Fuse FSW
* JIRA Integration (for potential sso.jboss.org deployment).
* SPNEGO Kerberos, so we can integration with OpenIPA (also an 
sso.jboss.org deployment requirement too) .
* Open ID Connect interoperability
* Tomcat Adapter
* Jetty Adapter
* Pure servlet adapter
* Node.js Adapter
* Internationalization
* TOTP improvements - we need a SPI to be able to add more multifactor 
authentication mechanisms, as well as support for admins to register 
totp tokens on behalf of users (hardware tokens)
* IP filtering, fail2ban features.


Clustering is an important deployment issue we have to solve.  The rest 
are integration requirements we need to solve now so other Red Hat 
projects can use Keycloak.  Internationalization, TOTP Improvements, and 
other new features need to be put off until our integration efforts are 
improved.





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

From bburke at redhat.com  Tue Sep  2 11:36:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 11:36:34 -0400
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <5405E384.8050609@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
	<5405E384.8050609@redhat.com>
Message-ID: <5405E402.6000605@redhat.com>

Forgot one.

On 9/2/2014 11:34 AM, Bill Burke wrote:
> I put them in my opinion of priority order
>
> * Clustering
> * SAML
> * Uberfire Integration (BRMS)
> * Fuse FSW
> * JIRA Integration (for potential sso.jboss.org deployment).
> * SPNEGO Kerberos, so we can integration with OpenIPA (also an
> sso.jboss.org deployment requirement too) .
> * Open ID Connect interoperability
> * Tomcat Adapter
> * Jetty Adapter
> * Pure servlet adapter
> * Node.js Adapter
> * Internationalization

* Improved claim support.  Custom claim definition and entry.

> * TOTP improvements - we need a SPI to be able to add more multifactor
> authentication mechanisms, as well as support for admins to register
> totp tokens on behalf of users (hardware tokens)
> * IP filtering, fail2ban features.


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

From bburke at redhat.com  Tue Sep  2 11:41:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 11:41:21 -0400
Subject: [keycloak-dev] theme changes and questions
Message-ID: <5405E521.3080303@redhat.com>

I added a "logo-example" theme to the distro.  This just provides a 
theme for login, account, and admin that overrides the logo (Keycloak 
image to Red Hat image).

Because admin console is not based on freemarker templates, I refactored 
the admin console 'styles.css' to make it easier to override styles for 
the admin console.  This now includes a 'base-styles.css' and a 
'overrides.css'.  The 'logo-example' theme for admin adds changes within 
'overrides.css'.  If you think this is the right way to implement this, 
I'll update the documentation to talk about how to override admin theme 
styles.


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

From psilva at redhat.com  Tue Sep  2 14:16:03 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Sep 2014 14:16:03 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KeyCloak Integration
In-Reply-To: <676939392.15342036.1409680853642.JavaMail.zimbra@redhat.com>
Message-ID: <262042786.15350958.1409681763525.JavaMail.zimbra@redhat.com>

Hey Guys,

    I've mentioned in a previous thread the work we are doing in PicketLink to support different token formats. One of the use cases we're considering is about consuming KeyCloak tokens.

    PicketLink is now able to consume tokens from KeyCloak in order to perform security checks. This is a very important step in order to combine all the functionalty provided by KeyCloak and PicketLink in a single application. With a minimal configuration and effort.

    From our last discussion, Bill said that we can have the integration code into the KeyCloak repository. If this is still true, I would like to start to prepare a PR to send all the code we need for this integration. The code is very simple and requires the usage of the KeyCloak API in order to properly parse tokens and information from them. Here is an example:

        https://github.com/pedroigor/jboss-wfk-quickstarts/tree/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication

    The good news is that people is already asking for this :)

    Wdyt ?

Regards.
Pedro Igor

From bburke at redhat.com  Tue Sep  2 15:38:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 15:38:50 -0400
Subject: [keycloak-dev] PicketLink and KeyCloak Integration
In-Reply-To: <262042786.15350958.1409681763525.JavaMail.zimbra@redhat.com>
References: <262042786.15350958.1409681763525.JavaMail.zimbra@redhat.com>
Message-ID: <54061CCA.6030700@redhat.com>

+1.  We won't merge it until after 1.0 though, ok?  1.0 next week 
sometime, or whenever screencasts and last bugs are done.

On 9/2/2014 2:16 PM, Pedro Igor Silva wrote:
> Hey Guys,
>
>      I've mentioned in a previous thread the work we are doing in PicketLink to support different token formats. One of the use cases we're considering is about consuming KeyCloak tokens.
>
>      PicketLink is now able to consume tokens from KeyCloak in order to perform security checks. This is a very important step in order to combine all the functionalty provided by KeyCloak and PicketLink in a single application. With a minimal configuration and effort.
>
>      From our last discussion, Bill said that we can have the integration code into the KeyCloak repository. If this is still true, I would like to start to prepare a PR to send all the code we need for this integration. The code is very simple and requires the usage of the KeyCloak API in order to properly parse tokens and information from them. Here is an example:
>
>          https://github.com/pedroigor/jboss-wfk-quickstarts/tree/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication
>
>      The good news is that people is already asking for this :)
>
>      Wdyt ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> 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 psilva at redhat.com  Tue Sep  2 15:48:43 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 2 Sep 2014 15:48:43 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KeyCloak Integration
In-Reply-To: <54061CCA.6030700@redhat.com>
References: <262042786.15350958.1409681763525.JavaMail.zimbra@redhat.com>
	<54061CCA.6030700@redhat.com>
Message-ID: <1468389669.15452344.1409687323261.JavaMail.zimbra@redhat.com>

Np. Thanks.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Tuesday, September 2, 2014 4:38:50 PM
Subject: Re: [keycloak-dev] PicketLink and KeyCloak Integration

+1.  We won't merge it until after 1.0 though, ok?  1.0 next week 
sometime, or whenever screencasts and last bugs are done.

On 9/2/2014 2:16 PM, Pedro Igor Silva wrote:
> Hey Guys,
>
>      I've mentioned in a previous thread the work we are doing in PicketLink to support different token formats. One of the use cases we're considering is about consuming KeyCloak tokens.
>
>      PicketLink is now able to consume tokens from KeyCloak in order to perform security checks. This is a very important step in order to combine all the functionalty provided by KeyCloak and PicketLink in a single application. With a minimal configuration and effort.
>
>      From our last discussion, Bill said that we can have the integration code into the KeyCloak repository. If this is still true, I would like to start to prepare a PR to send all the code we need for this integration. The code is very simple and requires the usage of the KeyCloak API in order to properly parse tokens and information from them. Here is an example:
>
>          https://github.com/pedroigor/jboss-wfk-quickstarts/tree/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication
>
>      The good news is that people is already asking for this :)
>
>      Wdyt ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> 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 Sep  2 18:42:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Sep 2014 18:42:24 -0400
Subject: [keycloak-dev] admin themes don't work on wildfly
Message-ID: <540647D0.3030601@redhat.com>

I can't get the admin themes to work on Wildfly appliance distribution. 
  They work when you run the admin console from maven, but not with the 
distribution.  Any idea why?

Thanks,

Bill

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

From stian at redhat.com  Wed Sep  3 02:39:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Sep 2014 02:39:40 -0400 (EDT)
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <5405E402.6000605@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
	<5405E384.8050609@redhat.com> <5405E402.6000605@redhat.com>
Message-ID: <276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>

I'm happy with that ordering, although I'd say Open ID Connect interoperability should be amongst the top 3.

Also, I was wondering if we should base our adapters on existing OAuth2/OpenID Connect adapters instead of writing them from scratch?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 5:36:34 PM
> Subject: Re: [keycloak-dev] Features for 1.1
> 
> Forgot one.
> 
> On 9/2/2014 11:34 AM, Bill Burke wrote:
> > I put them in my opinion of priority order
> >
> > * Clustering
> > * SAML
> > * Uberfire Integration (BRMS)
> > * Fuse FSW
> > * JIRA Integration (for potential sso.jboss.org deployment).
> > * SPNEGO Kerberos, so we can integration with OpenIPA (also an
> > sso.jboss.org deployment requirement too) .
> > * Open ID Connect interoperability
> > * Tomcat Adapter
> > * Jetty Adapter
> > * Pure servlet adapter
> > * Node.js Adapter
> > * Internationalization
> 
> * Improved claim support.  Custom claim definition and entry.
> 
> > * TOTP improvements - we need a SPI to be able to add more multifactor
> > authentication mechanisms, as well as support for admins to register
> > totp tokens on behalf of users (hardware tokens)
> > * IP filtering, fail2ban features.
> 
> 
> --
> 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 Sep  3 02:54:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Sep 2014 02:54:34 -0400 (EDT)
Subject: [keycloak-dev] AccoutTest.viewLog randomly fails
In-Reply-To: <1508839612.42556290.1409669597147.JavaMail.zimbra@redhat.com>
References: <5405D309.80602@redhat.com>
	<1508839612.42556290.1409669597147.JavaMail.zimbra@redhat.com>
Message-ID: <1465600108.42978629.1409727274161.JavaMail.zimbra@redhat.com>

Should be fixed now, let me know if there's still problems with it

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 4:53:17 PM
> Subject: Re: [keycloak-dev] AccoutTest.viewLog randomly fails
> 
> I bet it's caused by the tests running so quickly that the register and login
> events have the same timestamp.
> 
> The events it's checking against are held in a list by the test itself, so
> they will be ordered chronological, while the events showing on the account
> log page will be sorted by time (and events with the same time could easily
> swap around).
> 
> I'll fix the test tomorrow morning!
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 September, 2014 4:24:09 PM
> > Subject: [keycloak-dev] AccoutTest.viewLog randomly fails
> > 
> > AccountTest.viewLog:403 expected:<[login]> but was:<[register]>
> > 
> > This happens to me a lot and I can't figure out why.  It only happens in
> > a full build.  I can't replicate it in IDE, or if I run testsuite alone.
> > 
> > --
> > 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  Wed Sep  3 03:45:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Sep 2014 03:45:18 -0400 (EDT)
Subject: [keycloak-dev] theme changes and questions
In-Reply-To: <5405E521.3080303@redhat.com>
References: <5405E521.3080303@redhat.com>
Message-ID: <403206870.43005579.1409730318407.JavaMail.zimbra@redhat.com>

Looks good, except example themes should be in "examples/themes". They're included in the dists (under "examples/themes") and users should copy them manually to "standalone/configuration/themes".

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 2 September, 2014 5:41:21 PM
> Subject: [keycloak-dev] theme changes and questions
> 
> I added a "logo-example" theme to the distro.  This just provides a
> theme for login, account, and admin that overrides the logo (Keycloak
> image to Red Hat image).
> 
> Because admin console is not based on freemarker templates, I refactored
> the admin console 'styles.css' to make it easier to override styles for
> the admin console.  This now includes a 'base-styles.css' and a
> 'overrides.css'.  The 'logo-example' theme for admin adds changes within
> 'overrides.css'.  If you think this is the right way to implement this,
> I'll update the documentation to talk about how to override admin theme
> styles.
> 
> 
> --
> 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 Sep  3 03:53:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Sep 2014 03:53:57 -0400 (EDT)
Subject: [keycloak-dev] admin themes don't work on wildfly
In-Reply-To: <540647D0.3030601@redhat.com>
References: <540647D0.3030601@redhat.com>
Message-ID: <330047549.43008382.1409730837279.JavaMail.zimbra@redhat.com>

Worked fine here (with WF appliance), could it be a browser caching issue?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 September, 2014 12:42:24 AM
> Subject: [keycloak-dev] admin themes don't work on wildfly
> 
> I can't get the admin themes to work on Wildfly appliance distribution.
>   They work when you run the admin console from maven, but not with the
> distribution.  Any idea why?
> 
> Thanks,
> 
> 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 bdawidow at redhat.com  Wed Sep  3 04:11:07 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Wed, 03 Sep 2014 10:11:07 +0200
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>	<5405E384.8050609@redhat.com>
	<5405E402.6000605@redhat.com>
	<276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>
Message-ID: <5406CD1B.5020201@redhat.com>

What would be your time frame for 1.1?

W dniu 03/09/14 08:39, Stian Thorgersen pisze:
> I'm happy with that ordering, although I'd say Open ID Connect
> interoperability should be amongst the top 3.
>
> Also, I was wondering if we should base our adapters on existing
> OAuth2/OpenID Connect adapters instead of writing them from scratch?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com> To:
>> keycloak-dev at lists.jboss.org Sent: Tuesday, 2 September, 2014
>> 5:36:34 PM Subject: Re: [keycloak-dev] Features for 1.1
>>
>> Forgot one.
>>
>> On 9/2/2014 11:34 AM, Bill Burke wrote:
>>> I put them in my opinion of priority order
>>>
>>> * Clustering * SAML * Uberfire Integration (BRMS) * Fuse FSW *
>>> JIRA Integration (for potential sso.jboss.org deployment). *
>>> SPNEGO Kerberos, so we can integration with OpenIPA (also an
>>> sso.jboss.org deployment requirement too) . * Open ID Connect
>>> interoperability * Tomcat Adapter * Jetty Adapter * Pure servlet
>>> adapter * Node.js Adapter * Internationalization
>>
>> * Improved claim support.  Custom claim definition and entry.
>>
>>> * TOTP improvements - we need a SPI to be able to add more
>>> multifactor authentication mechanisms, as well as support for
>>> admins to register totp tokens on behalf of users (hardware
>>> tokens) * IP filtering, fail2ban features.
>>
>>
>> -- 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
>



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

From stian at redhat.com  Wed Sep  3 05:27:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Sep 2014 05:27:32 -0400 (EDT)
Subject: [keycloak-dev] Examples overview README.md
In-Reply-To: <1394008758.43050555.1409736217959.JavaMail.zimbra@redhat.com>
Message-ID: <850179422.43055367.1409736452795.JavaMail.zimbra@redhat.com>

I've added 'examples/README.md' with a brief overview over all the examples. This replaces 'examples/demo-template/README.md.overview', which only mentioned the demo.

Now I'll add instructions to 'unconfigured-demo/README.md' on how to configure it with an existing Keycloak server. I'll make sure the instructions work with either a local or external server. It would be good if the screencast follows the same order as this README.md so they can be used together.

From matzew at apache.org  Wed Sep  3 07:47:08 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 3 Sep 2014 13:47:08 +0200
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <5405E384.8050609@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
	<5405E384.8050609@redhat.com>
Message-ID: <CAAg5f2REjTwvkXhTqeznd5ttFb8P61Z9POJ73w47bPkHZkLxDw@mail.gmail.com>

On Tuesday, September 2, 2014, Bill Burke <bburke at redhat.com> wrote:

> I put them in my opinion of priority order
>
> * Clustering
> * SAML
> * Uberfire Integration (BRMS)
> * Fuse FSW
> * JIRA Integration (for potential sso.jboss.org deployment).
> * SPNEGO Kerberos, so we can integration with OpenIPA (also an
> sso.jboss.org deployment requirement too) .
> * Open ID Connect interoperability
> * Tomcat Adapter


Isn't there already a Tomcat(7?) Adapter?


> * Jetty Adapter
> * Pure servlet adapter
> * Node.js Adapter
> * Internationalization
> * TOTP improvements - we need a SPI to be able to add more multifactor
> authentication mechanisms, as well as support for admins to register
> totp tokens on behalf of users (hardware tokens)
> * IP filtering, fail2ban features.
>
>
> Clustering is an important deployment issue we have to solve.  The rest
> are integration requirements we need to solve now so other Red Hat
> projects can use Keycloak.  Internationalization, TOTP Improvements, and
> other new features need to be put off until our integration efforts are
> improved.
>
>
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140903/3c6d9f39/attachment.html 

From bburke at redhat.com  Wed Sep  3 08:25:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Sep 2014 08:25:28 -0400
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>
	<5405E384.8050609@redhat.com> <5405E402.6000605@redhat.com>
	<276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>
Message-ID: <540708B8.7000601@redhat.com>



On 9/3/2014 2:39 AM, Stian Thorgersen wrote:
> I'm happy with that ordering, although I'd say Open ID Connect interoperability should be amongst the top 3.
>
> Also, I was wondering if we should base our adapters on existing OAuth2/OpenID Connect adapters instead of writing them from scratch?
>

We could possibly ditch our non-integrated adapter, but our integrated 
adapters (wildfly, jboss) are designed to fit into a security 
framework/SPI and it wouldn't be feasible to use an existing third-party 
adapter to implement them.

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

From bburke at redhat.com  Wed Sep  3 08:27:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Sep 2014 08:27:48 -0400
Subject: [keycloak-dev] admin themes don't work on wildfly
In-Reply-To: <330047549.43008382.1409730837279.JavaMail.zimbra@redhat.com>
References: <540647D0.3030601@redhat.com>
	<330047549.43008382.1409730837279.JavaMail.zimbra@redhat.com>
Message-ID: <54070944.5020604@redhat.com>

No, its not.  I made sure multiple times that I destroyed my cache.  But 
it works in maven mode fine, but not with appliance. I tried rebooting 
wildfly, clearing browser cache, etc.

On 9/3/2014 3:53 AM, Stian Thorgersen wrote:
> Worked fine here (with WF appliance), could it be a browser caching issue?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 3 September, 2014 12:42:24 AM
>> Subject: [keycloak-dev] admin themes don't work on wildfly
>>
>> I can't get the admin themes to work on Wildfly appliance distribution.
>>    They work when you run the admin console from maven, but not with the
>> distribution.  Any idea why?
>>
>> Thanks,
>>
>> 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
>>

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

From bburke at redhat.com  Wed Sep  3 08:30:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Sep 2014 08:30:12 -0400
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <5406CD1B.5020201@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>	<5405E384.8050609@redhat.com>	<5405E402.6000605@redhat.com>	<276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>
	<5406CD1B.5020201@redhat.com>
Message-ID: <540709D4.6060000@redhat.com>

Plan is to have a release every time we implement something major.

On 9/3/2014 4:11 AM, Boles?aw Dawidowicz wrote:
> What would be your time frame for 1.1?
>
> W dniu 03/09/14 08:39, Stian Thorgersen pisze:
>> I'm happy with that ordering, although I'd say Open ID Connect
>> interoperability should be amongst the top 3.
>>
>> Also, I was wondering if we should base our adapters on existing
>> OAuth2/OpenID Connect adapters instead of writing them from scratch?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com> To:
>>> keycloak-dev at lists.jboss.org Sent: Tuesday, 2 September, 2014
>>> 5:36:34 PM Subject: Re: [keycloak-dev] Features for 1.1
>>>
>>> Forgot one.
>>>
>>> On 9/2/2014 11:34 AM, Bill Burke wrote:
>>>> I put them in my opinion of priority order
>>>>
>>>> * Clustering * SAML * Uberfire Integration (BRMS) * Fuse FSW *
>>>> JIRA Integration (for potential sso.jboss.org deployment). *
>>>> SPNEGO Kerberos, so we can integration with OpenIPA (also an
>>>> sso.jboss.org deployment requirement too) . * Open ID Connect
>>>> interoperability * Tomcat Adapter * Jetty Adapter * Pure servlet
>>>> adapter * Node.js Adapter * Internationalization
>>>
>>> * Improved claim support.  Custom claim definition and entry.
>>>
>>>> * TOTP improvements - we need a SPI to be able to add more
>>>> multifactor authentication mechanisms, as well as support for
>>>> admins to register totp tokens on behalf of users (hardware
>>>> tokens) * IP filtering, fail2ban features.
>>>
>>>
>>> -- 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 bburke at redhat.com  Wed Sep  3 08:31:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Sep 2014 08:31:06 -0400
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <CAAg5f2REjTwvkXhTqeznd5ttFb8P61Z9POJ73w47bPkHZkLxDw@mail.gmail.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>	<5405E384.8050609@redhat.com>
	<CAAg5f2REjTwvkXhTqeznd5ttFb8P61Z9POJ73w47bPkHZkLxDw@mail.gmail.com>
Message-ID: <54070A0A.1000700@redhat.com>



On 9/3/2014 7:47 AM, Matthias Wessendorf wrote:
>
> Isn't there already a Tomcat(7?) Adapter?
>

Work has been started on it and it would be easy to add it as the code 
would be almost the same as the EAP 6.x adapter.

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

From bdawidow at redhat.com  Wed Sep  3 08:39:43 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Wed, 03 Sep 2014 14:39:43 +0200
Subject: [keycloak-dev] Features for 1.1
In-Reply-To: <540709D4.6060000@redhat.com>
References: <209049355.42563523.1409670085390.JavaMail.zimbra@redhat.com>	<5405E384.8050609@redhat.com>	<5405E402.6000605@redhat.com>	<276181265.42975242.1409726380256.JavaMail.zimbra@redhat.com>	<5406CD1B.5020201@redhat.com>
	<540709D4.6060000@redhat.com>
Message-ID: <54070C0F.8040908@redhat.com>

It is a long list. So in practice it could feed 1.1 and 1.2 at least right?

I like time boxed approach.

On 09/03/2014 02:30 PM, Bill Burke wrote:
> Plan is to have a release every time we implement something major.
>
> On 9/3/2014 4:11 AM, Boles?aw Dawidowicz wrote:
>> What would be your time frame for 1.1?
>>
>> W dniu 03/09/14 08:39, Stian Thorgersen pisze:
>>> I'm happy with that ordering, although I'd say Open ID Connect
>>> interoperability should be amongst the top 3.
>>>
>>> Also, I was wondering if we should base our adapters on existing
>>> OAuth2/OpenID Connect adapters instead of writing them from scratch?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com> To:
>>>> keycloak-dev at lists.jboss.org Sent: Tuesday, 2 September, 2014
>>>> 5:36:34 PM Subject: Re: [keycloak-dev] Features for 1.1
>>>>
>>>> Forgot one.
>>>>
>>>> On 9/2/2014 11:34 AM, Bill Burke wrote:
>>>>> I put them in my opinion of priority order
>>>>>
>>>>> * Clustering * SAML * Uberfire Integration (BRMS) * Fuse FSW *
>>>>> JIRA Integration (for potential sso.jboss.org deployment). *
>>>>> SPNEGO Kerberos, so we can integration with OpenIPA (also an
>>>>> sso.jboss.org deployment requirement too) . * Open ID Connect
>>>>> interoperability * Tomcat Adapter * Jetty Adapter * Pure servlet
>>>>> adapter * Node.js Adapter * Internationalization
>>>>
>>>> * Improved claim support.  Custom claim definition and entry.
>>>>
>>>>> * TOTP improvements - we need a SPI to be able to add more
>>>>> multifactor authentication mechanisms, as well as support for
>>>>> admins to register totp tokens on behalf of users (hardware
>>>>> tokens) * IP filtering, fail2ban features.
>>>>
>>>>
>>>> -- 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
>>>
>>
>>
>>
>



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

From bburke at redhat.com  Wed Sep  3 09:44:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Sep 2014 09:44:25 -0400
Subject: [keycloak-dev] admin themes don't work on wildfly
In-Reply-To: <54070944.5020604@redhat.com>
References: <540647D0.3030601@redhat.com>	<330047549.43008382.1409730837279.JavaMail.zimbra@redhat.com>
	<54070944.5020604@redhat.com>
Message-ID: <54071B39.9020909@redhat.com>

Ah geeez!!! I am a freakin MORON!!!!!  I was changing it for the demo 
realm when I was logged into master.

On 9/3/2014 8:27 AM, Bill Burke wrote:
> No, its not.  I made sure multiple times that I destroyed my cache.  But
> it works in maven mode fine, but not with appliance. I tried rebooting
> wildfly, clearing browser cache, etc.
>
> On 9/3/2014 3:53 AM, Stian Thorgersen wrote:
>> Worked fine here (with WF appliance), could it be a browser caching issue?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 3 September, 2014 12:42:24 AM
>>> Subject: [keycloak-dev] admin themes don't work on wildfly
>>>
>>> I can't get the admin themes to work on Wildfly appliance distribution.
>>>     They work when you run the admin console from maven, but not with the
>>> distribution.  Any idea why?
>>>
>>> Thanks,
>>>
>>> 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
>>>
>

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

From stian at redhat.com  Thu Sep  4 05:31:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Sep 2014 05:31:44 -0400 (EDT)
Subject: [keycloak-dev] admin themes don't work on wildfly
In-Reply-To: <54071B39.9020909@redhat.com>
References: <540647D0.3030601@redhat.com>
	<330047549.43008382.1409730837279.JavaMail.zimbra@redhat.com>
	<54070944.5020604@redhat.com> <54071B39.9020909@redhat.com>
Message-ID: <275746228.43804028.1409823104927.JavaMail.zimbra@redhat.com>

Hahaha :)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 3 September, 2014 3:44:25 PM
> Subject: Re: [keycloak-dev] admin themes don't work on wildfly
> 
> Ah geeez!!! I am a freakin MORON!!!!!  I was changing it for the demo
> realm when I was logged into master.
> 
> On 9/3/2014 8:27 AM, Bill Burke wrote:
> > No, its not.  I made sure multiple times that I destroyed my cache.  But
> > it works in maven mode fine, but not with appliance. I tried rebooting
> > wildfly, clearing browser cache, etc.
> >
> > On 9/3/2014 3:53 AM, Stian Thorgersen wrote:
> >> Worked fine here (with WF appliance), could it be a browser caching issue?
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 3 September, 2014 12:42:24 AM
> >>> Subject: [keycloak-dev] admin themes don't work on wildfly
> >>>
> >>> I can't get the admin themes to work on Wildfly appliance distribution.
> >>>     They work when you run the admin console from maven, but not with the
> >>> distribution.  Any idea why?
> >>>
> >>> Thanks,
> >>>
> >>> 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
> >>>
> >
> 
> --
> 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 Sep  4 14:32:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Sep 2014 14:32:38 -0400
Subject: [keycloak-dev] admin consnole randomly logs out
Message-ID: <5408B046.2060108@redhat.com>

Even though I have my times set to hours, the admin console still seems 
to log me out randomly (with no message).   Any ideas?  I can't 
reproduce it on demand.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Sep  4 17:46:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Sep 2014 17:46:50 -0400
Subject: [keycloak-dev] ugh, google changed again
Message-ID: <5408DDCA.1090305@redhat.com>

FYI:

You now have to specify a project name and an email on the consent page 
in the GOogle Console, otherwise you get a login error.

I need to update our documentation.

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

From alarik at zwift.com  Fri Sep  5 06:35:01 2014
From: alarik at zwift.com (Alarik Myrin)
Date: Fri, 5 Sep 2014 06:35:01 -0400
Subject: [keycloak-dev] Certificate Authentication
Message-ID: <CAKTx7M6-cb3WBAVVZL_Ki8vgudM23D8AjSmGW-OaV+9sCd32FA@mail.gmail.com>

I noticed that Certificate Authentication was not on the list for 1.1 --
any idea when that might get added?

Alarik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140905/e25bd848/attachment.html 

From mposolda at redhat.com  Fri Sep  5 07:59:38 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 05 Sep 2014 13:59:38 +0200
Subject: [keycloak-dev] www.keycloak.org out
Message-ID: <5409A5AA.3060606@redhat.com>

It seems that I can't open "www.keycloak.org", but "keycloak.org" works.

Is "www.keycloak.org" also expected to work?

From bburke at redhat.com  Fri Sep  5 08:14:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Sep 2014 08:14:41 -0400
Subject: [keycloak-dev] www.keycloak.org out
In-Reply-To: <5409A5AA.3060606@redhat.com>
References: <5409A5AA.3060606@redhat.com>
Message-ID: <5409A931.9090907@redhat.com>

www.keycloak.org works for me.

On 9/5/2014 7:59 AM, Marek Posolda wrote:
> It seems that I can't open "www.keycloak.org", but "keycloak.org" works.
>
> Is "www.keycloak.org" also expected to work?
> _______________________________________________
> 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 Sep  5 10:10:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Sep 2014 10:10:49 -0400
Subject: [keycloak-dev] Certificate Authentication
In-Reply-To: <CAKTx7M6-cb3WBAVVZL_Ki8vgudM23D8AjSmGW-OaV+9sCd32FA@mail.gmail.com>
References: <CAKTx7M6-cb3WBAVVZL_Ki8vgudM23D8AjSmGW-OaV+9sCd32FA@mail.gmail.com>
Message-ID: <5409C469.2030409@redhat.com>

Yeah, that's something we'll have to add.  1.1 still needs priorize on 
integration though.    We're getting a lot of pressure both internally 
and externally in that area.  Hopefully we can get to cert auth by end 
of year.

On 9/5/2014 6:35 AM, Alarik Myrin wrote:
> I noticed that Certificate Authentication was not on the list for 1.1 --
> any idea when that might get added?
>
> Alarik
>
>
>
> _______________________________________________
> 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 Sep  5 13:12:30 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 05 Sep 2014 19:12:30 +0200
Subject: [keycloak-dev] www.keycloak.org out
In-Reply-To: <5409A931.9090907@redhat.com>
References: <5409A5AA.3060606@redhat.com> <5409A931.9090907@redhat.com>
Message-ID: <5409EEFE.7030800@redhat.com>

Me too right now. It just didn't work for me in the afternoon for some 
reason..

On 5.9.2014 14:14, Bill Burke wrote:
> www.keycloak.org works for me.
>
> On 9/5/2014 7:59 AM, Marek Posolda wrote:
>> It seems that I can't open "www.keycloak.org", but "keycloak.org" works.
>>
>> Is "www.keycloak.org" also expected to work?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Fri Sep  5 16:34:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Sep 2014 16:34:22 -0400
Subject: [keycloak-dev] screencasts all updated
Message-ID: <540A1E4E.4050404@redhat.com>

man I hate doing screencasts, but they are finally updated.  It really 
needed to be done as they were not in sync with the current version of 
keycloak.  I haven't linked them yet though.  I'll do that when we release.

One thing that drove me crazy was that I kept on getting logged out of 
the admin console sporadically.  Gotta figure out what is going wrong here.

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

From stian at redhat.com  Mon Sep  8 04:00:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 04:00:51 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <540A1E4E.4050404@redhat.com>
References: <540A1E4E.4050404@redhat.com>
Message-ID: <1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 5 September, 2014 10:34:22 PM
> Subject: [keycloak-dev] screencasts all updated
> 
> man I hate doing screencasts, but they are finally updated.  It really
> needed to be done as they were not in sync with the current version of
> keycloak.  I haven't linked them yet though.  I'll do that when we release.

Nice - next time I can pitch in and do a few ;)

> 
> One thing that drove me crazy was that I kept on getting logged out of
> the admin console sporadically.  Gotta figure out what is going wrong here.

Did you have multiple tabs open? We have a timer that logs you out after 300 seconds of inactivity. Problem is that if you have two tabs open with the admin console, one you're actively using and another in the background, the background tab will end up logging you out after 300 seconds.

We can either remove this altogether (my preferred option) and let the SSO idle timeout deal with it, or we could make sure your only logged out if there's no activity to the console (can have tabs write a timestamp to html5 storage periodically and check this before logging out).

> 
> --
> 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  Mon Sep  8 08:29:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 08 Sep 2014 08:29:59 -0400
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
Message-ID: <540DA147.5080202@redhat.com>



On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 5 September, 2014 10:34:22 PM
>> Subject: [keycloak-dev] screencasts all updated
>>
>> man I hate doing screencasts, but they are finally updated.  It really
>> needed to be done as they were not in sync with the current version of
>> keycloak.  I haven't linked them yet though.  I'll do that when we release.
>
> Nice - next time I can pitch in and do a few ;)
>
>>
>> One thing that drove me crazy was that I kept on getting logged out of
>> the admin console sporadically.  Gotta figure out what is going wrong here.
>
> Did you have multiple tabs open? We have a timer that logs you out after 300 seconds of inactivity. Problem is that if you have two tabs open with the admin console, one you're actively using and another in the background, the background tab will end up logging you out after 300 seconds.
>

That might be it.

> We can either remove this altogether (my preferred option) and let the SSO idle timeout deal with it, or we could make sure your only logged out if there's no activity to the console (can have tabs write a timestamp to html5 storage periodically and check this before logging out).
>

Or just have the timer download the SSO idle timeout.

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

From stian at redhat.com  Mon Sep  8 08:37:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 08:37:57 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <540DA147.5080202@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
Message-ID: <777372523.45355455.1410179877071.JavaMail.zimbra@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, 8 September, 2014 2:29:59 PM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> 
> 
> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 5 September, 2014 10:34:22 PM
> >> Subject: [keycloak-dev] screencasts all updated
> >>
> >> man I hate doing screencasts, but they are finally updated.  It really
> >> needed to be done as they were not in sync with the current version of
> >> keycloak.  I haven't linked them yet though.  I'll do that when we
> >> release.
> >
> > Nice - next time I can pitch in and do a few ;)
> >
> >>
> >> One thing that drove me crazy was that I kept on getting logged out of
> >> the admin console sporadically.  Gotta figure out what is going wrong
> >> here.
> >
> > Did you have multiple tabs open? We have a timer that logs you out after
> > 300 seconds of inactivity. Problem is that if you have two tabs open with
> > the admin console, one you're actively using and another in the
> > background, the background tab will end up logging you out after 300
> > seconds.
> >
> 
> That might be it.
> 
> > We can either remove this altogether (my preferred option) and let the SSO
> > idle timeout deal with it, or we could make sure your only logged out if
> > there's no activity to the console (can have tabs write a timestamp to
> > html5 storage periodically and check this before logging out).
> >
> 
> Or just have the timer download the SSO idle timeout.

Not sure I follow. Wouldn't that just change the timeout value, but still leave an inactive tab able to logout all tabs?

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

From bburke at redhat.com  Mon Sep  8 09:05:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 08 Sep 2014 09:05:47 -0400
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
Message-ID: <540DA9AB.1030901@redhat.com>



On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
>> Subject: Re: [keycloak-dev] screencasts all updated
>>
>>
>>
>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
>>>> Subject: [keycloak-dev] screencasts all updated
>>>>
>>>> man I hate doing screencasts, but they are finally updated.  It really
>>>> needed to be done as they were not in sync with the current version of
>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
>>>> release.
>>>
>>> Nice - next time I can pitch in and do a few ;)
>>>
>>>>
>>>> One thing that drove me crazy was that I kept on getting logged out of
>>>> the admin console sporadically.  Gotta figure out what is going wrong
>>>> here.
>>>
>>> Did you have multiple tabs open? We have a timer that logs you out after
>>> 300 seconds of inactivity. Problem is that if you have two tabs open with
>>> the admin console, one you're actively using and another in the
>>> background, the background tab will end up logging you out after 300
>>> seconds.
>>>
>>
>> That might be it.
>>
>>> We can either remove this altogether (my preferred option) and let the SSO
>>> idle timeout deal with it, or we could make sure your only logged out if
>>> there's no activity to the console (can have tabs write a timestamp to
>>> html5 storage periodically and check this before logging out).
>>>
>>
>> Or just have the timer download the SSO idle timeout.
>
> Not sure I follow. Wouldn't that just change the timeout value, but still leave an inactive tab able to logout all tabs?
>

Actually, are you sure that is it?  I thought the timer was for the 
timeout warning, not for anything else?  I'm not even seeing the warning.


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

From stian at redhat.com  Mon Sep  8 09:08:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 09:08:01 -0400 (EDT)
Subject: [keycloak-dev] theme changes and questions
In-Reply-To: <403206870.43005579.1409730318407.JavaMail.zimbra@redhat.com>
References: <5405E521.3080303@redhat.com>
	<403206870.43005579.1409730318407.JavaMail.zimbra@redhat.com>
Message-ID: <211374602.45403890.1410181681984.JavaMail.zimbra@redhat.com>

Can we move the logo-example themes to examples/themes instead of bundling them with the core themes?

----- 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, 3 September, 2014 9:45:18 AM
> Subject: Re: [keycloak-dev] theme changes and questions
> 
> Looks good, except example themes should be in "examples/themes". They're
> included in the dists (under "examples/themes") and users should copy them
> manually to "standalone/configuration/themes".
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 2 September, 2014 5:41:21 PM
> > Subject: [keycloak-dev] theme changes and questions
> > 
> > I added a "logo-example" theme to the distro.  This just provides a
> > theme for login, account, and admin that overrides the logo (Keycloak
> > image to Red Hat image).
> > 
> > Because admin console is not based on freemarker templates, I refactored
> > the admin console 'styles.css' to make it easier to override styles for
> > the admin console.  This now includes a 'base-styles.css' and a
> > 'overrides.css'.  The 'logo-example' theme for admin adds changes within
> > 'overrides.css'.  If you think this is the right way to implement this,
> > I'll update the documentation to talk about how to override admin theme
> > styles.
> > 
> > 
> > --
> > 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  Mon Sep  8 09:09:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 08 Sep 2014 09:09:59 -0400
Subject: [keycloak-dev] theme changes and questions
In-Reply-To: <211374602.45403890.1410181681984.JavaMail.zimbra@redhat.com>
References: <5405E521.3080303@redhat.com>
	<403206870.43005579.1409730318407.JavaMail.zimbra@redhat.com>
	<211374602.45403890.1410181681984.JavaMail.zimbra@redhat.com>
Message-ID: <540DAAA7.2020408@redhat.com>

Yeah, sorry.  I forgot to do that.

On 9/8/2014 9:08 AM, Stian Thorgersen wrote:
> Can we move the logo-example themes to examples/themes instead of bundling them with the core themes?
>
> ----- 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, 3 September, 2014 9:45:18 AM
>> Subject: Re: [keycloak-dev] theme changes and questions
>>
>> Looks good, except example themes should be in "examples/themes". They're
>> included in the dists (under "examples/themes") and users should copy them
>> manually to "standalone/configuration/themes".
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 2 September, 2014 5:41:21 PM
>>> Subject: [keycloak-dev] theme changes and questions
>>>
>>> I added a "logo-example" theme to the distro.  This just provides a
>>> theme for login, account, and admin that overrides the logo (Keycloak
>>> image to Red Hat image).
>>>
>>> Because admin console is not based on freemarker templates, I refactored
>>> the admin console 'styles.css' to make it easier to override styles for
>>> the admin console.  This now includes a 'base-styles.css' and a
>>> 'overrides.css'.  The 'logo-example' theme for admin adds changes within
>>> 'overrides.css'.  If you think this is the right way to implement this,
>>> I'll update the documentation to talk about how to override admin theme
>>> styles.
>>>
>>>
>>> --
>>> 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 stian at redhat.com  Mon Sep  8 09:30:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 09:30:29 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <540DA9AB.1030901@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
Message-ID: <2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>

Actually it seems we have two problems:

a) idletimeout plugin - this causes the logout if you have multiple tabs open. With the SSO idle timeout feature this is not needed, so we should just remove it to fix this issue

b) issue with sso idle timeout - I tried setting the SSO idle timeout to a low number (30 seconds), with access token lifespan lower (5 seconds) and was continuously browsing. After 1 min or two I was logged out, even though I was continuously doing requests (and network log shows it was doing refreshing the token)

----- 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, 8 September, 2014 3:05:47 PM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> 
> 
> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
> >> Subject: Re: [keycloak-dev] screencasts all updated
> >>
> >>
> >>
> >> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 5 September, 2014 10:34:22 PM
> >>>> Subject: [keycloak-dev] screencasts all updated
> >>>>
> >>>> man I hate doing screencasts, but they are finally updated.  It really
> >>>> needed to be done as they were not in sync with the current version of
> >>>> keycloak.  I haven't linked them yet though.  I'll do that when we
> >>>> release.
> >>>
> >>> Nice - next time I can pitch in and do a few ;)
> >>>
> >>>>
> >>>> One thing that drove me crazy was that I kept on getting logged out of
> >>>> the admin console sporadically.  Gotta figure out what is going wrong
> >>>> here.
> >>>
> >>> Did you have multiple tabs open? We have a timer that logs you out after
> >>> 300 seconds of inactivity. Problem is that if you have two tabs open with
> >>> the admin console, one you're actively using and another in the
> >>> background, the background tab will end up logging you out after 300
> >>> seconds.
> >>>
> >>
> >> That might be it.
> >>
> >>> We can either remove this altogether (my preferred option) and let the
> >>> SSO
> >>> idle timeout deal with it, or we could make sure your only logged out if
> >>> there's no activity to the console (can have tabs write a timestamp to
> >>> html5 storage periodically and check this before logging out).
> >>>
> >>
> >> Or just have the timer download the SSO idle timeout.
> >
> > Not sure I follow. Wouldn't that just change the timeout value, but still
> > leave an inactive tab able to logout all tabs?
> >
> 
> Actually, are you sure that is it?  I thought the timer was for the
> timeout warning, not for anything else?  I'm not even seeing the warning.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Sep  8 10:04:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 10:04:21 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
Message-ID: <322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>

Think I've figured out what's going on with problem b.

UserSession.LastSessionRefresh is only updated if the next access token refresh is after the timeout. The access token is also only refreshed when a request is made. With the default values being:

* access token lifespan: 1 min
* sso idle timeout: 5 min

This means that a request has to be made between 4 min and 5 min after the last time LastSessionRefresh was updated. So you can basically browse around all you want for 4 minutes, leave it idle for 60 seconds, then when you do the next request the session will be timed out.

The simple solution seems to be to update LastSessionRefresh everytime the token is refreshed. Then post-1.0.final come up with a better scheme to reduce the amount of writes to UserSession.LastSessionRefresh

----- 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, 8 September, 2014 3:30:29 PM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> Actually it seems we have two problems:
> 
> a) idletimeout plugin - this causes the logout if you have multiple tabs
> open. With the SSO idle timeout feature this is not needed, so we should
> just remove it to fix this issue
> 
> b) issue with sso idle timeout - I tried setting the SSO idle timeout to a
> low number (30 seconds), with access token lifespan lower (5 seconds) and
> was continuously browsing. After 1 min or two I was logged out, even though
> I was continuously doing requests (and network log shows it was doing
> refreshing the token)
> 
> ----- 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, 8 September, 2014 3:05:47 PM
> > Subject: Re: [keycloak-dev] screencasts all updated
> > 
> > 
> > 
> > On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
> > >> Subject: Re: [keycloak-dev] screencasts all updated
> > >>
> > >>
> > >>
> > >> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Friday, 5 September, 2014 10:34:22 PM
> > >>>> Subject: [keycloak-dev] screencasts all updated
> > >>>>
> > >>>> man I hate doing screencasts, but they are finally updated.  It really
> > >>>> needed to be done as they were not in sync with the current version of
> > >>>> keycloak.  I haven't linked them yet though.  I'll do that when we
> > >>>> release.
> > >>>
> > >>> Nice - next time I can pitch in and do a few ;)
> > >>>
> > >>>>
> > >>>> One thing that drove me crazy was that I kept on getting logged out of
> > >>>> the admin console sporadically.  Gotta figure out what is going wrong
> > >>>> here.
> > >>>
> > >>> Did you have multiple tabs open? We have a timer that logs you out
> > >>> after
> > >>> 300 seconds of inactivity. Problem is that if you have two tabs open
> > >>> with
> > >>> the admin console, one you're actively using and another in the
> > >>> background, the background tab will end up logging you out after 300
> > >>> seconds.
> > >>>
> > >>
> > >> That might be it.
> > >>
> > >>> We can either remove this altogether (my preferred option) and let the
> > >>> SSO
> > >>> idle timeout deal with it, or we could make sure your only logged out
> > >>> if
> > >>> there's no activity to the console (can have tabs write a timestamp to
> > >>> html5 storage periodically and check this before logging out).
> > >>>
> > >>
> > >> Or just have the timer download the SSO idle timeout.
> > >
> > > Not sure I follow. Wouldn't that just change the timeout value, but still
> > > leave an inactive tab able to logout all tabs?
> > >
> > 
> > Actually, are you sure that is it?  I thought the timer was for the
> > timeout warning, not for anything else?  I'm not even seeing the warning.
> > 
> > 
> > --
> > 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  Mon Sep  8 10:10:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 08 Sep 2014 10:10:01 -0400
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
	<322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
Message-ID: <540DB8B9.1040806@redhat.com>

Ah, so the keycloak.js token refresh isn't based on a timer then.  It is 
checked/refreshed on demand.

On 9/8/2014 10:04 AM, Stian Thorgersen wrote:
> Think I've figured out what's going on with problem b.
>
> UserSession.LastSessionRefresh is only updated if the next access token refresh is after the timeout. The access token is also only refreshed when a request is made. With the default values being:
>
> * access token lifespan: 1 min
> * sso idle timeout: 5 min
>
> This means that a request has to be made between 4 min and 5 min after the last time LastSessionRefresh was updated. So you can basically browse around all you want for 4 minutes, leave it idle for 60 seconds, then when you do the next request the session will be timed out.
>
> The simple solution seems to be to update LastSessionRefresh everytime the token is refreshed. Then post-1.0.final come up with a better scheme to reduce the amount of writes to UserSession.LastSessionRefresh
>
> ----- 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, 8 September, 2014 3:30:29 PM
>> Subject: Re: [keycloak-dev] screencasts all updated
>>
>> Actually it seems we have two problems:
>>
>> a) idletimeout plugin - this causes the logout if you have multiple tabs
>> open. With the SSO idle timeout feature this is not needed, so we should
>> just remove it to fix this issue
>>
>> b) issue with sso idle timeout - I tried setting the SSO idle timeout to a
>> low number (30 seconds), with access token lifespan lower (5 seconds) and
>> was continuously browsing. After 1 min or two I was logged out, even though
>> I was continuously doing requests (and network log shows it was doing
>> refreshing the token)
>>
>> ----- 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, 8 September, 2014 3:05:47 PM
>>> Subject: Re: [keycloak-dev] screencasts all updated
>>>
>>>
>>>
>>> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
>>>>> Subject: Re: [keycloak-dev] screencasts all updated
>>>>>
>>>>>
>>>>>
>>>>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
>>>>>>> Subject: [keycloak-dev] screencasts all updated
>>>>>>>
>>>>>>> man I hate doing screencasts, but they are finally updated.  It really
>>>>>>> needed to be done as they were not in sync with the current version of
>>>>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
>>>>>>> release.
>>>>>>
>>>>>> Nice - next time I can pitch in and do a few ;)
>>>>>>
>>>>>>>
>>>>>>> One thing that drove me crazy was that I kept on getting logged out of
>>>>>>> the admin console sporadically.  Gotta figure out what is going wrong
>>>>>>> here.
>>>>>>
>>>>>> Did you have multiple tabs open? We have a timer that logs you out
>>>>>> after
>>>>>> 300 seconds of inactivity. Problem is that if you have two tabs open
>>>>>> with
>>>>>> the admin console, one you're actively using and another in the
>>>>>> background, the background tab will end up logging you out after 300
>>>>>> seconds.
>>>>>>
>>>>>
>>>>> That might be it.
>>>>>
>>>>>> We can either remove this altogether (my preferred option) and let the
>>>>>> SSO
>>>>>> idle timeout deal with it, or we could make sure your only logged out
>>>>>> if
>>>>>> there's no activity to the console (can have tabs write a timestamp to
>>>>>> html5 storage periodically and check this before logging out).
>>>>>>
>>>>>
>>>>> Or just have the timer download the SSO idle timeout.
>>>>
>>>> Not sure I follow. Wouldn't that just change the timeout value, but still
>>>> leave an inactive tab able to logout all tabs?
>>>>
>>>
>>> Actually, are you sure that is it?  I thought the timer was for the
>>> timeout warning, not for anything else?  I'm not even seeing the warning.
>>>
>>>
>>> --
>>> 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  Mon Sep  8 11:06:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 8 Sep 2014 11:06:49 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <540DB8B9.1040806@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
	<322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
	<540DB8B9.1040806@redhat.com>
Message-ID: <382785675.45582102.1410188809583.JavaMail.zimbra@redhat.com>

Yep 

I'll remove the idle-timeout plugin and also change the LastSessionRefresh to be updated on each refresh. I'll also create a jira issue for 1.1 to figure out some way to reduce amount of updates to LastSessionRefresh.

----- 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, 8 September, 2014 4:10:01 PM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> Ah, so the keycloak.js token refresh isn't based on a timer then.  It is
> checked/refreshed on demand.
> 
> On 9/8/2014 10:04 AM, Stian Thorgersen wrote:
> > Think I've figured out what's going on with problem b.
> >
> > UserSession.LastSessionRefresh is only updated if the next access token
> > refresh is after the timeout. The access token is also only refreshed when
> > a request is made. With the default values being:
> >
> > * access token lifespan: 1 min
> > * sso idle timeout: 5 min
> >
> > This means that a request has to be made between 4 min and 5 min after the
> > last time LastSessionRefresh was updated. So you can basically browse
> > around all you want for 4 minutes, leave it idle for 60 seconds, then when
> > you do the next request the session will be timed out.
> >
> > The simple solution seems to be to update LastSessionRefresh everytime the
> > token is refreshed. Then post-1.0.final come up with a better scheme to
> > reduce the amount of writes to UserSession.LastSessionRefresh
> >
> > ----- 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, 8 September, 2014 3:30:29 PM
> >> Subject: Re: [keycloak-dev] screencasts all updated
> >>
> >> Actually it seems we have two problems:
> >>
> >> a) idletimeout plugin - this causes the logout if you have multiple tabs
> >> open. With the SSO idle timeout feature this is not needed, so we should
> >> just remove it to fix this issue
> >>
> >> b) issue with sso idle timeout - I tried setting the SSO idle timeout to a
> >> low number (30 seconds), with access token lifespan lower (5 seconds) and
> >> was continuously browsing. After 1 min or two I was logged out, even
> >> though
> >> I was continuously doing requests (and network log shows it was doing
> >> refreshing the token)
> >>
> >> ----- 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, 8 September, 2014 3:05:47 PM
> >>> Subject: Re: [keycloak-dev] screencasts all updated
> >>>
> >>>
> >>>
> >>> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
> >>>>> Subject: Re: [keycloak-dev] screencasts all updated
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> >>>>>>
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
> >>>>>>> Subject: [keycloak-dev] screencasts all updated
> >>>>>>>
> >>>>>>> man I hate doing screencasts, but they are finally updated.  It
> >>>>>>> really
> >>>>>>> needed to be done as they were not in sync with the current version
> >>>>>>> of
> >>>>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
> >>>>>>> release.
> >>>>>>
> >>>>>> Nice - next time I can pitch in and do a few ;)
> >>>>>>
> >>>>>>>
> >>>>>>> One thing that drove me crazy was that I kept on getting logged out
> >>>>>>> of
> >>>>>>> the admin console sporadically.  Gotta figure out what is going wrong
> >>>>>>> here.
> >>>>>>
> >>>>>> Did you have multiple tabs open? We have a timer that logs you out
> >>>>>> after
> >>>>>> 300 seconds of inactivity. Problem is that if you have two tabs open
> >>>>>> with
> >>>>>> the admin console, one you're actively using and another in the
> >>>>>> background, the background tab will end up logging you out after 300
> >>>>>> seconds.
> >>>>>>
> >>>>>
> >>>>> That might be it.
> >>>>>
> >>>>>> We can either remove this altogether (my preferred option) and let the
> >>>>>> SSO
> >>>>>> idle timeout deal with it, or we could make sure your only logged out
> >>>>>> if
> >>>>>> there's no activity to the console (can have tabs write a timestamp to
> >>>>>> html5 storage periodically and check this before logging out).
> >>>>>>
> >>>>>
> >>>>> Or just have the timer download the SSO idle timeout.
> >>>>
> >>>> Not sure I follow. Wouldn't that just change the timeout value, but
> >>>> still
> >>>> leave an inactive tab able to logout all tabs?
> >>>>
> >>>
> >>> Actually, are you sure that is it?  I thought the timer was for the
> >>> timeout warning, not for anything else?  I'm not even seeing the warning.
> >>>
> >>>
> >>> --
> >>> 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 lvadali at cisco.com  Tue Sep  9 01:48:44 2014
From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali))
Date: Tue, 9 Sep 2014 05:48:44 +0000
Subject: [keycloak-dev] Customising Keycloak Authentication flow
Message-ID: <BEA822DA38EAC24E869EEB395ABFA21C01EE2BA0@xmb-aln-x08.cisco.com>

Hi ,

Instead of Existing one step authentication(user/pass), We  need custom certificate based authentication which is 2-step Authentication as below:
    1. Bypass Login screen , instead generate nonce(UUID) and provide intermediate Endpoint URL for Certificate based authentication.
    2. Client will come to Certificate based authentication with its certificate and encrypted UUID.  After Validating Encrypted UUID
       and Client certificate server should generate "Access code".

We have gone through  1.3 Beta source code and realised to achieve this following code changes are needed
    1. Changes in TokenService class (login method) to bypass login form and generate UUID.
    2. Preserve UUID and url parameters obtained during the call in TokenManager.
    3. Redirect to custom_endpoint where client will submit its certificate and encrypted nonce.
       This end point will generate "access Code" once cert authentication completed.

It looks we need to make changes in some of core files like TokenService,TokenManager,OAuthFlows,...
Can you please let us know if there is any we can achieve this customization just by hooking our code
(without modifying).

Thanks,
Lakshmi Narayana V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140909/0c7518e3/attachment.html 

From mposolda at redhat.com  Tue Sep  9 02:47:17 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 09 Sep 2014 08:47:17 +0200
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com>	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>	<540DA147.5080202@redhat.com>	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>	<540DA9AB.1030901@redhat.com>	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
	<322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
Message-ID: <540EA275.4030301@redhat.com>

On 8.9.2014 16:04, Stian Thorgersen wrote:
> Think I've figured out what's going on with problem b.
>
> UserSession.LastSessionRefresh is only updated if the next access token refresh is after the timeout. The access token is also only refreshed when a request is made. With the default values being:
>
> * access token lifespan: 1 min
> * sso idle timeout: 5 min
>
> This means that a request has to be made between 4 min and 5 min after the last time LastSessionRefresh was updated. So you can basically browse around all you want for 4 minutes, leave it idle for 60 seconds, then when you do the next request the session will be timed out.
>
> The simple solution seems to be to update LastSessionRefresh everytime the token is refreshed. Then post-1.0.final come up with a better scheme to reduce the amount of writes to UserSession.LastSessionRefresh
I wonder if solution could be something simple like:

long minAllowedInterval = min(5 minutes, (sso idle timeout - access 
token lifespan) / 2);
if (System.currentTimeMillis() - lastSessionRefresh < minAllowedInterval) {
   updateLastSessionRefresh();
}

This will mean that if timeouts are low like:

* access token lifespan: 1 min
* sso idle timeout: 5 min

then it will update lastSessionRefresh in every token refresh. On the 
other hand with bigger values like:

* access token lifespan: 1 min
* sso idle timeout: 60 min

it will update lastSessionRefresh just if last refresh was older than 
around 30 minutes (exactly 30,5 minutes).

This might be good compromise between flexibility and easiness. The 
easiest approach might be to always update refresh or use some hardcoded 
minAllowedInterval (like 10 minutes). The most flexible approach might 
be to add another configuration option for configuring 
minAllowedInterval, but I am not sure if it's needed (too much 
configuration options for various timeouts might be confusing for people 
imo).

Marek
>
> ----- 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, 8 September, 2014 3:30:29 PM
>> Subject: Re: [keycloak-dev] screencasts all updated
>>
>> Actually it seems we have two problems:
>>
>> a) idletimeout plugin - this causes the logout if you have multiple tabs
>> open. With the SSO idle timeout feature this is not needed, so we should
>> just remove it to fix this issue
>>
>> b) issue with sso idle timeout - I tried setting the SSO idle timeout to a
>> low number (30 seconds), with access token lifespan lower (5 seconds) and
>> was continuously browsing. After 1 min or two I was logged out, even though
>> I was continuously doing requests (and network log shows it was doing
>> refreshing the token)
>>
>> ----- 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, 8 September, 2014 3:05:47 PM
>>> Subject: Re: [keycloak-dev] screencasts all updated
>>>
>>>
>>>
>>> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
>>>>> Subject: Re: [keycloak-dev] screencasts all updated
>>>>>
>>>>>
>>>>>
>>>>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
>>>>>>> Subject: [keycloak-dev] screencasts all updated
>>>>>>>
>>>>>>> man I hate doing screencasts, but they are finally updated.  It really
>>>>>>> needed to be done as they were not in sync with the current version of
>>>>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
>>>>>>> release.
>>>>>> Nice - next time I can pitch in and do a few ;)
>>>>>>
>>>>>>> One thing that drove me crazy was that I kept on getting logged out of
>>>>>>> the admin console sporadically.  Gotta figure out what is going wrong
>>>>>>> here.
>>>>>> Did you have multiple tabs open? We have a timer that logs you out
>>>>>> after
>>>>>> 300 seconds of inactivity. Problem is that if you have two tabs open
>>>>>> with
>>>>>> the admin console, one you're actively using and another in the
>>>>>> background, the background tab will end up logging you out after 300
>>>>>> seconds.
>>>>>>
>>>>> That might be it.
>>>>>
>>>>>> We can either remove this altogether (my preferred option) and let the
>>>>>> SSO
>>>>>> idle timeout deal with it, or we could make sure your only logged out
>>>>>> if
>>>>>> there's no activity to the console (can have tabs write a timestamp to
>>>>>> html5 storage periodically and check this before logging out).
>>>>>>
>>>>> Or just have the timer download the SSO idle timeout.
>>>> Not sure I follow. Wouldn't that just change the timeout value, but still
>>>> leave an inactive tab able to logout all tabs?
>>>>
>>> Actually, are you sure that is it?  I thought the timer was for the
>>> timeout warning, not for anything else?  I'm not even seeing the warning.
>>>
>>>
>>> --
>>> 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 Sep  9 04:03:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 04:03:18 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <540EA275.4030301@redhat.com>
References: <540A1E4E.4050404@redhat.com>
	<1538797388.45221633.1410163251395.JavaMail.zimbra@redhat.com>
	<540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
	<322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
	<540EA275.4030301@redhat.com>
Message-ID: <1715104666.46021233.1410249798893.JavaMail.zimbra@redhat.com>

For now I'm changing it to update every time. At the moment we don't have cluster support and all user sessions are stored in-mem so this is not an issue.

When we add cluster support we obviously need to distribute this. I think delaying the update would be best in those cases. Basically we only distribute the last refresh if it's close to expire.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 8:47:17 AM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> On 8.9.2014 16:04, Stian Thorgersen wrote:
> > Think I've figured out what's going on with problem b.
> >
> > UserSession.LastSessionRefresh is only updated if the next access token
> > refresh is after the timeout. The access token is also only refreshed when
> > a request is made. With the default values being:
> >
> > * access token lifespan: 1 min
> > * sso idle timeout: 5 min
> >
> > This means that a request has to be made between 4 min and 5 min after the
> > last time LastSessionRefresh was updated. So you can basically browse
> > around all you want for 4 minutes, leave it idle for 60 seconds, then when
> > you do the next request the session will be timed out.
> >
> > The simple solution seems to be to update LastSessionRefresh everytime the
> > token is refreshed. Then post-1.0.final come up with a better scheme to
> > reduce the amount of writes to UserSession.LastSessionRefresh
> I wonder if solution could be something simple like:
> 
> long minAllowedInterval = min(5 minutes, (sso idle timeout - access
> token lifespan) / 2);
> if (System.currentTimeMillis() - lastSessionRefresh < minAllowedInterval) {
>    updateLastSessionRefresh();
> }
> 
> This will mean that if timeouts are low like:
> 
> * access token lifespan: 1 min
> * sso idle timeout: 5 min
> 
> then it will update lastSessionRefresh in every token refresh. On the
> other hand with bigger values like:
> 
> * access token lifespan: 1 min
> * sso idle timeout: 60 min
> 
> it will update lastSessionRefresh just if last refresh was older than
> around 30 minutes (exactly 30,5 minutes).
> 
> This might be good compromise between flexibility and easiness. The
> easiest approach might be to always update refresh or use some hardcoded
> minAllowedInterval (like 10 minutes). The most flexible approach might
> be to add another configuration option for configuring
> minAllowedInterval, but I am not sure if it's needed (too much
> configuration options for various timeouts might be confusing for people
> imo).
> 
> Marek
> >
> > ----- 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, 8 September, 2014 3:30:29 PM
> >> Subject: Re: [keycloak-dev] screencasts all updated
> >>
> >> Actually it seems we have two problems:
> >>
> >> a) idletimeout plugin - this causes the logout if you have multiple tabs
> >> open. With the SSO idle timeout feature this is not needed, so we should
> >> just remove it to fix this issue
> >>
> >> b) issue with sso idle timeout - I tried setting the SSO idle timeout to a
> >> low number (30 seconds), with access token lifespan lower (5 seconds) and
> >> was continuously browsing. After 1 min or two I was logged out, even
> >> though
> >> I was continuously doing requests (and network log shows it was doing
> >> refreshing the token)
> >>
> >> ----- 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, 8 September, 2014 3:05:47 PM
> >>> Subject: Re: [keycloak-dev] screencasts all updated
> >>>
> >>>
> >>>
> >>> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
> >>>>> Subject: Re: [keycloak-dev] screencasts all updated
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
> >>>>>>> Subject: [keycloak-dev] screencasts all updated
> >>>>>>>
> >>>>>>> man I hate doing screencasts, but they are finally updated.  It
> >>>>>>> really
> >>>>>>> needed to be done as they were not in sync with the current version
> >>>>>>> of
> >>>>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
> >>>>>>> release.
> >>>>>> Nice - next time I can pitch in and do a few ;)
> >>>>>>
> >>>>>>> One thing that drove me crazy was that I kept on getting logged out
> >>>>>>> of
> >>>>>>> the admin console sporadically.  Gotta figure out what is going wrong
> >>>>>>> here.
> >>>>>> Did you have multiple tabs open? We have a timer that logs you out
> >>>>>> after
> >>>>>> 300 seconds of inactivity. Problem is that if you have two tabs open
> >>>>>> with
> >>>>>> the admin console, one you're actively using and another in the
> >>>>>> background, the background tab will end up logging you out after 300
> >>>>>> seconds.
> >>>>>>
> >>>>> That might be it.
> >>>>>
> >>>>>> We can either remove this altogether (my preferred option) and let the
> >>>>>> SSO
> >>>>>> idle timeout deal with it, or we could make sure your only logged out
> >>>>>> if
> >>>>>> there's no activity to the console (can have tabs write a timestamp to
> >>>>>> html5 storage periodically and check this before logging out).
> >>>>>>
> >>>>> Or just have the timer download the SSO idle timeout.
> >>>> Not sure I follow. Wouldn't that just change the timeout value, but
> >>>> still
> >>>> leave an inactive tab able to logout all tabs?
> >>>>
> >>> Actually, are you sure that is it?  I thought the timer was for the
> >>> timeout warning, not for anything else?  I'm not even seeing the warning.
> >>>
> >>>
> >>> --
> >>> 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
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Sep  9 04:09:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 04:09:29 -0400 (EDT)
Subject: [keycloak-dev] Customising Keycloak Authentication flow
In-Reply-To: <BEA822DA38EAC24E869EEB395ABFA21C01EE2BA0@xmb-aln-x08.cisco.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C01EE2BA0@xmb-aln-x08.cisco.com>
Message-ID: <1650067512.46023036.1410250169308.JavaMail.zimbra@redhat.com>

Afraid at the moment we don't have any proper way to hook into this, but we are planning to add this in the future.

I'm assuming you're authenticating clients, not users? If so that's something we plan to add support for at some point.

We'll probably add two extension points, one for adding custom login for users (for example a hardware multi-factor auth or even fingerprint scanner) and another for authenticating clients (certificate, jwt, etc.).

----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 7:48:44 AM
> Subject: [keycloak-dev] Customising Keycloak Authentication flow
> 
> 
> 
> Hi ,
> 
> 
> 
> Instead of Existing one step authentication(user/pass), We need custom
> certificate based authentication which is 2-step Authentication as below:
> 
> 1. Bypass Login screen , instead generate nonce(UUID) and provide
> intermediate Endpoint URL for Certificate based authentication.
> 
> 2. Client will come to Certificate based authentication with its certificate
> and encrypted UUID. After Validating Encrypted UUID
> 
> and Client certificate server should generate ?Access code?.
> 
> 
> 
> We have gone through 1.3 Beta source code and realised to achieve this
> following code changes are needed
> 
> 1. Changes in TokenService class (login method) to bypass login form and
> generate UUID.
> 
> 2. Preserve UUID and url parameters obtained during the call in TokenManager
> .
> 
> 3. Redirect to custom_endpoint where client will submit its certificate and
> encrypted nonce.
> 
> This end point will generate ?access Code? once cert authentication
> completed.
> 
> 
> 
> It looks we need to make changes in some of core files like
> TokenService,TokenManager,OAuthFlows,...
> 
> Can you please let us know if there is any we can achieve this customization
> just by hooking our code
> 
> (without modifying).
> 
> 
> 
> Thanks,
> 
> Lakshmi Narayana V
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From lvadali at cisco.com  Tue Sep  9 05:32:03 2014
From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali))
Date: Tue, 9 Sep 2014 09:32:03 +0000
Subject: [keycloak-dev] Customising Keycloak Authentication flow
In-Reply-To: <1650067512.46023036.1410250169308.JavaMail.zimbra@redhat.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C01EE2BA0@xmb-aln-x08.cisco.com>
	<1650067512.46023036.1410250169308.JavaMail.zimbra@redhat.com>
Message-ID: <BEA822DA38EAC24E869EEB395ABFA21C01EE2C22@xmb-aln-x08.cisco.com>

Thanks for the quick reply.

We are planning to authenticate a device(client) which will come with its certificate. It seems two extension points may not work for the requirement we have.

The cert implementation for keycloak that is planned may not work for us,  as we need to handle this authentication differently.
 For, e.g., we can?t configure the Realm client?s trust store to contain  certificates from all clients. In absence of  this we will 
need the client to provide its certificate which is signed by  a specific CA root authority and also  establish that it owns the private key 
for this certificate.

Can you please help us understand 
1. what kind of hooks are planned and when they are planned?
2. Will the hook help in  building  2-step authentication we need?(2-step authentication explained in my initial mail)

Thanks,
Lakshmi Narayana V

-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Tuesday, September 09, 2014 1:39 PM
To: Lakshmi Narayana VADALI (lvadali)
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Customising Keycloak Authentication flow

Afraid at the moment we don't have any proper way to hook into this, but we are planning to add this in the future.

I'm assuming you're authenticating clients, not users? If so that's something we plan to add support for at some point.

We'll probably add two extension points, one for adding custom login for users (for example a hardware multi-factor auth or even fingerprint scanner) and another for authenticating clients (certificate, jwt, etc.).

----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 7:48:44 AM
> Subject: [keycloak-dev] Customising Keycloak Authentication flow
> 
> 
> 
> Hi ,
> 
> 
> 
> Instead of Existing one step authentication(user/pass), We need custom 
> certificate based authentication which is 2-step Authentication as below:
> 
> 1. Bypass Login screen , instead generate nonce(UUID) and provide 
> intermediate Endpoint URL for Certificate based authentication.
> 
> 2. Client will come to Certificate based authentication with its 
> certificate and encrypted UUID. After Validating Encrypted UUID
> 
> and Client certificate server should generate ?Access code?.
> 
> 
> 
> We have gone through 1.3 Beta source code and realised to achieve this 
> following code changes are needed
> 
> 1. Changes in TokenService class (login method) to bypass login form 
> and generate UUID.
> 
> 2. Preserve UUID and url parameters obtained during the call in 
> TokenManager .
> 
> 3. Redirect to custom_endpoint where client will submit its 
> certificate and encrypted nonce.
> 
> This end point will generate ?access Code? once cert authentication 
> completed.
> 
> 
> 
> It looks we need to make changes in some of core files like 
> TokenService,TokenManager,OAuthFlows,...
> 
> Can you please let us know if there is any we can achieve this 
> customization just by hooking our code
> 
> (without modifying).
> 
> 
> 
> Thanks,
> 
> Lakshmi Narayana V
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Sep  9 05:43:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 05:43:43 -0400 (EDT)
Subject: [keycloak-dev] Customising Keycloak Authentication flow
In-Reply-To: <BEA822DA38EAC24E869EEB395ABFA21C01EE2C22@xmb-aln-x08.cisco.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C01EE2BA0@xmb-aln-x08.cisco.com>
	<1650067512.46023036.1410250169308.JavaMail.zimbra@redhat.com>
	<BEA822DA38EAC24E869EEB395ABFA21C01EE2C22@xmb-aln-x08.cisco.com>
Message-ID: <1144896978.46080301.1410255823429.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 11:32:03 AM
> Subject: RE: [keycloak-dev] Customising Keycloak Authentication flow
> 
> Thanks for the quick reply.
> 
> We are planning to authenticate a device(client) which will come with its
> certificate. It seems two extension points may not work for the requirement
> we have.
> 
> The cert implementation for keycloak that is planned may not work for us,  as
> we need to handle this authentication differently.
>  For, e.g., we can?t configure the Realm client?s trust store to contain
>  certificates from all clients. In absence of  this we will
> need the client to provide its certificate which is signed by  a specific CA
> root authority and also  establish that it owns the private key
> for this certificate.
> 
> Can you please help us understand
> 1. what kind of hooks are planned and when they are planned?

We don't know how it'll look like yet. Hopefully this is something we can add by the end of the year. 
 
In the mean-time I'd suggest you:

1. Create a new jaxrs class with two methods, one that returns the nounce and another that authenticates the client, look at TokenService as a reference for this, specifically at TokenService.grantAccessToken.
2. Extend KeycloakApplication to add your new class
3. Create your own auth-server war - see 'project-integrations/aerogear-ups' as a reference for this

That should allow you to add the functionality you need without having to modify existing Keycloak code.

> 2. Will the hook help in  building  2-step authentication we need?(2-step
> authentication explained in my initial mail)

Yes, we'll include your use-case when designing the hooks

> 
> Thanks,
> Lakshmi Narayana V
> 
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Tuesday, September 09, 2014 1:39 PM
> To: Lakshmi Narayana VADALI (lvadali)
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Customising Keycloak Authentication flow
> 
> Afraid at the moment we don't have any proper way to hook into this, but we
> are planning to add this in the future.
> 
> I'm assuming you're authenticating clients, not users? If so that's something
> we plan to add support for at some point.
> 
> We'll probably add two extension points, one for adding custom login for
> users (for example a hardware multi-factor auth or even fingerprint scanner)
> and another for authenticating clients (certificate, jwt, etc.).
> 
> ----- Original Message -----
> > From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 9 September, 2014 7:48:44 AM
> > Subject: [keycloak-dev] Customising Keycloak Authentication flow
> > 
> > 
> > 
> > Hi ,
> > 
> > 
> > 
> > Instead of Existing one step authentication(user/pass), We need custom
> > certificate based authentication which is 2-step Authentication as below:
> > 
> > 1. Bypass Login screen , instead generate nonce(UUID) and provide
> > intermediate Endpoint URL for Certificate based authentication.
> > 
> > 2. Client will come to Certificate based authentication with its
> > certificate and encrypted UUID. After Validating Encrypted UUID
> > 
> > and Client certificate server should generate ?Access code?.
> > 
> > 
> > 
> > We have gone through 1.3 Beta source code and realised to achieve this
> > following code changes are needed
> > 
> > 1. Changes in TokenService class (login method) to bypass login form
> > and generate UUID.
> > 
> > 2. Preserve UUID and url parameters obtained during the call in
> > TokenManager .
> > 
> > 3. Redirect to custom_endpoint where client will submit its
> > certificate and encrypted nonce.
> > 
> > This end point will generate ?access Code? once cert authentication
> > completed.
> > 
> > 
> > 
> > It looks we need to make changes in some of core files like
> > TokenService,TokenManager,OAuthFlows,...
> > 
> > Can you please let us know if there is any we can achieve this
> > customization just by hooking our code
> > 
> > (without modifying).
> > 
> > 
> > 
> > Thanks,
> > 
> > Lakshmi Narayana V
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From stian at redhat.com  Tue Sep  9 07:48:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 07:48:47 -0400 (EDT)
Subject: [keycloak-dev] screencasts all updated
In-Reply-To: <1715104666.46021233.1410249798893.JavaMail.zimbra@redhat.com>
References: <540A1E4E.4050404@redhat.com> <540DA147.5080202@redhat.com>
	<777372523.45355455.1410179877071.JavaMail.zimbra@redhat.com>
	<540DA9AB.1030901@redhat.com>
	<2014537319.45452541.1410183029873.JavaMail.zimbra@redhat.com>
	<322271078.45522260.1410185061037.JavaMail.zimbra@redhat.com>
	<540EA275.4030301@redhat.com>
	<1715104666.46021233.1410249798893.JavaMail.zimbra@redhat.com>
Message-ID: <36867284.46155090.1410263327400.JavaMail.zimbra@redhat.com>

I've fixed the user session and removed the idle-timeout. 

I also noticed that the admin console was doing 3 requests to refresh the token every time it expired. I fixed this by making sure only a single refresh request is sent concurrently, others just add to a queue waiting for the refresh token response.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 10:03:18 AM
> Subject: Re: [keycloak-dev] screencasts all updated
> 
> For now I'm changing it to update every time. At the moment we don't have
> cluster support and all user sessions are stored in-mem so this is not an
> issue.
> 
> When we add cluster support we obviously need to distribute this. I think
> delaying the update would be best in those cases. Basically we only
> distribute the last refresh if it's close to expire.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 9 September, 2014 8:47:17 AM
> > Subject: Re: [keycloak-dev] screencasts all updated
> > 
> > On 8.9.2014 16:04, Stian Thorgersen wrote:
> > > Think I've figured out what's going on with problem b.
> > >
> > > UserSession.LastSessionRefresh is only updated if the next access token
> > > refresh is after the timeout. The access token is also only refreshed
> > > when
> > > a request is made. With the default values being:
> > >
> > > * access token lifespan: 1 min
> > > * sso idle timeout: 5 min
> > >
> > > This means that a request has to be made between 4 min and 5 min after
> > > the
> > > last time LastSessionRefresh was updated. So you can basically browse
> > > around all you want for 4 minutes, leave it idle for 60 seconds, then
> > > when
> > > you do the next request the session will be timed out.
> > >
> > > The simple solution seems to be to update LastSessionRefresh everytime
> > > the
> > > token is refreshed. Then post-1.0.final come up with a better scheme to
> > > reduce the amount of writes to UserSession.LastSessionRefresh
> > I wonder if solution could be something simple like:
> > 
> > long minAllowedInterval = min(5 minutes, (sso idle timeout - access
> > token lifespan) / 2);
> > if (System.currentTimeMillis() - lastSessionRefresh < minAllowedInterval) {
> >    updateLastSessionRefresh();
> > }
> > 
> > This will mean that if timeouts are low like:
> > 
> > * access token lifespan: 1 min
> > * sso idle timeout: 5 min
> > 
> > then it will update lastSessionRefresh in every token refresh. On the
> > other hand with bigger values like:
> > 
> > * access token lifespan: 1 min
> > * sso idle timeout: 60 min
> > 
> > it will update lastSessionRefresh just if last refresh was older than
> > around 30 minutes (exactly 30,5 minutes).
> > 
> > This might be good compromise between flexibility and easiness. The
> > easiest approach might be to always update refresh or use some hardcoded
> > minAllowedInterval (like 10 minutes). The most flexible approach might
> > be to add another configuration option for configuring
> > minAllowedInterval, but I am not sure if it's needed (too much
> > configuration options for various timeouts might be confusing for people
> > imo).
> > 
> > Marek
> > >
> > > ----- 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, 8 September, 2014 3:30:29 PM
> > >> Subject: Re: [keycloak-dev] screencasts all updated
> > >>
> > >> Actually it seems we have two problems:
> > >>
> > >> a) idletimeout plugin - this causes the logout if you have multiple tabs
> > >> open. With the SSO idle timeout feature this is not needed, so we should
> > >> just remove it to fix this issue
> > >>
> > >> b) issue with sso idle timeout - I tried setting the SSO idle timeout to
> > >> a
> > >> low number (30 seconds), with access token lifespan lower (5 seconds)
> > >> and
> > >> was continuously browsing. After 1 min or two I was logged out, even
> > >> though
> > >> I was continuously doing requests (and network log shows it was doing
> > >> refreshing the token)
> > >>
> > >> ----- 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, 8 September, 2014 3:05:47 PM
> > >>> Subject: Re: [keycloak-dev] screencasts all updated
> > >>>
> > >>>
> > >>>
> > >>> On 9/8/2014 8:37 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: Monday, 8 September, 2014 2:29:59 PM
> > >>>>> Subject: Re: [keycloak-dev] screencasts all updated
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On 9/8/2014 4:00 AM, Stian Thorgersen wrote:
> > >>>>>>
> > >>>>>> ----- Original Message -----
> > >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>>> To: keycloak-dev at lists.jboss.org
> > >>>>>>> Sent: Friday, 5 September, 2014 10:34:22 PM
> > >>>>>>> Subject: [keycloak-dev] screencasts all updated
> > >>>>>>>
> > >>>>>>> man I hate doing screencasts, but they are finally updated.  It
> > >>>>>>> really
> > >>>>>>> needed to be done as they were not in sync with the current version
> > >>>>>>> of
> > >>>>>>> keycloak.  I haven't linked them yet though.  I'll do that when we
> > >>>>>>> release.
> > >>>>>> Nice - next time I can pitch in and do a few ;)
> > >>>>>>
> > >>>>>>> One thing that drove me crazy was that I kept on getting logged out
> > >>>>>>> of
> > >>>>>>> the admin console sporadically.  Gotta figure out what is going
> > >>>>>>> wrong
> > >>>>>>> here.
> > >>>>>> Did you have multiple tabs open? We have a timer that logs you out
> > >>>>>> after
> > >>>>>> 300 seconds of inactivity. Problem is that if you have two tabs open
> > >>>>>> with
> > >>>>>> the admin console, one you're actively using and another in the
> > >>>>>> background, the background tab will end up logging you out after 300
> > >>>>>> seconds.
> > >>>>>>
> > >>>>> That might be it.
> > >>>>>
> > >>>>>> We can either remove this altogether (my preferred option) and let
> > >>>>>> the
> > >>>>>> SSO
> > >>>>>> idle timeout deal with it, or we could make sure your only logged
> > >>>>>> out
> > >>>>>> if
> > >>>>>> there's no activity to the console (can have tabs write a timestamp
> > >>>>>> to
> > >>>>>> html5 storage periodically and check this before logging out).
> > >>>>>>
> > >>>>> Or just have the timer download the SSO idle timeout.
> > >>>> Not sure I follow. Wouldn't that just change the timeout value, but
> > >>>> still
> > >>>> leave an inactive tab able to logout all tabs?
> > >>>>
> > >>> Actually, are you sure that is it?  I thought the timer was for the
> > >>> timeout warning, not for anything else?  I'm not even seeing the
> > >>> warning.
> > >>>
> > >>>
> > >>> --
> > >>> 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
> > 
> > _______________________________________________
> > 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 Sep  9 08:10:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 08:10:22 -0400 (EDT)
Subject: [keycloak-dev] theme changes and questions
In-Reply-To: <540DAAA7.2020408@redhat.com>
References: <5405E521.3080303@redhat.com>
	<403206870.43005579.1409730318407.JavaMail.zimbra@redhat.com>
	<211374602.45403890.1410181681984.JavaMail.zimbra@redhat.com>
	<540DAAA7.2020408@redhat.com>
Message-ID: <1449260620.46173638.1410264622021.JavaMail.zimbra@redhat.com>

I moved the themes and updated examples/themes/README.md

----- 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, 8 September, 2014 3:09:59 PM
> Subject: Re: [keycloak-dev] theme changes and questions
> 
> Yeah, sorry.  I forgot to do that.
> 
> On 9/8/2014 9:08 AM, Stian Thorgersen wrote:
> > Can we move the logo-example themes to examples/themes instead of bundling
> > them with the core themes?
> >
> > ----- 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, 3 September, 2014 9:45:18 AM
> >> Subject: Re: [keycloak-dev] theme changes and questions
> >>
> >> Looks good, except example themes should be in "examples/themes". They're
> >> included in the dists (under "examples/themes") and users should copy them
> >> manually to "standalone/configuration/themes".
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 2 September, 2014 5:41:21 PM
> >>> Subject: [keycloak-dev] theme changes and questions
> >>>
> >>> I added a "logo-example" theme to the distro.  This just provides a
> >>> theme for login, account, and admin that overrides the logo (Keycloak
> >>> image to Red Hat image).
> >>>
> >>> Because admin console is not based on freemarker templates, I refactored
> >>> the admin console 'styles.css' to make it easier to override styles for
> >>> the admin console.  This now includes a 'base-styles.css' and a
> >>> 'overrides.css'.  The 'logo-example' theme for admin adds changes within
> >>> 'overrides.css'.  If you think this is the right way to implement this,
> >>> I'll update the documentation to talk about how to override admin theme
> >>> styles.
> >>>
> >>>
> >>> --
> >>> 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 bburke at redhat.com  Tue Sep  9 13:30:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 09 Sep 2014 13:30:16 -0400
Subject: [keycloak-dev] Are we all set?
Message-ID: <540F3928.7020305@redhat.com>

can I start doing final testing and release Thursday?

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

From stian at redhat.com  Tue Sep  9 14:01:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 9 Sep 2014 14:01:23 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <540F3928.7020305@redhat.com>
References: <540F3928.7020305@redhat.com>
Message-ID: <1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>

Yes - I'll do a round of testing tomorrow, but there's nothing outstanding I'm aware of

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 9 September, 2014 7:30:16 PM
> Subject: [keycloak-dev] Are we all set?
> 
> can I start doing final testing and release Thursday?
> 
> --
> 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  Tue Sep  9 17:47:49 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 09 Sep 2014 23:47:49 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
Message-ID: <540F7585.9020601@redhat.com>

Hi,

I am sorry to not help more with the release as I needed to work 
especially on some portal related stuff last weeks (hopefully it's gone 
now)...

Found couple of things:
* AccountService is actually broken for me in Chrome due to latest CSRF 
stuff. In FF it works fine, but in Chrome I can't update account or 
password. For some reason Chrome is always adding "Origin" header to the 
update requests (even if they are not ajax requests). So the newly added 
condition for CSRF in AccountService.init will always fail. I have 
Chrome 37.0.2062.94 (64-bit) .

* ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is 
not available with CORS . I've created JIRA 
https://issues.jboss.org/browse/KEYCLOAK-670 and send PR 
https://github.com/keycloak/keycloak/pull/683 for this, which is adding 
authentication for ServerInfoAdminResource and then it use allowOrigins 
from the authenticated bearer token. Admin console is already using 
bearer token for sending ServerInfo requests, so no changes are needed 
here. I believe that ServerInfoAdminResource should be authenticated 
(don't know why stuff like available social providers or themes should 
be publicly available). Let me know if you seeing issues with it. I did 
not merge PR so far as version in master is already changed to 1.0-Final 
so not sure what is the state of the release .

* Realm public resource (http://localhost:8080/auth/realms/master) is 
also not available for CORS requests. Not sure if this is an issue or 
not? Thing is that unauthenticated requests can't use CORS at this 
moment as I don't know what allowedOrigins to use. Only option is to 
allow it for all allowedOrigins (send same "Access-Control-Allow-Origin" 
as original value of "Origin" header from the request)

* There is still quite a lot of INFO logging . For example when I send 
product request from the cors-demo example I have 6 new INFO messages in 
log (Mainly from org.keycloak.adapters package)

I will continue with the testing tomorrow.

Marek

On 9.9.2014 20:01, Stian Thorgersen wrote:
> Yes - I'll do a round of testing tomorrow, but there's nothing outstanding I'm aware of
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 9 September, 2014 7:30:16 PM
>> Subject: [keycloak-dev] Are we all set?
>>
>> can I start doing final testing and release Thursday?
>>
>> --
>> 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

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

From mposolda at redhat.com  Tue Sep  9 17:55:11 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 09 Sep 2014 23:55:11 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <540F7585.9020601@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com>
Message-ID: <540F773F.6060000@redhat.com>

On 9.9.2014 23:47, Marek Posolda wrote:
> Hi,
>
> I am sorry to not help more with the release as I needed to work 
> especially on some portal related stuff last weeks (hopefully it's 
> gone now)...
>
> Found couple of things:
> * AccountService is actually broken for me in Chrome due to latest 
> CSRF stuff. In FF it works fine, but in Chrome I can't update account 
> or password. For some reason Chrome is always adding "Origin" header 
> to the update requests (even if they are not ajax requests). So the 
> newly added condition for CSRF in AccountService.init will always 
> fail. I have Chrome 37.0.2062.94 (64-bit) .
Created https://issues.jboss.org/browse/KEYCLOAK-671 with blocker priority.




>
> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is 
> not available with CORS . I've created JIRA 
> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR 
> https://github.com/keycloak/keycloak/pull/683 for this, which is 
> adding authentication for ServerInfoAdminResource and then it use 
> allowOrigins from the authenticated bearer token. Admin console is 
> already using bearer token for sending ServerInfo requests, so no 
> changes are needed here. I believe that ServerInfoAdminResource should 
> be authenticated (don't know why stuff like available social providers 
> or themes should be publicly available). Let me know if you seeing 
> issues with it. I did not merge PR so far as version in master is 
> already changed to 1.0-Final so not sure what is the state of the 
> release .
>
> * Realm public resource (http://localhost:8080/auth/realms/master) is 
> also not available for CORS requests. Not sure if this is an issue or 
> not? Thing is that unauthenticated requests can't use CORS at this 
> moment as I don't know what allowedOrigins to use. Only option is to 
> allow it for all allowedOrigins (send same 
> "Access-Control-Allow-Origin" as original value of "Origin" header 
> from the request)
>
> * There is still quite a lot of INFO logging . For example when I send 
> product request from the cors-demo example I have 6 new INFO messages 
> in log (Mainly from org.keycloak.adapters package)
>
> I will continue with the testing tomorrow.
>
> Marek
>
> On 9.9.2014 20:01, Stian Thorgersen wrote:
>> Yes - I'll do a round of testing tomorrow, but there's nothing outstanding I'm aware of
>>
>> ----- Original Message -----
>>> From: "Bill Burke"<bburke at redhat.com>
>>> To:keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 9 September, 2014 7:30:16 PM
>>> Subject: [keycloak-dev] Are we all set?
>>>
>>> can I start doing final testing and release Thursday?
>>>
>>> --
>>> 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
>
>
>
> _______________________________________________
> 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/20140909/ce856a9c/attachment-0001.html 

From bburke at redhat.com  Tue Sep  9 21:09:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 09 Sep 2014 21:09:20 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <540F7585.9020601@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com>
Message-ID: <540FA4C0.2030409@redhat.com>



On 9/9/2014 5:47 PM, Marek Posolda wrote:
> Hi,
>
> I am sorry to not help more with the release as I needed to work
> especially on some portal related stuff last weeks (hopefully it's gone
> now)...
>
> Found couple of things:
> * AccountService is actually broken for me in Chrome due to latest CSRF
> stuff. In FF it works fine, but in Chrome I can't update account or
> password. For some reason Chrome is always adding "Origin" header to the
> update requests (even if they are not ajax requests). So the newly added
> condition for CSRF in AccountService.init will always fail. I have
> Chrome 37.0.2062.94 (64-bit) .
>

Ok, I thought Origin header wasn't supposed to be sent with Browser 
requests.  I can probably fix this by allowing same origin.


> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
> not available with CORS . I've created JIRA
> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
> authentication for ServerInfoAdminResource and then it use allowOrigins
> from the authenticated bearer token. Admin console is already using
> bearer token for sending ServerInfo requests, so no changes are needed
> here. I believe that ServerInfoAdminResource should be authenticated
> (don't know why stuff like available social providers or themes should
> be publicly available). Let me know if you seeing issues with it. I did
> not merge PR so far as version in master is already changed to 1.0-Final
> so not sure what is the state of the release .
>

Merge it.

> * Realm public resource (http://localhost:8080/auth/realms/master) is
> also not available for CORS requests. Not sure if this is an issue or
> not? Thing is that unauthenticated requests can't use CORS at this
> moment as I don't know what allowedOrigins to use. Only option is to
> allow it for all allowedOrigins (send same "Access-Control-Allow-Origin"
> as original value of "Origin" header from the request)
>
> * There is still quite a lot of INFO logging . For example when I send
> product request from the cors-demo example I have 6 new INFO messages in
> log (Mainly from org.keycloak.adapters package)
>

Ping me on your status tomorrow (Wednesday).  I'll complete whatever you 
don't finish above.

Thanks.

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

From stian at redhat.com  Wed Sep 10 04:37:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 10 Sep 2014 04:37:15 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <540FA4C0.2030409@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
Message-ID: <1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 10 September, 2014 3:09:20 AM
> Subject: Re: [keycloak-dev] Are we all set?
> 
> 
> 
> On 9/9/2014 5:47 PM, Marek Posolda wrote:
> > Hi,
> >
> > I am sorry to not help more with the release as I needed to work
> > especially on some portal related stuff last weeks (hopefully it's gone
> > now)...
> >
> > Found couple of things:
> > * AccountService is actually broken for me in Chrome due to latest CSRF
> > stuff. In FF it works fine, but in Chrome I can't update account or
> > password. For some reason Chrome is always adding "Origin" header to the
> > update requests (even if they are not ajax requests). So the newly added
> > condition for CSRF in AccountService.init will always fail. I have
> > Chrome 37.0.2062.94 (64-bit) .
> >
> 
> Ok, I thought Origin header wasn't supposed to be sent with Browser
> requests.  I can probably fix this by allowing same origin.

Added fix to allow same origin. I also added check of 'Referer' header to make sure it's same origin as well.

> 
> 
> > * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
> > not available with CORS . I've created JIRA
> > https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> > https://github.com/keycloak/keycloak/pull/683 for this, which is adding
> > authentication for ServerInfoAdminResource and then it use allowOrigins
> > from the authenticated bearer token. Admin console is already using
> > bearer token for sending ServerInfo requests, so no changes are needed
> > here. I believe that ServerInfoAdminResource should be authenticated
> > (don't know why stuff like available social providers or themes should
> > be publicly available). Let me know if you seeing issues with it. I did
> > not merge PR so far as version in master is already changed to 1.0-Final
> > so not sure what is the state of the release .
> >
> 
> Merge it.
> 
> > * Realm public resource (http://localhost:8080/auth/realms/master) is
> > also not available for CORS requests. Not sure if this is an issue or
> > not? Thing is that unauthenticated requests can't use CORS at this
> > moment as I don't know what allowedOrigins to use. Only option is to
> > allow it for all allowedOrigins (send same "Access-Control-Allow-Origin"
> > as original value of "Origin" header from the request)
> >
> > * There is still quite a lot of INFO logging . For example when I send
> > product request from the cors-demo example I have 6 new INFO messages in
> > log (Mainly from org.keycloak.adapters package)
> >
> 
> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
> don't finish above.
> 
> Thanks.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Sep 10 08:11:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 10 Sep 2014 08:11:34 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
Message-ID: <1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>

We also need to reduce info level log output from adapters. I did this for the server for rc-2, but completely forgot about adapters. Marek is already working on this, and I guess it shouldn't take very long.

----- 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, 10 September, 2014 10:37:15 AM
> Subject: Re: [keycloak-dev] Are we all set?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> > <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 10 September, 2014 3:09:20 AM
> > Subject: Re: [keycloak-dev] Are we all set?
> > 
> > 
> > 
> > On 9/9/2014 5:47 PM, Marek Posolda wrote:
> > > Hi,
> > >
> > > I am sorry to not help more with the release as I needed to work
> > > especially on some portal related stuff last weeks (hopefully it's gone
> > > now)...
> > >
> > > Found couple of things:
> > > * AccountService is actually broken for me in Chrome due to latest CSRF
> > > stuff. In FF it works fine, but in Chrome I can't update account or
> > > password. For some reason Chrome is always adding "Origin" header to the
> > > update requests (even if they are not ajax requests). So the newly added
> > > condition for CSRF in AccountService.init will always fail. I have
> > > Chrome 37.0.2062.94 (64-bit) .
> > >
> > 
> > Ok, I thought Origin header wasn't supposed to be sent with Browser
> > requests.  I can probably fix this by allowing same origin.
> 
> Added fix to allow same origin. I also added check of 'Referer' header to
> make sure it's same origin as well.
> 
> > 
> > 
> > > * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
> > > not available with CORS . I've created JIRA
> > > https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> > > https://github.com/keycloak/keycloak/pull/683 for this, which is adding
> > > authentication for ServerInfoAdminResource and then it use allowOrigins
> > > from the authenticated bearer token. Admin console is already using
> > > bearer token for sending ServerInfo requests, so no changes are needed
> > > here. I believe that ServerInfoAdminResource should be authenticated
> > > (don't know why stuff like available social providers or themes should
> > > be publicly available). Let me know if you seeing issues with it. I did
> > > not merge PR so far as version in master is already changed to 1.0-Final
> > > so not sure what is the state of the release .
> > >
> > 
> > Merge it.
> > 
> > > * Realm public resource (http://localhost:8080/auth/realms/master) is
> > > also not available for CORS requests. Not sure if this is an issue or
> > > not? Thing is that unauthenticated requests can't use CORS at this
> > > moment as I don't know what allowedOrigins to use. Only option is to
> > > allow it for all allowedOrigins (send same "Access-Control-Allow-Origin"
> > > as original value of "Origin" header from the request)
> > >
> > > * There is still quite a lot of INFO logging . For example when I send
> > > product request from the cors-demo example I have 6 new INFO messages in
> > > log (Mainly from org.keycloak.adapters package)
> > >
> > 
> > Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
> > don't finish above.
> > 
> > Thanks.
> > 
> > --
> > 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 Sep 10 08:49:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 10 Sep 2014 08:49:12 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>
Message-ID: <1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>

Apparently login with keycloak.js doesn't work on Safari (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before releasing :/

----- 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, 10 September, 2014 2:11:34 PM
> Subject: Re: [keycloak-dev] Are we all set?
> 
> We also need to reduce info level log output from adapters. I did this for
> the server for rc-2, but completely forgot about adapters. Marek is already
> working on this, and I guess it shouldn't take very long.
> 
> ----- 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, 10 September, 2014 10:37:15 AM
> > Subject: Re: [keycloak-dev] Are we all set?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> > > <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 10 September, 2014 3:09:20 AM
> > > Subject: Re: [keycloak-dev] Are we all set?
> > > 
> > > 
> > > 
> > > On 9/9/2014 5:47 PM, Marek Posolda wrote:
> > > > Hi,
> > > >
> > > > I am sorry to not help more with the release as I needed to work
> > > > especially on some portal related stuff last weeks (hopefully it's gone
> > > > now)...
> > > >
> > > > Found couple of things:
> > > > * AccountService is actually broken for me in Chrome due to latest CSRF
> > > > stuff. In FF it works fine, but in Chrome I can't update account or
> > > > password. For some reason Chrome is always adding "Origin" header to
> > > > the
> > > > update requests (even if they are not ajax requests). So the newly
> > > > added
> > > > condition for CSRF in AccountService.init will always fail. I have
> > > > Chrome 37.0.2062.94 (64-bit) .
> > > >
> > > 
> > > Ok, I thought Origin header wasn't supposed to be sent with Browser
> > > requests.  I can probably fix this by allowing same origin.
> > 
> > Added fix to allow same origin. I also added check of 'Referer' header to
> > make sure it's same origin as well.
> > 
> > > 
> > > 
> > > > * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
> > > > not available with CORS . I've created JIRA
> > > > https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> > > > https://github.com/keycloak/keycloak/pull/683 for this, which is adding
> > > > authentication for ServerInfoAdminResource and then it use allowOrigins
> > > > from the authenticated bearer token. Admin console is already using
> > > > bearer token for sending ServerInfo requests, so no changes are needed
> > > > here. I believe that ServerInfoAdminResource should be authenticated
> > > > (don't know why stuff like available social providers or themes should
> > > > be publicly available). Let me know if you seeing issues with it. I did
> > > > not merge PR so far as version in master is already changed to
> > > > 1.0-Final
> > > > so not sure what is the state of the release .
> > > >
> > > 
> > > Merge it.
> > > 
> > > > * Realm public resource (http://localhost:8080/auth/realms/master) is
> > > > also not available for CORS requests. Not sure if this is an issue or
> > > > not? Thing is that unauthenticated requests can't use CORS at this
> > > > moment as I don't know what allowedOrigins to use. Only option is to
> > > > allow it for all allowedOrigins (send same
> > > > "Access-Control-Allow-Origin"
> > > > as original value of "Origin" header from the request)
> > > >
> > > > * There is still quite a lot of INFO logging . For example when I send
> > > > product request from the cors-demo example I have 6 new INFO messages
> > > > in
> > > > log (Mainly from org.keycloak.adapters package)
> > > >
> > > 
> > > Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
> > > don't finish above.
> > > 
> > > Thanks.
> > > 
> > > --
> > > 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  Wed Sep 10 09:03:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 09:03:12 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>
	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>
Message-ID: <54104C10.9040108@redhat.com>

I'm charging up my macbook.  I'll look into it.

On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
> Apparently login with keycloak.js doesn't work on Safari (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before releasing :/
>
> ----- 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, 10 September, 2014 2:11:34 PM
>> Subject: Re: [keycloak-dev] Are we all set?
>>
>> We also need to reduce info level log output from adapters. I did this for
>> the server for rc-2, but completely forgot about adapters. Marek is already
>> working on this, and I guess it shouldn't take very long.
>>
>> ----- 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, 10 September, 2014 10:37:15 AM
>>> Subject: Re: [keycloak-dev] Are we all set?
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>> <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>
>>>>
>>>>
>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>> Hi,
>>>>>
>>>>> I am sorry to not help more with the release as I needed to work
>>>>> especially on some portal related stuff last weeks (hopefully it's gone
>>>>> now)...
>>>>>
>>>>> Found couple of things:
>>>>> * AccountService is actually broken for me in Chrome due to latest CSRF
>>>>> stuff. In FF it works fine, but in Chrome I can't update account or
>>>>> password. For some reason Chrome is always adding "Origin" header to
>>>>> the
>>>>> update requests (even if they are not ajax requests). So the newly
>>>>> added
>>>>> condition for CSRF in AccountService.init will always fail. I have
>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>
>>>>
>>>> Ok, I thought Origin header wasn't supposed to be sent with Browser
>>>> requests.  I can probably fix this by allowing same origin.
>>>
>>> Added fix to allow same origin. I also added check of 'Referer' header to
>>> make sure it's same origin as well.
>>>
>>>>
>>>>
>>>>> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
>>>>> not available with CORS . I've created JIRA
>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
>>>>> authentication for ServerInfoAdminResource and then it use allowOrigins
>>>>> from the authenticated bearer token. Admin console is already using
>>>>> bearer token for sending ServerInfo requests, so no changes are needed
>>>>> here. I believe that ServerInfoAdminResource should be authenticated
>>>>> (don't know why stuff like available social providers or themes should
>>>>> be publicly available). Let me know if you seeing issues with it. I did
>>>>> not merge PR so far as version in master is already changed to
>>>>> 1.0-Final
>>>>> so not sure what is the state of the release .
>>>>>
>>>>
>>>> Merge it.
>>>>
>>>>> * Realm public resource (http://localhost:8080/auth/realms/master) is
>>>>> also not available for CORS requests. Not sure if this is an issue or
>>>>> not? Thing is that unauthenticated requests can't use CORS at this
>>>>> moment as I don't know what allowedOrigins to use. Only option is to
>>>>> allow it for all allowedOrigins (send same
>>>>> "Access-Control-Allow-Origin"
>>>>> as original value of "Origin" header from the request)
>>>>>
>>>>> * There is still quite a lot of INFO logging . For example when I send
>>>>> product request from the cors-demo example I have 6 new INFO messages
>>>>> in
>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>
>>>>
>>>> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
>>>> don't finish above.
>>>>
>>>> Thanks.
>>>>
>>>> --
>>>> 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 stian at redhat.com  Wed Sep 10 09:28:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 10 Sep 2014 09:28:58 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <54104C10.9040108@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>
	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>
	<54104C10.9040108@redhat.com>
Message-ID: <5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>

There's no Safari issue after all! So we're good to go.

----- 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, 10 September, 2014 3:03:12 PM
> Subject: Re: [keycloak-dev] Are we all set?
> 
> I'm charging up my macbook.  I'll look into it.
> 
> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
> > Apparently login with keycloak.js doesn't work on Safari
> > (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before
> > releasing :/
> >
> > ----- 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, 10 September, 2014 2:11:34 PM
> >> Subject: Re: [keycloak-dev] Are we all set?
> >>
> >> We also need to reduce info level log output from adapters. I did this for
> >> the server for rc-2, but completely forgot about adapters. Marek is
> >> already
> >> working on this, and I guess it shouldn't take very long.
> >>
> >> ----- 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, 10 September, 2014 10:37:15 AM
> >>> Subject: Re: [keycloak-dev] Are we all set?
> >>>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> >>>> <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
> >>>> Subject: Re: [keycloak-dev] Are we all set?
> >>>>
> >>>>
> >>>>
> >>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I am sorry to not help more with the release as I needed to work
> >>>>> especially on some portal related stuff last weeks (hopefully it's gone
> >>>>> now)...
> >>>>>
> >>>>> Found couple of things:
> >>>>> * AccountService is actually broken for me in Chrome due to latest CSRF
> >>>>> stuff. In FF it works fine, but in Chrome I can't update account or
> >>>>> password. For some reason Chrome is always adding "Origin" header to
> >>>>> the
> >>>>> update requests (even if they are not ajax requests). So the newly
> >>>>> added
> >>>>> condition for CSRF in AccountService.init will always fail. I have
> >>>>> Chrome 37.0.2062.94 (64-bit) .
> >>>>>
> >>>>
> >>>> Ok, I thought Origin header wasn't supposed to be sent with Browser
> >>>> requests.  I can probably fix this by allowing same origin.
> >>>
> >>> Added fix to allow same origin. I also added check of 'Referer' header to
> >>> make sure it's same origin as well.
> >>>
> >>>>
> >>>>
> >>>>> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
> >>>>> not available with CORS . I've created JIRA
> >>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> >>>>> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
> >>>>> authentication for ServerInfoAdminResource and then it use allowOrigins
> >>>>> from the authenticated bearer token. Admin console is already using
> >>>>> bearer token for sending ServerInfo requests, so no changes are needed
> >>>>> here. I believe that ServerInfoAdminResource should be authenticated
> >>>>> (don't know why stuff like available social providers or themes should
> >>>>> be publicly available). Let me know if you seeing issues with it. I did
> >>>>> not merge PR so far as version in master is already changed to
> >>>>> 1.0-Final
> >>>>> so not sure what is the state of the release .
> >>>>>
> >>>>
> >>>> Merge it.
> >>>>
> >>>>> * Realm public resource (http://localhost:8080/auth/realms/master) is
> >>>>> also not available for CORS requests. Not sure if this is an issue or
> >>>>> not? Thing is that unauthenticated requests can't use CORS at this
> >>>>> moment as I don't know what allowedOrigins to use. Only option is to
> >>>>> allow it for all allowedOrigins (send same
> >>>>> "Access-Control-Allow-Origin"
> >>>>> as original value of "Origin" header from the request)
> >>>>>
> >>>>> * There is still quite a lot of INFO logging . For example when I send
> >>>>> product request from the cors-demo example I have 6 new INFO messages
> >>>>> in
> >>>>> log (Mainly from org.keycloak.adapters package)
> >>>>>
> >>>>
> >>>> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
> >>>> don't finish above.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> --
> >>>> 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 bburke at redhat.com  Wed Sep 10 09:37:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 09:37:27 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>
	<540F7585.9020601@redhat.com> <540FA4C0.2030409@redhat.com>
	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>
	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>
	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>
	<54104C10.9040108@redhat.com>
	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
Message-ID: <54105417.2000009@redhat.com>

I'll handle the logging stuff if Marek hasn't gotten to it yet.  Thanks 
for doing all the issues reported by Marek last night.

i'll run my last tests using IE and EAP 6.3 to make sure we're good on 
those platforms.

On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
> There's no Safari issue after all! So we're good to go.
>
> ----- 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, 10 September, 2014 3:03:12 PM
>> Subject: Re: [keycloak-dev] Are we all set?
>>
>> I'm charging up my macbook.  I'll look into it.
>>
>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>> Apparently login with keycloak.js doesn't work on Safari
>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before
>>> releasing :/
>>>
>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>
>>>> We also need to reduce info level log output from adapters. I did this for
>>>> the server for rc-2, but completely forgot about adapters. Marek is
>>>> already
>>>> working on this, and I guess it shouldn't take very long.
>>>>
>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>> <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I am sorry to not help more with the release as I needed to work
>>>>>>> especially on some portal related stuff last weeks (hopefully it's gone
>>>>>>> now)...
>>>>>>>
>>>>>>> Found couple of things:
>>>>>>> * AccountService is actually broken for me in Chrome due to latest CSRF
>>>>>>> stuff. In FF it works fine, but in Chrome I can't update account or
>>>>>>> password. For some reason Chrome is always adding "Origin" header to
>>>>>>> the
>>>>>>> update requests (even if they are not ajax requests). So the newly
>>>>>>> added
>>>>>>> condition for CSRF in AccountService.init will always fail. I have
>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>
>>>>>>
>>>>>> Ok, I thought Origin header wasn't supposed to be sent with Browser
>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>
>>>>> Added fix to allow same origin. I also added check of 'Referer' header to
>>>>> make sure it's same origin as well.
>>>>>
>>>>>>
>>>>>>
>>>>>>> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>> not available with CORS . I've created JIRA
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
>>>>>>> authentication for ServerInfoAdminResource and then it use allowOrigins
>>>>>>> from the authenticated bearer token. Admin console is already using
>>>>>>> bearer token for sending ServerInfo requests, so no changes are needed
>>>>>>> here. I believe that ServerInfoAdminResource should be authenticated
>>>>>>> (don't know why stuff like available social providers or themes should
>>>>>>> be publicly available). Let me know if you seeing issues with it. I did
>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>> 1.0-Final
>>>>>>> so not sure what is the state of the release .
>>>>>>>
>>>>>>
>>>>>> Merge it.
>>>>>>
>>>>>>> * Realm public resource (http://localhost:8080/auth/realms/master) is
>>>>>>> also not available for CORS requests. Not sure if this is an issue or
>>>>>>> not? Thing is that unauthenticated requests can't use CORS at this
>>>>>>> moment as I don't know what allowedOrigins to use. Only option is to
>>>>>>> allow it for all allowedOrigins (send same
>>>>>>> "Access-Control-Allow-Origin"
>>>>>>> as original value of "Origin" header from the request)
>>>>>>>
>>>>>>> * There is still quite a lot of INFO logging . For example when I send
>>>>>>> product request from the cors-demo example I have 6 new INFO messages
>>>>>>> in
>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>
>>>>>>
>>>>>> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
>>>>>> don't finish above.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> --
>>>>>> 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
>>

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

From mposolda at redhat.com  Wed Sep 10 09:49:16 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 10 Sep 2014 15:49:16 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <54105417.2000009@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>	<540F7585.9020601@redhat.com>
	<540FA4C0.2030409@redhat.com>	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>	<54104C10.9040108@redhat.com>	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
	<54105417.2000009@redhat.com>
Message-ID: <541056DC.7070308@redhat.com>

Hi Bill,

I am on reducing INFO stuff and will commit the fix in few minutes. Will 
let you know again once it's done.

Marek

On 10.9.2014 15:37, Bill Burke wrote:
> I'll handle the logging stuff if Marek hasn't gotten to it yet.  Thanks
> for doing all the issues reported by Marek last night.
>
> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
> those platforms.
>
> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>> There's no Safari issue after all! So we're good to go.
>>
>> ----- 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, 10 September, 2014 3:03:12 PM
>>> Subject: Re: [keycloak-dev] Are we all set?
>>>
>>> I'm charging up my macbook.  I'll look into it.
>>>
>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>> Apparently login with keycloak.js doesn't work on Safari
>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before
>>>> releasing :/
>>>>
>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>
>>>>> We also need to reduce info level log output from adapters. I did this for
>>>>> the server for rc-2, but completely forgot about adapters. Marek is
>>>>> already
>>>>> working on this, and I guess it shouldn't take very long.
>>>>>
>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>> <stian at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am sorry to not help more with the release as I needed to work
>>>>>>>> especially on some portal related stuff last weeks (hopefully it's gone
>>>>>>>> now)...
>>>>>>>>
>>>>>>>> Found couple of things:
>>>>>>>> * AccountService is actually broken for me in Chrome due to latest CSRF
>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update account or
>>>>>>>> password. For some reason Chrome is always adding "Origin" header to
>>>>>>>> the
>>>>>>>> update requests (even if they are not ajax requests). So the newly
>>>>>>>> added
>>>>>>>> condition for CSRF in AccountService.init will always fail. I have
>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>
>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with Browser
>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>> Added fix to allow same origin. I also added check of 'Referer' header to
>>>>>> make sure it's same origin as well.
>>>>>>
>>>>>>>
>>>>>>>> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
>>>>>>>> authentication for ServerInfoAdminResource and then it use allowOrigins
>>>>>>>> from the authenticated bearer token. Admin console is already using
>>>>>>>> bearer token for sending ServerInfo requests, so no changes are needed
>>>>>>>> here. I believe that ServerInfoAdminResource should be authenticated
>>>>>>>> (don't know why stuff like available social providers or themes should
>>>>>>>> be publicly available). Let me know if you seeing issues with it. I did
>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>> 1.0-Final
>>>>>>>> so not sure what is the state of the release .
>>>>>>>>
>>>>>>> Merge it.
>>>>>>>
>>>>>>>> * Realm public resource (http://localhost:8080/auth/realms/master) is
>>>>>>>> also not available for CORS requests. Not sure if this is an issue or
>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at this
>>>>>>>> moment as I don't know what allowedOrigins to use. Only option is to
>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>
>>>>>>>> * There is still quite a lot of INFO logging . For example when I send
>>>>>>>> product request from the cors-demo example I have 6 new INFO messages
>>>>>>>> in
>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>
>>>>>>> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
>>>>>>> don't finish above.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> --
>>>>>>> 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 mposolda at redhat.com  Wed Sep 10 10:27:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 10 Sep 2014 16:27:56 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <541056DC.7070308@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>	<540F7585.9020601@redhat.com>	<540FA4C0.2030409@redhat.com>	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>	<54104C10.9040108@redhat.com>	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>	<54105417.2000009@redhat.com>
	<541056DC.7070308@redhat.com>
Message-ID: <54105FEC.4040004@redhat.com>

I've pushed the fix for reduced INFO logging level.

I've found few other things during quick testing like:

- Users can register with invalid email like "aaa" . Also they can 
change their email in account management to "aaa". Just keycloak admin 
console is fine and allows to save just valid email (

- In account management, when I fill firstName, lastName for admin user 
and won't fill email and then click "Save", it displays me error message 
"You didn't specify email", which is correct. But firstName and lastName 
are cleared too. Similar can be reproduced when updating user. Basically 
Account mgmt form is always reading persistent values from DB and 
ignores values previously filled by user before failed validation.

I guess these are not blocker for release and especially the second one 
might be risky to fix now? wdyt?

Marek

On 10.9.2014 15:49, Marek Posolda wrote:
> Hi Bill,
>
> I am on reducing INFO stuff and will commit the fix in few minutes. Will
> let you know again once it's done.
>
> Marek
>
> On 10.9.2014 15:37, Bill Burke wrote:
>> I'll handle the logging stuff if Marek hasn't gotten to it yet.  Thanks
>> for doing all the issues reported by Marek last night.
>>
>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
>> those platforms.
>>
>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>> There's no Safari issue after all! So we're good to go.
>>>
>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>
>>>> I'm charging up my macbook.  I'll look into it.
>>>>
>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix this before
>>>>> releasing :/
>>>>>
>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>
>>>>>> We also need to reduce info level log output from adapters. I did this for
>>>>>> the server for rc-2, but completely forgot about adapters. Marek is
>>>>>> already
>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>
>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>> <stian at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am sorry to not help more with the release as I needed to work
>>>>>>>>> especially on some portal related stuff last weeks (hopefully it's gone
>>>>>>>>> now)...
>>>>>>>>>
>>>>>>>>> Found couple of things:
>>>>>>>>> * AccountService is actually broken for me in Chrome due to latest CSRF
>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update account or
>>>>>>>>> password. For some reason Chrome is always adding "Origin" header to
>>>>>>>>> the
>>>>>>>>> update requests (even if they are not ajax requests). So the newly
>>>>>>>>> added
>>>>>>>>> condition for CSRF in AccountService.init will always fail. I have
>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>
>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with Browser
>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>> Added fix to allow same origin. I also added check of 'Referer' header to
>>>>>>> make sure it's same origin as well.
>>>>>>>
>>>>>>>>> * ServerInfo request (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which is adding
>>>>>>>>> authentication for ServerInfoAdminResource and then it use allowOrigins
>>>>>>>>> from the authenticated bearer token. Admin console is already using
>>>>>>>>> bearer token for sending ServerInfo requests, so no changes are needed
>>>>>>>>> here. I believe that ServerInfoAdminResource should be authenticated
>>>>>>>>> (don't know why stuff like available social providers or themes should
>>>>>>>>> be publicly available). Let me know if you seeing issues with it. I did
>>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>>> 1.0-Final
>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>
>>>>>>>> Merge it.
>>>>>>>>
>>>>>>>>> * Realm public resource (http://localhost:8080/auth/realms/master) is
>>>>>>>>> also not available for CORS requests. Not sure if this is an issue or
>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at this
>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option is to
>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>
>>>>>>>>> * There is still quite a lot of INFO logging . For example when I send
>>>>>>>>> product request from the cors-demo example I have 6 new INFO messages
>>>>>>>>> in
>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>
>>>>>>>> Ping me on your status tomorrow (Wednesday).  I'll complete whatever you
>>>>>>>> don't finish above.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Sep 10 10:31:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 10:31:08 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <54105FEC.4040004@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>	<540F7585.9020601@redhat.com>	<540FA4C0.2030409@redhat.com>	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>	<54104C10.9040108@redhat.com>	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>	<54105417.2000009@redhat.com>
	<541056DC.7070308@redhat.com> <54105FEC.4040004@redhat.com>
Message-ID: <541060AC.2070707@redhat.com>

Yeah, just wait IMO.

On 9/10/2014 10:27 AM, Marek Posolda wrote:
> I've pushed the fix for reduced INFO logging level.
>
> I've found few other things during quick testing like:
>
> - Users can register with invalid email like "aaa" . Also they can
> change their email in account management to "aaa". Just keycloak admin
> console is fine and allows to save just valid email (
>
> - In account management, when I fill firstName, lastName for admin user
> and won't fill email and then click "Save", it displays me error message
> "You didn't specify email", which is correct. But firstName and lastName
> are cleared too. Similar can be reproduced when updating user. Basically
> Account mgmt form is always reading persistent values from DB and
> ignores values previously filled by user before failed validation.
>
> I guess these are not blocker for release and especially the second one
> might be risky to fix now? wdyt?
>
> Marek
>
> On 10.9.2014 15:49, Marek Posolda wrote:
>> Hi Bill,
>>
>> I am on reducing INFO stuff and will commit the fix in few minutes. Will
>> let you know again once it's done.
>>
>> Marek
>>
>> On 10.9.2014 15:37, Bill Burke wrote:
>>> I'll handle the logging stuff if Marek hasn't gotten to it yet.  Thanks
>>> for doing all the issues reported by Marek last night.
>>>
>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
>>> those platforms.
>>>
>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>>> There's no Safari issue after all! So we're good to go.
>>>>
>>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>
>>>>> I'm charging up my macbook.  I'll look into it.
>>>>>
>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
>>>>>> this before
>>>>>> releasing :/
>>>>>>
>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>
>>>>>>> We also need to reduce info level log output from adapters. I did
>>>>>>> this for
>>>>>>> the server for rc-2, but completely forgot about adapters. Marek is
>>>>>>> already
>>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>>
>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>>> <stian at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I am sorry to not help more with the release as I needed to work
>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
>>>>>>>>>> it's gone
>>>>>>>>>> now)...
>>>>>>>>>>
>>>>>>>>>> Found couple of things:
>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
>>>>>>>>>> latest CSRF
>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
>>>>>>>>>> account or
>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
>>>>>>>>>> header to
>>>>>>>>>> the
>>>>>>>>>> update requests (even if they are not ajax requests). So the
>>>>>>>>>> newly
>>>>>>>>>> added
>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
>>>>>>>>>> have
>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>>
>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
>>>>>>>>> Browser
>>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
>>>>>>>> header to
>>>>>>>> make sure it's same origin as well.
>>>>>>>>
>>>>>>>>>> * ServerInfo request
>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
>>>>>>>>>> is adding
>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
>>>>>>>>>> allowOrigins
>>>>>>>>>> from the authenticated bearer token. Admin console is already
>>>>>>>>>> using
>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
>>>>>>>>>> are needed
>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
>>>>>>>>>> authenticated
>>>>>>>>>> (don't know why stuff like available social providers or
>>>>>>>>>> themes should
>>>>>>>>>> be publicly available). Let me know if you seeing issues with
>>>>>>>>>> it. I did
>>>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>>>> 1.0-Final
>>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>>
>>>>>>>>> Merge it.
>>>>>>>>>
>>>>>>>>>> * Realm public resource
>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
>>>>>>>>>> also not available for CORS requests. Not sure if this is an
>>>>>>>>>> issue or
>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
>>>>>>>>>> this
>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
>>>>>>>>>> is to
>>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>>
>>>>>>>>>> * There is still quite a lot of INFO logging . For example
>>>>>>>>>> when I send
>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
>>>>>>>>>> messages
>>>>>>>>>> in
>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>>
>>>>>>>>> Ping me on your status tomorrow (Wednesday).  I'll complete
>>>>>>>>> whatever you
>>>>>>>>> don't finish above.
>>>>>>>>>
>>>>>>>>> Thanks.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>
>> _______________________________________________
>> 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  Wed Sep 10 10:35:15 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 10 Sep 2014 16:35:15 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <541060AC.2070707@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>	<540F7585.9020601@redhat.com>	<540FA4C0.2030409@redhat.com>	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>	<54104C10.9040108@redhat.com>	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>	<54105417.2000009@redhat.com>
	<541056DC.7070308@redhat.com> <54105FEC.4040004@redhat.com>
	<541060AC.2070707@redhat.com>
Message-ID: <541061A3.1080905@redhat.com>

Ok, will just create JIRAs for next version.

Marek

On 10.9.2014 16:31, Bill Burke wrote:
> Yeah, just wait IMO.
>
> On 9/10/2014 10:27 AM, Marek Posolda wrote:
>> I've pushed the fix for reduced INFO logging level.
>>
>> I've found few other things during quick testing like:
>>
>> - Users can register with invalid email like "aaa" . Also they can
>> change their email in account management to "aaa". Just keycloak admin
>> console is fine and allows to save just valid email (
>>
>> - In account management, when I fill firstName, lastName for admin user
>> and won't fill email and then click "Save", it displays me error message
>> "You didn't specify email", which is correct. But firstName and lastName
>> are cleared too. Similar can be reproduced when updating user. Basically
>> Account mgmt form is always reading persistent values from DB and
>> ignores values previously filled by user before failed validation.
>>
>> I guess these are not blocker for release and especially the second one
>> might be risky to fix now? wdyt?
>>
>> Marek
>>
>> On 10.9.2014 15:49, Marek Posolda wrote:
>>> Hi Bill,
>>>
>>> I am on reducing INFO stuff and will commit the fix in few minutes. 
>>> Will
>>> let you know again once it's done.
>>>
>>> Marek
>>>
>>> On 10.9.2014 15:37, Bill Burke wrote:
>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet.  
>>>> Thanks
>>>> for doing all the issues reported by Marek last night.
>>>>
>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
>>>> those platforms.
>>>>
>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>>>> There's no Safari issue after all! So we're good to go.
>>>>>
>>>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>
>>>>>> I'm charging up my macbook.  I'll look into it.
>>>>>>
>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
>>>>>>> this before
>>>>>>> releasing :/
>>>>>>>
>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>
>>>>>>>> We also need to reduce info level log output from adapters. I did
>>>>>>>> this for
>>>>>>>> the server for rc-2, but completely forgot about adapters. 
>>>>>>>> Marek is
>>>>>>>> already
>>>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>>>
>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>>>> <stian at redhat.com>
>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I am sorry to not help more with the release as I needed to 
>>>>>>>>>>> work
>>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
>>>>>>>>>>> it's gone
>>>>>>>>>>> now)...
>>>>>>>>>>>
>>>>>>>>>>> Found couple of things:
>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
>>>>>>>>>>> latest CSRF
>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
>>>>>>>>>>> account or
>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
>>>>>>>>>>> header to
>>>>>>>>>>> the
>>>>>>>>>>> update requests (even if they are not ajax requests). So the
>>>>>>>>>>> newly
>>>>>>>>>>> added
>>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
>>>>>>>>>>> have
>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>>>
>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
>>>>>>>>>> Browser
>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
>>>>>>>>> header to
>>>>>>>>> make sure it's same origin as well.
>>>>>>>>>
>>>>>>>>>>> * ServerInfo request
>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
>>>>>>>>>>> is adding
>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
>>>>>>>>>>> allowOrigins
>>>>>>>>>>> from the authenticated bearer token. Admin console is already
>>>>>>>>>>> using
>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
>>>>>>>>>>> are needed
>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
>>>>>>>>>>> authenticated
>>>>>>>>>>> (don't know why stuff like available social providers or
>>>>>>>>>>> themes should
>>>>>>>>>>> be publicly available). Let me know if you seeing issues with
>>>>>>>>>>> it. I did
>>>>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>>>>> 1.0-Final
>>>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>>>
>>>>>>>>>> Merge it.
>>>>>>>>>>
>>>>>>>>>>> * Realm public resource
>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
>>>>>>>>>>> issue or
>>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
>>>>>>>>>>> this
>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
>>>>>>>>>>> is to
>>>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>>>
>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
>>>>>>>>>>> when I send
>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
>>>>>>>>>>> messages
>>>>>>>>>>> in
>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>>>
>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
>>>>>>>>>> whatever you
>>>>>>>>>> don't finish above.
>>>>>>>>>>
>>>>>>>>>> Thanks.
>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> 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
>>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From bburke at redhat.com  Wed Sep 10 10:35:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 10:35:53 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <541061A3.1080905@redhat.com>
References: <540F3928.7020305@redhat.com>	<1664916110.46418214.1410285683392.JavaMail.zimbra@redhat.com>	<540F7585.9020601@redhat.com>	<540FA4C0.2030409@redhat.com>	<1109672366.46747574.1410338235381.JavaMail.zimbra@redhat.com>	<1470290537.46846099.1410351094764.JavaMail.zimbra@redhat.com>	<1839434184.46868914.1410353352623.JavaMail.zimbra@redhat.com>	<54104C10.9040108@redhat.com>	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>	<54105417.2000009@redhat.com>
	<541056DC.7070308@redhat.com> <54105FEC.4040004@redhat.com>
	<541060AC.2070707@redhat.com> <541061A3.1080905@redhat.com>
Message-ID: <541061C9.8030405@redhat.com>

Yeah, take a break, celebrate!  Wish we could all go out and have a beer.

On 9/10/2014 10:35 AM, Marek Posolda wrote:
> Ok, will just create JIRAs for next version.
>
> Marek
>
> On 10.9.2014 16:31, Bill Burke wrote:
>> Yeah, just wait IMO.
>>
>> On 9/10/2014 10:27 AM, Marek Posolda wrote:
>>> I've pushed the fix for reduced INFO logging level.
>>>
>>> I've found few other things during quick testing like:
>>>
>>> - Users can register with invalid email like "aaa" . Also they can
>>> change their email in account management to "aaa". Just keycloak admin
>>> console is fine and allows to save just valid email (
>>>
>>> - In account management, when I fill firstName, lastName for admin user
>>> and won't fill email and then click "Save", it displays me error message
>>> "You didn't specify email", which is correct. But firstName and lastName
>>> are cleared too. Similar can be reproduced when updating user. Basically
>>> Account mgmt form is always reading persistent values from DB and
>>> ignores values previously filled by user before failed validation.
>>>
>>> I guess these are not blocker for release and especially the second one
>>> might be risky to fix now? wdyt?
>>>
>>> Marek
>>>
>>> On 10.9.2014 15:49, Marek Posolda wrote:
>>>> Hi Bill,
>>>>
>>>> I am on reducing INFO stuff and will commit the fix in few minutes.
>>>> Will
>>>> let you know again once it's done.
>>>>
>>>> Marek
>>>>
>>>> On 10.9.2014 15:37, Bill Burke wrote:
>>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet. Thanks
>>>>> for doing all the issues reported by Marek last night.
>>>>>
>>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
>>>>> those platforms.
>>>>>
>>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>>>>> There's no Safari issue after all! So we're good to go.
>>>>>>
>>>>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>
>>>>>>> I'm charging up my macbook.  I'll look into it.
>>>>>>>
>>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
>>>>>>>> this before
>>>>>>>> releasing :/
>>>>>>>>
>>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>
>>>>>>>>> We also need to reduce info level log output from adapters. I did
>>>>>>>>> this for
>>>>>>>>> the server for rc-2, but completely forgot about adapters.
>>>>>>>>> Marek is
>>>>>>>>> already
>>>>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>>>>
>>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>>>>> <stian at redhat.com>
>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I am sorry to not help more with the release as I needed to
>>>>>>>>>>>> work
>>>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
>>>>>>>>>>>> it's gone
>>>>>>>>>>>> now)...
>>>>>>>>>>>>
>>>>>>>>>>>> Found couple of things:
>>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
>>>>>>>>>>>> latest CSRF
>>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
>>>>>>>>>>>> account or
>>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
>>>>>>>>>>>> header to
>>>>>>>>>>>> the
>>>>>>>>>>>> update requests (even if they are not ajax requests). So the
>>>>>>>>>>>> newly
>>>>>>>>>>>> added
>>>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
>>>>>>>>>>>> have
>>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>>>>
>>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
>>>>>>>>>>> Browser
>>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
>>>>>>>>>> header to
>>>>>>>>>> make sure it's same origin as well.
>>>>>>>>>>
>>>>>>>>>>>> * ServerInfo request
>>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
>>>>>>>>>>>> is adding
>>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
>>>>>>>>>>>> allowOrigins
>>>>>>>>>>>> from the authenticated bearer token. Admin console is already
>>>>>>>>>>>> using
>>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
>>>>>>>>>>>> are needed
>>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
>>>>>>>>>>>> authenticated
>>>>>>>>>>>> (don't know why stuff like available social providers or
>>>>>>>>>>>> themes should
>>>>>>>>>>>> be publicly available). Let me know if you seeing issues with
>>>>>>>>>>>> it. I did
>>>>>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>>>>>> 1.0-Final
>>>>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>>>>
>>>>>>>>>>> Merge it.
>>>>>>>>>>>
>>>>>>>>>>>> * Realm public resource
>>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
>>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
>>>>>>>>>>>> issue or
>>>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
>>>>>>>>>>>> this
>>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
>>>>>>>>>>>> is to
>>>>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>>>>
>>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
>>>>>>>>>>>> when I send
>>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
>>>>>>>>>>>> messages
>>>>>>>>>>>> in
>>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>>>>
>>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
>>>>>>>>>>> whatever you
>>>>>>>>>>> don't finish above.
>>>>>>>>>>>
>>>>>>>>>>> Thanks.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>>>
>>>> _______________________________________________
>>>> 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 Sep 10 10:53:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 10 Sep 2014 10:53:52 -0400 (EDT)
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <541061C9.8030405@redhat.com>
References: <540F3928.7020305@redhat.com>
	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
	<54105417.2000009@redhat.com> <541056DC.7070308@redhat.com>
	<54105FEC.4040004@redhat.com> <541060AC.2070707@redhat.com>
	<541061A3.1080905@redhat.com> <541061C9.8030405@redhat.com>
Message-ID: <1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 10 September, 2014 4:35:53 PM
> Subject: Re: [keycloak-dev] Are we all set?
> 
> Yeah, take a break, celebrate!  Wish we could all go out and have a beer.

Just one beer? ;)

> 
> On 9/10/2014 10:35 AM, Marek Posolda wrote:
> > Ok, will just create JIRAs for next version.
> >
> > Marek
> >
> > On 10.9.2014 16:31, Bill Burke wrote:
> >> Yeah, just wait IMO.
> >>
> >> On 9/10/2014 10:27 AM, Marek Posolda wrote:
> >>> I've pushed the fix for reduced INFO logging level.
> >>>
> >>> I've found few other things during quick testing like:
> >>>
> >>> - Users can register with invalid email like "aaa" . Also they can
> >>> change their email in account management to "aaa". Just keycloak admin
> >>> console is fine and allows to save just valid email (
> >>>
> >>> - In account management, when I fill firstName, lastName for admin user
> >>> and won't fill email and then click "Save", it displays me error message
> >>> "You didn't specify email", which is correct. But firstName and lastName
> >>> are cleared too. Similar can be reproduced when updating user. Basically
> >>> Account mgmt form is always reading persistent values from DB and
> >>> ignores values previously filled by user before failed validation.
> >>>
> >>> I guess these are not blocker for release and especially the second one
> >>> might be risky to fix now? wdyt?
> >>>
> >>> Marek
> >>>
> >>> On 10.9.2014 15:49, Marek Posolda wrote:
> >>>> Hi Bill,
> >>>>
> >>>> I am on reducing INFO stuff and will commit the fix in few minutes.
> >>>> Will
> >>>> let you know again once it's done.
> >>>>
> >>>> Marek
> >>>>
> >>>> On 10.9.2014 15:37, Bill Burke wrote:
> >>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet. Thanks
> >>>>> for doing all the issues reported by Marek last night.
> >>>>>
> >>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
> >>>>> those platforms.
> >>>>>
> >>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
> >>>>>> There's no Safari issue after all! So we're good to go.
> >>>>>>
> >>>>>> ----- 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, 10 September, 2014 3:03:12 PM
> >>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> >>>>>>>
> >>>>>>> I'm charging up my macbook.  I'll look into it.
> >>>>>>>
> >>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
> >>>>>>>> Apparently login with keycloak.js doesn't work on Safari
> >>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
> >>>>>>>> this before
> >>>>>>>> releasing :/
> >>>>>>>>
> >>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
> >>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> >>>>>>>>>
> >>>>>>>>> We also need to reduce info level log output from adapters. I did
> >>>>>>>>> this for
> >>>>>>>>> the server for rc-2, but completely forgot about adapters.
> >>>>>>>>> Marek is
> >>>>>>>>> already
> >>>>>>>>> working on this, and I guess it shouldn't take very long.
> >>>>>>>>>
> >>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
> >>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> >>>>>>>>>>> <stian at redhat.com>
> >>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
> >>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I am sorry to not help more with the release as I needed to
> >>>>>>>>>>>> work
> >>>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
> >>>>>>>>>>>> it's gone
> >>>>>>>>>>>> now)...
> >>>>>>>>>>>>
> >>>>>>>>>>>> Found couple of things:
> >>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
> >>>>>>>>>>>> latest CSRF
> >>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
> >>>>>>>>>>>> account or
> >>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
> >>>>>>>>>>>> header to
> >>>>>>>>>>>> the
> >>>>>>>>>>>> update requests (even if they are not ajax requests). So the
> >>>>>>>>>>>> newly
> >>>>>>>>>>>> added
> >>>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
> >>>>>>>>>>>> have
> >>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
> >>>>>>>>>>>>
> >>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
> >>>>>>>>>>> Browser
> >>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
> >>>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
> >>>>>>>>>> header to
> >>>>>>>>>> make sure it's same origin as well.
> >>>>>>>>>>
> >>>>>>>>>>>> * ServerInfo request
> >>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
> >>>>>>>>>>>> not available with CORS . I've created JIRA
> >>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> >>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
> >>>>>>>>>>>> is adding
> >>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
> >>>>>>>>>>>> allowOrigins
> >>>>>>>>>>>> from the authenticated bearer token. Admin console is already
> >>>>>>>>>>>> using
> >>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
> >>>>>>>>>>>> are needed
> >>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
> >>>>>>>>>>>> authenticated
> >>>>>>>>>>>> (don't know why stuff like available social providers or
> >>>>>>>>>>>> themes should
> >>>>>>>>>>>> be publicly available). Let me know if you seeing issues with
> >>>>>>>>>>>> it. I did
> >>>>>>>>>>>> not merge PR so far as version in master is already changed to
> >>>>>>>>>>>> 1.0-Final
> >>>>>>>>>>>> so not sure what is the state of the release .
> >>>>>>>>>>>>
> >>>>>>>>>>> Merge it.
> >>>>>>>>>>>
> >>>>>>>>>>>> * Realm public resource
> >>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
> >>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
> >>>>>>>>>>>> issue or
> >>>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
> >>>>>>>>>>>> this
> >>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
> >>>>>>>>>>>> is to
> >>>>>>>>>>>> allow it for all allowedOrigins (send same
> >>>>>>>>>>>> "Access-Control-Allow-Origin"
> >>>>>>>>>>>> as original value of "Origin" header from the request)
> >>>>>>>>>>>>
> >>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
> >>>>>>>>>>>> when I send
> >>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
> >>>>>>>>>>>> messages
> >>>>>>>>>>>> in
> >>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
> >>>>>>>>>>>>
> >>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
> >>>>>>>>>>> whatever you
> >>>>>>>>>>> don't finish above.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks.
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> 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
> >>>>>>>
> >>>> _______________________________________________
> >>>> 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  Wed Sep 10 11:05:04 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 10 Sep 2014 17:05:04 +0200
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
	<54105417.2000009@redhat.com> <541056DC.7070308@redhat.com>
	<54105FEC.4040004@redhat.com> <541060AC.2070707@redhat.com>
	<541061A3.1080905@redhat.com> <541061C9.8030405@redhat.com>
	<1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>
Message-ID: <541068A0.8010009@redhat.com>

On 10.9.2014 16:53, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 10 September, 2014 4:35:53 PM
>> Subject: Re: [keycloak-dev] Are we all set?
>>
>> Yeah, take a break, celebrate!  Wish we could all go out and have a beer.
> Just one beer? ;)
I think I will take few more today's evening:-)

>
>> On 9/10/2014 10:35 AM, Marek Posolda wrote:
>>> Ok, will just create JIRAs for next version.
>>>
>>> Marek
>>>
>>> On 10.9.2014 16:31, Bill Burke wrote:
>>>> Yeah, just wait IMO.
>>>>
>>>> On 9/10/2014 10:27 AM, Marek Posolda wrote:
>>>>> I've pushed the fix for reduced INFO logging level.
>>>>>
>>>>> I've found few other things during quick testing like:
>>>>>
>>>>> - Users can register with invalid email like "aaa" . Also they can
>>>>> change their email in account management to "aaa". Just keycloak admin
>>>>> console is fine and allows to save just valid email (
>>>>>
>>>>> - In account management, when I fill firstName, lastName for admin user
>>>>> and won't fill email and then click "Save", it displays me error message
>>>>> "You didn't specify email", which is correct. But firstName and lastName
>>>>> are cleared too. Similar can be reproduced when updating user. Basically
>>>>> Account mgmt form is always reading persistent values from DB and
>>>>> ignores values previously filled by user before failed validation.
>>>>>
>>>>> I guess these are not blocker for release and especially the second one
>>>>> might be risky to fix now? wdyt?
>>>>>
>>>>> Marek
>>>>>
>>>>> On 10.9.2014 15:49, Marek Posolda wrote:
>>>>>> Hi Bill,
>>>>>>
>>>>>> I am on reducing INFO stuff and will commit the fix in few minutes.
>>>>>> Will
>>>>>> let you know again once it's done.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 10.9.2014 15:37, Bill Burke wrote:
>>>>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet. Thanks
>>>>>>> for doing all the issues reported by Marek last night.
>>>>>>>
>>>>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
>>>>>>> those platforms.
>>>>>>>
>>>>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>>>>>>> There's no Safari issue after all! So we're good to go.
>>>>>>>>
>>>>>>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>
>>>>>>>>> I'm charging up my macbook.  I'll look into it.
>>>>>>>>>
>>>>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>>>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
>>>>>>>>>> this before
>>>>>>>>>> releasing :/
>>>>>>>>>>
>>>>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>
>>>>>>>>>>> We also need to reduce info level log output from adapters. I did
>>>>>>>>>>> this for
>>>>>>>>>>> the server for rc-2, but completely forgot about adapters.
>>>>>>>>>>> Marek is
>>>>>>>>>>> already
>>>>>>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>>>>>>
>>>>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>>>>>>> <stian at redhat.com>
>>>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am sorry to not help more with the release as I needed to
>>>>>>>>>>>>>> work
>>>>>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
>>>>>>>>>>>>>> it's gone
>>>>>>>>>>>>>> now)...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Found couple of things:
>>>>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
>>>>>>>>>>>>>> latest CSRF
>>>>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
>>>>>>>>>>>>>> account or
>>>>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
>>>>>>>>>>>>>> header to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> update requests (even if they are not ajax requests). So the
>>>>>>>>>>>>>> newly
>>>>>>>>>>>>>> added
>>>>>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
>>>>>>>>>>>>> Browser
>>>>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
>>>>>>>>>>>> header to
>>>>>>>>>>>> make sure it's same origin as well.
>>>>>>>>>>>>
>>>>>>>>>>>>>> * ServerInfo request
>>>>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
>>>>>>>>>>>>>> is adding
>>>>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
>>>>>>>>>>>>>> allowOrigins
>>>>>>>>>>>>>> from the authenticated bearer token. Admin console is already
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
>>>>>>>>>>>>>> are needed
>>>>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
>>>>>>>>>>>>>> authenticated
>>>>>>>>>>>>>> (don't know why stuff like available social providers or
>>>>>>>>>>>>>> themes should
>>>>>>>>>>>>>> be publicly available). Let me know if you seeing issues with
>>>>>>>>>>>>>> it. I did
>>>>>>>>>>>>>> not merge PR so far as version in master is already changed to
>>>>>>>>>>>>>> 1.0-Final
>>>>>>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Merge it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Realm public resource
>>>>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
>>>>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
>>>>>>>>>>>>>> issue or
>>>>>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
>>>>>>>>>>>>>> is to
>>>>>>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
>>>>>>>>>>>>>> when I send
>>>>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
>>>>>>>>>>>>>> messages
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
>>>>>>>>>>>>> whatever you
>>>>>>>>>>>>> don't finish above.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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 Sep 10 11:18:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 11:18:22 -0400
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <541068A0.8010009@redhat.com>
References: <540F3928.7020305@redhat.com>
	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
	<54105417.2000009@redhat.com> <541056DC.7070308@redhat.com>
	<54105FEC.4040004@redhat.com> <541060AC.2070707@redhat.com>
	<541061A3.1080905@redhat.com> <541061C9.8030405@redhat.com>
	<1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>
	<541068A0.8010009@redhat.com>
Message-ID: <54106BBE.7040405@redhat.com>

Lol!

Hey, I'm going to release today.  I just ran all the demos on EAP 6.3 
with IE.  Looks good, just one minor formatting issue on role mapping 
page for IE.  Deferred to 1.1.  I'll try out appliance on Chrome now. 
Then I'll release after our meeting with Divya.

On 9/10/2014 11:05 AM, Marek Posolda wrote:
> On 10.9.2014 16:53, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>> <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 10 September, 2014 4:35:53 PM
>>> Subject: Re: [keycloak-dev] Are we all set?
>>>
>>> Yeah, take a break, celebrate!  Wish we could all go out and have a
>>> beer.
>> Just one beer? ;)
> I think I will take few more today's evening:-)
>
>>
>>> On 9/10/2014 10:35 AM, Marek Posolda wrote:
>>>> Ok, will just create JIRAs for next version.
>>>>
>>>> Marek
>>>>
>>>> On 10.9.2014 16:31, Bill Burke wrote:
>>>>> Yeah, just wait IMO.
>>>>>
>>>>> On 9/10/2014 10:27 AM, Marek Posolda wrote:
>>>>>> I've pushed the fix for reduced INFO logging level.
>>>>>>
>>>>>> I've found few other things during quick testing like:
>>>>>>
>>>>>> - Users can register with invalid email like "aaa" . Also they can
>>>>>> change their email in account management to "aaa". Just keycloak
>>>>>> admin
>>>>>> console is fine and allows to save just valid email (
>>>>>>
>>>>>> - In account management, when I fill firstName, lastName for admin
>>>>>> user
>>>>>> and won't fill email and then click "Save", it displays me error
>>>>>> message
>>>>>> "You didn't specify email", which is correct. But firstName and
>>>>>> lastName
>>>>>> are cleared too. Similar can be reproduced when updating user.
>>>>>> Basically
>>>>>> Account mgmt form is always reading persistent values from DB and
>>>>>> ignores values previously filled by user before failed validation.
>>>>>>
>>>>>> I guess these are not blocker for release and especially the
>>>>>> second one
>>>>>> might be risky to fix now? wdyt?
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 10.9.2014 15:49, Marek Posolda wrote:
>>>>>>> Hi Bill,
>>>>>>>
>>>>>>> I am on reducing INFO stuff and will commit the fix in few minutes.
>>>>>>> Will
>>>>>>> let you know again once it's done.
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On 10.9.2014 15:37, Bill Burke wrote:
>>>>>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet.
>>>>>>>> Thanks
>>>>>>>> for doing all the issues reported by Marek last night.
>>>>>>>>
>>>>>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're
>>>>>>>> good on
>>>>>>>> those platforms.
>>>>>>>>
>>>>>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
>>>>>>>>> There's no Safari issue after all! So we're good to go.
>>>>>>>>>
>>>>>>>>> ----- 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, 10 September, 2014 3:03:12 PM
>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>
>>>>>>>>>> I'm charging up my macbook.  I'll look into it.
>>>>>>>>>>
>>>>>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
>>>>>>>>>>> Apparently login with keycloak.js doesn't work on Safari
>>>>>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
>>>>>>>>>>> this before
>>>>>>>>>>> releasing :/
>>>>>>>>>>>
>>>>>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
>>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>>
>>>>>>>>>>>> We also need to reduce info level log output from adapters.
>>>>>>>>>>>> I did
>>>>>>>>>>>> this for
>>>>>>>>>>>> the server for rc-2, but completely forgot about adapters.
>>>>>>>>>>>> Marek is
>>>>>>>>>>>> already
>>>>>>>>>>>> working on this, and I guess it shouldn't take very long.
>>>>>>>>>>>>
>>>>>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
>>>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
>>>>>>>>>>>>>> <stian at redhat.com>
>>>>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
>>>>>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am sorry to not help more with the release as I needed to
>>>>>>>>>>>>>>> work
>>>>>>>>>>>>>>> especially on some portal related stuff last weeks
>>>>>>>>>>>>>>> (hopefully
>>>>>>>>>>>>>>> it's gone
>>>>>>>>>>>>>>> now)...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Found couple of things:
>>>>>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
>>>>>>>>>>>>>>> latest CSRF
>>>>>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
>>>>>>>>>>>>>>> account or
>>>>>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
>>>>>>>>>>>>>>> header to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> update requests (even if they are not ajax requests). So the
>>>>>>>>>>>>>>> newly
>>>>>>>>>>>>>>> added
>>>>>>>>>>>>>>> condition for CSRF in AccountService.init will always
>>>>>>>>>>>>>>> fail. I
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
>>>>>>>>>>>>>> Browser
>>>>>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
>>>>>>>>>>>>> Added fix to allow same origin. I also added check of
>>>>>>>>>>>>> 'Referer'
>>>>>>>>>>>>> header to
>>>>>>>>>>>>> make sure it's same origin as well.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * ServerInfo request
>>>>>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
>>>>>>>>>>>>>>> not available with CORS . I've created JIRA
>>>>>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
>>>>>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this,
>>>>>>>>>>>>>>> which
>>>>>>>>>>>>>>> is adding
>>>>>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
>>>>>>>>>>>>>>> allowOrigins
>>>>>>>>>>>>>>> from the authenticated bearer token. Admin console is
>>>>>>>>>>>>>>> already
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
>>>>>>>>>>>>>>> are needed
>>>>>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
>>>>>>>>>>>>>>> authenticated
>>>>>>>>>>>>>>> (don't know why stuff like available social providers or
>>>>>>>>>>>>>>> themes should
>>>>>>>>>>>>>>> be publicly available). Let me know if you seeing issues
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> it. I did
>>>>>>>>>>>>>>> not merge PR so far as version in master is already
>>>>>>>>>>>>>>> changed to
>>>>>>>>>>>>>>> 1.0-Final
>>>>>>>>>>>>>>> so not sure what is the state of the release .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Merge it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * Realm public resource
>>>>>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
>>>>>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
>>>>>>>>>>>>>>> issue or
>>>>>>>>>>>>>>> not? Thing is that unauthenticated requests can't use
>>>>>>>>>>>>>>> CORS at
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only
>>>>>>>>>>>>>>> option
>>>>>>>>>>>>>>> is to
>>>>>>>>>>>>>>> allow it for all allowedOrigins (send same
>>>>>>>>>>>>>>> "Access-Control-Allow-Origin"
>>>>>>>>>>>>>>> as original value of "Origin" header from the request)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
>>>>>>>>>>>>>>> when I send
>>>>>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
>>>>>>>>>>>>>>> messages
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
>>>>>>>>>>>>>> whatever you
>>>>>>>>>>>>>> don't finish above.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>
>

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

From bruno at abstractj.org  Wed Sep 10 13:22:43 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 10 Sep 2014 14:22:43 -0300
Subject: [keycloak-dev] Are we all set?
In-Reply-To: <1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>
References: <540F3928.7020305@redhat.com>
	<5786909.46903622.1410355738377.JavaMail.zimbra@redhat.com>
	<54105417.2000009@redhat.com> <541056DC.7070308@redhat.com>
	<54105FEC.4040004@redhat.com> <541060AC.2070707@redhat.com>
	<541061A3.1080905@redhat.com> <541061C9.8030405@redhat.com>
	<1865875201.46985760.1410360832234.JavaMail.zimbra@redhat.com>
Message-ID: <20140910172243.GA4780@abstractj.org>

You guys totally deserve it. Thanks for the fuckin' amazing work.

On 2014-09-10, Stian Thorgersen wrote:
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 10 September, 2014 4:35:53 PM
> > Subject: Re: [keycloak-dev] Are we all set?
> >
> > Yeah, take a break, celebrate!  Wish we could all go out and have a beer.
>
> Just one beer? ;)
>
> >
> > On 9/10/2014 10:35 AM, Marek Posolda wrote:
> > > Ok, will just create JIRAs for next version.
> > >
> > > Marek
> > >
> > > On 10.9.2014 16:31, Bill Burke wrote:
> > >> Yeah, just wait IMO.
> > >>
> > >> On 9/10/2014 10:27 AM, Marek Posolda wrote:
> > >>> I've pushed the fix for reduced INFO logging level.
> > >>>
> > >>> I've found few other things during quick testing like:
> > >>>
> > >>> - Users can register with invalid email like "aaa" . Also they can
> > >>> change their email in account management to "aaa". Just keycloak admin
> > >>> console is fine and allows to save just valid email (
> > >>>
> > >>> - In account management, when I fill firstName, lastName for admin user
> > >>> and won't fill email and then click "Save", it displays me error message
> > >>> "You didn't specify email", which is correct. But firstName and lastName
> > >>> are cleared too. Similar can be reproduced when updating user. Basically
> > >>> Account mgmt form is always reading persistent values from DB and
> > >>> ignores values previously filled by user before failed validation.
> > >>>
> > >>> I guess these are not blocker for release and especially the second one
> > >>> might be risky to fix now? wdyt?
> > >>>
> > >>> Marek
> > >>>
> > >>> On 10.9.2014 15:49, Marek Posolda wrote:
> > >>>> Hi Bill,
> > >>>>
> > >>>> I am on reducing INFO stuff and will commit the fix in few minutes.
> > >>>> Will
> > >>>> let you know again once it's done.
> > >>>>
> > >>>> Marek
> > >>>>
> > >>>> On 10.9.2014 15:37, Bill Burke wrote:
> > >>>>> I'll handle the logging stuff if Marek hasn't gotten to it yet. Thanks
> > >>>>> for doing all the issues reported by Marek last night.
> > >>>>>
> > >>>>> i'll run my last tests using IE and EAP 6.3 to make sure we're good on
> > >>>>> those platforms.
> > >>>>>
> > >>>>> On 9/10/2014 9:28 AM, Stian Thorgersen wrote:
> > >>>>>> There's no Safari issue after all! So we're good to go.
> > >>>>>>
> > >>>>>> ----- 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, 10 September, 2014 3:03:12 PM
> > >>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> > >>>>>>>
> > >>>>>>> I'm charging up my macbook.  I'll look into it.
> > >>>>>>>
> > >>>>>>> On 9/10/2014 8:49 AM, Stian Thorgersen wrote:
> > >>>>>>>> Apparently login with keycloak.js doesn't work on Safari
> > >>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-675). We need to fix
> > >>>>>>>> this before
> > >>>>>>>> releasing :/
> > >>>>>>>>
> > >>>>>>>> ----- 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, 10 September, 2014 2:11:34 PM
> > >>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> > >>>>>>>>>
> > >>>>>>>>> We also need to reduce info level log output from adapters. I did
> > >>>>>>>>> this for
> > >>>>>>>>> the server for rc-2, but completely forgot about adapters.
> > >>>>>>>>> Marek is
> > >>>>>>>>> already
> > >>>>>>>>> working on this, and I guess it shouldn't take very long.
> > >>>>>>>>>
> > >>>>>>>>> ----- 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, 10 September, 2014 10:37:15 AM
> > >>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> ----- Original Message -----
> > >>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen"
> > >>>>>>>>>>> <stian at redhat.com>
> > >>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> > >>>>>>>>>>> Sent: Wednesday, 10 September, 2014 3:09:20 AM
> > >>>>>>>>>>> Subject: Re: [keycloak-dev] Are we all set?
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 9/9/2014 5:47 PM, Marek Posolda wrote:
> > >>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I am sorry to not help more with the release as I needed to
> > >>>>>>>>>>>> work
> > >>>>>>>>>>>> especially on some portal related stuff last weeks (hopefully
> > >>>>>>>>>>>> it's gone
> > >>>>>>>>>>>> now)...
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Found couple of things:
> > >>>>>>>>>>>> * AccountService is actually broken for me in Chrome due to
> > >>>>>>>>>>>> latest CSRF
> > >>>>>>>>>>>> stuff. In FF it works fine, but in Chrome I can't update
> > >>>>>>>>>>>> account or
> > >>>>>>>>>>>> password. For some reason Chrome is always adding "Origin"
> > >>>>>>>>>>>> header to
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>> update requests (even if they are not ajax requests). So the
> > >>>>>>>>>>>> newly
> > >>>>>>>>>>>> added
> > >>>>>>>>>>>> condition for CSRF in AccountService.init will always fail. I
> > >>>>>>>>>>>> have
> > >>>>>>>>>>>> Chrome 37.0.2062.94 (64-bit) .
> > >>>>>>>>>>>>
> > >>>>>>>>>>> Ok, I thought Origin header wasn't supposed to be sent with
> > >>>>>>>>>>> Browser
> > >>>>>>>>>>> requests.  I can probably fix this by allowing same origin.
> > >>>>>>>>>> Added fix to allow same origin. I also added check of 'Referer'
> > >>>>>>>>>> header to
> > >>>>>>>>>> make sure it's same origin as well.
> > >>>>>>>>>>
> > >>>>>>>>>>>> * ServerInfo request
> > >>>>>>>>>>>> (http://localhost:8080/auth/admin/serverinfo) is
> > >>>>>>>>>>>> not available with CORS . I've created JIRA
> > >>>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-670 and send PR
> > >>>>>>>>>>>> https://github.com/keycloak/keycloak/pull/683 for this, which
> > >>>>>>>>>>>> is adding
> > >>>>>>>>>>>> authentication for ServerInfoAdminResource and then it use
> > >>>>>>>>>>>> allowOrigins
> > >>>>>>>>>>>> from the authenticated bearer token. Admin console is already
> > >>>>>>>>>>>> using
> > >>>>>>>>>>>> bearer token for sending ServerInfo requests, so no changes
> > >>>>>>>>>>>> are needed
> > >>>>>>>>>>>> here. I believe that ServerInfoAdminResource should be
> > >>>>>>>>>>>> authenticated
> > >>>>>>>>>>>> (don't know why stuff like available social providers or
> > >>>>>>>>>>>> themes should
> > >>>>>>>>>>>> be publicly available). Let me know if you seeing issues with
> > >>>>>>>>>>>> it. I did
> > >>>>>>>>>>>> not merge PR so far as version in master is already changed to
> > >>>>>>>>>>>> 1.0-Final
> > >>>>>>>>>>>> so not sure what is the state of the release .
> > >>>>>>>>>>>>
> > >>>>>>>>>>> Merge it.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> * Realm public resource
> > >>>>>>>>>>>> (http://localhost:8080/auth/realms/master) is
> > >>>>>>>>>>>> also not available for CORS requests. Not sure if this is an
> > >>>>>>>>>>>> issue or
> > >>>>>>>>>>>> not? Thing is that unauthenticated requests can't use CORS at
> > >>>>>>>>>>>> this
> > >>>>>>>>>>>> moment as I don't know what allowedOrigins to use. Only option
> > >>>>>>>>>>>> is to
> > >>>>>>>>>>>> allow it for all allowedOrigins (send same
> > >>>>>>>>>>>> "Access-Control-Allow-Origin"
> > >>>>>>>>>>>> as original value of "Origin" header from the request)
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> * There is still quite a lot of INFO logging . For example
> > >>>>>>>>>>>> when I send
> > >>>>>>>>>>>> product request from the cors-demo example I have 6 new INFO
> > >>>>>>>>>>>> messages
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>> log (Mainly from org.keycloak.adapters package)
> > >>>>>>>>>>>>
> > >>>>>>>>>>> Ping me on your status tomorrow (Wednesday). I'll complete
> > >>>>>>>>>>> whatever you
> > >>>>>>>>>>> don't finish above.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks.
> > >>>>>>>>>>>
> > >>>>>>>>>>> --
> > >>>>>>>>>>> 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
> > >>>>>>>
> > >>>> _______________________________________________
> > >>>> 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

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Wed Sep 10 16:19:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Sep 2014 16:19:25 -0400
Subject: [keycloak-dev] Keycloak 1.0 Final Released
Message-ID: <5410B24D.8010902@redhat.com>

Here's the details:

http://blog.keycloak.org/2014/09/10/keycloak-1-0-final-released/

Thank you Stian and Marek.  You guys have been amazing to work with.

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

From psilva at redhat.com  Wed Sep 10 16:59:18 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 10 Sep 2014 16:59:18 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0 Final Released
In-Reply-To: <5410B24D.8010902@redhat.com>
References: <5410B24D.8010902@redhat.com>
Message-ID: <1792945163.20410841.1410382758369.JavaMail.zimbra@redhat.com>

Congrats to the team !

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org, keycloak-user at lists.jboss.org
Sent: Wednesday, September 10, 2014 5:19:25 PM
Subject: [keycloak-dev] Keycloak 1.0 Final Released

Here's the details:

http://blog.keycloak.org/2014/09/10/keycloak-1-0-final-released/

Thank you Stian and Marek.  You guys have been amazing to work with.

-- 
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  Wed Sep 10 21:34:06 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 10 Sep 2014 18:34:06 -0700 (PDT)
Subject: [keycloak-dev] Keycloak 1.0 Final Released
In-Reply-To: <5410B24D.8010902@redhat.com>
References: <5410B24D.8010902@redhat.com>
Message-ID: <1410399245747.42f5834a@Nodemailer>

Congratulations!?
abstractj 
PGP: 0x84DC9914

On Wed, Sep 10, 2014 at 5:19 PM, Bill Burke <bburke at redhat.com> wrote:

> Here's the details:
> http://blog.keycloak.org/2014/09/10/keycloak-1-0-final-released/
> Thank you Stian and Marek.  You guys have been amazing to work with.
> -- 
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140910/7c54c694/attachment.html 

From stian at redhat.com  Thu Sep 11 04:01:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 11 Sep 2014 04:01:21 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OpenShift Cartridge 1.0.final Released
Message-ID: <920894234.47463103.1410422481400.JavaMail.zimbra@redhat.com>

The Keycloak OpenShift Cartridge has been updated to 1.0.final

From stian at redhat.com  Thu Sep 11 05:14:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 11 Sep 2014 05:14:21 -0400 (EDT)
Subject: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
In-Reply-To: <730626250.47492665.1410426735912.JavaMail.zimbra@redhat.com>
Message-ID: <1054560919.47493386.1410426861203.JavaMail.zimbra@redhat.com>

KeycloakServer now checks KEYCLOAK_DEV_PORT environment variable. If it's set that'll be used as the port to start the server on. As I prefer to have KeycloakServer running on 8080 I've set this env variable in my profile.

Note: this doesn't affect running the testsuite (still runs on port 8081) or when Keycloak is deployed to WildFly/EAP

From bburke at redhat.com  Thu Sep 11 09:15:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Sep 2014 09:15:16 -0400
Subject: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
In-Reply-To: <1054560919.47493386.1410426861203.JavaMail.zimbra@redhat.com>
References: <1054560919.47493386.1410426861203.JavaMail.zimbra@redhat.com>
Message-ID: <5411A064.80300@redhat.com>

Is this for builds only?

On 9/11/2014 5:14 AM, Stian Thorgersen wrote:
> KeycloakServer now checks KEYCLOAK_DEV_PORT environment variable. If it's set that'll be used as the port to start the server on. As I prefer to have KeycloakServer running on 8080 I've set this env variable in my profile.
>
> Note: this doesn't affect running the testsuite (still runs on port 8081) or when Keycloak is deployed to WildFly/EAP
> _______________________________________________
> 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 Sep 11 09:27:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 11 Sep 2014 09:27:17 -0400 (EDT)
Subject: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
In-Reply-To: <5411A064.80300@redhat.com>
References: <1054560919.47493386.1410426861203.JavaMail.zimbra@redhat.com>
	<5411A064.80300@redhat.com>
Message-ID: <1368170438.47652484.1410442037360.JavaMail.zimbra@redhat.com>

Not sure what you mean by builds only. It's only for KeycloakServer in testsuite/integration.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 11 September, 2014 3:15:16 PM
> Subject: Re: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
> 
> Is this for builds only?
> 
> On 9/11/2014 5:14 AM, Stian Thorgersen wrote:
> > KeycloakServer now checks KEYCLOAK_DEV_PORT environment variable. If it's
> > set that'll be used as the port to start the server on. As I prefer to
> > have KeycloakServer running on 8080 I've set this env variable in my
> > profile.
> >
> > Note: this doesn't affect running the testsuite (still runs on port 8081)
> > or when Keycloak is deployed to WildFly/EAP
> > _______________________________________________
> > 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  Thu Sep 11 09:36:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Sep 2014 09:36:50 -0400
Subject: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
In-Reply-To: <1368170438.47652484.1410442037360.JavaMail.zimbra@redhat.com>
References: <1054560919.47493386.1410426861203.JavaMail.zimbra@redhat.com>
	<5411A064.80300@redhat.com>
	<1368170438.47652484.1410442037360.JavaMail.zimbra@redhat.com>
Message-ID: <5411A572.9070606@redhat.com>

That answered my question.

On 9/11/2014 9:27 AM, Stian Thorgersen wrote:
> Not sure what you mean by builds only. It's only for KeycloakServer in testsuite/integration.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 11 September, 2014 3:15:16 PM
>> Subject: Re: [keycloak-dev] Added KEYCLOAK_DEV_PORT env for KeycloakSever
>>
>> Is this for builds only?
>>
>> On 9/11/2014 5:14 AM, Stian Thorgersen wrote:
>>> KeycloakServer now checks KEYCLOAK_DEV_PORT environment variable. If it's
>>> set that'll be used as the port to start the server on. As I prefer to
>>> have KeycloakServer running on 8080 I've set this env variable in my
>>> profile.
>>>
>>> Note: this doesn't affect running the testsuite (still runs on port 8081)
>>> or when Keycloak is deployed to WildFly/EAP
>>> _______________________________________________
>>> 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 ssilvert at redhat.com  Thu Sep 11 13:45:58 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 11 Sep 2014 13:45:58 -0400
Subject: [keycloak-dev] FYI: Installing Auth Server as part of the subsystem.
In-Reply-To: <5410C172.3000406@redhat.com>
References: <5410C172.3000406@redhat.com>
Message-ID: <5411DFD6.6070905@redhat.com>

Thanks to Brian Stansberry, I now see that it's quite doable to have the 
Keycloak Auth Server installed as part of our subsystem (see below).

Our current approach of copying the WAR into the /deployments directory 
will not work in an EAP cluster.  In a cluster, there is no /deployments 
directory.  Instead, you upload your content and tell the domain 
controller which nodes to run it on.  It makes sense to go ahead and 
install as part of the subsystem rather than forcing an administrator to 
upload the bits to his system.

So I'm going to go ahead and implement this if there are no objections.

Stan

-------- Original Message --------
Subject: 	Re: [wildfly-dev] Creating a Keycloak Feature Pack
Date: 	Wed, 10 Sep 2014 16:24:02 -0500
From: 	Brian Stansberry <brian.stansberry at redhat.com>
To: 	wildfly-dev at lists.jboss.org



On 9/10/14, 1:47 PM, Stan Silvert wrote:

>
> *Issue #3: Adding a deployment:*  The Keycloak auth server is deployed
> as a WAR.  We can use the copy-artifacts mechanism to simply copy the
> WAR into the deployments directory.  But that doesn't work for a domain
> where you want to have the WAR pre-loaded into the content repository.
> Furthermore, it's probably not the best way to integrate this for
> standalone either.
>
> What would be a better option?
>

See the "A Mixed Approach" section at
https://developer.jboss.org/docs/DOC-25627

The two comments at the bottom of that page are also relevant to that
part of the wiki.

Cheers,

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140911/1e66681e/attachment.html 

From bburke at redhat.com  Thu Sep 11 14:17:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Sep 2014 14:17:24 -0400
Subject: [keycloak-dev] FYI: Installing Auth Server as part of the
	subsystem.
In-Reply-To: <5411DFD6.6070905@redhat.com>
References: <5410C172.3000406@redhat.com> <5411DFD6.6070905@redhat.com>
Message-ID: <5411E734.1060405@redhat.com>

Can this be done or EAP too?

On 9/11/2014 1:45 PM, Stan Silvert wrote:
> Thanks to Brian Stansberry, I now see that it's quite doable to have the
> Keycloak Auth Server installed as part of our subsystem (see below).
>
> Our current approach of copying the WAR into the /deployments directory
> will not work in an EAP cluster.  In a cluster, there is no /deployments
> directory.  Instead, you upload your content and tell the domain
> controller which nodes to run it on.  It makes sense to go ahead and
> install as part of the subsystem rather than forcing an administrator to
> upload the bits to his system.
>
> So I'm going to go ahead and implement this if there are no objections.
>
> Stan
>
> -------- Original Message --------
> Subject: 	Re: [wildfly-dev] Creating a Keycloak Feature Pack
> Date: 	Wed, 10 Sep 2014 16:24:02 -0500
> From: 	Brian Stansberry <brian.stansberry at redhat.com>
> To: 	wildfly-dev at lists.jboss.org
>
>
>
> On 9/10/14, 1:47 PM, Stan Silvert wrote:
>
>>
>> *Issue #3: Adding a deployment:*  The Keycloak auth server is deployed
>> as a WAR.  We can use the copy-artifacts mechanism to simply copy the
>> WAR into the deployments directory.  But that doesn't work for a domain
>> where you want to have the WAR pre-loaded into the content repository.
>> Furthermore, it's probably not the best way to integrate this for
>> standalone either.
>>
>> What would be a better option?
>>
>
> See the "A Mixed Approach" section at
> https://developer.jboss.org/docs/DOC-25627
>
> The two comments at the bottom of that page are also relevant to that
> part of the wiki.
>
> Cheers,
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-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 Sep 11 14:33:17 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 11 Sep 2014 14:33:17 -0400
Subject: [keycloak-dev] FYI: Installing Auth Server as part of the
	subsystem.
In-Reply-To: <5411E734.1060405@redhat.com>
References: <5410C172.3000406@redhat.com> <5411DFD6.6070905@redhat.com>
	<5411E734.1060405@redhat.com>
Message-ID: <5411EAED.5080703@redhat.com>

On 9/11/2014 2:17 PM, Bill Burke wrote:
> Can this be done or EAP too?
Yep.  Should work on EAP 6.
>
> On 9/11/2014 1:45 PM, Stan Silvert wrote:
>> Thanks to Brian Stansberry, I now see that it's quite doable to have the
>> Keycloak Auth Server installed as part of our subsystem (see below).
>>
>> Our current approach of copying the WAR into the /deployments directory
>> will not work in an EAP cluster.  In a cluster, there is no /deployments
>> directory.  Instead, you upload your content and tell the domain
>> controller which nodes to run it on.  It makes sense to go ahead and
>> install as part of the subsystem rather than forcing an administrator to
>> upload the bits to his system.
>>
>> So I'm going to go ahead and implement this if there are no objections.
>>
>> Stan
>>
>> -------- Original Message --------
>> Subject: 	Re: [wildfly-dev] Creating a Keycloak Feature Pack
>> Date: 	Wed, 10 Sep 2014 16:24:02 -0500
>> From: 	Brian Stansberry <brian.stansberry at redhat.com>
>> To: 	wildfly-dev at lists.jboss.org
>>
>>
>>
>> On 9/10/14, 1:47 PM, Stan Silvert wrote:
>>
>>> *Issue #3: Adding a deployment:*  The Keycloak auth server is deployed
>>> as a WAR.  We can use the copy-artifacts mechanism to simply copy the
>>> WAR into the deployments directory.  But that doesn't work for a domain
>>> where you want to have the WAR pre-loaded into the content repository.
>>> Furthermore, it's probably not the best way to integrate this for
>>> standalone either.
>>>
>>> What would be a better option?
>>>
>> See the "A Mixed Approach" section at
>> https://developer.jboss.org/docs/DOC-25627
>>
>> The two comments at the bottom of that page are also relevant to that
>> part of the wiki.
>>
>> Cheers,
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-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 Sep 11 15:01:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Sep 2014 15:01:30 -0400
Subject: [keycloak-dev] Branch_1_0
Message-ID: <5411F18A.6010407@redhat.com>

I had created a Branch_1_0 with the 1.0 final release.  We need to 
decide whether or not we're going to branch and do point releases of 
1.0.x from that branch.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Fri Sep 12 04:18:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 12 Sep 2014 04:18:19 -0400 (EDT)
Subject: [keycloak-dev] Branch_1_0
In-Reply-To: <5411F18A.6010407@redhat.com>
References: <5411F18A.6010407@redhat.com>
Message-ID: <1860005532.48440385.1410509899434.JavaMail.zimbra@redhat.com>

Do we need to do point releases for the community version? I'd say as long as we don't change api's and db schema we should make users upgrade to the next release.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 11 September, 2014 9:01:30 PM
> Subject: [keycloak-dev] Branch_1_0
> 
> I had created a Branch_1_0 with the 1.0 final release.  We need to
> decide whether or not we're going to branch and do point releases of
> 1.0.x from that branch.
> --
> 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 Sep 12 05:25:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 12 Sep 2014 05:25:31 -0400 (EDT)
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <708731535.48478513.1410513868600.JavaMail.zimbra@redhat.com>
Message-ID: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>

I propose we remove the "Admin URL" field for bearer-only applications. As a bearer-only application doesn't manage any user sessions there's not much point in propagating logouts to those.

From stian at redhat.com  Fri Sep 12 05:53:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 12 Sep 2014 05:53:58 -0400 (EDT)
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
References: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
Message-ID: <1848102428.48492438.1410515638303.JavaMail.zimbra@redhat.com>

Ignore that - admin-url is also used to propagate notBefore

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 12 September, 2014 11:25:31 AM
> Subject: [keycloak-dev] Remove admin-url for bearer-only applications
> 
> I propose we remove the "Admin URL" field for bearer-only applications. As a
> bearer-only application doesn't manage any user sessions there's not much
> point in propagating logouts to those.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Sep 12 06:29:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 12 Sep 2014 06:29:33 -0400 (EDT)
Subject: [keycloak-dev] Only send logout action to applications associated
 with user session
In-Reply-To: <1627057066.48489131.1410515288178.JavaMail.zimbra@redhat.com>
Message-ID: <972526445.48508278.1410517773164.JavaMail.zimbra@redhat.com>

When logging out a specific user session I've updated the ResourceAdminManager to only logout applications that are associated with the specific user session.

If a realm has 100 applications and a user has only logged-in to one application this makes it 100x faster to logout ;)

From bburke at redhat.com  Fri Sep 12 08:48:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Sep 2014 08:48:59 -0400
Subject: [keycloak-dev] Branch_1_0
In-Reply-To: <1860005532.48440385.1410509899434.JavaMail.zimbra@redhat.com>
References: <5411F18A.6010407@redhat.com>
	<1860005532.48440385.1410509899434.JavaMail.zimbra@redhat.com>
Message-ID: <5412EBBB.7090809@redhat.com>

Master might not be in a state for a release and we may end up with 
emergency blocker bugs especially with all the refactoring that is going 
to be needed to support SAML, internationalization, etc.

On 9/12/2014 4:18 AM, Stian Thorgersen wrote:
> Do we need to do point releases for the community version? I'd say as long as we don't change api's and db schema we should make users upgrade to the next release.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 11 September, 2014 9:01:30 PM
>> Subject: [keycloak-dev] Branch_1_0
>>
>> I had created a Branch_1_0 with the 1.0 final release.  We need to
>> decide whether or not we're going to branch and do point releases of
>> 1.0.x from that branch.
>> --
>> 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  Fri Sep 12 08:51:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Sep 2014 08:51:44 -0400
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
References: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
Message-ID: <5412EC60.2070402@redhat.com>

Negative.  Bearer-only applications can receive revocation policies. 
i.e. "don't accept tokens before this date".  In the future we may want 
to push things like allowed CORS origins, IP blacklists, user 
blacklists, etc.  There's also stats we may want to gather from the 
applications.

On 9/12/2014 5:25 AM, Stian Thorgersen wrote:
> I propose we remove the "Admin URL" field for bearer-only applications. As a bearer-only application doesn't manage any user sessions there's not much point in propagating logouts to those.
> _______________________________________________
> 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 Sep 12 11:43:18 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Sep 2014 17:43:18 +0200
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <5412EC60.2070402@redhat.com>
References: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
	<5412EC60.2070402@redhat.com>
Message-ID: <54131496.3050907@redhat.com>

Possible related question is, if bearer-only applications need scopes 
and claims? Should we hide "Scopes" and "Claims" tabs in admin console 
when editing bearer-only application?


On 12.9.2014 14:51, Bill Burke wrote:
> Negative.  Bearer-only applications can receive revocation policies.
> i.e. "don't accept tokens before this date".  In the future we may want
> to push things like allowed CORS origins, IP blacklists, user
> blacklists, etc.  There's also stats we may want to gather from the
> applications.
>
> On 9/12/2014 5:25 AM, Stian Thorgersen wrote:
>> I propose we remove the "Admin URL" field for bearer-only applications. As a bearer-only application doesn't manage any user sessions there's not much point in propagating logouts to those.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Fri Sep 12 11:51:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Sep 2014 11:51:05 -0400
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <54131496.3050907@redhat.com>
References: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
	<5412EC60.2070402@redhat.com> <54131496.3050907@redhat.com>
Message-ID: <54131669.5040503@redhat.com>

Yes, we should hide scopes and claims.  Good catch.

On 9/12/2014 11:43 AM, Marek Posolda wrote:
> Possible related question is, if bearer-only applications need scopes
> and claims? Should we hide "Scopes" and "Claims" tabs in admin console
> when editing bearer-only application?
>
>
> On 12.9.2014 14:51, Bill Burke wrote:
>> Negative.  Bearer-only applications can receive revocation policies.
>> i.e. "don't accept tokens before this date".  In the future we may want
>> to push things like allowed CORS origins, IP blacklists, user
>> blacklists, etc.  There's also stats we may want to gather from the
>> applications.
>>
>> On 9/12/2014 5:25 AM, Stian Thorgersen wrote:
>>> I propose we remove the "Admin URL" field for bearer-only
>>> applications. As a bearer-only application doesn't manage any user
>>> sessions there's not much point in propagating logouts to those.
>>> _______________________________________________
>>> 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 Sep 12 11:52:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Sep 2014 11:52:54 -0400
Subject: [keycloak-dev] 1.0.1 release before major features?
Message-ID: <541316D6.2070200@redhat.com>

When we start working on some major features that require refactoring 
(SAML, internationalization, even expanded clustering support), should 
we do a 1.0.1 release?  22nd or 23rd?  Before we start our feature work?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Fri Sep 12 11:59:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Sep 2014 17:59:14 +0200
Subject: [keycloak-dev] Remove admin-url for bearer-only applications
In-Reply-To: <54131669.5040503@redhat.com>
References: <404210007.48478808.1410513931881.JavaMail.zimbra@redhat.com>
	<5412EC60.2070402@redhat.com> <54131496.3050907@redhat.com>
	<54131669.5040503@redhat.com>
Message-ID: <54131852.3000508@redhat.com>

Thanks, I will do that.

Marek

On 12.9.2014 17:51, Bill Burke wrote:
> Yes, we should hide scopes and claims.  Good catch.
>
> On 9/12/2014 11:43 AM, Marek Posolda wrote:
>> Possible related question is, if bearer-only applications need scopes
>> and claims? Should we hide "Scopes" and "Claims" tabs in admin console
>> when editing bearer-only application?
>>
>>
>> On 12.9.2014 14:51, Bill Burke wrote:
>>> Negative.  Bearer-only applications can receive revocation policies.
>>> i.e. "don't accept tokens before this date".  In the future we may want
>>> to push things like allowed CORS origins, IP blacklists, user
>>> blacklists, etc.  There's also stats we may want to gather from the
>>> applications.
>>>
>>> On 9/12/2014 5:25 AM, Stian Thorgersen wrote:
>>>> I propose we remove the "Admin URL" field for bearer-only
>>>> applications. As a bearer-only application doesn't manage any user
>>>> sessions there's not much point in propagating logouts to those.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>


From stian at redhat.com  Mon Sep 15 02:51:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Sep 2014 02:51:56 -0400 (EDT)
Subject: [keycloak-dev] 1.0.1 release before major features?
In-Reply-To: <541316D6.2070200@redhat.com>
References: <541316D6.2070200@redhat.com>
Message-ID: <889730289.49490683.1410763916496.JavaMail.zimbra@redhat.com>

Sure, there's already one thing that AeroGear will want (https://issues.jboss.org/browse/KEYCLOAK-653).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 12 September, 2014 5:52:54 PM
> Subject: [keycloak-dev] 1.0.1 release before major features?
> 
> When we start working on some major features that require refactoring
> (SAML, internationalization, even expanded clustering support), should
> we do a 1.0.1 release?  22nd or 23rd?  Before we start our feature work?
> --
> 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 Sep 15 08:28:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Sep 2014 08:28:48 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <2036576776.49626396.1410783004108.JavaMail.zimbra@redhat.com>
Message-ID: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>

Had an idea with regards to clustering and user sessions. Instead of sending messages to the cluster when a individual user session is refreshed all nodes send a periodic update message. Obviously that's only for user sessions and not for admin updates, where we should still send invalidation messages for each update.

Each node would keep a note of all user sessions where it has updated LastSessionRefresh, and once every period it would send this list to all nodes. This should mean that instead of sending a message every time a single session is updated, we send a single message per node every 60 seconds or so (should be configurable). When receiving a message from the cluster the node would go through the list and update the user sessions where the received LastSessionRefresh is higher than the one it has itself. Nodes still use the mem user sessions store, but with the cache on top.

From bburke at redhat.com  Mon Sep 15 08:41:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Sep 2014 08:41:39 -0400
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
Message-ID: <5416DE83.4010405@redhat.com>

Only works for session refreshes.  Also leaves an open window that the 
user is still logged in after they log out.

On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
> Had an idea with regards to clustering and user sessions. Instead of sending messages to the cluster when a individual user session is refreshed all nodes send a periodic update message. Obviously that's only for user sessions and not for admin updates, where we should still send invalidation messages for each update.
>
> Each node would keep a note of all user sessions where it has updated LastSessionRefresh, and once every period it would send this list to all nodes. This should mean that instead of sending a message every time a single session is updated, we send a single message per node every 60 seconds or so (should be configurable). When receiving a message from the cluster the node would go through the list and update the user sessions where the received LastSessionRefresh is higher than the one it has itself. Nodes still use the mem user sessions store, but with the cache on top.
> _______________________________________________
> 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  Mon Sep 15 08:52:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Sep 2014 08:52:46 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <5416DE83.4010405@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
Message-ID: <1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 15 September, 2014 2:41:39 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> Only works for session refreshes.  Also leaves an open window that the
> user is still logged in after they log out.

Yes, it's only for session refreshes, but IMO that's going to be the biggest traffic generator. For login and logouts we're going to have to send a message per event.

> 
> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
> > Had an idea with regards to clustering and user sessions. Instead of
> > sending messages to the cluster when a individual user session is
> > refreshed all nodes send a periodic update message. Obviously that's only
> > for user sessions and not for admin updates, where we should still send
> > invalidation messages for each update.
> >
> > Each node would keep a note of all user sessions where it has updated
> > LastSessionRefresh, and once every period it would send this list to all
> > nodes. This should mean that instead of sending a message every time a
> > single session is updated, we send a single message per node every 60
> > seconds or so (should be configurable). When receiving a message from the
> > cluster the node would go through the list and update the user sessions
> > where the received LastSessionRefresh is higher than the one it has
> > itself. Nodes still use the mem user sessions store, but with the cache on
> > top.
> > _______________________________________________
> > 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 supittma at redhat.com  Mon Sep 15 10:38:29 2014
From: supittma at redhat.com (Summers Pittman)
Date: Mon, 15 Sep 2014 10:38:29 -0400
Subject: [keycloak-dev] [Android] KeyCloak Authenticator
Message-ID: <5416F9E5.5010406@redhat.com>

<tldr>DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC 
AGAIN!</tldr>

Over the weekend I tried my hand at writing a Android Account 
Authenticator for KeyCloak.  This lets Android manage the KeyCloak 
account, fetch tokens, provide tokens to other apps etc.  KeyCloak 
Authenticator let's you drop your keycloak.json file into an apk and 
access your KeyCloak Account with one line of code from any application 
on your Android device.

Right now this is very much in the "I have an itch needing scratching" 
phase.  It doesn't do any robust error handling, hasn't been testing off 
the golden scenario, has no integration with any of the AeroGear stuff, 
etc.  Take a moment to watch the Demo and look at the demo project.

  Video Demo : 
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej

The Demo video uses Android's native account menu to request from the 
authenticator a KeyCloak account.  This launches the authenticator's 
activity which will retrieve the credentials for Android and store 
them.  When I am back in the settings page and showing off the stored 
account, this is all native Android UI and not part of the KeyCloak 
authenticator.

When I launch the Demo application this is a separate application from 
the authenticator apk.  The Demo project fetches the KeyCloak account 
from Android and gets its auth token.  Then it makes a request to 
KeyCloak's account service to fetch the user's account data.

In the demo app there are three lines of code related to auth.

   final Account account = am.getAccountsByType("org.keycloak.Account")[0];
   String token = am.getAuthToken(account, "org.keycloak.Account.token", 
null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN);

and

provider.setDefaultHeader("Authorization", "bearer " + token);

The first two lines fetch the account and token from Android.  The 
second line attaches the account's auth token to the web request to the 
server.

So now what?  I'll probably use this for my projects/demos because it 
makes my work easier.  Right now it doesn't have any connection to any 
of the "official" projects (Again, I wrote this over the weekend to see 
if I could) however it may be quite useful to someone.  In the project's 
README I've included a (incomplete) list of things that don't work.

wdyt?

Links :
  Project : https://github.com/secondsun/keycloak-android-authenticator
  Video Demo : 
https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
  Demo Source : 
https://github.com/secondsun/keycloak-account-authenticator-demo/


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From stian at redhat.com  Mon Sep 15 10:38:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Sep 2014 10:38:44 -0400 (EDT)
Subject: [keycloak-dev] Adapters
In-Reply-To: <1300704463.49765066.1410791732028.JavaMail.zimbra@redhat.com>
Message-ID: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>

I think it would make sense to provide a plain Java adapter, as well as a plain Servlet adapter. Further this should be the base for all other adapters.

  +--------+ +---------+  +-----------+     +---------+
  | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
  | Jetty  | |JBoss EAP|  |           |     |         |
  | ...    | |         |  |           |     |         |
  +----+---+ +---+-----+  +---+-------+     +----+----+
       |         |            |                  |
       |     +---v-----+      |             +----v----+
       +----->Servlet  <------+             | Undertow|
             |         |                    |         |
             +----+----+                    +----+----+
                  |       +---------+            |
                  +------->Java     <------------+
                          |         |
                          +---------+

The Java adapter should have minimum dependencies (maybe only http-client?).

Don't get to hung-up with the syntax (I knocked this together in 2 min), but the general idea would be something like:

        InputStream is = new FileInputStream("keycloak.json");

        KeycloakOAuthClient client = KeycloakClient.createOAuth(is);

        // get login url
        URL loginUrl = client.createLoginUrl(redirectUri);

        // exchange code to token
        AccessTokenResponse response = client.getToken(code, clientCredentials);

        // refresh token
        client.refreshToken(response.getToken());

We have most of the code, but what we don't is a public Java API.

From bburke at redhat.com  Mon Sep 15 10:47:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Sep 2014 10:47:26 -0400
Subject: [keycloak-dev] FYI: FreeOTP works OOTB
Message-ID: <5416FBFE.306@redhat.com>

Just tried FreeOTP.  It supports the same QR barcodes as Google 
Authenticator and works OOTB with keycloak.

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

From bburke at redhat.com  Mon Sep 15 11:17:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Sep 2014 11:17:35 -0400
Subject: [keycloak-dev] Adapters
In-Reply-To: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
Message-ID: <5417030F.6010606@redhat.com>

Much of you want is already the reality, but there are some caveats you 
must know about:

* Adapters need specific integration with each app server as they need 
to extract and set role mappings prior to the servlet container's roles 
allowed checks.  This can't be done in a filter.

* Being able to propagate the Subject between component layers 
(Servlet->EJB) requires specific app server integration.

* A keycloak logout invokes on adapter's admin url to invalidate the 
HTTP session.  The HTTP session invalidation is app server specific.

* I don't believe you can obtain client cert information from the 
servlet API which will be come important when we add client-cert support

Wildfly and JBossWeb have different integration SPIs for security, but 
most of the adapter code lives in a common library whose only dependency 
is Apache HTTP Client.  The core adapter library has a tiny Http message 
and http session mgmt facde to bridge between the two different containers.

On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> I think it would make sense to provide a plain Java adapter, as well as a plain Servlet adapter. Further this should be the base for all other adapters.
>
>    +--------+ +---------+  +-----------+     +---------+
>    | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
>    | Jetty  | |JBoss EAP|  |           |     |         |
>    | ...    | |         |  |           |     |         |
>    +----+---+ +---+-----+  +---+-------+     +----+----+
>         |         |            |                  |
>         |     +---v-----+      |             +----v----+
>         +----->Servlet  <------+             | Undertow|
>               |         |                    |         |
>               +----+----+                    +----+----+
>                    |       +---------+            |
>                    +------->Java     <------------+
>                            |         |
>                            +---------+
>
> The Java adapter should have minimum dependencies (maybe only http-client?).
>
> Don't get to hung-up with the syntax (I knocked this together in 2 min), but the general idea would be something like:
>
>          InputStream is = new FileInputStream("keycloak.json");
>
>          KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
>
>          // get login url
>          URL loginUrl = client.createLoginUrl(redirectUri);
>
>          // exchange code to token
>          AccessTokenResponse response = client.getToken(code, clientCredentials);
>
>          // refresh token
>          client.refreshToken(response.getToken());
>
> We have most of the code, but what we don't is a public Java API.
> _______________________________________________
> 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 Sep 15 11:21:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Sep 2014 11:21:32 -0400
Subject: [keycloak-dev] [Android] KeyCloak Authenticator
In-Reply-To: <5416F9E5.5010406@redhat.com>
References: <5416F9E5.5010406@redhat.com>
Message-ID: <541703FC.7040208@redhat.com>

Pretty cool.  How do we proceed?  What are next steps?

On 9/15/2014 10:38 AM, Summers Pittman wrote:
> <tldr>DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC
> AGAIN!</tldr>
>
> Over the weekend I tried my hand at writing a Android Account
> Authenticator for KeyCloak.  This lets Android manage the KeyCloak
> account, fetch tokens, provide tokens to other apps etc.  KeyCloak
> Authenticator let's you drop your keycloak.json file into an apk and
> access your KeyCloak Account with one line of code from any application
> on your Android device.
>
> Right now this is very much in the "I have an itch needing scratching"
> phase.  It doesn't do any robust error handling, hasn't been testing off
> the golden scenario, has no integration with any of the AeroGear stuff,
> etc.  Take a moment to watch the Demo and look at the demo project.
>
>    Video Demo :
> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
>
> The Demo video uses Android's native account menu to request from the
> authenticator a KeyCloak account.  This launches the authenticator's
> activity which will retrieve the credentials for Android and store
> them.  When I am back in the settings page and showing off the stored
> account, this is all native Android UI and not part of the KeyCloak
> authenticator.
>
> When I launch the Demo application this is a separate application from
> the authenticator apk.  The Demo project fetches the KeyCloak account
> from Android and gets its auth token.  Then it makes a request to
> KeyCloak's account service to fetch the user's account data.
>
> In the demo app there are three lines of code related to auth.
>
>     final Account account = am.getAccountsByType("org.keycloak.Account")[0];
>     String token = am.getAuthToken(account, "org.keycloak.Account.token",
> null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN);
>
> and
>
> provider.setDefaultHeader("Authorization", "bearer " + token);
>
> The first two lines fetch the account and token from Android.  The
> second line attaches the account's auth token to the web request to the
> server.
>
> So now what?  I'll probably use this for my projects/demos because it
> makes my work easier.  Right now it doesn't have any connection to any
> of the "official" projects (Again, I wrote this over the weekend to see
> if I could) however it may be quite useful to someone.  In the project's
> README I've included a (incomplete) list of things that don't work.
>
> wdyt?
>
> Links :
>    Project : https://github.com/secondsun/keycloak-android-authenticator
>    Video Demo :
> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
>    Demo Source :
> https://github.com/secondsun/keycloak-account-authenticator-demo/
>
>

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

From supittma at redhat.com  Mon Sep 15 12:09:26 2014
From: supittma at redhat.com (Summers Pittman)
Date: Mon, 15 Sep 2014 12:09:26 -0400
Subject: [keycloak-dev] [Android] KeyCloak Authenticator
In-Reply-To: <541703FC.7040208@redhat.com>
References: <5416F9E5.5010406@redhat.com> <541703FC.7040208@redhat.com>
Message-ID: <54170F36.2090900@redhat.com>

On Mon 15 Sep 2014 11:21:32 AM EDT, Bill Burke wrote:
>
> Pretty cool. How do we proceed? What are next steps?

First step is get people using it and sending feedback.  If anyone wants 
to for the repo and start making pull requests I would be more than 
happy to help/write a blog post/etc etc.

Right now this is firmly in the land of run the code up a flagpole and 
see who salutes while scratching my own itches.  I hate writing auth 
code and KC is the first thing that makes it seem like I will never have 
to again.

The immediate next step is making an app which uses a protected service 
and getting refresh tokens running.  At some point I will also need to 
add automated tests to the project. From there it is making sure that 
the project is easy to configure (ie any keycloak.json file will work) 
and that it will work when not pointed at the sup realm on my auth server.

After this will be getting error flows and social logins correct. Social 
logins will be hard because there are possibly infinite numbers of them 
as users add their own.  Also because I use a WebView I will need to 
white list a bunch of possible URLs somehow. This may be able to be 
communicated in the keycloak.json file or it could be an exercise left 
to the dev.

At a certain point we would want this to become an official project and 
end up in the keycloak or aerogear repositories.  We do have a few JIRAs 
around KeyCloak for Android (AGDROID-222, 229, 245).  This may obsolete 
them, I know the work has changed how I feel about how we are trying to 
do OAuth flavored things now.

Eventually in the far distant space future this little library will hit 
a 1.0.0.  In my mind, when the Authenticator is at 1.0.0 I will be able 
to create an Android OAuth client in the KC admin UI and be presented 
with the option to download an APK or an AAR(Android library), and a 
code example (similar to the Android variant in Unified Push).  Also 
there will be integration with Aerogear Android's pipeline modules for 
interacting with services.


>
>
> On 9/15/2014 10:38 AM, Summers Pittman wrote:
>>
>> <tldr>DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC
>> AGAIN!</tldr>
>>
>> Over the weekend I tried my hand at writing a Android Account
>> Authenticator for KeyCloak. This lets Android manage the KeyCloak
>> account, fetch tokens, provide tokens to other apps etc. KeyCloak
>> Authenticator let's you drop your keycloak.json file into an apk and
>> access your KeyCloak Account with one line of code from any application
>> on your Android device.
>>
>> Right now this is very much in the "I have an itch needing scratching"
>> phase. It doesn't do any robust error handling, hasn't been testing off
>> the golden scenario, has no integration with any of the AeroGear stuff,
>> etc. Take a moment to watch the Demo and look at the demo project.
>>
>> Video Demo :
>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
>>
>> The Demo video uses Android's native account menu to request from the
>> authenticator a KeyCloak account. This launches the authenticator's
>> activity which will retrieve the credentials for Android and store
>> them. When I am back in the settings page and showing off the stored
>> account, this is all native Android UI and not part of the KeyCloak
>> authenticator.
>>
>> When I launch the Demo application this is a separate application from
>> the authenticator apk. The Demo project fetches the KeyCloak account
>> from Android and gets its auth token. Then it makes a request to
>> KeyCloak's account service to fetch the user's account data.
>>
>> In the demo app there are three lines of code related to auth.
>>
>> final Account account = am.getAccountsByType("org.keycloak.Account")[0];
>> String token = am.getAuthToken(account, "org.keycloak.Account.token",
>> null, null, null, 
>> null).getResult().getString(AccountManager.KEY_AUTHTOKEN);
>>
>> and
>>
>> provider.setDefaultHeader("Authorization", "bearer " + token);
>>
>> The first two lines fetch the account and token from Android. The
>> second line attaches the account's auth token to the web request to the
>> server.
>>
>> So now what? I'll probably use this for my projects/demos because it
>> makes my work easier. Right now it doesn't have any connection to any
>> of the "official" projects (Again, I wrote this over the weekend to see
>> if I could) however it may be quite useful to someone. In the project's
>> README I've included a (incomplete) list of things that don't work.
>>
>> wdyt?
>>
>> Links :
>> Project : https://github.com/secondsun/keycloak-android-authenticator
>> Video Demo :
>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej
>> Demo Source :
>> https://github.com/secondsun/keycloak-account-authenticator-demo/
>>
>>
>
>




-- 
Summers Pittman
>
>>
>> Phone:404 941 4698
>> Java is my crack.
>


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.



From stian at redhat.com  Tue Sep 16 05:59:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 05:59:40 -0400 (EDT)
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <674980931.50266119.1410861270482.JavaMail.zimbra@redhat.com>
Message-ID: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>

WildFly 9 introduces features packs which seams ideal for us to build Keycloak upon.

I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs and WildFly's built in mechanism to create the appliance distro. This would replace our current custom appliance-dist. Further I'd like us to have two flavours of Keycloak:

* "appliance-lite": minimum Keycloak server only dist. For those that want a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we need to add Hibernate, RestEasy and Connectors (datasources) as well
* "appliance": full WildFly dist. For those that want to co-locate their JavaEE apps with the Keycloak server. Builds on the full WildFly dist.

I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and it works fine. Only thing I had to do was to include RestEasy and Hibernate jars in auth-server.war and configure the database directly in keycloak-server.json instead of using a datasource.

From mposolda at redhat.com  Tue Sep 16 06:09:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Sep 2014 12:09:07 +0200
Subject: [keycloak-dev] Cookies & RememberMe clarification
Message-ID: <54180C43.7080508@redhat.com>

Have few questions related to cookies & rememberMe.

1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by 
default (so expires when browser is closed). Thing is that lifespan of 
the identityToken generated in AuthenticationManager.createIdentityToken 
is just ssoSessionIdleTimeout, which is 10 minutes by default. And 
cookie is refreshed just during cookie SSO login. So for example when I 
have scenario like:
* Login to admin console
* Do some admin work for 15 minutes
* Then click to "Manage my account" button (or to some other Keycloak 
secured application), the token in the KEYCLOAK_IDENTITY cookie is not 
valid anymore, so I am immediately logged out. Note that UserSession is 
still valid as I had couple of refreshToken requests during my 15 
minutes 'admin' work.

So my question is if we can use ssoSessionMaxLifespan for the identity 
token instead of ssoSessionIdleTimeout? Note that even in cookie 
authentication, we are also checking if UserSession is valid. So if 
UserSession is expired, the login won't be successful anyway.

2) Second thing is RememberMe feature. Actually we have 
KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with 
rememberMe. But this cookie is actually not used anywhere for relogin! 
Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of 
ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY 
cookie will survive and you will be able to relogin.

Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So 
for example if I have scenario like:
* Login to admin console
* Close my browser and wait 15 minutes
* Then open my browser and try to relogin --- ATM both UserSession and 
KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't 
work and Keycloak login screen is displayed to me.

Also scenario like:
* Login to admin console
* Close my browser and restart Keycloak
* Then open my browser and try to relogin --- rememberMe also won't work 
as UserSession is not valid (unless I am using 'jpa' or 'mongo' 
UserSession provider).

IMO RememberMe shouldn't be tight to particular UserSession. I would 
expect that when I start browser next day, I will be automatically 
logged in even if my UserSession from previous day is already expired.

It seems that to properly support RememberMe, we should use 
KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of 
KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm 
privateKey and valid just for one use (Each RememberMe login will 
regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) . 
This would mean that we will need to persist stuff related to rememberMe 
with some additional related informations (realm, user, timestamp, 
ipAddress). So for example if admin will set Not-Before for realm, it 
will also invalidate all stored rememberMe tokens.

It seems that this will require some model changes and amount of work, 
but ATM RememberMe feature seems to be quite unusable to me.

wdyt?

Marek

From stian at redhat.com  Tue Sep 16 06:28:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 06:28:36 -0400 (EDT)
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <54180C43.7080508@redhat.com>
References: <54180C43.7080508@redhat.com>
Message-ID: <1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>

To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.

With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).

As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 September, 2014 12:09:07 PM
> Subject: [keycloak-dev] Cookies & RememberMe clarification
> 
> Have few questions related to cookies & rememberMe.
> 
> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
> default (so expires when browser is closed). Thing is that lifespan of
> the identityToken generated in AuthenticationManager.createIdentityToken
> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
> cookie is refreshed just during cookie SSO login. So for example when I
> have scenario like:
> * Login to admin console
> * Do some admin work for 15 minutes
> * Then click to "Manage my account" button (or to some other Keycloak
> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
> valid anymore, so I am immediately logged out. Note that UserSession is
> still valid as I had couple of refreshToken requests during my 15
> minutes 'admin' work.
> 
> So my question is if we can use ssoSessionMaxLifespan for the identity
> token instead of ssoSessionIdleTimeout? Note that even in cookie
> authentication, we are also checking if UserSession is valid. So if
> UserSession is expired, the login won't be successful anyway.
> 
> 2) Second thing is RememberMe feature. Actually we have
> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
> rememberMe. But this cookie is actually not used anywhere for relogin!
> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
> cookie will survive and you will be able to relogin.
> 
> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
> for example if I have scenario like:
> * Login to admin console
> * Close my browser and wait 15 minutes
> * Then open my browser and try to relogin --- ATM both UserSession and
> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
> work and Keycloak login screen is displayed to me.
> 
> Also scenario like:
> * Login to admin console
> * Close my browser and restart Keycloak
> * Then open my browser and try to relogin --- rememberMe also won't work
> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
> UserSession provider).
> 
> IMO RememberMe shouldn't be tight to particular UserSession. I would
> expect that when I start browser next day, I will be automatically
> logged in even if my UserSession from previous day is already expired.
> 
> It seems that to properly support RememberMe, we should use
> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
> privateKey and valid just for one use (Each RememberMe login will
> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
> This would mean that we will need to persist stuff related to rememberMe
> with some additional related informations (realm, user, timestamp,
> ipAddress). So for example if admin will set Not-Before for realm, it
> will also invalidate all stored rememberMe tokens.
> 
> It seems that this will require some model changes and amount of work,
> but ATM RememberMe feature seems to be quite unusable to me.
> 
> wdyt?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Sep 16 07:59:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 07:59:05 -0400 (EDT)
Subject: [keycloak-dev] Adapters
In-Reply-To: <5417030F.6010606@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
Message-ID: <952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>

What I was hoping to be able to achieve was a pure Java adapter, with an easy to use and well documented API. This would allow anyone to use Keycloak from anything Java. Most of the code is there, but we can clean-up the API IMO, and also provide some examples and documentation.

Further, we'd provide a pure Servlet adapter. As you point out it can't provide the same level of integration as our WildFly and AS7/EAP adapters. However, providing bespoke adapters for Tomcat, Jetty, etc. is going to be too much of an overhead, so I don't think we should provide bespoke adapters for non Red Hat products.

For mobile could just delegate to AeroGear. Ideally, AeroGear would provide the SDKs and documentation to use Keycloak with Android, iOS, Windows Mobile, Firefox, etc. and we would just add references to AeroGear in our documentation and webpage.

For other programming languages (php, ruby, etc.) I'm less sure what we can achieve. Perhaps we can delegate to existing OpenID Connect client libraries?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 15 September, 2014 5:17:35 PM
> Subject: Re: [keycloak-dev] Adapters
> 
> Much of you want is already the reality, but there are some caveats you
> must know about:
> 
> * Adapters need specific integration with each app server as they need
> to extract and set role mappings prior to the servlet container's roles
> allowed checks.  This can't be done in a filter.
> 
> * Being able to propagate the Subject between component layers
> (Servlet->EJB) requires specific app server integration.
> 
> * A keycloak logout invokes on adapter's admin url to invalidate the
> HTTP session.  The HTTP session invalidation is app server specific.
> 
> * I don't believe you can obtain client cert information from the
> servlet API which will be come important when we add client-cert support
> 
> Wildfly and JBossWeb have different integration SPIs for security, but
> most of the adapter code lives in a common library whose only dependency
> is Apache HTTP Client.  The core adapter library has a tiny Http message
> and http session mgmt facde to bridge between the two different containers.
> 
> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> > I think it would make sense to provide a plain Java adapter, as well as a
> > plain Servlet adapter. Further this should be the base for all other
> > adapters.
> >
> >    +--------+ +---------+  +-----------+     +---------+
> >    | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
> >    | Jetty  | |JBoss EAP|  |           |     |         |
> >    | ...    | |         |  |           |     |         |
> >    +----+---+ +---+-----+  +---+-------+     +----+----+
> >         |         |            |                  |
> >         |     +---v-----+      |             +----v----+
> >         +----->Servlet  <------+             | Undertow|
> >               |         |                    |         |
> >               +----+----+                    +----+----+
> >                    |       +---------+            |
> >                    +------->Java     <------------+
> >                            |         |
> >                            +---------+
> >
> > The Java adapter should have minimum dependencies (maybe only
> > http-client?).
> >
> > Don't get to hung-up with the syntax (I knocked this together in 2 min),
> > but the general idea would be something like:
> >
> >          InputStream is = new FileInputStream("keycloak.json");
> >
> >          KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
> >
> >          // get login url
> >          URL loginUrl = client.createLoginUrl(redirectUri);
> >
> >          // exchange code to token
> >          AccessTokenResponse response = client.getToken(code,
> >          clientCredentials);
> >
> >          // refresh token
> >          client.refreshToken(response.getToken());
> >
> > We have most of the code, but what we don't is a public Java API.
> > _______________________________________________
> > 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 ssilvert at redhat.com  Tue Sep 16 08:20:44 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 08:20:44 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
Message-ID: <54182B1C.7010609@redhat.com>

On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
> WildFly 9 introduces features packs which seams ideal for us to build Keycloak upon.
>
> I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs and WildFly's built in mechanism to create the appliance distro. This would replace our current custom appliance-dist.
I'm already working on this and I've found out that we're just a little 
bit early.  See 
http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html

We need Stuart to implement a feature to solve issue #2 and I'm working 
on issue #3 right now so that we can properly install the auth server in 
a domain environment.
> Further I'd like us to have two flavours of Keycloak:
>
> * "appliance-lite": minimum Keycloak server only dist. For those that want a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we need to add Hibernate, RestEasy and Connectors (datasources) as well
> * "appliance": full WildFly dist. For those that want to co-locate their JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
We need to think long and hard about this one.  Do we really want two 
appliance downloads?

The answer might come when the WildFly provisioning tool is finished.  
This is a tool that lets you "roll your own" server.  So it's possible 
that we rely on that.   One option might be that we let you download 
"appliance-lite" and then you use the provisioning tool to add other 
things you might want.
> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and it works fine. Only thing I had to do was to include RestEasy and Hibernate jars in auth-server.war and configure the database directly in keycloak-server.json instead of using a datasource.
Right now it won't run on the web profile.  I've submitted a patch to 
WildFly, so that should be fixed in the next release.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Sep 16 08:34:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 08:34:21 -0400 (EDT)
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <54182B1C.7010609@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54182B1C.7010609@redhat.com>
Message-ID: <769642125.50328583.1410870861319.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 September, 2014 2:20:44 PM
> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
> 
> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
> > WildFly 9 introduces features packs which seams ideal for us to build
> > Keycloak upon.
> >
> > I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs
> > and WildFly's built in mechanism to create the appliance distro. This
> > would replace our current custom appliance-dist.
> I'm already working on this and I've found out that we're just a little
> bit early.  See
> http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html

Great :)

Are you providing this directly in Keycloak, or do you have it somewhere else?

> 
> We need Stuart to implement a feature to solve issue #2 and I'm working
> on issue #3 right now so that we can properly install the auth server in
> a domain environment.
> > Further I'd like us to have two flavours of Keycloak:
> >
> > * "appliance-lite": minimum Keycloak server only dist. For those that want
> > a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we
> > need to add Hibernate, RestEasy and Connectors (datasources) as well
> > * "appliance": full WildFly dist. For those that want to co-locate their
> > JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
> We need to think long and hard about this one.  Do we really want two
> appliance downloads?

I think we'll want to at least have a standalone Keycloak server. However, only having that will make it harder for developers and also for anyone that wants to try our examples.

> 
> The answer might come when the WildFly provisioning tool is finished.
> This is a tool that lets you "roll your own" server.  So it's possible
> that we rely on that.   One option might be that we let you download
> "appliance-lite" and then you use the provisioning tool to add other
> things you might want.
> > I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and it
> > works fine. Only thing I had to do was to include RestEasy and Hibernate
> > jars in auth-server.war and configure the database directly in
> > keycloak-server.json instead of using a datasource.
> Right now it won't run on the web profile.  I've submitted a patch to
> WildFly, so that should be fixed in the next release.

What doesn't work? It seemed to work fine for me.

> > _______________________________________________
> > 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  Tue Sep 16 08:49:46 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 08:49:46 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <769642125.50328583.1410870861319.JavaMail.zimbra@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54182B1C.7010609@redhat.com>
	<769642125.50328583.1410870861319.JavaMail.zimbra@redhat.com>
Message-ID: <541831EA.5090907@redhat.com>

On 9/16/2014 8:34 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 16 September, 2014 2:20:44 PM
>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>
>> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>>> WildFly 9 introduces features packs which seams ideal for us to build
>>> Keycloak upon.
>>>
>>> I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs
>>> and WildFly's built in mechanism to create the appliance distro. This
>>> would replace our current custom appliance-dist.
>> I'm already working on this and I've found out that we're just a little
>> bit early.  See
>> http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html
> Great :)
>
> Are you providing this directly in Keycloak, or do you have it somewhere else?
The plan is to have it all live in the Keycloak project.  But perhaps we 
should talk about whether or not it makes sense as a Keycloak subproject 
or as just a Maven submodule.

The Keycloak Feature Pack definitely will not live in WildFly. WildFly 
itself is breaking up into more and more subprojects.
>
>> We need Stuart to implement a feature to solve issue #2 and I'm working
>> on issue #3 right now so that we can properly install the auth server in
>> a domain environment.
>>> Further I'd like us to have two flavours of Keycloak:
>>>
>>> * "appliance-lite": minimum Keycloak server only dist. For those that want
>>> a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we
>>> need to add Hibernate, RestEasy and Connectors (datasources) as well
>>> * "appliance": full WildFly dist. For those that want to co-locate their
>>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>> We need to think long and hard about this one.  Do we really want two
>> appliance downloads?
> I think we'll want to at least have a standalone Keycloak server. However, only having that will make it harder for developers and also for anyone that wants to try our examples.
What are you thinking of that will be harder if we only have one appliance?
>
>> The answer might come when the WildFly provisioning tool is finished.
>> This is a tool that lets you "roll your own" server.  So it's possible
>> that we rely on that.   One option might be that we let you download
>> "appliance-lite" and then you use the provisioning tool to add other
>> things you might want.
>>> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and it
>>> works fine. Only thing I had to do was to include RestEasy and Hibernate
>>> jars in auth-server.war and configure the database directly in
>>> keycloak-server.json instead of using a datasource.
>> Right now it won't run on the web profile.  I've submitted a patch to
>> WildFly, so that should be fixed in the next release.
> What doesn't work? It seemed to work fine for me.
I thought my patch didn't make it into the release.  I was wrong. False 
alarm.
>
>>> _______________________________________________
>>> 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 Sep 16 08:54:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 08:54:05 -0400 (EDT)
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <541831EA.5090907@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54182B1C.7010609@redhat.com>
	<769642125.50328583.1410870861319.JavaMail.zimbra@redhat.com>
	<541831EA.5090907@redhat.com>
Message-ID: <188876742.50340723.1410872045228.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 September, 2014 2:49:46 PM
> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
> 
> On 9/16/2014 8:34 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 16 September, 2014 2:20:44 PM
> >> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
> >>
> >> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
> >>> WildFly 9 introduces features packs which seams ideal for us to build
> >>> Keycloak upon.
> >>>
> >>> I'd like to start a "wildfly-9" branch of Keycloak that uses
> >>> feature-packs
> >>> and WildFly's built in mechanism to create the appliance distro. This
> >>> would replace our current custom appliance-dist.
> >> I'm already working on this and I've found out that we're just a little
> >> bit early.  See
> >> http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html
> > Great :)
> >
> > Are you providing this directly in Keycloak, or do you have it somewhere
> > else?
> The plan is to have it all live in the Keycloak project.  But perhaps we
> should talk about whether or not it makes sense as a Keycloak subproject
> or as just a Maven submodule.

I'd say it should be a Maven submodule as then we can use it to build our appliance(s)

> 
> The Keycloak Feature Pack definitely will not live in WildFly. WildFly
> itself is breaking up into more and more subprojects.
> >
> >> We need Stuart to implement a feature to solve issue #2 and I'm working
> >> on issue #3 right now so that we can properly install the auth server in
> >> a domain environment.
> >>> Further I'd like us to have two flavours of Keycloak:
> >>>
> >>> * "appliance-lite": minimum Keycloak server only dist. For those that
> >>> want
> >>> a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we
> >>> need to add Hibernate, RestEasy and Connectors (datasources) as well
> >>> * "appliance": full WildFly dist. For those that want to co-locate their
> >>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
> >> We need to think long and hard about this one.  Do we really want two
> >> appliance downloads?
> > I think we'll want to at least have a standalone Keycloak server. However,
> > only having that will make it harder for developers and also for anyone
> > that wants to try our examples.
> What are you thinking of that will be harder if we only have one appliance?

If we only provide a standalone Keycloak server dist (built on web-lite) that would mean that developers would have to either have a separate WildFly running to deploy examples and their own JavaEE apps

> >
> >> The answer might come when the WildFly provisioning tool is finished.
> >> This is a tool that lets you "roll your own" server.  So it's possible
> >> that we rely on that.   One option might be that we let you download
> >> "appliance-lite" and then you use the provisioning tool to add other
> >> things you might want.
> >>> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and
> >>> it
> >>> works fine. Only thing I had to do was to include RestEasy and Hibernate
> >>> jars in auth-server.war and configure the database directly in
> >>> keycloak-server.json instead of using a datasource.
> >> Right now it won't run on the web profile.  I've submitted a patch to
> >> WildFly, so that should be fixed in the next release.
> > What doesn't work? It seemed to work fine for me.
> I thought my patch didn't make it into the release.  I was wrong. False
> alarm.
> >
> >>> _______________________________________________
> >>> 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  Tue Sep 16 09:10:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 09:10:20 -0400
Subject: [keycloak-dev] Adapters
In-Reply-To: <952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
	<952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
Message-ID: <541836BC.4090205@redhat.com>

I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty, 
node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect 
libraries are only a fallback plan.

Also, we can't rely on third-party libs for the reasons I mentioned 
below.  Bearer auth is also implementation dependent because tokens are 
opaque in oauth/openid specs.  So any rest service is going to have to 
understand our token format and extract and validate the JWS.



On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
> What I was hoping to be able to achieve was a pure Java adapter, with an easy to use and well documented API. This would allow anyone to use Keycloak from anything Java. Most of the code is there, but we can clean-up the API IMO, and also provide some examples and documentation.
>
> Further, we'd provide a pure Servlet adapter. As you point out it can't provide the same level of integration as our WildFly and AS7/EAP adapters. However, providing bespoke adapters for Tomcat, Jetty, etc. is going to be too much of an overhead, so I don't think we should provide bespoke adapters for non Red Hat products.
>
> For mobile could just delegate to AeroGear. Ideally, AeroGear would provide the SDKs and documentation to use Keycloak with Android, iOS, Windows Mobile, Firefox, etc. and we would just add references to AeroGear in our documentation and webpage.
>
> For other programming languages (php, ruby, etc.) I'm less sure what we can achieve. Perhaps we can delegate to existing OpenID Connect client libraries?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 15 September, 2014 5:17:35 PM
>> Subject: Re: [keycloak-dev] Adapters
>>
>> Much of you want is already the reality, but there are some caveats you
>> must know about:
>>
>> * Adapters need specific integration with each app server as they need
>> to extract and set role mappings prior to the servlet container's roles
>> allowed checks.  This can't be done in a filter.
>>
>> * Being able to propagate the Subject between component layers
>> (Servlet->EJB) requires specific app server integration.
>>
>> * A keycloak logout invokes on adapter's admin url to invalidate the
>> HTTP session.  The HTTP session invalidation is app server specific.
>>
>> * I don't believe you can obtain client cert information from the
>> servlet API which will be come important when we add client-cert support
>>
>> Wildfly and JBossWeb have different integration SPIs for security, but
>> most of the adapter code lives in a common library whose only dependency
>> is Apache HTTP Client.  The core adapter library has a tiny Http message
>> and http session mgmt facde to bridge between the two different containers.
>>
>> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
>>> I think it would make sense to provide a plain Java adapter, as well as a
>>> plain Servlet adapter. Further this should be the base for all other
>>> adapters.
>>>
>>>     +--------+ +---------+  +-----------+     +---------+
>>>     | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
>>>     | Jetty  | |JBoss EAP|  |           |     |         |
>>>     | ...    | |         |  |           |     |         |
>>>     +----+---+ +---+-----+  +---+-------+     +----+----+
>>>          |         |            |                  |
>>>          |     +---v-----+      |             +----v----+
>>>          +----->Servlet  <------+             | Undertow|
>>>                |         |                    |         |
>>>                +----+----+                    +----+----+
>>>                     |       +---------+            |
>>>                     +------->Java     <------------+
>>>                             |         |
>>>                             +---------+
>>>
>>> The Java adapter should have minimum dependencies (maybe only
>>> http-client?).
>>>
>>> Don't get to hung-up with the syntax (I knocked this together in 2 min),
>>> but the general idea would be something like:
>>>
>>>           InputStream is = new FileInputStream("keycloak.json");
>>>
>>>           KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
>>>
>>>           // get login url
>>>           URL loginUrl = client.createLoginUrl(redirectUri);
>>>
>>>           // exchange code to token
>>>           AccessTokenResponse response = client.getToken(code,
>>>           clientCredentials);
>>>
>>>           // refresh token
>>>           client.refreshToken(response.getToken());
>>>
>>> We have most of the code, but what we don't is a public Java API.
>>> _______________________________________________
>>> 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 Sep 16 09:15:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Sep 2014 09:15:12 -0400 (EDT)
Subject: [keycloak-dev] Adapters
In-Reply-To: <541836BC.4090205@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
	<952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
	<541836BC.4090205@redhat.com>
Message-ID: <1168081435.50362026.1410873312152.JavaMail.zimbra@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, 16 September, 2014 3:10:20 PM
> Subject: Re: [keycloak-dev] Adapters
> 
> I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty,
> node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect
> libraries are only a fallback plan.

Who is going to implement and maintain all those adapters? I just can't see us having enough man-power to do that. Especially if we start venturing into non-java land.

> 
> Also, we can't rely on third-party libs for the reasons I mentioned
> below.  Bearer auth is also implementation dependent because tokens are
> opaque in oauth/openid specs.  So any rest service is going to have to
> understand our token format and extract and validate the JWS.

What parts of the token are non-standard other than the roles? OAuth2 has a standard param for roles 'scope', couldn't we use that?

> 
> 
> 
> On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
> > What I was hoping to be able to achieve was a pure Java adapter, with an
> > easy to use and well documented API. This would allow anyone to use
> > Keycloak from anything Java. Most of the code is there, but we can
> > clean-up the API IMO, and also provide some examples and documentation.
> >
> > Further, we'd provide a pure Servlet adapter. As you point out it can't
> > provide the same level of integration as our WildFly and AS7/EAP adapters.
> > However, providing bespoke adapters for Tomcat, Jetty, etc. is going to be
> > too much of an overhead, so I don't think we should provide bespoke
> > adapters for non Red Hat products.
> >
> > For mobile could just delegate to AeroGear. Ideally, AeroGear would provide
> > the SDKs and documentation to use Keycloak with Android, iOS, Windows
> > Mobile, Firefox, etc. and we would just add references to AeroGear in our
> > documentation and webpage.
> >
> > For other programming languages (php, ruby, etc.) I'm less sure what we can
> > achieve. Perhaps we can delegate to existing OpenID Connect client
> > libraries?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 15 September, 2014 5:17:35 PM
> >> Subject: Re: [keycloak-dev] Adapters
> >>
> >> Much of you want is already the reality, but there are some caveats you
> >> must know about:
> >>
> >> * Adapters need specific integration with each app server as they need
> >> to extract and set role mappings prior to the servlet container's roles
> >> allowed checks.  This can't be done in a filter.
> >>
> >> * Being able to propagate the Subject between component layers
> >> (Servlet->EJB) requires specific app server integration.
> >>
> >> * A keycloak logout invokes on adapter's admin url to invalidate the
> >> HTTP session.  The HTTP session invalidation is app server specific.
> >>
> >> * I don't believe you can obtain client cert information from the
> >> servlet API which will be come important when we add client-cert support
> >>
> >> Wildfly and JBossWeb have different integration SPIs for security, but
> >> most of the adapter code lives in a common library whose only dependency
> >> is Apache HTTP Client.  The core adapter library has a tiny Http message
> >> and http session mgmt facde to bridge between the two different
> >> containers.
> >>
> >> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> >>> I think it would make sense to provide a plain Java adapter, as well as a
> >>> plain Servlet adapter. Further this should be the base for all other
> >>> adapters.
> >>>
> >>>     +--------+ +---------+  +-----------+     +---------+
> >>>     | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
> >>>     | Jetty  | |JBoss EAP|  |           |     |         |
> >>>     | ...    | |         |  |           |     |         |
> >>>     +----+---+ +---+-----+  +---+-------+     +----+----+
> >>>          |         |            |                  |
> >>>          |     +---v-----+      |             +----v----+
> >>>          +----->Servlet  <------+             | Undertow|
> >>>                |         |                    |         |
> >>>                +----+----+                    +----+----+
> >>>                     |       +---------+            |
> >>>                     +------->Java     <------------+
> >>>                             |         |
> >>>                             +---------+
> >>>
> >>> The Java adapter should have minimum dependencies (maybe only
> >>> http-client?).
> >>>
> >>> Don't get to hung-up with the syntax (I knocked this together in 2 min),
> >>> but the general idea would be something like:
> >>>
> >>>           InputStream is = new FileInputStream("keycloak.json");
> >>>
> >>>           KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
> >>>
> >>>           // get login url
> >>>           URL loginUrl = client.createLoginUrl(redirectUri);
> >>>
> >>>           // exchange code to token
> >>>           AccessTokenResponse response = client.getToken(code,
> >>>           clientCredentials);
> >>>
> >>>           // refresh token
> >>>           client.refreshToken(response.getToken());
> >>>
> >>> We have most of the code, but what we don't is a public Java API.
> >>> _______________________________________________
> >>> 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 ssilvert at redhat.com  Tue Sep 16 09:29:03 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 09:29:03 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <188876742.50340723.1410872045228.JavaMail.zimbra@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54182B1C.7010609@redhat.com>
	<769642125.50328583.1410870861319.JavaMail.zimbra@redhat.com>
	<541831EA.5090907@redhat.com>
	<188876742.50340723.1410872045228.JavaMail.zimbra@redhat.com>
Message-ID: <54183B1F.8020902@redhat.com>

On 9/16/2014 8:54 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 16 September, 2014 2:49:46 PM
>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>
>> On 9/16/2014 8:34 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 16 September, 2014 2:20:44 PM
>>>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>>>
>>>> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>>>>> WildFly 9 introduces features packs which seams ideal for us to build
>>>>> Keycloak upon.
>>>>>
>>>>> I'd like to start a "wildfly-9" branch of Keycloak that uses
>>>>> feature-packs
>>>>> and WildFly's built in mechanism to create the appliance distro. This
>>>>> would replace our current custom appliance-dist.
>>>> I'm already working on this and I've found out that we're just a little
>>>> bit early.  See
>>>> http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feature-Pack-td5714921.html
>>> Great :)
>>>
>>> Are you providing this directly in Keycloak, or do you have it somewhere
>>> else?
>> The plan is to have it all live in the Keycloak project.  But perhaps we
>> should talk about whether or not it makes sense as a Keycloak subproject
>> or as just a Maven submodule.
> I'd say it should be a Maven submodule as then we can use it to build our appliance(s)
We can still do that if it is a Keycloak subproject.

The issue is about release schedules.  If it is a Keycloak subproject 
then the feature pack can have its own releases.  This might be 
necessary in order to keep up with changes in WildFly and EAP releases.  
If it is a subproject then we would probably do a feature pack release 
every time we do a Keycloak release.  However, let's say WildFly does a 
release that breaks our feature pack.  We might not be ready to do a 
Keycloak release but we could do a feature pack release to fix the problem.

On the other hand, I'm not sure if it's worth the overhead to have the 
subproject.  Maybe we should start it out as a submodule and move it 
later if needed.
>
>> The Keycloak Feature Pack definitely will not live in WildFly. WildFly
>> itself is breaking up into more and more subprojects.
>>>> We need Stuart to implement a feature to solve issue #2 and I'm working
>>>> on issue #3 right now so that we can properly install the auth server in
>>>> a domain environment.
>>>>> Further I'd like us to have two flavours of Keycloak:
>>>>>
>>>>> * "appliance-lite": minimum Keycloak server only dist. For those that
>>>>> want
>>>>> a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we
>>>>> need to add Hibernate, RestEasy and Connectors (datasources) as well
>>>>> * "appliance": full WildFly dist. For those that want to co-locate their
>>>>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>>>> We need to think long and hard about this one.  Do we really want two
>>>> appliance downloads?
>>> I think we'll want to at least have a standalone Keycloak server. However,
>>> only having that will make it harder for developers and also for anyone
>>> that wants to try our examples.
>> What are you thinking of that will be harder if we only have one appliance?
> If we only provide a standalone Keycloak server dist (built on web-lite) that would mean that developers would have to either have a separate WildFly running to deploy examples and their own JavaEE apps
This is where the provisioning tool might come to our rescue.  I think 
the way it will play out is that we keep the appliance as a 
downloadable, pre-configured, standalone auth server.

If you want to combine an auth server with other services then you use 
the provisioning tool to add Keycloak to your favorite flavor of WildFly.
>
>>>> The answer might come when the WildFly provisioning tool is finished.
>>>> This is a tool that lets you "roll your own" server.  So it's possible
>>>> that we rely on that.   One option might be that we let you download
>>>> "appliance-lite" and then you use the provisioning tool to add other
>>>> things you might want.
>>>>> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite and
>>>>> it
>>>>> works fine. Only thing I had to do was to include RestEasy and Hibernate
>>>>> jars in auth-server.war and configure the database directly in
>>>>> keycloak-server.json instead of using a datasource.
>>>> Right now it won't run on the web profile.  I've submitted a patch to
>>>> WildFly, so that should be fixed in the next release.
>>> What doesn't work? It seemed to work fine for me.
>> I thought my patch didn't make it into the release.  I was wrong. False
>> alarm.
>>>>> _______________________________________________
>>>>> 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  Tue Sep 16 09:39:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 09:39:52 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
Message-ID: <54183DA8.9070904@redhat.com>



On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
> WildFly 9 introduces features packs which seams ideal for us to build Keycloak upon.
>
> I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs and WildFly's built in mechanism to create the appliance distro. This would replace our current custom appliance-dist. Further I'd like us to have two flavours of Keycloak:
>
> * "appliance-lite": minimum Keycloak server only dist. For those that want a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we need to add Hibernate, RestEasy and Connectors (datasources) as well
> * "appliance": full WildFly dist. For those that want to co-locate their JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>

We've discussed this before.

The downside to a stripped down keycloak distro is the examples can't 
run out of the box anymore and users will have to  download a full 
Wildfly distro anyways and also configure it to run on different ports. 
  They will have to edit example config files to point to the correct 
ports.  Basically a lot more work to get things up and running for the 
first time.

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

From mposolda at redhat.com  Tue Sep 16 09:52:04 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Sep 2014 15:52:04 +0200
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>
References: <54180C43.7080508@redhat.com>
	<1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>
Message-ID: <54184084.9000107@redhat.com>

On 16.9.2014 12:28, Stian Thorgersen wrote:
> To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.
yeah. But besides validity of the KEYCLOAK_IDENTITY cookie, I would say 
that identityToken tight to the cookie should be set to 
ssoSessionMaxLifespan as well?

Fact is that KEYCLOAK_IDENTITY cookie is tight to the UserSession. But 
KEYCLOAK_IDENTITY cookie is refreshed just during SSO login, when 
UserSession.setLastSessionRefresh is called either during SSO login or 
refreshing token. This could lead to the situation when UserSession is 
still valid, but token from KEYCLOAK_IDENTITY cookie is expired, hence 
user is logged out even he has valid UserSession (my example 1 from 
previous mail) .

>
> With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).
Maybe yes. My understanding of rememberMe is that you may need to 
automatically login from your browser even after very long time (in 
days), hence I meant to not tight it to UserSession. But maybe it's just 
me:-)

I meant to address stuff like logout of all sessions from acct 
management with the persistent rememberMe records. So when someone wants 
to logout all sessions, it would clear rememberMe records too (Similarly 
when realm.notBefore is set by admin or other similar actions). It would 
be quite amount of work and model, so if we can live with tight 
automatic relogin just to UserSession, it's fine with me.
>
> As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.
ah, ok. So KEYCLOAK_REMEMBER_ME cookie will be used just as a 'hint' to 
prefil login form then? I can add support for this though. As actually 
KEYCLOAK_REMEMBER_ME cookie is not used for anything.

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 16 September, 2014 12:09:07 PM
>> Subject: [keycloak-dev] Cookies & RememberMe clarification
>>
>> Have few questions related to cookies & rememberMe.
>>
>> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
>> default (so expires when browser is closed). Thing is that lifespan of
>> the identityToken generated in AuthenticationManager.createIdentityToken
>> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
>> cookie is refreshed just during cookie SSO login. So for example when I
>> have scenario like:
>> * Login to admin console
>> * Do some admin work for 15 minutes
>> * Then click to "Manage my account" button (or to some other Keycloak
>> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
>> valid anymore, so I am immediately logged out. Note that UserSession is
>> still valid as I had couple of refreshToken requests during my 15
>> minutes 'admin' work.
>>
>> So my question is if we can use ssoSessionMaxLifespan for the identity
>> token instead of ssoSessionIdleTimeout? Note that even in cookie
>> authentication, we are also checking if UserSession is valid. So if
>> UserSession is expired, the login won't be successful anyway.
>>
>> 2) Second thing is RememberMe feature. Actually we have
>> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
>> rememberMe. But this cookie is actually not used anywhere for relogin!
>> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
>> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
>> cookie will survive and you will be able to relogin.
>>
>> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
>> for example if I have scenario like:
>> * Login to admin console
>> * Close my browser and wait 15 minutes
>> * Then open my browser and try to relogin --- ATM both UserSession and
>> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
>> work and Keycloak login screen is displayed to me.
>>
>> Also scenario like:
>> * Login to admin console
>> * Close my browser and restart Keycloak
>> * Then open my browser and try to relogin --- rememberMe also won't work
>> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
>> UserSession provider).
>>
>> IMO RememberMe shouldn't be tight to particular UserSession. I would
>> expect that when I start browser next day, I will be automatically
>> logged in even if my UserSession from previous day is already expired.
>>
>> It seems that to properly support RememberMe, we should use
>> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
>> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
>> privateKey and valid just for one use (Each RememberMe login will
>> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
>> This would mean that we will need to persist stuff related to rememberMe
>> with some additional related informations (realm, user, timestamp,
>> ipAddress). So for example if admin will set Not-Before for realm, it
>> will also invalidate all stored rememberMe tokens.
>>
>> It seems that this will require some model changes and amount of work,
>> but ATM RememberMe feature seems to be quite unusable to me.
>>
>> wdyt?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Tue Sep 16 09:52:25 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 09:52:25 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <54183DA8.9070904@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54183DA8.9070904@redhat.com>
Message-ID: <54184099.9020006@redhat.com>

On 9/16/2014 9:39 AM, Bill Burke wrote:
>
> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>> WildFly 9 introduces features packs which seams ideal for us to build Keycloak upon.
>>
>> I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs and WildFly's built in mechanism to create the appliance distro. This would replace our current custom appliance-dist. Further I'd like us to have two flavours of Keycloak:
>>
>> * "appliance-lite": minimum Keycloak server only dist. For those that want a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we need to add Hibernate, RestEasy and Connectors (datasources) as well
>> * "appliance": full WildFly dist. For those that want to co-locate their JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>>
> We've discussed this before.
>
> The downside to a stripped down keycloak distro is the examples can't
> run out of the box anymore and users will have to  download a full
> Wildfly distro anyways and also configure it to run on different ports.
>    They will have to edit example config files to point to the correct
> ports.  Basically a lot more work to get things up and running for the
> first time.
>
Hmm.  Perhaps the examples will be packaged as its own feature pack.

A feature pack might make it even easier to get up and running. Today 
you still have to download the appliance, boot the server, import the 
test realm, and then build and deploy the examples.  I'd like to get rid 
of those steps.

I think a lot of this depends on how good the provisioning tool turns 
out to be.

From bburke at redhat.com  Tue Sep 16 09:54:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 09:54:50 -0400
Subject: [keycloak-dev] Adapters
In-Reply-To: <1168081435.50362026.1410873312152.JavaMail.zimbra@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
	<952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
	<541836BC.4090205@redhat.com>
	<1168081435.50362026.1410873312152.JavaMail.zimbra@redhat.com>
Message-ID: <5418412A.50300@redhat.com>



On 9/16/2014 9:15 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: Tuesday, 16 September, 2014 3:10:20 PM
>> Subject: Re: [keycloak-dev] Adapters
>>
>> I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty,
>> node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect
>> libraries are only a fallback plan.
>
> Who is going to implement and maintain all those adapters? I just can't see us having enough man-power to do that. Especially if we start venturing into non-java land.
>

You're starting to sound like a whiny product manager instead of 
somebody that wants a successful keycloak project. :)

We're just going to have to do it.  Having an IAM that only works well 
in a JBoss ecosystem is unacceptable, IMO.  LIke I said, most of the 
logic in Java is in a common core adapter library already.  People are 
already demanding Tomcat support.  Netty won't be far behind.

These integration requirements are just going to become worse and worse. 
  We just have to deal with it if we want to succeed.

>>
>> Also, we can't rely on third-party libs for the reasons I mentioned
>> below.  Bearer auth is also implementation dependent because tokens are
>> opaque in oauth/openid specs.  So any rest service is going to have to
>> understand our token format and extract and validate the JWS.
>
> What parts of the token are non-standard other than the roles? OAuth2 has a standard param for roles 'scope', couldn't we use that?
>


Token formats are not standardized at all, not even around JWT.  Go read 
oauth2/openid connect.  Access tokens (and codes) are completely opaque. 
  I even had a talk with somebody on Oauth-WG about this as I wanted to 
standardize our CORS stuff.  He told me that nobody will ever agree on 
the token format.  At least not at this point in time.  Also scope has 
nothing to do with roles.  Scope doesn't solve bearer auth token 
validation problem.

>>
>>
>>
>> On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
>>> What I was hoping to be able to achieve was a pure Java adapter, with an
>>> easy to use and well documented API. This would allow anyone to use
>>> Keycloak from anything Java. Most of the code is there, but we can
>>> clean-up the API IMO, and also provide some examples and documentation.
>>>
>>> Further, we'd provide a pure Servlet adapter. As you point out it can't
>>> provide the same level of integration as our WildFly and AS7/EAP adapters.
>>> However, providing bespoke adapters for Tomcat, Jetty, etc. is going to be
>>> too much of an overhead, so I don't think we should provide bespoke
>>> adapters for non Red Hat products.
>>>
>>> For mobile could just delegate to AeroGear. Ideally, AeroGear would provide
>>> the SDKs and documentation to use Keycloak with Android, iOS, Windows
>>> Mobile, Firefox, etc. and we would just add references to AeroGear in our
>>> documentation and webpage.
>>>
>>> For other programming languages (php, ruby, etc.) I'm less sure what we can
>>> achieve. Perhaps we can delegate to existing OpenID Connect client
>>> libraries?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 15 September, 2014 5:17:35 PM
>>>> Subject: Re: [keycloak-dev] Adapters
>>>>
>>>> Much of you want is already the reality, but there are some caveats you
>>>> must know about:
>>>>
>>>> * Adapters need specific integration with each app server as they need
>>>> to extract and set role mappings prior to the servlet container's roles
>>>> allowed checks.  This can't be done in a filter.
>>>>
>>>> * Being able to propagate the Subject between component layers
>>>> (Servlet->EJB) requires specific app server integration.
>>>>
>>>> * A keycloak logout invokes on adapter's admin url to invalidate the
>>>> HTTP session.  The HTTP session invalidation is app server specific.
>>>>
>>>> * I don't believe you can obtain client cert information from the
>>>> servlet API which will be come important when we add client-cert support
>>>>
>>>> Wildfly and JBossWeb have different integration SPIs for security, but
>>>> most of the adapter code lives in a common library whose only dependency
>>>> is Apache HTTP Client.  The core adapter library has a tiny Http message
>>>> and http session mgmt facde to bridge between the two different
>>>> containers.
>>>>
>>>> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
>>>>> I think it would make sense to provide a plain Java adapter, as well as a
>>>>> plain Servlet adapter. Further this should be the base for all other
>>>>> adapters.
>>>>>
>>>>>      +--------+ +---------+  +-----------+     +---------+
>>>>>      | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
>>>>>      | Jetty  | |JBoss EAP|  |           |     |         |
>>>>>      | ...    | |         |  |           |     |         |
>>>>>      +----+---+ +---+-----+  +---+-------+     +----+----+
>>>>>           |         |            |                  |
>>>>>           |     +---v-----+      |             +----v----+
>>>>>           +----->Servlet  <------+             | Undertow|
>>>>>                 |         |                    |         |
>>>>>                 +----+----+                    +----+----+
>>>>>                      |       +---------+            |
>>>>>                      +------->Java     <------------+
>>>>>                              |         |
>>>>>                              +---------+
>>>>>
>>>>> The Java adapter should have minimum dependencies (maybe only
>>>>> http-client?).
>>>>>
>>>>> Don't get to hung-up with the syntax (I knocked this together in 2 min),
>>>>> but the general idea would be something like:
>>>>>
>>>>>            InputStream is = new FileInputStream("keycloak.json");
>>>>>
>>>>>            KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
>>>>>
>>>>>            // get login url
>>>>>            URL loginUrl = client.createLoginUrl(redirectUri);
>>>>>
>>>>>            // exchange code to token
>>>>>            AccessTokenResponse response = client.getToken(code,
>>>>>            clientCredentials);
>>>>>
>>>>>            // refresh token
>>>>>            client.refreshToken(response.getToken());
>>>>>
>>>>> We have most of the code, but what we don't is a public Java API.
>>>>> _______________________________________________
>>>>> 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
>>

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

From bburke at redhat.com  Tue Sep 16 10:15:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 10:15:33 -0400
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <54184084.9000107@redhat.com>
References: <54180C43.7080508@redhat.com>	<1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>
	<54184084.9000107@redhat.com>
Message-ID: <54184605.3000005@redhat.com>

There are multiple cookies that have different purposes.  The remember 
me cookie might be a legacy thing that we needed prior to having a user 
session.  We needed a way to propagate that the user clicked "remember 
me" if there was an account action that needed to take place or if OTP 
was enabled.  This cookie may not be needed anymore because UserSessions 
are so core to what we're doing.

We have two keycloak identity cookies.  One is persistent, secure, and 
HttpOnly and contains a digitally signed access token.   This is used to 
authenticate a user.  The other identity cookie is session only, 
non-persistent, can be propagated from Javascript (not HttpOnly) and is 
used solely with the Keycloak.js library to determine if the user is 
still logged in.  (the iframe stuff).

On 9/16/2014 9:52 AM, Marek Posolda wrote:
> On 16.9.2014 12:28, Stian Thorgersen wrote:
>> To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.
> yeah. But besides validity of the KEYCLOAK_IDENTITY cookie, I would say
> that identityToken tight to the cookie should be set to
> ssoSessionMaxLifespan as well?
>
> Fact is that KEYCLOAK_IDENTITY cookie is tight to the UserSession. But
> KEYCLOAK_IDENTITY cookie is refreshed just during SSO login, when
> UserSession.setLastSessionRefresh is called either during SSO login or
> refreshing token. This could lead to the situation when UserSession is
> still valid, but token from KEYCLOAK_IDENTITY cookie is expired, hence
> user is logged out even he has valid UserSession (my example 1 from
> previous mail) .
>
>>
>> With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).
> Maybe yes. My understanding of rememberMe is that you may need to
> automatically login from your browser even after very long time (in
> days), hence I meant to not tight it to UserSession. But maybe it's just
> me:-)
>
> I meant to address stuff like logout of all sessions from acct
> management with the persistent rememberMe records. So when someone wants
> to logout all sessions, it would clear rememberMe records too (Similarly
> when realm.notBefore is set by admin or other similar actions). It would
> be quite amount of work and model, so if we can live with tight
> automatic relogin just to UserSession, it's fine with me.
>>
>> As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.
> ah, ok. So KEYCLOAK_REMEMBER_ME cookie will be used just as a 'hint' to
> prefil login form then? I can add support for this though. As actually
> KEYCLOAK_REMEMBER_ME cookie is not used for anything.
>
> Marek
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 16 September, 2014 12:09:07 PM
>>> Subject: [keycloak-dev] Cookies & RememberMe clarification
>>>
>>> Have few questions related to cookies & rememberMe.
>>>
>>> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
>>> default (so expires when browser is closed). Thing is that lifespan of
>>> the identityToken generated in AuthenticationManager.createIdentityToken
>>> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
>>> cookie is refreshed just during cookie SSO login. So for example when I
>>> have scenario like:
>>> * Login to admin console
>>> * Do some admin work for 15 minutes
>>> * Then click to "Manage my account" button (or to some other Keycloak
>>> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
>>> valid anymore, so I am immediately logged out. Note that UserSession is
>>> still valid as I had couple of refreshToken requests during my 15
>>> minutes 'admin' work.
>>>
>>> So my question is if we can use ssoSessionMaxLifespan for the identity
>>> token instead of ssoSessionIdleTimeout? Note that even in cookie
>>> authentication, we are also checking if UserSession is valid. So if
>>> UserSession is expired, the login won't be successful anyway.
>>>
>>> 2) Second thing is RememberMe feature. Actually we have
>>> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
>>> rememberMe. But this cookie is actually not used anywhere for relogin!
>>> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
>>> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
>>> cookie will survive and you will be able to relogin.
>>>
>>> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
>>> for example if I have scenario like:
>>> * Login to admin console
>>> * Close my browser and wait 15 minutes
>>> * Then open my browser and try to relogin --- ATM both UserSession and
>>> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
>>> work and Keycloak login screen is displayed to me.
>>>
>>> Also scenario like:
>>> * Login to admin console
>>> * Close my browser and restart Keycloak
>>> * Then open my browser and try to relogin --- rememberMe also won't work
>>> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
>>> UserSession provider).
>>>
>>> IMO RememberMe shouldn't be tight to particular UserSession. I would
>>> expect that when I start browser next day, I will be automatically
>>> logged in even if my UserSession from previous day is already expired.
>>>
>>> It seems that to properly support RememberMe, we should use
>>> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
>>> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
>>> privateKey and valid just for one use (Each RememberMe login will
>>> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
>>> This would mean that we will need to persist stuff related to rememberMe
>>> with some additional related informations (realm, user, timestamp,
>>> ipAddress). So for example if admin will set Not-Before for realm, it
>>> will also invalidate all stored rememberMe tokens.
>>>
>>> It seems that this will require some model changes and amount of work,
>>> but ATM RememberMe feature seems to be quite unusable to me.
>>>
>>> wdyt?
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Sep 16 10:17:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 10:17:41 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <54184099.9020006@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>	<54183DA8.9070904@redhat.com>
	<54184099.9020006@redhat.com>
Message-ID: <54184685.3020404@redhat.com>



On 9/16/2014 9:52 AM, Stan Silvert wrote:
> On 9/16/2014 9:39 AM, Bill Burke wrote:
>>
>> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>>> WildFly 9 introduces features packs which seams ideal for us to build Keycloak upon.
>>>
>>> I'd like to start a "wildfly-9" branch of Keycloak that uses feature-packs and WildFly's built in mechanism to create the appliance distro. This would replace our current custom appliance-dist. Further I'd like us to have two flavours of Keycloak:
>>>
>>> * "appliance-lite": minimum Keycloak server only dist. For those that want a standalone Keycloak server. Builds on WildFly "web-lite" dist, but we need to add Hibernate, RestEasy and Connectors (datasources) as well
>>> * "appliance": full WildFly dist. For those that want to co-locate their JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>>>
>> We've discussed this before.
>>
>> The downside to a stripped down keycloak distro is the examples can't
>> run out of the box anymore and users will have to  download a full
>> Wildfly distro anyways and also configure it to run on different ports.
>>     They will have to edit example config files to point to the correct
>> ports.  Basically a lot more work to get things up and running for the
>> first time.
>>
> Hmm.  Perhaps the examples will be packaged as its own feature pack.
>
> A feature pack might make it even easier to get up and running. Today
> you still have to download the appliance, boot the server, import the
> test realm, and then build and deploy the examples.  I'd like to get rid
> of those steps.
>
> I think a lot of this depends on how good the provisioning tool turns
> out to be.

The screencast tutorials require you to manually create the realm and 
manually configure the applications.


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

From mposolda at redhat.com  Tue Sep 16 10:25:43 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Sep 2014 16:25:43 +0200
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <54184605.3000005@redhat.com>
References: <54180C43.7080508@redhat.com>	<1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>	<54184084.9000107@redhat.com>
	<54184605.3000005@redhat.com>
Message-ID: <54184867.3060005@redhat.com>

On 16.9.2014 16:15, Bill Burke wrote:
> There are multiple cookies that have different purposes.  The remember
> me cookie might be a legacy thing that we needed prior to having a user
> session.  We needed a way to propagate that the user clicked "remember
> me" if there was an account action that needed to take place or if OTP
> was enabled.  This cookie may not be needed anymore because UserSessions
> are so core to what we're doing.
yes, looks like it's purely legacy as it's not used for anything now. We 
can either remove this cookie completely (and all the code related to 
it) or use it for 'prefill' the login form as Stian proposed.
>
> We have two keycloak identity cookies.  One is persistent, secure, and
> HttpOnly and contains a digitally signed access token.   This is used to
> authenticate a user.  The other identity cookie is session only,
> non-persistent, can be propagated from Javascript (not HttpOnly) and is
> used solely with the Keycloak.js library to determine if the user is
> still logged in.  (the iframe stuff).
yep, I know. What I am proposing is increase lifespan of identityToken 
attached to KEYCLOAK_IDENTITY 
(AuthenticationManager.createIdentityToken) to ssoSessionMaxLifespan 
instead of ssoSessionIdleTimeout. As currently it could happen that you 
are logged-out even if your UserSession is still valid (example 1 from 
my first mail).

Marek
>
> On 9/16/2014 9:52 AM, Marek Posolda wrote:
>> On 16.9.2014 12:28, Stian Thorgersen wrote:
>>> To me there's only one problem here and that's the validity of the KEYCLOAK_IDENTITY cookie. As you say that should be set to ssoSessionMaxLifespan if remember-me is enabled for the user session.
>> yeah. But besides validity of the KEYCLOAK_IDENTITY cookie, I would say
>> that identityToken tight to the cookie should be set to
>> ssoSessionMaxLifespan as well?
>>
>> Fact is that KEYCLOAK_IDENTITY cookie is tight to the UserSession. But
>> KEYCLOAK_IDENTITY cookie is refreshed just during SSO login, when
>> UserSession.setLastSessionRefresh is called either during SSO login or
>> refreshing token. This could lead to the situation when UserSession is
>> still valid, but token from KEYCLOAK_IDENTITY cookie is expired, hence
>> user is logged out even he has valid UserSession (my example 1 from
>> previous mail) .
>>
>>> With regards to remember-me it should be linked to a user session as it is now. Directly tying it to a session allows users and admins to logout remotely (there's an option in account management to logout all sessions), and also allows admins to configure sensible expiration for sessions. If someone wants long lived user sessions they should set the SsoSessionIdleTimeout and SsoSessionMaxLifespan accordingly (for example 1 day and 30 days respectively).
>> Maybe yes. My understanding of rememberMe is that you may need to
>> automatically login from your browser even after very long time (in
>> days), hence I meant to not tight it to UserSession. But maybe it's just
>> me:-)
>>
>> I meant to address stuff like logout of all sessions from acct
>> management with the persistent rememberMe records. So when someone wants
>> to logout all sessions, it would clear rememberMe records too (Similarly
>> when realm.notBefore is set by admin or other similar actions). It would
>> be quite amount of work and model, so if we can live with tight
>> automatic relogin just to UserSession, it's fine with me.
>>> As it stands we don't even need the remember me cookie AFAIK. However, One improvement we should do is add the username/email to the REMEMBER_ME cookie. The REMEMBER_ME cookie should be set to never expire. Then when a users sessions expires we can pre-fill the username/email and the remember-me checkbox.
>> ah, ok. So KEYCLOAK_REMEMBER_ME cookie will be used just as a 'hint' to
>> prefil login form then? I can add support for this though. As actually
>> KEYCLOAK_REMEMBER_ME cookie is not used for anything.
>>
>> Marek
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 16 September, 2014 12:09:07 PM
>>>> Subject: [keycloak-dev] Cookies & RememberMe clarification
>>>>
>>>> Have few questions related to cookies & rememberMe.
>>>>
>>>> 1) Actually the KEYCLOAK_IDENTITY cookie is generated with the -1 by
>>>> default (so expires when browser is closed). Thing is that lifespan of
>>>> the identityToken generated in AuthenticationManager.createIdentityToken
>>>> is just ssoSessionIdleTimeout, which is 10 minutes by default. And
>>>> cookie is refreshed just during cookie SSO login. So for example when I
>>>> have scenario like:
>>>> * Login to admin console
>>>> * Do some admin work for 15 minutes
>>>> * Then click to "Manage my account" button (or to some other Keycloak
>>>> secured application), the token in the KEYCLOAK_IDENTITY cookie is not
>>>> valid anymore, so I am immediately logged out. Note that UserSession is
>>>> still valid as I had couple of refreshToken requests during my 15
>>>> minutes 'admin' work.
>>>>
>>>> So my question is if we can use ssoSessionMaxLifespan for the identity
>>>> token instead of ssoSessionIdleTimeout? Note that even in cookie
>>>> authentication, we are also checking if UserSession is valid. So if
>>>> UserSession is expired, the login won't be successful anyway.
>>>>
>>>> 2) Second thing is RememberMe feature. Actually we have
>>>> KEYCLOAK_REMEMBER_ME cookie, which is set after successful login with
>>>> rememberMe. But this cookie is actually not used anywhere for relogin!
>>>> Only thing is KEYCLOAK_IDENTITY cookie set with the lifespan of
>>>> ssoSessionIdleTimeout, so once you restart browser, KEYCLOAK_IDENTITY
>>>> cookie will survive and you will be able to relogin.
>>>>
>>>> Problem is that KEYCLOAK_IDENTITY is tight to particular UserSession. So
>>>> for example if I have scenario like:
>>>> * Login to admin console
>>>> * Close my browser and wait 15 minutes
>>>> * Then open my browser and try to relogin --- ATM both UserSession and
>>>> KEYCLOAK_IDENTITY cookie are not valid anymore so rememberMe doesn't
>>>> work and Keycloak login screen is displayed to me.
>>>>
>>>> Also scenario like:
>>>> * Login to admin console
>>>> * Close my browser and restart Keycloak
>>>> * Then open my browser and try to relogin --- rememberMe also won't work
>>>> as UserSession is not valid (unless I am using 'jpa' or 'mongo'
>>>> UserSession provider).
>>>>
>>>> IMO RememberMe shouldn't be tight to particular UserSession. I would
>>>> expect that when I start browser next day, I will be automatically
>>>> logged in even if my UserSession from previous day is already expired.
>>>>
>>>> It seems that to properly support RememberMe, we should use
>>>> KEYCLOAK_REMEMBER_ME cookie instead of KEYCLOAK_IDENTITY . IMO value of
>>>> KEYCLOAK_REMEMBER_ME cookie should be random token signed by realm
>>>> privateKey and valid just for one use (Each RememberMe login will
>>>> regenerate token and refresh value of KEYCLOAK_REMEMBER_ME cookie) .
>>>> This would mean that we will need to persist stuff related to rememberMe
>>>> with some additional related informations (realm, user, timestamp,
>>>> ipAddress). So for example if admin will set Not-Before for realm, it
>>>> will also invalidate all stored rememberMe tokens.
>>>>
>>>> It seems that this will require some model changes and amount of work,
>>>> but ATM RememberMe feature seems to be quite unusable to me.
>>>>
>>>> wdyt?
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Tue Sep 16 10:31:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 10:31:48 -0400
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <54184867.3060005@redhat.com>
References: <54180C43.7080508@redhat.com>	<1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>	<54184084.9000107@redhat.com>
	<54184605.3000005@redhat.com> <54184867.3060005@redhat.com>
Message-ID: <541849D4.6010406@redhat.com>



On 9/16/2014 10:25 AM, Marek Posolda wrote:
> On 16.9.2014 16:15, Bill Burke wrote:
>> There are multiple cookies that have different purposes.  The remember
>> me cookie might be a legacy thing that we needed prior to having a user
>> session.  We needed a way to propagate that the user clicked "remember
>> me" if there was an account action that needed to take place or if OTP
>> was enabled.  This cookie may not be needed anymore because UserSessions
>> are so core to what we're doing.
> yes, looks like it's purely legacy as it's not used for anything now. We
> can either remove this cookie completely (and all the code related to
> it) or use it for 'prefill' the login form as Stian proposed.
>>
>> We have two keycloak identity cookies.  One is persistent, secure, and
>> HttpOnly and contains a digitally signed access token.   This is used to
>> authenticate a user.  The other identity cookie is session only,
>> non-persistent, can be propagated from Javascript (not HttpOnly) and is
>> used solely with the Keycloak.js library to determine if the user is
>> still logged in.  (the iframe stuff).
> yep, I know. What I am proposing is increase lifespan of identityToken
> attached to KEYCLOAK_IDENTITY
> (AuthenticationManager.createIdentityToken) to ssoSessionMaxLifespan
> instead of ssoSessionIdleTimeout. As currently it could happen that you
> are logged-out even if your UserSession is still valid (example 1 from
> my first mail).
>

Again, probably a legacy thing why it is implemented the way its 
implemented.  Cookie authentication just needs to check the session to 
see if has been idle too long.



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

From ssilvert at redhat.com  Tue Sep 16 16:03:37 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 16:03:37 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
Message-ID: <54189799.9090206@redhat.com>

I have a prototype working and I think I've got the lay of the land.  
Now I need help to make design decisions.  (BTW, every time I say 
WildFly I mean WildFly or EAP)

*Background*
Deployment to the /deployments directory is generally discouraged, 
especially in production environments.  In a domain configuration, it is 
impossible because there is no deployment scanner and no /deployments 
directory.  Today, if you want to use the Keycloak Auth Server in a 
domain, you must upload the WAR to the content repository and assign it 
to one or more server groups.

This not only adds extra installation steps, it complicates management 
of the auth server.  The auth server could be assigned to WildFly 
instances where Keycloak modules are not installed. Furthermore, WildFly 
administrators with highly restricted roles in the web console and CLI 
would have too much control over the auth server deployment.  IMO, only 
Administrator or higher should be able to control the auth server 
deployment. [1]

*Subsystem-based Deployment*
The Keycloak Auth Server can instead be deployed as part of the Keycloak 
Subsystem[2].  The plan is to make subsystem deployment an option on 
both standalone and domain installations.  This makes the Auth Server 
into more of a service instead of an end-user application.

*Questions and Design Decisions*
The Auth Server WAR will live in its own module.  Is there any reason 
for it to be in exploded form?

The Keycloak Subsystem will get a new resource called "auth-server".  
Right now I only plan to have one attribute called "enabled".  By 
default, this will be false in a domain environment. You don't want an 
auth server to boot everywhere you install the keycloak subsystem.  Do 
we want this to be true for standalone?  In other words, should the auth 
server automatically boot if the keycloak subsystem is installed on 
standalone?

Are there any other attributes to add?  The Keycloak subsystem can do 
anything it wants to the auth server at deployment time.  It can change 
context params, add modules, boot in some kind of admin-only mode, or 
anything else.  Configuration settings on the WAR could be made from 
standalone.xml, domain.xml, CLI, etc.  Anything you would like the 
subsystem to do?

Do I need to allow for multiple auth server deployments in the same 
WildFly instance?  This is quite easy to do.  For the second instance, 
it would override the module name of the auth server WAR.

What are the plans and considerations for clustered auth server? 
Anything I should be aware of at this point?

[1] 
http://planet.jboss.org/post/role_based_access_control_in_wildfly_8_tech_tip_120
[2] See "A Mixed Apporach" https://developer.jboss.org/wiki/ExtendingAS7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140916/f7ce3f43/attachment-0001.html 

From bburke at redhat.com  Tue Sep 16 16:13:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 16 Sep 2014 16:13:16 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <54189799.9090206@redhat.com>
References: <54189799.9090206@redhat.com>
Message-ID: <541899DC.4040106@redhat.com>



On 9/16/2014 4:03 PM, Stan Silvert wrote:
> *Questions and Design Decisions*
> The Auth Server WAR will live in its own module.  Is there any reason
> for it to be in exploded form?
>

We have exploded form so that user can plug in their own custom user 
federation providers and other plugin SPIs.  These providers are scanned 
for in the classpath using the META-INF/services pattern.

> The Keycloak Subsystem will get a new resource called "auth-server".
> Right now I only plan to have one attribute called "enabled".  By
> default, this will be false in a domain environment. You don't want an
> auth server to boot everywhere you install the keycloak subsystem.  Do
> we want this to be true for standalone?  In other words, should the auth
> server automatically boot if the keycloak subsystem is installed on
> standalone?
>

Why wouldn't it boot?  What is the plan for distributing Keycloak?


> Are there any other attributes to add?  The Keycloak subsystem can do
> anything it wants to the auth server at deployment time.  It can change
> context params, add modules, boot in some kind of admin-only mode, or
> anything else.  Configuration settings on the WAR could be made from
> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
> subsystem to do?
>


there is a keycloak-server.json file.  Maybe that should be configurable 
in the subsystem too.


> Do I need to allow for multiple auth server deployments in the same
> WildFly instance?  This is quite easy to do.  For the second instance,
> it would override the module name of the auth server WAR.
>

I'm sure there is some weird user that will want to do this.  But I 
don't think this will be the norm, do you?

> What are the plans and considerations for clustered auth server?
> Anything I should be aware of at this point?
>

Might need infinispan configured for clustering going forward.


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

From mposolda at redhat.com  Tue Sep 16 16:16:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Sep 2014 22:16:07 +0200
Subject: [keycloak-dev] Cookies & RememberMe clarification
In-Reply-To: <541849D4.6010406@redhat.com>
References: <54180C43.7080508@redhat.com>	<1080889079.50281165.1410863316508.JavaMail.zimbra@redhat.com>	<54184084.9000107@redhat.com>
	<54184605.3000005@redhat.com> <54184867.3060005@redhat.com>
	<541849D4.6010406@redhat.com>
Message-ID: <54189A87.7@redhat.com>

Thanks for the confirm. I've changed it this way and also changed 
KEYCLOAK_REMEMBER_ME cookie to prefill login form.

Marek

On 16.9.2014 16:31, Bill Burke wrote:
> Again, probably a legacy thing why it is implemented the way its 
> implemented.  Cookie authentication just needs to check the session to 
> see if has been idle too long.
>
>
>
> -- 


From ssilvert at redhat.com  Tue Sep 16 20:13:07 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 16 Sep 2014 20:13:07 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <541899DC.4040106@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
Message-ID: <5418D213.4070609@redhat.com>

On 9/16/2014 4:13 PM, Bill Burke wrote:
>
> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>> *Questions and Design Decisions*
>> The Auth Server WAR will live in its own module.  Is there any reason
>> for it to be in exploded form?
>>
> We have exploded form so that user can plug in their own custom user
> federation providers and other plugin SPIs.  These providers are scanned
> for in the classpath using the META-INF/services pattern.
They could (should?) install the plugin as a module and expose the 
services from there.  But for now I'll use exploded form.
>
>> The Keycloak Subsystem will get a new resource called "auth-server".
>> Right now I only plan to have one attribute called "enabled".  By
>> default, this will be false in a domain environment. You don't want an
>> auth server to boot everywhere you install the keycloak subsystem.  Do
>> we want this to be true for standalone?  In other words, should the auth
>> server automatically boot if the keycloak subsystem is installed on
>> standalone?
>>
> Why wouldn't it boot?  What is the plan for distributing Keycloak?
You don't want the auth server to boot if you are just using the 
subsystem for clients.  But now that I think about it, I've answered my 
own question.  Whether or not the auth server is enabled is something 
that can be defined when you add the Keycloak feature pack.  So you 
could set the default to whatever you want depending on the situation.

I'm not sure I understand your question about distribution.  With the 
feature pack, Keycloak can be added when a server is first assembled or 
Keycloak can be added on later.  The feature pack lives in the Maven 
repo.  For example, the WildFly full build will use the Keycloak FP to 
add Keycloak and make it part of its download.  The WildFly web build 
probably won't include Keycloak, but you can use the feature pack to add 
it later.

Feature Pack = module references + configuration XML + extra content
>
>
>> Are there any other attributes to add?  The Keycloak subsystem can do
>> anything it wants to the auth server at deployment time.  It can change
>> context params, add modules, boot in some kind of admin-only mode, or
>> anything else.  Configuration settings on the WAR could be made from
>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>> subsystem to do?
>>
>
> there is a keycloak-server.json file.  Maybe that should be configurable
> in the subsystem too.
OK.  I'll take a look at that.  Should be very similar to what we do for 
clients configured by the subsystem.
>
>
>> Do I need to allow for multiple auth server deployments in the same
>> WildFly instance?  This is quite easy to do.  For the second instance,
>> it would override the module name of the auth server WAR.
>>
> I'm sure there is some weird user that will want to do this.  But I
> don't think this will be the norm, do you?
No, not the norm.  Would there be a scenario where someone wanted to 
have prod and test instances of the auth server inside the same WildFly 
instance?  Or maybe someone wants a single WildFly instance to host two 
auth servers from unrelated entities?
>
>> What are the plans and considerations for clustered auth server?
>> Anything I should be aware of at this point?
>>
> Might need infinispan configured for clustering going forward.
>
>


From stian at redhat.com  Wed Sep 17 03:07:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 03:07:25 -0400 (EDT)
Subject: [keycloak-dev] Adapters
In-Reply-To: <5418412A.50300@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
	<952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
	<541836BC.4090205@redhat.com>
	<1168081435.50362026.1410873312152.JavaMail.zimbra@redhat.com>
	<5418412A.50300@redhat.com>
Message-ID: <76697932.50762794.1410937645526.JavaMail.zimbra@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, 16 September, 2014 3:54:50 PM
> Subject: Re: [keycloak-dev] Adapters
> 
> 
> 
> On 9/16/2014 9:15 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: Tuesday, 16 September, 2014 3:10:20 PM
> >> Subject: Re: [keycloak-dev] Adapters
> >>
> >> I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty,
> >> node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect
> >> libraries are only a fallback plan.
> >
> > Who is going to implement and maintain all those adapters? I just can't see
> > us having enough man-power to do that. Especially if we start venturing
> > into non-java land.
> >
> 
> You're starting to sound like a whiny product manager instead of
> somebody that wants a successful keycloak project. :)

You're wrong, I'm a whiny developer ;)

I give in, but we'll have to automate testing of all these adapters. I'm going to sink into depression if I have to manually test all of this for every release...

> 
> We're just going to have to do it.  Having an IAM that only works well
> in a JBoss ecosystem is unacceptable, IMO.  LIke I said, most of the
> logic in Java is in a common core adapter library already.  People are
> already demanding Tomcat support.  Netty won't be far behind.
> 
> These integration requirements are just going to become worse and worse.
>   We just have to deal with it if we want to succeed.
> 
> >>
> >> Also, we can't rely on third-party libs for the reasons I mentioned
> >> below.  Bearer auth is also implementation dependent because tokens are
> >> opaque in oauth/openid specs.  So any rest service is going to have to
> >> understand our token format and extract and validate the JWS.
> >
> > What parts of the token are non-standard other than the roles? OAuth2 has a
> > standard param for roles 'scope', couldn't we use that?
> >
> 
> 
> Token formats are not standardized at all, not even around JWT.  Go read
> oauth2/openid connect.  Access tokens (and codes) are completely opaque.
>   I even had a talk with somebody on Oauth-WG about this as I wanted to
> standardize our CORS stuff.  He told me that nobody will ever agree on
> the token format.  At least not at this point in time.  Also scope has
> nothing to do with roles.  Scope doesn't solve bearer auth token
> validation problem.

I thought there was a standard 'scope' param in the jwt, but looks like I'm wrong.

I might need to brush up on these specs, and now I'm also going to have to read about SAML

> 
> >>
> >>
> >>
> >> On 9/16/2014 7:59 AM, Stian Thorgersen wrote:
> >>> What I was hoping to be able to achieve was a pure Java adapter, with an
> >>> easy to use and well documented API. This would allow anyone to use
> >>> Keycloak from anything Java. Most of the code is there, but we can
> >>> clean-up the API IMO, and also provide some examples and documentation.
> >>>
> >>> Further, we'd provide a pure Servlet adapter. As you point out it can't
> >>> provide the same level of integration as our WildFly and AS7/EAP
> >>> adapters.
> >>> However, providing bespoke adapters for Tomcat, Jetty, etc. is going to
> >>> be
> >>> too much of an overhead, so I don't think we should provide bespoke
> >>> adapters for non Red Hat products.
> >>>
> >>> For mobile could just delegate to AeroGear. Ideally, AeroGear would
> >>> provide
> >>> the SDKs and documentation to use Keycloak with Android, iOS, Windows
> >>> Mobile, Firefox, etc. and we would just add references to AeroGear in our
> >>> documentation and webpage.
> >>>
> >>> For other programming languages (php, ruby, etc.) I'm less sure what we
> >>> can
> >>> achieve. Perhaps we can delegate to existing OpenID Connect client
> >>> libraries?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Monday, 15 September, 2014 5:17:35 PM
> >>>> Subject: Re: [keycloak-dev] Adapters
> >>>>
> >>>> Much of you want is already the reality, but there are some caveats you
> >>>> must know about:
> >>>>
> >>>> * Adapters need specific integration with each app server as they need
> >>>> to extract and set role mappings prior to the servlet container's roles
> >>>> allowed checks.  This can't be done in a filter.
> >>>>
> >>>> * Being able to propagate the Subject between component layers
> >>>> (Servlet->EJB) requires specific app server integration.
> >>>>
> >>>> * A keycloak logout invokes on adapter's admin url to invalidate the
> >>>> HTTP session.  The HTTP session invalidation is app server specific.
> >>>>
> >>>> * I don't believe you can obtain client cert information from the
> >>>> servlet API which will be come important when we add client-cert support
> >>>>
> >>>> Wildfly and JBossWeb have different integration SPIs for security, but
> >>>> most of the adapter code lives in a common library whose only dependency
> >>>> is Apache HTTP Client.  The core adapter library has a tiny Http message
> >>>> and http session mgmt facde to bridge between the two different
> >>>> containers.
> >>>>
> >>>> On 9/15/2014 10:38 AM, Stian Thorgersen wrote:
> >>>>> I think it would make sense to provide a plain Java adapter, as well as
> >>>>> a
> >>>>> plain Servlet adapter. Further this should be the base for all other
> >>>>> adapters.
> >>>>>
> >>>>>      +--------+ +---------+  +-----------+     +---------+
> >>>>>      | Tomcat | |JBoss AS |  |PicketLink |     | WildFly |
> >>>>>      | Jetty  | |JBoss EAP|  |           |     |         |
> >>>>>      | ...    | |         |  |           |     |         |
> >>>>>      +----+---+ +---+-----+  +---+-------+     +----+----+
> >>>>>           |         |            |                  |
> >>>>>           |     +---v-----+      |             +----v----+
> >>>>>           +----->Servlet  <------+             | Undertow|
> >>>>>                 |         |                    |         |
> >>>>>                 +----+----+                    +----+----+
> >>>>>                      |       +---------+            |
> >>>>>                      +------->Java     <------------+
> >>>>>                              |         |
> >>>>>                              +---------+
> >>>>>
> >>>>> The Java adapter should have minimum dependencies (maybe only
> >>>>> http-client?).
> >>>>>
> >>>>> Don't get to hung-up with the syntax (I knocked this together in 2
> >>>>> min),
> >>>>> but the general idea would be something like:
> >>>>>
> >>>>>            InputStream is = new FileInputStream("keycloak.json");
> >>>>>
> >>>>>            KeycloakOAuthClient client = KeycloakClient.createOAuth(is);
> >>>>>
> >>>>>            // get login url
> >>>>>            URL loginUrl = client.createLoginUrl(redirectUri);
> >>>>>
> >>>>>            // exchange code to token
> >>>>>            AccessTokenResponse response = client.getToken(code,
> >>>>>            clientCredentials);
> >>>>>
> >>>>>            // refresh token
> >>>>>            client.refreshToken(response.getToken());
> >>>>>
> >>>>> We have most of the code, but what we don't is a public Java API.
> >>>>> _______________________________________________
> >>>>> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Sep 17 03:26:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 03:26:51 -0400 (EDT)
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <54184685.3020404@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54183DA8.9070904@redhat.com> <54184099.9020006@redhat.com>
	<54184685.3020404@redhat.com>
Message-ID: <1944158275.50775380.1410938811692.JavaMail.zimbra@redhat.com>

Let me clarify what I'm proposing. I'm not proposing any changes to the contents of the appliance-dist.zip. It'll still contain:

* keycloak
* examples
* ...

Although, maybe we should have a separate server only download (would be more handy for provisioning), but that's another issue.

What I'm proposing is we change how we build the 'keycloak' part. Also, that we have two flavours of it available. One built on the WildFly web-lite (so it would be ~30MB) and another built on the full WildFly (150MB+).

Actually, I think my preference would be to have two downloads:

* Everything zip (not sure appliance-dist is the best name) - this would have Keycloak with full WildFly, would also contain examples and documentations
* Standalone server - this would have a standalone Keycloak server with web-lite WildFly

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 16 September, 2014 4:17:41 PM
> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
> 
> 
> 
> On 9/16/2014 9:52 AM, Stan Silvert wrote:
> > On 9/16/2014 9:39 AM, Bill Burke wrote:
> >>
> >> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
> >>> WildFly 9 introduces features packs which seams ideal for us to build
> >>> Keycloak upon.
> >>>
> >>> I'd like to start a "wildfly-9" branch of Keycloak that uses
> >>> feature-packs and WildFly's built in mechanism to create the appliance
> >>> distro. This would replace our current custom appliance-dist. Further
> >>> I'd like us to have two flavours of Keycloak:
> >>>
> >>> * "appliance-lite": minimum Keycloak server only dist. For those that
> >>> want a standalone Keycloak server. Builds on WildFly "web-lite" dist,
> >>> but we need to add Hibernate, RestEasy and Connectors (datasources) as
> >>> well
> >>> * "appliance": full WildFly dist. For those that want to co-locate their
> >>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
> >>>
> >> We've discussed this before.
> >>
> >> The downside to a stripped down keycloak distro is the examples can't
> >> run out of the box anymore and users will have to  download a full
> >> Wildfly distro anyways and also configure it to run on different ports.
> >>     They will have to edit example config files to point to the correct
> >> ports.  Basically a lot more work to get things up and running for the
> >> first time.
> >>
> > Hmm.  Perhaps the examples will be packaged as its own feature pack.
> >
> > A feature pack might make it even easier to get up and running. Today
> > you still have to download the appliance, boot the server, import the
> > test realm, and then build and deploy the examples.  I'd like to get rid
> > of those steps.
> >
> > I think a lot of this depends on how good the provisioning tool turns
> > out to be.
> 
> The screencast tutorials require you to manually create the realm and
> manually configure the applications.
> 
> 
> --
> 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 Sep 17 04:03:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 04:03:44 -0400 (EDT)
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <5418D213.4070609@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
	<5418D213.4070609@redhat.com>
Message-ID: <714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 2:13:07 AM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> 
> On 9/16/2014 4:13 PM, Bill Burke wrote:
> >
> > On 9/16/2014 4:03 PM, Stan Silvert wrote:
> >> *Questions and Design Decisions*
> >> The Auth Server WAR will live in its own module.  Is there any reason
> >> for it to be in exploded form?
> >>
> > We have exploded form so that user can plug in their own custom user
> > federation providers and other plugin SPIs.  These providers are scanned
> > for in the classpath using the META-INF/services pattern.
> They could (should?) install the plugin as a module and expose the
> services from there.  But for now I'll use exploded form.

I don't personally like the current way we add plugins to the auth-server.war. Would it be possible to "deploy" plugins in "deployments"? Alternatively have plugins added as modules, then either have the Keycloak subsystem automatically detect them on startup or require users to register them with Keycloak somehow.

> >
> >> The Keycloak Subsystem will get a new resource called "auth-server".
> >> Right now I only plan to have one attribute called "enabled".  By
> >> default, this will be false in a domain environment. You don't want an
> >> auth server to boot everywhere you install the keycloak subsystem.  Do
> >> we want this to be true for standalone?  In other words, should the auth
> >> server automatically boot if the keycloak subsystem is installed on
> >> standalone?
> >>
> > Why wouldn't it boot?  What is the plan for distributing Keycloak?
> You don't want the auth server to boot if you are just using the
> subsystem for clients.  But now that I think about it, I've answered my
> own question.  Whether or not the auth server is enabled is something
> that can be defined when you add the Keycloak feature pack.  So you
> could set the default to whatever you want depending on the situation.
> 
> I'm not sure I understand your question about distribution.  With the
> feature pack, Keycloak can be added when a server is first assembled or
> Keycloak can be added on later.  The feature pack lives in the Maven
> repo.  For example, the WildFly full build will use the Keycloak FP to
> add Keycloak and make it part of its download.  The WildFly web build
> probably won't include Keycloak, but you can use the feature pack to add
> it later.
> 
> Feature Pack = module references + configuration XML + extra content
> >
> >
> >> Are there any other attributes to add?  The Keycloak subsystem can do
> >> anything it wants to the auth server at deployment time.  It can change
> >> context params, add modules, boot in some kind of admin-only mode, or
> >> anything else.  Configuration settings on the WAR could be made from
> >> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
> >> subsystem to do?
> >>
> >
> > there is a keycloak-server.json file.  Maybe that should be configurable
> > in the subsystem too.
> OK.  I'll take a look at that.  Should be very similar to what we do for
> clients configured by the subsystem.

Would it not be best to drop 'keycloak-server.json' and configure it all from standalone/domain.xml?

> >
> >
> >> Do I need to allow for multiple auth server deployments in the same
> >> WildFly instance?  This is quite easy to do.  For the second instance,
> >> it would override the module name of the auth server WAR.
> >>
> > I'm sure there is some weird user that will want to do this.  But I
> > don't think this will be the norm, do you?
> No, not the norm.  Would there be a scenario where someone wanted to
> have prod and test instances of the auth server inside the same WildFly
> instance?  Or maybe someone wants a single WildFly instance to host two
> auth servers from unrelated entities?
> >
> >> What are the plans and considerations for clustered auth server?
> >> Anything I should be aware of at this point?
> >>
> > Might need infinispan configured for clustering going forward.
> >
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Wed Sep 17 06:46:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Sep 2014 12:46:33 +0200
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
Message-ID: <54196689.7050806@redhat.com>

I am thinking about scenario like this (assuming sessionIdleTimeout is 5 
minutes and cluster update period is 60 seconds) :
* User login at time 0
* At time 4:30 he refresh token, which will update lastSessionRefresh on 
his userSession. This will happen on cluster node1
* At time 5:15 he sends another refresh token request, which would be 
redirected by loadbalancer to node2 this time. Assuming that last 
cluster update from node1 to node2 happened at 4:20, so next update will 
happen at 5:20. So ATM node2 will see that session is idle for 5 minutes 
and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So 
node2 will logout session due to timeout.

So right now it seems safer to me to update lastSessionRefresh 
immediatelly to cluster. Or am I missing something?

I wonder if access to each UserSession can always happen just to same 
cluster node, but it seems that we won't be able to guarantee this . 
Even with sticky sessions, the communication from same user (and 
USerSession) can happen either via browser (SSO login to different 
application) or via back channel from adapters (refreshing tokens etc) 
and right now I am not seeing much way to guarantee sticky session 
between those .

Marek

On 15.9.2014 14:52, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 15 September, 2014 2:41:39 PM
>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>
>> Only works for session refreshes.  Also leaves an open window that the
>> user is still logged in after they log out.
> Yes, it's only for session refreshes, but IMO that's going to be the biggest traffic generator. For login and logouts we're going to have to send a message per event.
>
>> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
>>> Had an idea with regards to clustering and user sessions. Instead of
>>> sending messages to the cluster when a individual user session is
>>> refreshed all nodes send a periodic update message. Obviously that's only
>>> for user sessions and not for admin updates, where we should still send
>>> invalidation messages for each update.
>>>
>>> Each node would keep a note of all user sessions where it has updated
>>> LastSessionRefresh, and once every period it would send this list to all
>>> nodes. This should mean that instead of sending a message every time a
>>> single session is updated, we send a single message per node every 60
>>> seconds or so (should be configurable). When receiving a message from the
>>> cluster the node would go through the list and update the user sessions
>>> where the received LastSessionRefresh is higher than the one it has
>>> itself. Nodes still use the mem user sessions store, but with the cache on
>>> top.
>>> _______________________________________________
>>> 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


From stian at redhat.com  Wed Sep 17 07:03:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 07:03:14 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <54196689.7050806@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
Message-ID: <822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>

By far the most common request to Keycloak is going to be refreshing the token and if we're sending a message to the cluster for every token refresh it's just not going to scale very well. 

Will it even scale past 1 node?! Think about it, every refresh causes a request one node to handle one request from the client and send a message to the cluster, while all other nodes have to deal with a message from the cluster. It's going to increase availability, but not scalability.

So we're going to have to do something smarter than simply sending lastSessionRefresh every time.

Following your example I don't think it's a big deal that there's a window where the session is expired on one node, while not on another. We can always come up with a schema to improve that. Two alternatives we could do if a node detects a session as expired:

1. Ask the cluster if the session is expired, if at least one node says it's not expired it's not
2. Tell the cluster that the session is expired

Another solution we could consider is sharding. We have one or more front servers to the cluster which just delegate to a shard to process a request. Each shared handles one set of users and can consist of one or more nodes for increased availability. The front servers only need to know about the shards and members of a shard. This is probably the only solution that's going to scale to really big numbers, so might eventually be required.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 12:46:33 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> I am thinking about scenario like this (assuming sessionIdleTimeout is 5
> minutes and cluster update period is 60 seconds) :
> * User login at time 0
> * At time 4:30 he refresh token, which will update lastSessionRefresh on
> his userSession. This will happen on cluster node1
> * At time 5:15 he sends another refresh token request, which would be
> redirected by loadbalancer to node2 this time. Assuming that last
> cluster update from node1 to node2 happened at 4:20, so next update will
> happen at 5:20. So ATM node2 will see that session is idle for 5 minutes
> and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So
> node2 will logout session due to timeout.
> 
> So right now it seems safer to me to update lastSessionRefresh
> immediatelly to cluster. Or am I missing something?
> 
> I wonder if access to each UserSession can always happen just to same
> cluster node, but it seems that we won't be able to guarantee this .
> Even with sticky sessions, the communication from same user (and
> USerSession) can happen either via browser (SSO login to different
> application) or via back channel from adapters (refreshing tokens etc)
> and right now I am not seeing much way to guarantee sticky session
> between those .
> 
> Marek
> 
> On 15.9.2014 14:52, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 15 September, 2014 2:41:39 PM
> >> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>
> >> Only works for session refreshes.  Also leaves an open window that the
> >> user is still logged in after they log out.
> > Yes, it's only for session refreshes, but IMO that's going to be the
> > biggest traffic generator. For login and logouts we're going to have to
> > send a message per event.
> >
> >> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
> >>> Had an idea with regards to clustering and user sessions. Instead of
> >>> sending messages to the cluster when a individual user session is
> >>> refreshed all nodes send a periodic update message. Obviously that's only
> >>> for user sessions and not for admin updates, where we should still send
> >>> invalidation messages for each update.
> >>>
> >>> Each node would keep a note of all user sessions where it has updated
> >>> LastSessionRefresh, and once every period it would send this list to all
> >>> nodes. This should mean that instead of sending a message every time a
> >>> single session is updated, we send a single message per node every 60
> >>> seconds or so (should be configurable). When receiving a message from the
> >>> cluster the node would go through the list and update the user sessions
> >>> where the received LastSessionRefresh is higher than the one it has
> >>> itself. Nodes still use the mem user sessions store, but with the cache
> >>> on
> >>> top.
> >>> _______________________________________________
> >>> 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
> 
> 

From ssilvert at redhat.com  Wed Sep 17 08:23:12 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 Sep 2014 08:23:12 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
	<5418D213.4070609@redhat.com>
	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>
Message-ID: <54197D30.2080201@redhat.com>

On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>> *Questions and Design Decisions*
>>>> The Auth Server WAR will live in its own module.  Is there any reason
>>>> for it to be in exploded form?
>>>>
>>> We have exploded form so that user can plug in their own custom user
>>> federation providers and other plugin SPIs.  These providers are scanned
>>> for in the classpath using the META-INF/services pattern.
>> They could (should?) install the plugin as a module and expose the
>> services from there.  But for now I'll use exploded form.
> I don't personally like the current way we add plugins to the auth-server.war. Would it be possible to "deploy" plugins in "deployments"? Alternatively have plugins added as modules, then either have the Keycloak subsystem automatically detect them on startup or require users to register them with Keycloak somehow.
Anything is possible, but adding as a deployment is definitely not the 
way to go.  Deployments are for end-user applications.

Adding as a module is the cleanest way to do this but it requires a 
little more than just copying the jar to the file system.  So we're 
talking about either creating a module.xml by hand or using a tool.

Since there will soon be a keycloak-auth-server module, you could put 
the jar in that module and add an entry in that module.xml. That's 
probably a good compromise.
>
>>>> The Keycloak Subsystem will get a new resource called "auth-server".
>>>> Right now I only plan to have one attribute called "enabled".  By
>>>> default, this will be false in a domain environment. You don't want an
>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
>>>> we want this to be true for standalone?  In other words, should the auth
>>>> server automatically boot if the keycloak subsystem is installed on
>>>> standalone?
>>>>
>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
>> You don't want the auth server to boot if you are just using the
>> subsystem for clients.  But now that I think about it, I've answered my
>> own question.  Whether or not the auth server is enabled is something
>> that can be defined when you add the Keycloak feature pack.  So you
>> could set the default to whatever you want depending on the situation.
>>
>> I'm not sure I understand your question about distribution.  With the
>> feature pack, Keycloak can be added when a server is first assembled or
>> Keycloak can be added on later.  The feature pack lives in the Maven
>> repo.  For example, the WildFly full build will use the Keycloak FP to
>> add Keycloak and make it part of its download.  The WildFly web build
>> probably won't include Keycloak, but you can use the feature pack to add
>> it later.
>>
>> Feature Pack = module references + configuration XML + extra content
>>>
>>>> Are there any other attributes to add?  The Keycloak subsystem can do
>>>> anything it wants to the auth server at deployment time.  It can change
>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>> anything else.  Configuration settings on the WAR could be made from
>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>>>> subsystem to do?
>>>>
>>> there is a keycloak-server.json file.  Maybe that should be configurable
>>> in the subsystem too.
>> OK.  I'll take a look at that.  Should be very similar to what we do for
>> clients configured by the subsystem.
> Would it not be best to drop 'keycloak-server.json' and configure it all from standalone/domain.xml?
For WildFly/EAP deployments, I think this will become the preferred way 
of doing it.   We'll still need keycloak-server.json for other containers.
>
>>>
>>>> Do I need to allow for multiple auth server deployments in the same
>>>> WildFly instance?  This is quite easy to do.  For the second instance,
>>>> it would override the module name of the auth server WAR.
>>>>
>>> I'm sure there is some weird user that will want to do this.  But I
>>> don't think this will be the norm, do you?
>> No, not the norm.  Would there be a scenario where someone wanted to
>> have prod and test instances of the auth server inside the same WildFly
>> instance?  Or maybe someone wants a single WildFly instance to host two
>> auth servers from unrelated entities?
>>>> What are the plans and considerations for clustered auth server?
>>>> Anything I should be aware of at this point?
>>>>
>>> Might need infinispan configured for clustering going forward.
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Wed Sep 17 08:35:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 08:35:15 -0400 (EDT)
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <54197D30.2080201@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
	<5418D213.4070609@redhat.com>
	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>
	<54197D30.2080201@redhat.com>
Message-ID: <1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 2:23:12 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> 
> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 17 September, 2014 2:13:07 AM
> >> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> >>
> >> On 9/16/2014 4:13 PM, Bill Burke wrote:
> >>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
> >>>> *Questions and Design Decisions*
> >>>> The Auth Server WAR will live in its own module.  Is there any reason
> >>>> for it to be in exploded form?
> >>>>
> >>> We have exploded form so that user can plug in their own custom user
> >>> federation providers and other plugin SPIs.  These providers are scanned
> >>> for in the classpath using the META-INF/services pattern.
> >> They could (should?) install the plugin as a module and expose the
> >> services from there.  But for now I'll use exploded form.
> > I don't personally like the current way we add plugins to the
> > auth-server.war. Would it be possible to "deploy" plugins in
> > "deployments"? Alternatively have plugins added as modules, then either
> > have the Keycloak subsystem automatically detect them on startup or
> > require users to register them with Keycloak somehow.
> Anything is possible, but adding as a deployment is definitely not the
> way to go.  Deployments are for end-user applications.

Plugins are end-user things though, and it certainly would make it easier to develop plugins if you could do "mvn wildfly:deploy" ;)

> 
> Adding as a module is the cleanest way to do this but it requires a
> little more than just copying the jar to the file system.  So we're
> talking about either creating a module.xml by hand or using a tool.
> 
> Since there will soon be a keycloak-auth-server module, you could put
> the jar in that module and add an entry in that module.xml. That's
> probably a good compromise.

Whatever we do we should make it simple - we've already had complaints about having to copy a jar into standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and updating keycloak-auth-server module.xml is even more work. Also what happens when you upgrade the keycloak-auth-server module, wouldn't it loose the dependencies added by users?

> >
> >>>> The Keycloak Subsystem will get a new resource called "auth-server".
> >>>> Right now I only plan to have one attribute called "enabled".  By
> >>>> default, this will be false in a domain environment. You don't want an
> >>>> auth server to boot everywhere you install the keycloak subsystem.  Do
> >>>> we want this to be true for standalone?  In other words, should the auth
> >>>> server automatically boot if the keycloak subsystem is installed on
> >>>> standalone?
> >>>>
> >>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
> >> You don't want the auth server to boot if you are just using the
> >> subsystem for clients.  But now that I think about it, I've answered my
> >> own question.  Whether or not the auth server is enabled is something
> >> that can be defined when you add the Keycloak feature pack.  So you
> >> could set the default to whatever you want depending on the situation.
> >>
> >> I'm not sure I understand your question about distribution.  With the
> >> feature pack, Keycloak can be added when a server is first assembled or
> >> Keycloak can be added on later.  The feature pack lives in the Maven
> >> repo.  For example, the WildFly full build will use the Keycloak FP to
> >> add Keycloak and make it part of its download.  The WildFly web build
> >> probably won't include Keycloak, but you can use the feature pack to add
> >> it later.
> >>
> >> Feature Pack = module references + configuration XML + extra content
> >>>
> >>>> Are there any other attributes to add?  The Keycloak subsystem can do
> >>>> anything it wants to the auth server at deployment time.  It can change
> >>>> context params, add modules, boot in some kind of admin-only mode, or
> >>>> anything else.  Configuration settings on the WAR could be made from
> >>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
> >>>> subsystem to do?
> >>>>
> >>> there is a keycloak-server.json file.  Maybe that should be configurable
> >>> in the subsystem too.
> >> OK.  I'll take a look at that.  Should be very similar to what we do for
> >> clients configured by the subsystem.
> > Would it not be best to drop 'keycloak-server.json' and configure it all
> > from standalone/domain.xml?
> For WildFly/EAP deployments, I think this will become the preferred way
> of doing it.   We'll still need keycloak-server.json for other containers.
> >
> >>>
> >>>> Do I need to allow for multiple auth server deployments in the same
> >>>> WildFly instance?  This is quite easy to do.  For the second instance,
> >>>> it would override the module name of the auth server WAR.
> >>>>
> >>> I'm sure there is some weird user that will want to do this.  But I
> >>> don't think this will be the norm, do you?
> >> No, not the norm.  Would there be a scenario where someone wanted to
> >> have prod and test instances of the auth server inside the same WildFly
> >> instance?  Or maybe someone wants a single WildFly instance to host two
> >> auth servers from unrelated entities?
> >>>> What are the plans and considerations for clustered auth server?
> >>>> Anything I should be aware of at this point?
> >>>>
> >>> Might need infinispan configured for clustering going forward.
> >>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From mposolda at redhat.com  Wed Sep 17 09:03:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Sep 2014 15:03:56 +0200
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
Message-ID: <541986BC.9030607@redhat.com>

On 17.9.2014 13:03, Stian Thorgersen wrote:
> By far the most common request to Keycloak is going to be refreshing the token and if we're sending a message to the cluster for every token refresh it's just not going to scale very well.
Probably yes. Might be interesting to know the ratio between refresh 
requests and other requests in typical deployment though. It also 
depends on the environment and apps which will people use for keycloak. 
For example I am personally hardly spend more than 5 minutes on any web 
page (unless it's real-time work like writing some docs online etc)
>
> Will it even scale past 1 node?! Think about it, every refresh causes a request one node to handle one request from the client and send a message to the cluster, while all other nodes have to deal with a message from the cluster. It's going to increase availability, but not scalability.
>
> So we're going to have to do something smarter than simply sending lastSessionRefresh every time.
>
> Following your example I don't think it's a big deal that there's a window where the session is expired on one node, while not on another. We can always come up with a schema to improve that. Two alternatives we could do if a node detects a session as expired:
>
> 1. Ask the cluster if the session is expired, if at least one node says it's not expired it's not
> 2. Tell the cluster that the session is expired
yes, asking the cluster should help to avoid the window. Still the 
traffic might be quite big though. Especially with cluster with bigger 
number of nodes it could happen quite often that user is redirected 
every time on different node and hence it's bigger chance that 
UserSession might not be refreshed here. But I agree that it should 
likely reduce the traffic in most cases.
>
> Another solution we could consider is sharding. We have one or more front servers to the cluster which just delegate to a shard to process a request. Each shared handles one set of users and can consist of one or more nodes for increased availability. The front servers only need to know about the shards and members of a shard. This is probably the only solution that's going to scale to really big numbers, so might eventually be required.
Sharding will be great. Front servers would need to know to which server 
to send the request, which might be quite tricky thing though. Doing 
sharding based on usernames seems to best as UserSession will be created 
in shard group where user login. But in some requests (like refresh 
token request) you don't have access to username even in parsed token.

I wonder if we can add some additional info to requests, which will help 
front-servers/loadbalancers to recognize where to resend the request.

But anyway, I guess it's a priority after we have some basic clustering 
support?

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 12:46:33 PM
>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>
>> I am thinking about scenario like this (assuming sessionIdleTimeout is 5
>> minutes and cluster update period is 60 seconds) :
>> * User login at time 0
>> * At time 4:30 he refresh token, which will update lastSessionRefresh on
>> his userSession. This will happen on cluster node1
>> * At time 5:15 he sends another refresh token request, which would be
>> redirected by loadbalancer to node2 this time. Assuming that last
>> cluster update from node1 to node2 happened at 4:20, so next update will
>> happen at 5:20. So ATM node2 will see that session is idle for 5 minutes
>> and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So
>> node2 will logout session due to timeout.
>>
>> So right now it seems safer to me to update lastSessionRefresh
>> immediatelly to cluster. Or am I missing something?
>>
>> I wonder if access to each UserSession can always happen just to same
>> cluster node, but it seems that we won't be able to guarantee this .
>> Even with sticky sessions, the communication from same user (and
>> USerSession) can happen either via browser (SSO login to different
>> application) or via back channel from adapters (refreshing tokens etc)
>> and right now I am not seeing much way to guarantee sticky session
>> between those .
>>
>> Marek
>>
>> On 15.9.2014 14:52, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 15 September, 2014 2:41:39 PM
>>>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>>>
>>>> Only works for session refreshes.  Also leaves an open window that the
>>>> user is still logged in after they log out.
>>> Yes, it's only for session refreshes, but IMO that's going to be the
>>> biggest traffic generator. For login and logouts we're going to have to
>>> send a message per event.
>>>
>>>> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
>>>>> Had an idea with regards to clustering and user sessions. Instead of
>>>>> sending messages to the cluster when a individual user session is
>>>>> refreshed all nodes send a periodic update message. Obviously that's only
>>>>> for user sessions and not for admin updates, where we should still send
>>>>> invalidation messages for each update.
>>>>>
>>>>> Each node would keep a note of all user sessions where it has updated
>>>>> LastSessionRefresh, and once every period it would send this list to all
>>>>> nodes. This should mean that instead of sending a message every time a
>>>>> single session is updated, we send a single message per node every 60
>>>>> seconds or so (should be configurable). When receiving a message from the
>>>>> cluster the node would go through the list and update the user sessions
>>>>> where the received LastSessionRefresh is higher than the one it has
>>>>> itself. Nodes still use the mem user sessions store, but with the cache
>>>>> on
>>>>> top.
>>>>> _______________________________________________
>>>>> 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
>>


From ssilvert at redhat.com  Wed Sep 17 09:15:18 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 Sep 2014 09:15:18 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
	<5418D213.4070609@redhat.com>
	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>
	<54197D30.2080201@redhat.com>
	<1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>
Message-ID: <54198966.7000107@redhat.com>

On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>
>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>> *Questions and Design Decisions*
>>>>>> The Auth Server WAR will live in its own module.  Is there any reason
>>>>>> for it to be in exploded form?
>>>>>>
>>>>> We have exploded form so that user can plug in their own custom user
>>>>> federation providers and other plugin SPIs.  These providers are scanned
>>>>> for in the classpath using the META-INF/services pattern.
>>>> They could (should?) install the plugin as a module and expose the
>>>> services from there.  But for now I'll use exploded form.
>>> I don't personally like the current way we add plugins to the
>>> auth-server.war. Would it be possible to "deploy" plugins in
>>> "deployments"? Alternatively have plugins added as modules, then either
>>> have the Keycloak subsystem automatically detect them on startup or
>>> require users to register them with Keycloak somehow.
>> Anything is possible, but adding as a deployment is definitely not the
>> way to go.  Deployments are for end-user applications.
> Plugins are end-user things though, and it certainly would make it easier to develop plugins if you could do "mvn wildfly:deploy" ;)
I agree.  That's why the EAP team is working on tooling for that sort of 
thing.  Before WildFly/AS7, everything was a deployment. But we've 
changed that now to divide the world into applications and services.
>
>> Adding as a module is the cleanest way to do this but it requires a
>> little more than just copying the jar to the file system.  So we're
>> talking about either creating a module.xml by hand or using a tool.
>>
>> Since there will soon be a keycloak-auth-server module, you could put
>> the jar in that module and add an entry in that module.xml. That's
>> probably a good compromise.
> Whatever we do we should make it simple - we've already had complaints about having to copy a jar into standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and updating keycloak-auth-server module.xml is even more work. Also what happens when you upgrade the keycloak-auth-server module, wouldn't it loose the dependencies added by users?
If you upgrade by hand, it definitely won't lose anything.  How well it 
all works in the end will depend on how good the new provisioning tools 
are.  We can fill in the gaps with our own tools though.

If the requirement is to be able to upload the jar, we can accomplish 
that one way or the other.
>
>>>>>> The Keycloak Subsystem will get a new resource called "auth-server".
>>>>>> Right now I only plan to have one attribute called "enabled".  By
>>>>>> default, this will be false in a domain environment. You don't want an
>>>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
>>>>>> we want this to be true for standalone?  In other words, should the auth
>>>>>> server automatically boot if the keycloak subsystem is installed on
>>>>>> standalone?
>>>>>>
>>>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
>>>> You don't want the auth server to boot if you are just using the
>>>> subsystem for clients.  But now that I think about it, I've answered my
>>>> own question.  Whether or not the auth server is enabled is something
>>>> that can be defined when you add the Keycloak feature pack.  So you
>>>> could set the default to whatever you want depending on the situation.
>>>>
>>>> I'm not sure I understand your question about distribution.  With the
>>>> feature pack, Keycloak can be added when a server is first assembled or
>>>> Keycloak can be added on later.  The feature pack lives in the Maven
>>>> repo.  For example, the WildFly full build will use the Keycloak FP to
>>>> add Keycloak and make it part of its download.  The WildFly web build
>>>> probably won't include Keycloak, but you can use the feature pack to add
>>>> it later.
>>>>
>>>> Feature Pack = module references + configuration XML + extra content
>>>>>> Are there any other attributes to add?  The Keycloak subsystem can do
>>>>>> anything it wants to the auth server at deployment time.  It can change
>>>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>>>> anything else.  Configuration settings on the WAR could be made from
>>>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>>>>>> subsystem to do?
>>>>>>
>>>>> there is a keycloak-server.json file.  Maybe that should be configurable
>>>>> in the subsystem too.
>>>> OK.  I'll take a look at that.  Should be very similar to what we do for
>>>> clients configured by the subsystem.
>>> Would it not be best to drop 'keycloak-server.json' and configure it all
>>> from standalone/domain.xml?
>> For WildFly/EAP deployments, I think this will become the preferred way
>> of doing it.   We'll still need keycloak-server.json for other containers.
>>>>>> Do I need to allow for multiple auth server deployments in the same
>>>>>> WildFly instance?  This is quite easy to do.  For the second instance,
>>>>>> it would override the module name of the auth server WAR.
>>>>>>
>>>>> I'm sure there is some weird user that will want to do this.  But I
>>>>> don't think this will be the norm, do you?
>>>> No, not the norm.  Would there be a scenario where someone wanted to
>>>> have prod and test instances of the auth server inside the same WildFly
>>>> instance?  Or maybe someone wants a single WildFly instance to host two
>>>> auth servers from unrelated entities?
>>>>>> What are the plans and considerations for clustered auth server?
>>>>>> Anything I should be aware of at this point?
>>>>>>
>>>>> Might need infinispan configured for clustering going forward.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From stian at redhat.com  Wed Sep 17 09:15:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 09:15:38 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <541986BC.9030607@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<541986BC.9030607@redhat.com>
Message-ID: <221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:03:56 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> On 17.9.2014 13:03, Stian Thorgersen wrote:
> > By far the most common request to Keycloak is going to be refreshing the
> > token and if we're sending a message to the cluster for every token
> > refresh it's just not going to scale very well.
> Probably yes. Might be interesting to know the ratio between refresh
> requests and other requests in typical deployment though. It also
> depends on the environment and apps which will people use for keycloak.
> For example I am personally hardly spend more than 5 minutes on any web
> page (unless it's real-time work like writing some docs online etc)
> >
> > Will it even scale past 1 node?! Think about it, every refresh causes a
> > request one node to handle one request from the client and send a message
> > to the cluster, while all other nodes have to deal with a message from the
> > cluster. It's going to increase availability, but not scalability.
> >
> > So we're going to have to do something smarter than simply sending
> > lastSessionRefresh every time.
> >
> > Following your example I don't think it's a big deal that there's a window
> > where the session is expired on one node, while not on another. We can
> > always come up with a schema to improve that. Two alternatives we could do
> > if a node detects a session as expired:
> >
> > 1. Ask the cluster if the session is expired, if at least one node says
> > it's not expired it's not
> > 2. Tell the cluster that the session is expired
> yes, asking the cluster should help to avoid the window. Still the
> traffic might be quite big though. Especially with cluster with bigger
> number of nodes it could happen quite often that user is redirected
> every time on different node and hence it's bigger chance that
> UserSession might not be refreshed here. But I agree that it should
> likely reduce the traffic in most cases.

Question though, for initial clustering support would this inconsistency be OK? I think it would. Also, even if update interval was as low as 1 second it would probably generate much less traffic than one message per lastSessionRefresh. Obviously it would only send an update message if there was at least one session with updated lastSessionRefresh.

> >
> > Another solution we could consider is sharding. We have one or more front
> > servers to the cluster which just delegate to a shard to process a
> > request. Each shared handles one set of users and can consist of one or
> > more nodes for increased availability. The front servers only need to know
> > about the shards and members of a shard. This is probably the only
> > solution that's going to scale to really big numbers, so might eventually
> > be required.
> Sharding will be great. Front servers would need to know to which server
> to send the request, which might be quite tricky thing though. Doing
> sharding based on usernames seems to best as UserSession will be created
> in shard group where user login. But in some requests (like refresh
> token request) you don't have access to username even in parsed token.

Sorry, I didn't mean username I was thinking about user id.

> 
> I wonder if we can add some additional info to requests, which will help
> front-servers/loadbalancers to recognize where to resend the request.
> 
> But anyway, I guess it's a priority after we have some basic clustering
> support?

Absolutely, but it will significantly affect how we design clustering.

> 
> Marek
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 17 September, 2014 12:46:33 PM
> >> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>
> >> I am thinking about scenario like this (assuming sessionIdleTimeout is 5
> >> minutes and cluster update period is 60 seconds) :
> >> * User login at time 0
> >> * At time 4:30 he refresh token, which will update lastSessionRefresh on
> >> his userSession. This will happen on cluster node1
> >> * At time 5:15 he sends another refresh token request, which would be
> >> redirected by loadbalancer to node2 this time. Assuming that last
> >> cluster update from node1 to node2 happened at 4:20, so next update will
> >> happen at 5:20. So ATM node2 will see that session is idle for 5 minutes
> >> and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So
> >> node2 will logout session due to timeout.
> >>
> >> So right now it seems safer to me to update lastSessionRefresh
> >> immediatelly to cluster. Or am I missing something?
> >>
> >> I wonder if access to each UserSession can always happen just to same
> >> cluster node, but it seems that we won't be able to guarantee this .
> >> Even with sticky sessions, the communication from same user (and
> >> USerSession) can happen either via browser (SSO login to different
> >> application) or via back channel from adapters (refreshing tokens etc)
> >> and right now I am not seeing much way to guarantee sticky session
> >> between those .
> >>
> >> Marek
> >>
> >> On 15.9.2014 14:52, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Monday, 15 September, 2014 2:41:39 PM
> >>>> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>>>
> >>>> Only works for session refreshes.  Also leaves an open window that the
> >>>> user is still logged in after they log out.
> >>> Yes, it's only for session refreshes, but IMO that's going to be the
> >>> biggest traffic generator. For login and logouts we're going to have to
> >>> send a message per event.
> >>>
> >>>> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
> >>>>> Had an idea with regards to clustering and user sessions. Instead of
> >>>>> sending messages to the cluster when a individual user session is
> >>>>> refreshed all nodes send a periodic update message. Obviously that's
> >>>>> only
> >>>>> for user sessions and not for admin updates, where we should still send
> >>>>> invalidation messages for each update.
> >>>>>
> >>>>> Each node would keep a note of all user sessions where it has updated
> >>>>> LastSessionRefresh, and once every period it would send this list to
> >>>>> all
> >>>>> nodes. This should mean that instead of sending a message every time a
> >>>>> single session is updated, we send a single message per node every 60
> >>>>> seconds or so (should be configurable). When receiving a message from
> >>>>> the
> >>>>> cluster the node would go through the list and update the user sessions
> >>>>> where the received LastSessionRefresh is higher than the one it has
> >>>>> itself. Nodes still use the mem user sessions store, but with the cache
> >>>>> on
> >>>>> top.
> >>>>> _______________________________________________
> >>>>> 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
> >>
> 
> 

From stian at redhat.com  Wed Sep 17 09:19:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 09:19:05 -0400 (EDT)
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <54198966.7000107@redhat.com>
References: <54189799.9090206@redhat.com> <541899DC.4040106@redhat.com>
	<5418D213.4070609@redhat.com>
	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>
	<54197D30.2080201@redhat.com>
	<1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>
	<54198966.7000107@redhat.com>
Message-ID: <607808881.50961284.1410959945748.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:15:18 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> 
> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 17 September, 2014 2:23:12 PM
> >> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> >>
> >> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
> >>> ----- Original Message -----
> >>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
> >>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> >>>>
> >>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
> >>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
> >>>>>> *Questions and Design Decisions*
> >>>>>> The Auth Server WAR will live in its own module.  Is there any reason
> >>>>>> for it to be in exploded form?
> >>>>>>
> >>>>> We have exploded form so that user can plug in their own custom user
> >>>>> federation providers and other plugin SPIs.  These providers are
> >>>>> scanned
> >>>>> for in the classpath using the META-INF/services pattern.
> >>>> They could (should?) install the plugin as a module and expose the
> >>>> services from there.  But for now I'll use exploded form.
> >>> I don't personally like the current way we add plugins to the
> >>> auth-server.war. Would it be possible to "deploy" plugins in
> >>> "deployments"? Alternatively have plugins added as modules, then either
> >>> have the Keycloak subsystem automatically detect them on startup or
> >>> require users to register them with Keycloak somehow.
> >> Anything is possible, but adding as a deployment is definitely not the
> >> way to go.  Deployments are for end-user applications.
> > Plugins are end-user things though, and it certainly would make it easier
> > to develop plugins if you could do "mvn wildfly:deploy" ;)
> I agree.  That's why the EAP team is working on tooling for that sort of
> thing.  Before WildFly/AS7, everything was a deployment. But we've
> changed that now to divide the world into applications and services.
> >
> >> Adding as a module is the cleanest way to do this but it requires a
> >> little more than just copying the jar to the file system.  So we're
> >> talking about either creating a module.xml by hand or using a tool.
> >>
> >> Since there will soon be a keycloak-auth-server module, you could put
> >> the jar in that module and add an entry in that module.xml. That's
> >> probably a good compromise.
> > Whatever we do we should make it simple - we've already had complaints
> > about having to copy a jar into
> > standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
> > updating keycloak-auth-server module.xml is even more work. Also what
> > happens when you upgrade the keycloak-auth-server module, wouldn't it
> > loose the dependencies added by users?
> If you upgrade by hand, it definitely won't lose anything.  How well it
> all works in the end will depend on how good the new provisioning tools
> are.  We can fill in the gaps with our own tools though.
> 
> If the requirement is to be able to upload the jar, we can accomplish
> that one way or the other.

Ignoring the underlying details, it would be cool if we had a Maven plugin that could "deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed to make sure it's available.

> >
> >>>>>> The Keycloak Subsystem will get a new resource called "auth-server".
> >>>>>> Right now I only plan to have one attribute called "enabled".  By
> >>>>>> default, this will be false in a domain environment. You don't want an
> >>>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
> >>>>>> we want this to be true for standalone?  In other words, should the
> >>>>>> auth
> >>>>>> server automatically boot if the keycloak subsystem is installed on
> >>>>>> standalone?
> >>>>>>
> >>>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
> >>>> You don't want the auth server to boot if you are just using the
> >>>> subsystem for clients.  But now that I think about it, I've answered my
> >>>> own question.  Whether or not the auth server is enabled is something
> >>>> that can be defined when you add the Keycloak feature pack.  So you
> >>>> could set the default to whatever you want depending on the situation.
> >>>>
> >>>> I'm not sure I understand your question about distribution.  With the
> >>>> feature pack, Keycloak can be added when a server is first assembled or
> >>>> Keycloak can be added on later.  The feature pack lives in the Maven
> >>>> repo.  For example, the WildFly full build will use the Keycloak FP to
> >>>> add Keycloak and make it part of its download.  The WildFly web build
> >>>> probably won't include Keycloak, but you can use the feature pack to add
> >>>> it later.
> >>>>
> >>>> Feature Pack = module references + configuration XML + extra content
> >>>>>> Are there any other attributes to add?  The Keycloak subsystem can do
> >>>>>> anything it wants to the auth server at deployment time.  It can
> >>>>>> change
> >>>>>> context params, add modules, boot in some kind of admin-only mode, or
> >>>>>> anything else.  Configuration settings on the WAR could be made from
> >>>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
> >>>>>> subsystem to do?
> >>>>>>
> >>>>> there is a keycloak-server.json file.  Maybe that should be
> >>>>> configurable
> >>>>> in the subsystem too.
> >>>> OK.  I'll take a look at that.  Should be very similar to what we do for
> >>>> clients configured by the subsystem.
> >>> Would it not be best to drop 'keycloak-server.json' and configure it all
> >>> from standalone/domain.xml?
> >> For WildFly/EAP deployments, I think this will become the preferred way
> >> of doing it.   We'll still need keycloak-server.json for other containers.
> >>>>>> Do I need to allow for multiple auth server deployments in the same
> >>>>>> WildFly instance?  This is quite easy to do.  For the second instance,
> >>>>>> it would override the module name of the auth server WAR.
> >>>>>>
> >>>>> I'm sure there is some weird user that will want to do this.  But I
> >>>>> don't think this will be the norm, do you?
> >>>> No, not the norm.  Would there be a scenario where someone wanted to
> >>>> have prod and test instances of the auth server inside the same WildFly
> >>>> instance?  Or maybe someone wants a single WildFly instance to host two
> >>>> auth servers from unrelated entities?
> >>>>>> What are the plans and considerations for clustered auth server?
> >>>>>> Anything I should be aware of at this point?
> >>>>>>
> >>>>> Might need infinispan configured for clustering going forward.
> >>>>>
> >>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> 
> 

From mposolda at redhat.com  Wed Sep 17 09:46:21 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Sep 2014 15:46:21 +0200
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<541986BC.9030607@redhat.com>
	<221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>
Message-ID: <541990AD.4060005@redhat.com>

On 17.9.2014 15:15, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 3:03:56 PM
>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>
>> On 17.9.2014 13:03, Stian Thorgersen wrote:
>>> By far the most common request to Keycloak is going to be refreshing the
>>> token and if we're sending a message to the cluster for every token
>>> refresh it's just not going to scale very well.
>> Probably yes. Might be interesting to know the ratio between refresh
>> requests and other requests in typical deployment though. It also
>> depends on the environment and apps which will people use for keycloak.
>> For example I am personally hardly spend more than 5 minutes on any web
>> page (unless it's real-time work like writing some docs online etc)
>>> Will it even scale past 1 node?! Think about it, every refresh causes a
>>> request one node to handle one request from the client and send a message
>>> to the cluster, while all other nodes have to deal with a message from the
>>> cluster. It's going to increase availability, but not scalability.
>>>
>>> So we're going to have to do something smarter than simply sending
>>> lastSessionRefresh every time.
>>>
>>> Following your example I don't think it's a big deal that there's a window
>>> where the session is expired on one node, while not on another. We can
>>> always come up with a schema to improve that. Two alternatives we could do
>>> if a node detects a session as expired:
>>>
>>> 1. Ask the cluster if the session is expired, if at least one node says
>>> it's not expired it's not
>>> 2. Tell the cluster that the session is expired
>> yes, asking the cluster should help to avoid the window. Still the
>> traffic might be quite big though. Especially with cluster with bigger
>> number of nodes it could happen quite often that user is redirected
>> every time on different node and hence it's bigger chance that
>> UserSession might not be refreshed here. But I agree that it should
>> likely reduce the traffic in most cases.
> Question though, for initial clustering support would this inconsistency be OK? I think it would. Also, even if update interval was as low as 1 second it would probably generate much less traffic than one message per lastSessionRefresh. Obviously it would only send an update message if there was at least one session with updated lastSessionRefresh.
yeah, I think that it's ok as well as long as interval is configurable 
likely with some small value by default. Adding support for "asking 
cluster if session is really expired" shouldn't be so hard to add though..
>
>>> Another solution we could consider is sharding. We have one or more front
>>> servers to the cluster which just delegate to a shard to process a
>>> request. Each shared handles one set of users and can consist of one or
>>> more nodes for increased availability. The front servers only need to know
>>> about the shards and members of a shard. This is probably the only
>>> solution that's going to scale to really big numbers, so might eventually
>>> be required.
>> Sharding will be great. Front servers would need to know to which server
>> to send the request, which might be quite tricky thing though. Doing
>> sharding based on usernames seems to best as UserSession will be created
>> in shard group where user login. But in some requests (like refresh
>> token request) you don't have access to username even in parsed token.
> Sorry, I didn't mean username I was thinking about user id.
yeah, userId or sessionId will be great as it's random value and you 
have best shard equality. However I am not sure if you have this info. 
As typical scenario might be:
* User send request to display KC login page 
(/auth/realms/my-realm/tokens/login) - this is anonymous request, so 
front-server can redirect to any random shard group
* Once user confirms login form, front-server would need to recognize to 
which shard he send this request (POST to 
/auth/realms/my-realm/tokens/auth/request/login). Once he do it, 
UserSession will be created on this shard so subsequent requests should 
go there. But at the time of sending POST request, userId is not known 
to front-server. Unless front server are so clever, that they can lookup 
KC database (so in the end, they might need to have access to KC 
services too)
>
>> I wonder if we can add some additional info to requests, which will help
>> front-servers/loadbalancers to recognize where to resend the request.
>>
>> But anyway, I guess it's a priority after we have some basic clustering
>> support?
> Absolutely, but it will significantly affect how we design clustering.
>
>> Marek
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
>>>> <bburke at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 17 September, 2014 12:46:33 PM
>>>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>>>
>>>> I am thinking about scenario like this (assuming sessionIdleTimeout is 5
>>>> minutes and cluster update period is 60 seconds) :
>>>> * User login at time 0
>>>> * At time 4:30 he refresh token, which will update lastSessionRefresh on
>>>> his userSession. This will happen on cluster node1
>>>> * At time 5:15 he sends another refresh token request, which would be
>>>> redirected by loadbalancer to node2 this time. Assuming that last
>>>> cluster update from node1 to node2 happened at 4:20, so next update will
>>>> happen at 5:20. So ATM node2 will see that session is idle for 5 minutes
>>>> and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So
>>>> node2 will logout session due to timeout.
>>>>
>>>> So right now it seems safer to me to update lastSessionRefresh
>>>> immediatelly to cluster. Or am I missing something?
>>>>
>>>> I wonder if access to each UserSession can always happen just to same
>>>> cluster node, but it seems that we won't be able to guarantee this .
>>>> Even with sticky sessions, the communication from same user (and
>>>> USerSession) can happen either via browser (SSO login to different
>>>> application) or via back channel from adapters (refreshing tokens etc)
>>>> and right now I am not seeing much way to guarantee sticky session
>>>> between those .
>>>>
>>>> Marek
>>>>
>>>> On 15.9.2014 14:52, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Monday, 15 September, 2014 2:41:39 PM
>>>>>> Subject: Re: [keycloak-dev] Clustering and user sessions
>>>>>>
>>>>>> Only works for session refreshes.  Also leaves an open window that the
>>>>>> user is still logged in after they log out.
>>>>> Yes, it's only for session refreshes, but IMO that's going to be the
>>>>> biggest traffic generator. For login and logouts we're going to have to
>>>>> send a message per event.
>>>>>
>>>>>> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
>>>>>>> Had an idea with regards to clustering and user sessions. Instead of
>>>>>>> sending messages to the cluster when a individual user session is
>>>>>>> refreshed all nodes send a periodic update message. Obviously that's
>>>>>>> only
>>>>>>> for user sessions and not for admin updates, where we should still send
>>>>>>> invalidation messages for each update.
>>>>>>>
>>>>>>> Each node would keep a note of all user sessions where it has updated
>>>>>>> LastSessionRefresh, and once every period it would send this list to
>>>>>>> all
>>>>>>> nodes. This should mean that instead of sending a message every time a
>>>>>>> single session is updated, we send a single message per node every 60
>>>>>>> seconds or so (should be configurable). When receiving a message from
>>>>>>> the
>>>>>>> cluster the node would go through the list and update the user sessions
>>>>>>> where the received LastSessionRefresh is higher than the one it has
>>>>>>> itself. Nodes still use the mem user sessions store, but with the cache
>>>>>>> on
>>>>>>> top.
>>>>>>> _______________________________________________
>>>>>>> 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
>>


From bburke at redhat.com  Wed Sep 17 09:51:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Sep 2014 09:51:45 -0400
Subject: [keycloak-dev] Adapters
In-Reply-To: <76697932.50762794.1410937645526.JavaMail.zimbra@redhat.com>
References: <826559907.49778575.1410791924443.JavaMail.zimbra@redhat.com>
	<5417030F.6010606@redhat.com>
	<952227280.50310092.1410868745521.JavaMail.zimbra@redhat.com>
	<541836BC.4090205@redhat.com>
	<1168081435.50362026.1410873312152.JavaMail.zimbra@redhat.com>
	<5418412A.50300@redhat.com>
	<76697932.50762794.1410937645526.JavaMail.zimbra@redhat.com>
Message-ID: <541991F1.6000107@redhat.com>

On 9/17/2014 3:07 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: Tuesday, 16 September, 2014 3:54:50 PM
>> Subject: Re: [keycloak-dev] Adapters
>>
>>
>>
>> On 9/16/2014 9:15 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: Tuesday, 16 September, 2014 3:10:20 PM
>>>> Subject: Re: [keycloak-dev] Adapters
>>>>
>>>> I disagree.  We need to expand our adapters everywhere.  Tomcat, Jetty,
>>>> node.js, Rails, etc.  Pure servlet, pure Java, pure openid connect
>>>> libraries are only a fallback plan.
>>>
>>> Who is going to implement and maintain all those adapters? I just can't see
>>> us having enough man-power to do that. Especially if we start venturing
>>> into non-java land.
>>>
>>
>> You're starting to sound like a whiny product manager instead of
>> somebody that wants a successful keycloak project. :)
>
> You're wrong, I'm a whiny developer ;)
>
> I give in, but we'll have to automate testing of all these adapters. I'm going to sink into depression if I have to manually test all of this for every release...
>

Hey, I feel your pain.  I'm already manually testing on Chrome, FF, and 
IE, Wildfly and EAP 6.3 prior to releasing.  I"m not worried about the 
Java stuff.  Our Wildfly adapter is already integrated into our 
testsuite.  Really any Java-based adapter should be integratable with 
our testsuite.

> I might need to brush up on these specs, and now I'm also going to have to read about SAML
>

Hey, at least you're only reading about SAML.  I actually have to 
integrate with it. :(

Bill

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

From stian at redhat.com  Wed Sep 17 09:52:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 09:52:59 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <541990AD.4060005@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<541986BC.9030607@redhat.com>
	<221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>
	<541990AD.4060005@redhat.com>
Message-ID: <1289567352.50992189.1410961979513.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:46:21 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> On 17.9.2014 15:15, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 17 September, 2014 3:03:56 PM
> >> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>
> >> On 17.9.2014 13:03, Stian Thorgersen wrote:
> >>> By far the most common request to Keycloak is going to be refreshing the
> >>> token and if we're sending a message to the cluster for every token
> >>> refresh it's just not going to scale very well.
> >> Probably yes. Might be interesting to know the ratio between refresh
> >> requests and other requests in typical deployment though. It also
> >> depends on the environment and apps which will people use for keycloak.
> >> For example I am personally hardly spend more than 5 minutes on any web
> >> page (unless it's real-time work like writing some docs online etc)
> >>> Will it even scale past 1 node?! Think about it, every refresh causes a
> >>> request one node to handle one request from the client and send a message
> >>> to the cluster, while all other nodes have to deal with a message from
> >>> the
> >>> cluster. It's going to increase availability, but not scalability.
> >>>
> >>> So we're going to have to do something smarter than simply sending
> >>> lastSessionRefresh every time.
> >>>
> >>> Following your example I don't think it's a big deal that there's a
> >>> window
> >>> where the session is expired on one node, while not on another. We can
> >>> always come up with a schema to improve that. Two alternatives we could
> >>> do
> >>> if a node detects a session as expired:
> >>>
> >>> 1. Ask the cluster if the session is expired, if at least one node says
> >>> it's not expired it's not
> >>> 2. Tell the cluster that the session is expired
> >> yes, asking the cluster should help to avoid the window. Still the
> >> traffic might be quite big though. Especially with cluster with bigger
> >> number of nodes it could happen quite often that user is redirected
> >> every time on different node and hence it's bigger chance that
> >> UserSession might not be refreshed here. But I agree that it should
> >> likely reduce the traffic in most cases.
> > Question though, for initial clustering support would this inconsistency be
> > OK? I think it would. Also, even if update interval was as low as 1 second
> > it would probably generate much less traffic than one message per
> > lastSessionRefresh. Obviously it would only send an update message if
> > there was at least one session with updated lastSessionRefresh.
> yeah, I think that it's ok as well as long as interval is configurable
> likely with some small value by default. Adding support for "asking
> cluster if session is really expired" shouldn't be so hard to add though..
> >
> >>> Another solution we could consider is sharding. We have one or more front
> >>> servers to the cluster which just delegate to a shard to process a
> >>> request. Each shared handles one set of users and can consist of one or
> >>> more nodes for increased availability. The front servers only need to
> >>> know
> >>> about the shards and members of a shard. This is probably the only
> >>> solution that's going to scale to really big numbers, so might eventually
> >>> be required.
> >> Sharding will be great. Front servers would need to know to which server
> >> to send the request, which might be quite tricky thing though. Doing
> >> sharding based on usernames seems to best as UserSession will be created
> >> in shard group where user login. But in some requests (like refresh
> >> token request) you don't have access to username even in parsed token.
> > Sorry, I didn't mean username I was thinking about user id.
> yeah, userId or sessionId will be great as it's random value and you
> have best shard equality. However I am not sure if you have this info.
> As typical scenario might be:
> * User send request to display KC login page
> (/auth/realms/my-realm/tokens/login) - this is anonymous request, so
> front-server can redirect to any random shard group

No biggy - doesn't need user knowledge so can be sent to any server

> * Once user confirms login form, front-server would need to recognize to
> which shard he send this request (POST to
> /auth/realms/my-realm/tokens/auth/request/login). Once he do it,
> UserSession will be created on this shard so subsequent requests should
> go there. But at the time of sending POST request, userId is not known
> to front-server. Unless front server are so clever, that they can lookup
> KC database (so in the end, they might need to have access to KC
> services too)

Yeah, we would need to be able to somehow lookup userId based on username/email

> >
> >> I wonder if we can add some additional info to requests, which will help
> >> front-servers/loadbalancers to recognize where to resend the request.
> >>
> >> But anyway, I guess it's a priority after we have some basic clustering
> >> support?
> > Absolutely, but it will significantly affect how we design clustering.
> >
> >> Marek
> >>> ----- Original Message -----
> >>>> From: "Marek Posolda" <mposolda at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >>>> <bburke at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 17 September, 2014 12:46:33 PM
> >>>> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>>>
> >>>> I am thinking about scenario like this (assuming sessionIdleTimeout is 5
> >>>> minutes and cluster update period is 60 seconds) :
> >>>> * User login at time 0
> >>>> * At time 4:30 he refresh token, which will update lastSessionRefresh on
> >>>> his userSession. This will happen on cluster node1
> >>>> * At time 5:15 he sends another refresh token request, which would be
> >>>> redirected by loadbalancer to node2 this time. Assuming that last
> >>>> cluster update from node1 to node2 happened at 4:20, so next update will
> >>>> happen at 5:20. So ATM node2 will see that session is idle for 5 minutes
> >>>> and 15 seconds (as last refresh at 4:30 is not yet visible to node2). So
> >>>> node2 will logout session due to timeout.
> >>>>
> >>>> So right now it seems safer to me to update lastSessionRefresh
> >>>> immediatelly to cluster. Or am I missing something?
> >>>>
> >>>> I wonder if access to each UserSession can always happen just to same
> >>>> cluster node, but it seems that we won't be able to guarantee this .
> >>>> Even with sticky sessions, the communication from same user (and
> >>>> USerSession) can happen either via browser (SSO login to different
> >>>> application) or via back channel from adapters (refreshing tokens etc)
> >>>> and right now I am not seeing much way to guarantee sticky session
> >>>> between those .
> >>>>
> >>>> Marek
> >>>>
> >>>> On 15.9.2014 14:52, Stian Thorgersen wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Monday, 15 September, 2014 2:41:39 PM
> >>>>>> Subject: Re: [keycloak-dev] Clustering and user sessions
> >>>>>>
> >>>>>> Only works for session refreshes.  Also leaves an open window that the
> >>>>>> user is still logged in after they log out.
> >>>>> Yes, it's only for session refreshes, but IMO that's going to be the
> >>>>> biggest traffic generator. For login and logouts we're going to have to
> >>>>> send a message per event.
> >>>>>
> >>>>>> On 9/15/2014 8:28 AM, Stian Thorgersen wrote:
> >>>>>>> Had an idea with regards to clustering and user sessions. Instead of
> >>>>>>> sending messages to the cluster when a individual user session is
> >>>>>>> refreshed all nodes send a periodic update message. Obviously that's
> >>>>>>> only
> >>>>>>> for user sessions and not for admin updates, where we should still
> >>>>>>> send
> >>>>>>> invalidation messages for each update.
> >>>>>>>
> >>>>>>> Each node would keep a note of all user sessions where it has updated
> >>>>>>> LastSessionRefresh, and once every period it would send this list to
> >>>>>>> all
> >>>>>>> nodes. This should mean that instead of sending a message every time
> >>>>>>> a
> >>>>>>> single session is updated, we send a single message per node every 60
> >>>>>>> seconds or so (should be configurable). When receiving a message from
> >>>>>>> the
> >>>>>>> cluster the node would go through the list and update the user
> >>>>>>> sessions
> >>>>>>> where the received LastSessionRefresh is higher than the one it has
> >>>>>>> itself. Nodes still use the mem user sessions store, but with the
> >>>>>>> cache
> >>>>>>> on
> >>>>>>> top.
> >>>>>>> _______________________________________________
> >>>>>>> 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
> >>
> 
> 

From bburke at redhat.com  Wed Sep 17 09:55:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Sep 2014 09:55:04 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <1944158275.50775380.1410938811692.JavaMail.zimbra@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54183DA8.9070904@redhat.com> <54184099.9020006@redhat.com>
	<54184685.3020404@redhat.com>
	<1944158275.50775380.1410938811692.JavaMail.zimbra@redhat.com>
Message-ID: <541992B8.3020407@redhat.com>

On 9/17/2014 3:26 AM, Stian Thorgersen wrote:
> Let me clarify what I'm proposing. I'm not proposing any changes to the contents of the appliance-dist.zip. It'll still contain:
>
> * keycloak
> * examples
> * ...
>
> Although, maybe we should have a separate server only download (would be more handy for provisioning), but that's another issue.
>
> What I'm proposing is we change how we build the 'keycloak' part. Also, that we have two flavours of it available. One built on the WildFly web-lite (so it would be ~30MB) and another built on the full WildFly (150MB+).
>
> Actually, I think my preference would be to have two downloads:
>
> * Everything zip (not sure appliance-dist is the best name) - this would have Keycloak with full WildFly, would also contain examples and documentations
> * Standalone server - this would have a standalone Keycloak server with web-lite WildFly
>

And :
* war-dist  for those that want to deploy Keycloak on EAP 6.x.
* If Stans integration works on EAP 6.x too, maybe have a subsystem dist 
so it can be deployed on EAP?


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

From bburke at redhat.com  Wed Sep 17 09:57:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Sep 2014 09:57:49 -0400
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
Message-ID: <5419935D.2080705@redhat.com>



On 9/17/2014 7:03 AM, Stian Thorgersen wrote:
> By far the most common request to Keycloak is going to be refreshing the token and if we're sending a message to the cluster for every token refresh it's just not going to scale very well.
>
> Will it even scale past 1 node?! Think about it, every refresh causes a request one node to handle one request from the client and send a message to the cluster, while all other nodes have to deal with a message from the cluster. It's going to increase availability, but not scalability.
>
> So we're going to have to do something smarter than simply sending lastSessionRefresh every time.
>
> Following your example I don't think it's a big deal that there's a window where the session is expired on one node, while not on another. We can always come up with a schema to improve that. Two alternatives we could do if a node detects a session as expired:
>
> 1. Ask the cluster if the session is expired, if at least one node says it's not expired it's not
> 2. Tell the cluster that the session is expired
>
> Another solution we could consider is sharding. We have one or more front servers to the cluster which just delegate to a shard to process a request. Each shared handles one set of users and can consist of one or more nodes for increased availability. The front servers only need to know about the shards and members of a shard. This is probably the only solution that's going to scale to really big numbers, so might eventually be required.
>

For sharding, you'd also have to change our architecture.  When the 
client needs to change the code to a token, it is going to have to know 
which shard to communicate to.

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

From bburke at redhat.com  Wed Sep 17 09:59:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Sep 2014 09:59:01 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <607808881.50961284.1410959945748.JavaMail.zimbra@redhat.com>
References: <54189799.9090206@redhat.com>
	<541899DC.4040106@redhat.com>	<5418D213.4070609@redhat.com>	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>	<54197D30.2080201@redhat.com>	<1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>	<54198966.7000107@redhat.com>
	<607808881.50961284.1410959945748.JavaMail.zimbra@redhat.com>
Message-ID: <541993A5.5010202@redhat.com>

This conversation has become hard to follow.  Can you guys summarize 
what you've agreed to?

On 9/17/2014 9:19 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 3:15:18 PM
>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>
>> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>
>>>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>>>
>>>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>>>> *Questions and Design Decisions*
>>>>>>>> The Auth Server WAR will live in its own module.  Is there any reason
>>>>>>>> for it to be in exploded form?
>>>>>>>>
>>>>>>> We have exploded form so that user can plug in their own custom user
>>>>>>> federation providers and other plugin SPIs.  These providers are
>>>>>>> scanned
>>>>>>> for in the classpath using the META-INF/services pattern.
>>>>>> They could (should?) install the plugin as a module and expose the
>>>>>> services from there.  But for now I'll use exploded form.
>>>>> I don't personally like the current way we add plugins to the
>>>>> auth-server.war. Would it be possible to "deploy" plugins in
>>>>> "deployments"? Alternatively have plugins added as modules, then either
>>>>> have the Keycloak subsystem automatically detect them on startup or
>>>>> require users to register them with Keycloak somehow.
>>>> Anything is possible, but adding as a deployment is definitely not the
>>>> way to go.  Deployments are for end-user applications.
>>> Plugins are end-user things though, and it certainly would make it easier
>>> to develop plugins if you could do "mvn wildfly:deploy" ;)
>> I agree.  That's why the EAP team is working on tooling for that sort of
>> thing.  Before WildFly/AS7, everything was a deployment. But we've
>> changed that now to divide the world into applications and services.
>>>
>>>> Adding as a module is the cleanest way to do this but it requires a
>>>> little more than just copying the jar to the file system.  So we're
>>>> talking about either creating a module.xml by hand or using a tool.
>>>>
>>>> Since there will soon be a keycloak-auth-server module, you could put
>>>> the jar in that module and add an entry in that module.xml. That's
>>>> probably a good compromise.
>>> Whatever we do we should make it simple - we've already had complaints
>>> about having to copy a jar into
>>> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
>>> updating keycloak-auth-server module.xml is even more work. Also what
>>> happens when you upgrade the keycloak-auth-server module, wouldn't it
>>> loose the dependencies added by users?
>> If you upgrade by hand, it definitely won't lose anything.  How well it
>> all works in the end will depend on how good the new provisioning tools
>> are.  We can fill in the gaps with our own tools though.
>>
>> If the requirement is to be able to upload the jar, we can accomplish
>> that one way or the other.
>
> Ignoring the underlying details, it would be cool if we had a Maven plugin that could "deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed to make sure it's available.
>
>>>
>>>>>>>> The Keycloak Subsystem will get a new resource called "auth-server".
>>>>>>>> Right now I only plan to have one attribute called "enabled".  By
>>>>>>>> default, this will be false in a domain environment. You don't want an
>>>>>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
>>>>>>>> we want this to be true for standalone?  In other words, should the
>>>>>>>> auth
>>>>>>>> server automatically boot if the keycloak subsystem is installed on
>>>>>>>> standalone?
>>>>>>>>
>>>>>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
>>>>>> You don't want the auth server to boot if you are just using the
>>>>>> subsystem for clients.  But now that I think about it, I've answered my
>>>>>> own question.  Whether or not the auth server is enabled is something
>>>>>> that can be defined when you add the Keycloak feature pack.  So you
>>>>>> could set the default to whatever you want depending on the situation.
>>>>>>
>>>>>> I'm not sure I understand your question about distribution.  With the
>>>>>> feature pack, Keycloak can be added when a server is first assembled or
>>>>>> Keycloak can be added on later.  The feature pack lives in the Maven
>>>>>> repo.  For example, the WildFly full build will use the Keycloak FP to
>>>>>> add Keycloak and make it part of its download.  The WildFly web build
>>>>>> probably won't include Keycloak, but you can use the feature pack to add
>>>>>> it later.
>>>>>>
>>>>>> Feature Pack = module references + configuration XML + extra content
>>>>>>>> Are there any other attributes to add?  The Keycloak subsystem can do
>>>>>>>> anything it wants to the auth server at deployment time.  It can
>>>>>>>> change
>>>>>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>>>>>> anything else.  Configuration settings on the WAR could be made from
>>>>>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>>>>>>>> subsystem to do?
>>>>>>>>
>>>>>>> there is a keycloak-server.json file.  Maybe that should be
>>>>>>> configurable
>>>>>>> in the subsystem too.
>>>>>> OK.  I'll take a look at that.  Should be very similar to what we do for
>>>>>> clients configured by the subsystem.
>>>>> Would it not be best to drop 'keycloak-server.json' and configure it all
>>>>> from standalone/domain.xml?
>>>> For WildFly/EAP deployments, I think this will become the preferred way
>>>> of doing it.   We'll still need keycloak-server.json for other containers.
>>>>>>>> Do I need to allow for multiple auth server deployments in the same
>>>>>>>> WildFly instance?  This is quite easy to do.  For the second instance,
>>>>>>>> it would override the module name of the auth server WAR.
>>>>>>>>
>>>>>>> I'm sure there is some weird user that will want to do this.  But I
>>>>>>> don't think this will be the norm, do you?
>>>>>> No, not the norm.  Would there be a scenario where someone wanted to
>>>>>> have prod and test instances of the auth server inside the same WildFly
>>>>>> instance?  Or maybe someone wants a single WildFly instance to host two
>>>>>> auth servers from unrelated entities?
>>>>>>>> What are the plans and considerations for clustered auth server?
>>>>>>>> Anything I should be aware of at this point?
>>>>>>>>
>>>>>>> Might need infinispan configured for clustering going forward.
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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  Wed Sep 17 09:59:29 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 Sep 2014 09:59:29 -0400
Subject: [keycloak-dev] Appliance dist and WildFly feature packs
In-Reply-To: <541992B8.3020407@redhat.com>
References: <1812197479.50267515.1410861580599.JavaMail.zimbra@redhat.com>
	<54183DA8.9070904@redhat.com> <54184099.9020006@redhat.com>
	<54184685.3020404@redhat.com>
	<1944158275.50775380.1410938811692.JavaMail.zimbra@redhat.com>
	<541992B8.3020407@redhat.com>
Message-ID: <541993C1.5030700@redhat.com>

On 9/17/2014 9:55 AM, Bill Burke wrote:
> On 9/17/2014 3:26 AM, Stian Thorgersen wrote:
>> Let me clarify what I'm proposing. I'm not proposing any changes to the contents of the appliance-dist.zip. It'll still contain:
>>
>> * keycloak
>> * examples
>> * ...
>>
>> Although, maybe we should have a separate server only download (would be more handy for provisioning), but that's another issue.
>>
>> What I'm proposing is we change how we build the 'keycloak' part. Also, that we have two flavours of it available. One built on the WildFly web-lite (so it would be ~30MB) and another built on the full WildFly (150MB+).
>>
>> Actually, I think my preference would be to have two downloads:
>>
>> * Everything zip (not sure appliance-dist is the best name) - this would have Keycloak with full WildFly, would also contain examples and documentations
>> * Standalone server - this would have a standalone Keycloak server with web-lite WildFly
>>
> And :
> * war-dist  for those that want to deploy Keycloak on EAP 6.x.
> * If Stans integration works on EAP 6.x too, maybe have a subsystem dist
> so it can be deployed on EAP?
>
>
The subsystem should run fine on EAP 6.  But I don't know if feature 
packs will work with EAP 6 (kind of doubt it).  So it will be a manual 
install on EAP 6 just as we have today.

From stian at redhat.com  Wed Sep 17 09:59:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 09:59:32 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <5419935D.2080705@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<5419935D.2080705@redhat.com>
Message-ID: <517105094.50996860.1410962372398.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 3:57:49 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> 
> 
> On 9/17/2014 7:03 AM, Stian Thorgersen wrote:
> > By far the most common request to Keycloak is going to be refreshing the
> > token and if we're sending a message to the cluster for every token
> > refresh it's just not going to scale very well.
> >
> > Will it even scale past 1 node?! Think about it, every refresh causes a
> > request one node to handle one request from the client and send a message
> > to the cluster, while all other nodes have to deal with a message from the
> > cluster. It's going to increase availability, but not scalability.
> >
> > So we're going to have to do something smarter than simply sending
> > lastSessionRefresh every time.
> >
> > Following your example I don't think it's a big deal that there's a window
> > where the session is expired on one node, while not on another. We can
> > always come up with a schema to improve that. Two alternatives we could do
> > if a node detects a session as expired:
> >
> > 1. Ask the cluster if the session is expired, if at least one node says
> > it's not expired it's not
> > 2. Tell the cluster that the session is expired
> >
> > Another solution we could consider is sharding. We have one or more front
> > servers to the cluster which just delegate to a shard to process a
> > request. Each shared handles one set of users and can consist of one or
> > more nodes for increased availability. The front servers only need to know
> > about the shards and members of a shard. This is probably the only
> > solution that's going to scale to really big numbers, so might eventually
> > be required.
> >
> 
> For sharding, you'd also have to change our architecture.  When the
> client needs to change the code to a token, it is going to have to know
> which shard to communicate to.

Nopes, it talks to the a front-end server not the back-end shards. The front-end then delegates the request to one of the back-end servers.

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

From mposolda at redhat.com  Wed Sep 17 10:00:25 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Sep 2014 16:00:25 +0200
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <1289567352.50992189.1410961979513.JavaMail.zimbra@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<5416DE83.4010405@redhat.com>
	<1223342615.49650728.1410785566306.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<541986BC.9030607@redhat.com>
	<221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>
	<541990AD.4060005@redhat.com>
	<1289567352.50992189.1410961979513.JavaMail.zimbra@redhat.com>
Message-ID: <541993F9.1070508@redhat.com>

On 17.9.2014 15:52, Stian Thorgersen wrote:
>> yeah, userId or sessionId will be great as it's random value and you
>> >have best shard equality. However I am not sure if you have this info.
>> >As typical scenario might be:
>> >* User send request to display KC login page
>> >(/auth/realms/my-realm/tokens/login) - this is anonymous request, so
>> >front-server can redirect to any random shard group
> No biggy - doesn't need user knowledge so can be sent to any server
>
>> >* Once user confirms login form, front-server would need to recognize to
>> >which shard he send this request (POST to
>> >/auth/realms/my-realm/tokens/auth/request/login). Once he do it,
>> >UserSession will be created on this shard so subsequent requests should
>> >go there. But at the time of sending POST request, userId is not known
>> >to front-server. Unless front server are so clever, that they can lookup
>> >KC database (so in the end, they might need to have access to KC
>> >services too)
> Yeah, we would need to be able to somehow lookup userId based on username/email
>
yes, so front-servers might be something like proxy-servers with access 
to all keycloak services, but with slightly changed keycloak rest 
endpoints (Their only task would be to find correct shard for sending 
request). This should work.

Maybe there is some even better solution (adding some info to request to 
preserve something like sticky session), but I don't know yet...

Marek

From ssilvert at redhat.com  Wed Sep 17 13:15:20 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 Sep 2014 13:15:20 -0400
Subject: [keycloak-dev] Designing Auth Server startup from subsystem
In-Reply-To: <541993A5.5010202@redhat.com>
References: <54189799.9090206@redhat.com>
	<541899DC.4040106@redhat.com>	<5418D213.4070609@redhat.com>	<714719407.50793633.1410941024042.JavaMail.zimbra@redhat.com>	<54197D30.2080201@redhat.com>	<1539542850.50927519.1410957315281.JavaMail.zimbra@redhat.com>	<54198966.7000107@redhat.com>
	<607808881.50961284.1410959945748.JavaMail.zimbra@redhat.com>
	<541993A5.5010202@redhat.com>
Message-ID: <5419C1A8.30702@redhat.com>

On 9/17/2014 9:59 AM, Bill Burke wrote:
> This conversation has become hard to follow.  Can you guys summarize
> what you've agreed to?
I think I got my questions answered.  We veered into a discussion about 
how to deal with plugins.

The auth server will live in its own module and be deployed by the 
Keycloak subsystem.

Here are the options for dealing with plugins that use the 
META-INF/services pattern:
1)  Leave the WAR as exploded.  So it's the same as today except you 
drop your jar in the WAR in the module instead of the WAR in the 
/deployments directory.
2)  Put the jar in its own module and reference it from the Keycloak 
subsystem
3)  Put the jar in the same module as the auth server and add a line in 
module.xml for it.
4)  Use a tool to accomplish one of the first three.

I think that #1 and #3 will require no additional code.  So for the sake 
of getting this out sooner, we might want to pick one of those for the 
time being.

>
> On 9/17/2014 9:19 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 17 September, 2014 3:15:18 PM
>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>
>>> On 9/17/2014 8:35 AM, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Wednesday, 17 September, 2014 2:23:12 PM
>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>>
>>>>> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, 17 September, 2014 2:13:07 AM
>>>>>>> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
>>>>>>>
>>>>>>> On 9/16/2014 4:13 PM, Bill Burke wrote:
>>>>>>>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
>>>>>>>>> *Questions and Design Decisions*
>>>>>>>>> The Auth Server WAR will live in its own module.  Is there any reason
>>>>>>>>> for it to be in exploded form?
>>>>>>>>>
>>>>>>>> We have exploded form so that user can plug in their own custom user
>>>>>>>> federation providers and other plugin SPIs.  These providers are
>>>>>>>> scanned
>>>>>>>> for in the classpath using the META-INF/services pattern.
>>>>>>> They could (should?) install the plugin as a module and expose the
>>>>>>> services from there.  But for now I'll use exploded form.
>>>>>> I don't personally like the current way we add plugins to the
>>>>>> auth-server.war. Would it be possible to "deploy" plugins in
>>>>>> "deployments"? Alternatively have plugins added as modules, then either
>>>>>> have the Keycloak subsystem automatically detect them on startup or
>>>>>> require users to register them with Keycloak somehow.
>>>>> Anything is possible, but adding as a deployment is definitely not the
>>>>> way to go.  Deployments are for end-user applications.
>>>> Plugins are end-user things though, and it certainly would make it easier
>>>> to develop plugins if you could do "mvn wildfly:deploy" ;)
>>> I agree.  That's why the EAP team is working on tooling for that sort of
>>> thing.  Before WildFly/AS7, everything was a deployment. But we've
>>> changed that now to divide the world into applications and services.
>>>>> Adding as a module is the cleanest way to do this but it requires a
>>>>> little more than just copying the jar to the file system.  So we're
>>>>> talking about either creating a module.xml by hand or using a tool.
>>>>>
>>>>> Since there will soon be a keycloak-auth-server module, you could put
>>>>> the jar in that module and add an entry in that module.xml. That's
>>>>> probably a good compromise.
>>>> Whatever we do we should make it simple - we've already had complaints
>>>> about having to copy a jar into
>>>> standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and
>>>> updating keycloak-auth-server module.xml is even more work. Also what
>>>> happens when you upgrade the keycloak-auth-server module, wouldn't it
>>>> loose the dependencies added by users?
>>> If you upgrade by hand, it definitely won't lose anything.  How well it
>>> all works in the end will depend on how good the new provisioning tools
>>> are.  We can fill in the gaps with our own tools though.
>>>
>>> If the requirement is to be able to upload the jar, we can accomplish
>>> that one way or the other.
>> Ignoring the underlying details, it would be cool if we had a Maven plugin that could "deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed to make sure it's available.
>>
>>>>>>>>> The Keycloak Subsystem will get a new resource called "auth-server".
>>>>>>>>> Right now I only plan to have one attribute called "enabled".  By
>>>>>>>>> default, this will be false in a domain environment. You don't want an
>>>>>>>>> auth server to boot everywhere you install the keycloak subsystem.  Do
>>>>>>>>> we want this to be true for standalone?  In other words, should the
>>>>>>>>> auth
>>>>>>>>> server automatically boot if the keycloak subsystem is installed on
>>>>>>>>> standalone?
>>>>>>>>>
>>>>>>>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
>>>>>>> You don't want the auth server to boot if you are just using the
>>>>>>> subsystem for clients.  But now that I think about it, I've answered my
>>>>>>> own question.  Whether or not the auth server is enabled is something
>>>>>>> that can be defined when you add the Keycloak feature pack.  So you
>>>>>>> could set the default to whatever you want depending on the situation.
>>>>>>>
>>>>>>> I'm not sure I understand your question about distribution.  With the
>>>>>>> feature pack, Keycloak can be added when a server is first assembled or
>>>>>>> Keycloak can be added on later.  The feature pack lives in the Maven
>>>>>>> repo.  For example, the WildFly full build will use the Keycloak FP to
>>>>>>> add Keycloak and make it part of its download.  The WildFly web build
>>>>>>> probably won't include Keycloak, but you can use the feature pack to add
>>>>>>> it later.
>>>>>>>
>>>>>>> Feature Pack = module references + configuration XML + extra content
>>>>>>>>> Are there any other attributes to add?  The Keycloak subsystem can do
>>>>>>>>> anything it wants to the auth server at deployment time.  It can
>>>>>>>>> change
>>>>>>>>> context params, add modules, boot in some kind of admin-only mode, or
>>>>>>>>> anything else.  Configuration settings on the WAR could be made from
>>>>>>>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
>>>>>>>>> subsystem to do?
>>>>>>>>>
>>>>>>>> there is a keycloak-server.json file.  Maybe that should be
>>>>>>>> configurable
>>>>>>>> in the subsystem too.
>>>>>>> OK.  I'll take a look at that.  Should be very similar to what we do for
>>>>>>> clients configured by the subsystem.
>>>>>> Would it not be best to drop 'keycloak-server.json' and configure it all
>>>>>> from standalone/domain.xml?
>>>>> For WildFly/EAP deployments, I think this will become the preferred way
>>>>> of doing it.   We'll still need keycloak-server.json for other containers.
>>>>>>>>> Do I need to allow for multiple auth server deployments in the same
>>>>>>>>> WildFly instance?  This is quite easy to do.  For the second instance,
>>>>>>>>> it would override the module name of the auth server WAR.
>>>>>>>>>
>>>>>>>> I'm sure there is some weird user that will want to do this.  But I
>>>>>>>> don't think this will be the norm, do you?
>>>>>>> No, not the norm.  Would there be a scenario where someone wanted to
>>>>>>> have prod and test instances of the auth server inside the same WildFly
>>>>>>> instance?  Or maybe someone wants a single WildFly instance to host two
>>>>>>> auth servers from unrelated entities?
>>>>>>>>> What are the plans and considerations for clustered auth server?
>>>>>>>>> Anything I should be aware of at this point?
>>>>>>>>>
>>>>>>>> Might need infinispan configured for clustering going forward.
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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  Wed Sep 17 14:00:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Sep 2014 14:00:50 -0400 (EDT)
Subject: [keycloak-dev] Clustering and user sessions
In-Reply-To: <541993F9.1070508@redhat.com>
References: <130380586.49634250.1410784128110.JavaMail.zimbra@redhat.com>
	<54196689.7050806@redhat.com>
	<822439113.50881362.1410951794123.JavaMail.zimbra@redhat.com>
	<541986BC.9030607@redhat.com>
	<221974919.50957430.1410959738332.JavaMail.zimbra@redhat.com>
	<541990AD.4060005@redhat.com>
	<1289567352.50992189.1410961979513.JavaMail.zimbra@redhat.com>
	<541993F9.1070508@redhat.com>
Message-ID: <1109815888.51154512.1410976850916.JavaMail.zimbra@redhat.com>

I think we should do it in stages as we discussed today:

1. Check that clustering works with cache turned off and user sessions persisted to db - we should try using Docker + Fig
2. Add cache invalidation messages + replication of user sessions
3. Secure replication messages - there's no sensitive data being sent so signature should be sufficient
4. Address scalability

Let's have a chat tomorrow about how to split the work and a bit more discussion on how we'll do it. ATM I'm thinking using jgroups directly may be better in the long run than using Infinispan as it will give us a lot more control over what messages are sent. However, I don't know enough details about Infinispan to know what benefits it could give us and if we can get the control we'd like with that.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 4:00:25 PM
> Subject: Re: [keycloak-dev] Clustering and user sessions
> 
> On 17.9.2014 15:52, Stian Thorgersen wrote:
> >> yeah, userId or sessionId will be great as it's random value and you
> >> >have best shard equality. However I am not sure if you have this info.
> >> >As typical scenario might be:
> >> >* User send request to display KC login page
> >> >(/auth/realms/my-realm/tokens/login) - this is anonymous request, so
> >> >front-server can redirect to any random shard group
> > No biggy - doesn't need user knowledge so can be sent to any server
> >
> >> >* Once user confirms login form, front-server would need to recognize to
> >> >which shard he send this request (POST to
> >> >/auth/realms/my-realm/tokens/auth/request/login). Once he do it,
> >> >UserSession will be created on this shard so subsequent requests should
> >> >go there. But at the time of sending POST request, userId is not known
> >> >to front-server. Unless front server are so clever, that they can lookup
> >> >KC database (so in the end, they might need to have access to KC
> >> >services too)
> > Yeah, we would need to be able to somehow lookup userId based on
> > username/email
> >
> yes, so front-servers might be something like proxy-servers with access
> to all keycloak services, but with slightly changed keycloak rest
> endpoints (Their only task would be to find correct shard for sending
> request). This should work.
> 
> Maybe there is some even better solution (adding some info to request to
> preserve something like sticky session), but I don't know yet...
> 
> Marek
> 

From ssilvert at redhat.com  Wed Sep 17 15:15:54 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 17 Sep 2014 15:15:54 -0400
Subject: [keycloak-dev] keycloak-server.json
Message-ID: <5419DDEA.6000205@redhat.com>

Is there any updated doco on keycloak-server.json?  I need to know all 
the options and their possible values.  All I can find is this, but it's 
incomplete: 
https://github.com/keycloak/keycloak/wiki/keycloak-server.json-options

Stan

From stian at redhat.com  Thu Sep 18 00:43:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 18 Sep 2014 00:43:31 -0400 (EDT)
Subject: [keycloak-dev] keycloak-server.json
In-Reply-To: <5419DDEA.6000205@redhat.com>
References: <5419DDEA.6000205@redhat.com>
Message-ID: <79156121.51420171.1411015411812.JavaMail.zimbra@redhat.com>

No, I need to do that. I'll sort it out today. 

Schema for JSON would be nice ;)

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 17 September, 2014 9:15:54 PM
> Subject: [keycloak-dev] keycloak-server.json
> 
> Is there any updated doco on keycloak-server.json?  I need to know all
> the options and their possible values.  All I can find is this, but it's
> incomplete:
> https://github.com/keycloak/keycloak/wiki/keycloak-server.json-options
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Sep 18 13:49:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 18 Sep 2014 13:49:56 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.1 Final Released
In-Reply-To: <346688931.51908088.1411062563779.JavaMail.zimbra@redhat.com>
Message-ID: <283645111.51908422.1411062596314.JavaMail.zimbra@redhat.com>

We?re releasing a few minor fixes and improvements before we start work on SAML and Clustering.

For the complete list of fixes and improvements go to https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.0.1.Final%20AND%20resolution%20%3D%20Done


From lukas.fryc at gmail.com  Thu Sep 18 14:14:03 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Thu, 18 Sep 2014 20:14:03 +0200
Subject: [keycloak-dev] Keycloak Ionic / Cordova theme
Message-ID: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>

Hey guys,

I've started some work on a theme for Keycloak that would include Ionic
Framework styling.

This makes sure that Ionic/Cordova demos that includes Keycloak has smooth
transition between application and login process / registration.

See attached screenshots.

It's still in early prototypal stage, so just just login, registration and
social (only google) fully works so far, but others can be simply expanded.

Feel free to use it in demos or so... ;-)


Cheers,

~ Lukas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140918/bcc5c27f/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: login.png
Type: image/png
Size: 10430 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140918/bcc5c27f/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: register.png
Type: image/png
Size: 12041 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140918/bcc5c27f/attachment-0003.png 

From lukas.fryc at gmail.com  Thu Sep 18 14:19:24 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Thu, 18 Sep 2014 20:19:24 +0200
Subject: [keycloak-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
Message-ID: <CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>

Yeah and off course, the source is here:

https://github.com/lfryc/keycloak/tree/ionic-styling

On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? <lukas.fryc at gmail.com> wrote:

> Hey guys,
>
> I've started some work on a theme for Keycloak that would include Ionic
> Framework styling.
>
> This makes sure that Ionic/Cordova demos that includes Keycloak has smooth
> transition between application and login process / registration.
>
> See attached screenshots.
>
> It's still in early prototypal stage, so just just login, registration and
> social (only google) fully works so far, but others can be simply expanded.
>
> Feel free to use it in demos or so... ;-)
>
>
> Cheers,
>
> ~ Lukas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140918/7dca0f7b/attachment.html 

From bburke at redhat.com  Thu Sep 18 14:24:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Sep 2014 14:24:09 -0400
Subject: [keycloak-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
Message-ID: <541B2349.90404@redhat.com>

When you're done, let us know.  You and us should do a blog about it 
with screenshots and stuff.

On 9/18/2014 2:19 PM, Luk?? Fry? wrote:
> Yeah and off course, the source is here:
>
> https://github.com/lfryc/keycloak/tree/ionic-styling
>
> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? <lukas.fryc at gmail.com
> <mailto:lukas.fryc at gmail.com>> wrote:
>
>     Hey guys,
>
>     I've started some work on a theme for Keycloak that would include
>     Ionic Framework styling.
>
>     This makes sure that Ionic/Cordova demos that includes Keycloak has
>     smooth transition between application and login process / registration.
>
>     See attached screenshots.
>
>     It's still in early prototypal stage, so just just login,
>     registration and social (only google) fully works so far, but others
>     can be simply expanded.
>
>     Feel free to use it in demos or so... ;-)
>
>
>     Cheers,
>
>     ~ Lukas
>
>
>
>
> _______________________________________________
> 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 sblanc at redhat.com  Thu Sep 18 14:30:20 2014
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 18 Sep 2014 20:30:20 +0200
Subject: [keycloak-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <541B2349.90404@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<541B2349.90404@redhat.com>
Message-ID: <541B24BC.3010903@redhat.com>

For info I will showcase this at JavaOne ;)

On 18/09/14 20:24, Bill Burke wrote:
> When you're done, let us know.  You and us should do a blog about it
> with screenshots and stuff.
>
> On 9/18/2014 2:19 PM, Luk?? Fry? wrote:
>> Yeah and off course, the source is here:
>>
>> https://github.com/lfryc/keycloak/tree/ionic-styling
>>
>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? <lukas.fryc at gmail.com
>> <mailto:lukas.fryc at gmail.com>> wrote:
>>
>>      Hey guys,
>>
>>      I've started some work on a theme for Keycloak that would include
>>      Ionic Framework styling.
>>
>>      This makes sure that Ionic/Cordova demos that includes Keycloak has
>>      smooth transition between application and login process / registration.
>>
>>      See attached screenshots.
>>
>>      It's still in early prototypal stage, so just just login,
>>      registration and social (only google) fully works so far, but others
>>      can be simply expanded.
>>
>>      Feel free to use it in demos or so... ;-)
>>
>>
>>      Cheers,
>>
>>      ~ Lukas
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bgorai at cisco.com  Fri Sep 19 02:53:04 2014
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Fri, 19 Sep 2014 06:53:04 +0000
Subject: [keycloak-dev] Clarification on  Access Token and Refresh Token
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD055D8C3A@xmb-aln-x12.cisco.com>

Hi  Keycloak Dev Team,
First of all congrats to you guys with your 1.0 Final release.

We have an application configured in Keycloack as public client, which is accessed using a java client (httpclient). However we don't see access_token coming out of Resource server. So for the next call to Resource server, my client need to repeat authorization steps all over again (If we don't maintain session in client side , which is our requirement) . I understand for web client (web browser)  session id is used by keycloak adapter to establish the authenticity  of the client for consecutive resource access calls.


1.       Is there any way to get the access_token  in resource server response (may be as a cookie ) as resource server adapter is doing "code to token" ? So that successive call to resource server we can send the access_token .


2.       Actually in my setup Resource Server/Application is behind load balancer. So session id may not be valid for different node. Is there any way to configure application/resource server so that

a)      Client can get back the access token.

b)      Refresh can also happen automatically.


3.       As per my understanding, currently  keycloak stores access token /refresh token etc  in server http session.   If there is way to  persist access token /refresh token etc in data store so that

a.       Inactivity/session will not clear these data. (Can provide longevity)

b.      Resource Servers can use load balancer setup.


Thanks
Bappaditya Gorai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140919/49589799/attachment.html 

From stian at redhat.com  Fri Sep 19 03:43:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 03:43:02 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
Message-ID: <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>

This raises the question. Should we allow overriding the theme on an per-application basis?

It would allow a better integration with the app, but on the other side does it even make sense to login to a SSO realm that way?

----- Original Message -----
> From: "Erik Jan de Wit" <edewit at redhat.com>
> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 8:08:02 AM
> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> 
> Looks very nice, will this integrate well with the work that Summers did?
> 
> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
> 
> 
> 
> 
> Yeah and off course, the source is here:
> 
> https://github.com/lfryc/keycloak/tree/ionic-styling
> 
> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote:
> 
> 
> 
> Hey guys,
> 
> I've started some work on a theme for Keycloak that would include Ionic
> Framework styling.
> 
> This makes sure that Ionic/Cordova demos that includes Keycloak has smooth
> transition between application and login process / registration.
> 
> See attached screenshots.
> 
> It's still in early prototypal stage, so just just login, registration and
> social (only google) fully works so far, but others can be simply expanded.
> 
> Feel free to use it in demos or so... ;-)
> 
> 
> Cheers,
> 
> ~ Lukas
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From stian at redhat.com  Fri Sep 19 04:08:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 04:08:26 -0400 (EDT)
Subject: [keycloak-dev] Clarification on Access Token and Refresh Token
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD055D8C3A@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD055D8C3A@xmb-aln-x12.cisco.com>
Message-ID: <966980083.52229606.1411114106402.JavaMail.zimbra@redhat.com>

Hi,

I'm assuming you're using the WildFly adapter? It associates the token with the users http session. So you'd either need to replicate the sessions or use sticky sessions.

It would make sense to me to add an option to the adapter to make it stateless and use cookies instead of the http session to store the tokens. Added https://issues.jboss.org/browse/KEYCLOAK-702

----- Original Message -----
> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 8:53:04 AM
> Subject: [keycloak-dev] Clarification on  Access Token and Refresh Token
> 
> 
> 
> Hi Keycloak Dev Team,
> 
> First of all congrats to you guys with your 1.0 Final release.
> 
> 
> 
> We have an application configured in Keycloack as public client, which is
> accessed using a java client (httpclient). However we don?t see access_token
> coming out of Resource server. So for the next call to Resource server, my
> client need to repeat authorization steps all over again (If we don?t
> maintain session in client side , which is our requirement) . I understand
> for web client (web browser) session id is used by keycloak adapter to
> establish the authenticity of the client for consecutive resource access
> calls.
> 
> 
> 
> 1. Is there any way to get the access_token in resource server response (may
> be as a cookie ) as resource server adapter is doing ?code to token? ? So
> that successive call to resource server we can send the access_token .
> 
> 
> 
> 2. Actually in my setup Resource Server/Application is behind load balancer.
> So session id may not be valid for different node. Is there any way to
> configure application/resource server so that
> 
> a) Client can get back the access token.
> 
> b) Refresh can also happen automatically.
> 
> 
> 
> 3. As per my understanding, currently keycloak stores access token /refresh
> token etc in server http session. If there is way to persist access token
> /refresh token etc in data store so that
> 
> a. Inactivity/session will not clear these data. (Can provide longevity)
> 
> b. Resource Servers can use load balancer setup.
> 
> 
> 
> 
> 
> Thanks
> 
> Bappaditya Gorai
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From lukas at fryc.eu  Fri Sep 19 07:18:19 2014
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 19 Sep 2014 13:18:19 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
Message-ID: <CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>

IMHO the SSO endpoint could either detect an incoming client (that would be
rather complex)

or simply allow user client preference. Can we allow more than one theme
per realm and let the client app choose?

On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <stian at redhat.com> wrote:

> This raises the question. Should we allow overriding the theme on an
> per-application basis?
>
> It would allow a better integration with the app, but on the other side
> does it even make sense to login to a SSO realm that way?
>
> ----- Original Message -----
> > From: "Erik Jan de Wit" <edewit at redhat.com>
> > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 19 September, 2014 8:08:02 AM
> > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> >
> > Looks very nice, will this integrate well with the work that Summers did?
> >
> > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
> >
> >
> >
> >
> > Yeah and off course, the source is here:
> >
> > https://github.com/lfryc/keycloak/tree/ionic-styling
> >
> > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com >
> wrote:
> >
> >
> >
> > Hey guys,
> >
> > I've started some work on a theme for Keycloak that would include Ionic
> > Framework styling.
> >
> > This makes sure that Ionic/Cordova demos that includes Keycloak has
> smooth
> > transition between application and login process / registration.
> >
> > See attached screenshots.
> >
> > It's still in early prototypal stage, so just just login, registration
> and
> > social (only google) fully works so far, but others can be simply
> expanded.
> >
> > Feel free to use it in demos or so... ;-)
> >
> >
> > Cheers,
> >
> > ~ Lukas
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-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/20140919/8bdd7290/attachment.html 

From stian at redhat.com  Fri Sep 19 07:26:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 07:26:54 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
Message-ID: <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Luk?? Fry?" <lukas at fryc.eu>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>, keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 1:18:19 PM
> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> 
> IMHO the SSO endpoint could either detect an incoming client (that would be
> rather complex)
> 
> or simply allow user client preference. Can we allow more than one theme
> per realm and let the client app choohse?

Not sure what you mean, we always know which client is requesting the login (it's the client_id query param). The client should only be used for one variant of an application as well (so for an app that has a web, android and ios variants, there should be 3 clients configured in KC). So there's no problem providing an option to override the theme on a per-client basis.

> 
> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > This raises the question. Should we allow overriding the theme on an
> > per-application basis?
> >
> > It would allow a better integration with the app, but on the other side
> > does it even make sense to login to a SSO realm that way?
> >
> > ----- Original Message -----
> > > From: "Erik Jan de Wit" <edewit at redhat.com>
> > > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Friday, 19 September, 2014 8:08:02 AM
> > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> > >
> > > Looks very nice, will this integrate well with the work that Summers did?
> > >
> > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
> > >
> > >
> > >
> > >
> > > Yeah and off course, the source is here:
> > >
> > > https://github.com/lfryc/keycloak/tree/ionic-styling
> > >
> > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com >
> > wrote:
> > >
> > >
> > >
> > > Hey guys,
> > >
> > > I've started some work on a theme for Keycloak that would include Ionic
> > > Framework styling.
> > >
> > > This makes sure that Ionic/Cordova demos that includes Keycloak has
> > smooth
> > > transition between application and login process / registration.
> > >
> > > See attached screenshots.
> > >
> > > It's still in early prototypal stage, so just just login, registration
> > and
> > > social (only google) fully works so far, but others can be simply
> > expanded.
> > >
> > > Feel free to use it in demos or so... ;-)
> > >
> > >
> > > Cheers,
> > >
> > > ~ Lukas
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 


From lukas.fryc at gmail.com  Fri Sep 19 07:30:21 2014
From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 19 Sep 2014 13:30:21 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
Message-ID: <CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>

That would be awesome,

do I read correctly that it is not possible at the moment? Should I create
a feature request?

On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen <stian at redhat.com> wrote:

> ----- Original Message -----
> > From: "Luk?? Fry?" <lukas at fryc.eu>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> keycloak-dev at lists.jboss.org
> > Sent: Friday, 19 September, 2014 1:18:19 PM
> > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> >
> > IMHO the SSO endpoint could either detect an incoming client (that would
> be
> > rather complex)
> >
> > or simply allow user client preference. Can we allow more than one theme
> > per realm and let the client app choohse?
>
> Not sure what you mean, we always know which client is requesting the
> login (it's the client_id query param). The client should only be used for
> one variant of an application as well (so for an app that has a web,
> android and ios variants, there should be 3 clients configured in KC). So
> there's no problem providing an option to override the theme on a
> per-client basis.
>
> >
> > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > > This raises the question. Should we allow overriding the theme on an
> > > per-application basis?
> > >
> > > It would allow a better integration with the app, but on the other side
> > > does it even make sense to login to a SSO realm that way?
> > >
> > > ----- Original Message -----
> > > > From: "Erik Jan de Wit" <edewit at redhat.com>
> > > > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 19 September, 2014 8:08:02 AM
> > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> > > >
> > > > Looks very nice, will this integrate well with the work that Summers
> did?
> > > >
> > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > Yeah and off course, the source is here:
> > > >
> > > > https://github.com/lfryc/keycloak/tree/ionic-styling
> > > >
> > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com >
> > > wrote:
> > > >
> > > >
> > > >
> > > > Hey guys,
> > > >
> > > > I've started some work on a theme for Keycloak that would include
> Ionic
> > > > Framework styling.
> > > >
> > > > This makes sure that Ionic/Cordova demos that includes Keycloak has
> > > smooth
> > > > transition between application and login process / registration.
> > > >
> > > > See attached screenshots.
> > > >
> > > > It's still in early prototypal stage, so just just login,
> registration
> > > and
> > > > social (only google) fully works so far, but others can be simply
> > > expanded.
> > > >
> > > > Feel free to use it in demos or so... ;-)
> > > >
> > > >
> > > > Cheers,
> > > >
> > > > ~ Lukas
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-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/20140919/ca13adf7/attachment.html 

From stian at redhat.com  Fri Sep 19 07:40:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 07:40:17 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev]   Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
Message-ID: <2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>, keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 1:30:21 PM
> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova theme
> 
> That would be awesome,
> 
> do I read correctly that it is not possible at the moment? Should I create a
> feature request?

Currently we can only configure the theme on a per-realm basis. With the exception of css media-types there's not currently any way to modify the l&f based on client (or client type).

An alternative, which may make more sense, is to add multiple variants of a theme. So for example you could have a theme that has web, android, ios, etc variants. Then you have some way of specifying for the client what variant it is. The reason this may make more sense is so that the SSO login screen looks the same whichever application you come from.

For example Acme Inc may have two applications (both with web, ios and android variants):

* calendar
* mail

You want the login screen to be adapted to the variant of the apps. So the login screens can look different if you use a browser or if you use a mobile. What you don't want is the login screens to look different for the calendar and mail applications, as it's SSO you're not logging in to an app, you're looging in to a group of apps.

Can we reliably detect what variant it is? Or does this have to be configured in the admin console on a per-client basis?

> 
> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com > wrote:
> 
> 
> ----- Original Message -----
> > From: "Luk?? Fry?" < lukas at fryc.eu >
> > To: "Stian Thorgersen" < stian at redhat.com >
> > Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org >,
> > keycloak-dev at lists.jboss.org
> > Sent: Friday, 19 September, 2014 1:18:19 PM
> > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> > 
> > IMHO the SSO endpoint could either detect an incoming client (that would be
> > rather complex)
> > 
> > or simply allow user client preference. Can we allow more than one theme
> > per realm and let the client app choohse?
> 
> Not sure what you mean, we always know which client is requesting the login
> (it's the client_id query param). The client should only be used for one
> variant of an application as well (so for an app that has a web, android and
> ios variants, there should be 3 clients configured in KC). So there's no
> problem providing an option to override the theme on a per-client basis.
> 
> > 
> > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
> > wrote:
> > 
> > > This raises the question. Should we allow overriding the theme on an
> > > per-application basis?
> > > 
> > > It would allow a better integration with the app, but on the other side
> > > does it even make sense to login to a SSO realm that way?
> > > 
> > > ----- Original Message -----
> > > > From: "Erik Jan de Wit" < edewit at redhat.com >
> > > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org >
> > > > Cc: keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 19 September, 2014 8:08:02 AM
> > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> > > > 
> > > > Looks very nice, will this integrate well with the work that Summers
> > > > did?
> > > > 
> > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Yeah and off course, the source is here:
> > > > 
> > > > https://github.com/lfryc/keycloak/tree/ionic-styling
> > > > 
> > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com >
> > > wrote:
> > > > 
> > > > 
> > > > 
> > > > Hey guys,
> > > > 
> > > > I've started some work on a theme for Keycloak that would include Ionic
> > > > Framework styling.
> > > > 
> > > > This makes sure that Ionic/Cordova demos that includes Keycloak has
> > > smooth
> > > > transition between application and login process / registration.
> > > > 
> > > > See attached screenshots.
> > > > 
> > > > It's still in early prototypal stage, so just just login, registration
> > > and
> > > > social (only google) fully works so far, but others can be simply
> > > expanded.
> > > > 
> > > > Feel free to use it in demos or so... ;-)
> > > > 
> > > > 
> > > > Cheers,
> > > > 
> > > > ~ Lukas
> > > > 
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > 
> > > > 
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


From ssilvert at redhat.com  Fri Sep 19 08:30:34 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 Sep 2014 08:30:34 -0400
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
Message-ID: <541C21EA.9070204@redhat.com>

On 9/19/2014 7:18 AM, Luk?? Fry? wrote:
> IMHO the SSO endpoint could either detect an incoming client (that 
> would be rather complex)
>
> or simply allow user client preference. Can we allow more than one 
> theme per realm and let the client app choose?
-1 for user preference.  I can't imagine that the user cares enough to 
set it himself, so why do the work to add and maintain the feature at 
that level?
>
> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <stian at redhat.com 
> <mailto:stian at redhat.com>> wrote:
>
>     This raises the question. Should we allow overriding the theme on
>     an per-application basis?
>
>     It would allow a better integration with the app, but on the other
>     side does it even make sense to login to a SSO realm that way?
>
>     ----- Original Message -----
>     > From: "Erik Jan de Wit" <edewit at redhat.com
>     <mailto:edewit at redhat.com>>
>     > To: "AeroGear Developer Mailing List"
>     <aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>>
>     > Cc: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     > Sent: Friday, 19 September, 2014 8:08:02 AM
>     > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>     >
>     > Looks very nice, will this integrate well with the work that
>     Summers did?
>     >
>     > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com
>     <mailto:lukas.fryc at gmail.com> > wrote:
>     >
>     >
>     >
>     >
>     > Yeah and off course, the source is here:
>     >
>     > https://github.com/lfryc/keycloak/tree/ionic-styling
>     >
>     > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? <
>     lukas.fryc at gmail.com <mailto:lukas.fryc at gmail.com> > wrote:
>     >
>     >
>     >
>     > Hey guys,
>     >
>     > I've started some work on a theme for Keycloak that would
>     include Ionic
>     > Framework styling.
>     >
>     > This makes sure that Ionic/Cordova demos that includes Keycloak
>     has smooth
>     > transition between application and login process / registration.
>     >
>     > See attached screenshots.
>     >
>     > It's still in early prototypal stage, so just just login,
>     registration and
>     > social (only google) fully works so far, but others can be
>     simply expanded.
>     >
>     > Feel free to use it in demos or so... ;-)
>     >
>     >
>     > Cheers,
>     >
>     > ~ Lukas
>     >
>     > _______________________________________________
>     > aerogear-dev mailing list
>     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>     >
>     >
>     > _______________________________________________
>     > aerogear-dev mailing list
>     > aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/aerogear-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
>
>
>
>
> _______________________________________________
> 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/20140919/b59a770b/attachment.html 

From lukas at fryc.eu  Fri Sep 19 08:37:43 2014
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 19 Sep 2014 14:37:43 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <541C21EA.9070204@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<541C21EA.9070204@redhat.com>
Message-ID: <CAEroY37vOgt9z_pJf_swYYVLs-NRss=xvj79FEm2jidAJBeH-A@mail.gmail.com>

That was rather meant as user-agent preference (as client app), as opposed
to user preference (as a human).

On Fri, Sep 19, 2014 at 2:30 PM, Stan Silvert <ssilvert at redhat.com> wrote:

>  On 9/19/2014 7:18 AM, Luk?? Fry? wrote:
>
> IMHO the SSO endpoint could either detect an incoming client (that would
> be rather complex)
>
>  or simply allow user client preference. Can we allow more than one theme
> per realm and let the client app choose?
>
> -1 for user preference.  I can't imagine that the user cares enough to set
> it himself, so why do the work to add and maintain the feature at that
> level?
>
>
> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>> This raises the question. Should we allow overriding the theme on an
>> per-application basis?
>>
>> It would allow a better integration with the app, but on the other side
>> does it even make sense to login to a SSO realm that way?
>>
>> ----- Original Message -----
>> > From: "Erik Jan de Wit" <edewit at redhat.com>
>> > To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
>> > Cc: keycloak-dev at lists.jboss.org
>> > Sent: Friday, 19 September, 2014 8:08:02 AM
>> > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>> >
>> > Looks very nice, will this integrate well with the work that Summers
>> did?
>> >
>> > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
>> >
>> >
>> >
>> >
>> > Yeah and off course, the source is here:
>> >
>> > https://github.com/lfryc/keycloak/tree/ionic-styling
>> >
>> > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com >
>> wrote:
>> >
>> >
>> >
>> > Hey guys,
>> >
>> > I've started some work on a theme for Keycloak that would include Ionic
>> > Framework styling.
>> >
>> > This makes sure that Ionic/Cordova demos that includes Keycloak has
>> smooth
>> > transition between application and login process / registration.
>> >
>> > See attached screenshots.
>> >
>> > It's still in early prototypal stage, so just just login, registration
>> and
>> > social (only google) fully works so far, but others can be simply
>> expanded.
>> >
>> > Feel free to use it in demos or so... ;-)
>> >
>> >
>> > Cheers,
>> >
>> > ~ Lukas
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>   _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140919/4c3c482c/attachment.html 

From ssilvert at redhat.com  Fri Sep 19 08:00:34 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 Sep 2014 08:00:34 -0400
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
Message-ID: <541C1AE2.2090107@redhat.com>

On 9/19/2014 3:43 AM, Stian Thorgersen wrote:
> This raises the question. Should we allow overriding the theme on an per-application basis?
>
> It would allow a better integration with the app, but on the other side does it even make sense to login to a SSO realm that way?
That's a very interesting question.  I think it boils down to, "Should 
SSO be cognitively hidden from the user?".   This is a usability 
question and it might be helpful to get Cathrine's opinion.

Cathrine, in Keycloak we have "SSO screens" like login and user 
profile.  So let's say you have two applications that use Keycloak for 
SSO and the two apps have different themes.  Is it better from a 
usability standpoint to have a separate theme for the SSO screens or is 
it better for the SSO screen to take on the theme of the app you are 
calling it from?

>
> ----- Original Message -----
>> From: "Erik Jan de Wit" <edewit at redhat.com>
>> To: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 19 September, 2014 8:08:02 AM
>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>>
>> Looks very nice, will this integrate well with the work that Summers did?
>>
>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote:
>>
>>
>>
>>
>> Yeah and off course, the source is here:
>>
>> https://github.com/lfryc/keycloak/tree/ionic-styling
>>
>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote:
>>
>>
>>
>> Hey guys,
>>
>> I've started some work on a theme for Keycloak that would include Ionic
>> Framework styling.
>>
>> This makes sure that Ionic/Cordova demos that includes Keycloak has smooth
>> transition between application and login process / registration.
>>
>> See attached screenshots.
>>
>> It's still in early prototypal stage, so just just login, registration and
>> social (only google) fully works so far, but others can be simply expanded.
>>
>> Feel free to use it in demos or so... ;-)
>>
>>
>> Cheers,
>>
>> ~ Lukas
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From lukas at fryc.eu  Fri Sep 19 08:49:43 2014
From: lukas at fryc.eu (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=)
Date: Fri, 19 Sep 2014 14:49:43 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34G9iHCPzLh9E_FhyoerhFd=yO9BcM2Cotb2KT6ZEiAnQ@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>
Message-ID: <CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>

I completely agree that the SSO should have same look for all applications
using one realm.


Yes, a customization can be partially achieved just with CSS tweaks, but it
doesn't have to meet all requirements and further per-platform tweaks may
be necessary.

In the Ionic demo above I was to meet 70% cases by using built-in CSS
classes. The rest had to be hard-coded. We can either extend CSS classes
coverage or allow higher customization with e.g. theming per variants.

This feature would make "theming per-platform" easier, I could achieve that
with pure CSS/HTML tweaks and media-queries anyway.

On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Luk?? Fry?" <lukas.fryc at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> keycloak-dev at lists.jboss.org
> > Sent: Friday, 19 September, 2014 1:30:21 PM
> > Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
> theme
> >
> > That would be awesome,
> >
> > do I read correctly that it is not possible at the moment? Should I
> create a
> > feature request?
>
> Currently we can only configure the theme on a per-realm basis. With the
> exception of css media-types there's not currently any way to modify the
> l&f based on client (or client type).
>
> An alternative, which may make more sense, is to add multiple variants of
> a theme. So for example you could have a theme that has web, android, ios,
> etc variants. Then you have some way of specifying for the client what
> variant it is. The reason this may make more sense is so that the SSO login
> screen looks the same whichever application you come from.
>
> For example Acme Inc may have two applications (both with web, ios and
> android variants):
>
> * calendar
> * mail
>
> You want the login screen to be adapted to the variant of the apps. So the
> login screens can look different if you use a browser or if you use a
> mobile. What you don't want is the login screens to look different for the
> calendar and mail applications, as it's SSO you're not logging in to an
> app, you're looging in to a group of apps.
>
> Can we reliably detect what variant it is? Or does this have to be
> configured in the admin console on a per-client basis?
>
> >
> > On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
> wrote:
> >
> >
> > ----- Original Message -----
> > > From: "Luk?? Fry?" < lukas at fryc.eu >
> > > To: "Stian Thorgersen" < stian at redhat.com >
> > > Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
> >,
> > > keycloak-dev at lists.jboss.org
> > > Sent: Friday, 19 September, 2014 1:18:19 PM
> > > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
> theme
> > >
> > > IMHO the SSO endpoint could either detect an incoming client (that
> would be
> > > rather complex)
> > >
> > > or simply allow user client preference. Can we allow more than one
> theme
> > > per realm and let the client app choohse?
> >
> > Not sure what you mean, we always know which client is requesting the
> login
> > (it's the client_id query param). The client should only be used for one
> > variant of an application as well (so for an app that has a web, android
> and
> > ios variants, there should be 3 clients configured in KC). So there's no
> > problem providing an option to override the theme on a per-client basis.
> >
> > >
> > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
> > > wrote:
> > >
> > > > This raises the question. Should we allow overriding the theme on an
> > > > per-application basis?
> > > >
> > > > It would allow a better integration with the app, but on the other
> side
> > > > does it even make sense to login to a SSO realm that way?
> > > >
> > > > ----- Original Message -----
> > > > > From: "Erik Jan de Wit" < edewit at redhat.com >
> > > > > To: "AeroGear Developer Mailing List" <
> aerogear-dev at lists.jboss.org >
> > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > Sent: Friday, 19 September, 2014 8:08:02 AM
> > > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> > > > >
> > > > > Looks very nice, will this integrate well with the work that
> Summers
> > > > > did?
> > > > >
> > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Yeah and off course, the source is here:
> > > > >
> > > > > https://github.com/lfryc/keycloak/tree/ionic-styling
> > > > >
> > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
> >
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > Hey guys,
> > > > >
> > > > > I've started some work on a theme for Keycloak that would include
> Ionic
> > > > > Framework styling.
> > > > >
> > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has
> > > > smooth
> > > > > transition between application and login process / registration.
> > > > >
> > > > > See attached screenshots.
> > > > >
> > > > > It's still in early prototypal stage, so just just login,
> registration
> > > > and
> > > > > social (only google) fully works so far, but others can be simply
> > > > expanded.
> > > > >
> > > > > Feel free to use it in demos or so... ;-)
> > > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > > ~ Lukas
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >
> > >
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-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/20140919/5adb8b70/attachment-0001.html 

From stian at redhat.com  Fri Sep 19 08:53:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 08:53:12 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>
	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>
	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>
Message-ID: <1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>

Another thing we should consider is embedding of the login form. Instead of doing a full-page redirect we could allow embedding using a modal and/or iframe. In that situation you'd also want it to look slightly different than the full-page version.

----- Original Message -----
> From: "Luk?? Fry?" <lukas at fryc.eu>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>, keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 2:49:43 PM
> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> 
> I completely agree that the SSO should have same look for all applications
> using one realm.
> 
> 
> Yes, a customization can be partially achieved just with CSS tweaks, but it
> doesn't have to meet all requirements and further per-platform tweaks may
> be necessary.
> 
> In the Ionic demo above I was to meet 70% cases by using built-in CSS
> classes. The rest had to be hard-coded. We can either extend CSS classes
> coverage or allow higher customization with e.g. theming per variants.
> 
> This feature would make "theming per-platform" easier, I could achieve that
> with pure CSS/HTML tweaks and media-queries anyway.
> 
> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Luk?? Fry?" <lukas.fryc at gmail.com>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> > keycloak-dev at lists.jboss.org
> > > Sent: Friday, 19 September, 2014 1:30:21 PM
> > > Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
> > theme
> > >
> > > That would be awesome,
> > >
> > > do I read correctly that it is not possible at the moment? Should I
> > create a
> > > feature request?
> >
> > Currently we can only configure the theme on a per-realm basis. With the
> > exception of css media-types there's not currently any way to modify the
> > l&f based on client (or client type).
> >
> > An alternative, which may make more sense, is to add multiple variants of
> > a theme. So for example you could have a theme that has web, android, ios,
> > etc variants. Then you have some way of specifying for the client what
> > variant it is. The reason this may make more sense is so that the SSO login
> > screen looks the same whichever application you come from.
> >
> > For example Acme Inc may have two applications (both with web, ios and
> > android variants):
> >
> > * calendar
> > * mail
> >
> > You want the login screen to be adapted to the variant of the apps. So the
> > login screens can look different if you use a browser or if you use a
> > mobile. What you don't want is the login screens to look different for the
> > calendar and mail applications, as it's SSO you're not logging in to an
> > app, you're looging in to a group of apps.
> >
> > Can we reliably detect what variant it is? Or does this have to be
> > configured in the admin console on a per-client basis?
> >
> > >
> > > On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
> > wrote:
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Luk?? Fry?" < lukas at fryc.eu >
> > > > To: "Stian Thorgersen" < stian at redhat.com >
> > > > Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
> > >,
> > > > keycloak-dev at lists.jboss.org
> > > > Sent: Friday, 19 September, 2014 1:18:19 PM
> > > > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
> > theme
> > > >
> > > > IMHO the SSO endpoint could either detect an incoming client (that
> > would be
> > > > rather complex)
> > > >
> > > > or simply allow user client preference. Can we allow more than one
> > theme
> > > > per realm and let the client app choohse?
> > >
> > > Not sure what you mean, we always know which client is requesting the
> > login
> > > (it's the client_id query param). The client should only be used for one
> > > variant of an application as well (so for an app that has a web, android
> > and
> > > ios variants, there should be 3 clients configured in KC). So there's no
> > > problem providing an option to override the theme on a per-client basis.
> > >
> > > >
> > > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
> > > > wrote:
> > > >
> > > > > This raises the question. Should we allow overriding the theme on an
> > > > > per-application basis?
> > > > >
> > > > > It would allow a better integration with the app, but on the other
> > side
> > > > > does it even make sense to login to a SSO realm that way?
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Erik Jan de Wit" < edewit at redhat.com >
> > > > > > To: "AeroGear Developer Mailing List" <
> > aerogear-dev at lists.jboss.org >
> > > > > > Cc: keycloak-dev at lists.jboss.org
> > > > > > Sent: Friday, 19 September, 2014 8:08:02 AM
> > > > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> > > > > >
> > > > > > Looks very nice, will this integrate well with the work that
> > Summers
> > > > > > did?
> > > > > >
> > > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
> > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yeah and off course, the source is here:
> > > > > >
> > > > > > https://github.com/lfryc/keycloak/tree/ionic-styling
> > > > > >
> > > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hey guys,
> > > > > >
> > > > > > I've started some work on a theme for Keycloak that would include
> > Ionic
> > > > > > Framework styling.
> > > > > >
> > > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has
> > > > > smooth
> > > > > > transition between application and login process / registration.
> > > > > >
> > > > > > See attached screenshots.
> > > > > >
> > > > > > It's still in early prototypal stage, so just just login,
> > registration
> > > > > and
> > > > > > social (only google) fully works so far, but others can be simply
> > > > > expanded.
> > > > > >
> > > > > > Feel free to use it in demos or so... ;-)
> > > > > >
> > > > > >
> > > > > > Cheers,
> > > > > >
> > > > > > ~ Lukas
> > > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/aerogear-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 Sep 19 09:19:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Sep 2014 09:19:13 -0400
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>	<2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com>	<1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com>	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>
	<1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>
Message-ID: <541C2D51.4010101@redhat.com>

Browsers set the User-Agent header.  Wouldn't it be better to pick the 
theme based on the user-agent header?  I don't remember if browsers also 
automatically push locale info.

On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
> Another thing we should consider is embedding of the login form. Instead of doing a full-page redirect we could allow embedding using a modal and/or iframe. In that situation you'd also want it to look slightly different than the full-page version.
>
> ----- Original Message -----
>> From: "Luk?? Fry?" <lukas at fryc.eu>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>, keycloak-dev at lists.jboss.org
>> Sent: Friday, 19 September, 2014 2:49:43 PM
>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>
>> I completely agree that the SSO should have same look for all applications
>> using one realm.
>>
>>
>> Yes, a customization can be partially achieved just with CSS tweaks, but it
>> doesn't have to meet all requirements and further per-platform tweaks may
>> be necessary.
>>
>> In the Ionic demo above I was to meet 70% cases by using built-in CSS
>> classes. The rest had to be hard-coded. We can either extend CSS classes
>> coverage or allow higher customization with e.g. theming per variants.
>>
>> This feature would make "theming per-platform" easier, I could achieve that
>> with pure CSS/HTML tweaks and media-queries anyway.
>>
>> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
>>> keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 19 September, 2014 1:30:21 PM
>>>> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
>>> theme
>>>>
>>>> That would be awesome,
>>>>
>>>> do I read correctly that it is not possible at the moment? Should I
>>> create a
>>>> feature request?
>>>
>>> Currently we can only configure the theme on a per-realm basis. With the
>>> exception of css media-types there's not currently any way to modify the
>>> l&f based on client (or client type).
>>>
>>> An alternative, which may make more sense, is to add multiple variants of
>>> a theme. So for example you could have a theme that has web, android, ios,
>>> etc variants. Then you have some way of specifying for the client what
>>> variant it is. The reason this may make more sense is so that the SSO login
>>> screen looks the same whichever application you come from.
>>>
>>> For example Acme Inc may have two applications (both with web, ios and
>>> android variants):
>>>
>>> * calendar
>>> * mail
>>>
>>> You want the login screen to be adapted to the variant of the apps. So the
>>> login screens can look different if you use a browser or if you use a
>>> mobile. What you don't want is the login screens to look different for the
>>> calendar and mail applications, as it's SSO you're not logging in to an
>>> app, you're looging in to a group of apps.
>>>
>>> Can we reliably detect what variant it is? Or does this have to be
>>> configured in the admin console on a per-client basis?
>>>
>>>>
>>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
>>> wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Luk?? Fry?" < lukas at fryc.eu >
>>>>> To: "Stian Thorgersen" < stian at redhat.com >
>>>>> Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
>>>> ,
>>>>> keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
>>> theme
>>>>>
>>>>> IMHO the SSO endpoint could either detect an incoming client (that
>>> would be
>>>>> rather complex)
>>>>>
>>>>> or simply allow user client preference. Can we allow more than one
>>> theme
>>>>> per realm and let the client app choohse?
>>>>
>>>> Not sure what you mean, we always know which client is requesting the
>>> login
>>>> (it's the client_id query param). The client should only be used for one
>>>> variant of an application as well (so for an app that has a web, android
>>> and
>>>> ios variants, there should be 3 clients configured in KC). So there's no
>>>> problem providing an option to override the theme on a per-client basis.
>>>>
>>>>>
>>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
>>>>> wrote:
>>>>>
>>>>>> This raises the question. Should we allow overriding the theme on an
>>>>>> per-application basis?
>>>>>>
>>>>>> It would allow a better integration with the app, but on the other
>>> side
>>>>>> does it even make sense to login to a SSO realm that way?
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Erik Jan de Wit" < edewit at redhat.com >
>>>>>>> To: "AeroGear Developer Mailing List" <
>>> aerogear-dev at lists.jboss.org >
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
>>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>>>>>>>
>>>>>>> Looks very nice, will this integrate well with the work that
>>> Summers
>>>>>>> did?
>>>>>>>
>>>>>>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yeah and off course, the source is here:
>>>>>>>
>>>>>>> https://github.com/lfryc/keycloak/tree/ionic-styling
>>>>>>>
>>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> I've started some work on a theme for Keycloak that would include
>>> Ionic
>>>>>>> Framework styling.
>>>>>>>
>>>>>>> This makes sure that Ionic/Cordova demos that includes Keycloak has
>>>>>> smooth
>>>>>>> transition between application and login process / registration.
>>>>>>>
>>>>>>> See attached screenshots.
>>>>>>>
>>>>>>> It's still in early prototypal stage, so just just login,
>>> registration
>>>>>> and
>>>>>>> social (only google) fully works so far, but others can be simply
>>>>>> expanded.
>>>>>>>
>>>>>>> Feel free to use it in demos or so... ;-)
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> ~ Lukas
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-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 bburke at redhat.com  Fri Sep 19 09:23:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Sep 2014 09:23:36 -0400
Subject: [keycloak-dev] 1.0.2 release for security bug
Message-ID: <541C2E58.5010708@redhat.com>

https://issues.jboss.org/browse/KEYCLOAK-705

See any problem with doing a release for that?  I'll do that today if 
you agree.


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

From stian at redhat.com  Fri Sep 19 10:14:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 10:14:53 -0400 (EDT)
Subject: [keycloak-dev] 1.0.2 release for security bug
In-Reply-To: <541C2E58.5010708@redhat.com>
References: <541C2E58.5010708@redhat.com>
Message-ID: <827023506.52436972.1411136093242.JavaMail.zimbra@redhat.com>

Go for it

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 3:23:36 PM
> Subject: [keycloak-dev] 1.0.2 release for security bug
> 
> https://issues.jboss.org/browse/KEYCLOAK-705
> 
> See any problem with doing a release for that?  I'll do that today if
> you agree.
> 
> 
> --
> 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 Sep 19 10:16:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Sep 2014 10:16:37 -0400
Subject: [keycloak-dev] 1.0.2 release for security bug
In-Reply-To: <827023506.52436972.1411136093242.JavaMail.zimbra@redhat.com>
References: <541C2E58.5010708@redhat.com>
	<827023506.52436972.1411136093242.JavaMail.zimbra@redhat.com>
Message-ID: <541C3AC5.1020300@redhat.com>

meh.  Just gonna wait until Florian finishes his audit.

On 9/19/2014 10:14 AM, Stian Thorgersen wrote:
> Go for it
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 19 September, 2014 3:23:36 PM
>> Subject: [keycloak-dev] 1.0.2 release for security bug
>>
>> https://issues.jboss.org/browse/KEYCLOAK-705
>>
>> See any problem with doing a release for that?  I'll do that today if
>> you agree.
>>
>>
>> --
>> 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 Sep 19 10:27:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 19 Sep 2014 10:27:43 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <541C2D51.4010101@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>
	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>
	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>
	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>
	<1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>
	<541C2D51.4010101@redhat.com>
Message-ID: <1570810070.52446844.1411136863721.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 19 September, 2014 3:19:13 PM
> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> 
> Browsers set the User-Agent header.  Wouldn't it be better to pick the
> theme based on the user-agent header?  I don't remember if browsers also
> automatically push locale info.

User-Agent header is useful, but I think we may something in addition, for example when form is displayed embedded instead of full page redirect. Not 100% sure user-agent is always reliable either.

Browsers set's Accept-Language header, but apparently it's not always reliable so it's only recommended to use it as a starting point. I've got a proposal for internationalization support here: https://issues.jboss.org/browse/KEYCLOAK-301

> 
> On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
> > Another thing we should consider is embedding of the login form. Instead of
> > doing a full-page redirect we could allow embedding using a modal and/or
> > iframe. In that situation you'd also want it to look slightly different
> > than the full-page version.
> >
> > ----- Original Message -----
> >> From: "Luk?? Fry?" <lukas at fryc.eu>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> >> keycloak-dev at lists.jboss.org
> >> Sent: Friday, 19 September, 2014 2:49:43 PM
> >> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> >>
> >> I completely agree that the SSO should have same look for all applications
> >> using one realm.
> >>
> >>
> >> Yes, a customization can be partially achieved just with CSS tweaks, but
> >> it
> >> doesn't have to meet all requirements and further per-platform tweaks may
> >> be necessary.
> >>
> >> In the Ionic demo above I was to meet 70% cases by using built-in CSS
> >> classes. The rest had to be hard-coded. We can either extend CSS classes
> >> coverage or allow higher customization with e.g. theming per variants.
> >>
> >> This feature would make "theming per-platform" easier, I could achieve
> >> that
> >> with pure CSS/HTML tweaks and media-queries anyway.
> >>
> >> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> >>> keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 19 September, 2014 1:30:21 PM
> >>>> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
> >>> theme
> >>>>
> >>>> That would be awesome,
> >>>>
> >>>> do I read correctly that it is not possible at the moment? Should I
> >>> create a
> >>>> feature request?
> >>>
> >>> Currently we can only configure the theme on a per-realm basis. With the
> >>> exception of css media-types there's not currently any way to modify the
> >>> l&f based on client (or client type).
> >>>
> >>> An alternative, which may make more sense, is to add multiple variants of
> >>> a theme. So for example you could have a theme that has web, android,
> >>> ios,
> >>> etc variants. Then you have some way of specifying for the client what
> >>> variant it is. The reason this may make more sense is so that the SSO
> >>> login
> >>> screen looks the same whichever application you come from.
> >>>
> >>> For example Acme Inc may have two applications (both with web, ios and
> >>> android variants):
> >>>
> >>> * calendar
> >>> * mail
> >>>
> >>> You want the login screen to be adapted to the variant of the apps. So
> >>> the
> >>> login screens can look different if you use a browser or if you use a
> >>> mobile. What you don't want is the login screens to look different for
> >>> the
> >>> calendar and mail applications, as it's SSO you're not logging in to an
> >>> app, you're looging in to a group of apps.
> >>>
> >>> Can we reliably detect what variant it is? Or does this have to be
> >>> configured in the admin console on a per-client basis?
> >>>
> >>>>
> >>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
> >>> wrote:
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Luk?? Fry?" < lukas at fryc.eu >
> >>>>> To: "Stian Thorgersen" < stian at redhat.com >
> >>>>> Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
> >>>> ,
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
> >>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
> >>> theme
> >>>>>
> >>>>> IMHO the SSO endpoint could either detect an incoming client (that
> >>> would be
> >>>>> rather complex)
> >>>>>
> >>>>> or simply allow user client preference. Can we allow more than one
> >>> theme
> >>>>> per realm and let the client app choohse?
> >>>>
> >>>> Not sure what you mean, we always know which client is requesting the
> >>> login
> >>>> (it's the client_id query param). The client should only be used for one
> >>>> variant of an application as well (so for an app that has a web, android
> >>> and
> >>>> ios variants, there should be 3 clients configured in KC). So there's no
> >>>> problem providing an option to override the theme on a per-client basis.
> >>>>
> >>>>>
> >>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
> >>>>> wrote:
> >>>>>
> >>>>>> This raises the question. Should we allow overriding the theme on an
> >>>>>> per-application basis?
> >>>>>>
> >>>>>> It would allow a better integration with the app, but on the other
> >>> side
> >>>>>> does it even make sense to login to a SSO realm that way?
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Erik Jan de Wit" < edewit at redhat.com >
> >>>>>>> To: "AeroGear Developer Mailing List" <
> >>> aerogear-dev at lists.jboss.org >
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
> >>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> >>>>>>>
> >>>>>>> Looks very nice, will this integrate well with the work that
> >>> Summers
> >>>>>>> did?
> >>>>>>>
> >>>>>>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
> >>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Yeah and off course, the source is here:
> >>>>>>>
> >>>>>>> https://github.com/lfryc/keycloak/tree/ionic-styling
> >>>>>>>
> >>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
> >>>>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Hey guys,
> >>>>>>>
> >>>>>>> I've started some work on a theme for Keycloak that would include
> >>> Ionic
> >>>>>>> Framework styling.
> >>>>>>>
> >>>>>>> This makes sure that Ionic/Cordova demos that includes Keycloak has
> >>>>>> smooth
> >>>>>>> transition between application and login process / registration.
> >>>>>>>
> >>>>>>> See attached screenshots.
> >>>>>>>
> >>>>>>> It's still in early prototypal stage, so just just login,
> >>> registration
> >>>>>> and
> >>>>>>> social (only google) fully works so far, but others can be simply
> >>>>>> expanded.
> >>>>>>>
> >>>>>>> Feel free to use it in demos or so... ;-)
> >>>>>>>
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>
> >>>>>>> ~ Lukas
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> aerogear-dev mailing list
> >>>>>>> aerogear-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> aerogear-dev mailing list
> >>>>>>> aerogear-dev at lists.jboss.org
> >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> aerogear-dev mailing list
> >>>> aerogear-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Sep 19 11:38:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Sep 2014 11:38:18 -0400
Subject: [keycloak-dev] security vulnerabilites documented please review
Message-ID: <541C4DEA.6070106@redhat.com>

I created a security vulnerabilities chapter in our documentation. 
Please review to see if I forgot anything.

Thanks,

Bill


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

From ssilvert at redhat.com  Fri Sep 19 12:18:01 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 19 Sep 2014 12:18:01 -0400
Subject: [keycloak-dev] 1.0.2 release for security bug
In-Reply-To: <541C2E58.5010708@redhat.com>
References: <541C2E58.5010708@redhat.com>
Message-ID: <541C5739.1020702@redhat.com>

On 9/19/2014 9:23 AM, Bill Burke wrote:
> https://issues.jboss.org/browse/KEYCLOAK-705
>
> See any problem with doing a release for that?  I'll do that today if
> you agree.
>
>
I don't have permission to see that JIRA.  Who do I talk to?

From corinnekrych at gmail.com  Sat Sep 20 11:48:53 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Sat, 20 Sep 2014 17:48:53 +0200
Subject: [keycloak-dev] OAuth2 revoke
Message-ID: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>

Hello 

Trying to implement AGIOS-206 [1] linked to [2], what iI need is a revoke of all tokens (refresh and access token).

I've tried ?logout? with a refresh token this endpoint:
http://docs.jboss.org/keycloak/docs/1.0.1.Final/rest-api/realms/%7Brealm%7D/tokens/logout/index.html#POST
for a public client.
I run appliance 1.0-final distribution of key cloak.

But I run into this exception [3] after a timeout. Anything else I can try or should I just wait for revoke feature to be implemented in Keycloak?

++
Corinne

[1] https://issues.jboss.org/browse/AGIOS-206
[2] https://issues.jboss.org/browse/KEYCLOAK-312
[3] https://gist.github.com/corinnekrych/53bd73c4e047281a94f1

From mposolda at redhat.com  Mon Sep 22 03:06:39 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 22 Sep 2014 09:06:39 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <1570810070.52446844.1411136863721.JavaMail.zimbra@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>	<1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>	<541C2D51.4010101@redhat.com>
	<1570810070.52446844.1411136863721.JavaMail.zimbra@redhat.com>
Message-ID: <541FCA7F.4010207@redhat.com>

I wonder there might be some more browser javascript properties, which 
might help to detect client type. For example screen.width (with low 
values, there is quite big chance that you are using mobile device). 
Also it might be useful to detect if device support touch screen or not 
(not sure if there is some reliable way though). If we go this way, it 
might be also helpful to cache the detected client type into cookie, so 
detection doesn't need to be done in each request.

Marek

On 19.9.2014 16:27, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 19 September, 2014 3:19:13 PM
>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>
>> Browsers set the User-Agent header.  Wouldn't it be better to pick the
>> theme based on the user-agent header?  I don't remember if browsers also
>> automatically push locale info.
> User-Agent header is useful, but I think we may something in addition, for example when form is displayed embedded instead of full page redirect. Not 100% sure user-agent is always reliable either.
>
> Browsers set's Accept-Language header, but apparently it's not always reliable so it's only recommended to use it as a starting point. I've got a proposal for internationalization support here: https://issues.jboss.org/browse/KEYCLOAK-301
>
>> On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
>>> Another thing we should consider is embedding of the login form. Instead of
>>> doing a full-page redirect we could allow embedding using a modal and/or
>>> iframe. In that situation you'd also want it to look slightly different
>>> than the full-page version.
>>>
>>> ----- Original Message -----
>>>> From: "Luk?? Fry?" <lukas at fryc.eu>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
>>>> keycloak-dev at lists.jboss.org
>>>> Sent: Friday, 19 September, 2014 2:49:43 PM
>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>>>
>>>> I completely agree that the SSO should have same look for all applications
>>>> using one realm.
>>>>
>>>>
>>>> Yes, a customization can be partially achieved just with CSS tweaks, but
>>>> it
>>>> doesn't have to meet all requirements and further per-platform tweaks may
>>>> be necessary.
>>>>
>>>> In the Ionic demo above I was to meet 70% cases by using built-in CSS
>>>> classes. The rest had to be hard-coded. We can either extend CSS classes
>>>> coverage or allow higher customization with e.g. theming per variants.
>>>>
>>>> This feature would make "theming per-platform" easier, I could achieve
>>>> that
>>>> with pure CSS/HTML tweaks and media-queries anyway.
>>>>
>>>> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
>>>>> keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, 19 September, 2014 1:30:21 PM
>>>>>> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
>>>>> theme
>>>>>> That would be awesome,
>>>>>>
>>>>>> do I read correctly that it is not possible at the moment? Should I
>>>>> create a
>>>>>> feature request?
>>>>> Currently we can only configure the theme on a per-realm basis. With the
>>>>> exception of css media-types there's not currently any way to modify the
>>>>> l&f based on client (or client type).
>>>>>
>>>>> An alternative, which may make more sense, is to add multiple variants of
>>>>> a theme. So for example you could have a theme that has web, android,
>>>>> ios,
>>>>> etc variants. Then you have some way of specifying for the client what
>>>>> variant it is. The reason this may make more sense is so that the SSO
>>>>> login
>>>>> screen looks the same whichever application you come from.
>>>>>
>>>>> For example Acme Inc may have two applications (both with web, ios and
>>>>> android variants):
>>>>>
>>>>> * calendar
>>>>> * mail
>>>>>
>>>>> You want the login screen to be adapted to the variant of the apps. So
>>>>> the
>>>>> login screens can look different if you use a browser or if you use a
>>>>> mobile. What you don't want is the login screens to look different for
>>>>> the
>>>>> calendar and mail applications, as it's SSO you're not logging in to an
>>>>> app, you're looging in to a group of apps.
>>>>>
>>>>> Can we reliably detect what variant it is? Or does this have to be
>>>>> configured in the admin console on a per-client basis?
>>>>>
>>>>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
>>>>> wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Luk?? Fry?" < lukas at fryc.eu >
>>>>>>> To: "Stian Thorgersen" < stian at redhat.com >
>>>>>>> Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
>>>>>> ,
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
>>>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
>>>>> theme
>>>>>>> IMHO the SSO endpoint could either detect an incoming client (that
>>>>> would be
>>>>>>> rather complex)
>>>>>>>
>>>>>>> or simply allow user client preference. Can we allow more than one
>>>>> theme
>>>>>>> per realm and let the client app choohse?
>>>>>> Not sure what you mean, we always know which client is requesting the
>>>>> login
>>>>>> (it's the client_id query param). The client should only be used for one
>>>>>> variant of an application as well (so for an app that has a web, android
>>>>> and
>>>>>> ios variants, there should be 3 clients configured in KC). So there's no
>>>>>> problem providing an option to override the theme on a per-client basis.
>>>>>>
>>>>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This raises the question. Should we allow overriding the theme on an
>>>>>>>> per-application basis?
>>>>>>>>
>>>>>>>> It would allow a better integration with the app, but on the other
>>>>> side
>>>>>>>> does it even make sense to login to a SSO realm that way?
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Erik Jan de Wit" < edewit at redhat.com >
>>>>>>>>> To: "AeroGear Developer Mailing List" <
>>>>> aerogear-dev at lists.jboss.org >
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
>>>>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>>>>>>>>>
>>>>>>>>> Looks very nice, will this integrate well with the work that
>>>>> Summers
>>>>>>>>> did?
>>>>>>>>>
>>>>>>>>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yeah and off course, the source is here:
>>>>>>>>>
>>>>>>>>> https://github.com/lfryc/keycloak/tree/ionic-styling
>>>>>>>>>
>>>>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hey guys,
>>>>>>>>>
>>>>>>>>> I've started some work on a theme for Keycloak that would include
>>>>> Ionic
>>>>>>>>> Framework styling.
>>>>>>>>>
>>>>>>>>> This makes sure that Ionic/Cordova demos that includes Keycloak has
>>>>>>>> smooth
>>>>>>>>> transition between application and login process / registration.
>>>>>>>>>
>>>>>>>>> See attached screenshots.
>>>>>>>>>
>>>>>>>>> It's still in early prototypal stage, so just just login,
>>>>> registration
>>>>>>>> and
>>>>>>>>> social (only google) fully works so far, but others can be simply
>>>>>>>> expanded.
>>>>>>>>> Feel free to use it in demos or so... ;-)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> ~ Lukas
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> aerogear-dev mailing list
>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> aerogear-dev mailing list
>>>>>> aerogear-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-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
>> _______________________________________________
>> 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 Sep 22 03:29:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 22 Sep 2014 03:29:13 -0400 (EDT)
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <541FCA7F.4010207@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>
	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>
	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>
	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>
	<1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>
	<541C2D51.4010101@redhat.com>
	<1570810070.52446844.1411136863721.JavaMail.zimbra@redhat.com>
	<541FCA7F.4010207@redhat.com>
Message-ID: <416408063.52975022.1411370953337.JavaMail.zimbra@redhat.com>

Javascript and css3 can already be done as those won't require any updates to Keycloak. I'm not sure if that will cover all cases though. So me may need to expose at least user-agent header, we could also make the client_id available to the themes.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 22 September, 2014 9:06:39 AM
> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> 
> I wonder there might be some more browser javascript properties, which
> might help to detect client type. For example screen.width (with low
> values, there is quite big chance that you are using mobile device).
> Also it might be useful to detect if device support touch screen or not
> (not sure if there is some reliable way though). If we go this way, it
> might be also helpful to cache the detected client type into cookie, so
> detection doesn't need to be done in each request.
> 
> Marek
> 
> On 19.9.2014 16:27, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 19 September, 2014 3:19:13 PM
> >> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
> >>
> >> Browsers set the User-Agent header.  Wouldn't it be better to pick the
> >> theme based on the user-agent header?  I don't remember if browsers also
> >> automatically push locale info.
> > User-Agent header is useful, but I think we may something in addition, for
> > example when form is displayed embedded instead of full page redirect. Not
> > 100% sure user-agent is always reliable either.
> >
> > Browsers set's Accept-Language header, but apparently it's not always
> > reliable so it's only recommended to use it as a starting point. I've got
> > a proposal for internationalization support here:
> > https://issues.jboss.org/browse/KEYCLOAK-301
> >
> >> On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
> >>> Another thing we should consider is embedding of the login form. Instead
> >>> of
> >>> doing a full-page redirect we could allow embedding using a modal and/or
> >>> iframe. In that situation you'd also want it to look slightly different
> >>> than the full-page version.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Luk?? Fry?" <lukas at fryc.eu>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> >>>> keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, 19 September, 2014 2:49:43 PM
> >>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
> >>>> theme
> >>>>
> >>>> I completely agree that the SSO should have same look for all
> >>>> applications
> >>>> using one realm.
> >>>>
> >>>>
> >>>> Yes, a customization can be partially achieved just with CSS tweaks, but
> >>>> it
> >>>> doesn't have to meet all requirements and further per-platform tweaks
> >>>> may
> >>>> be necessary.
> >>>>
> >>>> In the Ionic demo above I was to meet 70% cases by using built-in CSS
> >>>> classes. The rest had to be hard-coded. We can either extend CSS classes
> >>>> coverage or allow higher customization with e.g. theming per variants.
> >>>>
> >>>> This feature would make "theming per-platform" easier, I could achieve
> >>>> that
> >>>> with pure CSS/HTML tweaks and media-queries anyway.
> >>>>
> >>>> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com>
> >>>> wrote:
> >>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
> >>>>> keycloak-dev at lists.jboss.org
> >>>>>> Sent: Friday, 19 September, 2014 1:30:21 PM
> >>>>>> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
> >>>>> theme
> >>>>>> That would be awesome,
> >>>>>>
> >>>>>> do I read correctly that it is not possible at the moment? Should I
> >>>>> create a
> >>>>>> feature request?
> >>>>> Currently we can only configure the theme on a per-realm basis. With
> >>>>> the
> >>>>> exception of css media-types there's not currently any way to modify
> >>>>> the
> >>>>> l&f based on client (or client type).
> >>>>>
> >>>>> An alternative, which may make more sense, is to add multiple variants
> >>>>> of
> >>>>> a theme. So for example you could have a theme that has web, android,
> >>>>> ios,
> >>>>> etc variants. Then you have some way of specifying for the client what
> >>>>> variant it is. The reason this may make more sense is so that the SSO
> >>>>> login
> >>>>> screen looks the same whichever application you come from.
> >>>>>
> >>>>> For example Acme Inc may have two applications (both with web, ios and
> >>>>> android variants):
> >>>>>
> >>>>> * calendar
> >>>>> * mail
> >>>>>
> >>>>> You want the login screen to be adapted to the variant of the apps. So
> >>>>> the
> >>>>> login screens can look different if you use a browser or if you use a
> >>>>> mobile. What you don't want is the login screens to look different for
> >>>>> the
> >>>>> calendar and mail applications, as it's SSO you're not logging in to an
> >>>>> app, you're looging in to a group of apps.
> >>>>>
> >>>>> Can we reliably detect what variant it is? Or does this have to be
> >>>>> configured in the admin console on a per-client basis?
> >>>>>
> >>>>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
> >>>>> wrote:
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Luk?? Fry?" < lukas at fryc.eu >
> >>>>>>> To: "Stian Thorgersen" < stian at redhat.com >
> >>>>>>> Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
> >>>>>> ,
> >>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
> >>>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
> >>>>> theme
> >>>>>>> IMHO the SSO endpoint could either detect an incoming client (that
> >>>>> would be
> >>>>>>> rather complex)
> >>>>>>>
> >>>>>>> or simply allow user client preference. Can we allow more than one
> >>>>> theme
> >>>>>>> per realm and let the client app choohse?
> >>>>>> Not sure what you mean, we always know which client is requesting the
> >>>>> login
> >>>>>> (it's the client_id query param). The client should only be used for
> >>>>>> one
> >>>>>> variant of an application as well (so for an app that has a web,
> >>>>>> android
> >>>>> and
> >>>>>> ios variants, there should be 3 clients configured in KC). So there's
> >>>>>> no
> >>>>>> problem providing an option to override the theme on a per-client
> >>>>>> basis.
> >>>>>>
> >>>>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com
> >>>>>>> >
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> This raises the question. Should we allow overriding the theme on an
> >>>>>>>> per-application basis?
> >>>>>>>>
> >>>>>>>> It would allow a better integration with the app, but on the other
> >>>>> side
> >>>>>>>> does it even make sense to login to a SSO realm that way?
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Erik Jan de Wit" < edewit at redhat.com >
> >>>>>>>>> To: "AeroGear Developer Mailing List" <
> >>>>> aerogear-dev at lists.jboss.org >
> >>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
> >>>>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
> >>>>>>>>>
> >>>>>>>>> Looks very nice, will this integrate well with the work that
> >>>>> Summers
> >>>>>>>>> did?
> >>>>>>>>>
> >>>>>>>>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Yeah and off course, the source is here:
> >>>>>>>>>
> >>>>>>>>> https://github.com/lfryc/keycloak/tree/ionic-styling
> >>>>>>>>>
> >>>>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hey guys,
> >>>>>>>>>
> >>>>>>>>> I've started some work on a theme for Keycloak that would include
> >>>>> Ionic
> >>>>>>>>> Framework styling.
> >>>>>>>>>
> >>>>>>>>> This makes sure that Ionic/Cordova demos that includes Keycloak has
> >>>>>>>> smooth
> >>>>>>>>> transition between application and login process / registration.
> >>>>>>>>>
> >>>>>>>>> See attached screenshots.
> >>>>>>>>>
> >>>>>>>>> It's still in early prototypal stage, so just just login,
> >>>>> registration
> >>>>>>>> and
> >>>>>>>>> social (only google) fully works so far, but others can be simply
> >>>>>>>> expanded.
> >>>>>>>>> Feel free to use it in demos or so... ;-)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>>
> >>>>>>>>> ~ Lukas
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> aerogear-dev mailing list
> >>>>>>>>> aerogear-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> aerogear-dev mailing list
> >>>>>>>>> aerogear-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>>>>>> _______________________________________________
> >>>>>>>> keycloak-dev mailing list
> >>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> aerogear-dev mailing list
> >>>>>> aerogear-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-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
> >> _______________________________________________
> >> 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 sblanc at redhat.com  Mon Sep 22 03:39:08 2014
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 22 Sep 2014 09:39:08 +0200
Subject: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
In-Reply-To: <541FCA7F.4010207@redhat.com>
References: <CAEroY37bLW59RpjCFffQFSzEYgiEU-y9Qb3MQTcnJ6DtiX8Dvw@mail.gmail.com>	<CAEroY376mWKV0g5wmNiDvAAAkhFaRqztuQPnf_y7sg-G4sYf=w@mail.gmail.com>	<351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com>	<CAEroY34FgyBK3BpbnPvfrgdXtNmA_XSKDHGXpRdw5T+gytmr0w@mail.gmail.com>	<2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com>	<CAEroY35fYxg3-B+CRRNzsF0FMRjK-8fpAMs=V1=aGcsEVd_GHQ@mail.gmail.com>	<1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com>	<541C2D51.4010101@redhat.com>	<1570810070.52446844.1411136863721.JavaMail.zimbra@redhat.com>
	<541FCA7F.4010207@redhat.com>
Message-ID: <541FD21C.8070205@redhat.com>

On 22/09/14 09:06, Marek Posolda wrote:
> I wonder there might be some more browser javascript properties, which
> might help to detect client type. For example screen.width (with low
> values, there is quite big chance that you are using mobile device).
> Also it might be useful to detect if device support touch screen or not
> (not sure if there is some reliable way though). If we go this way, it
> might be also helpful to cache the detected client type into cookie, so
> detection doesn't need to be done in each request.
>
> Marek
We could use something similar to Spring Mobile Device Resolver 
(http://projects.spring.io/spring-mobile/) which is pretty accurate. 
When I worked on it (for a Grails plugin) it was using WURFL 
(http://wurfl.sourceforge.net/ ) which is a Device Description 
Repository, but I believe they have change their licensing model, so not 
sure we can use it.

>
> On 19.9.2014 16:27, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 19 September, 2014 3:19:13 PM
>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>>
>>> Browsers set the User-Agent header.  Wouldn't it be better to pick the
>>> theme based on the user-agent header?  I don't remember if browsers also
>>> automatically push locale info.
>> User-Agent header is useful, but I think we may something in addition, for example when form is displayed embedded instead of full page redirect. Not 100% sure user-agent is always reliable either.
>>
>> Browsers set's Accept-Language header, but apparently it's not always reliable so it's only recommended to use it as a starting point. I've got a proposal for internationalization support here: https://issues.jboss.org/browse/KEYCLOAK-301
>>
>>> On 9/19/2014 8:53 AM, Stian Thorgersen wrote:
>>>> Another thing we should consider is embedding of the login form. Instead of
>>>> doing a full-page redirect we could allow embedding using a modal and/or
>>>> iframe. In that situation you'd also want it to look slightly different
>>>> than the full-page version.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Luk?? Fry?" <lukas at fryc.eu>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
>>>>> keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 19 September, 2014 2:49:43 PM
>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme
>>>>>
>>>>> I completely agree that the SSO should have same look for all applications
>>>>> using one realm.
>>>>>
>>>>>
>>>>> Yes, a customization can be partially achieved just with CSS tweaks, but
>>>>> it
>>>>> doesn't have to meet all requirements and further per-platform tweaks may
>>>>> be necessary.
>>>>>
>>>>> In the Ionic demo above I was to meet 70% cases by using built-in CSS
>>>>> classes. The rest had to be hard-coded. We can either extend CSS classes
>>>>> coverage or allow higher customization with e.g. theming per variants.
>>>>>
>>>>> This feature would make "theming per-platform" easier, I could achieve
>>>>> that
>>>>> with pure CSS/HTML tweaks and media-queries anyway.
>>>>>
>>>>> On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen <stian at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Luk?? Fry?" <lukas.fryc at gmail.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: "AeroGear Developer Mailing List" <aerogear-dev at lists.jboss.org>,
>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, 19 September, 2014 1:30:21 PM
>>>>>>> Subject: Re: [aerogear-dev] [keycloak-dev]  Keycloak Ionic / Cordova
>>>>>> theme
>>>>>>> That would be awesome,
>>>>>>>
>>>>>>> do I read correctly that it is not possible at the moment? Should I
>>>>>> create a
>>>>>>> feature request?
>>>>>> Currently we can only configure the theme on a per-realm basis. With the
>>>>>> exception of css media-types there's not currently any way to modify the
>>>>>> l&f based on client (or client type).
>>>>>>
>>>>>> An alternative, which may make more sense, is to add multiple variants of
>>>>>> a theme. So for example you could have a theme that has web, android,
>>>>>> ios,
>>>>>> etc variants. Then you have some way of specifying for the client what
>>>>>> variant it is. The reason this may make more sense is so that the SSO
>>>>>> login
>>>>>> screen looks the same whichever application you come from.
>>>>>>
>>>>>> For example Acme Inc may have two applications (both with web, ios and
>>>>>> android variants):
>>>>>>
>>>>>> * calendar
>>>>>> * mail
>>>>>>
>>>>>> You want the login screen to be adapted to the variant of the apps. So
>>>>>> the
>>>>>> login screens can look different if you use a browser or if you use a
>>>>>> mobile. What you don't want is the login screens to look different for
>>>>>> the
>>>>>> calendar and mail applications, as it's SSO you're not logging in to an
>>>>>> app, you're looging in to a group of apps.
>>>>>>
>>>>>> Can we reliably detect what variant it is? Or does this have to be
>>>>>> configured in the admin console on a per-client basis?
>>>>>>
>>>>>>> On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com >
>>>>>> wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Luk?? Fry?" < lukas at fryc.eu >
>>>>>>>> To: "Stian Thorgersen" < stian at redhat.com >
>>>>>>>> Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org
>>>>>>> ,
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Friday, 19 September, 2014 1:18:19 PM
>>>>>>>> Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova
>>>>>> theme
>>>>>>>> IMHO the SSO endpoint could either detect an incoming client (that
>>>>>> would be
>>>>>>>> rather complex)
>>>>>>>>
>>>>>>>> or simply allow user client preference. Can we allow more than one
>>>>>> theme
>>>>>>>> per realm and let the client app choohse?
>>>>>>> Not sure what you mean, we always know which client is requesting the
>>>>>> login
>>>>>>> (it's the client_id query param). The client should only be used for one
>>>>>>> variant of an application as well (so for an app that has a web, android
>>>>>> and
>>>>>>> ios variants, there should be 3 clients configured in KC). So there's no
>>>>>>> problem providing an option to override the theme on a per-client basis.
>>>>>>>
>>>>>>>> On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This raises the question. Should we allow overriding the theme on an
>>>>>>>>> per-application basis?
>>>>>>>>>
>>>>>>>>> It would allow a better integration with the app, but on the other
>>>>>> side
>>>>>>>>> does it even make sense to login to a SSO realm that way?
>>>>>>>>>
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Erik Jan de Wit" < edewit at redhat.com >
>>>>>>>>>> To: "AeroGear Developer Mailing List" <
>>>>>> aerogear-dev at lists.jboss.org >
>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>> Sent: Friday, 19 September, 2014 8:08:02 AM
>>>>>>>>>> Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme
>>>>>>>>>>
>>>>>>>>>> Looks very nice, will this integrate well with the work that
>>>>>> Summers
>>>>>>>>>> did?
>>>>>>>>>>
>>>>>>>>>> On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com >
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yeah and off course, the source is here:
>>>>>>>>>>
>>>>>>>>>> https://github.com/lfryc/keycloak/tree/ionic-styling
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hey guys,
>>>>>>>>>>
>>>>>>>>>> I've started some work on a theme for Keycloak that would include
>>>>>> Ionic
>>>>>>>>>> Framework styling.
>>>>>>>>>>
>>>>>>>>>> This makes sure that Ionic/Cordova demos that includes Keycloak has
>>>>>>>>> smooth
>>>>>>>>>> transition between application and login process / registration.
>>>>>>>>>>
>>>>>>>>>> See attached screenshots.
>>>>>>>>>>
>>>>>>>>>> It's still in early prototypal stage, so just just login,
>>>>>> registration
>>>>>>>>> and
>>>>>>>>>> social (only google) fully works so far, but others can be simply
>>>>>>>>> expanded.
>>>>>>>>>> Feel free to use it in demos or so... ;-)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> ~ Lukas
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> aerogear-dev mailing list
>>>>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> aerogear-dev mailing list
>>>>>>> aerogear-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-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
>>> _______________________________________________
>>> 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  Mon Sep 22 03:44:50 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 22 Sep 2014 09:44:50 +0200
Subject: [keycloak-dev] OAuth2 revoke
In-Reply-To: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>
References: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>
Message-ID: <541FD372.30200@redhat.com>

Hi,

there is exception in the log like:

Caused by: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:8081 refused

isn't it possible that adminURL for some of your applications is not 
configured correctly (like there is localhost:8081 instead of 
localhost:8080)?

Btv. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-709 as 
currently it seems that if ResourceAdminManager.logoutUser wants to call 
logout to more applications (like app1 and app2) and logout to app1 
fails, then RuntimeException is thrown and logout to app2 is not called 
at all, which doesn't seem to be correct behaviour to me.

Marek


On 20.9.2014 17:48, Corinne Krych wrote:
> Hello
>
> Trying to implement AGIOS-206 [1] linked to [2], what iI need is a revoke of all tokens (refresh and access token).
>
> I've tried ?logout? with a refresh token this endpoint:
> http://docs.jboss.org/keycloak/docs/1.0.1.Final/rest-api/realms/%7Brealm%7D/tokens/logout/index.html#POST
> for a public client.
> I run appliance 1.0-final distribution of key cloak.
>
> But I run into this exception [3] after a timeout. Anything else I can try or should I just wait for revoke feature to be implemented in Keycloak?
>
> ++
> Corinne
>
> [1] https://issues.jboss.org/browse/AGIOS-206
> [2] https://issues.jboss.org/browse/KEYCLOAK-312
> [3] https://gist.github.com/corinnekrych/53bd73c4e047281a94f1
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From corinnekrych at gmail.com  Mon Sep 22 04:28:13 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 22 Sep 2014 10:28:13 +0200
Subject: [keycloak-dev] OAuth2 revoke
In-Reply-To: <541FD372.30200@redhat.com>
References: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>
	<541FD372.30200@redhat.com>
Message-ID: <A853EB88-42F9-41C6-9705-45985409C065@gmail.com>

Yep indeed i think it?s an error of configuration but not sure which one i should change. In my use case it?s a oauth2 client app. whe re should I specify the URL redirect for logout?
See my config  file here:
https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L39

do I need to define a product-inventory app? or a simple oauth2 client is enough?

Best Regards,
Corinne
On 22 Sep 2014, at 09:44, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
> 
> there is exception in the log like:
> 
> Caused by: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:8081 refused
> 
> isn't it possible that adminURL for some of your applications is not configured correctly (like there is localhost:8081 instead of localhost:8080)?
> 
> Btv. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-709 as currently it seems that if ResourceAdminManager.logoutUser wants to call logout to more applications (like app1 and app2) and logout to app1 fails, then RuntimeException is thrown and logout to app2 is not called at all, which doesn't seem to be correct behaviour to me.
> 
> Marek
> 
> 
> On 20.9.2014 17:48, Corinne Krych wrote:
>> Hello
>> 
>> Trying to implement AGIOS-206 [1] linked to [2], what iI need is a revoke of all tokens (refresh and access token).
>> 
>> I've tried ?logout? with a refresh token this endpoint:
>> http://docs.jboss.org/keycloak/docs/1.0.1.Final/rest-api/realms/%7Brealm%7D/tokens/logout/index.html#POST
>> for a public client.
>> I run appliance 1.0-final distribution of key cloak.
>> 
>> But I run into this exception [3] after a timeout. Anything else I can try or should I just wait for revoke feature to be implemented in Keycloak?
>> 
>> ++
>> Corinne
>> 
>> [1] https://issues.jboss.org/browse/AGIOS-206
>> [2] https://issues.jboss.org/browse/KEYCLOAK-312
>> [3] https://gist.github.com/corinnekrych/53bd73c4e047281a94f1
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 



From mposolda at redhat.com  Mon Sep 22 05:01:23 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 22 Sep 2014 11:01:23 +0200
Subject: [keycloak-dev] OAuth2 revoke
In-Reply-To: <A853EB88-42F9-41C6-9705-45985409C065@gmail.com>
References: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>
	<541FD372.30200@redhat.com>
	<A853EB88-42F9-41C6-9705-45985409C065@gmail.com>
Message-ID: <541FE563.80004@redhat.com>

In this config, you specified product-inventory to be public OAuth 
client. In this case, you may delete this line:
https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L42
because for public applications/oauth clients, you don't need secret at all.

Also I think the exception with revocation is due to incorrect 
configuration of this application: 
https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L64. 
Do you really have this application running and deployed on 
localhost:8081 ? If not, you can either delete this or update 
configurations.

Also it might be good to update to Keycloak 1.0.1.Final as Stian added 
this fix: https://issues.jboss.org/browse/KEYCLOAK-682 which cause that 
logout is not send to all applications, but just to those when user is 
really logged into.

Marek



On 22.9.2014 10:28, Corinne Krych wrote:
> Yep indeed i think it?s an error of configuration but not sure which one i should change. In my use case it?s a oauth2 client app. whe re should I specify the URL redirect for logout?
> See my config  file here:
> https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L39
>
> do I need to define a product-inventory app? or a simple oauth2 client is enough?
>
> Best Regards,
> Corinne
> On 22 Sep 2014, at 09:44, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> there is exception in the log like:
>>
>> Caused by: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:8081 refused
>>
>> isn't it possible that adminURL for some of your applications is not configured correctly (like there is localhost:8081 instead of localhost:8080)?
>>
>> Btv. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-709 as currently it seems that if ResourceAdminManager.logoutUser wants to call logout to more applications (like app1 and app2) and logout to app1 fails, then RuntimeException is thrown and logout to app2 is not called at all, which doesn't seem to be correct behaviour to me.
>>
>> Marek
>>
>>
>> On 20.9.2014 17:48, Corinne Krych wrote:
>>> Hello
>>>
>>> Trying to implement AGIOS-206 [1] linked to [2], what iI need is a revoke of all tokens (refresh and access token).
>>>
>>> I've tried ?logout? with a refresh token this endpoint:
>>> http://docs.jboss.org/keycloak/docs/1.0.1.Final/rest-api/realms/%7Brealm%7D/tokens/logout/index.html#POST
>>> for a public client.
>>> I run appliance 1.0-final distribution of key cloak.
>>>
>>> But I run into this exception [3] after a timeout. Anything else I can try or should I just wait for revoke feature to be implemented in Keycloak?
>>>
>>> ++
>>> Corinne
>>>
>>> [1] https://issues.jboss.org/browse/AGIOS-206
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-312
>>> [3] https://gist.github.com/corinnekrych/53bd73c4e047281a94f1
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sblanc at redhat.com  Mon Sep 22 09:44:55 2014
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 22 Sep 2014 15:44:55 +0200
Subject: [keycloak-dev] Keycloak 1.0.1 Final Released
In-Reply-To: <283645111.51908422.1411062596314.JavaMail.zimbra@redhat.com>
References: <283645111.51908422.1411062596314.JavaMail.zimbra@redhat.com>
Message-ID: <542027D7.8020600@redhat.com>

On 18/09/14 19:49, Stian Thorgersen wrote:
> We?re releasing a few minor fixes and improvements before we start work on SAML and Clustering.
>
> For the complete list of fixes and improvements go to https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.0.1.Final%20AND%20resolution%20%3D%20Done
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
Has 1.0.1 release been pushed on Maven Central ? I can not find it there.



From ssilvert at redhat.com  Mon Sep 22 13:45:48 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 22 Sep 2014 13:45:48 -0400
Subject: [keycloak-dev] keycloak-server.json
In-Reply-To: <79156121.51420171.1411015411812.JavaMail.zimbra@redhat.com>
References: <5419DDEA.6000205@redhat.com>
	<79156121.51420171.1411015411812.JavaMail.zimbra@redhat.com>
Message-ID: <5420604C.3050004@redhat.com>

On 9/18/2014 12:43 AM, Stian Thorgersen wrote:
> No, I need to do that. I'll sort it out today.
>
> Schema for JSON would be nice ;)
Any progress on this?   If you are too busy and can just point me in the 
right direction I'll give it a shot.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 17 September, 2014 9:15:54 PM
>> Subject: [keycloak-dev] keycloak-server.json
>>
>> Is there any updated doco on keycloak-server.json?  I need to know all
>> the options and their possible values.  All I can find is this, but it's
>> incomplete:
>> https://github.com/keycloak/keycloak/wiki/keycloak-server.json-options
>>
>> Stan
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Mon Sep 22 13:47:33 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 22 Sep 2014 13:47:33 -0400
Subject: [keycloak-dev] keycloak-server.json
In-Reply-To: <5420604C.3050004@redhat.com>
References: <5419DDEA.6000205@redhat.com>
	<79156121.51420171.1411015411812.JavaMail.zimbra@redhat.com>
	<5420604C.3050004@redhat.com>
Message-ID: <542060B5.50505@redhat.com>

On 9/22/2014 1:45 PM, Stan Silvert wrote:
> On 9/18/2014 12:43 AM, Stian Thorgersen wrote:
>> No, I need to do that. I'll sort it out today.
>>
>> Schema for JSON would be nice ;)
> Any progress on this?   If you are too busy and can just point me in the
> right direction I'll give it a shot.
BTW, I don't necessarily need schema.  But I do need to know what 
options are available and a short description with their possible values.
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 17 September, 2014 9:15:54 PM
>>> Subject: [keycloak-dev] keycloak-server.json
>>>
>>> Is there any updated doco on keycloak-server.json?  I need to know all
>>> the options and their possible values.  All I can find is this, but it's
>>> incomplete:
>>> https://github.com/keycloak/keycloak/wiki/keycloak-server.json-options
>>>
>>> Stan
>>> _______________________________________________
>>> 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 Sep 22 16:08:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Sep 2014 16:08:59 -0400
Subject: [keycloak-dev] UserSession changes required for SAML
Message-ID: <542081DB.5050004@redhat.com>

There's a few problems with UserSession and AccessCode and screen flows

* UserSession and AccessCode is hard wired to oauth protocol
* userSession is not created until credentials have been entered
* SAML has state that needs to hang around until final redirect back to 
client
* Final redirect needs to know the protocol that started the login.
* Screen flows assume various query parameters are set (client_id, etc.)

So here's the changes:
* UserSessions will be created when the login page is first visited if 
the user hasn't already logged in.
* ClientSession will also be created when login page is visited. 
setAuthMethod for the ClientSession will be set so that later on, when 
the final redirect happens, the auth server will know which protocol to use
* ClientSession will have a generic string hashmap 
(ClientSession.getNotes()) where you can store arbitrary state.  (i.e. 
like HttpSession, but specific to the client).
* ClientSession.getState() will be removed and put in 
ClientSession.getNotes()
* AccessCode needs to expose the ClientSession instead of hiding and 
delegating to it.
* Screen flows will access the ClientSession for all information required.


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

From bburke at redhat.com  Mon Sep 22 16:14:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Sep 2014 16:14:55 -0400
Subject: [keycloak-dev] sticky sessions for UserSession
Message-ID: <5420833F.1080102@redhat.com>

Was thinking about clustering.  Sticky sessions combined with in-memory 
only UserSessions might be best for clustering.  We'll need to change 
access code processing so that it is a) signed and b) contains the 
callback URL.  In looking at SAML, it jsut seems we need to have the 
notion of an HttpSession and the idea of loading this session from a 
database (or even a clustered cache) doesn't seem very feasible or scalable.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Tue Sep 23 03:09:21 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 23 Sep 2014 09:09:21 +0200
Subject: [keycloak-dev] sticky sessions for UserSession
In-Reply-To: <5420833F.1080102@redhat.com>
References: <5420833F.1080102@redhat.com>
Message-ID: <54211CA1.8040202@redhat.com>

I think that generally there are 2 main purposes of clustering:
a) scalability and better performance (ideally n-times better 
performance with n nodes in cluster)
b) failover

With in-memory session you will achieve (a), but (b) won't be addressed. 
So if you have 2 keycloak nodes and you kill node-1, then all 
UserSessions on node-1 will be lost and users would need to relogin. IMO 
Sticky sessions are good, but there is still need to replicate sessions 
(at least to 1 additional cluster node) if you want to address failover. 
Or am I just not understand correctly what you meant?

Marek

On 22.9.2014 22:14, Bill Burke wrote:
> Was thinking about clustering.  Sticky sessions combined with in-memory
> only UserSessions might be best for clustering.  We'll need to change
> access code processing so that it is a) signed and b) contains the
> callback URL.  In looking at SAML, it jsut seems we need to have the
> notion of an HttpSession and the idea of loading this session from a
> database (or even a clustered cache) doesn't seem very feasible or scalable.


From stian at redhat.com  Tue Sep 23 03:55:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 23 Sep 2014 03:55:44 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.1.Final finally in Maven Central
Message-ID: <1670745448.53728660.1411458944193.JavaMail.zimbra@redhat.com>

Keycloak 1.0.1.Final is finally in Maven Central. I forgot to mark it as released in JBoss Nexus, which is why it never synced to Central.

Sorry for any inconvenience,
Stian

From stian at redhat.com  Tue Sep 23 06:29:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 23 Sep 2014 06:29:21 -0400 (EDT)
Subject: [keycloak-dev] sticky sessions for UserSession
In-Reply-To: <54211CA1.8040202@redhat.com>
References: <5420833F.1080102@redhat.com> <54211CA1.8040202@redhat.com>
Message-ID: <435581910.53805115.1411468161842.JavaMail.zimbra@redhat.com>

I don't like the idea of introducing a sticky session, also I'd prefer if we could at least provide the illusion of Keycloak being stateless.

Some issues with sticky sessions:

1) Load balancer needs session cookie to make requests from browser sticky
2) Also need to make requests from clients "sticky", either by a cookie or by having clients go to a specific url (latter means exposing internal nodes as well as load balancer)
3) Doesn't increase availability - in that case we still need some replication

An alternative solution is to have the user session provider deal with this. I propose we use Infinispan to provide a clustered and sharded in-memory store for user sessions. This means that Keycloak itself doesn't store user-sessions in-memory, but instead delegates this to Infinspan. It also means that if someone really wants to persist user sessions they still can (using clustered relational db, or a sharded mongodb).

With that in mind the stages involved in developing clustering support would be:

1) Use JPA (or Mongo) stores for everything with no caches
2) Use Docker to easily create a cluster (multiple Keycloak instances and Apache load balancer) for testing
3) Create a cluster testsuite
4) Enable realm cache - using jgroups to send cache invalidation messages (messages are signed with realm key and contain no sensitive data, only id that is invalidated, so doesn't need to be encrypted)
5) Enable user cache - same as 4, but for users
6) Infinispan User Session provider
   6.1) No replication or sharding
   6.2) Replicated for availability
   6.3) Sharded for scalability

This would support any load balancer (where the load balancer is the only externally visible url) and a cluster of Keycloak servers. Any Keycloak server can process any request. In non-clustered config we can use a single in-memory Infinispan cache to retrieve user sessions from (so there's no need to maintain a separate in-mem user session store). For increasing availability we can have multiple Infinispan nodes that replicates all user sessions. Finally, for increased scalability Infinispan would shard on user-session-id.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 9:09:21 AM
> Subject: Re: [keycloak-dev] sticky sessions for UserSession
> 
> I think that generally there are 2 main purposes of clustering:
> a) scalability and better performance (ideally n-times better
> performance with n nodes in cluster)
> b) failover
> 
> With in-memory session you will achieve (a), but (b) won't be addressed.
> So if you have 2 keycloak nodes and you kill node-1, then all
> UserSessions on node-1 will be lost and users would need to relogin. IMO
> Sticky sessions are good, but there is still need to replicate sessions
> (at least to 1 additional cluster node) if you want to address failover.
> Or am I just not understand correctly what you meant?
> 
> Marek
> 
> On 22.9.2014 22:14, Bill Burke wrote:
> > Was thinking about clustering.  Sticky sessions combined with in-memory
> > only UserSessions might be best for clustering.  We'll need to change
> > access code processing so that it is a) signed and b) contains the
> > callback URL.  In looking at SAML, it jsut seems we need to have the
> > notion of an HttpSession and the idea of loading this session from a
> > database (or even a clustered cache) doesn't seem very feasible or
> > scalable.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Sep 23 07:24:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Sep 2014 07:24:36 -0400
Subject: [keycloak-dev] sticky sessions for UserSession
In-Reply-To: <54211CA1.8040202@redhat.com>
References: <5420833F.1080102@redhat.com> <54211CA1.8040202@redhat.com>
Message-ID: <54215874.7090901@redhat.com>

Failures should be a rare event and performance is more important than 
session retention, IMO.  Replication is an expensive luxury and is not a 
requirement for failover.  We just need to ensure that users can relogin 
on a node failure.

On 9/23/2014 3:09 AM, Marek Posolda wrote:
> I think that generally there are 2 main purposes of clustering:
> a) scalability and better performance (ideally n-times better
> performance with n nodes in cluster)
> b) failover
>
> With in-memory session you will achieve (a), but (b) won't be addressed.
> So if you have 2 keycloak nodes and you kill node-1, then all
> UserSessions on node-1 will be lost and users would need to relogin. IMO
> Sticky sessions are good, but there is still need to replicate sessions
> (at least to 1 additional cluster node) if you want to address failover.
> Or am I just not understand correctly what you meant?
>
> Marek
>
> On 22.9.2014 22:14, Bill Burke wrote:
>> Was thinking about clustering.  Sticky sessions combined with in-memory
>> only UserSessions might be best for clustering.  We'll need to change
>> access code processing so that it is a) signed and b) contains the
>> callback URL.  In looking at SAML, it jsut seems we need to have the
>> notion of an HttpSession and the idea of loading this session from a
>> database (or even a clustered cache) doesn't seem very feasible or
>> scalable.
>

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

From stian at redhat.com  Tue Sep 23 09:16:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 23 Sep 2014 09:16:37 -0400 (EDT)
Subject: [keycloak-dev] sticky sessions for UserSession
In-Reply-To: <435581910.53805115.1411468161842.JavaMail.zimbra@redhat.com>
References: <5420833F.1080102@redhat.com> <54211CA1.8040202@redhat.com>
	<435581910.53805115.1411468161842.JavaMail.zimbra@redhat.com>
Message-ID: <1748643033.53909975.1411478197267.JavaMail.zimbra@redhat.com>

Another issue with sticky sessions is that it would be difficult to implement queries (retrieve all user sessions and client sessions), remove expired sessions, etc..

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 12:29:21 PM
> Subject: Re: [keycloak-dev] sticky sessions for UserSession
> 
> I don't like the idea of introducing a sticky session, also I'd prefer if we
> could at least provide the illusion of Keycloak being stateless.
> 
> Some issues with sticky sessions:
> 
> 1) Load balancer needs session cookie to make requests from browser sticky
> 2) Also need to make requests from clients "sticky", either by a cookie or by
> having clients go to a specific url (latter means exposing internal nodes as
> well as load balancer)
> 3) Doesn't increase availability - in that case we still need some
> replication
> 
> An alternative solution is to have the user session provider deal with this.
> I propose we use Infinispan to provide a clustered and sharded in-memory
> store for user sessions. This means that Keycloak itself doesn't store
> user-sessions in-memory, but instead delegates this to Infinspan. It also
> means that if someone really wants to persist user sessions they still can
> (using clustered relational db, or a sharded mongodb).
> 
> With that in mind the stages involved in developing clustering support would
> be:
> 
> 1) Use JPA (or Mongo) stores for everything with no caches
> 2) Use Docker to easily create a cluster (multiple Keycloak instances and
> Apache load balancer) for testing
> 3) Create a cluster testsuite
> 4) Enable realm cache - using jgroups to send cache invalidation messages
> (messages are signed with realm key and contain no sensitive data, only id
> that is invalidated, so doesn't need to be encrypted)
> 5) Enable user cache - same as 4, but for users
> 6) Infinispan User Session provider
>    6.1) No replication or sharding
>    6.2) Replicated for availability
>    6.3) Sharded for scalability
> 
> This would support any load balancer (where the load balancer is the only
> externally visible url) and a cluster of Keycloak servers. Any Keycloak
> server can process any request. In non-clustered config we can use a single
> in-memory Infinispan cache to retrieve user sessions from (so there's no
> need to maintain a separate in-mem user session store). For increasing
> availability we can have multiple Infinispan nodes that replicates all user
> sessions. Finally, for increased scalability Infinispan would shard on
> user-session-id.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 23 September, 2014 9:09:21 AM
> > Subject: Re: [keycloak-dev] sticky sessions for UserSession
> > 
> > I think that generally there are 2 main purposes of clustering:
> > a) scalability and better performance (ideally n-times better
> > performance with n nodes in cluster)
> > b) failover
> > 
> > With in-memory session you will achieve (a), but (b) won't be addressed.
> > So if you have 2 keycloak nodes and you kill node-1, then all
> > UserSessions on node-1 will be lost and users would need to relogin. IMO
> > Sticky sessions are good, but there is still need to replicate sessions
> > (at least to 1 additional cluster node) if you want to address failover.
> > Or am I just not understand correctly what you meant?
> > 
> > Marek
> > 
> > On 22.9.2014 22:14, Bill Burke wrote:
> > > Was thinking about clustering.  Sticky sessions combined with in-memory
> > > only UserSessions might be best for clustering.  We'll need to change
> > > access code processing so that it is a) signed and b) contains the
> > > callback URL.  In looking at SAML, it jsut seems we need to have the
> > > notion of an HttpSession and the idea of loading this session from a
> > > database (or even a clustered cache) doesn't seem very feasible or
> > > scalable.
> > 
> > _______________________________________________
> > 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  Tue Sep 23 09:24:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Sep 2014 09:24:34 -0400
Subject: [keycloak-dev] sticky sessions for UserSession
In-Reply-To: <1748643033.53909975.1411478197267.JavaMail.zimbra@redhat.com>
References: <5420833F.1080102@redhat.com>
	<54211CA1.8040202@redhat.com>	<435581910.53805115.1411468161842.JavaMail.zimbra@redhat.com>
	<1748643033.53909975.1411478197267.JavaMail.zimbra@redhat.com>
Message-ID: <54217492.3040204@redhat.com>

True.

On 9/23/2014 9:16 AM, Stian Thorgersen wrote:
> Another issue with sticky sessions is that it would be difficult to implement queries (retrieve all user sessions and client sessions), remove expired sessions, etc..
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 23 September, 2014 12:29:21 PM
>> Subject: Re: [keycloak-dev] sticky sessions for UserSession
>>
>> I don't like the idea of introducing a sticky session, also I'd prefer if we
>> could at least provide the illusion of Keycloak being stateless.
>>
>> Some issues with sticky sessions:
>>
>> 1) Load balancer needs session cookie to make requests from browser sticky
>> 2) Also need to make requests from clients "sticky", either by a cookie or by
>> having clients go to a specific url (latter means exposing internal nodes as
>> well as load balancer)
>> 3) Doesn't increase availability - in that case we still need some
>> replication
>>
>> An alternative solution is to have the user session provider deal with this.
>> I propose we use Infinispan to provide a clustered and sharded in-memory
>> store for user sessions. This means that Keycloak itself doesn't store
>> user-sessions in-memory, but instead delegates this to Infinspan. It also
>> means that if someone really wants to persist user sessions they still can
>> (using clustered relational db, or a sharded mongodb).
>>
>> With that in mind the stages involved in developing clustering support would
>> be:
>>
>> 1) Use JPA (or Mongo) stores for everything with no caches
>> 2) Use Docker to easily create a cluster (multiple Keycloak instances and
>> Apache load balancer) for testing
>> 3) Create a cluster testsuite
>> 4) Enable realm cache - using jgroups to send cache invalidation messages
>> (messages are signed with realm key and contain no sensitive data, only id
>> that is invalidated, so doesn't need to be encrypted)
>> 5) Enable user cache - same as 4, but for users
>> 6) Infinispan User Session provider
>>     6.1) No replication or sharding
>>     6.2) Replicated for availability
>>     6.3) Sharded for scalability
>>
>> This would support any load balancer (where the load balancer is the only
>> externally visible url) and a cluster of Keycloak servers. Any Keycloak
>> server can process any request. In non-clustered config we can use a single
>> in-memory Infinispan cache to retrieve user sessions from (so there's no
>> need to maintain a separate in-mem user session store). For increasing
>> availability we can have multiple Infinispan nodes that replicates all user
>> sessions. Finally, for increased scalability Infinispan would shard on
>> user-session-id.
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 23 September, 2014 9:09:21 AM
>>> Subject: Re: [keycloak-dev] sticky sessions for UserSession
>>>
>>> I think that generally there are 2 main purposes of clustering:
>>> a) scalability and better performance (ideally n-times better
>>> performance with n nodes in cluster)
>>> b) failover
>>>
>>> With in-memory session you will achieve (a), but (b) won't be addressed.
>>> So if you have 2 keycloak nodes and you kill node-1, then all
>>> UserSessions on node-1 will be lost and users would need to relogin. IMO
>>> Sticky sessions are good, but there is still need to replicate sessions
>>> (at least to 1 additional cluster node) if you want to address failover.
>>> Or am I just not understand correctly what you meant?
>>>
>>> Marek
>>>
>>> On 22.9.2014 22:14, Bill Burke wrote:
>>>> Was thinking about clustering.  Sticky sessions combined with in-memory
>>>> only UserSessions might be best for clustering.  We'll need to change
>>>> access code processing so that it is a) signed and b) contains the
>>>> callback URL.  In looking at SAML, it jsut seems we need to have the
>>>> notion of an HttpSession and the idea of loading this session from a
>>>> database (or even a clustered cache) doesn't seem very feasible or
>>>> scalable.
>>>
>>> _______________________________________________
>>> 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 bburke at redhat.com  Tue Sep 23 11:04:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Sep 2014 11:04:46 -0400
Subject: [keycloak-dev] Purpose of UserSession.getAuthMethod()?
Message-ID: <54218C0E.8020006@redhat.com>

What is the purpose of UserSession.getAuthMethod()?  What does it mean? 
  I need something similar, but it needs to be tied to the ClientSession.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Sep 23 12:49:07 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 23 Sep 2014 12:49:07 -0400 (EDT)
Subject: [keycloak-dev] Purpose of UserSession.getAuthMethod()?
In-Reply-To: <54218C0E.8020006@redhat.com>
References: <54218C0E.8020006@redhat.com>
Message-ID: <751183287.54080694.1411490947113.JavaMail.zimbra@redhat.com>

It's used to know how the user logged in. There's currently a few valid values:

* form - standard Keycloak login
* oauth_credentials - direct grant
* social@<social provider> (for example social at google) - social login

Currently it's only purpose is for the EventListener and audit.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 5:04:46 PM
> Subject: [keycloak-dev] Purpose of UserSession.getAuthMethod()?
> 
> What is the purpose of UserSession.getAuthMethod()?  What does it mean?
>   I need something similar, but it needs to be tied to the ClientSession.
> --
> 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 Sep 23 16:23:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 23 Sep 2014 16:23:08 -0400
Subject: [keycloak-dev] UserSession changes required for SAML
In-Reply-To: <542081DB.5050004@redhat.com>
References: <542081DB.5050004@redhat.com>
Message-ID: <5421D6AC.7020509@redhat.com>

Ugh, this is getting hairy, but doable.  I'm changing things around.


The Login page will create a ClientSession that is not yet attached to a 
UserSession.  A reference to this ClientSession will be passed around 
via a query parameter (like you currently do for AccessCode) between 
user actions (registration, social login, reset password, login totp, 
etc.).  Only when Keycloak is ready to redirect back to the client will 
a UserSession be created and the ClientSession attached to it.

On 9/22/2014 4:08 PM, Bill Burke wrote:
> There's a few problems with UserSession and AccessCode and screen flows
>
> * UserSession and AccessCode is hard wired to oauth protocol
> * userSession is not created until credentials have been entered
> * SAML has state that needs to hang around until final redirect back to
> client
> * Final redirect needs to know the protocol that started the login.
> * Screen flows assume various query parameters are set (client_id, etc.)
>
> So here's the changes:
> * UserSessions will be created when the login page is first visited if
> the user hasn't already logged in.
> * ClientSession will also be created when login page is visited.
> setAuthMethod for the ClientSession will be set so that later on, when
> the final redirect happens, the auth server will know which protocol to use
> * ClientSession will have a generic string hashmap
> (ClientSession.getNotes()) where you can store arbitrary state.  (i.e.
> like HttpSession, but specific to the client).
> * ClientSession.getState() will be removed and put in
> ClientSession.getNotes()
> * AccessCode needs to expose the ClientSession instead of hiding and
> delegating to it.
> * Screen flows will access the ClientSession for all information required.
>
>

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

From stian at redhat.com  Wed Sep 24 03:40:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 24 Sep 2014 03:40:03 -0400 (EDT)
Subject: [keycloak-dev] UserSession changes required for SAML
In-Reply-To: <5421D6AC.7020509@redhat.com>
References: <542081DB.5050004@redhat.com> <5421D6AC.7020509@redhat.com>
Message-ID: <1678079339.54452103.1411544403050.JavaMail.zimbra@redhat.com>

I was worried it would get messy :|

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 23 September, 2014 9:23:08 PM
> Subject: Re: [keycloak-dev] UserSession changes required for SAML
> 
> Ugh, this is getting hairy, but doable.  I'm changing things around.
> 
> 
> The Login page will create a ClientSession that is not yet attached to a
> UserSession.  A reference to this ClientSession will be passed around
> via a query parameter (like you currently do for AccessCode) between
> user actions (registration, social login, reset password, login totp,
> etc.).  Only when Keycloak is ready to redirect back to the client will
> a UserSession be created and the ClientSession attached to it.
> 
> On 9/22/2014 4:08 PM, Bill Burke wrote:
> > There's a few problems with UserSession and AccessCode and screen flows
> >
> > * UserSession and AccessCode is hard wired to oauth protocol
> > * userSession is not created until credentials have been entered
> > * SAML has state that needs to hang around until final redirect back to
> > client
> > * Final redirect needs to know the protocol that started the login.
> > * Screen flows assume various query parameters are set (client_id, etc.)
> >
> > So here's the changes:
> > * UserSessions will be created when the login page is first visited if
> > the user hasn't already logged in.
> > * ClientSession will also be created when login page is visited.
> > setAuthMethod for the ClientSession will be set so that later on, when
> > the final redirect happens, the auth server will know which protocol to use
> > * ClientSession will have a generic string hashmap
> > (ClientSession.getNotes()) where you can store arbitrary state.  (i.e.
> > like HttpSession, but specific to the client).
> > * ClientSession.getState() will be removed and put in
> > ClientSession.getNotes()
> > * AccessCode needs to expose the ClientSession instead of hiding and
> > delegating to it.
> > * Screen flows will access the ClientSession for all information required.
> >
> >
> 
> --
> 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 Sep 25 09:32:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 25 Sep 2014 09:32:32 -0400
Subject: [keycloak-dev] Keycloak Intergration
In-Reply-To: <CAA_YYjbijycCA0UZhL9MQa0wFWPKP2_qZ_77DArC5NKxb-Vexw@mail.gmail.com>
References: <CAA_YYjbijycCA0UZhL9MQa0wFWPKP2_qZ_77DArC5NKxb-Vexw@mail.gmail.com>
Message-ID: <54241970.6000608@redhat.com>

Sagar,  I'm moving this to keycloak-dev list.  See comments inline

On 9/25/2014 6:53 AM, Sagar Zond wrote:
> Hi,
>
> We are planning to use KeyClock for OAuth authorization server for our
> API platform. Our understanding to KeyClock and OAuth is not very clear
> so need your help to properly utilize KeyClock features.
>
> Just to introduce our self, we are a start-up firm and creating products
> for Health care domain. In our architecture we will have multiple Rest
> API servers and multiple types of client like mobile, web and publicly
> expose API. KeyCloak can be used as authentication and authorization
> server. We have already gone through most of KeyCloak tutorials.
>
> Here are few points of which we need answer -
>
> 1. API platform will be registered as application server on KeyClock and
> clients (mobile app, web app or other app) will be authorized by
> keyclock as per defined role. Is this a proper use case of KeyClock ?
>

You'll have to elaborate.  I don't know exactly what you are saying. 
Your REST API server would be registered as a Keycloak "Application". 
You can define roles per "Application" or at the Realm level (global roles).

> 2. How do we integrate OAuth into mobile app ? Where can we write token
> refresh logic?
>

You can start off by defining an public "OAuth Client" per mobile app. 
You can use the direct grant REST API to obtain a token, or, use mobile 
redirects to login through the mobile's browser.  I believe the Aerogear 
project is doing some work around Keycloak IOS and Android clients, but 
you'd have to ping them.

> 3. How we can add more fields in session? e.g. if we want to add more
> token in header which may contain some extra application specific
> encrypted data.
>

Not sure what you mean.  We don't have a nice way of adding claims to 
the token at the moment.

> 4. We are currently using OpenDS Ldap for authentication and we already
> have number of registered users which currently using API. So we need
> Keyclock to be configured for OpenDS, so please suggested how to
> integrate OpenDS with KeyClock.
>

We have LDAP integration:

http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/user_federation.html#d4e1263



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

From corinnekrych at gmail.com  Thu Sep 25 10:19:51 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Thu, 25 Sep 2014 16:19:51 +0200
Subject: [keycloak-dev] OAuth2 revoke
In-Reply-To: <541FE563.80004@redhat.com>
References: <F96F4C24-0A91-4290-85F8-36DA71DB4A34@gmail.com>
	<541FD372.30200@redhat.com>
	<A853EB88-42F9-41C6-9705-45985409C065@gmail.com>
	<541FE563.80004@redhat.com>
Message-ID: <D89C0355-78BE-49F9-B253-AD483BBBE1B2@gmail.com>

Thanks Marek
Indeed with a correct backend realm config [1], I have a Swift iOS helloworld type demo[2] with request/refresh/revoke tokens working just fine.
Next step, I want to share how to use oauth2 with KC and iOS with a blog post.

++
Corinne
[1] https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L59
[2] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/ProductInventory


On 22 Sep 2014, at 11:01, Marek Posolda <mposolda at redhat.com> wrote:

> In this config, you specified product-inventory to be public OAuth client. In this case, you may delete this line:
> https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L42
> because for public applications/oauth clients, you don't need secret at all.
> 
> Also I think the exception with revocation is due to incorrect configuration of this application: https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L64. Do you really have this application running and deployed on localhost:8081 ? If not, you can either delete this or update configurations.
> 
> Also it might be good to update to Keycloak 1.0.1.Final as Stian added this fix: https://issues.jboss.org/browse/KEYCLOAK-682 which cause that logout is not send to all applications, but just to those when user is really logged into.
> 
> Marek
> 
> 
> 
> On 22.9.2014 10:28, Corinne Krych wrote:
>> Yep indeed i think it?s an error of configuration but not sure which one i should change. In my use case it?s a oauth2 client app. whe re should I specify the URL redirect for logout?
>> See my config  file here:
>> https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/ProductInventory/configuration/testrealm.json#L39
>> 
>> do I need to define a product-inventory app? or a simple oauth2 client is enough?
>> 
>> Best Regards,
>> Corinne
>> On 22 Sep 2014, at 09:44, Marek Posolda <mposolda at redhat.com> wrote:
>> 
>>> Hi,
>>> 
>>> there is exception in the log like:
>>> 
>>> Caused by: org.apache.http.conn.HttpHostConnectException: Connection to http://localhost:8081 refused
>>> 
>>> isn't it possible that adminURL for some of your applications is not configured correctly (like there is localhost:8081 instead of localhost:8080)?
>>> 
>>> Btv. I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-709 as currently it seems that if ResourceAdminManager.logoutUser wants to call logout to more applications (like app1 and app2) and logout to app1 fails, then RuntimeException is thrown and logout to app2 is not called at all, which doesn't seem to be correct behaviour to me.
>>> 
>>> Marek
>>> 
>>> 
>>> On 20.9.2014 17:48, Corinne Krych wrote:
>>>> Hello
>>>> 
>>>> Trying to implement AGIOS-206 [1] linked to [2], what iI need is a revoke of all tokens (refresh and access token).
>>>> 
>>>> I've tried ?logout? with a refresh token this endpoint:
>>>> http://docs.jboss.org/keycloak/docs/1.0.1.Final/rest-api/realms/%7Brealm%7D/tokens/logout/index.html#POST
>>>> for a public client.
>>>> I run appliance 1.0-final distribution of key cloak.
>>>> 
>>>> But I run into this exception [3] after a timeout. Anything else I can try or should I just wait for revoke feature to be implemented in Keycloak?
>>>> 
>>>> ++
>>>> Corinne
>>>> 
>>>> [1] https://issues.jboss.org/browse/AGIOS-206
>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-312
>>>> [3] https://gist.github.com/corinnekrych/53bd73c4e047281a94f1
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 



From corinnekrych at gmail.com  Thu Sep 25 11:36:13 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Thu, 25 Sep 2014 17:36:13 +0200
Subject: [keycloak-dev] Keycloak Intergration
In-Reply-To: <54241970.6000608@redhat.com>
References: <CAA_YYjbijycCA0UZhL9MQa0wFWPKP2_qZ_77DArC5NKxb-Vexw@mail.gmail.com>
	<54241970.6000608@redhat.com>
Message-ID: <B195DA9D-A960-48CD-8A10-12D5837CBAA5@gmail.com>

Hello Sagar,

For Keycloak OAuth2, AeroGear provides a sdk, we have both Obj-C and Swift. Although lastest features goes in Swift version.

1. AeroGear-iOS 1.6 targets obj-c code [1] with its associated test repo [2], [2bis]

2. AeroGear 2.0 is modularized and based on Swift:
aerogear-ios-http [3]
aerogear-ios-oauth2 [4]
Here you can find interesting access/refresh/revoke simple example:
aerogear-ios-cookbook [5]
aerogear-backend-cookbook [6]
Note that 2.0 is on its way and should be release early October.
http module (aerogear-ios-http coupled with aerogear-ios-oauth2) is taking care of refreshing implictly tokens for you. 

Some blog posts [7]. I?m actually going to write an update blog post for Swift version.
Some links to go through.. Feedback welcome.

++
Corinne
iOS AeroGear
[1] https://github.com/aerogear/aerogear-ios
[2] https://github.com/aerogear/aerogear-ios-cookbook/tree/master/ProductInventory
[2bis] https://github.com/aerogear/aerogear-integration-tests-server#oauth2-with-keycloak
[3] https://github.com/aerogear/aerogear-ios-http
[4] https://github.com/aerogear/aerogear-ios-oauth2
[5] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/ProductInventory
[6] https://github.com/corinnekrych/aerogear-backend-cookbook/tree/master/ProductInventory
[7] http://corinnekrych.blogspot.fr/search/label/OAuth2

On 25 Sep 2014, at 15:32, Bill Burke <bburke at redhat.com> wrote:

> Sagar,  I'm moving this to keycloak-dev list.  See comments inline
> 
> On 9/25/2014 6:53 AM, Sagar Zond wrote:
>> Hi,
>> 
>> We are planning to use KeyClock for OAuth authorization server for our
>> API platform. Our understanding to KeyClock and OAuth is not very clear
>> so need your help to properly utilize KeyClock features.
>> 
>> Just to introduce our self, we are a start-up firm and creating products
>> for Health care domain. In our architecture we will have multiple Rest
>> API servers and multiple types of client like mobile, web and publicly
>> expose API. KeyCloak can be used as authentication and authorization
>> server. We have already gone through most of KeyCloak tutorials.
>> 
>> Here are few points of which we need answer -
>> 
>> 1. API platform will be registered as application server on KeyClock and
>> clients (mobile app, web app or other app) will be authorized by
>> keyclock as per defined role. Is this a proper use case of KeyClock ?
>> 
> 
> You'll have to elaborate.  I don't know exactly what you are saying. 
> Your REST API server would be registered as a Keycloak "Application". 
> You can define roles per "Application" or at the Realm level (global roles).
> 
>> 2. How do we integrate OAuth into mobile app ? Where can we write token
>> refresh logic?
>> 
> 
> You can start off by defining an public "OAuth Client" per mobile app. 
> You can use the direct grant REST API to obtain a token, or, use mobile 
> redirects to login through the mobile's browser.  I believe the Aerogear 
> project is doing some work around Keycloak IOS and Android clients, but 
> you'd have to ping them.
> 
>> 3. How we can add more fields in session? e.g. if we want to add more
>> token in header which may contain some extra application specific
>> encrypted data.
>> 
> 
> Not sure what you mean.  We don't have a nice way of adding claims to 
> the token at the moment.
> 
>> 4. We are currently using OpenDS Ldap for authentication and we already
>> have number of registered users which currently using API. So we need
>> Keyclock to be configured for OpenDS, so please suggested how to
>> integrate OpenDS with KeyClock.
>> 
> 
> We have LDAP integration:
> 
> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/user_federation.html#d4e1263
> 
> 
> 
> -- 
> 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 Sep 25 11:37:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 25 Sep 2014 11:37:24 -0400
Subject: [keycloak-dev] merge master to Branch_1_0
Message-ID: <542436B4.6030305@redhat.com>

When I finish my initial refactoring to allow multi-protocol login, I'm 
going to merge master to Branch_1_0 first.  After the security audit 
team is done with Keycloak, I'll do a 1.0.2 release from this branch.

Is there anything currently in master that shouldn't be in 1.0.2?


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

From stian at redhat.com  Thu Sep 25 11:50:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 25 Sep 2014 11:50:37 -0400 (EDT)
Subject: [keycloak-dev] merge master to Branch_1_0
In-Reply-To: <542436B4.6030305@redhat.com>
References: <542436B4.6030305@redhat.com>
Message-ID: <1892334506.55788240.1411660237157.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 25 September, 2014 5:37:24 PM
> Subject: [keycloak-dev] merge master to Branch_1_0
> 
> When I finish my initial refactoring to allow multi-protocol login, I'm
> going to merge master to Branch_1_0 first.  After the security audit
> team is done with Keycloak, I'll do a 1.0.2 release from this branch.
> 
> Is there anything currently in master that shouldn't be in 1.0.2?

Nopes... I've got Infinispan User Session provider ready to go, but was going to hold off until after your refactoring.

> 
> 
> --
> 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  Thu Sep 25 15:42:35 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 25 Sep 2014 15:42:35 -0400
Subject: [keycloak-dev] loading keycloak-server.json
Message-ID: <5424702B.4060009@redhat.com>

Anyone have a problem with adding a param to this loadConfig() method?
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/KeycloakApplication.java#L106

If keycloak-server.json is loaded from the Keycloak subsystem then it 
will come in through the ServletContext as a String.  So I want to pass 
in the ServletContext.

The reason I ask is because this is a public method.  It looks like it 
is only public because a test tool wants to call it.
https://github.com/keycloak/keycloak/blob/master/testsuite/tools/src/main/java/org/keycloak/test/tools/KeycloakTestApplication.java#L25

Would anyone in the real world ever call loadConfig()?  Should it really 
be public?

I can change the method to package private and change the package of the 
test tool to match.  That's the way I've always handled it when a test 
class absolutely must call a non-public method.

Comments?

From stian at redhat.com  Fri Sep 26 02:37:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 26 Sep 2014 02:37:58 -0400 (EDT)
Subject: [keycloak-dev] loading keycloak-server.json
In-Reply-To: <5424702B.4060009@redhat.com>
References: <5424702B.4060009@redhat.com>
Message-ID: <927781472.56297224.1411713478640.JavaMail.zimbra@redhat.com>

Adding param is fine, but make the method protected so anyone that extends KeycloakApplication can access it.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 25 September, 2014 9:42:35 PM
> Subject: [keycloak-dev] loading keycloak-server.json
> 
> Anyone have a problem with adding a param to this loadConfig() method?
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/KeycloakApplication.java#L106
> 
> If keycloak-server.json is loaded from the Keycloak subsystem then it
> will come in through the ServletContext as a String.  So I want to pass
> in the ServletContext.
> 
> The reason I ask is because this is a public method.  It looks like it
> is only public because a test tool wants to call it.
> https://github.com/keycloak/keycloak/blob/master/testsuite/tools/src/main/java/org/keycloak/test/tools/KeycloakTestApplication.java#L25
> 
> Would anyone in the real world ever call loadConfig()?  Should it really
> be public?
> 
> I can change the method to package private and change the package of the
> test tool to match.  That's the way I've always handled it when a test
> class absolutely must call a non-public method.
> 
> Comments?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Sep 26 11:27:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 26 Sep 2014 11:27:03 -0400
Subject: [keycloak-dev] Ok to have no direct links to...
Message-ID: <542585C7.3050703@redhat.com>

I need some input.

It is ok for, registration page and social link buttons to only be 
linkable from within a Keycloak login page?

The idea is that there would be a OAUTH specific and SAML specific login 
page entry point where client ids are verified and a ClientSessionModel 
is created.  Registration page, social login links, required user 
actions would all be driven by a ClientSession code and would not be 
linkable to from the outside world.  This allows those pages to be 
completely separate from the login protocol being used.

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

From bburke at redhat.com  Fri Sep 26 18:04:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 26 Sep 2014 18:04:58 -0400
Subject: [keycloak-dev] need more time
Message-ID: <5425E30A.2080108@redhat.com>

I need more time on the refactoring of login actions.  So far I've 
refactored all the code to

* create a ClientSession when login page is visited
* Pass around a "client session code" as a query parameter that 
references the client session
* Store state within the client session instead of in query and form 
parameters
* Refactor Social login to use a client session.  This allowed me to 
remove the "KEYCLOAK_SOCIAL" cookie.

I have all this building correctly.

Next steps are to create a "protocol adapter" interface and have all 
login actions use this adapter instead of being hardcoded to oauth.  I 
probably won't get this done until late next week.   After that I'll 
start on SAML and the "protocol adapter" interface will probably go 
through another iteration.

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

From stian at redhat.com  Mon Sep 29 02:32:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 02:32:43 -0400 (EDT)
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542585C7.3050703@redhat.com>
References: <542585C7.3050703@redhat.com>
Message-ID: <1127817335.57638585.1411972363709.JavaMail.zimbra@redhat.com>

I think registration page should be linkable from the outside. Social links doesn't need to.

We also have some required actions that are links sent to emails (reset password, verify email, etc.).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 26 September, 2014 5:27:03 PM
> Subject: [keycloak-dev] Ok to have no direct links to...
> 
> I need some input.
> 
> It is ok for, registration page and social link buttons to only be
> linkable from within a Keycloak login page?
> 
> The idea is that there would be a OAUTH specific and SAML specific login
> page entry point where client ids are verified and a ClientSessionModel
> is created.  Registration page, social login links, required user
> actions would all be driven by a ClientSession code and would not be
> linkable to from the outside world.  This allows those pages to be
> completely separate from the login protocol being used.
> 
> --
> 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 Sep 29 02:34:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 02:34:29 -0400 (EDT)
Subject: [keycloak-dev] need more time
In-Reply-To: <5425E30A.2080108@redhat.com>
References: <5425E30A.2080108@redhat.com>
Message-ID: <1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>

Can I commit the Infinispan user sessions provider? Or do you want me to wait until you've commited the refactoring?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 27 September, 2014 12:04:58 AM
> Subject: [keycloak-dev] need more time
> 
> I need more time on the refactoring of login actions.  So far I've
> refactored all the code to
> 
> * create a ClientSession when login page is visited
> * Pass around a "client session code" as a query parameter that
> references the client session
> * Store state within the client session instead of in query and form
> parameters
> * Refactor Social login to use a client session.  This allowed me to
> remove the "KEYCLOAK_SOCIAL" cookie.
> 
> I have all this building correctly.
> 
> Next steps are to create a "protocol adapter" interface and have all
> login actions use this adapter instead of being hardcoded to oauth.  I
> probably won't get this done until late next week.   After that I'll
> start on SAML and the "protocol adapter" interface will probably go
> through another iteration.
> 
> --
> 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 Sep 29 02:38:58 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 29 Sep 2014 08:38:58 +0200
Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
Message-ID: <5428FE82.8070303@redhat.com>

I wonder if it's ok to add possibility to WildFly/AS7 adapter for 
alternative resolving of relative redirectUris. Currently it's always 
retrieved from HTTP request sent by browser (ie. with relative uri 
"/auth" and HTTP request is "http://localhost:8080/customer-portal" then 
adapter is able to resolve the URI to "http://localhost:8080/auth"). Is 
it ok to have possibility (perhaps boolean config option on adapter like 
"preserve-hostname") to resolve them from the actual hostname instead of 
browser request? Usually it's not much difference, but in cluster there 
might be scenario like:
- Setup with loadbalancer on "http://frontend:8080" and 2 backend 
cluster nodes "http://backend-node1:8080" and "http://backend-node2:8080"
- Then user filled login form. Now assume that request request with 
code+state is processed on 
"http://backend-node1:8080/customer-portal?code=...&state=..." . Now 
adapter sends codeToToken exchanging request  to relative URI, which is 
resolved from browser to "http://frontend:8080". So adapter sends 
request to loadbalancer, which is then resended back to one of backend 
nodes. So 2 additional network hops needed.

So when there is possibility to resolve relative URI from hostname, then 
backend-node1 will send exchanging request to itself instead of going 
through loadbalancer. In cluster it should help to save performance and 
reduce network communication.

Note that this will be configurable and will be used by adapters just 
for backend requests (codeToToken, refresh token etc). All browser 
redirects will still need to go through loadbalancer IMO, in usual 
cluster environments are cluster nodes hidden in private network and URI 
like "http://backend-node1:8080/auth" may not be available for users.

wdyt?

Marek

From stian at redhat.com  Mon Sep 29 02:58:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 02:58:39 -0400 (EDT)
Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
In-Reply-To: <5428FE82.8070303@redhat.com>
References: <5428FE82.8070303@redhat.com>
Message-ID: <720881848.57650371.1411973919000.JavaMail.zimbra@redhat.com>

To avoid sending all traffic through a proxy it would be better to either:

* Use round-robin DNS
* Use HTTP redirect from http://frontend:8080 to http://backend-node1:8080

However, neither what you propose or HTTP redirect would work with cookies. Round-robin DNS would though and IMO that's the cleanest way to do it.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 29 September, 2014 8:38:58 AM
> Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
> 
> I wonder if it's ok to add possibility to WildFly/AS7 adapter for
> alternative resolving of relative redirectUris. Currently it's always
> retrieved from HTTP request sent by browser (ie. with relative uri
> "/auth" and HTTP request is "http://localhost:8080/customer-portal" then
> adapter is able to resolve the URI to "http://localhost:8080/auth"). Is
> it ok to have possibility (perhaps boolean config option on adapter like
> "preserve-hostname") to resolve them from the actual hostname instead of
> browser request? Usually it's not much difference, but in cluster there
> might be scenario like:
> - Setup with loadbalancer on "http://frontend:8080" and 2 backend
> cluster nodes "http://backend-node1:8080" and "http://backend-node2:8080"
> - Then user filled login form. Now assume that request request with
> code+state is processed on
> "http://backend-node1:8080/customer-portal?code=...&state=..." . Now
> adapter sends codeToToken exchanging request  to relative URI, which is
> resolved from browser to "http://frontend:8080". So adapter sends
> request to loadbalancer, which is then resended back to one of backend
> nodes. So 2 additional network hops needed.
> 
> So when there is possibility to resolve relative URI from hostname, then
> backend-node1 will send exchanging request to itself instead of going
> through loadbalancer. In cluster it should help to save performance and
> reduce network communication.
> 
> Note that this will be configurable and will be used by adapters just
> for backend requests (codeToToken, refresh token etc). All browser
> redirects will still need to go through loadbalancer IMO, in usual
> cluster environments are cluster nodes hidden in private network and URI
> like "http://backend-node1:8080/auth" may not be available for users.
> 
> wdyt?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Sep 29 03:42:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 03:42:32 -0400 (EDT)
Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
In-Reply-To: <720881848.57650371.1411973919000.JavaMail.zimbra@redhat.com>
References: <5428FE82.8070303@redhat.com>
	<720881848.57650371.1411973919000.JavaMail.zimbra@redhat.com>
Message-ID: <1941143689.57703830.1411976552840.JavaMail.zimbra@redhat.com>

Ignore my email - I didn't read the email properly (Monday @ 9am isn't a good time to read technical emails).

It's a good idea and we should add it. Adapters will often be located behind the firewall and can communicate directly with Keycloak servers so shouldn't need to go through the proxy server.

Made me think, maybe we could add a in-vm transport for refreshing tokens etc.. That would further lower the overhead of refreshing tokens if applications are co-located on the same WildFly server.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 29 September, 2014 8:58:39 AM
> Subject: Re: [keycloak-dev] Resolving of relative redirectUri in cluster
> 
> To avoid sending all traffic through a proxy it would be better to either:
> 
> * Use round-robin DNS
> * Use HTTP redirect from http://frontend:8080 to http://backend-node1:8080
> 
> However, neither what you propose or HTTP redirect would work with cookies.
> Round-robin DNS would though and IMO that's the cleanest way to do it.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, 29 September, 2014 8:38:58 AM
> > Subject: [keycloak-dev] Resolving of relative redirectUri in cluster
> > 
> > I wonder if it's ok to add possibility to WildFly/AS7 adapter for
> > alternative resolving of relative redirectUris. Currently it's always
> > retrieved from HTTP request sent by browser (ie. with relative uri
> > "/auth" and HTTP request is "http://localhost:8080/customer-portal" then
> > adapter is able to resolve the URI to "http://localhost:8080/auth"). Is
> > it ok to have possibility (perhaps boolean config option on adapter like
> > "preserve-hostname") to resolve them from the actual hostname instead of
> > browser request? Usually it's not much difference, but in cluster there
> > might be scenario like:
> > - Setup with loadbalancer on "http://frontend:8080" and 2 backend
> > cluster nodes "http://backend-node1:8080" and "http://backend-node2:8080"
> > - Then user filled login form. Now assume that request request with
> > code+state is processed on
> > "http://backend-node1:8080/customer-portal?code=...&state=..." . Now
> > adapter sends codeToToken exchanging request  to relative URI, which is
> > resolved from browser to "http://frontend:8080". So adapter sends
> > request to loadbalancer, which is then resended back to one of backend
> > nodes. So 2 additional network hops needed.
> > 
> > So when there is possibility to resolve relative URI from hostname, then
> > backend-node1 will send exchanging request to itself instead of going
> > through loadbalancer. In cluster it should help to save performance and
> > reduce network communication.
> > 
> > Note that this will be configurable and will be used by adapters just
> > for backend requests (codeToToken, refresh token etc). All browser
> > redirects will still need to go through loadbalancer IMO, in usual
> > cluster environments are cluster nodes hidden in private network and URI
> > like "http://backend-node1:8080/auth" may not be available for users.
> > 
> > wdyt?
> > 
> > Marek
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Sep 29 07:29:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 07:29:52 -0400 (EDT)
Subject: [keycloak-dev] Update on clustering support
In-Reply-To: <829055860.57800861.1411989286588.JavaMail.zimbra@redhat.com>
Message-ID: <1838461146.57807840.1411990192096.JavaMail.zimbra@redhat.com>

A quick update on clustering work. The plan is:

* Infinispan User Session Provider - supports local, distributed and replicated modes / almost completed
* Infinispan Realm Cache - supports local and invalidation modes (should not be used in distributed/replicated modes) / almost completed
* Infinispan User Cache - supports local and invalidation modes (should not be used in distributed/replicated modes) / almost completed
* Clustering support for adapters 
   - Support stateless (no http session) and distributed http session / not started
   - Support direct communication with Keycloak (avoid proxy when auth-server url is relative) / not started
* Security for clustering - use an interceptor to sign/verify messages with realm keys - question is, do we really need this? Nodes need to be on the same subnet, realm/users are invalidation only and the only thing a malicious node could do with user sessions is to prevent them from expiring.
* Docker config for setting up test environment / almost completed
* Cluster testsuite / not started
* Jenkins clustering tests / not sure we'll get around to this

We're aiming to complete the above work by the end of the week, and release 1.1.0.Final with clustering support next week (or should we wait for SAML?).

With regards to using Infinispan for realm and user cache invalidation. Reasoning for using this instead of a custom solution include:

* Significantly less time to impl (took only ~2h to impl!)
* Multicast/jgroups is much more efficient compared to http messages
* No need to deal with cluster memberships, disconnect/partitions, etc ourselves
* Infinispan provides loads of configuration options (evictions, transports, cache-modes, etc.)
* Sensitive data never transferred between nodes (only invalidation messages)
* We can still sign messages with realm keys for security
* In theory we could also support distributed and replicated cache-modes in the future - not sure this makes sense (maybe for users only?), also we're certainly not doing it for this round

From bburke at redhat.com  Mon Sep 29 08:31:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Sep 2014 08:31:42 -0400
Subject: [keycloak-dev] need more time
In-Reply-To: <1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
Message-ID: <5429512E.8060906@redhat.com>

I can commit my stuff now, but it is a work in progress.  Up to you. 
API has changed a little:

https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models


On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
> Can I commit the Infinispan user sessions provider? Or do you want me to wait until you've commited the refactoring?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 27 September, 2014 12:04:58 AM
>> Subject: [keycloak-dev] need more time
>>
>> I need more time on the refactoring of login actions.  So far I've
>> refactored all the code to
>>
>> * create a ClientSession when login page is visited
>> * Pass around a "client session code" as a query parameter that
>> references the client session
>> * Store state within the client session instead of in query and form
>> parameters
>> * Refactor Social login to use a client session.  This allowed me to
>> remove the "KEYCLOAK_SOCIAL" cookie.
>>
>> I have all this building correctly.
>>
>> Next steps are to create a "protocol adapter" interface and have all
>> login actions use this adapter instead of being hardcoded to oauth.  I
>> probably won't get this done until late next week.   After that I'll
>> start on SAML and the "protocol adapter" interface will probably go
>> through another iteration.
>>
>> --
>> 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  Mon Sep 29 09:03:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 09:03:27 -0400 (EDT)
Subject: [keycloak-dev] need more time
In-Reply-To: <5429512E.8060906@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
Message-ID: <1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>

Are you expecting more changes to sessions? Is it fully working atm?

I'd like to finish clustering this week and hopefully release next week (see separate email I sent).

----- 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, 29 September, 2014 2:31:42 PM
> Subject: Re: [keycloak-dev] need more time
> 
> I can commit my stuff now, but it is a work in progress.  Up to you.
> API has changed a little:
> 
> https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models
> 
> 
> On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
> > Can I commit the Infinispan user sessions provider? Or do you want me to
> > wait until you've commited the refactoring?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Saturday, 27 September, 2014 12:04:58 AM
> >> Subject: [keycloak-dev] need more time
> >>
> >> I need more time on the refactoring of login actions.  So far I've
> >> refactored all the code to
> >>
> >> * create a ClientSession when login page is visited
> >> * Pass around a "client session code" as a query parameter that
> >> references the client session
> >> * Store state within the client session instead of in query and form
> >> parameters
> >> * Refactor Social login to use a client session.  This allowed me to
> >> remove the "KEYCLOAK_SOCIAL" cookie.
> >>
> >> I have all this building correctly.
> >>
> >> Next steps are to create a "protocol adapter" interface and have all
> >> login actions use this adapter instead of being hardcoded to oauth.  I
> >> probably won't get this done until late next week.   After that I'll
> >> start on SAML and the "protocol adapter" interface will probably go
> >> through another iteration.
> >>
> >> --
> >> 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  Mon Sep 29 09:04:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Sep 2014 09:04:46 -0400
Subject: [keycloak-dev] need more time
In-Reply-To: <1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
Message-ID: <542958EE.2020803@redhat.com>

I don't think session api will change any more.  But everything else 
will  (required actions, token service, etc.)

On 9/29/2014 9:03 AM, Stian Thorgersen wrote:
> Are you expecting more changes to sessions? Is it fully working atm?
>
> I'd like to finish clustering this week and hopefully release next week (see separate email I sent).
>
> ----- 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, 29 September, 2014 2:31:42 PM
>> Subject: Re: [keycloak-dev] need more time
>>
>> I can commit my stuff now, but it is a work in progress.  Up to you.
>> API has changed a little:
>>
>> https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models
>>
>>
>> On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
>>> Can I commit the Infinispan user sessions provider? Or do you want me to
>>> wait until you've commited the refactoring?
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Saturday, 27 September, 2014 12:04:58 AM
>>>> Subject: [keycloak-dev] need more time
>>>>
>>>> I need more time on the refactoring of login actions.  So far I've
>>>> refactored all the code to
>>>>
>>>> * create a ClientSession when login page is visited
>>>> * Pass around a "client session code" as a query parameter that
>>>> references the client session
>>>> * Store state within the client session instead of in query and form
>>>> parameters
>>>> * Refactor Social login to use a client session.  This allowed me to
>>>> remove the "KEYCLOAK_SOCIAL" cookie.
>>>>
>>>> I have all this building correctly.
>>>>
>>>> Next steps are to create a "protocol adapter" interface and have all
>>>> login actions use this adapter instead of being hardcoded to oauth.  I
>>>> probably won't get this done until late next week.   After that I'll
>>>> start on SAML and the "protocol adapter" interface will probably go
>>>> through another iteration.
>>>>
>>>> --
>>>> 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
>>

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

From stian at redhat.com  Mon Sep 29 09:11:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 09:11:31 -0400 (EDT)
Subject: [keycloak-dev] need more time
In-Reply-To: <542958EE.2020803@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
Message-ID: <1486387971.57879045.1411996291571.JavaMail.zimbra@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, 29 September, 2014 3:04:46 PM
> Subject: Re: [keycloak-dev] need more time
> 
> I don't think session api will change any more.  But everything else
> will  (required actions, token service, etc.)

Ok - my vote is commit the changes then

I'd like to delete mem/jpa/mongo user session providers, and only leave the Infinispan provider.

> 
> On 9/29/2014 9:03 AM, Stian Thorgersen wrote:
> > Are you expecting more changes to sessions? Is it fully working atm?
> >
> > I'd like to finish clustering this week and hopefully release next week
> > (see separate email I sent).
> >
> > ----- 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, 29 September, 2014 2:31:42 PM
> >> Subject: Re: [keycloak-dev] need more time
> >>
> >> I can commit my stuff now, but it is a work in progress.  Up to you.
> >> API has changed a little:
> >>
> >> https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models
> >>
> >>
> >> On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
> >>> Can I commit the Infinispan user sessions provider? Or do you want me to
> >>> wait until you've commited the refactoring?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Saturday, 27 September, 2014 12:04:58 AM
> >>>> Subject: [keycloak-dev] need more time
> >>>>
> >>>> I need more time on the refactoring of login actions.  So far I've
> >>>> refactored all the code to
> >>>>
> >>>> * create a ClientSession when login page is visited
> >>>> * Pass around a "client session code" as a query parameter that
> >>>> references the client session
> >>>> * Store state within the client session instead of in query and form
> >>>> parameters
> >>>> * Refactor Social login to use a client session.  This allowed me to
> >>>> remove the "KEYCLOAK_SOCIAL" cookie.
> >>>>
> >>>> I have all this building correctly.
> >>>>
> >>>> Next steps are to create a "protocol adapter" interface and have all
> >>>> login actions use this adapter instead of being hardcoded to oauth.  I
> >>>> probably won't get this done until late next week.   After that I'll
> >>>> start on SAML and the "protocol adapter" interface will probably go
> >>>> through another iteration.
> >>>>
> >>>> --
> >>>> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon Sep 29 09:17:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Sep 2014 09:17:32 -0400
Subject: [keycloak-dev] need more time
In-Reply-To: <1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
	<1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
Message-ID: <54295BEC.3030809@redhat.com>

Why do you want to delete mem, jpa, and mongo providers?  IMO, we 
shouldn't have a hard dependency on Infinispan.  In the future, users 
might want a jpa or mongo provider with a cache in front of it so they 
can archive user sessions.

On 9/29/2014 9:11 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: Monday, 29 September, 2014 3:04:46 PM
>> Subject: Re: [keycloak-dev] need more time
>>
>> I don't think session api will change any more.  But everything else
>> will  (required actions, token service, etc.)
>
> Ok - my vote is commit the changes then
>
> I'd like to delete mem/jpa/mongo user session providers, and only leave the Infinispan provider.
>
>>
>> On 9/29/2014 9:03 AM, Stian Thorgersen wrote:
>>> Are you expecting more changes to sessions? Is it fully working atm?
>>>
>>> I'd like to finish clustering this week and hopefully release next week
>>> (see separate email I sent).
>>>
>>> ----- 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, 29 September, 2014 2:31:42 PM
>>>> Subject: Re: [keycloak-dev] need more time
>>>>
>>>> I can commit my stuff now, but it is a work in progress.  Up to you.
>>>> API has changed a little:
>>>>
>>>> https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models
>>>>
>>>>
>>>> On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
>>>>> Can I commit the Infinispan user sessions provider? Or do you want me to
>>>>> wait until you've commited the refactoring?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Saturday, 27 September, 2014 12:04:58 AM
>>>>>> Subject: [keycloak-dev] need more time
>>>>>>
>>>>>> I need more time on the refactoring of login actions.  So far I've
>>>>>> refactored all the code to
>>>>>>
>>>>>> * create a ClientSession when login page is visited
>>>>>> * Pass around a "client session code" as a query parameter that
>>>>>> references the client session
>>>>>> * Store state within the client session instead of in query and form
>>>>>> parameters
>>>>>> * Refactor Social login to use a client session.  This allowed me to
>>>>>> remove the "KEYCLOAK_SOCIAL" cookie.
>>>>>>
>>>>>> I have all this building correctly.
>>>>>>
>>>>>> Next steps are to create a "protocol adapter" interface and have all
>>>>>> login actions use this adapter instead of being hardcoded to oauth.  I
>>>>>> probably won't get this done until late next week.   After that I'll
>>>>>> start on SAML and the "protocol adapter" interface will probably go
>>>>>> through another iteration.
>>>>>>
>>>>>> --
>>>>>> 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
>>>>
>>
>> --
>> 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  Mon Sep 29 10:02:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Sep 2014 10:02:40 -0400
Subject: [keycloak-dev] merged initial login refactor
Message-ID: <54296680.70403@redhat.com>

See details in my previous email.  There's still a lot to do, but I 
think the UserSession/ClientSessionModel/UserSessionProvider apis are 
stable now.

Bill

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

From stian at redhat.com  Mon Sep 29 10:40:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 10:40:43 -0400 (EDT)
Subject: [keycloak-dev] need more time
In-Reply-To: <54295BEC.3030809@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
	<1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
	<54295BEC.3030809@redhat.com>
Message-ID: <327405710.57959334.1412001643985.JavaMail.zimbra@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, 29 September, 2014 3:17:32 PM
> Subject: Re: [keycloak-dev] need more time
> 
> Why do you want to delete mem, jpa, and mongo providers?  IMO, we
> shouldn't have a hard dependency on Infinispan.  In the future, users
> might want a jpa or mongo provider with a cache in front of it so they
> can archive user sessions.

Ok, I don't have an issue with leaving them. I guess not having a hard dep on would be good.

I was just thinking a bit of cleanup to reduce code that needs to be maintained ;)

> 
> On 9/29/2014 9:11 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: Monday, 29 September, 2014 3:04:46 PM
> >> Subject: Re: [keycloak-dev] need more time
> >>
> >> I don't think session api will change any more.  But everything else
> >> will  (required actions, token service, etc.)
> >
> > Ok - my vote is commit the changes then
> >
> > I'd like to delete mem/jpa/mongo user session providers, and only leave the
> > Infinispan provider.
> >
> >>
> >> On 9/29/2014 9:03 AM, Stian Thorgersen wrote:
> >>> Are you expecting more changes to sessions? Is it fully working atm?
> >>>
> >>> I'd like to finish clustering this week and hopefully release next week
> >>> (see separate email I sent).
> >>>
> >>> ----- 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, 29 September, 2014 2:31:42 PM
> >>>> Subject: Re: [keycloak-dev] need more time
> >>>>
> >>>> I can commit my stuff now, but it is a work in progress.  Up to you.
> >>>> API has changed a little:
> >>>>
> >>>> https://github.com/patriot1burke/keycloak/tree/master/model/api/src/main/java/org/keycloak/models
> >>>>
> >>>>
> >>>> On 9/29/2014 2:34 AM, Stian Thorgersen wrote:
> >>>>> Can I commit the Infinispan user sessions provider? Or do you want me
> >>>>> to
> >>>>> wait until you've commited the refactoring?
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Saturday, 27 September, 2014 12:04:58 AM
> >>>>>> Subject: [keycloak-dev] need more time
> >>>>>>
> >>>>>> I need more time on the refactoring of login actions.  So far I've
> >>>>>> refactored all the code to
> >>>>>>
> >>>>>> * create a ClientSession when login page is visited
> >>>>>> * Pass around a "client session code" as a query parameter that
> >>>>>> references the client session
> >>>>>> * Store state within the client session instead of in query and form
> >>>>>> parameters
> >>>>>> * Refactor Social login to use a client session.  This allowed me to
> >>>>>> remove the "KEYCLOAK_SOCIAL" cookie.
> >>>>>>
> >>>>>> I have all this building correctly.
> >>>>>>
> >>>>>> Next steps are to create a "protocol adapter" interface and have all
> >>>>>> login actions use this adapter instead of being hardcoded to oauth.  I
> >>>>>> probably won't get this done until late next week.   After that I'll
> >>>>>> start on SAML and the "protocol adapter" interface will probably go
> >>>>>> through another iteration.
> >>>>>>
> >>>>>> --
> >>>>>> 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
> >>>>
> >>
> >> --
> >> 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  Mon Sep 29 11:15:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Sep 2014 11:15:06 -0400
Subject: [keycloak-dev] need more time
In-Reply-To: <327405710.57959334.1412001643985.JavaMail.zimbra@redhat.com>
References: <5425E30A.2080108@redhat.com>
	<1204161107.57638884.1411972469600.JavaMail.zimbra@redhat.com>
	<5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
	<1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
	<54295BEC.3030809@redhat.com>
	<327405710.57959334.1412001643985.JavaMail.zimbra@redhat.com>
Message-ID: <5429777A.4040909@redhat.com>



On 9/29/2014 10:40 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: Monday, 29 September, 2014 3:17:32 PM
>> Subject: Re: [keycloak-dev] need more time
>>
>> Why do you want to delete mem, jpa, and mongo providers?  IMO, we
>> shouldn't have a hard dependency on Infinispan.  In the future, users
>> might want a jpa or mongo provider with a cache in front of it so they
>> can archive user sessions.
>
> Ok, I don't have an issue with leaving them. I guess not having a hard dep on would be good.
>
> I was just thinking a bit of cleanup to reduce code that needs to be maintained ;)
>

Remove mongo?

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

From stian at redhat.com  Mon Sep 29 12:44:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Sep 2014 12:44:20 -0400 (EDT)
Subject: [keycloak-dev] need more time
In-Reply-To: <5429777A.4040909@redhat.com>
References: <5425E30A.2080108@redhat.com> <5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
	<1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
	<54295BEC.3030809@redhat.com>
	<327405710.57959334.1412001643985.JavaMail.zimbra@redhat.com>
	<5429777A.4040909@redhat.com>
Message-ID: <2130109608.58088647.1412009060805.JavaMail.zimbra@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, 29 September, 2014 5:15:06 PM
> Subject: Re: [keycloak-dev] need more time
> 
> 
> 
> On 9/29/2014 10:40 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: Monday, 29 September, 2014 3:17:32 PM
> >> Subject: Re: [keycloak-dev] need more time
> >>
> >> Why do you want to delete mem, jpa, and mongo providers?  IMO, we
> >> shouldn't have a hard dependency on Infinispan.  In the future, users
> >> might want a jpa or mongo provider with a cache in front of it so they
> >> can archive user sessions.
> >
> > Ok, I don't have an issue with leaving them. I guess not having a hard dep
> > on would be good.
> >
> > I was just thinking a bit of cleanup to reduce code that needs to be
> > maintained ;)
> >
> 
> Remove mongo?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ssilvert at redhat.com  Mon Sep 29 13:04:27 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 29 Sep 2014 13:04:27 -0400
Subject: [keycloak-dev] need more time
In-Reply-To: <2130109608.58088647.1412009060805.JavaMail.zimbra@redhat.com>
References: <5425E30A.2080108@redhat.com> <5429512E.8060906@redhat.com>
	<1517903932.57872933.1411995807629.JavaMail.zimbra@redhat.com>
	<542958EE.2020803@redhat.com>
	<1486387971.57879045.1411996291571.JavaMail.zimbra@redhat.com>
	<54295BEC.3030809@redhat.com>
	<327405710.57959334.1412001643985.JavaMail.zimbra@redhat.com>
	<5429777A.4040909@redhat.com>
	<2130109608.58088647.1412009060805.JavaMail.zimbra@redhat.com>
Message-ID: <5429911B.4090408@redhat.com>

On 9/29/2014 12:44 PM, 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: Monday, 29 September, 2014 5:15:06 PM
>> Subject: Re: [keycloak-dev] need more time
>>
>>
>>
>> On 9/29/2014 10:40 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: Monday, 29 September, 2014 3:17:32 PM
>>>> Subject: Re: [keycloak-dev] need more time
>>>>
>>>> Why do you want to delete mem, jpa, and mongo providers?  IMO, we
>>>> shouldn't have a hard dependency on Infinispan.  In the future, users
>>>> might want a jpa or mongo provider with a cache in front of it so they
>>>> can archive user sessions.
>>> Ok, I don't have an issue with leaving them. I guess not having a hard dep
>>> on would be good.
>>>
>>> I was just thinking a bit of cleanup to reduce code that needs to be
>>> maintained ;)
>>>
>> Remove mongo?
Mongo no go. Mongo stay with Sheriff Bart. Sheriff Bart first man ever 
whip Mongo. Mongo impressed. Have deep feelings for Sheriff Bart.
>> --
>> 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 corinnekrych at gmail.com  Tue Sep 30 09:28:48 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 30 Sep 2014 15:28:48 +0200
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542585C7.3050703@redhat.com>
References: <542585C7.3050703@redhat.com>
Message-ID: <62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>


On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:

> I need some input.
> 
> It is ok for, registration page and social link buttons to only be 
> linkable from within a Keycloak login page?
> 

When you say keyclaok login page, does it have to ba web-based page?

What about mobile native app?
It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk. 
Like google+plus btutton for example:
https://developers.google.com/+/mobile/ios/sign-in


> The idea is that there would be a OAUTH specific and SAML specific login 
> page entry point where client ids are verified and a ClientSessionModel 
> is created.  Registration page, social login links, required user 
> actions would all be driven by a ClientSession code and would not be 
> linkable to from the outside world.  This allows those pages to be 
> completely separate from the login protocol being used.
> 
> -- 
> 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 Sep 30 09:31:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 30 Sep 2014 09:31:27 -0400
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
Message-ID: <542AB0AF.705@redhat.com>



On 9/30/2014 9:28 AM, Corinne Krych wrote:
>
> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
>
>> I need some input.
>>
>> It is ok for, registration page and social link buttons to only be
>> linkable from within a Keycloak login page?
>>
>
> When you say keyclaok login page, does it have to ba web-based page?
>
> What about mobile native app?
> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
> Like google+plus btutton for example:
> https://developers.google.com/+/mobile/ios/sign-in
>

Somebody on the Aerogear project implemented something like this for 
Android.  They may be doing the same for iOS too.

Bill

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

From corinnekrych at gmail.com  Tue Sep 30 09:41:50 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 30 Sep 2014 15:41:50 +0200
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542AB0AF.705@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com>
Message-ID: <69916117-758B-4EE0-BDAE-2F916D6A3455@gmail.com>

ah oki, I guess I misunderstood " only be linlkable from within a login page?.
Let me look at implementing "logging with keycloak account" in iOS.
++
Corinne
AeroGear iOS dev

On 30 Sep 2014, at 15:31, Bill Burke <bburke at redhat.com> wrote:

> 
> 
> On 9/30/2014 9:28 AM, Corinne Krych wrote:
>> 
>> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
>> 
>>> I need some input.
>>> 
>>> It is ok for, registration page and social link buttons to
>>> linkable from within a Keycloak login page?
>>> 
>> 
>> When you say keyclaok login page, does it have to ba web-based page?
>> 
>> What about mobile native app?
>> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
>> Like google+plus btutton for example:
>> https://developers.google.com/+/mobile/ios/sign-in
>> 
> 
> Somebody on the Aerogear project implemented something like this for Android.  They may be doing the same for iOS too.
> 
> Bill
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com



From daniel at passos.me  Tue Sep 30 10:03:10 2014
From: daniel at passos.me (Daniel Passos)
Date: Tue, 30 Sep 2014 11:03:10 -0300
Subject: [keycloak-dev] Keycloak Intergration
In-Reply-To: <B195DA9D-A960-48CD-8A10-12D5837CBAA5@gmail.com>
References: <CAA_YYjbijycCA0UZhL9MQa0wFWPKP2_qZ_77DArC5NKxb-Vexw@mail.gmail.com>
	<54241970.6000608@redhat.com>
	<B195DA9D-A960-48CD-8A10-12D5837CBAA5@gmail.com>
Message-ID: <CAKjsGbvxiwhhrQ9NJz1LkJYW3Y809HJ8pueRKYJM4R4RpSEMBw@mail.gmail.com>

Hey Sagar,

In AeroGear Android[1] land we have the same need to integrate with
KeyCloak using OAuth2[2]. We are modularizing our library so keep in touch
for the new Authz lib/module[3].

In related news we're planning to add Android Integration with KeyCloak
using Android Account Manager[4] like we did in this PoC[5][6]. We have
more information about that in this thread[7]

[1] http://github.com/aerogear/aerogear-android
[2] http://aerogear.org/docs/guides/aerogear-android/authz/
[3] https://github.com/aerogear/aerogear-android-authz
[4]
http://developer.android.com/reference/android/accounts/AccountManager.html
[5] https://plus.google.com/+SummersPittman/posts/WSFbdodMsej
[6] https://github.com/secondsun/keycloak-android-authenticator
[7] http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002589.html

-- Passos

On Thu, Sep 25, 2014 at 12:36 PM, Corinne Krych <corinnekrych at gmail.com>
wrote:

> Hello Sagar,
>
> For Keycloak OAuth2, AeroGear provides a sdk, we have both Obj-C and
> Swift. Although lastest features goes in Swift version.
>
> 1. AeroGear-iOS 1.6 targets obj-c code [1] with its associated test repo
> [2], [2bis]
>
> 2. AeroGear 2.0 is modularized and based on Swift:
> aerogear-ios-http [3]
> aerogear-ios-oauth2 [4]
> Here you can find interesting access/refresh/revoke simple example:
> aerogear-ios-cookbook [5]
> aerogear-backend-cookbook [6]
> Note that 2.0 is on its way and should be release early October.
> http module (aerogear-ios-http coupled with aerogear-ios-oauth2) is taking
> care of refreshing implictly tokens for you.
>
> Some blog posts [7]. I?m actually going to write an update blog post for
> Swift version.
> Some links to go through.. Feedback welcome.
>
> ++
> Corinne
> iOS AeroGear
> [1] https://github.com/aerogear/aerogear-ios
> [2]
> https://github.com/aerogear/aerogear-ios-cookbook/tree/master/ProductInventory
> [2bis]
> https://github.com/aerogear/aerogear-integration-tests-server#oauth2-with-keycloak
> [3] https://github.com/aerogear/aerogear-ios-http
> [4] https://github.com/aerogear/aerogear-ios-oauth2
> [5]
> https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/ProductInventory
> [6]
> https://github.com/corinnekrych/aerogear-backend-cookbook/tree/master/ProductInventory
> [7] http://corinnekrych.blogspot.fr/search/label/OAuth2
>
> On 25 Sep 2014, at 15:32, Bill Burke <bburke at redhat.com> wrote:
>
> > Sagar,  I'm moving this to keycloak-dev list.  See comments inline
> >
> > On 9/25/2014 6:53 AM, Sagar Zond wrote:
> >> Hi,
> >>
> >> We are planning to use KeyClock for OAuth authorization server for our
> >> API platform. Our understanding to KeyClock and OAuth is not very clear
> >> so need your help to properly utilize KeyClock features.
> >>
> >> Just to introduce our self, we are a start-up firm and creating products
> >> for Health care domain. In our architecture we will have multiple Rest
> >> API servers and multiple types of client like mobile, web and publicly
> >> expose API. KeyCloak can be used as authentication and authorization
> >> server. We have already gone through most of KeyCloak tutorials.
> >>
> >> Here are few points of which we need answer -
> >>
> >> 1. API platform will be registered as application server on KeyClock and
> >> clients (mobile app, web app or other app) will be authorized by
> >> keyclock as per defined role. Is this a proper use case of KeyClock ?
> >>
> >
> > You'll have to elaborate.  I don't know exactly what you are saying.
> > Your REST API server would be registered as a Keycloak "Application".
> > You can define roles per "Application" or at the Realm level (global
> roles).
> >
> >> 2. How do we integrate OAuth into mobile app ? Where can we write token
> >> refresh logic?
> >>
> >
> > You can start off by defining an public "OAuth Client" per mobile app.
> > You can use the direct grant REST API to obtain a token, or, use mobile
> > redirects to login through the mobile's browser.  I believe the Aerogear
> > project is doing some work around Keycloak IOS and Android clients, but
> > you'd have to ping them.
> >
> >> 3. How we can add more fields in session? e.g. if we want to add more
> >> token in header which may contain some extra application specific
> >> encrypted data.
> >>
> >
> > Not sure what you mean.  We don't have a nice way of adding claims to
> > the token at the moment.
> >
> >> 4. We are currently using OpenDS Ldap for authentication and we already
> >> have number of registered users which currently using API. So we need
> >> Keyclock to be configured for OpenDS, so please suggested how to
> >> integrate OpenDS with KeyClock.
> >>
> >
> > We have LDAP integration:
> >
> >
> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/user_federation.html#d4e1263
> >
> >
> >
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140930/3079cde3/attachment-0001.html 

From supittma at redhat.com  Tue Sep 30 10:12:00 2014
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 Sep 2014 10:12:00 -0400
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542AB0AF.705@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com>
Message-ID: <542ABA30.2050801@redhat.com>

On 9/30/2014 9:31 AM, Bill Burke wrote:
>
> On 9/30/2014 9:28 AM, Corinne Krych wrote:
>> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I need some input.
>>>
>>> It is ok for, registration page and social link buttons to only be
>>> linkable from within a Keycloak login page?
>>>
>> When you say keyclaok login page, does it have to ba web-based page?
>>
>> What about mobile native app?
>> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
>> Like google+plus btutton for example:
>> https://developers.google.com/+/mobile/ios/sign-in
>>
> Somebody on the Aerogear project implemented something like this for
> Android.  They may be doing the same for iOS too.
I have no plans on doing things for iOS. The Android Authenticator just 
displays a webview of the login page and detects when then "code" 
parameter is in the response URI.
>
> Bill
>


From corinnekrych at gmail.com  Tue Sep 30 10:33:04 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Tue, 30 Sep 2014 16:33:04 +0200
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542ABA30.2050801@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
Message-ID: <623A7936-709F-4BB2-8801-74F36A83D403@gmail.com>

Bill

Just to rephrase my initial question.
Will it be possible to have an iOS (i.e.: or an android button) like ?login to keycloack account?? without embedding a web view that I can add to my native app?
Is there any endpoint available for that already?

++
Corinne
On 30 Sep 2014, at 16:12, Summers Pittman <supittma at redhat.com> wrote:

> On 9/30/2014 9:31 AM, Bill Burke wrote:
>> 
>> On 9/30/2014 9:28 AM, Corinne Krych wrote:
>>> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>>> I need some input.
>>>> 
>>>> It is ok for, registration page and social link buttons to only be
>>>> linkable from within a Keycloak login page?
>>>> 
>>> When you say keyclaok login page, does it have to ba web-based page?
>>> 
>>> What about mobile native app?
>>> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
>>> Like google+plus btutton for example:
>>> https://developers.google.com/+/mobile/ios/sign-in
>>> 
>> Somebody on the Aerogear project implemented something like this for
>> Android.  They may be doing the same for iOS too.
> I have no plans on doing things for iOS. The Android Authenticator just 
> displays a webview of the login page and detects when then "code" 
> parameter is in the response URI.
>> 
>> Bill
>> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From supittma at redhat.com  Tue Sep 30 10:36:38 2014
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 30 Sep 2014 10:36:38 -0400
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <623A7936-709F-4BB2-8801-74F36A83D403@gmail.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
	<623A7936-709F-4BB2-8801-74F36A83D403@gmail.com>
Message-ID: <542ABFF6.50608@redhat.com>

On Tuesday, September 30, 2014 10:33:04 AM, Corinne Krych wrote:
> Bill
>
> Just to rephrase my initial question.
> Will it be possible to have an iOS (i.e.: or an android button) like ?login to keycloack account?? without embedding a web view that I can add to my native app?
> Is there any endpoint available for that already?

And if there is, can we have it exposed for OAuth clients in the 
keycloak.json file?

The Android Authenticator PoC can, in theory, get lots of settings from 
the json config.  Right now there aren't many to pull out.

>
> ++
> Corinne
> On 30 Sep 2014, at 16:12, Summers Pittman <supittma at redhat.com> wrote:
>
>> On 9/30/2014 9:31 AM, Bill Burke wrote:
>>>
>>> On 9/30/2014 9:28 AM, Corinne Krych wrote:
>>>> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> I need some input.
>>>>>
>>>>> It is ok for, registration page and social link buttons to only be
>>>>> linkable from within a Keycloak login page?
>>>>>
>>>> When you say keyclaok login page, does it have to ba web-based page?
>>>>
>>>> What about mobile native app?
>>>> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
>>>> Like google+plus btutton for example:
>>>> https://developers.google.com/+/mobile/ios/sign-in
>>>>
>>> Somebody on the Aerogear project implemented something like this for
>>> Android.  They may be doing the same for iOS too.
>> I have no plans on doing things for iOS. The Android Authenticator just
>> displays a webview of the login page and detects when then "code"
>> parameter is in the response URI.
>>>
>>> Bill
>>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



From bruno at abstractj.org  Tue Sep 30 19:06:13 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 30 Sep 2014 16:06:13 -0700
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <542ABA30.2050801@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
Message-ID: <20140930230613.GA26685@abstractj.org>

Back from vacations, I think would be nice if it doesn't exist already
endpoints like Corinne mentioned.

Webviews from the security side of the things are a bad idea for mobile apps. I wouldn't like
to use that if possible.

On 2014-09-30, Summers Pittman wrote:
> On 9/30/2014 9:31 AM, Bill Burke wrote:
> >
> > On 9/30/2014 9:28 AM, Corinne Krych wrote:
> >> On 26 Sep 2014, at 17:27, Bill Burke <bburke at redhat.com> wrote:
> >>
> >>> I need some input.
> >>>
> >>> It is ok for, registration page and social link buttons to only be
> >>> linkable from within a Keycloak login page?
> >>>
> >> When you say keyclaok login page, does it have to ba web-based page?
> >>
> >> What about mobile native app?
> >> It would be nice to have the option for an iOS mobile app to add ?MykeycloakServername login? customizable button from the native app sdk.
> >> Like google+plus btutton for example:
> >> https://developers.google.com/+/mobile/ios/sign-in
> >>
> > Somebody on the Aerogear project implemented something like this for
> > Android.  They may be doing the same for iOS too.
> I have no plans on doing things for iOS. The Android Authenticator just
> displays a webview of the login page and detects when then "code"
> parameter is in the response URI.
> >
> > Bill
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From ssilvert at redhat.com  Tue Sep 30 21:43:21 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 30 Sep 2014 21:43:21 -0400
Subject: [keycloak-dev] auth-server and WEB-INF/lib
Message-ID: <542B5C39.5000409@redhat.com>

Does anyone have an objection to letting the jar files in WEB-INF/lib 
lose their version numbers?  I won't bore you with the details of why I 
want to do this, but it makes it much simpler to deal with automatically 
replacing the account and login SPI jars:
http://docs.jboss.org/keycloak/docs/1.0-beta-4/userguide/html/themes.html#d4e1018

Also, it keeps the above doco from getting out of date like it is now. :-)

We can easily do this with the Maven WAR plugin.
http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html

Any objections to letting jars in WEB-INF/lib get the 
@{artifactId}@.@{extension}@ pattern?

Stan

From bburke at redhat.com  Tue Sep 30 21:47:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 30 Sep 2014 21:47:27 -0400
Subject: [keycloak-dev] auth-server and WEB-INF/lib
In-Reply-To: <542B5C39.5000409@redhat.com>
References: <542B5C39.5000409@redhat.com>
Message-ID: <542B5D2F.5020908@redhat.com>

Very bad practice.  I vote no.

On 9/30/2014 9:43 PM, Stan Silvert wrote:
> Does anyone have an objection to letting the jar files in WEB-INF/lib
> lose their version numbers?  I won't bore you with the details of why I
> want to do this, but it makes it much simpler to deal with automatically
> replacing the account and login SPI jars:
> http://docs.jboss.org/keycloak/docs/1.0-beta-4/userguide/html/themes.html#d4e1018
>
> Also, it keeps the above doco from getting out of date like it is now. :-)
>
> We can easily do this with the Maven WAR plugin.
> http://maven.apache.org/plugins/maven-war-plugin/examples/file-name-mapping.html
>
> Any objections to letting jars in WEB-INF/lib get the
> @{artifactId}@.@{extension}@ pattern?
>
> 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