From stian at redhat.com  Wed Oct  1 02:48:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Oct 2014 02:48:48 -0400 (EDT)
Subject: [keycloak-dev] auth-server and WEB-INF/lib
In-Reply-To: <542B5C39.5000409@redhat.com>
References: <542B5C39.5000409@redhat.com>
Message-ID: <676526507.59391760.1412146128746.JavaMail.zimbra@redhat.com>

-1

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 3:43:21 AM
> Subject: [keycloak-dev] auth-server and WEB-INF/lib
> 
> 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. :-)

How are the docs out of date? See https://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html_single/index.html#d4e1060 that refers to latest version.

They're just tied to a specific release, but that's going to be the case with or without a version in there.

> 
> 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
> 

From stian at redhat.com  Wed Oct  1 02:59:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Oct 2014 02:59:02 -0400 (EDT)
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <20140930230613.GA26685@abstractj.org>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
	<20140930230613.GA26685@abstractj.org>
Message-ID: <1508649391.59398491.1412146742409.JavaMail.zimbra@redhat.com>

I agree that a non-webview approach may have benefits. However, there's a lot of functionality that would have to be reproduced for all platforms. Alternatively, we could support a limited set of functionality without a webview, and if anything else is required use a webview, or even pop up the browser.

On Android, Google uses a webview if you have Google Authenticator enabled.

For a complete experience the following is currently required:

* Login (username/password)
  - Social logins (configurable through realm)
  - Recover password link
  - Registration link
  - Remember me option
* Multi-factor authenticating (soon we'll support pluggable auth mechanisms)
* Registration page (fields will be configurable in the future)
* Required actions (update profile, reset password, verify email, configure totp)

Then there's also single-sign on/out to consider.

All of the above can be done in a native way already by just doing the same HTTP posts as the login forms does. However, even a basic login would be tricky to do due to multi-factor authentication.

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Summers Pittman" <supittma at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 1:06:13 AM
> Subject: Re: [keycloak-dev] Ok to have no direct links to...
> 
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Wed Oct  1 03:37:59 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 1 Oct 2014 00:37:59 -0700
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <1508649391.59398491.1412146742409.JavaMail.zimbra@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
	<20140930230613.GA26685@abstractj.org>
	<1508649391.59398491.1412146742409.JavaMail.zimbra@redhat.com>
Message-ID: <20141001073759.GA33926@abstractj.org>

Hi Stian, that's cool if it's planned for the further releases.

The major concern here is about a vulnerability which can be exploit on
Android < 4.2 ? most of Android devices
(http://www.rapid7.com/db/modules/exploit/android/browser/webview_addjavascriptinterface).

We can go with Webview and improve later.

Thanks a lot.

On 2014-10-01, Stian Thorgersen wrote:
> I agree that a non-webview approach may have benefits. However, there's a lot of functionality that would have to be reproduced for all platforms. Alternatively, we could support a limited set of functionality without a webview, and if anything else is required use a webview, or even pop up the browser.
>
> On Android, Google uses a webview if you have Google Authenticator enabled.
>
> For a complete experience the following is currently required:
>
> * Login (username/password)
>   - Social logins (configurable through realm)
>   - Recover password link
>   - Registration link
>   - Remember me option
> * Multi-factor authenticating (soon we'll support pluggable auth mechanisms)
> * Registration page (fields will be configurable in the future)
> * Required actions (update profile, reset password, verify email, configure totp)
>
> Then there's also single-sign on/out to consider.
>
> All of the above can be done in a native way already by just doing the same HTTP posts as the login forms does. However, even a basic login would be tricky to do due to multi-factor authentication.
>
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "Summers Pittman" <supittma at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 1 October, 2014 1:06:13 AM
> > Subject: Re: [keycloak-dev] Ok to have no direct links to...
> >
> > 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
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Wed Oct  1 03:53:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Oct 2014 03:53:16 -0400 (EDT)
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <20141001073759.GA33926@abstractj.org>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
	<20140930230613.GA26685@abstractj.org>
	<1508649391.59398491.1412146742409.JavaMail.zimbra@redhat.com>
	<20141001073759.GA33926@abstractj.org>
Message-ID: <611816004.59520714.1412149996107.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Summers Pittman" <supittma at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 9:37:59 AM
> Subject: Re: [keycloak-dev] Ok to have no direct links to...
> 
> Hi Stian, that's cool if it's planned for the further releases.

We haven't planned anything (have we?). With regards to SDKs for Android and iOS (and that pesky Windows thing) we're hoping to delegate it all to you guys ;)

> 
> The major concern here is about a vulnerability which can be exploit on
> Android < 4.2 ? most of Android devices
> (http://www.rapid7.com/db/modules/exploit/android/browser/webview_addjavascriptinterface).

There's no JS in Keycloak login forms or account management, it's all just plain-old html. Maybe it's possible to disable JS in the webviews which would eliminate this exploit?

> 
> We can go with Webview and improve later.
> 
> Thanks a lot.
> 
> On 2014-10-01, Stian Thorgersen wrote:
> > I agree that a non-webview approach may have benefits. However, there's a
> > lot of functionality that would have to be reproduced for all platforms.
> > Alternatively, we could support a limited set of functionality without a
> > webview, and if anything else is required use a webview, or even pop up
> > the browser.
> >
> > On Android, Google uses a webview if you have Google Authenticator enabled.
> >
> > For a complete experience the following is currently required:
> >
> > * Login (username/password)
> >   - Social logins (configurable through realm)
> >   - Recover password link
> >   - Registration link
> >   - Remember me option
> > * Multi-factor authenticating (soon we'll support pluggable auth
> > mechanisms)
> > * Registration page (fields will be configurable in the future)
> > * Required actions (update profile, reset password, verify email, configure
> > totp)
> >
> > Then there's also single-sign on/out to consider.
> >
> > All of the above can be done in a native way already by just doing the same
> > HTTP posts as the login forms does. However, even a basic login would be
> > tricky to do due to multi-factor authentication.
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org>
> > > To: "Summers Pittman" <supittma at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 1 October, 2014 1:06:13 AM
> > > Subject: Re: [keycloak-dev] Ok to have no direct links to...
> > >
> > > 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
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> 


From corinnekrych at gmail.com  Wed Oct  1 05:19:56 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 1 Oct 2014 11:19:56 +0200
Subject: [keycloak-dev] Ok to have no direct links to...
In-Reply-To: <611816004.59520714.1412149996107.JavaMail.zimbra@redhat.com>
References: <542585C7.3050703@redhat.com>
	<62C083A1-A58B-4EE5-B729-76193042841C@gmail.com>
	<542AB0AF.705@redhat.com> <542ABA30.2050801@redhat.com>
	<20140930230613.GA26685@abstractj.org>
	<1508649391.59398491.1412146742409.JavaMail.zimbra@redhat.com>
	<20141001073759.GA33926@abstractj.org>
	<611816004.59520714.1412149996107.JavaMail.zimbra@redhat.com>
Message-ID: <BCE6ED1C-1A0E-4909-9034-6277A27C9F17@gmail.com>


On 01 Oct 2014, at 09:53, Stian Thorgersen <stian at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Summers Pittman" <supittma at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 1 October, 2014 9:37:59 AM
>> Subject: Re: [keycloak-dev] Ok to have no direct links to...
>> 
>> Hi Stian, that's cool if it's planned for the further releases.
> 
> We haven't planned anything (have we?). With regards to SDKs for Android and iOS (and that pesky Windows thing) we're hoping to delegate it all to you guys ;)


Let?s hold the discussion here. Let me do a demo app on my side in iOS and get back to you just to mekae sure I can implement it.
what i want isan opeinid connect authz code flow as described in spec:
http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth

without embedded browser but  rather an external browser as we used for oauth2 authz code.

Stiant do I have all i need on keycloak to configure it this way? that was my original question...
Maybe with sample test we can clear out the misunderstanding...


> 
>> 
>> The major concern here is about a vulnerability which can be exploit on
>> Android < 4.2 ? most of Android devices
>> (http://www.rapid7.com/db/modules/exploit/android/browser/webview_addjavascriptinterface).
> 
> There's no JS in Keycloak login forms or account management, it's all just plain-old html. Maybe it's possible to disable JS in the webviews which would eliminate this exploit?
> 
>> 
>> We can go with Webview and improve later.
>> 
>> Thanks a lot.
>> 
>> On 2014-10-01, Stian Thorgersen wrote:
>>> I agree that a non-webview approach may have benefits. However, there's a
>>> lot of functionality that would have to be reproduced for all platforms.
>>> Alternatively, we could support a limited set of functionality without a
>>> webview, and if anything else is required use a webview, or even pop up
>>> the browser.
>>> 
>>> On Android, Google uses a webview if you have Google Authenticator enabled.
>>> 
>>> For a complete experience the following is currently required:
>>> 
>>> * Login (username/password)
>>>  - Social logins (configurable through realm)
>>>  - Recover password link
>>>  - Registration link
>>>  - Remember me option
>>> * Multi-factor authenticating (soon we'll support pluggable auth
>>> mechanisms)
>>> * Registration page (fields will be configurable in the future)
>>> * Required actions (update profile, reset password, verify email, configure
>>> totp)
>>> 
>>> Then there's also single-sign on/out to consider.
>>> 
>>> All of the above can be done in a native way already by just doing the same
>>> HTTP posts as the login forms does. However, even a basic login would be
>>> tricky to do due to multi-factor authentication.
>>> 
>>> ----- Original Message -----
>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>> To: "Summers Pittman" <supittma at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 1 October, 2014 1:06:13 AM
>>>> Subject: Re: [keycloak-dev] Ok to have no direct links to...
>>>> 
>>>> 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
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> --
>> 
>> abstractj
>> PGP: 0x84DC9914
>> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From ssilvert at redhat.com  Wed Oct  1 07:26:41 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 01 Oct 2014 07:26:41 -0400
Subject: [keycloak-dev] auth-server and WEB-INF/lib
In-Reply-To: <676526507.59391760.1412146128746.JavaMail.zimbra@redhat.com>
References: <542B5C39.5000409@redhat.com>
	<676526507.59391760.1412146128746.JavaMail.zimbra@redhat.com>
Message-ID: <542BE4F1.2030909@redhat.com>

On 10/1/2014 2:48 AM, Stian Thorgersen wrote:
> -1
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 1 October, 2014 3:43:21 AM
>> Subject: [keycloak-dev] auth-server and WEB-INF/lib
>>
>> 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. :-)
> How are the docs out of date? See https://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html_single/index.html#d4e1060 that refers to latest version.
>
> They're just tied to a specific release, but that's going to be the case with or without a version in there.
Turns out I was out of date.  Looking at the wrong version.

I can still deal with it.  Just makes things a little harder.
>
>> 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
>>


From stian at redhat.com  Wed Oct  1 09:10:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Oct 2014 09:10:27 -0400 (EDT)
Subject: [keycloak-dev] Releases next week?
In-Reply-To: <491390034.59691881.1412168942571.JavaMail.zimbra@redhat.com>
Message-ID: <1310265562.59692609.1412169027665.JavaMail.zimbra@redhat.com>

Looks like clustering will still be finished this week, so I'd like to release 1.1.0.Alpha1 next week (probably Wed). Then once SAML is finished we can release Alpha2 (or Beta1?).

At the same time should we release a 1.0.2.RC1 (or just go straight for 1.0.2.Final)?

From bburke at redhat.com  Wed Oct  1 09:13:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Oct 2014 09:13:36 -0400
Subject: [keycloak-dev] Releases next week?
In-Reply-To: <1310265562.59692609.1412169027665.JavaMail.zimbra@redhat.com>
References: <1310265562.59692609.1412169027665.JavaMail.zimbra@redhat.com>
Message-ID: <542BFE00.20107@redhat.com>

Do betas.  We're not alpha tech anymore.  And just go to 1.0.2.Final.

On 10/1/2014 9:10 AM, Stian Thorgersen wrote:
> Looks like clustering will still be finished this week, so I'd like to release 1.1.0.Alpha1 next week (probably Wed). Then once SAML is finished we can release Alpha2 (or Beta1?).
>
> At the same time should we release a 1.0.2.RC1 (or just go straight for 1.0.2.Final)?
> _______________________________________________
> 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 Oct  1 09:16:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Oct 2014 09:16:59 -0400 (EDT)
Subject: [keycloak-dev] Releases next week?
In-Reply-To: <542BFE00.20107@redhat.com>
References: <1310265562.59692609.1412169027665.JavaMail.zimbra@redhat.com>
	<542BFE00.20107@redhat.com>
Message-ID: <6984440.59698285.1412169419593.JavaMail.zimbra@redhat.com>

Oki - I'll release 1.0.2.Final and 1.1.0.Beta1 next week

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 3:13:36 PM
> Subject: Re: [keycloak-dev] Releases next week?
> 
> Do betas.  We're not alpha tech anymore.  And just go to 1.0.2.Final.
> 
> On 10/1/2014 9:10 AM, Stian Thorgersen wrote:
> > Looks like clustering will still be finished this week, so I'd like to
> > release 1.1.0.Alpha1 next week (probably Wed). Then once SAML is finished
> > we can release Alpha2 (or Beta1?).
> >
> > At the same time should we release a 1.0.2.RC1 (or just go straight for
> > 1.0.2.Final)?
> > _______________________________________________
> > 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  Wed Oct  1 10:27:51 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 01 Oct 2014 10:27:51 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
Message-ID: <542C0F67.5020507@redhat.com>

After lots of experimentation, I think I've finally settled on a 
design.  Though this whole effort has taken longer than expected, I 
don't think the coding will take that long since I've got experimental 
code that does the hard stuff.  I just need to rearrange it and clean it up.

Here is the design.  I appreciate your feedback.

_*Design Goals*_
* Support auth-server running in a WildFly domain.
* Eliminate deployment from /deployments directory to make it a proper 
service instead of an ordinary app.
* Eliminate need to explode or crack open auth-server.war.  Keep it 
intact so it doesn't need to be hacked up.
* Load user-provided overlays for keycloak-server.json, SPI jars, and 
theme jars.
* Allow uploading overlays from CLI.
* Allow more than one auth-server in a WildFly instance.
* Compatibility with EAP6, EAP7, WildFly8, and WildFly9.


_*Management Model*_
The Keycloak subsystem introduces a new resource called, "auth-server".  
You can define more than one auth-server if you like.  The simplest form 
just looks like this:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
             <auth-server name="my-auth-server-name"/>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">

On startup, this deploys my-auth-server-name.war with web context "auth".

There are two optional attributes under <auth-server>.  They are 
"enabled" and "web-context".  Here is an example:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
             <auth-server name="auth-server1"/>
             <auth-server name="auth-server2">
                      <enabled>true<enabled/>
                      <web-context>auth2</web-context>
             </auth-server>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">

In a domain environment, there is an additional resource.  You assign 
the auth server to one or more server groups:
<subsystem xmlns="urn:jboss:domain:keycloak:1.1">
             <auth-server name="my-auth-server-name">
                      <server-group name="group1"/>
                      <server-group name="group2"/>
             </auth-server>
</subsystem xmlns="urn:jboss:domain:keycloak:1.1">

_*Loading the Auth Server*_
The auth-server.war will be loaded from the Keycloak subsystem module.   
This is just a convenient place to put it.  We could actually load it 
from anywhere.  Note that it no longer needs to be exploded.

_*Using Overalys*_
The Keycloak subsystem can overlay or add to the auth-server.war. 
Overlays do not touch the original content of auth-server.war.

To define an overaly, you just drop your files in the proper directories 
on the file system.  The layout is:

/overlays/<auth-server-name>/server-config/
/overlays/<auth-server-name>/account-spi/
/overlays/<auth-server-name>/login-spi/
/overlays/<auth-server-name>/other-spi/

/server-config optionally contains a single json file that replaces 
keycloak-server.json
/account-spi optionally contains a single jar file that replaces 
keycloak-account-freemarker.jar.
/login-spi optionally contains a single jar file that replaces 
keycloak-login-freemarker.jar
/other-spi optionally contains one or more spi jar files to be added to 
WEB-INF/lib.  Theme jars also go here.

_*Location of SPI jars and other user-defined overalys*_
For now, I'm planning to have the /overlays directory in the Keycloak 
subsystem module.  They could, for instance, go in a /keycloak directory 
such as <wildfly-home>/keycloak.   Any thoughts on this?

_*Uploading overlays from CLI*_
It is already possible to create overalys via CLI.  You upload the 
content and assign it to deployments and server-groups.  The CLI 
commands for this are rather complicated and you really need to know 
what you are doing.

We could make this easier by adding simpler CLI operations to the 
Keycloak subsystem.  However, I think we should hold off on this until 
we find out if the directory-based approach is acceptable to users.  In 
the mean time, we can just document the CLI commands needed to upload 
overlays.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141001/75caf6bb/attachment-0001.html 

From bburke at redhat.com  Wed Oct  1 16:05:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Oct 2014 16:05:36 -0400
Subject: [keycloak-dev] initial login protocol refactoring done
Message-ID: <542C5E90.7000006@redhat.com>

I think everything that can be is now protocol independent.  I wrote a 
provider for protocol plugins:

LoginProtocol
LoginProtocolFactory

URI schemes were refactored, but the old ones are there and deprecated 
for backward compatibility.  I'll probably have to tweak things more 
once I put in SAML, but the bulk of it should be done.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Oct  1 16:07:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Oct 2014 16:07:03 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542C0F67.5020507@redhat.com>
References: <542C0F67.5020507@redhat.com>
Message-ID: <542C5EE7.3040204@redhat.com>

Theme support is unaffected?

On 10/1/2014 10:27 AM, Stan Silvert wrote:
> After lots of experimentation, I think I've finally settled on a
> design.  Though this whole effort has taken longer than expected, I
> don't think the coding will take that long since I've got experimental
> code that does the hard stuff.  I just need to rearrange it and clean it up.
>
> Here is the design.  I appreciate your feedback.
>
> _*Design Goals*_
> * Support auth-server running in a WildFly domain.
> * Eliminate deployment from /deployments directory to make it a proper
> service instead of an ordinary app.
> * Eliminate need to explode or crack open auth-server.war.  Keep it
> intact so it doesn't need to be hacked up.
> * Load user-provided overlays for keycloak-server.json, SPI jars, and
> theme jars.
> * Allow uploading overlays from CLI.
> * Allow more than one auth-server in a WildFly instance.
> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
>
>
> _*Management Model*_
> The Keycloak subsystem introduces a new resource called, "auth-server".
> You can define more than one auth-server if you like.  The simplest form
> just looks like this:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="my-auth-server-name"/>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> On startup, this deploys my-auth-server-name.war with web context "auth".
>
> There are two optional attributes under <auth-server>.  They are
> "enabled" and "web-context".  Here is an example:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="auth-server1"/>
>              <auth-server name="auth-server2">
>                       <enabled>true<enabled/>
>                       <web-context>auth2</web-context>
>              </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> In a domain environment, there is an additional resource.  You assign
> the auth server to one or more server groups:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>              <auth-server name="my-auth-server-name">
>                       <server-group name="group1"/>
>                       <server-group name="group2"/>
>              </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>
> _*Loading the Auth Server*_
> The auth-server.war will be loaded from the Keycloak subsystem module.
> This is just a convenient place to put it.  We could actually load it
> from anywhere.  Note that it no longer needs to be exploded.
>
> _*Using Overalys*_
> The Keycloak subsystem can overlay or add to the auth-server.war.
> Overlays do not touch the original content of auth-server.war.
>
> To define an overaly, you just drop your files in the proper directories
> on the file system.  The layout is:
>
> /overlays/<auth-server-name>/server-config/
> /overlays/<auth-server-name>/account-spi/
> /overlays/<auth-server-name>/login-spi/
> /overlays/<auth-server-name>/other-spi/
>
> /server-config optionally contains a single json file that replaces
> keycloak-server.json
> /account-spi optionally contains a single jar file that replaces
> keycloak-account-freemarker.jar.
> /login-spi optionally contains a single jar file that replaces
> keycloak-login-freemarker.jar
> /other-spi optionally contains one or more spi jar files to be added to
> WEB-INF/lib.  Theme jars also go here.
>
> _*Location of SPI jars and other user-defined overalys*_
> For now, I'm planning to have the /overlays directory in the Keycloak
> subsystem module.  They could, for instance, go in a /keycloak directory
> such as <wildfly-home>/keycloak.   Any thoughts on this?
>
> _*Uploading overlays from CLI*_
> It is already possible to create overalys via CLI.  You upload the
> content and assign it to deployments and server-groups.  The CLI
> commands for this are rather complicated and you really need to know
> what you are doing.
>
> We could make this easier by adding simpler CLI operations to the
> Keycloak subsystem.  However, I think we should hold off on this until
> we find out if the directory-based approach is acceptable to users.  In
> the mean time, we can just document the CLI commands needed to upload
> overlays.
>
>
> _______________________________________________
> 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 Oct  1 16:50:07 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 01 Oct 2014 16:50:07 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542C5EE7.3040204@redhat.com>
References: <542C0F67.5020507@redhat.com> <542C5EE7.3040204@redhat.com>
Message-ID: <542C68FF.8060106@redhat.com>

On 10/1/2014 4:07 PM, Bill Burke wrote:
> Theme support is unaffected?
The short answer is yes, no affect except that you can now put a custom 
theme in a jar and place in /overlays/<auth-server-name>/other-spi.

However, concerning themes, the current location for themes will 
probably not work in a domain environment because it lives in 
standalone/configuration/themes.  I'm not sure about the consequences of 
that.  Are there default themes available inside the auth-server.war?


>
> On 10/1/2014 10:27 AM, Stan Silvert wrote:
>> After lots of experimentation, I think I've finally settled on a
>> design.  Though this whole effort has taken longer than expected, I
>> don't think the coding will take that long since I've got experimental
>> code that does the hard stuff.  I just need to rearrange it and clean it up.
>>
>> Here is the design.  I appreciate your feedback.
>>
>> _*Design Goals*_
>> * Support auth-server running in a WildFly domain.
>> * Eliminate deployment from /deployments directory to make it a proper
>> service instead of an ordinary app.
>> * Eliminate need to explode or crack open auth-server.war.  Keep it
>> intact so it doesn't need to be hacked up.
>> * Load user-provided overlays for keycloak-server.json, SPI jars, and
>> theme jars.
>> * Allow uploading overlays from CLI.
>> * Allow more than one auth-server in a WildFly instance.
>> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
>>
>>
>> _*Management Model*_
>> The Keycloak subsystem introduces a new resource called, "auth-server".
>> You can define more than one auth-server if you like.  The simplest form
>> just looks like this:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>               <auth-server name="my-auth-server-name"/>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> On startup, this deploys my-auth-server-name.war with web context "auth".
>>
>> There are two optional attributes under <auth-server>.  They are
>> "enabled" and "web-context".  Here is an example:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>               <auth-server name="auth-server1"/>
>>               <auth-server name="auth-server2">
>>                        <enabled>true<enabled/>
>>                        <web-context>auth2</web-context>
>>               </auth-server>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> In a domain environment, there is an additional resource.  You assign
>> the auth server to one or more server groups:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>               <auth-server name="my-auth-server-name">
>>                        <server-group name="group1"/>
>>                        <server-group name="group2"/>
>>               </auth-server>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> _*Loading the Auth Server*_
>> The auth-server.war will be loaded from the Keycloak subsystem module.
>> This is just a convenient place to put it.  We could actually load it
>> from anywhere.  Note that it no longer needs to be exploded.
>>
>> _*Using Overalys*_
>> The Keycloak subsystem can overlay or add to the auth-server.war.
>> Overlays do not touch the original content of auth-server.war.
>>
>> To define an overaly, you just drop your files in the proper directories
>> on the file system.  The layout is:
>>
>> /overlays/<auth-server-name>/server-config/
>> /overlays/<auth-server-name>/account-spi/
>> /overlays/<auth-server-name>/login-spi/
>> /overlays/<auth-server-name>/other-spi/
>>
>> /server-config optionally contains a single json file that replaces
>> keycloak-server.json
>> /account-spi optionally contains a single jar file that replaces
>> keycloak-account-freemarker.jar.
>> /login-spi optionally contains a single jar file that replaces
>> keycloak-login-freemarker.jar
>> /other-spi optionally contains one or more spi jar files to be added to
>> WEB-INF/lib.  Theme jars also go here.
>>
>> _*Location of SPI jars and other user-defined overalys*_
>> For now, I'm planning to have the /overlays directory in the Keycloak
>> subsystem module.  They could, for instance, go in a /keycloak directory
>> such as <wildfly-home>/keycloak.   Any thoughts on this?
>>
>> _*Uploading overlays from CLI*_
>> It is already possible to create overalys via CLI.  You upload the
>> content and assign it to deployments and server-groups.  The CLI
>> commands for this are rather complicated and you really need to know
>> what you are doing.
>>
>> We could make this easier by adding simpler CLI operations to the
>> Keycloak subsystem.  However, I think we should hold off on this until
>> we find out if the directory-based approach is acceptable to users.  In
>> the mean time, we can just document the CLI commands needed to upload
>> overlays.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Wed Oct  1 22:22:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Oct 2014 22:22:36 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542C68FF.8060106@redhat.com>
References: <542C0F67.5020507@redhat.com> <542C5EE7.3040204@redhat.com>
	<542C68FF.8060106@redhat.com>
Message-ID: <542CB6EC.4050305@redhat.com>

Yes, they are available I think.

On 10/1/2014 4:50 PM, Stan Silvert wrote:
> On 10/1/2014 4:07 PM, Bill Burke wrote:
>> Theme support is unaffected?
> The short answer is yes, no affect except that you can now put a custom
> theme in a jar and place in /overlays/<auth-server-name>/other-spi.
>
> However, concerning themes, the current location for themes will
> probably not work in a domain environment because it lives in
> standalone/configuration/themes.  I'm not sure about the consequences of
> that.  Are there default themes available inside the auth-server.war?
>
>
>>
>> On 10/1/2014 10:27 AM, Stan Silvert wrote:
>>> After lots of experimentation, I think I've finally settled on a
>>> design.  Though this whole effort has taken longer than expected, I
>>> don't think the coding will take that long since I've got experimental
>>> code that does the hard stuff.  I just need to rearrange it and clean it up.
>>>
>>> Here is the design.  I appreciate your feedback.
>>>
>>> _*Design Goals*_
>>> * Support auth-server running in a WildFly domain.
>>> * Eliminate deployment from /deployments directory to make it a proper
>>> service instead of an ordinary app.
>>> * Eliminate need to explode or crack open auth-server.war.  Keep it
>>> intact so it doesn't need to be hacked up.
>>> * Load user-provided overlays for keycloak-server.json, SPI jars, and
>>> theme jars.
>>> * Allow uploading overlays from CLI.
>>> * Allow more than one auth-server in a WildFly instance.
>>> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
>>>
>>>
>>> _*Management Model*_
>>> The Keycloak subsystem introduces a new resource called, "auth-server".
>>> You can define more than one auth-server if you like.  The simplest form
>>> just looks like this:
>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>                <auth-server name="my-auth-server-name"/>
>>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>
>>> On startup, this deploys my-auth-server-name.war with web context "auth".
>>>
>>> There are two optional attributes under <auth-server>.  They are
>>> "enabled" and "web-context".  Here is an example:
>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>                <auth-server name="auth-server1"/>
>>>                <auth-server name="auth-server2">
>>>                         <enabled>true<enabled/>
>>>                         <web-context>auth2</web-context>
>>>                </auth-server>
>>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>
>>> In a domain environment, there is an additional resource.  You assign
>>> the auth server to one or more server groups:
>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>                <auth-server name="my-auth-server-name">
>>>                         <server-group name="group1"/>
>>>                         <server-group name="group2"/>
>>>                </auth-server>
>>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>>
>>> _*Loading the Auth Server*_
>>> The auth-server.war will be loaded from the Keycloak subsystem module.
>>> This is just a convenient place to put it.  We could actually load it
>>> from anywhere.  Note that it no longer needs to be exploded.
>>>
>>> _*Using Overalys*_
>>> The Keycloak subsystem can overlay or add to the auth-server.war.
>>> Overlays do not touch the original content of auth-server.war.
>>>
>>> To define an overaly, you just drop your files in the proper directories
>>> on the file system.  The layout is:
>>>
>>> /overlays/<auth-server-name>/server-config/
>>> /overlays/<auth-server-name>/account-spi/
>>> /overlays/<auth-server-name>/login-spi/
>>> /overlays/<auth-server-name>/other-spi/
>>>
>>> /server-config optionally contains a single json file that replaces
>>> keycloak-server.json
>>> /account-spi optionally contains a single jar file that replaces
>>> keycloak-account-freemarker.jar.
>>> /login-spi optionally contains a single jar file that replaces
>>> keycloak-login-freemarker.jar
>>> /other-spi optionally contains one or more spi jar files to be added to
>>> WEB-INF/lib.  Theme jars also go here.
>>>
>>> _*Location of SPI jars and other user-defined overalys*_
>>> For now, I'm planning to have the /overlays directory in the Keycloak
>>> subsystem module.  They could, for instance, go in a /keycloak directory
>>> such as <wildfly-home>/keycloak.   Any thoughts on this?
>>>
>>> _*Uploading overlays from CLI*_
>>> It is already possible to create overalys via CLI.  You upload the
>>> content and assign it to deployments and server-groups.  The CLI
>>> commands for this are rather complicated and you really need to know
>>> what you are doing.
>>>
>>> We could make this easier by adding simpler CLI operations to the
>>> Keycloak subsystem.  However, I think we should hold off on this until
>>> we find out if the directory-based approach is acceptable to users.  In
>>> the mean time, we can just document the CLI commands needed to upload
>>> overlays.
>>>
>>>
>>> _______________________________________________
>>> 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  Thu Oct  2 02:10:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 02:10:55 -0400 (EDT)
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542C0F67.5020507@redhat.com>
References: <542C0F67.5020507@redhat.com>
Message-ID: <2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 4:27:51 PM
> Subject: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> After lots of experimentation, I think I've finally settled on a design.
> Though this whole effort has taken longer than expected, I don't think the
> coding will take that long since I've got experimental code that does the
> hard stuff. I just need to rearrange it and clean it up.
> 
> Here is the design. I appreciate your feedback.
> 
> Design Goals
> * Support auth-server running in a WildFly domain.
> * Eliminate deployment from /deployments directory to make it a proper
> service instead of an ordinary app.
> * Eliminate need to explode or crack open auth-server.war. Keep it intact so
> it doesn't need to be hacked up.
> * Load user-provided overlays for keycloak-server.json, SPI jars, and theme
> jars.
> * Allow uploading overlays from CLI.
> * Allow more than one auth-server in a WildFly instance.
> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
> 
> 
> Management Model
> The Keycloak subsystem introduces a new resource called, "auth-server". You
> can define more than one auth-server if you like. The simplest form just
> looks like this:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> <auth-server name="my-auth-server-name"/>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> 
> On startup, this deploys my-auth-server-name.war with web context "auth".
> 
> There are two optional attributes under <auth-server>. They are "enabled" and
> "web-context". Here is an example:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> <auth-server name="auth-server1"/>
> <auth-server name="auth-server2">
> <enabled>true<enabled/>
> <web-context>auth2</web-context>
> </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> 
> In a domain environment, there is an additional resource. You assign the auth
> server to one or more server groups:
> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> <auth-server name="my-auth-server-name">
> <server-group name="group1"/>
> <server-group name="group2"/>
> </auth-server>
> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> 
> Loading the Auth Server
> The auth-server.war will be loaded from the Keycloak subsystem module. This
> is just a convenient place to put it. We could actually load it from
> anywhere. Note that it no longer needs to be exploded.
> 
> Using Overalys
> The Keycloak subsystem can overlay or add to the auth-server.war. Overlays do
> not touch the original content of auth-server.war.
> 
> To define an overaly, you just drop your files in the proper directories on
> the file system. The layout is:
> 
> /overlays/<auth-server-name>/server-config/
> /overlays/<auth-server-name>/account-spi/
> /overlays/<auth-server-name>/login-spi/
> /overlays/<auth-server-name>/other-spi/
> 
> /server-config optionally contains a single json file that replaces
> keycloak-server.json

What's the purpose of this? Are those config options not loaded from standalone/domain.xml?

> /account-spi optionally contains a single jar file that replaces
> keycloak-account-freemarker.jar.
> /login-spi optionally contains a single jar file that replaces
> keycloak-login-freemarker.jar

Why replace keycloak-*-freemarker.jar?

> /other-spi optionally contains one or more spi jar files to be added to
> WEB-INF/lib. Theme jars also go here.
> 
> Location of SPI jars and other user-defined overalys
> For now, I'm planning to have the /overlays directory in the Keycloak
> subsystem module. They could, for instance, go in a /keycloak directory such
> as <wildfly-home>/keycloak. Any thoughts on this?
> 
> Uploading overlays from CLI
> It is already possible to create overalys via CLI. You upload the content and
> assign it to deployments and server-groups. The CLI commands for this are
> rather complicated and you really need to know what you are doing.
> 
> We could make this easier by adding simpler CLI operations to the Keycloak
> subsystem. However, I think we should hold off on this until we find out if
> the directory-based approach is acceptable to users. In the mean time, we
> can just document the CLI commands needed to upload overlays.

It would be awesome to have the ability to upload jars and themes from the KC admin console as well

> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Oct  2 02:28:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 02:28:40 -0400 (EDT)
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542C68FF.8060106@redhat.com>
References: <542C0F67.5020507@redhat.com> <542C5EE7.3040204@redhat.com>
	<542C68FF.8060106@redhat.com>
Message-ID: <459655050.60169730.1412231320060.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 October, 2014 10:50:07 PM
> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> On 10/1/2014 4:07 PM, Bill Burke wrote:
> > Theme support is unaffected?
> The short answer is yes, no affect except that you can now put a custom
> theme in a jar and place in /overlays/<auth-server-name>/other-spi.
> 
> However, concerning themes, the current location for themes will
> probably not work in a domain environment because it lives in
> standalone/configuration/themes.  I'm not sure about the consequences of
> that.  Are there default themes available inside the auth-server.war?

Themes are loaded from "${jboss.server.config.dir}/themes", but this is configurable through keycloak-server.json. We also bundle the themes in a jar in auth-server.war. Exploded themes (${jboss.server.config.dir}/themes) override those in the war, but if someone deletes them then they're loaded from the war.

I propose we simplify the way theme jars are created and make this the recommended way to add themes in a domain. This should only take a few hours to do. Currently a theme jar has to provide an implementation of theme provider, but we'd change that to simply a jar with:

  META-INF/theme.json
  META-INF/themes/<theme type>/<theme name>

contents of theme.json would be:

  { 
    "type": "login",
    "name": "mytheme",
    "parent": "keycloak",
    "styles": [ ... ]
  }

Main reason to change it to a json file instead of properties file is to allow multiple themes in the same jar:

  [ { "type": "login", "name": "mytheme" }, { "type": "account", "name": "mytheme" } ]

> 
> 
> >
> > On 10/1/2014 10:27 AM, Stan Silvert wrote:
> >> After lots of experimentation, I think I've finally settled on a
> >> design.  Though this whole effort has taken longer than expected, I
> >> don't think the coding will take that long since I've got experimental
> >> code that does the hard stuff.  I just need to rearrange it and clean it
> >> up.
> >>
> >> Here is the design.  I appreciate your feedback.
> >>
> >> _*Design Goals*_
> >> * Support auth-server running in a WildFly domain.
> >> * Eliminate deployment from /deployments directory to make it a proper
> >> service instead of an ordinary app.
> >> * Eliminate need to explode or crack open auth-server.war.  Keep it
> >> intact so it doesn't need to be hacked up.
> >> * Load user-provided overlays for keycloak-server.json, SPI jars, and
> >> theme jars.
> >> * Allow uploading overlays from CLI.
> >> * Allow more than one auth-server in a WildFly instance.
> >> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
> >>
> >>
> >> _*Management Model*_
> >> The Keycloak subsystem introduces a new resource called, "auth-server".
> >> You can define more than one auth-server if you like.  The simplest form
> >> just looks like this:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>               <auth-server name="my-auth-server-name"/>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> On startup, this deploys my-auth-server-name.war with web context "auth".
> >>
> >> There are two optional attributes under <auth-server>.  They are
> >> "enabled" and "web-context".  Here is an example:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>               <auth-server name="auth-server1"/>
> >>               <auth-server name="auth-server2">
> >>                        <enabled>true<enabled/>
> >>                        <web-context>auth2</web-context>
> >>               </auth-server>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> In a domain environment, there is an additional resource.  You assign
> >> the auth server to one or more server groups:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>               <auth-server name="my-auth-server-name">
> >>                        <server-group name="group1"/>
> >>                        <server-group name="group2"/>
> >>               </auth-server>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> _*Loading the Auth Server*_
> >> The auth-server.war will be loaded from the Keycloak subsystem module.
> >> This is just a convenient place to put it.  We could actually load it
> >> from anywhere.  Note that it no longer needs to be exploded.
> >>
> >> _*Using Overalys*_
> >> The Keycloak subsystem can overlay or add to the auth-server.war.
> >> Overlays do not touch the original content of auth-server.war.
> >>
> >> To define an overaly, you just drop your files in the proper directories
> >> on the file system.  The layout is:
> >>
> >> /overlays/<auth-server-name>/server-config/
> >> /overlays/<auth-server-name>/account-spi/
> >> /overlays/<auth-server-name>/login-spi/
> >> /overlays/<auth-server-name>/other-spi/
> >>
> >> /server-config optionally contains a single json file that replaces
> >> keycloak-server.json
> >> /account-spi optionally contains a single jar file that replaces
> >> keycloak-account-freemarker.jar.
> >> /login-spi optionally contains a single jar file that replaces
> >> keycloak-login-freemarker.jar
> >> /other-spi optionally contains one or more spi jar files to be added to
> >> WEB-INF/lib.  Theme jars also go here.
> >>
> >> _*Location of SPI jars and other user-defined overalys*_
> >> For now, I'm planning to have the /overlays directory in the Keycloak
> >> subsystem module.  They could, for instance, go in a /keycloak directory
> >> such as <wildfly-home>/keycloak.   Any thoughts on this?
> >>
> >> _*Uploading overlays from CLI*_
> >> It is already possible to create overalys via CLI.  You upload the
> >> content and assign it to deployments and server-groups.  The CLI
> >> commands for this are rather complicated and you really need to know
> >> what you are doing.
> >>
> >> We could make this easier by adding simpler CLI operations to the
> >> Keycloak subsystem.  However, I think we should hold off on this until
> >> we find out if the directory-based approach is acceptable to users.  In
> >> the mean time, we can just document the CLI commands needed to upload
> >> overlays.
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Oct  2 03:49:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 03:49:00 -0400 (EDT)
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <1423289436.60195348.1412235987811.JavaMail.zimbra@redhat.com>
Message-ID: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>

A few things I'd like us to follow with regards to using JIRA:

* Create a JIRA for all changes/fixes/improvements - unless they have no effect on users
* When completing an issue mark as resolved (not closed) - we'll close when we do a release (otherwise we can't change fix version without re-opening the issue)

A few things for Git:

* Try to keep it to a single commit per-JIRA
* Refer to JIRA issue in the commit message

From stian at redhat.com  Thu Oct  2 04:47:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 04:47:33 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <1041228473.60238561.1412238968485.JavaMail.zimbra@redhat.com>
Message-ID: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>

Currently adapters use the HTTP session to manage sessions. This works fine for most, but I believe there's situations when something different is needed. For example for stateless applications. It also doesn't work for bearer-only applications, or oauth clients.

I propose we add a Session SPI to adapters, which allows plugging in a mechanism to manage user sessions. The interface would be something along the lines of:

* void addSession(String userId, String sessionId)
* boolean isSessionValid(String sessionId)
* boolean removeSession(String userId, String sessionId)

We could provide a few built in providers:

* HTTP Session - store in http session as we currently do
* Infinispan - store in an Infinispan cache
* JPA - store in a database
* Keycloak Session Endpoint - we could add a session info endpoint to Keycloak
* None - no session management (relies on expiration of access token to logout users)

Further, we probably need to add some option to enable/disable logout admin events for applications. For example:

* Keycloak Session Endpoint - no need to send logout events
* JPA (or Infinispan) - if multiple applications shares a session database, it's only necessary to send the logout event to one application

Thoughts?

From ssilvert at redhat.com  Thu Oct  2 08:08:31 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 02 Oct 2014 08:08:31 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>
References: <542C0F67.5020507@redhat.com>
	<2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>
Message-ID: <542D403F.4020509@redhat.com>

On 10/2/2014 2:10 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 1 October, 2014 4:27:51 PM
>> Subject: [keycloak-dev] Design of Auth Server startup from subsystem
>>
>> After lots of experimentation, I think I've finally settled on a design.
>> Though this whole effort has taken longer than expected, I don't think the
>> coding will take that long since I've got experimental code that does the
>> hard stuff. I just need to rearrange it and clean it up.
>>
>> Here is the design. I appreciate your feedback.
>>
>> Design Goals
>> * Support auth-server running in a WildFly domain.
>> * Eliminate deployment from /deployments directory to make it a proper
>> service instead of an ordinary app.
>> * Eliminate need to explode or crack open auth-server.war. Keep it intact so
>> it doesn't need to be hacked up.
>> * Load user-provided overlays for keycloak-server.json, SPI jars, and theme
>> jars.
>> * Allow uploading overlays from CLI.
>> * Allow more than one auth-server in a WildFly instance.
>> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
>>
>>
>> Management Model
>> The Keycloak subsystem introduces a new resource called, "auth-server". You
>> can define more than one auth-server if you like. The simplest form just
>> looks like this:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>> <auth-server name="my-auth-server-name"/>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> On startup, this deploys my-auth-server-name.war with web context "auth".
>>
>> There are two optional attributes under <auth-server>. They are "enabled" and
>> "web-context". Here is an example:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>> <auth-server name="auth-server1"/>
>> <auth-server name="auth-server2">
>> <enabled>true<enabled/>
>> <web-context>auth2</web-context>
>> </auth-server>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> In a domain environment, there is an additional resource. You assign the auth
>> server to one or more server groups:
>> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>> <auth-server name="my-auth-server-name">
>> <server-group name="group1"/>
>> <server-group name="group2"/>
>> </auth-server>
>> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
>>
>> Loading the Auth Server
>> The auth-server.war will be loaded from the Keycloak subsystem module. This
>> is just a convenient place to put it. We could actually load it from
>> anywhere. Note that it no longer needs to be exploded.
>>
>> Using Overalys
>> The Keycloak subsystem can overlay or add to the auth-server.war. Overlays do
>> not touch the original content of auth-server.war.
>>
>> To define an overaly, you just drop your files in the proper directories on
>> the file system. The layout is:
>>
>> /overlays/<auth-server-name>/server-config/
>> /overlays/<auth-server-name>/account-spi/
>> /overlays/<auth-server-name>/login-spi/
>> /overlays/<auth-server-name>/other-spi/
>>
>> /server-config optionally contains a single json file that replaces
>> keycloak-server.json
> What's the purpose of this? Are those config options not loaded from standalone/domain.xml?
That was my original intention.  The problem is that the management 
model needs metadata that is more well-defined than what we have in 
keycloak-server.json.  We could translate our own options to DMR but it 
would be impossible to know all the options available for third-party 
providers.  So we would have to do a meta-meta thing for that.  Yuck.

So the next thing I tried was to just imbed the keycloak-server.json 
directly into standalone/domain.xml.  That turned out kind of ugly. 
Better to just let it be its own file and use the same overlay technique 
we are using for everything else.  Cleaner to do everything the same way.

Anyway, that's my reasoning.  Feel free to poke holes if you disagree.
>
>> /account-spi optionally contains a single jar file that replaces
>> keycloak-account-freemarker.jar.
>> /login-spi optionally contains a single jar file that replaces
>> keycloak-login-freemarker.jar
> Why replace keycloak-*-freemarker.jar?
http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.html#d4e1060

For account or login SPI, it says to delete these jars or disable with a 
System property if you want to use your own provider.  I chose replace.  
It doesn't actually change the original auth-server.war on disk.  It's a 
virtual replace.
>
>> /other-spi optionally contains one or more spi jar files to be added to
>> WEB-INF/lib. Theme jars also go here.
>>
>> Location of SPI jars and other user-defined overalys
>> For now, I'm planning to have the /overlays directory in the Keycloak
>> subsystem module. They could, for instance, go in a /keycloak directory such
>> as <wildfly-home>/keycloak. Any thoughts on this?
>>
>> Uploading overlays from CLI
>> It is already possible to create overalys via CLI. You upload the content and
>> assign it to deployments and server-groups. The CLI commands for this are
>> rather complicated and you really need to know what you are doing.
>>
>> We could make this easier by adding simpler CLI operations to the Keycloak
>> subsystem. However, I think we should hold off on this until we find out if
>> the directory-based approach is acceptable to users. In the mean time, we
>> can just document the CLI commands needed to upload overlays.
> It would be awesome to have the ability to upload jars and themes from the KC admin console as well
I agree.  Down the road we need to look into it.
>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Oct  2 08:18:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 08:18:59 -0400 (EDT)
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542D403F.4020509@redhat.com>
References: <542C0F67.5020507@redhat.com>
	<2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>
	<542D403F.4020509@redhat.com>
Message-ID: <1348750769.60359924.1412252339590.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: Thursday, 2 October, 2014 2:08:31 PM
> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> On 10/2/2014 2:10 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 1 October, 2014 4:27:51 PM
> >> Subject: [keycloak-dev] Design of Auth Server startup from subsystem
> >>
> >> After lots of experimentation, I think I've finally settled on a design.
> >> Though this whole effort has taken longer than expected, I don't think the
> >> coding will take that long since I've got experimental code that does the
> >> hard stuff. I just need to rearrange it and clean it up.
> >>
> >> Here is the design. I appreciate your feedback.
> >>
> >> Design Goals
> >> * Support auth-server running in a WildFly domain.
> >> * Eliminate deployment from /deployments directory to make it a proper
> >> service instead of an ordinary app.
> >> * Eliminate need to explode or crack open auth-server.war. Keep it intact
> >> so
> >> it doesn't need to be hacked up.
> >> * Load user-provided overlays for keycloak-server.json, SPI jars, and
> >> theme
> >> jars.
> >> * Allow uploading overlays from CLI.
> >> * Allow more than one auth-server in a WildFly instance.
> >> * Compatibility with EAP6, EAP7, WildFly8, and WildFly9.
> >>
> >>
> >> Management Model
> >> The Keycloak subsystem introduces a new resource called, "auth-server".
> >> You
> >> can define more than one auth-server if you like. The simplest form just
> >> looks like this:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >> <auth-server name="my-auth-server-name"/>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> On startup, this deploys my-auth-server-name.war with web context "auth".
> >>
> >> There are two optional attributes under <auth-server>. They are "enabled"
> >> and
> >> "web-context". Here is an example:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >> <auth-server name="auth-server1"/>
> >> <auth-server name="auth-server2">
> >> <enabled>true<enabled/>
> >> <web-context>auth2</web-context>
> >> </auth-server>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> In a domain environment, there is an additional resource. You assign the
> >> auth
> >> server to one or more server groups:
> >> <subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >> <auth-server name="my-auth-server-name">
> >> <server-group name="group1"/>
> >> <server-group name="group2"/>
> >> </auth-server>
> >> </subsystem xmlns="urn:jboss:domain:keycloak:1.1">
> >>
> >> Loading the Auth Server
> >> The auth-server.war will be loaded from the Keycloak subsystem module.
> >> This
> >> is just a convenient place to put it. We could actually load it from
> >> anywhere. Note that it no longer needs to be exploded.
> >>
> >> Using Overalys
> >> The Keycloak subsystem can overlay or add to the auth-server.war. Overlays
> >> do
> >> not touch the original content of auth-server.war.
> >>
> >> To define an overaly, you just drop your files in the proper directories
> >> on
> >> the file system. The layout is:
> >>
> >> /overlays/<auth-server-name>/server-config/
> >> /overlays/<auth-server-name>/account-spi/
> >> /overlays/<auth-server-name>/login-spi/
> >> /overlays/<auth-server-name>/other-spi/
> >>
> >> /server-config optionally contains a single json file that replaces
> >> keycloak-server.json
> > What's the purpose of this? Are those config options not loaded from
> > standalone/domain.xml?
> That was my original intention.  The problem is that the management
> model needs metadata that is more well-defined than what we have in
> keycloak-server.json.  We could translate our own options to DMR but it
> would be impossible to know all the options available for third-party
> providers.  So we would have to do a meta-meta thing for that.  Yuck.
> 
> So the next thing I tried was to just imbed the keycloak-server.json
> directly into standalone/domain.xml.  That turned out kind of ugly.
> Better to just let it be its own file and use the same overlay technique
> we are using for everything else.  Cleaner to do everything the same way.
> 
> Anyway, that's my reasoning.  Feel free to poke holes if you disagree.
> >
> >> /account-spi optionally contains a single jar file that replaces
> >> keycloak-account-freemarker.jar.
> >> /login-spi optionally contains a single jar file that replaces
> >> keycloak-login-freemarker.jar
> > Why replace keycloak-*-freemarker.jar?
> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.html#d4e1060
> 
> For account or login SPI, it says to delete these jars or disable with a
> System property if you want to use your own provider.  I chose replace.
> It doesn't actually change the original auth-server.war on disk.  It's a
> virtual replace.

Ah, forgot that was how it used to work - that doc is out of date, sorry! You don't need to replace or use system properties any more, instead you configure the provider to use in keycloak-server.json:

  {
    "account" : {
      "provider": "my-account-provider"
    }
  }

Basically Keycloak either retrieves a named provider for an SPI (for example to get the ldap federation) or just picks the default provider configured for the server (for example account provider). The default provider is either specified as above, or if there's only one available it'll pick that one.

Made me think about another thing. How should we deal with what providers are included by default, and what users can add later? For instance we could just put everything in the auth-server.war as we do now, or we could have a simple mechanism to add those needed (stuff like ldap, google login, etc, etc..).

> >
> >> /other-spi optionally contains one or more spi jar files to be added to
> >> WEB-INF/lib. Theme jars also go here.
> >>
> >> Location of SPI jars and other user-defined overalys
> >> For now, I'm planning to have the /overlays directory in the Keycloak
> >> subsystem module. They could, for instance, go in a /keycloak directory
> >> such
> >> as <wildfly-home>/keycloak. Any thoughts on this?
> >>
> >> Uploading overlays from CLI
> >> It is already possible to create overalys via CLI. You upload the content
> >> and
> >> assign it to deployments and server-groups. The CLI commands for this are
> >> rather complicated and you really need to know what you are doing.
> >>
> >> We could make this easier by adding simpler CLI operations to the Keycloak
> >> subsystem. However, I think we should hold off on this until we find out
> >> if
> >> the directory-based approach is acceptable to users. In the mean time, we
> >> can just document the CLI commands needed to upload overlays.
> > It would be awesome to have the ability to upload jars and themes from the
> > KC admin console as well
> I agree.  Down the road we need to look into it.
> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From ssilvert at redhat.com  Thu Oct  2 08:46:01 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 02 Oct 2014 08:46:01 -0400
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <1348750769.60359924.1412252339590.JavaMail.zimbra@redhat.com>
References: <542C0F67.5020507@redhat.com>
	<2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>
	<542D403F.4020509@redhat.com>
	<1348750769.60359924.1412252339590.JavaMail.zimbra@redhat.com>
Message-ID: <542D4909.4030504@redhat.com>

On 10/2/2014 8:18 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: Thursday, 2 October, 2014 2:08:31 PM
>> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
>>
>>
>>>> /account-spi optionally contains a single jar file that replaces
>>>> keycloak-account-freemarker.jar.
>>>> /login-spi optionally contains a single jar file that replaces
>>>> keycloak-login-freemarker.jar
>>> Why replace keycloak-*-freemarker.jar?
>> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.html#d4e1060
>>
>> For account or login SPI, it says to delete these jars or disable with a
>> System property if you want to use your own provider.  I chose replace.
>> It doesn't actually change the original auth-server.war on disk.  It's a
>> virtual replace.
> Ah, forgot that was how it used to work - that doc is out of date, sorry! You don't need to replace or use system properties any more, instead you configure the provider to use in keycloak-server.json:
>
>    {
>      "account" : {
>        "provider": "my-account-provider"
>      }
>    }
>
> Basically Keycloak either retrieves a named provider for an SPI (for example to get the ldap federation) or just picks the default provider configured for the server (for example account provider). The default provider is either specified as above, or if there's only one available it'll pick that one.
That's much better.  So I just need one directory where you drop all the 
SPI jars.  Maybe I'll call it /plugins.  That name covers both SPI jars 
and theme jars.
>
> Made me think about another thing. How should we deal with what providers are included by default, and what users can add later? For instance we could just put everything in the auth-server.war as we do now, or we could have a simple mechanism to add those needed (stuff like ldap, google login, etc, etc..).
>
Is there a reason to leave them out?

From stian at redhat.com  Thu Oct  2 08:54:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 08:54:17 -0400 (EDT)
Subject: [keycloak-dev] Design of Auth Server startup from subsystem
In-Reply-To: <542D4909.4030504@redhat.com>
References: <542C0F67.5020507@redhat.com>
	<2052179518.60166717.1412230255250.JavaMail.zimbra@redhat.com>
	<542D403F.4020509@redhat.com>
	<1348750769.60359924.1412252339590.JavaMail.zimbra@redhat.com>
	<542D4909.4030504@redhat.com>
Message-ID: <1058239498.60385152.1412254457493.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: Thursday, 2 October, 2014 2:46:01 PM
> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> On 10/2/2014 8:18 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: Thursday, 2 October, 2014 2:08:31 PM
> >> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> >>
> >>
> >>>> /account-spi optionally contains a single jar file that replaces
> >>>> keycloak-account-freemarker.jar.
> >>>> /login-spi optionally contains a single jar file that replaces
> >>>> keycloak-login-freemarker.jar
> >>> Why replace keycloak-*-freemarker.jar?
> >> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.html#d4e1060
> >>
> >> For account or login SPI, it says to delete these jars or disable with a
> >> System property if you want to use your own provider.  I chose replace.
> >> It doesn't actually change the original auth-server.war on disk.  It's a
> >> virtual replace.
> > Ah, forgot that was how it used to work - that doc is out of date, sorry!
> > You don't need to replace or use system properties any more, instead you
> > configure the provider to use in keycloak-server.json:
> >
> >    {
> >      "account" : {
> >        "provider": "my-account-provider"
> >      }
> >    }
> >
> > Basically Keycloak either retrieves a named provider for an SPI (for
> > example to get the ldap federation) or just picks the default provider
> > configured for the server (for example account provider). The default
> > provider is either specified as above, or if there's only one available
> > it'll pick that one.
> That's much better.  So I just need one directory where you drop all the
> SPI jars.  Maybe I'll call it /plugins.  That name covers both SPI jars
> and theme jars.
> >
> > Made me think about another thing. How should we deal with what providers
> > are included by default, and what users can add later? For instance we
> > could just put everything in the auth-server.war as we do now, or we could
> > have a simple mechanism to add those needed (stuff like ldap, google
> > login, etc, etc..).
> >
> Is there a reason to leave them out?
> 

Size and to disable/remove certain features. Could be useful for other projects if they want to include a slim auth-server for OOTB experience. For example AeroGear currently excludes most providers (ldap, social, etc.).

From bburke at redhat.com  Thu Oct  2 09:01:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Oct 2014 09:01:53 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
Message-ID: <542D4CC1.3010908@redhat.com>



On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
> Currently adapters use the HTTP session to manage sessions. This works fine for most, but I believe there's situations when something different is needed. For example for stateless applications. It also doesn't work for bearer-only applications, or oauth clients.
>

What doesn't work for bearer only applications? It works fine.  Bearer 
is completely stateless already and doesn't rely on the HTTP Session for 
anything.

> I propose we add a Session SPI to adapters, which allows plugging in a mechanism to manage user sessions. The interface would be something along the lines of:
>
> * void addSession(String userId, String sessionId)
> * boolean isSessionValid(String sessionId)
> * boolean removeSession(String userId, String sessionId)
>

We already have something.  JBossWeb session mgmt API != Undertow 
session mgmt so there is already an abstraction.

> We could provide a few built in providers:
>
> * HTTP Session - store in http session as we currently do
> * Infinispan - store in an Infinispan cache
> * JPA - store in a database
> * Keycloak Session Endpoint - we could add a session info endpoint to Keycloak
> * None - no session management (relies on expiration of access token to logout users)
>

I'm not convinced at all we need this.  We shouldn't be reimplementing 
Http session replication as it was already done years and years ago...


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

From stian at redhat.com  Thu Oct  2 09:12:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 09:12:29 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542D4CC1.3010908@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
Message-ID: <271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 2 October, 2014 3:01:53 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
> > Currently adapters use the HTTP session to manage sessions. This works fine
> > for most, but I believe there's situations when something different is
> > needed. For example for stateless applications. It also doesn't work for
> > bearer-only applications, or oauth clients.
> >
> 
> What doesn't work for bearer only applications? It works fine.  Bearer
> is completely stateless already and doesn't rely on the HTTP Session for
> anything.

Bearer-only doesn't have any way to check if a session is still valid.

> 
> > I propose we add a Session SPI to adapters, which allows plugging in a
> > mechanism to manage user sessions. The interface would be something along
> > the lines of:
> >
> > * void addSession(String userId, String sessionId)
> > * boolean isSessionValid(String sessionId)
> > * boolean removeSession(String userId, String sessionId)
> >
> 
> We already have something.  JBossWeb session mgmt API != Undertow
> session mgmt so there is already an abstraction.
> 
> > We could provide a few built in providers:
> >
> > * HTTP Session - store in http session as we currently do
> > * Infinispan - store in an Infinispan cache
> > * JPA - store in a database
> > * Keycloak Session Endpoint - we could add a session info endpoint to
> > Keycloak
> > * None - no session management (relies on expiration of access token to
> > logout users)
> >
> 
> I'm not convinced at all we need this.  We shouldn't be reimplementing
> Http session replication as it was already done years and years ago...

The whole idea is not to require a http session for applications that don't want that. There was already a guy requesting this on the mailing list.

> 
> 
> --
> 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 Oct  2 09:23:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Oct 2014 09:23:46 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
Message-ID: <542D51E2.30500@redhat.com>



On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 2 October, 2014 3:01:53 PM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
>>> Currently adapters use the HTTP session to manage sessions. This works fine
>>> for most, but I believe there's situations when something different is
>>> needed. For example for stateless applications. It also doesn't work for
>>> bearer-only applications, or oauth clients.
>>>
>>
>> What doesn't work for bearer only applications? It works fine.  Bearer
>> is completely stateless already and doesn't rely on the HTTP Session for
>> anything.
>
> Bearer-only doesn't have any way to check if a session is still valid.
>

If bearer-only doesn't keep track of revocation policy events then that 
is an oversight and must be fixed.  Bearer only apps are stateless and 
don't have HTTP Sessions.  Asking them to keep track of each and every 
Keycloak user session is just not feasible.  We do have a token 
validation REST resource.  Bearer-only apps could be configured to call 
back to the auth server to validate the token.

>>
>>> I propose we add a Session SPI to adapters, which allows plugging in a
>>> mechanism to manage user sessions. The interface would be something along
>>> the lines of:
>>>
>>> * void addSession(String userId, String sessionId)
>>> * boolean isSessionValid(String sessionId)
>>> * boolean removeSession(String userId, String sessionId)
>>>
>>
>> We already have something.  JBossWeb session mgmt API != Undertow
>> session mgmt so there is already an abstraction.
>>
>>> We could provide a few built in providers:
>>>
>>> * HTTP Session - store in http session as we currently do
>>> * Infinispan - store in an Infinispan cache
>>> * JPA - store in a database
>>> * Keycloak Session Endpoint - we could add a session info endpoint to
>>> Keycloak
>>> * None - no session management (relies on expiration of access token to
>>> logout users)
>>>
>>
>> I'm not convinced at all we need this.  We shouldn't be reimplementing
>> Http session replication as it was already done years and years ago...
>
> The whole idea is not to require a http session for applications that don't want that. There was already a guy requesting this on the mailing list.
>

For bearer only apps, HTTP session is not used.  For browser apps, 
hitting the auth server every single request is just stupid.  So, in 
that case a JWS or JWE cookie would have to hold authentication state. 
IIRC, I used to implement it that way in either Keycloak or Resteasy's 
OAuth implementation.



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

From stian at redhat.com  Thu Oct  2 09:43:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Oct 2014 09:43:43 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542D51E2.30500@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
Message-ID: <1220564959.60422376.1412257423758.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: Thursday, 2 October, 2014 3:23:46 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 2 October, 2014 3:01:53 PM
> >> Subject: Re: [keycloak-dev] Session SPI for adapters
> >>
> >>
> >>
> >> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
> >>> Currently adapters use the HTTP session to manage sessions. This works
> >>> fine
> >>> for most, but I believe there's situations when something different is
> >>> needed. For example for stateless applications. It also doesn't work for
> >>> bearer-only applications, or oauth clients.
> >>>
> >>
> >> What doesn't work for bearer only applications? It works fine.  Bearer
> >> is completely stateless already and doesn't rely on the HTTP Session for
> >> anything.
> >
> > Bearer-only doesn't have any way to check if a session is still valid.
> >
> 
> If bearer-only doesn't keep track of revocation policy events then that
> is an oversight and must be fixed.  Bearer only apps are stateless and
> don't have HTTP Sessions.  Asking them to keep track of each and every
> Keycloak user session is just not feasible.  We do have a token
> validation REST resource.  Bearer-only apps could be configured to call
> back to the auth server to validate the token.
> 
> >>
> >>> I propose we add a Session SPI to adapters, which allows plugging in a
> >>> mechanism to manage user sessions. The interface would be something along
> >>> the lines of:
> >>>
> >>> * void addSession(String userId, String sessionId)
> >>> * boolean isSessionValid(String sessionId)
> >>> * boolean removeSession(String userId, String sessionId)
> >>>
> >>
> >> We already have something.  JBossWeb session mgmt API != Undertow
> >> session mgmt so there is already an abstraction.
> >>
> >>> We could provide a few built in providers:
> >>>
> >>> * HTTP Session - store in http session as we currently do
> >>> * Infinispan - store in an Infinispan cache
> >>> * JPA - store in a database
> >>> * Keycloak Session Endpoint - we could add a session info endpoint to
> >>> Keycloak
> >>> * None - no session management (relies on expiration of access token to
> >>> logout users)
> >>>
> >>
> >> I'm not convinced at all we need this.  We shouldn't be reimplementing
> >> Http session replication as it was already done years and years ago...
> >
> > The whole idea is not to require a http session for applications that don't
> > want that. There was already a guy requesting this on the mailing list.
> >
> 
> For bearer only apps, HTTP session is not used.  For browser apps,
> hitting the auth server every single request is just stupid.  So, in
> that case a JWS or JWE cookie would have to hold authentication state.
> IIRC, I used to implement it that way in either Keycloak or Resteasy's
> OAuth implementation.

Who said hitting the auth-server for every request?

With a single Infinispan cluster or a shared db multiple apps could talk to that to check the session instead of having to hit KC. Also, they'd be able to be fully stateless.

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

From ssilvert at redhat.com  Thu Oct  2 09:54:19 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 02 Oct 2014 09:54:19 -0400
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
References: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
Message-ID: <542D590B.1010803@redhat.com>

+1

On 10/2/2014 3:49 AM, Stian Thorgersen wrote:
> A few things I'd like us to follow with regards to using JIRA:
>
> * Create a JIRA for all changes/fixes/improvements - unless they have no effect on users
> * When completing an issue mark as resolved (not closed) - we'll close when we do a release (otherwise we can't change fix version without re-opening the issue)
>
> A few things for Git:
>
> * Try to keep it to a single commit per-JIRA
> * Refer to JIRA issue in the commit message
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Oct  2 11:07:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Oct 2014 11:07:09 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
Message-ID: <542D6A1D.1030705@redhat.com>



On 10/2/2014 9:43 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 2 October, 2014 3:23:46 PM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 2 October, 2014 3:01:53 PM
>>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>>
>>>>
>>>>
>>>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
>>>>> Currently adapters use the HTTP session to manage sessions. This works
>>>>> fine
>>>>> for most, but I believe there's situations when something different is
>>>>> needed. For example for stateless applications. It also doesn't work for
>>>>> bearer-only applications, or oauth clients.
>>>>>
>>>>
>>>> What doesn't work for bearer only applications? It works fine.  Bearer
>>>> is completely stateless already and doesn't rely on the HTTP Session for
>>>> anything.
>>>
>>> Bearer-only doesn't have any way to check if a session is still valid.
>>>
>>
>> If bearer-only doesn't keep track of revocation policy events then that
>> is an oversight and must be fixed.  Bearer only apps are stateless and
>> don't have HTTP Sessions.  Asking them to keep track of each and every
>> Keycloak user session is just not feasible.  We do have a token
>> validation REST resource.  Bearer-only apps could be configured to call
>> back to the auth server to validate the token.
>>
>>>>
>>>>> I propose we add a Session SPI to adapters, which allows plugging in a
>>>>> mechanism to manage user sessions. The interface would be something along
>>>>> the lines of:
>>>>>
>>>>> * void addSession(String userId, String sessionId)
>>>>> * boolean isSessionValid(String sessionId)
>>>>> * boolean removeSession(String userId, String sessionId)
>>>>>
>>>>
>>>> We already have something.  JBossWeb session mgmt API != Undertow
>>>> session mgmt so there is already an abstraction.
>>>>
>>>>> We could provide a few built in providers:
>>>>>
>>>>> * HTTP Session - store in http session as we currently do
>>>>> * Infinispan - store in an Infinispan cache
>>>>> * JPA - store in a database
>>>>> * Keycloak Session Endpoint - we could add a session info endpoint to
>>>>> Keycloak
>>>>> * None - no session management (relies on expiration of access token to
>>>>> logout users)
>>>>>
>>>>
>>>> I'm not convinced at all we need this.  We shouldn't be reimplementing
>>>> Http session replication as it was already done years and years ago...
>>>
>>> The whole idea is not to require a http session for applications that don't
>>> want that. There was already a guy requesting this on the mailing list.
>>>
>>
>> For bearer only apps, HTTP session is not used.  For browser apps,
>> hitting the auth server every single request is just stupid.  So, in
>> that case a JWS or JWE cookie would have to hold authentication state.
>> IIRC, I used to implement it that way in either Keycloak or Resteasy's
>> OAuth implementation.
>
> Who said hitting the auth-server for every request?
>
> With a single Infinispan cluster or a shared db multiple apps could talk to that to check the session instead of having to hit KC. Also, they'd be able to be fully stateless.
>

So every session create and logout you want broadcasted to every single 
instance of every single application?  In that case, why don't you take 
it further and ditch the keycloak server entirely?  Store everything in 
infinispan.  It would also probably be pointless to use oauth, oidc, or 
SAML too.  If you really think that kind of architecture will actually 
scale, go for it.

Bill

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

From Frank.French at causeway.com  Thu Oct  2 11:42:35 2014
From: Frank.French at causeway.com (Frank French)
Date: Thu, 2 Oct 2014 15:42:35 +0000
Subject: [keycloak-dev] Multi-tenancy
Message-ID: <D05330FA.181CB%frank.french@causeway.com>

Hi

I've been looking at using Keycloak to secure our cloud based apps. Everything I've tried up until now has worked like a charm (very impressed especially with the docs).

What I'm trying to do now is decide programatically which database schema to use based on the user credentials. I've had a multi-tenanted database working before so I'm not looking for help configuring that side of things. I'd like to know whether there is anything within Keycloak that I could use as a tenant identifier or whether I'm missing the point and there's a much slicker way of performing this type of operation.

Just so I'm clear I'm expecting there to be 1 Keycloak athentication database and 1 application database supporting multiple schemas.


Frank


________________________________

Causeway is committed towards reducing its carbon footprint. Please consider the environment before printing this email.

________________________________


Disclaimer Notice :-

The message and any attachments contained in this e-mail are intended for the named recipient(s) only. It may contain privileged or confidential information or information which is exempt from disclosure under the applicable laws. If you are not the intended recipient(s), you must not read, print, retain, copy distribute, forward or take any or refrain from taking any action in reliance on it or any of its attachments. If you have received or have been forwarded this e-mail in error, please notify us immediately by return e-mail or telephone (+44 (0)1628 552000) and delete this message from the computer or any other data-reading device in its entirety.

Please advise us immediately if you do not or your employer does not consent to Internet e-mail for messages of this nature.

Internet communications cannot be guaranteed to be secure and error-free as the information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender and this Company therefore do not and shall not accept any liability or responsibility of whatsoever nature in the context of this message and its attachment(s) which arises as a result of Internet transmission. Opinions, conclusion, representations, views and such other information in this message that do not relate to the official business of this Company shall be understood as neither given nor endorsed by it.

Registered Office: Comino House, Furlong Road, Bourne End, Buckinghamshire, SL8 5AQ
Registered in England No: 3921897 www.causeway.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141002/c3d3ee59/attachment-0001.html 

From bburke at redhat.com  Thu Oct  2 13:15:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Oct 2014 13:15:34 -0400
Subject: [keycloak-dev] Multi-tenancy
In-Reply-To: <D05330FA.181CB%frank.french@causeway.com>
References: <D05330FA.181CB%frank.french@causeway.com>
Message-ID: <542D8836.8000003@redhat.com>

We don't have a way yet of piggybacking any extra user info beyond basic 
claims.  Its on the roadmap though.

On 10/2/2014 11:42 AM, Frank French wrote:
> Hi
>
> I?ve been looking at using Keycloak to secure our cloud based apps.
> Everything I?ve tried up until now has worked like a charm (very
> impressed especially with the docs).
>
> What I?m trying to do now is decide programatically which database
> schema to use based on the user credentials. I?ve had a multi-tenanted
> database working before so I?m not looking for help configuring that
> side of things. I?d like to know whether there is anything within
> Keycloak that I could use as a tenant identifier or whether I?m missing
> the point and there?s a much slicker way of performing this type of
> operation.
>
> Just so I?m clear I?m expecting there to be 1 Keycloak athentication
> database and 1 application database supporting multiple schemas.
>
> *Frank*
>
>
>
> ------------------------------------------------------------------------
>
> Causeway is committed towards reducing its carbon footprint. Please
> consider the environment before printing this email.
>
> ------------------------------------------------------------------------
>
>
> Disclaimer Notice :-
>
> The message and any attachments contained in this e-mail are intended
> for the named recipient(s) only. It may contain privileged or
> confidential information or information which is exempt from disclosure
> under the applicable laws. If you are not the intended recipient(s), you
> must not read, print, retain, copy distribute, forward or take any or
> refrain from taking any action in reliance on it or any of its
> attachments. If you have received or have been forwarded this e-mail in
> error, please notify us immediately by return e-mail or telephone (+44
> (0)1628 552000) and delete this message from the computer or any other
> data-reading device in its entirety.
>
> Please advise us immediately if you do not or your employer does not
> consent to Internet e-mail for messages of this nature.
>
> Internet communications cannot be guaranteed to be secure and error-free
> as the information could be intercepted, corrupted, lost, arrive late or
> contain viruses. The sender and this Company therefore do not and shall
> not accept any liability or responsibility of whatsoever nature in the
> context of this message and its attachment(s) which arises as a result
> of Internet transmission. Opinions, conclusion, representations, views
> and such other information in this message that do not relate to the
> official business of this Company shall be understood as neither given
> nor endorsed by it.
>
> Registered Office: Comino House, Furlong Road, Bourne End,
> Buckinghamshire, SL8 5AQ
> Registered in England No: 3921897 www.causeway.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 Oct  3 02:27:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 3 Oct 2014 02:27:20 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542D6A1D.1030705@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
Message-ID: <256105327.60878442.1412317640961.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: Thursday, 2 October, 2014 5:07:09 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> On 10/2/2014 9:43 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 2 October, 2014 3:23:46 PM
> >> Subject: Re: [keycloak-dev] Session SPI for adapters
> >>
> >>
> >>
> >> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 2 October, 2014 3:01:53 PM
> >>>> Subject: Re: [keycloak-dev] Session SPI for adapters
> >>>>
> >>>>
> >>>>
> >>>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
> >>>>> Currently adapters use the HTTP session to manage sessions. This works
> >>>>> fine
> >>>>> for most, but I believe there's situations when something different is
> >>>>> needed. For example for stateless applications. It also doesn't work
> >>>>> for
> >>>>> bearer-only applications, or oauth clients.
> >>>>>
> >>>>
> >>>> What doesn't work for bearer only applications? It works fine.  Bearer
> >>>> is completely stateless already and doesn't rely on the HTTP Session for
> >>>> anything.
> >>>
> >>> Bearer-only doesn't have any way to check if a session is still valid.
> >>>
> >>
> >> If bearer-only doesn't keep track of revocation policy events then that
> >> is an oversight and must be fixed.  Bearer only apps are stateless and
> >> don't have HTTP Sessions.  Asking them to keep track of each and every
> >> Keycloak user session is just not feasible.  We do have a token
> >> validation REST resource.  Bearer-only apps could be configured to call
> >> back to the auth server to validate the token.
> >>
> >>>>
> >>>>> I propose we add a Session SPI to adapters, which allows plugging in a
> >>>>> mechanism to manage user sessions. The interface would be something
> >>>>> along
> >>>>> the lines of:
> >>>>>
> >>>>> * void addSession(String userId, String sessionId)
> >>>>> * boolean isSessionValid(String sessionId)
> >>>>> * boolean removeSession(String userId, String sessionId)
> >>>>>
> >>>>
> >>>> We already have something.  JBossWeb session mgmt API != Undertow
> >>>> session mgmt so there is already an abstraction.
> >>>>
> >>>>> We could provide a few built in providers:
> >>>>>
> >>>>> * HTTP Session - store in http session as we currently do
> >>>>> * Infinispan - store in an Infinispan cache
> >>>>> * JPA - store in a database
> >>>>> * Keycloak Session Endpoint - we could add a session info endpoint to
> >>>>> Keycloak
> >>>>> * None - no session management (relies on expiration of access token to
> >>>>> logout users)
> >>>>>
> >>>>
> >>>> I'm not convinced at all we need this.  We shouldn't be reimplementing
> >>>> Http session replication as it was already done years and years ago...
> >>>
> >>> The whole idea is not to require a http session for applications that
> >>> don't
> >>> want that. There was already a guy requesting this on the mailing list.
> >>>
> >>
> >> For bearer only apps, HTTP session is not used.  For browser apps,
> >> hitting the auth server every single request is just stupid.  So, in
> >> that case a JWS or JWE cookie would have to hold authentication state.
> >> IIRC, I used to implement it that way in either Keycloak or Resteasy's
> >> OAuth implementation.
> >
> > Who said hitting the auth-server for every request?
> >
> > With a single Infinispan cluster or a shared db multiple apps could talk to
> > that to check the session instead of having to hit KC. Also, they'd be
> > able to be fully stateless.
> >
> 
> So every session create and logout you want broadcasted to every single
> instance of every single application?  In that case, why don't you take
> it further and ditch the keycloak server entirely?  Store everything in
> infinispan.  It would also probably be pointless to use oauth, oidc, or
> SAML too.  If you really think that kind of architecture will actually
> scale, go for it.

Huh?

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

From stian at redhat.com  Fri Oct  3 02:38:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 3 Oct 2014 02:38:50 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
Message-ID: <937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>

Let's take a step-back here and consider the problem instead of a potential solution.

Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.

I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 3 October, 2014 8:27:20 AM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 2 October, 2014 5:07:09 PM
> > Subject: Re: [keycloak-dev] Session SPI for adapters
> > 
> > 
> > 
> > On 10/2/2014 9:43 AM, Stian Thorgersen wrote:
> > >
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, 2 October, 2014 3:23:46 PM
> > >> Subject: Re: [keycloak-dev] Session SPI for adapters
> > >>
> > >>
> > >>
> > >> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: keycloak-dev at lists.jboss.org
> > >>>> Sent: Thursday, 2 October, 2014 3:01:53 PM
> > >>>> Subject: Re: [keycloak-dev] Session SPI for adapters
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
> > >>>>> Currently adapters use the HTTP session to manage sessions. This
> > >>>>> works
> > >>>>> fine
> > >>>>> for most, but I believe there's situations when something different
> > >>>>> is
> > >>>>> needed. For example for stateless applications. It also doesn't work
> > >>>>> for
> > >>>>> bearer-only applications, or oauth clients.
> > >>>>>
> > >>>>
> > >>>> What doesn't work for bearer only applications? It works fine.  Bearer
> > >>>> is completely stateless already and doesn't rely on the HTTP Session
> > >>>> for
> > >>>> anything.
> > >>>
> > >>> Bearer-only doesn't have any way to check if a session is still valid.
> > >>>
> > >>
> > >> If bearer-only doesn't keep track of revocation policy events then that
> > >> is an oversight and must be fixed.  Bearer only apps are stateless and
> > >> don't have HTTP Sessions.  Asking them to keep track of each and every
> > >> Keycloak user session is just not feasible.  We do have a token
> > >> validation REST resource.  Bearer-only apps could be configured to call
> > >> back to the auth server to validate the token.
> > >>
> > >>>>
> > >>>>> I propose we add a Session SPI to adapters, which allows plugging in
> > >>>>> a
> > >>>>> mechanism to manage user sessions. The interface would be something
> > >>>>> along
> > >>>>> the lines of:
> > >>>>>
> > >>>>> * void addSession(String userId, String sessionId)
> > >>>>> * boolean isSessionValid(String sessionId)
> > >>>>> * boolean removeSession(String userId, String sessionId)
> > >>>>>
> > >>>>
> > >>>> We already have something.  JBossWeb session mgmt API != Undertow
> > >>>> session mgmt so there is already an abstraction.
> > >>>>
> > >>>>> We could provide a few built in providers:
> > >>>>>
> > >>>>> * HTTP Session - store in http session as we currently do
> > >>>>> * Infinispan - store in an Infinispan cache
> > >>>>> * JPA - store in a database
> > >>>>> * Keycloak Session Endpoint - we could add a session info endpoint to
> > >>>>> Keycloak
> > >>>>> * None - no session management (relies on expiration of access token
> > >>>>> to
> > >>>>> logout users)
> > >>>>>
> > >>>>
> > >>>> I'm not convinced at all we need this.  We shouldn't be reimplementing
> > >>>> Http session replication as it was already done years and years ago...
> > >>>
> > >>> The whole idea is not to require a http session for applications that
> > >>> don't
> > >>> want that. There was already a guy requesting this on the mailing list.
> > >>>
> > >>
> > >> For bearer only apps, HTTP session is not used.  For browser apps,
> > >> hitting the auth server every single request is just stupid.  So, in
> > >> that case a JWS or JWE cookie would have to hold authentication state.
> > >> IIRC, I used to implement it that way in either Keycloak or Resteasy's
> > >> OAuth implementation.
> > >
> > > Who said hitting the auth-server for every request?
> > >
> > > With a single Infinispan cluster or a shared db multiple apps could talk
> > > to
> > > that to check the session instead of having to hit KC. Also, they'd be
> > > able to be fully stateless.
> > >
> > 
> > So every session create and logout you want broadcasted to every single
> > instance of every single application?  In that case, why don't you take
> > it further and ditch the keycloak server entirely?  Store everything in
> > infinispan.  It would also probably be pointless to use oauth, oidc, or
> > SAML too.  If you really think that kind of architecture will actually
> > scale, go for it.
> 
> Huh?
> 
> > 
> > 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 mposolda at redhat.com  Fri Oct  3 06:30:48 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 03 Oct 2014 12:30:48 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
Message-ID: <542E7AD8.4010408@redhat.com>

On 3.10.2014 08:38, Stian Thorgersen wrote:
> Let's take a step-back here and consider the problem instead of a potential solution.
>
> Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.
>
> I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?
One possibility I can think about is, that adapters would have some 
option to specify if they are:
- statefull (In this case HttpSession is used as is now)
- stateless (In this case token stored in the cookie like 
KEYCLOAK_PRINCIPAL)

Now for logouts I can see 2 possible flows:
1) Single sign-out which will use browser redirection for stateless apps 
(combined with backend requests for statefull apps as is now)

Details:
The option would need to be added to ApplicationModel as well. Now when 
single-sign out happens, then ResourceAdminManager.logoutApplication 
will be able to:
* In case that application is statefull, do the same as is know (invoke 
admin endpoint with httpClient)
* In case that application is stateless, it will do browser redirection 
to the application. Applications would need to have endpoint, which will 
be able to handle this and just invalidate KEYCLOAK_PRINCIPAL cookie and 
redirect back to KC. In ResourceAdminManager.logoutApplication will need 
to remove application from UserSession before this redirection happens, 
so the app logout is not invoked more times from ResourceAdminManager.

2) Logout just for the original stateless app (So not single-sign out 
for other browser stateless apps in browser):
Details:
* User invokes endpoint like 
"http://localhost:8080/customer-portal/logoutMe"
*In case that it's "stateless" app, adapter will be able to recognize it 
and it will expire KEYCLOAK_PRINCIPAL cookie. Then it will redirect to 
logout endpoint like: 
http://host/auth/realms/demo/protocol/openid-connect/logout as is now.

Flow 2 is quite easy to add and won't require any changes in Keycloak 
server. But it will logout just original application and "stateful" apps 
in this browser. "Stateless" applications != original app won't be 
logged out.

Flow 1 is complicated and requires more changes . It addresses 
single-sign out but just when invoked by user himself from his browser.

In any of those, admin user won't be able to logout and also he won't be 
able to invoke endpoints provided in ResourceAdminManager for those apps 
(statistics etc). So for stateless apps, logout by admin will always 
need to rely on the token expiration...

IMHO at least add the stateless possibility to adapters and do the 
"easy" path (flow 2) worth an effort.

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: Friday, 3 October, 2014 8:27:20 AM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 2 October, 2014 5:07:09 PM
>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>
>>>
>>>
>>> On 10/2/2014 9:43 AM, Stian Thorgersen wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 2 October, 2014 3:23:46 PM
>>>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>>>
>>>>>
>>>>>
>>>>> On 10/2/2014 9:12 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, 2 October, 2014 3:01:53 PM
>>>>>>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 10/2/2014 4:47 AM, Stian Thorgersen wrote:
>>>>>>>> Currently adapters use the HTTP session to manage sessions. This
>>>>>>>> works
>>>>>>>> fine
>>>>>>>> for most, but I believe there's situations when something different
>>>>>>>> is
>>>>>>>> needed. For example for stateless applications. It also doesn't work
>>>>>>>> for
>>>>>>>> bearer-only applications, or oauth clients.
>>>>>>>>
>>>>>>> What doesn't work for bearer only applications? It works fine.  Bearer
>>>>>>> is completely stateless already and doesn't rely on the HTTP Session
>>>>>>> for
>>>>>>> anything.
>>>>>> Bearer-only doesn't have any way to check if a session is still valid.
>>>>>>
>>>>> If bearer-only doesn't keep track of revocation policy events then that
>>>>> is an oversight and must be fixed.  Bearer only apps are stateless and
>>>>> don't have HTTP Sessions.  Asking them to keep track of each and every
>>>>> Keycloak user session is just not feasible.  We do have a token
>>>>> validation REST resource.  Bearer-only apps could be configured to call
>>>>> back to the auth server to validate the token.
>>>>>
>>>>>>>> I propose we add a Session SPI to adapters, which allows plugging in
>>>>>>>> a
>>>>>>>> mechanism to manage user sessions. The interface would be something
>>>>>>>> along
>>>>>>>> the lines of:
>>>>>>>>
>>>>>>>> * void addSession(String userId, String sessionId)
>>>>>>>> * boolean isSessionValid(String sessionId)
>>>>>>>> * boolean removeSession(String userId, String sessionId)
>>>>>>>>
>>>>>>> We already have something.  JBossWeb session mgmt API != Undertow
>>>>>>> session mgmt so there is already an abstraction.
>>>>>>>
>>>>>>>> We could provide a few built in providers:
>>>>>>>>
>>>>>>>> * HTTP Session - store in http session as we currently do
>>>>>>>> * Infinispan - store in an Infinispan cache
>>>>>>>> * JPA - store in a database
>>>>>>>> * Keycloak Session Endpoint - we could add a session info endpoint to
>>>>>>>> Keycloak
>>>>>>>> * None - no session management (relies on expiration of access token
>>>>>>>> to
>>>>>>>> logout users)
>>>>>>>>
>>>>>>> I'm not convinced at all we need this.  We shouldn't be reimplementing
>>>>>>> Http session replication as it was already done years and years ago...
>>>>>> The whole idea is not to require a http session for applications that
>>>>>> don't
>>>>>> want that. There was already a guy requesting this on the mailing list.
>>>>>>
>>>>> For bearer only apps, HTTP session is not used.  For browser apps,
>>>>> hitting the auth server every single request is just stupid.  So, in
>>>>> that case a JWS or JWE cookie would have to hold authentication state.
>>>>> IIRC, I used to implement it that way in either Keycloak or Resteasy's
>>>>> OAuth implementation.
>>>> Who said hitting the auth-server for every request?
>>>>
>>>> With a single Infinispan cluster or a shared db multiple apps could talk
>>>> to
>>>> that to check the session instead of having to hit KC. Also, they'd be
>>>> able to be fully stateless.
>>>>
>>> So every session create and logout you want broadcasted to every single
>>> instance of every single application?  In that case, why don't you take
>>> it further and ditch the keycloak server entirely?  Store everything in
>>> infinispan.  It would also probably be pointless to use oauth, oidc, or
>>> SAML too.  If you really think that kind of architecture will actually
>>> scale, go for it.
>> Huh?
>>
>>> Bill
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Oct  3 11:17:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Oct 2014 11:17:50 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D4CC1.3010908@redhat.com>
	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
Message-ID: <542EBE1E.5040905@redhat.com>



On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
> Let's take a step-back here and consider the problem instead of a potential solution.
>
> Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.
>
> I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?
>

You don't have to change anything for bearer-only apps.  Blacklist and 
time-based revocation policies are enough.

For browser apps, the problem is logout.  Cookie won't work for logout. 
  While you could logout one user via a browser redirect protocol, 
doesn't work when an admin wants to initiate a logout to one or all 
users from the admin console.  This is because a logout generates an 
out-of-band request to each application.  The applications match the 
UserSessionModel id with an HTTP Session and invalidate the session.  So 
the adapter needs a UserSessionModel->HttpSession id map.

Maybe the access code to token protocol could be modified to send the 
Http session id?  This could be stored in the client session and sent 
with the out-of-band logout request.


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

From bburke at redhat.com  Fri Oct  3 11:27:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Oct 2014 11:27:46 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542E7AD8.4010408@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542E7AD8.4010408@redhat.com>
Message-ID: <542EC072.9030105@redhat.com>



On 10/3/2014 6:30 AM, Marek Posolda wrote:
> On 3.10.2014 08:38, Stian Thorgersen wrote:
>> Let's take a step-back here and consider the problem instead of a potential solution.
>>
>> Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.
>>
>> I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?
> One possibility I can think about is, that adapters would have some
> option to specify if they are:
> - statefull (In this case HttpSession is used as is now)
> - stateless (In this case token stored in the cookie like
> KEYCLOAK_PRINCIPAL)
>

Stateless browser apps could also just be configured to override token 
timeouts.  Either:

a) Refresh the access token on every request
b) Do a shorter token timeout.

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

From bburke at redhat.com  Sat Oct  4 22:18:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 04 Oct 2014 22:18:55 -0400
Subject: [keycloak-dev] saml basic committed
Message-ID: <5430AA8F.8010304@redhat.com>

Got basic SAML POST binding working and committed with PL quickstart.

Still a lot to do:

* Don't know if it works with appliance yet.  There might be some 
classloader voodoo I have to overcome
* SAML logout support is next
* Get support for signatures/encryption
* Client admin console config for saml.  There's a lot of metadata that 
might be needed
* testsuite

Still probably a few weeks away from being done.

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

From mposolda at redhat.com  Sun Oct  5 16:59:28 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Sun, 05 Oct 2014 22:59:28 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542EBE1E.5040905@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com>
Message-ID: <5431B130.3080905@redhat.com>

On 3.10.2014 17:17, Bill Burke wrote:
>
> On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
>> Let's take a step-back here and consider the problem instead of a potential solution.
>>
>> Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.
>>
>> I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?
>>
> You don't have to change anything for bearer-only apps.  Blacklist and
> time-based revocation policies are enough.
>
> For browser apps, the problem is logout.  Cookie won't work for logout.
>    While you could logout one user via a browser redirect protocol,
> doesn't work when an admin wants to initiate a logout to one or all
> users from the admin console.  This is because a logout generates an
> out-of-band request to each application.  The applications match the
> UserSessionModel id with an HTTP Session and invalidate the session.  So
> the adapter needs a UserSessionModel->HttpSession id map.
>
> Maybe the access code to token protocol could be modified to send the
> Http session id?  This could be stored in the client session and sent
> with the out-of-band logout request.
>
>
I think that this will be good . Perhaps HttpSession ID could be stored 
on ClientSessionModel as note, so no changes on UserSession model required?

Related issue is that our UserSessionManagement implementations (for 
both undertow and AS7) are stateful. Is it issue to refactor them to be 
stateless? With HttpSession passed around from KC it will be possible imo.

Stateful impls have issues like:
- State in UndertowUserSessionManagement and CatalinaUserManagement is 
stored in ConcurrentHashMaps and hence is not cluster-aware . This is 
causing issues especially with logout (for example login happens on 
node1, but admin out-of-bound request is handled on node2 -> it won't be 
able to find session in it's maps -> logout won't happen as user is 
still logged on node1)
- Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734

I experimented on Friday and did prototype of UserSessionManagement 
impls backed by infinispan (this can address both cluster and memory 
leak), but tbh I am not so happy with it. IMO stateless 
UserSessionManagement is a way to go. What I can see for particular 
UserSessionManagement operations:
- logoutKeycloakSession will be easy to handle as long as logout req 
from KC will send HttpSessionID. So we don't need any state with mapping 
from kcSessions to HttpSessions.
- logoutUser --- Instead of sending username, Keycloak can send list of 
all HttpSessions of user for this app. Those all will be invalidated
- logoutAll --- Both undertow Manager and org.apache.catalina.Manager 
has possibility to list all HttpSessions and invalidate them (This will 
invalidate also anonymous HttpSessions, but is this an issue?)

Other methods for UserSessionManagement are for handle statistics, but 
do we really need them? Endpoint for 
PreAuthActionsHandler.handleGetUserStats() is not called from any place 
in Keycloak admin console. KC admin console is just using UserSession 
API directly. Is it an issue to remove 
PreAuthActionsHandler.handleGetUserStats() and all related methods from 
UserSessionManagement?

Marek


From mposolda at redhat.com  Sun Oct  5 17:04:10 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Sun, 05 Oct 2014 23:04:10 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <542EC072.9030105@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>	<542E7AD8.4010408@redhat.com>
	<542EC072.9030105@redhat.com>
Message-ID: <5431B24A.9030002@redhat.com>

On 3.10.2014 17:27, Bill Burke wrote:
>
> On 10/3/2014 6:30 AM, Marek Posolda wrote:
>> On 3.10.2014 08:38, Stian Thorgersen wrote:
>>> Let's take a step-back here and consider the problem instead of a potential solution.
>>>
>>> Currently we require all applications to have an HTTP session to keep track of the users session as well as storing the tokens. When an application is clustered this requires replicating the HTTP session to all nodes, or using sticky load balancer sessions.
>>>
>>> I think it's quite likely that some don't want to have a HTTP session and instead store the token in a cookie to make the application fully stateless. That's simple enough to add right? And storing the token in a http-only cookie should be safe as well. However, one issue remains how do we deal with single-sign out in this case. As there's no state kept in the application a logout admin event from Keycloak isn't going to work. So would be just rely on the access token expiring in this case? Or could we add something better?
>> One possibility I can think about is, that adapters would have some
>> option to specify if they are:
>> - statefull (In this case HttpSession is used as is now)
>> - stateless (In this case token stored in the cookie like
>> KEYCLOAK_PRINCIPAL)
>>
> Stateless browser apps could also just be configured to override token
> timeouts.  Either:
>
> a) Refresh the access token on every request
> b) Do a shorter token timeout.
>
Ok, (b) is already possible. For (a) we can add option to adapters?

From matzew at apache.org  Mon Oct  6 04:43:30 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 6 Oct 2014 10:43:30 +0200
Subject: [keycloak-dev] database migration
Message-ID: <CAAg5f2T1GEa7QJUQE0zEjDOrPirtAMj=bSFMGjfyqd_P_9bkVQ@mail.gmail.com>

hello there.

I have one question, looks like between 1.0-rc-1 and 1.0-final there were
some changes on the underlying database model:
http://lists.jboss.org/pipermail/aerogear-dev/2014-October/009202.html

I guess this is fine, since it was before the -final, but wanted to double
check if you guys have any database migration scripts.

Thanks,
Matthias

-- 
Matthias Wessendorf

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

From stian at redhat.com  Mon Oct  6 04:48:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 04:48:58 -0400 (EDT)
Subject: [keycloak-dev] database migration
In-Reply-To: <CAAg5f2T1GEa7QJUQE0zEjDOrPirtAMj=bSFMGjfyqd_P_9bkVQ@mail.gmail.com>
References: <CAAg5f2T1GEa7QJUQE0zEjDOrPirtAMj=bSFMGjfyqd_P_9bkVQ@mail.gmail.com>
Message-ID: <1346751256.61771247.1412585338699.JavaMail.zimbra@redhat.com>

Hi,

There was some changes of the DB between rc-2 and rc-2, but we forgot to add the a comment to the migration guide for this.

In the future we'll make sure the db can easily be migrated between releases, probably with migration scripts.

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 6 October, 2014 10:43:30 AM
> Subject: [keycloak-dev] database migration
> 
> hello there.
> 
> I have one question, looks like between 1.0-rc-1 and 1.0-final there were
> some changes on the underlying database model:
> http://lists.jboss.org/pipermail/aerogear-dev/2014-October/009202.html
> 
> I guess this is fine, since it was before the -final, but wanted to double
> check if you guys have any database migration scripts.
> 
> Thanks,
> Matthias
> 
> --
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From corinnekrych at gmail.com  Mon Oct  6 05:09:11 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 6 Oct 2014 11:09:11 +0200
Subject: [keycloak-dev] Native mobile OAuth2 keycloak flows
Message-ID: <D20B149E-9318-4813-8680-75D16F599621@gmail.com>

Hello Keycloak team,

On native app, our aerogear-oauth2 sdk supports the following flows:
- oauth2 authz code (publicl client) bearer-only using external browser. See Shoot demo.
- oauth2 refresh grant
- oauth2 revoke (using logout endpoint to revoke all refresh/access tokens).

We have a iOS demo [1] and its associated backend [2] which shows how to use authz code grant on Google, Facebook and Keycloak using aerogear oauth2 sdk [3]. For Android we have same level features [4] (just missing the Shoot demo).

To come in next release: 
- openID flow based on authz code (need an extra token decoding to get ID information) with a ui button ?login with your keyclakbackend account?. Thanks to Stian I managed the base64url decoding...
- direct grant (resource owner grant). 
- basic auth support for confidential mode

I?m thinking to do a Keyclaok (only) HelloWorld demo which show all different use cases.

Therefore the question: What other use cases do I miss? Feedback welcome.

++
Corinne
AeroGear iOS
???????????
[1] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/Shoot
[2] https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/Shoot/README.md
[3] https://github.com/aerogear/aerogear-ios-oauth2
[4] https://github.com/aerogear/aerogear-android-authz

From stian at redhat.com  Mon Oct  6 07:16:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 07:16:49 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5431B24A.9030002@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542E7AD8.4010408@redhat.com> <542EC072.9030105@redhat.com>
	<5431B24A.9030002@redhat.com>
Message-ID: <447013723.61846691.1412594209607.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Sunday, 5 October, 2014 11:04:10 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> On 3.10.2014 17:27, Bill Burke wrote:
> >
> > On 10/3/2014 6:30 AM, Marek Posolda wrote:
> >> On 3.10.2014 08:38, Stian Thorgersen wrote:
> >>> Let's take a step-back here and consider the problem instead of a
> >>> potential solution.
> >>>
> >>> Currently we require all applications to have an HTTP session to keep
> >>> track of the users session as well as storing the tokens. When an
> >>> application is clustered this requires replicating the HTTP session to
> >>> all nodes, or using sticky load balancer sessions.
> >>>
> >>> I think it's quite likely that some don't want to have a HTTP session and
> >>> instead store the token in a cookie to make the application fully
> >>> stateless. That's simple enough to add right? And storing the token in a
> >>> http-only cookie should be safe as well. However, one issue remains how
> >>> do we deal with single-sign out in this case. As there's no state kept
> >>> in the application a logout admin event from Keycloak isn't going to
> >>> work. So would be just rely on the access token expiring in this case?
> >>> Or could we add something better?
> >> One possibility I can think about is, that adapters would have some
> >> option to specify if they are:
> >> - statefull (In this case HttpSession is used as is now)
> >> - stateless (In this case token stored in the cookie like
> >> KEYCLOAK_PRINCIPAL)
> >>
> > Stateless browser apps could also just be configured to override token
> > timeouts.  Either:
> >
> > a) Refresh the access token on every request
> > b) Do a shorter token timeout.
> >
> Ok, (b) is already possible. For (a) we can add option to adapters?

Instead of (a) would it not be better to add an endpoint to Keycloak that allows verifying a token? Then add an option to an adapter to do optionally do this every request? If I remember correctly this endpoint may already exist.

> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Oct  6 07:23:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 07:23:20 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5431B130.3080905@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
Message-ID: <349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Sunday, 5 October, 2014 10:59:28 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> On 3.10.2014 17:17, Bill Burke wrote:
> >
> > On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
> >> Let's take a step-back here and consider the problem instead of a
> >> potential solution.
> >>
> >> Currently we require all applications to have an HTTP session to keep
> >> track of the users session as well as storing the tokens. When an
> >> application is clustered this requires replicating the HTTP session to
> >> all nodes, or using sticky load balancer sessions.
> >>
> >> I think it's quite likely that some don't want to have a HTTP session and
> >> instead store the token in a cookie to make the application fully
> >> stateless. That's simple enough to add right? And storing the token in a
> >> http-only cookie should be safe as well. However, one issue remains how
> >> do we deal with single-sign out in this case. As there's no state kept in
> >> the application a logout admin event from Keycloak isn't going to work.
> >> So would be just rely on the access token expiring in this case? Or could
> >> we add something better?
> >>
> > You don't have to change anything for bearer-only apps.  Blacklist and
> > time-based revocation policies are enough.
> >
> > For browser apps, the problem is logout.  Cookie won't work for logout.
> >    While you could logout one user via a browser redirect protocol,
> > doesn't work when an admin wants to initiate a logout to one or all
> > users from the admin console.  This is because a logout generates an
> > out-of-band request to each application.  The applications match the
> > UserSessionModel id with an HTTP Session and invalidate the session.  So
> > the adapter needs a UserSessionModel->HttpSession id map.
> >
> > Maybe the access code to token protocol could be modified to send the
> > Http session id?  This could be stored in the client session and sent
> > with the out-of-band logout request.
> >
> >
> I think that this will be good . Perhaps HttpSession ID could be stored
> on ClientSessionModel as note, so no changes on UserSession model required?

Would have to be ClientSession (user session doesn't work as one user session can be linked to multiple application http sessions), so yes

> 
> Related issue is that our UserSessionManagement implementations (for
> both undertow and AS7) are stateful. Is it issue to refactor them to be
> stateless? With HttpSession passed around from KC it will be possible imo.
> 
> Stateful impls have issues like:
> - State in UndertowUserSessionManagement and CatalinaUserManagement is
> stored in ConcurrentHashMaps and hence is not cluster-aware . This is
> causing issues especially with logout (for example login happens on
> node1, but admin out-of-bound request is handled on node2 -> it won't be
> able to find session in it's maps -> logout won't happen as user is
> still logged on node1)
> - Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734
> 
> I experimented on Friday and did prototype of UserSessionManagement
> impls backed by infinispan (this can address both cluster and memory
> leak), but tbh I am not so happy with it. IMO stateless
> UserSessionManagement is a way to go. What I can see for particular
> UserSessionManagement operations:
> - logoutKeycloakSession will be easy to handle as long as logout req
> from KC will send HttpSessionID. So we don't need any state with mapping
> from kcSessions to HttpSessions.
> - logoutUser --- Instead of sending username, Keycloak can send list of
> all HttpSessions of user for this app. Those all will be invalidated
> - logoutAll --- Both undertow Manager and org.apache.catalina.Manager
> has possibility to list all HttpSessions and invalidate them (This will
> invalidate also anonymous HttpSessions, but is this an issue?)

Stateless UserSessionManagement sounds good to me. A few questions though:

 a) How does the app pass the http session id to Keycloak? 
 b) Is there anything in OpenID Connect for this already?
 c) How does it affect SAML?
 d) How does it affect applications that don't use Keycloak adapters

> 
> Other methods for UserSessionManagement are for handle statistics, but
> do we really need them? Endpoint for
> PreAuthActionsHandler.handleGetUserStats() is not called from any place
> in Keycloak admin console. KC admin console is just using UserSession
> API directly. Is it an issue to remove
> PreAuthActionsHandler.handleGetUserStats() and all related methods from
> UserSessionManagement?

I believe we can remove these, they're from before we had user/client sessions.

> 
> Marek
> 
> 

From stian at redhat.com  Mon Oct  6 07:32:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 07:32:53 -0400 (EDT)
Subject: [keycloak-dev] Database migration
In-Reply-To: <872927193.61850130.1412594710988.JavaMail.zimbra@redhat.com>
Message-ID: <2116624894.61854797.1412595173647.JavaMail.zimbra@redhat.com>

For 1.1.0.Beta1 the DB schema has changed (user and client sessions only). That means we'll have to provide a migration strategy. As part of testing a release we'll also have to start testing migrating a server.

I found a couple tools to help migrating databases (http://flywaydb.org/, http://www.liquibase.org/). It's probably worth looking at those as they let you have a single update script for all databases.

With that in mind, and the adapter clustering issues, 1.1.0.Beta1 is probably not going to be until later this week or early next week.

From mposolda at redhat.com  Mon Oct  6 08:03:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 06 Oct 2014 14:03:14 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D51E2.30500@redhat.com>
	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
Message-ID: <54328502.7060909@redhat.com>

On 6.10.2014 13:23, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Sunday, 5 October, 2014 10:59:28 PM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>> On 3.10.2014 17:17, Bill Burke wrote:
>>> On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
>>>> Let's take a step-back here and consider the problem instead of a
>>>> potential solution.
>>>>
>>>> Currently we require all applications to have an HTTP session to keep
>>>> track of the users session as well as storing the tokens. When an
>>>> application is clustered this requires replicating the HTTP session to
>>>> all nodes, or using sticky load balancer sessions.
>>>>
>>>> I think it's quite likely that some don't want to have a HTTP session and
>>>> instead store the token in a cookie to make the application fully
>>>> stateless. That's simple enough to add right? And storing the token in a
>>>> http-only cookie should be safe as well. However, one issue remains how
>>>> do we deal with single-sign out in this case. As there's no state kept in
>>>> the application a logout admin event from Keycloak isn't going to work.
>>>> So would be just rely on the access token expiring in this case? Or could
>>>> we add something better?
>>>>
>>> You don't have to change anything for bearer-only apps.  Blacklist and
>>> time-based revocation policies are enough.
>>>
>>> For browser apps, the problem is logout.  Cookie won't work for logout.
>>>     While you could logout one user via a browser redirect protocol,
>>> doesn't work when an admin wants to initiate a logout to one or all
>>> users from the admin console.  This is because a logout generates an
>>> out-of-band request to each application.  The applications match the
>>> UserSessionModel id with an HTTP Session and invalidate the session.  So
>>> the adapter needs a UserSessionModel->HttpSession id map.
>>>
>>> Maybe the access code to token protocol could be modified to send the
>>> Http session id?  This could be stored in the client session and sent
>>> with the out-of-band logout request.
>>>
>>>
>> I think that this will be good . Perhaps HttpSession ID could be stored
>> on ClientSessionModel as note, so no changes on UserSession model required?
> Would have to be ClientSession (user session doesn't work as one user session can be linked to multiple application http sessions), so yes
>
>> Related issue is that our UserSessionManagement implementations (for
>> both undertow and AS7) are stateful. Is it issue to refactor them to be
>> stateless? With HttpSession passed around from KC it will be possible imo.
>>
>> Stateful impls have issues like:
>> - State in UndertowUserSessionManagement and CatalinaUserManagement is
>> stored in ConcurrentHashMaps and hence is not cluster-aware . This is
>> causing issues especially with logout (for example login happens on
>> node1, but admin out-of-bound request is handled on node2 -> it won't be
>> able to find session in it's maps -> logout won't happen as user is
>> still logged on node1)
>> - Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734
>>
>> I experimented on Friday and did prototype of UserSessionManagement
>> impls backed by infinispan (this can address both cluster and memory
>> leak), but tbh I am not so happy with it. IMO stateless
>> UserSessionManagement is a way to go. What I can see for particular
>> UserSessionManagement operations:
>> - logoutKeycloakSession will be easy to handle as long as logout req
>> from KC will send HttpSessionID. So we don't need any state with mapping
>> from kcSessions to HttpSessions.
>> - logoutUser --- Instead of sending username, Keycloak can send list of
>> all HttpSessions of user for this app. Those all will be invalidated
>> - logoutAll --- Both undertow Manager and org.apache.catalina.Manager
>> has possibility to list all HttpSessions and invalidate them (This will
>> invalidate also anonymous HttpSessions, but is this an issue?)
> Stateless UserSessionManagement sounds good to me. A few questions though:
>
>   a) How does the app pass the http session id to Keycloak?
Bill suggested to pass it in codeToToken request and that's what I am 
doing now in my prototype (I have it working on Wildfly/Undertow already).

I wonder that another option might be to pass it directly in "state" 
parameter? This would mean that there is no need to have another cookie 
OAuth_Token_Request_State, which we now have and also no changes 
required to protocol. The disadvantage is that it would require creating 
HttpSession even before user is redirected to Keycloak login screen.
>   b) Is there anything in OpenID Connect for this already?
No idea. I will try to check...
>   c) How does it affect SAML?
>   d) How does it affect applications that don't use Keycloak adapters
UserSessionManagement is used just by Wildfly, AS7/EAP6 and Tomcat 
adapters. Other applications are not affected at all.

For the future, I hope that frameworks like PHP, Ruby on rails, node.js 
have concept of HttpSession. So as long as we can pass their "sessionId" 
and they're able to lookup session by sessionId and logout it, we should 
be good.

In general, I think that passing application "sessionId" instead of 
keycloakSessionID to adapters is always better as in case that we pass 
keycloakSessionID, adapter need to maintain some state for mapping of 
kcSessions to httpSessions as is now.
>
>> Other methods for UserSessionManagement are for handle statistics, but
>> do we really need them? Endpoint for
>> PreAuthActionsHandler.handleGetUserStats() is not called from any place
>> in Keycloak admin console. KC admin console is just using UserSession
>> API directly. Is it an issue to remove
>> PreAuthActionsHandler.handleGetUserStats() and all related methods from
>> UserSessionManagement?
> I believe we can remove these, they're from before we had user/client sessions.
Great!

If we still want to keep them, it's possible. It's not an issue to keep 
getActiveSessions() (It can just count number of httpSessions). For 
tracking all other stats, which are available now, we would need to 
iterate over httpSessions and read the data from them. So it would be 
performance killer, but it's doable;-)

For now, I am counting with the possibility to remove them.

Marek
>
>> Marek
>>
>>


From stian at redhat.com  Mon Oct  6 08:12:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 08:12:54 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <54328502.7060909@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
Message-ID: <235231688.61888334.1412597574838.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: Monday, 6 October, 2014 2:03:14 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> On 6.10.2014 13:23, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
> >> <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Sunday, 5 October, 2014 10:59:28 PM
> >> Subject: Re: [keycloak-dev] Session SPI for adapters
> >>
> >> On 3.10.2014 17:17, Bill Burke wrote:
> >>> On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
> >>>> Let's take a step-back here and consider the problem instead of a
> >>>> potential solution.
> >>>>
> >>>> Currently we require all applications to have an HTTP session to keep
> >>>> track of the users session as well as storing the tokens. When an
> >>>> application is clustered this requires replicating the HTTP session to
> >>>> all nodes, or using sticky load balancer sessions.
> >>>>
> >>>> I think it's quite likely that some don't want to have a HTTP session
> >>>> and
> >>>> instead store the token in a cookie to make the application fully
> >>>> stateless. That's simple enough to add right? And storing the token in a
> >>>> http-only cookie should be safe as well. However, one issue remains how
> >>>> do we deal with single-sign out in this case. As there's no state kept
> >>>> in
> >>>> the application a logout admin event from Keycloak isn't going to work.
> >>>> So would be just rely on the access token expiring in this case? Or
> >>>> could
> >>>> we add something better?
> >>>>
> >>> You don't have to change anything for bearer-only apps.  Blacklist and
> >>> time-based revocation policies are enough.
> >>>
> >>> For browser apps, the problem is logout.  Cookie won't work for logout.
> >>>     While you could logout one user via a browser redirect protocol,
> >>> doesn't work when an admin wants to initiate a logout to one or all
> >>> users from the admin console.  This is because a logout generates an
> >>> out-of-band request to each application.  The applications match the
> >>> UserSessionModel id with an HTTP Session and invalidate the session.  So
> >>> the adapter needs a UserSessionModel->HttpSession id map.
> >>>
> >>> Maybe the access code to token protocol could be modified to send the
> >>> Http session id?  This could be stored in the client session and sent
> >>> with the out-of-band logout request.
> >>>
> >>>
> >> I think that this will be good . Perhaps HttpSession ID could be stored
> >> on ClientSessionModel as note, so no changes on UserSession model
> >> required?
> > Would have to be ClientSession (user session doesn't work as one user
> > session can be linked to multiple application http sessions), so yes
> >
> >> Related issue is that our UserSessionManagement implementations (for
> >> both undertow and AS7) are stateful. Is it issue to refactor them to be
> >> stateless? With HttpSession passed around from KC it will be possible imo.
> >>
> >> Stateful impls have issues like:
> >> - State in UndertowUserSessionManagement and CatalinaUserManagement is
> >> stored in ConcurrentHashMaps and hence is not cluster-aware . This is
> >> causing issues especially with logout (for example login happens on
> >> node1, but admin out-of-bound request is handled on node2 -> it won't be
> >> able to find session in it's maps -> logout won't happen as user is
> >> still logged on node1)
> >> - Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734
> >>
> >> I experimented on Friday and did prototype of UserSessionManagement
> >> impls backed by infinispan (this can address both cluster and memory
> >> leak), but tbh I am not so happy with it. IMO stateless
> >> UserSessionManagement is a way to go. What I can see for particular
> >> UserSessionManagement operations:
> >> - logoutKeycloakSession will be easy to handle as long as logout req
> >> from KC will send HttpSessionID. So we don't need any state with mapping
> >> from kcSessions to HttpSessions.
> >> - logoutUser --- Instead of sending username, Keycloak can send list of
> >> all HttpSessions of user for this app. Those all will be invalidated
> >> - logoutAll --- Both undertow Manager and org.apache.catalina.Manager
> >> has possibility to list all HttpSessions and invalidate them (This will
> >> invalidate also anonymous HttpSessions, but is this an issue?)
> > Stateless UserSessionManagement sounds good to me. A few questions though:
> >
> >   a) How does the app pass the http session id to Keycloak?
> Bill suggested to pass it in codeToToken request and that's what I am
> doing now in my prototype (I have it working on Wildfly/Undertow already).
> 
> I wonder that another option might be to pass it directly in "state"
> parameter? This would mean that there is no need to have another cookie
> OAuth_Token_Request_State, which we now have and also no changes
> required to protocol. The disadvantage is that it would require creating
> HttpSession even before user is redirected to Keycloak login screen.

Sounds hacky to me. Better to have a separate (optional) param in codeToToken IMO.

> >   b) Is there anything in OpenID Connect for this already?
> No idea. I will try to check...
> >   c) How does it affect SAML?
> >   d) How does it affect applications that don't use Keycloak adapters
> UserSessionManagement is used just by Wildfly, AS7/EAP6 and Tomcat
> adapters. Other applications are not affected at all.
> 
> For the future, I hope that frameworks like PHP, Ruby on rails, node.js
> have concept of HttpSession. So as long as we can pass their "sessionId"
> and they're able to lookup session by sessionId and logout it, we should
> be good.
> 
> In general, I think that passing application "sessionId" instead of
> keycloakSessionID to adapters is always better as in case that we pass
> keycloakSessionID, adapter need to maintain some state for mapping of
> kcSessions to httpSessions as is now.

What I mean is that this is a Keycloak proprietary feature and we need to make sure it doesn't affect applications that don't use Keycloak adapters, but instead use a standard OpenID Connect (or SAML?) adapter. 

> >
> >> Other methods for UserSessionManagement are for handle statistics, but
> >> do we really need them? Endpoint for
> >> PreAuthActionsHandler.handleGetUserStats() is not called from any place
> >> in Keycloak admin console. KC admin console is just using UserSession
> >> API directly. Is it an issue to remove
> >> PreAuthActionsHandler.handleGetUserStats() and all related methods from
> >> UserSessionManagement?
> > I believe we can remove these, they're from before we had user/client
> > sessions.
> Great!
> 
> If we still want to keep them, it's possible. It's not an issue to keep
> getActiveSessions() (It can just count number of httpSessions). For
> tracking all other stats, which are available now, we would need to
> iterate over httpSessions and read the data from them. So it would be
> performance killer, but it's doable;-)
> 
> For now, I am counting with the possibility to remove them.

My vote is to get rid of it, but check with Bill first

> 
> Marek
> >
> >> Marek
> >>
> >>
> 
> 

From bburke at redhat.com  Mon Oct  6 09:17:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 06 Oct 2014 09:17:40 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5431B130.3080905@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
Message-ID: <54329674.3040701@redhat.com>



On 10/5/2014 4:59 PM, Marek Posolda wrote:
> On 3.10.2014 17:17, Bill Burke wrote:
>>
>> On 10/3/2014 2:38 AM, Stian Thorgersen wrote:
>>> Let's take a step-back here and consider the problem instead of a
>>> potential solution.
>>>
>>> Currently we require all applications to have an HTTP session to keep
>>> track of the users session as well as storing the tokens. When an
>>> application is clustered this requires replicating the HTTP session
>>> to all nodes, or using sticky load balancer sessions.
>>>
>>> I think it's quite likely that some don't want to have a HTTP session
>>> and instead store the token in a cookie to make the application fully
>>> stateless. That's simple enough to add right? And storing the token
>>> in a http-only cookie should be safe as well. However, one issue
>>> remains how do we deal with single-sign out in this case. As there's
>>> no state kept in the application a logout admin event from Keycloak
>>> isn't going to work. So would be just rely on the access token
>>> expiring in this case? Or could we add something better?
>>>
>> You don't have to change anything for bearer-only apps.  Blacklist and
>> time-based revocation policies are enough.
>>
>> For browser apps, the problem is logout.  Cookie won't work for logout.
>>    While you could logout one user via a browser redirect protocol,
>> doesn't work when an admin wants to initiate a logout to one or all
>> users from the admin console.  This is because a logout generates an
>> out-of-band request to each application.  The applications match the
>> UserSessionModel id with an HTTP Session and invalidate the session.  So
>> the adapter needs a UserSessionModel->HttpSession id map.
>>
>> Maybe the access code to token protocol could be modified to send the
>> Http session id?  This could be stored in the client session and sent
>> with the out-of-band logout request.
>>
>>
> I think that this will be good . Perhaps HttpSession ID could be stored
> on ClientSessionModel as note, so no changes on UserSession model required?
>
> Related issue is that our UserSessionManagement implementations (for
> both undertow and AS7) are stateful. Is it issue to refactor them to be
> stateless? With HttpSession passed around from KC it will be possible imo.
>
> Stateful impls have issues like:
> - State in UndertowUserSessionManagement and CatalinaUserManagement is
> stored in ConcurrentHashMaps and hence is not cluster-aware . This is
> causing issues especially with logout (for example login happens on
> node1, but admin out-of-bound request is handled on node2 -> it won't be
> able to find session in it's maps -> logout won't happen as user is
> still logged on node1)
> - Memory leaks https://issues.jboss.org/browse/KEYCLOAK-734
>
> I experimented on Friday and did prototype of UserSessionManagement
> impls backed by infinispan (this can address both cluster and memory
> leak), but tbh I am not so happy with it. IMO stateless
> UserSessionManagement is a way to go. What I can see for particular
> UserSessionManagement operations:
> - logoutKeycloakSession will be easy to handle as long as logout req
> from KC will send HttpSessionID. So we don't need any state with mapping
> from kcSessions to HttpSessions.
> - logoutUser --- Instead of sending username, Keycloak can send list of
> all HttpSessions of user for this app. Those all will be invalidated
> - logoutAll --- Both undertow Manager and org.apache.catalina.Manager
> has possibility to list all HttpSessions and invalidate them (This will
> invalidate also anonymous HttpSessions, but is this an issue?)
>
> Other methods for UserSessionManagement are for handle statistics, but
> do we really need them? Endpoint for
> PreAuthActionsHandler.handleGetUserStats() is not called from any place
> in Keycloak admin console. KC admin console is just using UserSession
> API directly. Is it an issue to remove
> PreAuthActionsHandler.handleGetUserStats() and all related methods from
> UserSessionManagement?
>

We can probably get rid of the stats.  These stat methods all existed 
prior to ClientSessionModel.


So, piggyback the http session id on access code to token and store in 
ClientSession?  Session id hopefully is usable cross-cluster in 
replicated http sessions.


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

From stian at redhat.com  Mon Oct  6 09:18:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 09:18:52 -0400 (EDT)
Subject: [keycloak-dev] Native mobile OAuth2 keycloak flows
In-Reply-To: <D20B149E-9318-4813-8680-75D16F599621@gmail.com>
References: <D20B149E-9318-4813-8680-75D16F599621@gmail.com>
Message-ID: <1209233549.61963314.1412601532826.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "keycloak-user at lists.jboss.org" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 6 October, 2014 11:09:11 AM
> Subject: [keycloak-dev] Native mobile OAuth2 keycloak flows
> 
> Hello Keycloak team,
> 
> On native app, our aerogear-oauth2 sdk supports the following flows:
> - oauth2 authz code (publicl client) bearer-only using external browser. See
> Shoot demo.
> - oauth2 refresh grant
> - oauth2 revoke (using logout endpoint to revoke all refresh/access tokens).
> 
> We have a iOS demo [1] and its associated backend [2] which shows how to use
> authz code grant on Google, Facebook and Keycloak using aerogear oauth2 sdk
> [3]. For Android we have same level features [4] (just missing the Shoot
> demo).
> 
> To come in next release:
> - openID flow based on authz code (need an extra token decoding to get ID
> information) with a ui button ?login with your keyclakbackend account?.
> Thanks to Stian I managed the base64url decoding...
> - direct grant (resource owner grant).
> - basic auth support for confidential mode
> 
> I?m thinking to do a Keyclaok (only) HelloWorld demo which show all different
> use cases.
> 
> Therefore the question: What other use cases do I miss? Feedback welcome.

A few things I can think of:

* SSO - on Android you can add shared accounts (SSO to multiple apps), is something like this available on iOS
* Social login through Keycloak - does this currently work? Again, does iOS have the concept of shared accounts for social networks, how can we utilize these?
* Roles - Keycloak tokens contains permitted roles. Some applications may wish to show/hide features depending on permissions.

> 
> ++
> Corinne
> AeroGear iOS
> ???????????
> [1] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/Shoot
> [2]
> https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/Shoot/README.md
> [3] https://github.com/aerogear/aerogear-ios-oauth2
> [4] https://github.com/aerogear/aerogear-android-authz
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From bburke at redhat.com  Mon Oct  6 09:26:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 06 Oct 2014 09:26:36 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
Message-ID: <5432988C.5030803@redhat.com>



A few more things:

Stian made a good point that any extensions we do have to be compatible 
with non keycloak pure oidc adapters.  The thing is though, OIDC doesn't 
have a logout request like SAML does.  I'll ping pedro to see if session 
information can be extracted from a logout request.

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

From alarik at zwift.com  Mon Oct  6 09:27:18 2014
From: alarik at zwift.com (Alarik Myrin)
Date: Mon, 6 Oct 2014 09:27:18 -0400
Subject: [keycloak-dev] Database migration
Message-ID: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>

I have been using flywaydb for a few months now, and I like it a lot...

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

From stian at redhat.com  Mon Oct  6 09:42:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 09:42:12 -0400 (EDT)
Subject: [keycloak-dev] Database migration
In-Reply-To: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>
References: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>
Message-ID: <1137430629.61980886.1412602932805.JavaMail.zimbra@redhat.com>

Nice to know, thanks

BTW had a look at your website, really cool. Sadly my trainer is not smart enough!

Do you guys use Keycloak for Zwift?

----- Original Message -----
> From: "Alarik Myrin" <alarik at zwift.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 6 October, 2014 3:27:18 PM
> Subject: Re: [keycloak-dev] Database migration
> 
> I have been using flywaydb for a few months now, and I like it a lot...
> 
> Alarik
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Mon Oct  6 09:58:00 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 06 Oct 2014 15:58:00 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5432988C.5030803@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com>
Message-ID: <54329FE8.6070906@redhat.com>

On 6.10.2014 15:26, Bill Burke wrote:
>
>
> A few more things:
>
> Stian made a good point that any extensions we do have to be 
> compatible with non keycloak pure oidc adapters.  The thing is though, 
> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to 
> see if session information can be extracted from a logout request.
>
AFAIR SAML single-sign out is based on chain of browser redirections to 
all apps where you are logged. No "out-of-bound" requests . At least 
that's how picketlink is doing afaik (not 100% sure and not sure about 
SAML specs). So in this case logout request is browser-based and have 
access to JSESSIONID cookie. Hence there is no need to maintain 
sessionId in keycloak or any state on adapters as well. I am not 100% 
sure (will try to doublecheck..)

Marek

From corinnekrych at gmail.com  Mon Oct  6 09:59:55 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 6 Oct 2014 15:59:55 +0200
Subject: [keycloak-dev] Native mobile OAuth2 keycloak flows
In-Reply-To: <1209233549.61963314.1412601532826.JavaMail.zimbra@redhat.com>
References: <D20B149E-9318-4813-8680-75D16F599621@gmail.com>
	<1209233549.61963314.1412601532826.JavaMail.zimbra@redhat.com>
Message-ID: <2181340D-073F-47F8-85C3-0F417F81AAAA@gmail.com>


On 06 Oct 2014, at 15:18, Stian Thorgersen <stian at redhat.com> wrote:

> 
> 
> ----- Original Message -----
>> From: "Corinne Krych" <corinnekrych at gmail.com>
>> To: "keycloak-user at lists.jboss.org" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 6 October, 2014 11:09:11 AM
>> Subject: [keycloak-dev] Native mobile OAuth2 keycloak flows
>> 
>> Hello Keycloak team,
>> 
>> On native app, our aerogear-oauth2 sdk supports the following flows:
>> - oauth2 authz code (publicl client) bearer-only using external browser. See
>> Shoot demo.
>> - oauth2 refresh grant
>> - oauth2 revoke (using logout endpoint to revoke all refresh/access tokens).
>> 
>> We have a iOS demo [1] and its associated backend [2] which shows how to use
>> authz code grant on Google, Facebook and Keycloak using aerogear oauth2 sdk
>> [3]. For Android we have same level features [4] (just missing the Shoot
>> demo).
>> 
>> To come in next release:
>> - openID flow based on authz code (need an extra token decoding to get ID
>> information) with a ui button ?login with your keyclakbackend account?.
>> Thanks to Stian I managed the base64url decoding...
>> - direct grant (resource owner grant).
>> - basic auth support for confidential mode
>> 
>> I?m thinking to do a Keyclaok (only) HelloWorld demo which show all different
>> use cases.
>> 
>> Therefore the question: What other use cases do I miss? Feedback welcome.
> 
> A few things I can think of:
> 
> * SSO - on Android you can add shared accounts (SSO to multiple apps), is something like this available on iOS
> * Social login through Keycloak - does this currently work? Again, does iOS have the concept of shared accounts for social networks, how can we utilize these?

iOS have shared social networks embedded in the OS directly but it?s not opened. It?s a place where your put your credentials.
But iOS8 Social.framework is limited to set of providers (Facebook, twitter)
see my blog post on the subject:
http://corinnekrych.blogspot.fr/2014/06/different-ways-to-manage-facebook.html

One way to go for SSO will be to store oauth2 token in keychain (as we currently do) and use sharing data between keychain. I?ll dig that one. Let?s track with:
https://issues.jboss.org/browse/AGIOS-285 


> * Roles - Keycloak tokens contains permitted roles. Some applications may wish to show/hide features depending on permissions.
> 

Let me add a ticket for that to enhance Shoot demo.
https://issues.jboss.org/browse/AGIOS-286

Thanks Stian!

>> 
>> ++
>> Corinne
>> AeroGear iOS
>> ???????????
>> [1] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/Shoot
>> [2]
>> https://github.com/corinnekrych/aerogear-backend-cookbook/blob/master/Shoot/README.md
>> [3] https://github.com/aerogear/aerogear-ios-oauth2
>> [4] https://github.com/aerogear/aerogear-android-authz
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mposolda at redhat.com  Mon Oct  6 10:02:09 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 06 Oct 2014 16:02:09 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <54329674.3040701@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D4CC1.3010908@redhat.com>	<271288273.60399588.1412255549293.JavaMail.zimbra@redhat.com>	<542D51E2.30500@redhat.com>	<1220564959.60422376.1412257423758.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<54329674.3040701@redhat.com>
Message-ID: <5432A0E1.6010505@redhat.com>

On 6.10.2014 15:17, Bill Burke wrote:
>
> We can probably get rid of the stats.  These stat methods all existed 
> prior to ClientSessionModel.
Thanks, will do it.
>
>
> So, piggyback the http session id on access code to token and store in 
> ClientSession?  Session id hopefully is usable cross-cluster in 
> replicated http sessions. 
yep, it is. I already prototyped this approach and works well.

Marek


From mposolda at redhat.com  Mon Oct  6 10:10:57 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 06 Oct 2014 16:10:57 +0200
Subject: [keycloak-dev] Database migration
In-Reply-To: <2116624894.61854797.1412595173647.JavaMail.zimbra@redhat.com>
References: <2116624894.61854797.1412595173647.JavaMail.zimbra@redhat.com>
Message-ID: <5432A2F1.1070603@redhat.com>

At some point we wanted to use export/import for that?
Like:
- export whole DB content to json file with KC 1.0.Final
- Transform JSON content from 1.0.Final format to "1.1.0.Beta1" format 
(would likely need to be detyped due to possible changes in 
*Representation objects)
- Import JSON back to DB

It required re-creating DB from scratch, but on the other hand it's very 
generic and independent on model (not tightly coupled to SQL/JPA).

Marek

On 6.10.2014 13:32, Stian Thorgersen wrote:
> For 1.1.0.Beta1 the DB schema has changed (user and client sessions only). That means we'll have to provide a migration strategy. As part of testing a release we'll also have to start testing migrating a server.
>
> I found a couple tools to help migrating databases (http://flywaydb.org/, http://www.liquibase.org/). It's probably worth looking at those as they let you have a single update script for all databases.
>
> With that in mind, and the adapter clustering issues, 1.1.0.Beta1 is probably not going to be until later this week or early next week.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon Oct  6 10:28:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 06 Oct 2014 10:28:53 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <54329FE8.6070906@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<542D6A1D.1030705@redhat.com>
	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>
	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>
	<542EBE1E.5040905@redhat.com> <5431B130.3080905@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com> <54329FE8.6070906@redhat.com>
Message-ID: <5432A725.2050509@redhat.com>



On 10/6/2014 9:58 AM, Marek Posolda wrote:
> On 6.10.2014 15:26, Bill Burke wrote:
>>
>>
>> A few more things:
>>
>> Stian made a good point that any extensions we do have to be
>> compatible with non keycloak pure oidc adapters.  The thing is though,
>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
>> see if session information can be extracted from a logout request.
>>
> AFAIR SAML single-sign out is based on chain of browser redirections to
> all apps where you are logged. No "out-of-bound" requests . At least
> that's how picketlink is doing afaik (not 100% sure and not sure about
> SAML specs). So in this case logout request is browser-based and have
> access to JSESSIONID cookie. Hence there is no need to maintain
> sessionId in keycloak or any state on adapters as well. I am not 100%
> sure (will try to doublecheck..)
>

SAML has out-of-band logout requests too.  At least thats what I think 
Pedro told me.

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

From stian at redhat.com  Mon Oct  6 10:55:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 6 Oct 2014 10:55:26 -0400 (EDT)
Subject: [keycloak-dev] Database migration
In-Reply-To: <5432A2F1.1070603@redhat.com>
References: <2116624894.61854797.1412595173647.JavaMail.zimbra@redhat.com>
	<5432A2F1.1070603@redhat.com>
Message-ID: <1740873267.62124546.1412607326874.JavaMail.zimbra@redhat.com>

Yep, but then someone came along and talked about millions of users ;)

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 6 October, 2014 4:10:57 PM
> Subject: Re: [keycloak-dev] Database migration
> 
> At some point we wanted to use export/import for that?
> Like:
> - export whole DB content to json file with KC 1.0.Final
> - Transform JSON content from 1.0.Final format to "1.1.0.Beta1" format
> (would likely need to be detyped due to possible changes in
> *Representation objects)
> - Import JSON back to DB
> 
> It required re-creating DB from scratch, but on the other hand it's very
> generic and independent on model (not tightly coupled to SQL/JPA).
> 
> Marek
> 
> On 6.10.2014 13:32, Stian Thorgersen wrote:
> > For 1.1.0.Beta1 the DB schema has changed (user and client sessions only).
> > That means we'll have to provide a migration strategy. As part of testing
> > a release we'll also have to start testing migrating a server.
> >
> > I found a couple tools to help migrating databases (http://flywaydb.org/,
> > http://www.liquibase.org/). It's probably worth looking at those as they
> > let you have a single update script for all databases.
> >
> > With that in mind, and the adapter clustering issues, 1.1.0.Beta1 is
> > probably not going to be until later this week or early next week.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Mon Oct  6 14:38:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 06 Oct 2014 14:38:01 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5432A725.2050509@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<542D6A1D.1030705@redhat.com>	<256105327.60878442.1412317640961.JavaMail.zimbra@redhat.com>	<937493370.60881244.1412318330498.JavaMail.zimbra@redhat.com>	<542EBE1E.5040905@redhat.com>
	<5431B130.3080905@redhat.com>	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>	<54328502.7060909@redhat.com>	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>	<5432988C.5030803@redhat.com>
	<54329FE8.6070906@redhat.com> <5432A725.2050509@redhat.com>
Message-ID: <5432E189.5040506@redhat.com>



On 10/6/2014 10:28 AM, Bill Burke wrote:
>
>
> On 10/6/2014 9:58 AM, Marek Posolda wrote:
>> On 6.10.2014 15:26, Bill Burke wrote:
>>>
>>>
>>> A few more things:
>>>
>>> Stian made a good point that any extensions we do have to be
>>> compatible with non keycloak pure oidc adapters.  The thing is though,
>>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
>>> see if session information can be extracted from a logout request.
>>>
>> AFAIR SAML single-sign out is based on chain of browser redirections to
>> all apps where you are logged. No "out-of-bound" requests . At least
>> that's how picketlink is doing afaik (not 100% sure and not sure about
>> SAML specs). So in this case logout request is browser-based and have
>> access to JSESSIONID cookie. Hence there is no need to maintain
>> sessionId in keycloak or any state on adapters as well. I am not 100%
>> sure (will try to doublecheck..)
>>
>
> SAML has out-of-band logout requests too.  At least thats what I think
> Pedro told me.
>

For Picketlink SAML SPs, you either do a browse redirect protocol to 
each SP for Single Log out, or you do an out of band logout request to 
the SP.  PL SAML SP adapter currently has the same problem as us in a 
cluster.  They keep an in-memory map between username and http session.

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

From daniel at passos.me  Mon Oct  6 18:31:40 2014
From: daniel at passos.me (Daniel Passos)
Date: Mon, 6 Oct 2014 19:31:40 -0300
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <542D590B.1010803@redhat.com>
References: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
	<542D590B.1010803@redhat.com>
Message-ID: <CAKjsGbvzqpMT2rcmjDRxH=Kn8sAb0X-sRZ=VYsc0cOG3K0NtPw@mail.gmail.com>

I don't like refer JIRA in commit message. I prefer refer it in PR. apart
of that +1

-- Passos

On Thu, Oct 2, 2014 at 10:54 AM, Stan Silvert <ssilvert at redhat.com> wrote:

> +1
>
> On 10/2/2014 3:49 AM, Stian Thorgersen wrote:
> > A few things I'd like us to follow with regards to using JIRA:
> >
> > * Create a JIRA for all changes/fixes/improvements - unless they have no
> effect on users
> > * When completing an issue mark as resolved (not closed) - we'll close
> when we do a release (otherwise we can't change fix version without
> re-opening the issue)
> >
> > A few things for Git:
> >
> > * Try to keep it to a single commit per-JIRA
> > * Refer to JIRA issue in the commit message
> > _______________________________________________
> > 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/20141006/8f4893e8/attachment.html 

From stian at redhat.com  Tue Oct  7 02:13:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Oct 2014 02:13:43 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5432E189.5040506@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com> <54329FE8.6070906@redhat.com>
	<5432A725.2050509@redhat.com> <5432E189.5040506@redhat.com>
Message-ID: <1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 6 October, 2014 8:38:01 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> On 10/6/2014 10:28 AM, Bill Burke wrote:
> >
> >
> > On 10/6/2014 9:58 AM, Marek Posolda wrote:
> >> On 6.10.2014 15:26, Bill Burke wrote:
> >>>
> >>>
> >>> A few more things:
> >>>
> >>> Stian made a good point that any extensions we do have to be
> >>> compatible with non keycloak pure oidc adapters.  The thing is though,
> >>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
> >>> see if session information can be extracted from a logout request.
> >>>
> >> AFAIR SAML single-sign out is based on chain of browser redirections to
> >> all apps where you are logged. No "out-of-bound" requests . At least
> >> that's how picketlink is doing afaik (not 100% sure and not sure about
> >> SAML specs). So in this case logout request is browser-based and have
> >> access to JSESSIONID cookie. Hence there is no need to maintain
> >> sessionId in keycloak or any state on adapters as well. I am not 100%
> >> sure (will try to doublecheck..)
> >>
> >
> > SAML has out-of-band logout requests too.  At least thats what I think
> > Pedro told me.
> >
> 
> For Picketlink SAML SPs, you either do a browse redirect protocol to
> each SP for Single Log out, or you do an out of band logout request to
> the SP.  PL SAML SP adapter currently has the same problem as us in a
> cluster.  They keep an in-memory map between username and http session.

Would it make sense to add redirect logout as well? Then you can set in the admin console which logout mechanism you want (none, redirect or out-of-band request?)

> 
> --
> 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 Oct  7 03:38:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 07 Oct 2014 09:38:07 +0200
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>	<54328502.7060909@redhat.com>	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>	<5432988C.5030803@redhat.com>
	<54329FE8.6070906@redhat.com>	<5432A725.2050509@redhat.com>
	<5432E189.5040506@redhat.com>
	<1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
Message-ID: <5433985F.6070002@redhat.com>

On 7.10.2014 08:13, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 6 October, 2014 8:38:01 PM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> On 10/6/2014 10:28 AM, Bill Burke wrote:
>>>
>>> On 10/6/2014 9:58 AM, Marek Posolda wrote:
>>>> On 6.10.2014 15:26, Bill Burke wrote:
>>>>>
>>>>> A few more things:
>>>>>
>>>>> Stian made a good point that any extensions we do have to be
>>>>> compatible with non keycloak pure oidc adapters.  The thing is though,
>>>>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
>>>>> see if session information can be extracted from a logout request.
>>>>>
>>>> AFAIR SAML single-sign out is based on chain of browser redirections to
>>>> all apps where you are logged. No "out-of-bound" requests . At least
>>>> that's how picketlink is doing afaik (not 100% sure and not sure about
>>>> SAML specs). So in this case logout request is browser-based and have
>>>> access to JSESSIONID cookie. Hence there is no need to maintain
>>>> sessionId in keycloak or any state on adapters as well. I am not 100%
>>>> sure (will try to doublecheck..)
>>>>
>>> SAML has out-of-band logout requests too.  At least thats what I think
>>> Pedro told me.
>>>
>> For Picketlink SAML SPs, you either do a browse redirect protocol to
>> each SP for Single Log out, or you do an out of band logout request to
>> the SP.  PL SAML SP adapter currently has the same problem as us in a
>> cluster.  They keep an in-memory map between username and http session.
> Would it make sense to add redirect logout as well? Then you can set in the admin console which logout mechanism you want (none, redirect or out-of-band request?)
For me it makes sense. Regarding SAML I looked briefly that specs 
supports both redirect and out-of-band . Redirect seems to be preferred 
according to SAML-Profiles-2.0, section 4.4.3.1:

"The identity provider SHOULD then propagate any required logout 
messages to additional session participants as required using either a 
synchronous or asynchronous binding. The use of an asynchronous binding 
for the original request is preferred because it gives the identity 
provider the best chance of successfully propagating the logout to the 
other session participants during step 3."

By asynchronous binding it's meant to propagate request through browser.

It seems that supporting redirect will be good. Even if picketlink SP 
has some possible solution for out-of-band (which is not cluster-aware), 
for interoperability with other 3rd party SAML SPs redirect might be the 
only possibility.

Marek
>> --
>> 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 Oct  7 04:00:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Oct 2014 04:00:15 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5433985F.6070002@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com> <54329FE8.6070906@redhat.com>
	<5432A725.2050509@redhat.com> <5432E189.5040506@redhat.com>
	<1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
	<5433985F.6070002@redhat.com>
Message-ID: <1866433538.62809552.1412668815381.JavaMail.zimbra@redhat.com>



----- 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: Tuesday, 7 October, 2014 9:38:07 AM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> On 7.10.2014 08:13, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 6 October, 2014 8:38:01 PM
> >> Subject: Re: [keycloak-dev] Session SPI for adapters
> >>
> >>
> >>
> >> On 10/6/2014 10:28 AM, Bill Burke wrote:
> >>>
> >>> On 10/6/2014 9:58 AM, Marek Posolda wrote:
> >>>> On 6.10.2014 15:26, Bill Burke wrote:
> >>>>>
> >>>>> A few more things:
> >>>>>
> >>>>> Stian made a good point that any extensions we do have to be
> >>>>> compatible with non keycloak pure oidc adapters.  The thing is though,
> >>>>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
> >>>>> see if session information can be extracted from a logout request.
> >>>>>
> >>>> AFAIR SAML single-sign out is based on chain of browser redirections to
> >>>> all apps where you are logged. No "out-of-bound" requests . At least
> >>>> that's how picketlink is doing afaik (not 100% sure and not sure about
> >>>> SAML specs). So in this case logout request is browser-based and have
> >>>> access to JSESSIONID cookie. Hence there is no need to maintain
> >>>> sessionId in keycloak or any state on adapters as well. I am not 100%
> >>>> sure (will try to doublecheck..)
> >>>>
> >>> SAML has out-of-band logout requests too.  At least thats what I think
> >>> Pedro told me.
> >>>
> >> For Picketlink SAML SPs, you either do a browse redirect protocol to
> >> each SP for Single Log out, or you do an out of band logout request to
> >> the SP.  PL SAML SP adapter currently has the same problem as us in a
> >> cluster.  They keep an in-memory map between username and http session.
> > Would it make sense to add redirect logout as well? Then you can set in the
> > admin console which logout mechanism you want (none, redirect or
> > out-of-band request?)
> For me it makes sense. Regarding SAML I looked briefly that specs
> supports both redirect and out-of-band . Redirect seems to be preferred
> according to SAML-Profiles-2.0, section 4.4.3.1:
> 
> "The identity provider SHOULD then propagate any required logout
> messages to additional session participants as required using either a
> synchronous or asynchronous binding. The use of an asynchronous binding
> for the original request is preferred because it gives the identity
> provider the best chance of successfully propagating the logout to the
> other session participants during step 3."
> 
> By asynchronous binding it's meant to propagate request through browser.
> 
> It seems that supporting redirect will be good. Even if picketlink SP
> has some possible solution for out-of-band (which is not cluster-aware),
> for interoperability with other 3rd party SAML SPs redirect might be the
> only possibility.

I was wondering about adding an option to keycloak.js to allow storing the tokens in html5 session storage. Currently we don't store the tokens, but instead start a new client session every-time the screen is refreshed. If we added this logout redirect feature, that would make it possible to remove these tokens on logout as well.

> 
> Marek
> >> --
> >> 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  Tue Oct  7 08:38:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Oct 2014 08:38:24 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>
	<54328502.7060909@redhat.com>
	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com> <54329FE8.6070906@redhat.com>
	<5432A725.2050509@redhat.com> <5432E189.5040506@redhat.com>
	<1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
Message-ID: <5433DEC0.2090306@redhat.com>



On 10/7/2014 2:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 6 October, 2014 8:38:01 PM
>> Subject: Re: [keycloak-dev] Session SPI for adapters
>>
>>
>>
>> On 10/6/2014 10:28 AM, Bill Burke wrote:
>>>
>>>
>>> On 10/6/2014 9:58 AM, Marek Posolda wrote:
>>>> On 6.10.2014 15:26, Bill Burke wrote:
>>>>>
>>>>>
>>>>> A few more things:
>>>>>
>>>>> Stian made a good point that any extensions we do have to be
>>>>> compatible with non keycloak pure oidc adapters.  The thing is though,
>>>>> OIDC doesn't have a logout request like SAML does.  I'll ping pedro to
>>>>> see if session information can be extracted from a logout request.
>>>>>
>>>> AFAIR SAML single-sign out is based on chain of browser redirections to
>>>> all apps where you are logged. No "out-of-bound" requests . At least
>>>> that's how picketlink is doing afaik (not 100% sure and not sure about
>>>> SAML specs). So in this case logout request is browser-based and have
>>>> access to JSESSIONID cookie. Hence there is no need to maintain
>>>> sessionId in keycloak or any state on adapters as well. I am not 100%
>>>> sure (will try to doublecheck..)
>>>>
>>>
>>> SAML has out-of-band logout requests too.  At least thats what I think
>>> Pedro told me.
>>>
>>
>> For Picketlink SAML SPs, you either do a browse redirect protocol to
>> each SP for Single Log out, or you do an out of band logout request to
>> the SP.  PL SAML SP adapter currently has the same problem as us in a
>> cluster.  They keep an in-memory map between username and http session.
>
> Would it make sense to add redirect logout as well? Then you can set in the admin console which logout mechanism you want (none, redirect or out-of-band request?)
>

Yes.  I'm going to do that.  I need to add logout to the protocol SPI.



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

From ssilvert at redhat.com  Tue Oct  7 08:42:39 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 07 Oct 2014 08:42:39 -0400
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <CAKjsGbvzqpMT2rcmjDRxH=Kn8sAb0X-sRZ=VYsc0cOG3K0NtPw@mail.gmail.com>
References: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
	<542D590B.1010803@redhat.com>
	<CAKjsGbvzqpMT2rcmjDRxH=Kn8sAb0X-sRZ=VYsc0cOG3K0NtPw@mail.gmail.com>
Message-ID: <5433DFBF.2090905@redhat.com>

On 10/6/2014 6:31 PM, Daniel Passos wrote:
> I don't like refer JIRA in commit message. I prefer refer it in PR. 
> apart of that +1
Sounds reasonable to me.
>
> -- Passos
>
> On Thu, Oct 2, 2014 at 10:54 AM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     +1
>
>     On 10/2/2014 3:49 AM, Stian Thorgersen wrote:
>     > A few things I'd like us to follow with regards to using JIRA:
>     >
>     > * Create a JIRA for all changes/fixes/improvements - unless they
>     have no effect on users
>     > * When completing an issue mark as resolved (not closed) - we'll
>     close when we do a release (otherwise we can't change fix version
>     without re-opening the issue)
>     >
>     > A few things for Git:
>     >
>     > * Try to keep it to a single commit per-JIRA
>     > * Refer to JIRA issue in the commit message
>     > _______________________________________________
>     > keycloak-dev mailing list
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141007/93c4c974/attachment-0001.html 

From alarik at zwift.com  Tue Oct  7 08:53:18 2014
From: alarik at zwift.com (Alarik Myrin)
Date: Tue, 7 Oct 2014 08:53:18 -0400
Subject: [keycloak-dev] Database migration
In-Reply-To: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>
References: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>
Message-ID: <CAKTx7M4mpe-LoZYyX95-AmbFNx0XQkmGeM6hxBMMocpLBELN6w@mail.gmail.com>

Although one downside of flywaydb is that you write SQL files, and so, it
becomes very database specific.  Not sure you guys want to get into the
business of writing SQL by hand for MySQL, PostgresSQL, Oracle, SQL Server,
DB2, H2, etc.



On Mon, Oct 6, 2014 at 9:27 AM, Alarik Myrin <alarik at zwift.com> wrote:

> I have been using flywaydb for a few months now, and I like it a lot...
>
> Alarik
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141007/a2b34ff7/attachment.html 

From stian at redhat.com  Tue Oct  7 08:54:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Oct 2014 08:54:06 -0400 (EDT)
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <5433DFBF.2090905@redhat.com>
References: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
	<542D590B.1010803@redhat.com>
	<CAKjsGbvzqpMT2rcmjDRxH=Kn8sAb0X-sRZ=VYsc0cOG3K0NtPw@mail.gmail.com>
	<5433DFBF.2090905@redhat.com>
Message-ID: <1654004787.63024248.1412686446237.JavaMail.zimbra@redhat.com>

If they're in the PR they're lost once it's merged, so we should put them in the commit.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Daniel Passos" <daniel at passos.me>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 October, 2014 2:42:39 PM
> Subject: Re: [keycloak-dev] JIRA usage
> 
> On 10/6/2014 6:31 PM, Daniel Passos wrote:
> 
> 
> 
> I don't like refer JIRA in commit message. I prefer refer it in PR. apart of
> that +1
> Sounds reasonable to me.
> 
> 
> 
> 
> -- Passos
> 
> On Thu, Oct 2, 2014 at 10:54 AM, Stan Silvert < ssilvert at redhat.com > wrote:
> 
> 
> +1
> 
> On 10/2/2014 3:49 AM, Stian Thorgersen wrote:
> > A few things I'd like us to follow with regards to using JIRA:
> > 
> > * Create a JIRA for all changes/fixes/improvements - unless they have no
> > effect on users
> > * When completing an issue mark as resolved (not closed) - we'll close when
> > we do a release (otherwise we can't change fix version without re-opening
> > the issue)
> > 
> > A few things for Git:
> > 
> > * Try to keep it to a single commit per-JIRA
> > * Refer to JIRA issue in the commit message
> > _______________________________________________
> > 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 Oct  7 08:56:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Oct 2014 08:56:57 -0400 (EDT)
Subject: [keycloak-dev] Database migration
In-Reply-To: <CAKTx7M4mpe-LoZYyX95-AmbFNx0XQkmGeM6hxBMMocpLBELN6w@mail.gmail.com>
References: <CAKTx7M4zVeo23+tudLWZjdr4msWP40jRwY2+oDRW3=kaR9OEgg@mail.gmail.com>
	<CAKTx7M4mpe-LoZYyX95-AmbFNx0XQkmGeM6hxBMMocpLBELN6w@mail.gmail.com>
Message-ID: <342662585.63025108.1412686617481.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Alarik Myrin" <alarik at zwift.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 October, 2014 2:53:18 PM
> Subject: Re: [keycloak-dev] Database migration
> 
> Although one downside of flywaydb is that you write SQL files, and so, it
> becomes very database specific. Not sure you guys want to get into the
> business of writing SQL by hand for MySQL, PostgresSQL, Oracle, SQL Server,
> DB2, H2, etc.

No, that's what I realised, so I'm looking at Liquibase now. 

Liquibase supports a generic xml file that it translates to individual databases. Looks like that'll be the best option for us.

> 
> 
> 
> On Mon, Oct 6, 2014 at 9:27 AM, Alarik Myrin < alarik at zwift.com > wrote:
> 
> 
> 
> I have been using flywaydb for a few months now, and I like it a lot...
> 
> Alarik
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Tue Oct  7 09:47:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Oct 2014 09:47:01 -0400
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5433DEC0.2090306@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>	<349291524.61849353.1412594600184.JavaMail.zimbra@redhat.com>	<54328502.7060909@redhat.com>	<235231688.61888334.1412597574838.JavaMail.zimbra@redhat.com>	<5432988C.5030803@redhat.com>
	<54329FE8.6070906@redhat.com>	<5432A725.2050509@redhat.com>
	<5432E189.5040506@redhat.com>	<1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
	<5433DEC0.2090306@redhat.com>
Message-ID: <5433EED5.8010805@redhat.com>



On 10/7/2014 8:38 AM, Bill Burke wrote:
>>>>
>>>> SAML has out-of-band logout requests too.  At least thats what I think
>>>> Pedro told me.
>>>>
>>>
>>> For Picketlink SAML SPs, you either do a browse redirect protocol to
>>> each SP for Single Log out, or you do an out of band logout request to
>>> the SP.  PL SAML SP adapter currently has the same problem as us in a
>>> cluster.  They keep an in-memory map between username and http session.
>>
>> Would it make sense to add redirect logout as well? Then you can set in the admin console which logout mechanism you want (none, redirect or out-of-band request?)
>>
>
> Yes.  I'm going to do that.  I need to add logout to the protocol SPI.
>

IMO, logouts via redirects are really ugly and you don't really need a 
redirect logout for keycloak.js clients.  With the iframe hack OpenID 
Connect has (and we implemented), you can just check if the user is 
logged out when a UI event happens.


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

From bburke at redhat.com  Tue Oct  7 09:49:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Oct 2014 09:49:21 -0400
Subject: [keycloak-dev] further changes to UserSessionModel
Message-ID: <5433EF61.5080005@redhat.com>

FYI:

To support multi-protocol logout via redirect, some changes to 
UserSessionModel will need to be done.  I'll need to have a "state" 
variable with values like "LOGGED_IN", "LOGGING_OUT", "LOGGED_OUT".  It 
will also need a map to hold state relevant to the entire UserSession.

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

From stian at redhat.com  Tue Oct  7 09:55:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Oct 2014 09:55:10 -0400 (EDT)
Subject: [keycloak-dev] Session SPI for adapters
In-Reply-To: <5433EED5.8010805@redhat.com>
References: <385188767.60265426.1412239653267.JavaMail.zimbra@redhat.com>
	<5432988C.5030803@redhat.com> <54329FE8.6070906@redhat.com>
	<5432A725.2050509@redhat.com> <5432E189.5040506@redhat.com>
	<1081805183.62743065.1412662423234.JavaMail.zimbra@redhat.com>
	<5433DEC0.2090306@redhat.com> <5433EED5.8010805@redhat.com>
Message-ID: <1833953523.63086079.1412690110110.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 October, 2014 3:47:01 PM
> Subject: Re: [keycloak-dev] Session SPI for adapters
> 
> 
> 
> On 10/7/2014 8:38 AM, Bill Burke wrote:
> >>>>
> >>>> SAML has out-of-band logout requests too.  At least thats what I think
> >>>> Pedro told me.
> >>>>
> >>>
> >>> For Picketlink SAML SPs, you either do a browse redirect protocol to
> >>> each SP for Single Log out, or you do an out of band logout request to
> >>> the SP.  PL SAML SP adapter currently has the same problem as us in a
> >>> cluster.  They keep an in-memory map between username and http session.
> >>
> >> Would it make sense to add redirect logout as well? Then you can set in
> >> the admin console which logout mechanism you want (none, redirect or
> >> out-of-band request?)
> >>
> >
> > Yes.  I'm going to do that.  I need to add logout to the protocol SPI.
> >
> 
> IMO, logouts via redirects are really ugly and you don't really need a
> redirect logout for keycloak.js clients.  With the iframe hack OpenID
> Connect has (and we implemented), you can just check if the user is
> logged out when a UI event happens.

I agree - how about we add the option to save the refresh token only. Then you have the two scenarios:

a) app is open (loaded in a browser tab) - iframe detects logout straight away
b) app is closed - if user opens app, refresh token is retrieved from session store, app will try to get access token, but fail as session is closed

> 
> 
> --
> 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 Oct  7 10:00:12 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 07 Oct 2014 10:00:12 -0400
Subject: [keycloak-dev] JIRA usage
In-Reply-To: <1654004787.63024248.1412686446237.JavaMail.zimbra@redhat.com>
References: <2092713139.60195863.1412236140508.JavaMail.zimbra@redhat.com>
	<542D590B.1010803@redhat.com>
	<CAKjsGbvzqpMT2rcmjDRxH=Kn8sAb0X-sRZ=VYsc0cOG3K0NtPw@mail.gmail.com>
	<5433DFBF.2090905@redhat.com>
	<1654004787.63024248.1412686446237.JavaMail.zimbra@redhat.com>
Message-ID: <5433F1EC.9020608@redhat.com>

On 10/7/2014 8:54 AM, Stian Thorgersen wrote:
> If they're in the PR they're lost once it's merged, so we should put them in the commit.
In the WFLY project, I think we are rewriting the commit messages when 
the PR is merged.  That way it is always referenced and always shows up 
in the JIRA.

If you link the PR in the JIRA then you can always go back to the commits.

That being said, I'm fine with whatever you guys want to do.  But I 
agree that we need some way to track this.


>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Daniel Passos" <daniel at passos.me>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 October, 2014 2:42:39 PM
>> Subject: Re: [keycloak-dev] JIRA usage
>>
>> On 10/6/2014 6:31 PM, Daniel Passos wrote:
>>
>>
>>
>> I don't like refer JIRA in commit message. I prefer refer it in PR. apart of
>> that +1
>> Sounds reasonable to me.
>>
>>
>>
>>
>> -- Passos
>>
>> On Thu, Oct 2, 2014 at 10:54 AM, Stan Silvert < ssilvert at redhat.com > wrote:
>>
>>
>> +1
>>
>> On 10/2/2014 3:49 AM, Stian Thorgersen wrote:
>>> A few things I'd like us to follow with regards to using JIRA:
>>>
>>> * Create a JIRA for all changes/fixes/improvements - unless they have no
>>> effect on users
>>> * When completing an issue mark as resolved (not closed) - we'll close when
>>> we do a release (otherwise we can't change fix version without re-opening
>>> the issue)
>>>
>>> A few things for Git:
>>>
>>> * Try to keep it to a single commit per-JIRA
>>> * Refer to JIRA issue in the commit message
>>> _______________________________________________
>>> 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  Wed Oct  8 09:44:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Oct 2014 15:44:45 +0200
Subject: [keycloak-dev] AS 7.1.1 broken in master
Message-ID: <54353FCD.7090804@redhat.com>

Currently AS 7.1.1 is broken on latest master due to this: 
https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L19 
.

To workaround that, I've needed to remove it from 
auth-server.war/WEB-INF/jboss-deployment-structure.xml and comment whole 
"webservices" extension and subsystem in standalone.xml .

Seems that we should fix it for release or drop support of JBoss AS 7.1.1.

Thoughts?

Marek

From stian at redhat.com  Wed Oct  8 09:47:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Oct 2014 09:47:29 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.2.Final released
In-Reply-To: <1130742028.64280615.1412776029225.JavaMail.zimbra@redhat.com>
Message-ID: <342511452.64280755.1412776049544.JavaMail.zimbra@redhat.com>

This is a maintenance release and contains only bug fixes and one minor security fix.

For full details look in JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.0.2.Final%20AND%20resolution%20%3D%20Done)

From bburke at redhat.com  Wed Oct  8 09:57:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 09:57:25 -0400
Subject: [keycloak-dev] Keycloak 1.0.2.Final released
In-Reply-To: <342511452.64280755.1412776049544.JavaMail.zimbra@redhat.com>
References: <342511452.64280755.1412776049544.JavaMail.zimbra@redhat.com>
Message-ID: <543542C5.5060405@redhat.com>

thanks stian.

On 10/8/2014 9:47 AM, Stian Thorgersen wrote:
> This is a maintenance release and contains only bug fixes and one minor security fix.
>
> For full details look in JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.0.2.Final%20AND%20resolution%20%3D%20Done)
> _______________________________________________
> 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 Oct  8 10:00:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 10:00:12 -0400
Subject: [keycloak-dev] AS 7.1.1 broken in master
In-Reply-To: <54353FCD.7090804@redhat.com>
References: <54353FCD.7090804@redhat.com>
Message-ID: <5435436C.1060500@redhat.com>

Just maybe document it in installation docs and add a migration note? 
Its just a matter of commenting out lines in jds.xml right?

On 10/8/2014 9:44 AM, Marek Posolda wrote:
> Currently AS 7.1.1 is broken on latest master due to this:
> https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L19
> .
>
> To workaround that, I've needed to remove it from
> auth-server.war/WEB-INF/jboss-deployment-structure.xml and comment whole
> "webservices" extension and subsystem in standalone.xml .
>
> Seems that we should fix it for release or drop support of JBoss AS 7.1.1.
>
> Thoughts?
>
> Marek
> _______________________________________________
> 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 Oct  8 10:01:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 10:01:32 -0400
Subject: [keycloak-dev] AS 7.1.1 broken in master
In-Reply-To: <5435436C.1060500@redhat.com>
References: <54353FCD.7090804@redhat.com> <5435436C.1060500@redhat.com>
Message-ID: <543543BC.3040001@redhat.com>

Oh, BTW, for SAML stuff I had to add that line, otherwise auth server 
doesn't deploy.  PL federation library has webservice endpoints that the 
deployer picks up :(

On 10/8/2014 10:00 AM, Bill Burke wrote:
> Just maybe document it in installation docs and add a migration note?
> Its just a matter of commenting out lines in jds.xml right?
>
> On 10/8/2014 9:44 AM, Marek Posolda wrote:
>> Currently AS 7.1.1 is broken on latest master due to this:
>> https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L19
>> .
>>
>> To workaround that, I've needed to remove it from
>> auth-server.war/WEB-INF/jboss-deployment-structure.xml and comment whole
>> "webservices" extension and subsystem in standalone.xml .
>>
>> Seems that we should fix it for release or drop support of JBoss AS 7.1.1.
>>
>> Thoughts?
>>
>> Marek
>> _______________________________________________
>> 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 Oct  8 10:08:54 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 08 Oct 2014 10:08:54 -0400
Subject: [keycloak-dev] What causes this?
Message-ID: <54354576.7060102@redhat.com>

I've screwed something up.  I've seen this before, but I can't for the 
life of me remember what causes it.  Look familiar to any of you guys?

09:00:40,332 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) 
MSC000001: Failed to start service 
jboss.undertow.deployment.default-server.default-host./customer-portal: 
org.jboss.msc.service.StartException in service 
jboss.undertow.deployment.default-server.default-host./customer-portal: 
Failed to start service
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) 
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
         at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown 
Source) [rt.jar:1.7.0_51]
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown 
Source) [rt.jar:1.7.0_51]
         at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: 
UT010039: Unknown authentication mechanism KEYCLOAK
         at 
io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
         at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
         at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) 
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
         at 
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) 
[jboss-msc-1.2.2.Final.jar:1.2.2.Final]
         ... 3 more
Caused by: java.lang.RuntimeException: UT010039: Unknown authentication 
mechanism KEYCLOAK
         at 
io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:320)
         at 
io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
         ... 7 more

From ssilvert at redhat.com  Wed Oct  8 10:13:51 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 08 Oct 2014 10:13:51 -0400
Subject: [keycloak-dev] What causes this?
In-Reply-To: <54354576.7060102@redhat.com>
References: <54354576.7060102@redhat.com>
Message-ID: <5435469F.3080709@redhat.com>

BTW, this is happening when I deploy the customer-portal.war app.

On 10/8/2014 10:08 AM, Stan Silvert wrote:
> I've screwed something up.  I've seen this before, but I can't for the
> life of me remember what causes it.  Look familiar to any of you guys?
>
> 09:00:40,332 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
> MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./customer-portal:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./customer-portal:
> Failed to start service
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) [rt.jar:1.7.0_51]
>           at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) [rt.jar:1.7.0_51]
>           at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
> UT010039: Unknown authentication mechanism KEYCLOAK
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
>           at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>           at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           ... 3 more
> Caused by: java.lang.RuntimeException: UT010039: Unknown authentication
> mechanism KEYCLOAK
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:320)
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
>           ... 7 more
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Oct  8 10:14:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 10:14:42 -0400
Subject: [keycloak-dev] What causes this?
In-Reply-To: <54354576.7060102@redhat.com>
References: <54354576.7060102@redhat.com>
Message-ID: <543546D2.5040706@redhat.com>

servlet extension not being found.  Did you install the keycloak adapter 
modules?

On 10/8/2014 10:08 AM, Stan Silvert wrote:
> I've screwed something up.  I've seen this before, but I can't for the
> life of me remember what causes it.  Look familiar to any of you guys?
>
> 09:00:40,332 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
> MSC000001: Failed to start service
> jboss.undertow.deployment.default-server.default-host./customer-portal:
> org.jboss.msc.service.StartException in service
> jboss.undertow.deployment.default-server.default-host./customer-portal:
> Failed to start service
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) [rt.jar:1.7.0_51]
>           at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) [rt.jar:1.7.0_51]
>           at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
> UT010039: Unknown authentication mechanism KEYCLOAK
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
>           at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>           at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>           ... 3 more
> Caused by: java.lang.RuntimeException: UT010039: Unknown authentication
> mechanism KEYCLOAK
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:320)
>           at
> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
>           ... 7 more
> _______________________________________________
> 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 Oct  8 10:18:47 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 08 Oct 2014 10:18:47 -0400
Subject: [keycloak-dev] What causes this?
In-Reply-To: <543546D2.5040706@redhat.com>
References: <54354576.7060102@redhat.com> <543546D2.5040706@redhat.com>
Message-ID: <543547C7.7030600@redhat.com>

Yes, but I probably messed up the reference to it.  That tells me where 
to look.  thanks.

On 10/8/2014 10:14 AM, Bill Burke wrote:
> servlet extension not being found.  Did you install the keycloak adapter
> modules?
>
> On 10/8/2014 10:08 AM, Stan Silvert wrote:
>> I've screwed something up.  I've seen this before, but I can't for the
>> life of me remember what causes it.  Look familiar to any of you guys?
>>
>> 09:00:40,332 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
>> MSC000001: Failed to start service
>> jboss.undertow.deployment.default-server.default-host./customer-portal:
>> org.jboss.msc.service.StartException in service
>> jboss.undertow.deployment.default-server.default-host./customer-portal:
>> Failed to start service
>>            at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>            at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>> Source) [rt.jar:1.7.0_51]
>>            at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>> Source) [rt.jar:1.7.0_51]
>>            at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>> UT010039: Unknown authentication mechanism KEYCLOAK
>>            at
>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
>>            at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>>            at
>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>            at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>            at
>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>            ... 3 more
>> Caused by: java.lang.RuntimeException: UT010039: Unknown authentication
>> mechanism KEYCLOAK
>>            at
>> io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:320)
>>            at
>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
>>            ... 7 more
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Wed Oct  8 10:41:14 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 08 Oct 2014 10:41:14 -0400
Subject: [keycloak-dev] What causes this?
In-Reply-To: <543547C7.7030600@redhat.com>
References: <54354576.7060102@redhat.com> <543546D2.5040706@redhat.com>
	<543547C7.7030600@redhat.com>
Message-ID: <54354D0A.4030009@redhat.com>

Found it.  Thanks again.

On 10/8/2014 10:18 AM, Stan Silvert wrote:
> Yes, but I probably messed up the reference to it.  That tells me where
> to look.  thanks.
>
> On 10/8/2014 10:14 AM, Bill Burke wrote:
>> servlet extension not being found.  Did you install the keycloak adapter
>> modules?
>>
>> On 10/8/2014 10:08 AM, Stan Silvert wrote:
>>> I've screwed something up.  I've seen this before, but I can't for the
>>> life of me remember what causes it.  Look familiar to any of you guys?
>>>
>>> 09:00:40,332 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8)
>>> MSC000001: Failed to start service
>>> jboss.undertow.deployment.default-server.default-host./customer-portal:
>>> org.jboss.msc.service.StartException in service
>>> jboss.undertow.deployment.default-server.default-host./customer-portal:
>>> Failed to start service
>>>             at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>             at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
>>> Source) [rt.jar:1.7.0_51]
>>>             at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
>>> Source) [rt.jar:1.7.0_51]
>>>             at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_51]
>>> Caused by: java.lang.RuntimeException: java.lang.RuntimeException:
>>> UT010039: Unknown authentication mechanism KEYCLOAK
>>>             at
>>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:219)
>>>             at
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:87)
>>>             at
>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72)
>>>             at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>             at
>>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>>> [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
>>>             ... 3 more
>>> Caused by: java.lang.RuntimeException: UT010039: Unknown authentication
>>> mechanism KEYCLOAK
>>>             at
>>> io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:320)
>>>             at
>>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:195)
>>>             ... 7 more
>>> _______________________________________________
>>> 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 lholmqui at redhat.com  Wed Oct  8 11:29:22 2014
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Wed, 8 Oct 2014 11:29:22 -0400
Subject: [keycloak-dev] node.js support
Message-ID: <73DEA98B-8BCF-4854-8E7D-40E23038C952@redhat.com>

so i know node.js support is on the road map,  i was wondering if you guys have any thoughts on what that will look like at this point?

I?m playing around with the idea of creating an ?adapter? for passport.js, http://passportjs.org/,  that would hook into KC. 

-Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141008/5c2964d7/attachment-0001.html 

From bburke at redhat.com  Wed Oct  8 12:12:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 12:12:14 -0400
Subject: [keycloak-dev] node.js support
In-Reply-To: <73DEA98B-8BCF-4854-8E7D-40E23038C952@redhat.com>
References: <73DEA98B-8BCF-4854-8E7D-40E23038C952@redhat.com>
Message-ID: <5435625E.4070401@redhat.com>

I thought it might only be bearer-token auth at the node.js server side, 
with node.js interceptors to add roles allowed checks and maybe some way 
to propagate the principal.

On 10/8/2014 11:29 AM, Lucas Holmquist wrote:
> so i know node.js support is on the road map,  i was wondering if you
> guys have any thoughts on what that will look like at this point?
>
> I?m playing around with the idea of creating an ?adapter? for
> passport.js, http://passportjs.org/,  that would hook into KC.
>
> -Luke
>
>
> _______________________________________________
> 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 Oct  8 12:14:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 12:14:22 -0400
Subject: [keycloak-dev] need angular js help!
Message-ID: <543562DE.8060104@redhat.com>

I can't figure out how to encode a link in a html page for angular js

                 <td><a 
href="#/realms/{{realm.realm}}/applications/{{app.name | 
encodeUri}}">{{app.name}}</a></td>


I wrote a filter to do this "encodeUri" that is getting invoked, but the 
link still is not encoded when displayed.  ARG!!!!

module.filter('encodeUri', function($window) {
     return function(str) {
         var str = encodeURIComponent(shit);
         return str;
     };
});
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Oct  8 12:24:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 12:24:08 -0400
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <543562DE.8060104@redhat.com>
References: <543562DE.8060104@redhat.com>
Message-ID: <54356528.8020501@redhat.com>

In other words, the filter gets called, but angular seems to decode it! 
  WTF!!!! ARG!!!!

On 10/8/2014 12:14 PM, Bill Burke wrote:
> I can't figure out how to encode a link in a html page for angular js
>
>                   <td><a
> href="#/realms/{{realm.realm}}/applications/{{app.name |
> encodeUri}}">{{app.name}}</a></td>
>
>
> I wrote a filter to do this "encodeUri" that is getting invoked, but the
> link still is not encoded when displayed.  ARG!!!!
>
> module.filter('encodeUri', function($window) {
>       return function(str) {
>           var str = encodeURIComponent(shit);
>           return str;
>       };
> });
>

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

From mposolda at redhat.com  Wed Oct  8 12:39:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Oct 2014 18:39:52 +0200
Subject: [keycloak-dev] AS 7.1.1 broken in master
In-Reply-To: <543543BC.3040001@redhat.com>
References: <54353FCD.7090804@redhat.com> <5435436C.1060500@redhat.com>
	<543543BC.3040001@redhat.com>
Message-ID: <543568D8.8040200@redhat.com>

It's jds.xml and standalone.xml . After commenting just jds.xml I have 
issue at server startup like:
...
Caused by: java.io.FileNotFoundException: 
/tmp/kc/keycloak/bin/WEB-INF/wsdl/PicketLinkSTS.wsdl

So I needed to comment webservices extension and subsystem in 
standalone.xml. Maybe it's more clever workaround, but I didn't look 
deeper at it...

Documenting seems to be fine, but it's limitation that people who use 
keycloak on AS 7.1.1 can't use webservices subsystem on same server. Is 
it ok?

Marek

On 8.10.2014 16:01, Bill Burke wrote:
> Oh, BTW, for SAML stuff I had to add that line, otherwise auth server
> doesn't deploy.  PL federation library has webservice endpoints that the
> deployer picks up :(
>
> On 10/8/2014 10:00 AM, Bill Burke wrote:
>> Just maybe document it in installation docs and add a migration note?
>> Its just a matter of commenting out lines in jds.xml right?
>>
>> On 10/8/2014 9:44 AM, Marek Posolda wrote:
>>> Currently AS 7.1.1 is broken on latest master due to this:
>>> https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L19
>>> .
>>>
>>> To workaround that, I've needed to remove it from
>>> auth-server.war/WEB-INF/jboss-deployment-structure.xml and comment whole
>>> "webservices" extension and subsystem in standalone.xml .
>>>
>>> Seems that we should fix it for release or drop support of JBoss AS 7.1.1.
>>>
>>> Thoughts?
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>


From bburke at redhat.com  Wed Oct  8 12:42:13 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 12:42:13 -0400
Subject: [keycloak-dev] AS 7.1.1 broken in master
In-Reply-To: <543568D8.8040200@redhat.com>
References: <54353FCD.7090804@redhat.com> <5435436C.1060500@redhat.com>
	<543543BC.3040001@redhat.com> <543568D8.8040200@redhat.com>
Message-ID: <54356965.20905@redhat.com>

They could also remove picketlink-federation jar but they would get no SAML.

On 10/8/2014 12:39 PM, Marek Posolda wrote:
> It's jds.xml and standalone.xml . After commenting just jds.xml I have
> issue at server startup like:
> ...
> Caused by: java.io.FileNotFoundException:
> /tmp/kc/keycloak/bin/WEB-INF/wsdl/PicketLinkSTS.wsdl
>
> So I needed to comment webservices extension and subsystem in
> standalone.xml. Maybe it's more clever workaround, but I didn't look
> deeper at it...
>
> Documenting seems to be fine, but it's limitation that people who use
> keycloak on AS 7.1.1 can't use webservices subsystem on same server. Is
> it ok?
>
> Marek
>
> On 8.10.2014 16:01, Bill Burke wrote:
>> Oh, BTW, for SAML stuff I had to add that line, otherwise auth server
>> doesn't deploy.  PL federation library has webservice endpoints that the
>> deployer picks up :(
>>
>> On 10/8/2014 10:00 AM, Bill Burke wrote:
>>> Just maybe document it in installation docs and add a migration note?
>>> Its just a matter of commenting out lines in jds.xml right?
>>>
>>> On 10/8/2014 9:44 AM, Marek Posolda wrote:
>>>> Currently AS 7.1.1 is broken on latest master due to this:
>>>> https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L19
>>>>
>>>> .
>>>>
>>>> To workaround that, I've needed to remove it from
>>>> auth-server.war/WEB-INF/jboss-deployment-structure.xml and comment
>>>> whole
>>>> "webservices" extension and subsystem in standalone.xml .
>>>>
>>>> Seems that we should fix it for release or drop support of JBoss AS
>>>> 7.1.1.
>>>>
>>>> Thoughts?
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> 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 Oct  8 12:44:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 12:44:26 -0400
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <54356528.8020501@redhat.com>
References: <543562DE.8060104@redhat.com> <54356528.8020501@redhat.com>
Message-ID: <543569EA.5090501@redhat.com>

ARG!!!!  Now I'm stuck.  Seems to be a bug in angular that causes '/' to 
be decoded automatically...

https://github.com/angular/angular.js/issues/5645

SAML client ids are all URLs.



On 10/8/2014 12:24 PM, Bill Burke wrote:
> In other words, the filter gets called, but angular seems to decode it!
>    WTF!!!! ARG!!!!
>
> On 10/8/2014 12:14 PM, Bill Burke wrote:
>> I can't figure out how to encode a link in a html page for angular js
>>
>>                    <td><a
>> href="#/realms/{{realm.realm}}/applications/{{app.name |
>> encodeUri}}">{{app.name}}</a></td>
>>
>>
>> I wrote a filter to do this "encodeUri" that is getting invoked, but the
>> link still is not encoded when displayed.  ARG!!!!
>>
>> module.filter('encodeUri', function($window) {
>>        return function(str) {
>>            var str = encodeURIComponent(shit);
>>            return str;
>>        };
>> });
>>
>

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

From stian at redhat.com  Wed Oct  8 13:17:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Oct 2014 13:17:12 -0400 (EDT)
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <543562DE.8060104@redhat.com>
References: <543562DE.8060104@redhat.com>
Message-ID: <1329107314.64429606.1412788632566.JavaMail.zimbra@redhat.com>

How about double encode it to get around the bug?:

  module.filter('encodeUri', function($window) {
    return function(shit) {
      var shit = encodeURIComponent(encodeURIComponent(shit));
      return shit;
    };
  });

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 8 October, 2014 6:14:22 PM
> Subject: [keycloak-dev] need angular js help!
> 
> I can't figure out how to encode a link in a html page for angular js
> 
>                  <td><a
> href="#/realms/{{realm.realm}}/applications/{{app.name |
> encodeUri}}">{{app.name}}</a></td>
> 
> 
> I wrote a filter to do this "encodeUri" that is getting invoked, but the
> link still is not encoded when displayed.  ARG!!!!
> 
> module.filter('encodeUri', function($window) {
>      return function(str) {
>          var str = encodeURIComponent(shit);
>          return str;
>      };
> });
> --
> 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 Oct  8 13:38:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Oct 2014 13:38:21 -0400 (EDT)
Subject: [keycloak-dev] Data migration strategy
In-Reply-To: <629131424.64431724.1412788895478.JavaMail.zimbra@redhat.com>
Message-ID: <2141634968.64439545.1412789901960.JavaMail.zimbra@redhat.com>

As mentioned before to allow users from keeping their existing database when upgrading to a new version we'll need a migration strategy.

There's 3 separate things to deal with: JPA database, Mongo database and finally JSON representation (exports). For 1.1.0.Beta1 as the JPA and Mongo schemas have changed we'll need to sort out for this release. JSON representations have not changed (afaik) so we can leave this for later when it's needed.

For relational databases I propose (and I have a working prototype for this) we use Liquibase. Liquibase makes it possible to create a generic "change-set" that transforms a database from one version to the next. As it supports creating these change-sets from a running database it's fairly trivial to generate this automatically and only requires a short review. If data in any columns needs updating or adding that still needs to be done manually. The change-sets are also database agnostic and Liquibase concerts these into SQL specific to the current database. I've made a JPAUpdaterSpi, with Liquibase being an optional provider. This means there's no hard dependency on Liquibase. However, if it's not included it won't be possible to upgrade the database automatically. In that case the user could use Liquibase command line tool to update the database manually.

For Mongo databases I propose something similar to Liquibase, but we'll have to write it ourselves. We'll create an interface that has one method transform(DB db), and for each release where data has changed we'll have to provide an implementation of this that can rewrite the data. We'll maintain a list of these transformations, and store which has been applied in a collection.

For representations (again we don't need this now) we'll do something similar to Mongo, a chain of transforms that can convert the JSON representations from one version to the next.

With regards to Liquibase there was recently a thread on tag that suggest we discuss inclusion of 3rd party components in projects. AeroGear also have similar needs and they want to use LiquiBase as well. Just to make sure there's no issues with using Liquibase I'll write a mail to tag. Although, other similar projects are far from as nice as Liquibase (don't have database agnostic script, don't have automatic generation of changsets, etc.). If we had to do it manually we'd have to replicate what Liquibase does with regards to recording applied changes in a table, then we'd also have to write SQL scripts for each release for each database we support.

First before I write mail to tag. Any objections to using Liquibase here? Or proposals for another solution?

From bburke at redhat.com  Wed Oct  8 14:37:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 14:37:56 -0400
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <1329107314.64429606.1412788632566.JavaMail.zimbra@redhat.com>
References: <543562DE.8060104@redhat.com>
	<1329107314.64429606.1412788632566.JavaMail.zimbra@redhat.com>
Message-ID: <54358484.2000301@redhat.com>

You are just brilliant!  I am just stupid...

On 10/8/2014 1:17 PM, Stian Thorgersen wrote:
> How about double encode it to get around the bug?:
>
>    module.filter('encodeUri', function($window) {
>      return function(shit) {
>        var shit = encodeURIComponent(encodeURIComponent(shit));
>        return shit;
>      };
>    });
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 8 October, 2014 6:14:22 PM
>> Subject: [keycloak-dev] need angular js help!
>>
>> I can't figure out how to encode a link in a html page for angular js
>>
>>                   <td><a
>> href="#/realms/{{realm.realm}}/applications/{{app.name |
>> encodeUri}}">{{app.name}}</a></td>
>>
>>
>> I wrote a filter to do this "encodeUri" that is getting invoked, but the
>> link still is not encoded when displayed.  ARG!!!!
>>
>> module.filter('encodeUri', function($window) {
>>       return function(str) {
>>           var str = encodeURIComponent(shit);
>>           return str;
>>       };
>> });
>> --
>> 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 Oct  8 14:43:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 14:43:59 -0400
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <54358484.2000301@redhat.com>
References: <543562DE.8060104@redhat.com>	<1329107314.64429606.1412788632566.JavaMail.zimbra@redhat.com>
	<54358484.2000301@redhat.com>
Message-ID: <543585EF.2060004@redhat.com>

Ugh...Now the browser's URL is doubly encoded....

Can I switch things to just use ids and keep application name as an option?

On 10/8/2014 2:37 PM, Bill Burke wrote:
> You are just brilliant!  I am just stupid...
>
> On 10/8/2014 1:17 PM, Stian Thorgersen wrote:
>> How about double encode it to get around the bug?:
>>
>>     module.filter('encodeUri', function($window) {
>>       return function(shit) {
>>         var shit = encodeURIComponent(encodeURIComponent(shit));
>>         return shit;
>>       };
>>     });
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 8 October, 2014 6:14:22 PM
>>> Subject: [keycloak-dev] need angular js help!
>>>
>>> I can't figure out how to encode a link in a html page for angular js
>>>
>>>                    <td><a
>>> href="#/realms/{{realm.realm}}/applications/{{app.name |
>>> encodeUri}}">{{app.name}}</a></td>
>>>
>>>
>>> I wrote a filter to do this "encodeUri" that is getting invoked, but the
>>> link still is not encoded when displayed.  ARG!!!!
>>>
>>> module.filter('encodeUri', function($window) {
>>>        return function(str) {
>>>            var str = encodeURIComponent(shit);
>>>            return str;
>>>        };
>>> });
>>> --
>>> 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 Oct  8 14:45:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 14:45:42 -0400
Subject: [keycloak-dev] need angular js help!
In-Reply-To: <543585EF.2060004@redhat.com>
References: <543562DE.8060104@redhat.com>	<1329107314.64429606.1412788632566.JavaMail.zimbra@redhat.com>	<54358484.2000301@redhat.com>
	<543585EF.2060004@redhat.com>
Message-ID: <54358656.1050109@redhat.com>

It works for menu migration, but the browser url is doubly encoded and 
you can't refresh the page.  I guess it is the router that is 
re-encoding things.

On 10/8/2014 2:43 PM, Bill Burke wrote:
> Ugh...Now the browser's URL is doubly encoded....
>
> Can I switch things to just use ids and keep application name as an option?
>
> On 10/8/2014 2:37 PM, Bill Burke wrote:
>> You are just brilliant!  I am just stupid...
>>
>> On 10/8/2014 1:17 PM, Stian Thorgersen wrote:
>>> How about double encode it to get around the bug?:
>>>
>>>      module.filter('encodeUri', function($window) {
>>>        return function(shit) {
>>>          var shit = encodeURIComponent(encodeURIComponent(shit));
>>>          return shit;
>>>        };
>>>      });
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 8 October, 2014 6:14:22 PM
>>>> Subject: [keycloak-dev] need angular js help!
>>>>
>>>> I can't figure out how to encode a link in a html page for angular js
>>>>
>>>>                     <td><a
>>>> href="#/realms/{{realm.realm}}/applications/{{app.name |
>>>> encodeUri}}">{{app.name}}</a></td>
>>>>
>>>>
>>>> I wrote a filter to do this "encodeUri" that is getting invoked, but the
>>>> link still is not encoded when displayed.  ARG!!!!
>>>>
>>>> module.filter('encodeUri', function($window) {
>>>>         return function(str) {
>>>>             var str = encodeURIComponent(shit);
>>>>             return str;
>>>>         };
>>>> });
>>>> --
>>>> 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 Oct  8 15:37:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Oct 2014 15:37:42 -0400
Subject: [keycloak-dev] admin console will use IDs for urls
Message-ID: <54359286.8010702@redhat.com>

Usings URLs for applicaiton and oauth client names will be the norm for 
SAML and probably also very common for openid-connect too since a lot of 
spec examples use URLs IIRC.

Angular JS does not like URLs specifically encoded slashes.  I've tried 
a bunch of things, but can't really get everything to work completely 
and properly.  We should just switch back to IDs for referencing 
applications and oauth clients.  To facilitate that I'm going to keep 
the old REST api, but add

realms/{realm-name}/applications-by-id/{id}
realms/{realm-name}/oauth-clients-by-id/{id}

Very minimal changes on the server side, but the admin console is going 
to require a lot of work :(

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

From mposolda at redhat.com  Wed Oct  8 18:02:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 09 Oct 2014 00:02:07 +0200
Subject: [keycloak-dev] Stateless session management pushed
Message-ID: <5435B45F.1040304@redhat.com>

Some summary of my changes:

- Added new parameter "http_session_id" to code-to-token request. It's 
not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's 
saved as note in ClientSessionModel.

- ResourceAdminManager refactored to use the IDs of httpSession, which 
are retrieved from ClientSessions. Removed username and 
keycloakSessionId from LogoutAction

- Adapter statistics removed and everything related to them.

- UndertowUserSessionManagement and CatalinaUserManagement are now fully 
stateless.

- Added new config option to adapters 'always-refresh-token' as we 
discussed. If it's true, then adapter will always send request to 
refresh accessToken during authentication (doesn't apply for bearer 
authentication, just for cookie). In the end I've used this approach 
instead of validating accessToken . It seems to be safer (no window) and 
you are always fine with 1 additional request. This option is useful in 
cluster in case that you have non-distributable sessions. With 
non-distributable it could happen that your user logged on node1, but 
logout request from KC is handled on node2 where httpSession doesn't 
exist. This is no issue with "distributable" sessions as those are 
replicated and hence logout can happen on any node.

- https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token 
fails from adapters, then httpSession is invalidated immediatelly

So clustering on adapters side works well now for both Wildfly & EAP 6.3


Questions & remaining work:

- I am not so happy with logout for apps with non-distributable HTTP 
sessions. It can be handled with 'always-refresh-token' but it's 
performance penalty to always refresh token. The alternative might be to 
send also hostname in code-to-token request. This would help as 
ResourceAdminManager will be able to detect to which node send request 
for invalidate http session. Does it worth adding it?

- Is it ok to have parameter like "http_session_id" or should it be 
instead something more generic like "adapter_session_id" ? I am not sure 
if 'Http Session' is not JEE specific term? I looked at OpenID connect 
and there is no something like this mentioned (In fact OpenID Connect 
doesn't handle single-sign-out)

- Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support 
for storing token in cookie instead of HttpSession) or is it ok to leave 
it for later? Note that for logout it will require 
'always-refresh-token' or "hostname" stuff I mentioned above.

thoughts?

Marek

From stian at redhat.com  Thu Oct  9 03:19:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Oct 2014 03:19:03 -0400 (EDT)
Subject: [keycloak-dev] admin console will use IDs for urls
In-Reply-To: <54359286.8010702@redhat.com>
References: <54359286.8010702@redhat.com>
Message-ID: <1981444688.64703322.1412839143724.JavaMail.zimbra@redhat.com>

That sucks - but I don't have any other suggestions, so I guess that's what we'll have to do

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 8 October, 2014 9:37:42 PM
> Subject: [keycloak-dev] admin console will use IDs for urls
> 
> Usings URLs for applicaiton and oauth client names will be the norm for
> SAML and probably also very common for openid-connect too since a lot of
> spec examples use URLs IIRC.
> 
> Angular JS does not like URLs specifically encoded slashes.  I've tried
> a bunch of things, but can't really get everything to work completely
> and properly.  We should just switch back to IDs for referencing
> applications and oauth clients.  To facilitate that I'm going to keep
> the old REST api, but add
> 
> realms/{realm-name}/applications-by-id/{id}
> realms/{realm-name}/oauth-clients-by-id/{id}
> 
> Very minimal changes on the server side, but the admin console is going
> to require a lot of 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  Thu Oct  9 09:45:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Oct 2014 09:45:29 -0400 (EDT)
Subject: [keycloak-dev] Move wiki pages to keycloak/docs
In-Reply-To: <59598536.64953664.1412862064514.JavaMail.zimbra@redhat.com>
Message-ID: <1726309284.64957067.1412862329236.JavaMail.zimbra@redhat.com>

For developer related docs, for example:

* Release process
* Release manual testing
* Upgrading database schema
* Upgrading OpenShift cartridge

I propose we stop using the GitHub wiki and instead add it to https://github.com/keycloak/keycloak/misc. We can add a link to the docs in the main https://github.com/keycloak/keycloak/README.md.

From bburke at redhat.com  Thu Oct  9 18:37:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Oct 2014 18:37:35 -0400
Subject: [keycloak-dev] important changes/additions
Message-ID: <54370E2F.8080108@redhat.com>

Some recent changes in my last commit.

* Just changed the admin console to use ids instead of names for 
applications in URLs because of the Angular encoding bug.  I will do 
this for oauth clients tomorrow.
* Admin REST API is backwards compatible, but I added an additional 
parallel path where appropriate so that REST queries can use app ids 
instead of names.  I will be doing the same for oauth clients too.
* I added attributes to ClientModel as well as a new protocol property. 
  There's some extra metadata that SAML needs to store.  Flags and 
client keypairs.

Bill

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

From ken at kenfinnigan.me  Thu Oct  9 19:56:58 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Thu, 9 Oct 2014 19:56:58 -0400
Subject: [keycloak-dev] Creating Users with no Email Address
Message-ID: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>

Hi,

It used to be possible to create multiple users with no email address.

With 1.0.1.Final, and maybe earlier versions, it's no longer possible. As
soon as a user is created with no email address set, any other user created
is not able to not have an email address.

The Keycloak Admin console doesn't specify email address as a required
field, so I was wondering whether this is a bug, and whether it's a bug in
the UI or the model?

No problems in creating a JIRA, wanted to verify I wasn't mistaken with
what's happening.

Thanks
Ken Finnigan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141009/fe3d87ac/attachment.html 

From mposolda at redhat.com  Fri Oct 10 02:58:01 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Oct 2014 08:58:01 +0200
Subject: [keycloak-dev] Creating Users with no Email Address
In-Reply-To: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>
References: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>
Message-ID: <54378379.1060204@redhat.com>

Hi,

That's strange. It works for me with latest keycloak master. I've 
created 2 users in kc admin console with empty email and both are saved 
(I am using mongo model like liveoak does). Only added related thing in 
1.0.1.Final is https://issues.jboss.org/browse/KEYCLOAK-676, which 
disallow users to register with invalid email. But that's just added 
validation in registration forms and account mgmt - no changes in admin 
console or model.

I wonder if it can't be "null vs. empty string" issue? KC admin console 
doesn't send email attribute at all when you don't fill email. I suspect 
that you're creating users in liveoak admin console? Isn't it possible 
that liveoak is sending email with empty string when it's not filled?

Marek


On 10.10.2014 01:56, Ken Finnigan wrote:
> Hi,
>
> It used to be possible to create multiple users with no email address.
>
> With 1.0.1.Final, and maybe earlier versions, it's no longer possible. 
> As soon as a user is created with no email address set, any other user 
> created is not able to not have an email address.
>
> The Keycloak Admin console doesn't specify email address as a required 
> field, so I was wondering whether this is a bug, and whether it's a 
> bug in the UI or the model?
>
> No problems in creating a JIRA, wanted to verify I wasn't mistaken 
> with what's happening.
>
> Thanks
> Ken Finnigan
>
>
> _______________________________________________
> 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/20141010/5553789a/attachment.html 

From stian at redhat.com  Fri Oct 10 05:03:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Oct 2014 05:03:00 -0400 (EDT)
Subject: [keycloak-dev] Stateless session management pushed
In-Reply-To: <5435B45F.1040304@redhat.com>
References: <5435B45F.1040304@redhat.com>
Message-ID: <1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 October, 2014 12:02:07 AM
> Subject: [keycloak-dev] Stateless session management pushed
> 
> Some summary of my changes:
> 
> - Added new parameter "http_session_id" to code-to-token request. It's
> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
> saved as note in ClientSessionModel.
> 
> - ResourceAdminManager refactored to use the IDs of httpSession, which
> are retrieved from ClientSessions. Removed username and
> keycloakSessionId from LogoutAction
> 
> - Adapter statistics removed and everything related to them.
> 
> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
> stateless.
> 
> - Added new config option to adapters 'always-refresh-token' as we
> discussed. If it's true, then adapter will always send request to
> refresh accessToken during authentication (doesn't apply for bearer
> authentication, just for cookie). In the end I've used this approach
> instead of validating accessToken . It seems to be safer (no window) and
> you are always fine with 1 additional request. This option is useful in
> cluster in case that you have non-distributable sessions. With
> non-distributable it could happen that your user logged on node1, but
> logout request from KC is handled on node2 where httpSession doesn't
> exist. This is no issue with "distributable" sessions as those are
> replicated and hence logout can happen on any node.
> 
> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
> fails from adapters, then httpSession is invalidated immediatelly
> 
> So clustering on adapters side works well now for both Wildfly & EAP 6.3
> 
> 
> Questions & remaining work:
> 
> - I am not so happy with logout for apps with non-distributable HTTP
> sessions. It can be handled with 'always-refresh-token' but it's
> performance penalty to always refresh token. The alternative might be to
> send also hostname in code-to-token request. This would help as
> ResourceAdminManager will be able to detect to which node send request
> for invalidate http session. Does it worth adding it?

Can you elaborate on the 'hostname' in code-to-token requests? I don't quite get what that would do.

I think the two options we have currently is sufficient, if properly document:

a) Logout doesn't happen until access token expires (default)
b) Access token is always refreshed (make sure we document the potential performance hit)

As an optimization I think we should do is that we should add a cookie that is invalidated when a user logs-out. The cookie would only be invalidated for the application driving the logout (retrieves the 'final' logout redirect) or for applications using the coming crazy logout redirect loop. My reasoning is that I think a) is sufficient for single-sign out, but if a user logs-out through a specific application at least that application should show a logged out state straight away.

> 
> - Is it ok to have parameter like "http_session_id" or should it be
> instead something more generic like "adapter_session_id" ? I am not sure
> if 'Http Session' is not JEE specific term? I looked at OpenID connect
> and there is no something like this mentioned (In fact OpenID Connect
> doesn't handle single-sign-out)

I don't think there's nothing JEE specific about a http session, but it leaves some confusion to which session. What about 'application_session_state'?

> 
> - Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
> for storing token in cookie instead of HttpSession) or is it ok to leave
> it for later? Note that for logout it will require
> 'always-refresh-token' or "hostname" stuff I mentioned above.

I think we should add it now, see my comment above (only the driving app has to be logged-out immediately IMO).

> 
> thoughts?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Fri Oct 10 07:07:49 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Oct 2014 13:07:49 +0200
Subject: [keycloak-dev] Stateless session management pushed
In-Reply-To: <1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>
References: <5435B45F.1040304@redhat.com>
	<1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>
Message-ID: <5437BE05.9050204@redhat.com>

On 10.10.2014 11:03, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 9 October, 2014 12:02:07 AM
>> Subject: [keycloak-dev] Stateless session management pushed
>>
>> Some summary of my changes:
>>
>> - Added new parameter "http_session_id" to code-to-token request. It's
>> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
>> saved as note in ClientSessionModel.
>>
>> - ResourceAdminManager refactored to use the IDs of httpSession, which
>> are retrieved from ClientSessions. Removed username and
>> keycloakSessionId from LogoutAction
>>
>> - Adapter statistics removed and everything related to them.
>>
>> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
>> stateless.
>>
>> - Added new config option to adapters 'always-refresh-token' as we
>> discussed. If it's true, then adapter will always send request to
>> refresh accessToken during authentication (doesn't apply for bearer
>> authentication, just for cookie). In the end I've used this approach
>> instead of validating accessToken . It seems to be safer (no window) and
>> you are always fine with 1 additional request. This option is useful in
>> cluster in case that you have non-distributable sessions. With
>> non-distributable it could happen that your user logged on node1, but
>> logout request from KC is handled on node2 where httpSession doesn't
>> exist. This is no issue with "distributable" sessions as those are
>> replicated and hence logout can happen on any node.
>>
>> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
>> fails from adapters, then httpSession is invalidated immediatelly
>>
>> So clustering on adapters side works well now for both Wildfly & EAP 6.3
>>
>>
>> Questions & remaining work:
>>
>> - I am not so happy with logout for apps with non-distributable HTTP
>> sessions. It can be handled with 'always-refresh-token' but it's
>> performance penalty to always refresh token. The alternative might be to
>> send also hostname in code-to-token request. This would help as
>> ResourceAdminManager will be able to detect to which node send request
>> for invalidate http session. Does it worth adding it?
> Can you elaborate on the 'hostname' in code-to-token requests? I don't quite get what that would do.
Hostname where application is logged and sticky session is established, 
so keycloak knows to which host to send out-of-bound logout request.

In details:
- User logs to product-portal and session "httpSession1" is established 
on node1
- Now he send logout request to keycloak. Keycloak will then send 
out-of-band logout request, but it can happen that this ends on node2.

Note that this is not an issue for distributable apps. Here sessions are 
replicated so session invalidation could happen on node2 and it's 
propagated to node1 too. It's just an issue for non-distributable apps 
as session with ID "httpSession1" doesn't exist on node2, so nothing 
would be invalidated and user is still logged.

With this feature, keycloak knows to which node send invalidation 
request. Without this we would need to rely either on the logout just of 
the app, which initiated logout (no single-sign-out) or rely on browser 
redirects. Is it sufficient?

Btv. I've already worked on this yesterday and pushed it to master;-)
>
> I think the two options we have currently is sufficient, if properly document:
>
> a) Logout doesn't happen until access token expires (default)
> b) Access token is always refreshed (make sure we document the potential performance hit)
>
> As an optimization I think we should do is that we should add a cookie that is invalidated when a user logs-out. The cookie would only be invalidated for the application driving the logout (retrieves the 'final' logout redirect) or for applications using the coming crazy logout redirect loop. My reasoning is that I think a) is sufficient for single-sign out, but if a user logs-out through a specific application at least that application should show a logged out state straight away.
yep, so that's https://issues.jboss.org/browse/KEYCLOAK-702 right? And 
the cookie will be used just for apps, which don't want to have 
httpSession, correct? As for other apps, there is already cookie 
JSESSIONID, so there is no need to have another cookie imo?
>
>> - Is it ok to have parameter like "http_session_id" or should it be
>> instead something more generic like "adapter_session_id" ? I am not sure
>> if 'Http Session' is not JEE specific term? I looked at OpenID connect
>> and there is no something like this mentioned (In fact OpenID Connect
>> doesn't handle single-sign-out)
> I don't think there's nothing JEE specific about a http session, but it leaves some confusion to which session. What about 'application_session_state'?
yup, I think it's better. Will update it.
>
>> - Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
>> for storing token in cookie instead of HttpSession) or is it ok to leave
>> it for later? Note that for logout it will require
>> 'always-refresh-token' or "hostname" stuff I mentioned above.
> I think we should add it now, see my comment above (only the driving app has to be logged-out immediately IMO).
>
>> thoughts?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Fri Oct 10 07:13:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Oct 2014 07:13:27 -0400 (EDT)
Subject: [keycloak-dev] Stateless session management pushed
In-Reply-To: <5437BE05.9050204@redhat.com>
References: <5435B45F.1040304@redhat.com>
	<1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>
	<5437BE05.9050204@redhat.com>
Message-ID: <2124220188.65663067.1412939607014.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 October, 2014 1:07:49 PM
> Subject: Re: [keycloak-dev] Stateless session management pushed
> 
> On 10.10.2014 11:03, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 9 October, 2014 12:02:07 AM
> >> Subject: [keycloak-dev] Stateless session management pushed
> >>
> >> Some summary of my changes:
> >>
> >> - Added new parameter "http_session_id" to code-to-token request. It's
> >> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
> >> saved as note in ClientSessionModel.
> >>
> >> - ResourceAdminManager refactored to use the IDs of httpSession, which
> >> are retrieved from ClientSessions. Removed username and
> >> keycloakSessionId from LogoutAction
> >>
> >> - Adapter statistics removed and everything related to them.
> >>
> >> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
> >> stateless.
> >>
> >> - Added new config option to adapters 'always-refresh-token' as we
> >> discussed. If it's true, then adapter will always send request to
> >> refresh accessToken during authentication (doesn't apply for bearer
> >> authentication, just for cookie). In the end I've used this approach
> >> instead of validating accessToken . It seems to be safer (no window) and
> >> you are always fine with 1 additional request. This option is useful in
> >> cluster in case that you have non-distributable sessions. With
> >> non-distributable it could happen that your user logged on node1, but
> >> logout request from KC is handled on node2 where httpSession doesn't
> >> exist. This is no issue with "distributable" sessions as those are
> >> replicated and hence logout can happen on any node.
> >>
> >> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
> >> fails from adapters, then httpSession is invalidated immediatelly
> >>
> >> So clustering on adapters side works well now for both Wildfly & EAP 6.3
> >>
> >>
> >> Questions & remaining work:
> >>
> >> - I am not so happy with logout for apps with non-distributable HTTP
> >> sessions. It can be handled with 'always-refresh-token' but it's
> >> performance penalty to always refresh token. The alternative might be to
> >> send also hostname in code-to-token request. This would help as
> >> ResourceAdminManager will be able to detect to which node send request
> >> for invalidate http session. Does it worth adding it?
> > Can you elaborate on the 'hostname' in code-to-token requests? I don't
> > quite get what that would do.
> Hostname where application is logged and sticky session is established,
> so keycloak knows to which host to send out-of-bound logout request.
> 
> In details:
> - User logs to product-portal and session "httpSession1" is established
> on node1
> - Now he send logout request to keycloak. Keycloak will then send
> out-of-band logout request, but it can happen that this ends on node2.
> 
> Note that this is not an issue for distributable apps. Here sessions are
> replicated so session invalidation could happen on node2 and it's
> propagated to node1 too. It's just an issue for non-distributable apps
> as session with ID "httpSession1" doesn't exist on node2, so nothing
> would be invalidated and user is still logged.
> 
> With this feature, keycloak knows to which node send invalidation
> request. Without this we would need to rely either on the logout just of
> the app, which initiated logout (no single-sign-out) or rely on browser
> redirects. Is it sufficient?

Would it not be better that Keycloak talks to the load-balancer in that case, and the LB is responsible for sending the request to the correct node. KC can send a cookie with application_state_id (or a query param) so LB knows which node to send to.

> 
> Btv. I've already worked on this yesterday and pushed it to master;-)
> >
> > I think the two options we have currently is sufficient, if properly
> > document:
> >
> > a) Logout doesn't happen until access token expires (default)
> > b) Access token is always refreshed (make sure we document the potential
> > performance hit)
> >
> > As an optimization I think we should do is that we should add a cookie that
> > is invalidated when a user logs-out. The cookie would only be invalidated
> > for the application driving the logout (retrieves the 'final' logout
> > redirect) or for applications using the coming crazy logout redirect loop.
> > My reasoning is that I think a) is sufficient for single-sign out, but if
> > a user logs-out through a specific application at least that application
> > should show a logged out state straight away.
> yep, so that's https://issues.jboss.org/browse/KEYCLOAK-702 right? And
> the cookie will be used just for apps, which don't want to have
> httpSession, correct? As for other apps, there is already cookie
> JSESSIONID, so there is no need to have another cookie imo?
> >
> >> - Is it ok to have parameter like "http_session_id" or should it be
> >> instead something more generic like "adapter_session_id" ? I am not sure
> >> if 'Http Session' is not JEE specific term? I looked at OpenID connect
> >> and there is no something like this mentioned (In fact OpenID Connect
> >> doesn't handle single-sign-out)
> > I don't think there's nothing JEE specific about a http session, but it
> > leaves some confusion to which session. What about
> > 'application_session_state'?
> yup, I think it's better. Will update it.
> >
> >> - Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
> >> for storing token in cookie instead of HttpSession) or is it ok to leave
> >> it for later? Note that for logout it will require
> >> 'always-refresh-token' or "hostname" stuff I mentioned above.
> > I think we should add it now, see my comment above (only the driving app
> > has to be logged-out immediately IMO).
> >
> >> thoughts?
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From stian at redhat.com  Fri Oct 10 07:41:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Oct 2014 07:41:34 -0400 (EDT)
Subject: [keycloak-dev] important changes/additions
In-Reply-To: <54370E2F.8080108@redhat.com>
References: <54370E2F.8080108@redhat.com>
Message-ID: <1900682247.65729114.1412941294118.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 October, 2014 12:37:35 AM
> Subject: [keycloak-dev] important changes/additions
> 
> Some recent changes in my last commit.
> 
> * Just changed the admin console to use ids instead of names for
> applications in URLs because of the Angular encoding bug.  I will do
> this for oauth clients tomorrow.
> * Admin REST API is backwards compatible, but I added an additional
> parallel path where appropriate so that REST queries can use app ids
> instead of names.  I will be doing the same for oauth clients too.
> * I added attributes to ClientModel as well as a new protocol property.
>   There's some extra metadata that SAML needs to store.  Flags and
> client keypairs.

Oki - I'll update the DB migration. 

Two questions: 

* Will OpenID connect work for existing clients with protocol=null and empty attributes?
* Any more changes coming to the model?

> 
> 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 ken at kenfinnigan.me  Fri Oct 10 08:12:13 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Fri, 10 Oct 2014 08:12:13 -0400
Subject: [keycloak-dev] Creating Users with no Email Address
In-Reply-To: <54378379.1060204@redhat.com>
References: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>
	<54378379.1060204@redhat.com>
Message-ID: <CAKeeVe6k+T7rsiMOV-gZE=S10rNUVOoo9E+sNuCAA1mDpxNdDQ@mail.gmail.com>

Marek,

Thanks for the prompt response.

I checked this morning and LO is not sending an email on the payload if one
hasn't been set.

I tried creating the users directly in the Keycloak console and had the
same issue.

I'll upgrade to 1.0.2.Final and see if that fixes it.

Thanks
Ken

On Fri, Oct 10, 2014 at 2:58 AM, Marek Posolda <mposolda at redhat.com> wrote:

>  Hi,
>
> That's strange. It works for me with latest keycloak master. I've created
> 2 users in kc admin console with empty email and both are saved (I am using
> mongo model like liveoak does). Only added related thing in 1.0.1.Final is
> https://issues.jboss.org/browse/KEYCLOAK-676, which disallow users to
> register with invalid email. But that's just added validation in
> registration forms and account mgmt - no changes in admin console or model.
>
> I wonder if it can't be "null vs. empty string" issue? KC admin console
> doesn't send email attribute at all when you don't fill email. I suspect
> that you're creating users in liveoak admin console? Isn't it possible that
> liveoak is sending email with empty string when it's not filled?
>
> Marek
>
>
>
> On 10.10.2014 01:56, Ken Finnigan wrote:
>
> Hi,
>
>  It used to be possible to create multiple users with no email address.
>
>  With 1.0.1.Final, and maybe earlier versions, it's no longer possible.
> As soon as a user is created with no email address set, any other user
> created is not able to not have an email address.
>
>  The Keycloak Admin console doesn't specify email address as a required
> field, so I was wondering whether this is a bug, and whether it's a bug in
> the UI or the model?
>
>  No problems in creating a JIRA, wanted to verify I wasn't mistaken with
> what's happening.
>
>  Thanks
> Ken Finnigan
>
>
> _______________________________________________
> 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/20141010/53374099/attachment.html 

From stian at redhat.com  Fri Oct 10 08:24:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Oct 2014 08:24:26 -0400 (EDT)
Subject: [keycloak-dev] Creating Users with no Email Address
In-Reply-To: <CAKeeVe6k+T7rsiMOV-gZE=S10rNUVOoo9E+sNuCAA1mDpxNdDQ@mail.gmail.com>
References: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>
	<54378379.1060204@redhat.com>
	<CAKeeVe6k+T7rsiMOV-gZE=S10rNUVOoo9E+sNuCAA1mDpxNdDQ@mail.gmail.com>
Message-ID: <1564626202.65750280.1412943866415.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Ken Finnigan" <ken at kenfinnigan.me>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 10 October, 2014 2:12:13 PM
> Subject: Re: [keycloak-dev] Creating Users with no Email Address
> 
> Marek,
> 
> Thanks for the prompt response.
> 
> I checked this morning and LO is not sending an email on the payload if one
> hasn't been set.
> 
> I tried creating the users directly in the Keycloak console and had the same
> issue.
> 
> I'll upgrade to 1.0.2.Final and see if that fixes it.

There's no related fixes in 1.0.2.Final.

Can you try the steps on vanilla-KC? If it still fails there can you list the exact steps you take to make it fail?

> 
> Thanks
> Ken
> 
> On Fri, Oct 10, 2014 at 2:58 AM, Marek Posolda < mposolda at redhat.com > wrote:
> 
> 
> 
> Hi,
> 
> That's strange. It works for me with latest keycloak master. I've created 2
> users in kc admin console with empty email and both are saved (I am using
> mongo model like liveoak does). Only added related thing in 1.0.1.Final is
> https://issues.jboss.org/browse/KEYCLOAK-676 , which disallow users to
> register with invalid email. But that's just added validation in
> registration forms and account mgmt - no changes in admin console or model.
> 
> I wonder if it can't be "null vs. empty string" issue? KC admin console
> doesn't send email attribute at all when you don't fill email. I suspect
> that you're creating users in liveoak admin console? Isn't it possible that
> liveoak is sending email with empty string when it's not filled?
> 
> Marek
> 
> 
> 
> On 10.10.2014 01:56, Ken Finnigan wrote:
> 
> 
> 
> Hi,
> 
> It used to be possible to create multiple users with no email address.
> 
> With 1.0.1.Final, and maybe earlier versions, it's no longer possible. As
> soon as a user is created with no email address set, any other user created
> is not able to not have an email address.
> 
> The Keycloak Admin console doesn't specify email address as a required field,
> so I was wondering whether this is a bug, and whether it's a bug in the UI
> or the model?
> 
> No problems in creating a JIRA, wanted to verify I wasn't mistaken with
> what's happening.
> 
> Thanks
> Ken Finnigan
> 
> 
> _______________________________________________
> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Fri Oct 10 08:38:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Oct 2014 08:38:03 -0400
Subject: [keycloak-dev] important changes/additions
In-Reply-To: <1900682247.65729114.1412941294118.JavaMail.zimbra@redhat.com>
References: <54370E2F.8080108@redhat.com>
	<1900682247.65729114.1412941294118.JavaMail.zimbra@redhat.com>
Message-ID: <5437D32B.8060209@redhat.com>



On 10/10/2014 7:41 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 10 October, 2014 12:37:35 AM
>> Subject: [keycloak-dev] important changes/additions
>>
>> Some recent changes in my last commit.
>>
>> * Just changed the admin console to use ids instead of names for
>> applications in URLs because of the Angular encoding bug.  I will do
>> this for oauth clients tomorrow.
>> * Admin REST API is backwards compatible, but I added an additional
>> parallel path where appropriate so that REST queries can use app ids
>> instead of names.  I will be doing the same for oauth clients too.
>> * I added attributes to ClientModel as well as a new protocol property.
>>    There's some extra metadata that SAML needs to store.  Flags and
>> client keypairs.
>
> Oki - I'll update the DB migration.
>
> Two questions:
>
> * Will OpenID connect work for existing clients with protocol=null and empty attributes?
> * Any more changes coming to the model?
>
There's really 2 protocol attributes.  One is part of ClientModel, the 
other is part of ClientSessionModel.  ClientModel.protocol is currently 
only used by the admin console to know whether to hide or show certain 
menus/config input.  ClientSessionModel has a LOGIN_PROTOCOL attribute 
set to either SAML or OIDC depending on how the client tries to log in.

I'll make sure that protocol=null won't break the admin console.

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

From ken at kenfinnigan.me  Fri Oct 10 10:15:54 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Fri, 10 Oct 2014 10:15:54 -0400
Subject: [keycloak-dev] Creating Users with no Email Address
In-Reply-To: <1564626202.65750280.1412943866415.JavaMail.zimbra@redhat.com>
References: <CAKeeVe6eBqM=edEqzOr4TCyv9pgUdqht-K3UvHhb25N5p=mPrQ@mail.gmail.com>
	<54378379.1060204@redhat.com>
	<CAKeeVe6k+T7rsiMOV-gZE=S10rNUVOoo9E+sNuCAA1mDpxNdDQ@mail.gmail.com>
	<1564626202.65750280.1412943866415.JavaMail.zimbra@redhat.com>
Message-ID: <CAKeeVe5BuTdsRX-S0Q6COcVGjq+F_ZFWz9pmXsud6yfLKNoXug@mail.gmail.com>

Updating to 1.0.2.Final resolved the issue.

Thanks for the help!

On Fri, Oct 10, 2014 at 8:24 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Ken Finnigan" <ken at kenfinnigan.me>
> > To: "Marek Posolda" <mposolda at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 10 October, 2014 2:12:13 PM
> > Subject: Re: [keycloak-dev] Creating Users with no Email Address
> >
> > Marek,
> >
> > Thanks for the prompt response.
> >
> > I checked this morning and LO is not sending an email on the payload if
> one
> > hasn't been set.
> >
> > I tried creating the users directly in the Keycloak console and had the
> same
> > issue.
> >
> > I'll upgrade to 1.0.2.Final and see if that fixes it.
>
> There's no related fixes in 1.0.2.Final.
>
> Can you try the steps on vanilla-KC? If it still fails there can you list
> the exact steps you take to make it fail?
>
> >
> > Thanks
> > Ken
> >
> > On Fri, Oct 10, 2014 at 2:58 AM, Marek Posolda < mposolda at redhat.com >
> wrote:
> >
> >
> >
> > Hi,
> >
> > That's strange. It works for me with latest keycloak master. I've
> created 2
> > users in kc admin console with empty email and both are saved (I am using
> > mongo model like liveoak does). Only added related thing in 1.0.1.Final
> is
> > https://issues.jboss.org/browse/KEYCLOAK-676 , which disallow users to
> > register with invalid email. But that's just added validation in
> > registration forms and account mgmt - no changes in admin console or
> model.
> >
> > I wonder if it can't be "null vs. empty string" issue? KC admin console
> > doesn't send email attribute at all when you don't fill email. I suspect
> > that you're creating users in liveoak admin console? Isn't it possible
> that
> > liveoak is sending email with empty string when it's not filled?
> >
> > Marek
> >
> >
> >
> > On 10.10.2014 01:56, Ken Finnigan wrote:
> >
> >
> >
> > Hi,
> >
> > It used to be possible to create multiple users with no email address.
> >
> > With 1.0.1.Final, and maybe earlier versions, it's no longer possible. As
> > soon as a user is created with no email address set, any other user
> created
> > is not able to not have an email address.
> >
> > The Keycloak Admin console doesn't specify email address as a required
> field,
> > so I was wondering whether this is a bug, and whether it's a bug in the
> UI
> > or the model?
> >
> > No problems in creating a JIRA, wanted to verify I wasn't mistaken with
> > what's happening.
> >
> > Thanks
> > Ken Finnigan
> >
> >
> > _______________________________________________
> > 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/20141010/d645e966/attachment.html 

From mposolda at redhat.com  Fri Oct 10 11:07:47 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Oct 2014 17:07:47 +0200
Subject: [keycloak-dev] Is it ok to support multiple managementUrls per
	application?
Message-ID: <5437F643.5010803@redhat.com>

The problem I am looking at is sending "Push NotBefore" from keycloak to 
adapters in cluster. Basically the info about push notBefore should be 
propagated to all cluster nodes where application is deployed.

ATM I am seeing 2 possibilities:

a) More managementUrls per ApplicationModel. People would need to 
configure all nodes where adapter is deployed . Then Keycloak ( 
ResourceAdminManager ) will be able to send "global" events like 
pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will 
be sent just to single node like now .

b) Ensure that notBefore can be replicated on adapters side. I don't 
like this tbh. It requires adapters to be in replicated cluster, which 
may not be an option for many deployments, who want to rely just on 
sticky session.

Any of those is not super-ideal, but I don't have better idea to ensure 
cluster-safe propagation of NotBefore and global logout to all cluster 
nodes.

Better ideas?

I have (b) already prototyped and working, but wanted to have ack from 
you before go further, cleanup, start changing admin console etc.

Marek

From mposolda at redhat.com  Fri Oct 10 11:08:44 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Oct 2014 17:08:44 +0200
Subject: [keycloak-dev] Is it ok to support multiple managementUrls per
	application?
In-Reply-To: <5437F643.5010803@redhat.com>
References: <5437F643.5010803@redhat.com>
Message-ID: <5437F67C.1060604@redhat.com>

On 10.10.2014 17:07, Marek Posolda wrote:
> The problem I am looking at is sending "Push NotBefore" from keycloak 
> to adapters in cluster. Basically the info about push notBefore should 
> be propagated to all cluster nodes where application is deployed.
>
> ATM I am seeing 2 possibilities:
>
> a) More managementUrls per ApplicationModel. People would need to 
> configure all nodes where adapter is deployed . Then Keycloak ( 
> ResourceAdminManager ) will be able to send "global" events like 
> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will 
> be sent just to single node like now .
>
> b) Ensure that notBefore can be replicated on adapters side. I don't 
> like this tbh. It requires adapters to be in replicated cluster, which 
> may not be an option for many deployments, who want to rely just on 
> sticky session.
>
> Any of those is not super-ideal, but I don't have better idea to 
> ensure cluster-safe propagation of NotBefore and global logout to all 
> cluster nodes.
>
> Better ideas?
>
> I have (b) already prototyped and working, but wanted to have ack from 
> you before go further, cleanup, start changing admin console etc.
oops, sorry. I have (a) working (model change to support multiple 
managementUrls)
>
> Marek


From mposolda at redhat.com  Fri Oct 10 11:30:20 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 10 Oct 2014 17:30:20 +0200
Subject: [keycloak-dev] Stateless session management pushed
In-Reply-To: <2124220188.65663067.1412939607014.JavaMail.zimbra@redhat.com>
References: <5435B45F.1040304@redhat.com>
	<1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>
	<5437BE05.9050204@redhat.com>
	<2124220188.65663067.1412939607014.JavaMail.zimbra@redhat.com>
Message-ID: <5437FB8C.4060408@redhat.com>

On 10.10.2014 13:13, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 10 October, 2014 1:07:49 PM
>> Subject: Re: [keycloak-dev] Stateless session management pushed
>>
>> On 10.10.2014 11:03, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 9 October, 2014 12:02:07 AM
>>>> Subject: [keycloak-dev] Stateless session management pushed
>>>>
>>>> Some summary of my changes:
>>>>
>>>> - Added new parameter "http_session_id" to code-to-token request. It's
>>>> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
>>>> saved as note in ClientSessionModel.
>>>>
>>>> - ResourceAdminManager refactored to use the IDs of httpSession, which
>>>> are retrieved from ClientSessions. Removed username and
>>>> keycloakSessionId from LogoutAction
>>>>
>>>> - Adapter statistics removed and everything related to them.
>>>>
>>>> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
>>>> stateless.
>>>>
>>>> - Added new config option to adapters 'always-refresh-token' as we
>>>> discussed. If it's true, then adapter will always send request to
>>>> refresh accessToken during authentication (doesn't apply for bearer
>>>> authentication, just for cookie). In the end I've used this approach
>>>> instead of validating accessToken . It seems to be safer (no window) and
>>>> you are always fine with 1 additional request. This option is useful in
>>>> cluster in case that you have non-distributable sessions. With
>>>> non-distributable it could happen that your user logged on node1, but
>>>> logout request from KC is handled on node2 where httpSession doesn't
>>>> exist. This is no issue with "distributable" sessions as those are
>>>> replicated and hence logout can happen on any node.
>>>>
>>>> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
>>>> fails from adapters, then httpSession is invalidated immediatelly
>>>>
>>>> So clustering on adapters side works well now for both Wildfly & EAP 6.3
>>>>
>>>>
>>>> Questions & remaining work:
>>>>
>>>> - I am not so happy with logout for apps with non-distributable HTTP
>>>> sessions. It can be handled with 'always-refresh-token' but it's
>>>> performance penalty to always refresh token. The alternative might be to
>>>> send also hostname in code-to-token request. This would help as
>>>> ResourceAdminManager will be able to detect to which node send request
>>>> for invalidate http session. Does it worth adding it?
>>> Can you elaborate on the 'hostname' in code-to-token requests? I don't
>>> quite get what that would do.
>> Hostname where application is logged and sticky session is established,
>> so keycloak knows to which host to send out-of-bound logout request.
>>
>> In details:
>> - User logs to product-portal and session "httpSession1" is established
>> on node1
>> - Now he send logout request to keycloak. Keycloak will then send
>> out-of-band logout request, but it can happen that this ends on node2.
>>
>> Note that this is not an issue for distributable apps. Here sessions are
>> replicated so session invalidation could happen on node2 and it's
>> propagated to node1 too. It's just an issue for non-distributable apps
>> as session with ID "httpSession1" doesn't exist on node2, so nothing
>> would be invalidated and user is still logged.
>>
>> With this feature, keycloak knows to which node send invalidation
>> request. Without this we would need to rely either on the logout just of
>> the app, which initiated logout (no single-sign-out) or rely on browser
>> redirects. Is it sufficient?
> Would it not be better that Keycloak talks to the load-balancer in that case, and the LB is responsible for sending the request to the correct node. KC can send a cookie with application_state_id (or a query param) so LB knows which node to send to.
I am not convinced that going through LB is a way to go.
- You need 2 hops - from KC to loadbalancer and then LB to app. This is 
usually unecessary imo.

- I am not sure there is some generic way how to pass sessionId via 
loadbalancer. For LB I know (mod_cluster, mod_jk) you can pass it via 
"jsessionid" parameter, but is this not something JEE specific? Will it 
work for other application types, like non-java apps?

- For Undertow, sessionId actually sent to Keycloak contains just ID 
(not the node identifier) - should be likely possible to solve though...

- Small disadvantage is, that cluster node with KC itself may be on 
private network with some firewall and limited access. And it may not 
itself know the host with LB. For example user is accessing KC 
loadbalancer under URL: "http://www.frontend-auth-server.com/auth" and 
this host may not be known to the cluster node itself (not sure if it's 
really an issue for real environments or not. Actually I have issues 
with this on docker setup ;-)

Marek
>
>> Btv. I've already worked on this yesterday and pushed it to master;-)
>>> I think the two options we have currently is sufficient, if properly
>>> document:
>>>
>>> a) Logout doesn't happen until access token expires (default)
>>> b) Access token is always refreshed (make sure we document the potential
>>> performance hit)
>>>
>>> As an optimization I think we should do is that we should add a cookie that
>>> is invalidated when a user logs-out. The cookie would only be invalidated
>>> for the application driving the logout (retrieves the 'final' logout
>>> redirect) or for applications using the coming crazy logout redirect loop.
>>> My reasoning is that I think a) is sufficient for single-sign out, but if
>>> a user logs-out through a specific application at least that application
>>> should show a logged out state straight away.
>> yep, so that's https://issues.jboss.org/browse/KEYCLOAK-702 right? And
>> the cookie will be used just for apps, which don't want to have
>> httpSession, correct? As for other apps, there is already cookie
>> JSESSIONID, so there is no need to have another cookie imo?
>>>> - Is it ok to have parameter like "http_session_id" or should it be
>>>> instead something more generic like "adapter_session_id" ? I am not sure
>>>> if 'Http Session' is not JEE specific term? I looked at OpenID connect
>>>> and there is no something like this mentioned (In fact OpenID Connect
>>>> doesn't handle single-sign-out)
>>> I don't think there's nothing JEE specific about a http session, but it
>>> leaves some confusion to which session. What about
>>> 'application_session_state'?
>> yup, I think it's better. Will update it.
>>>> - Should we add https://issues.jboss.org/browse/KEYCLOAK-702 (Support
>>>> for storing token in cookie instead of HttpSession) or is it ok to leave
>>>> it for later? Note that for logout it will require
>>>> 'always-refresh-token' or "hostname" stuff I mentioned above.
>>> I think we should add it now, see my comment above (only the driving app
>>> has to be logged-out immediately IMO).
>>>
>>>> thoughts?
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From bburke at redhat.com  Fri Oct 10 13:24:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Oct 2014 13:24:46 -0400
Subject: [keycloak-dev] Stateless session management pushed
In-Reply-To: <5437FB8C.4060408@redhat.com>
References: <5435B45F.1040304@redhat.com>	<1860525831.65510337.1412931780189.JavaMail.zimbra@redhat.com>	<5437BE05.9050204@redhat.com>	<2124220188.65663067.1412939607014.JavaMail.zimbra@redhat.com>
	<5437FB8C.4060408@redhat.com>
Message-ID: <5438165E.1050009@redhat.com>



On 10/10/2014 11:30 AM, Marek Posolda wrote:
> On 10.10.2014 13:13, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 10 October, 2014 1:07:49 PM
>>> Subject: Re: [keycloak-dev] Stateless session management pushed
>>>
>>> On 10.10.2014 11:03, Stian Thorgersen wrote:
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 9 October, 2014 12:02:07 AM
>>>>> Subject: [keycloak-dev] Stateless session management pushed
>>>>>
>>>>> Some summary of my changes:
>>>>>
>>>>> - Added new parameter "http_session_id" to code-to-token request. It's
>>>>> not mandatory and used just for AS7/Wildfly adapters. In Keycloak, it's
>>>>> saved as note in ClientSessionModel.
>>>>>
>>>>> - ResourceAdminManager refactored to use the IDs of httpSession, which
>>>>> are retrieved from ClientSessions. Removed username and
>>>>> keycloakSessionId from LogoutAction
>>>>>
>>>>> - Adapter statistics removed and everything related to them.
>>>>>
>>>>> - UndertowUserSessionManagement and CatalinaUserManagement are now fully
>>>>> stateless.
>>>>>
>>>>> - Added new config option to adapters 'always-refresh-token' as we
>>>>> discussed. If it's true, then adapter will always send request to
>>>>> refresh accessToken during authentication (doesn't apply for bearer
>>>>> authentication, just for cookie). In the end I've used this approach
>>>>> instead of validating accessToken . It seems to be safer (no window) and
>>>>> you are always fine with 1 additional request. This option is useful in
>>>>> cluster in case that you have non-distributable sessions. With
>>>>> non-distributable it could happen that your user logged on node1, but
>>>>> logout request from KC is handled on node2 where httpSession doesn't
>>>>> exist. This is no issue with "distributable" sessions as those are
>>>>> replicated and hence logout can happen on any node.
>>>>>
>>>>> - https://issues.jboss.org/browse/KEYCLOAK-741 -- If refreshing token
>>>>> fails from adapters, then httpSession is invalidated immediatelly
>>>>>
>>>>> So clustering on adapters side works well now for both Wildfly & EAP 6.3
>>>>>
>>>>>
>>>>> Questions & remaining work:
>>>>>
>>>>> - I am not so happy with logout for apps with non-distributable HTTP
>>>>> sessions. It can be handled with 'always-refresh-token' but it's
>>>>> performance penalty to always refresh token. The alternative might be to
>>>>> send also hostname in code-to-token request. This would help as
>>>>> ResourceAdminManager will be able to detect to which node send request
>>>>> for invalidate http session. Does it worth adding it?
>>>> Can you elaborate on the 'hostname' in code-to-token requests? I don't
>>>> quite get what that would do.
>>> Hostname where application is logged and sticky session is established,
>>> so keycloak knows to which host to send out-of-bound logout request.
>>>
>>> In details:
>>> - User logs to product-portal and session "httpSession1" is established
>>> on node1
>>> - Now he send logout request to keycloak. Keycloak will then send
>>> out-of-band logout request, but it can happen that this ends on node2.
>>>
>>> Note that this is not an issue for distributable apps. Here sessions are
>>> replicated so session invalidation could happen on node2 and it's
>>> propagated to node1 too. It's just an issue for non-distributable apps
>>> as session with ID "httpSession1" doesn't exist on node2, so nothing
>>> would be invalidated and user is still logged.
>>>
>>> With this feature, keycloak knows to which node send invalidation
>>> request. Without this we would need to rely either on the logout just of
>>> the app, which initiated logout (no single-sign-out) or rely on browser
>>> redirects. Is it sufficient?
>> Would it not be better that Keycloak talks to the load-balancer in that case, and the LB is responsible for sending the request to the correct node. KC can send a cookie with application_state_id (or a query param) so LB knows which node to send to.
> I am not convinced that going through LB is a way to go.
> - You need 2 hops - from KC to loadbalancer and then LB to app. This is
> usually unecessary imo.
>

+1 to adding multiple admin urls.  It's trivial to add right?  Probably 
won't need more than one, but it will be good to have just in case.



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

From stian at redhat.com  Mon Oct 13 02:42:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 02:42:01 -0400 (EDT)
Subject: [keycloak-dev] Revert changing from Google Authenticator to FreeOTP
In-Reply-To: <1687408557.66578324.1413182194768.JavaMail.zimbra@redhat.com>
Message-ID: <700619097.66579265.1413182521146.JavaMail.zimbra@redhat.com>

I'm not a big fan of the recent change from Google Authenticator to FreeOTP.

* Google Authenticator is far more widely used than FreeOTP
* We have existing users that use Google Authenticator (we know it works for both, but they and their users don't)

To support FreeOTP we need to add support for multiple OTP providers so developers/users themselves can choose between the providers, not us.

From stian at redhat.com  Mon Oct 13 03:23:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 03:23:34 -0400 (EDT)
Subject: [keycloak-dev] Authentication SPI
In-Reply-To: <1977687603.66597360.1413184320459.JavaMail.zimbra@redhat.com>
Message-ID: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>

We should consider adding an Authentication SPI. This would be something similar to what we used to have, but should be more flexible (for example allow redirect to other IdPs).

This could be used for:

* Kerberos bridge
* Authenticate with external IdP (SAML or OpenID Connect)
* Add custom authentication providers
* Additional authentication mechanisms (fingerprint, hardware keys, etc.)

Same SPI could also be used for custom multi-factor authenticators. As well as for authenticating non-human users (cert, jwt, etc.).

A realm should be able to have more than one authentication mechanism. For example by default users authenticate with username/password (through the user store), but all users with a specific email domain authenticate with an external IdP. At the same time a user could have one or more main authenticators (password, hardware devices, etc.) and one or more secondary authenticators (totp, hardware token, etc.).

Certainly needs a lot more thinking/design, but if it's something we're interested in I'd like to look at it.

From stian at redhat.com  Mon Oct 13 03:59:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 03:59:26 -0400 (EDT)
Subject: [keycloak-dev] Is it ok to support multiple managementUrls
	per	application?
In-Reply-To: <5437F67C.1060604@redhat.com>
References: <5437F643.5010803@redhat.com> <5437F67C.1060604@redhat.com>
Message-ID: <1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>

Adding multiple management URLs to an application is going to be cumbersome to maintain. It would require manually registering/unregistering nodes with Keycloak.

WildFly for example automatically detects cluster members, and add/removes nodes to Apache. Introducing KC would then add a cumbersome manual registration process. Even worse with automatic provisioning of nodes it simply won't work (think cloud).

Another issue is that we'd have to deal with making sure new nodes and temporarily unavailable nodes retrieve the updates as well. We probably need to improve on this in either case, a single node can also be temporarily unavailable (and miss notBefore or logout notifications), but doing it for a cluster is harder than for a single node.

There's also the use-case when KC and applications are on different subnets where only the load balancer is visible to Keycloak.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 October, 2014 5:08:44 PM
> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls per	application?
> 
> On 10.10.2014 17:07, Marek Posolda wrote:
> > The problem I am looking at is sending "Push NotBefore" from keycloak
> > to adapters in cluster. Basically the info about push notBefore should
> > be propagated to all cluster nodes where application is deployed.
> >
> > ATM I am seeing 2 possibilities:
> >
> > a) More managementUrls per ApplicationModel. People would need to
> > configure all nodes where adapter is deployed . Then Keycloak (
> > ResourceAdminManager ) will be able to send "global" events like
> > pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
> > be sent just to single node like now .
> >
> > b) Ensure that notBefore can be replicated on adapters side. I don't
> > like this tbh. It requires adapters to be in replicated cluster, which
> > may not be an option for many deployments, who want to rely just on
> > sticky session.
> >
> > Any of those is not super-ideal, but I don't have better idea to
> > ensure cluster-safe propagation of NotBefore and global logout to all
> > cluster nodes.
> >
> > Better ideas?
> >
> > I have (b) already prototyped and working, but wanted to have ack from
> > you before go further, cleanup, start changing admin console etc.
> oops, sorry. I have (a) working (model change to support multiple
> managementUrls)
> >
> > Marek
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Oct 13 10:32:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Oct 2014 10:32:05 -0400
Subject: [keycloak-dev] Revert changing from Google Authenticator to
	FreeOTP
In-Reply-To: <700619097.66579265.1413182521146.JavaMail.zimbra@redhat.com>
References: <700619097.66579265.1413182521146.JavaMail.zimbra@redhat.com>
Message-ID: <543BE265.5040700@redhat.com>

Why not just change the pages to link to Google Authenticator *AND* 
FreeOTP?

I don't understand what you mean by  we need to add support for multiple 
OTP providers.  Google Authenticator and FreeOTP both already work with 
what we currently have.

On 10/13/2014 2:42 AM, Stian Thorgersen wrote:
> I'm not a big fan of the recent change from Google Authenticator to FreeOTP.
>
> * Google Authenticator is far more widely used than FreeOTP
> * We have existing users that use Google Authenticator (we know it works for both, but they and their users don't)
>
> To support FreeOTP we need to add support for multiple OTP providers so developers/users themselves can choose between the providers, not us.
> _______________________________________________
> 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 Oct 13 10:37:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Oct 2014 10:37:34 -0400
Subject: [keycloak-dev] Authentication SPI
In-Reply-To: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>
References: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>
Message-ID: <543BE3AE.3060604@redhat.com>

We should discuss whether we need to reshuffle our prioritization. 
Also, personally, I don't want to be stuck with all the integration work 
we have to do with Tomcat, Jetty, BRMS, etc. :)

On 10/13/2014 3:23 AM, Stian Thorgersen wrote:
> We should consider adding an Authentication SPI. This would be something similar to what we used to have, but should be more flexible (for example allow redirect to other IdPs).
>
> This could be used for:
>
> * Kerberos bridge
> * Authenticate with external IdP (SAML or OpenID Connect)
> * Add custom authentication providers
> * Additional authentication mechanisms (fingerprint, hardware keys, etc.)
>
> Same SPI could also be used for custom multi-factor authenticators. As well as for authenticating non-human users (cert, jwt, etc.).
>
> A realm should be able to have more than one authentication mechanism. For example by default users authenticate with username/password (through the user store), but all users with a specific email domain authenticate with an external IdP. At the same time a user could have one or more main authenticators (password, hardware devices, etc.) and one or more secondary authenticators (totp, hardware token, etc.).
>
> Certainly needs a lot more thinking/design, but if it's something we're interested in I'd like to look at it.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Mon Oct 13 13:18:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 13:18:24 -0400 (EDT)
Subject: [keycloak-dev] Revert changing from Google Authenticator
	to	FreeOTP
In-Reply-To: <543BE265.5040700@redhat.com>
References: <700619097.66579265.1413182521146.JavaMail.zimbra@redhat.com>
	<543BE265.5040700@redhat.com>
Message-ID: <391112744.67213508.1413220704423.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 October, 2014 4:32:05 PM
> Subject: Re: [keycloak-dev] Revert changing from Google Authenticator to	FreeOTP
> 
> Why not just change the pages to link to Google Authenticator *AND*
> FreeOTP?

That's a decent compromise. I just don't want existing developers and their users to believe Google Authenticator support is gone.

> 
> I don't understand what you mean by  we need to add support for multiple
> OTP providers.  Google Authenticator and FreeOTP both already work with
> what we currently have.

The protocol is the same, but configuration instructions for users are different.

I think we should have a multi-factor authenticator SPI (or just baked it into the authenticator SPI I mentioned before) for this. As well as be able to authenticate it needs to be able to modify the login-totp form and configuration instructions. I think it should be possible to configure what multi-factor authenticators should be available for a realm. Then if there is more than one option users can first select which one they want to use, before being given instructions on how to install and configure the specific mechanism.

This SPI would also allow using other things that the standard OTP protocol. For example SMS/email, hardware tokens (i.e. Yubikey). Have a look at http://vimeo.com/72978755 it's pretty cool.

> 
> On 10/13/2014 2:42 AM, Stian Thorgersen wrote:
> > I'm not a big fan of the recent change from Google Authenticator to
> > FreeOTP.
> >
> > * Google Authenticator is far more widely used than FreeOTP
> > * We have existing users that use Google Authenticator (we know it works
> > for both, but they and their users don't)
> >
> > To support FreeOTP we need to add support for multiple OTP providers so
> > developers/users themselves can choose between the providers, not us.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Oct 13 13:23:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 13:23:39 -0400 (EDT)
Subject: [keycloak-dev] Authentication SPI
In-Reply-To: <543BE3AE.3060604@redhat.com>
References: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>
	<543BE3AE.3060604@redhat.com>
Message-ID: <659245832.67216797.1413221019820.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 October, 2014 4:37:34 PM
> Subject: Re: [keycloak-dev] Authentication SPI
> 
> We should discuss whether we need to reshuffle our prioritization.
> Also, personally, I don't want to be stuck with all the integration work
> we have to do with Tomcat, Jetty, BRMS, etc. :)

Fair enough, I reckon one adapter each this time around then let's take a break? Highest priority should be what's needed for xPaaS I think (so UberFire, BMRS, Fuse, Fuse Fabric, etc.). 

I was still going to do adapter(s), but look at design/architecture for this at the same time. I reckon a properly designed Authenticator SPI could let us do federation (openid connect, saml, kerberos, etc.), password-less logins (fingerprint) and more multi-factor (sms, email, hardware tokens). It should also allow us to be future proof whenever there's new authentication mechanisms (for example why can't a browser prove your identity? that could give you sso to everything web!).

> 
> On 10/13/2014 3:23 AM, Stian Thorgersen wrote:
> > We should consider adding an Authentication SPI. This would be something
> > similar to what we used to have, but should be more flexible (for example
> > allow redirect to other IdPs).
> >
> > This could be used for:
> >
> > * Kerberos bridge
> > * Authenticate with external IdP (SAML or OpenID Connect)
> > * Add custom authentication providers
> > * Additional authentication mechanisms (fingerprint, hardware keys, etc.)
> >
> > Same SPI could also be used for custom multi-factor authenticators. As well
> > as for authenticating non-human users (cert, jwt, etc.).
> >
> > A realm should be able to have more than one authentication mechanism. For
> > example by default users authenticate with username/password (through the
> > user store), but all users with a specific email domain authenticate with
> > an external IdP. At the same time a user could have one or more main
> > authenticators (password, hardware devices, etc.) and one or more
> > secondary authenticators (totp, hardware token, etc.).
> >
> > Certainly needs a lot more thinking/design, but if it's something we're
> > interested in I'd like to look at it.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Oct 13 13:33:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Oct 2014 13:33:53 -0400
Subject: [keycloak-dev] Authentication SPI
In-Reply-To: <659245832.67216797.1413221019820.JavaMail.zimbra@redhat.com>
References: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>
	<543BE3AE.3060604@redhat.com>
	<659245832.67216797.1413221019820.JavaMail.zimbra@redhat.com>
Message-ID: <543C0D01.8030604@redhat.com>



On 10/13/2014 1:23 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 13 October, 2014 4:37:34 PM
>> Subject: Re: [keycloak-dev] Authentication SPI
>>
>> We should discuss whether we need to reshuffle our prioritization.
>> Also, personally, I don't want to be stuck with all the integration work
>> we have to do with Tomcat, Jetty, BRMS, etc. :)
>
> Fair enough, I reckon one adapter each this time around then let's take a break? Highest priority should be what's needed for xPaaS I think (so UberFire, BMRS, Fuse, Fuse Fabric, etc.).
>

Tomcat needs to be in there too.

> I was still going to do adapter(s), but look at design/architecture for this at the same time. I reckon a properly designed Authenticator SPI could let us do federation (openid connect, saml, kerberos, etc.), password-less logins (fingerprint) and more multi-factor (sms, email, hardware tokens). It should also allow us to be future proof whenever there's new authentication mechanisms (for example why can't a browser prove your identity? that could give you sso to everything web!).
>

Not sure they all fall under the same SPI.  You got authentication via 
user input (passwords, OTP), identity brokering (SAML, OIDC, Social 
login, kerberos), authentication via non-user-input (kerberos, 
cert-auth, our auth cookie).



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

From stian at redhat.com  Mon Oct 13 13:40:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Oct 2014 13:40:11 -0400 (EDT)
Subject: [keycloak-dev] Authentication SPI
In-Reply-To: <543C0D01.8030604@redhat.com>
References: <968007173.66602325.1413185014975.JavaMail.zimbra@redhat.com>
	<543BE3AE.3060604@redhat.com>
	<659245832.67216797.1413221019820.JavaMail.zimbra@redhat.com>
	<543C0D01.8030604@redhat.com>
Message-ID: <208251668.67222817.1413222011301.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, 13 October, 2014 7:33:53 PM
> Subject: Re: [keycloak-dev] Authentication SPI
> 
> 
> 
> On 10/13/2014 1:23 PM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 13 October, 2014 4:37:34 PM
> >> Subject: Re: [keycloak-dev] Authentication SPI
> >>
> >> We should discuss whether we need to reshuffle our prioritization.
> >> Also, personally, I don't want to be stuck with all the integration work
> >> we have to do with Tomcat, Jetty, BRMS, etc. :)
> >
> > Fair enough, I reckon one adapter each this time around then let's take a
> > break? Highest priority should be what's needed for xPaaS I think (so
> > UberFire, BMRS, Fuse, Fuse Fabric, etc.).
> >
> 
> Tomcat needs to be in there too.
> 
> > I was still going to do adapter(s), but look at design/architecture for
> > this at the same time. I reckon a properly designed Authenticator SPI
> > could let us do federation (openid connect, saml, kerberos, etc.),
> > password-less logins (fingerprint) and more multi-factor (sms, email,
> > hardware tokens). It should also allow us to be future proof whenever
> > there's new authentication mechanisms (for example why can't a browser
> > prove your identity? that could give you sso to everything web!).
> >
> 
> Not sure they all fall under the same SPI.  You got authentication via
> user input (passwords, OTP), identity brokering (SAML, OIDC, Social
> login, kerberos), authentication via non-user-input (kerberos,
> cert-auth, our auth cookie).

I agree, I'm not sure if it's best to design it as one SPI with a lot of "options" or as multiple more bespoke SPIs.

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

From stian at redhat.com  Tue Oct 14 04:45:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Oct 2014 04:45:52 -0400 (EDT)
Subject: [keycloak-dev] Database migration support added
In-Reply-To: <280037938.67604999.1413276182791.JavaMail.zimbra@redhat.com>
Message-ID: <1460664598.67606510.1413276352803.JavaMail.zimbra@redhat.com>

I've added database migration support. In summary:

* JPA migration is done with Liquibase
* Mongo migration is done in a similar way, but no 3rd party lib (Mongo is easier as it's schema-less and single vendor)
* connectionsJpa and connectionsMongo will automatically update the database (if databaseSchema = update)

For more details look at https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSchema.md

If there's any issues let me know!

From stian at redhat.com  Tue Oct 14 13:49:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Oct 2014 13:49:20 -0400 (EDT)
Subject: [keycloak-dev] Is it ok to support multiple
	managementUrls	per	application?
In-Reply-To: <1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>
References: <5437F643.5010803@redhat.com> <5437F67C.1060604@redhat.com>
	<1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>
Message-ID: <1236833049.68395121.1413308960920.JavaMail.zimbra@redhat.com>

Would it be an idea to add more options on how admin events are delivered? We could for example add jgroups and jms. Either of those would be more efficient in a cluster and wouldn't require managing nodes.

----- 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, 13 October, 2014 9:59:26 AM
> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls	per	application?
> 
> Adding multiple management URLs to an application is going to be cumbersome
> to maintain. It would require manually registering/unregistering nodes with
> Keycloak.
> 
> WildFly for example automatically detects cluster members, and add/removes
> nodes to Apache. Introducing KC would then add a cumbersome manual
> registration process. Even worse with automatic provisioning of nodes it
> simply won't work (think cloud).
> 
> Another issue is that we'd have to deal with making sure new nodes and
> temporarily unavailable nodes retrieve the updates as well. We probably need
> to improve on this in either case, a single node can also be temporarily
> unavailable (and miss notBefore or logout notifications), but doing it for a
> cluster is harder than for a single node.
> 
> There's also the use-case when KC and applications are on different subnets
> where only the load balancer is visible to Keycloak.
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, 10 October, 2014 5:08:44 PM
> > Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls per
> > 	application?
> > 
> > On 10.10.2014 17:07, Marek Posolda wrote:
> > > The problem I am looking at is sending "Push NotBefore" from keycloak
> > > to adapters in cluster. Basically the info about push notBefore should
> > > be propagated to all cluster nodes where application is deployed.
> > >
> > > ATM I am seeing 2 possibilities:
> > >
> > > a) More managementUrls per ApplicationModel. People would need to
> > > configure all nodes where adapter is deployed . Then Keycloak (
> > > ResourceAdminManager ) will be able to send "global" events like
> > > pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
> > > be sent just to single node like now .
> > >
> > > b) Ensure that notBefore can be replicated on adapters side. I don't
> > > like this tbh. It requires adapters to be in replicated cluster, which
> > > may not be an option for many deployments, who want to rely just on
> > > sticky session.
> > >
> > > Any of those is not super-ideal, but I don't have better idea to
> > > ensure cluster-safe propagation of NotBefore and global logout to all
> > > cluster nodes.
> > >
> > > Better ideas?
> > >
> > > I have (b) already prototyped and working, but wanted to have ack from
> > > you before go further, cleanup, start changing admin console etc.
> > oops, sorry. I have (a) working (model change to support multiple
> > managementUrls)
> > >
> > > 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 Oct 14 19:02:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Oct 2014 19:02:58 -0400
Subject: [keycloak-dev] liquibase problems breaking my build
Message-ID: <543DABA2.3050902@redhat.com>

Can you explain this liquipoop stuff and how it effects things?  I am 
unable to build locally.  I've added a column to RealmEntity and now I'm 
getting a column not found exception on startup in the testsuite.


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

From bburke at redhat.com  Tue Oct 14 19:15:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Oct 2014 19:15:36 -0400
Subject: [keycloak-dev] liquibase problems breaking my build
In-Reply-To: <543DABA2.3050902@redhat.com>
References: <543DABA2.3050902@redhat.com>
Message-ID: <543DAE98.1060105@redhat.com>

Nevermind.  Finally found the email missed it at first.

         <delete tableName="LIQUIPOOP"/>
         <createTable tableName="LIQUICOOL">
             <column name="BILL_IS_AN_IDIOT"/>
         </createTable>


On 10/14/2014 7:02 PM, Bill Burke wrote:
> Can you explain this liquipoop stuff and how it effects things?  I am
> unable to build locally.  I've added a column to RealmEntity and now I'm
> getting a column not found exception on startup in the testsuite.
>
>

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

From stian at redhat.com  Wed Oct 15 03:39:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Oct 2014 03:39:17 -0400 (EDT)
Subject: [keycloak-dev] liquibase problems breaking my build
In-Reply-To: <543DAE98.1060105@redhat.com>
References: <543DABA2.3050902@redhat.com> <543DAE98.1060105@redhat.com>
Message-ID: <904617180.68685203.1413358757427.JavaMail.zimbra@redhat.com>

If you'd like I can do a Hangout next week to show the work-flow I had in mind. At the same time we could discuss next steps.

While working on JPA entities you can also set databaseSchema=development-update (connectionsJpa/default) this uses Hibernate instead of Liquibase.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 15 October, 2014 1:15:36 AM
> Subject: Re: [keycloak-dev] liquibase problems breaking my build
> 
> Nevermind.  Finally found the email missed it at first.
> 
>          <delete tableName="LIQUIPOOP"/>
>          <createTable tableName="LIQUICOOL">
>              <column name="BILL_IS_AN_IDIOT"/>
>          </createTable>
> 
> 
> On 10/14/2014 7:02 PM, Bill Burke wrote:
> > Can you explain this liquipoop stuff and how it effects things?  I am
> > unable to build locally.  I've added a column to RealmEntity and now I'm
> > getting a column not found exception on startup in the testsuite.
> >
> >
> 
> --
> 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  Wed Oct 15 04:22:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 15 Oct 2014 10:22:56 +0200
Subject: [keycloak-dev] Automatic sign out from admin console
Message-ID: <543E2EE0.6060103@redhat.com>

Sorry to restore the discussion about admin console timeouts, but the 
situation is still not ideal though...

Consider scenario:
- I have ssoSessionIdleTimeout 5 minutes
- Now I login to admin console and I want to create new federation provider
- I am disturbed for 5 minutes
- Now I want to go back to admin console and finish creating my 
federation provider. After filling all the values, I click "Add" button. 
But session is idle, so I am signed-out and all values I filled in admin 
console are lost.

I wonder if we can still improve things a bit to avoid this? Maybe 
restore idleTimeout plugin, but instead of having hardcoded timeout 
value, it will periodically ask Keycloak (say in 1 minutes intervals) 
for send the remaining timeout value? Also it would need to display the 
topbar warning with "you will be logged out in N seconds" in case that 
there are 2 minutes remaining, so it's visible in KC admin console for 
at least 1 minute.

It's still not super-ideal and won't handle all scenarios though (for 
example if user is going out of browser for these 5 minutes and he comes 
back, he will be just signed-out). So I am not sure if it worth an 
effort to add that?

Note that this may not be an issue just for KC admin console, but for 
other JS apps secured by keycloak too (See liveoak admin console 
https://issues.jboss.org/browse/LIVEOAK-475 )

Marek

From bgorai at cisco.com  Wed Oct 15 04:34:37 2014
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Wed, 15 Oct 2014 08:34:37 +0000
Subject: [keycloak-dev] Does Keycloak support HA?
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD055DB55D@xmb-aln-x12.cisco.com>

Hi Keycloak Dev Team,

We are planning to install multiple  Keycloak instance behind Load Balancer ,therefore wanted to check whether Keycloak supports HA. If yes, then  please let us know since which version HA support is available.
We are currently using  1.0-beta-3 with some customization.

Thanks
Bappaditya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141015/59c65956/attachment.html 

From mposolda at redhat.com  Wed Oct 15 06:17:08 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 15 Oct 2014 12:17:08 +0200
Subject: [keycloak-dev] Is it ok to support multiple managementUrls	per
 application?
In-Reply-To: <1236833049.68395121.1413308960920.JavaMail.zimbra@redhat.com>
References: <5437F643.5010803@redhat.com> <5437F67C.1060604@redhat.com>
	<1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>
	<1236833049.68395121.1413308960920.JavaMail.zimbra@redhat.com>
Message-ID: <543E49A4.6080209@redhat.com>

That's an option, but it would require that adapters would need to be 
aware of that and have support for jgroups/jms/infinispan ? Perhaps we 
can add sender/receiver SPI for that?

I know that having more managementUrls is not ideal solution and have 
many pitfalls as you mentioned:-\ However it doesn't have any further 
requirements on adapters (like being capable to receive jgroups/jms 
message). I think that many adapters might want to rely just on 
sticky-session provided by LB and don't want to have any additional 
communication among each other. So setup with more managementUrls might 
be still the best option for some deployments.

I am not sure tbh. Maybe for Beta-1 we can keep just multiple 
managementUrls and add sender/receiver SPI with possibility for 
jgroups/jms to Beta-2 ?

Marek

On 14.10.2014 19:49, Stian Thorgersen wrote:
> Would it be an idea to add more options on how admin events are delivered? We could for example add jgroups and jms. Either of those would be more efficient in a cluster and wouldn't require managing nodes.
>
> ----- 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, 13 October, 2014 9:59:26 AM
>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls	per	application?
>>
>> Adding multiple management URLs to an application is going to be cumbersome
>> to maintain. It would require manually registering/unregistering nodes with
>> Keycloak.
>>
>> WildFly for example automatically detects cluster members, and add/removes
>> nodes to Apache. Introducing KC would then add a cumbersome manual
>> registration process. Even worse with automatic provisioning of nodes it
>> simply won't work (think cloud).
>>
>> Another issue is that we'd have to deal with making sure new nodes and
>> temporarily unavailable nodes retrieve the updates as well. We probably need
>> to improve on this in either case, a single node can also be temporarily
>> unavailable (and miss notBefore or logout notifications), but doing it for a
>> cluster is harder than for a single node.
>>
>> There's also the use-case when KC and applications are on different subnets
>> where only the load balancer is visible to Keycloak.
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 10 October, 2014 5:08:44 PM
>>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls per
>>> 	application?
>>>
>>> On 10.10.2014 17:07, Marek Posolda wrote:
>>>> The problem I am looking at is sending "Push NotBefore" from keycloak
>>>> to adapters in cluster. Basically the info about push notBefore should
>>>> be propagated to all cluster nodes where application is deployed.
>>>>
>>>> ATM I am seeing 2 possibilities:
>>>>
>>>> a) More managementUrls per ApplicationModel. People would need to
>>>> configure all nodes where adapter is deployed . Then Keycloak (
>>>> ResourceAdminManager ) will be able to send "global" events like
>>>> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
>>>> be sent just to single node like now .
>>>>
>>>> b) Ensure that notBefore can be replicated on adapters side. I don't
>>>> like this tbh. It requires adapters to be in replicated cluster, which
>>>> may not be an option for many deployments, who want to rely just on
>>>> sticky session.
>>>>
>>>> Any of those is not super-ideal, but I don't have better idea to
>>>> ensure cluster-safe propagation of NotBefore and global logout to all
>>>> cluster nodes.
>>>>
>>>> Better ideas?
>>>>
>>>> I have (b) already prototyped and working, but wanted to have ack from
>>>> you before go further, cleanup, start changing admin console etc.
>>> oops, sorry. I have (a) working (model change to support multiple
>>> managementUrls)
>>>> 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  Wed Oct 15 07:23:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Oct 2014 07:23:08 -0400
Subject: [keycloak-dev] Does Keycloak support HA?
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD055DB55D@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD055DB55D@xmb-aln-x12.cisco.com>
Message-ID: <543E591C.7030901@redhat.com>

You can cluster 1.0.2, but it will not scale well as everything must 
sync via the database.  Also, client adapters don't work for single log 
out if your applications clustered and load-balanced.

For the next release 1.1.Beta1 (In a week or two?) Stian and Marek did a 
lot of clustering work.  Realm metadata is cached in Infinispan.  User 
sessions are now stored in an Infinispan data grid.  Adapters have been 
refactored so single log out works in a cluster.

On 10/15/2014 4:34 AM, Bappaditya Gorai (bgorai) wrote:
> Hi Keycloak Dev Team,
>
> We are planning to install multiple  Keycloak instance behind Load
> Balancer ,therefore wanted to check whether Keycloak supports HA. If
> yes, then  please let us know since which version HA support is available.
>
> We are currently using  1.0-beta-3 with some customization.
>
> Thanks
>
> Bappaditya
>
>
>
> _______________________________________________
> 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 Oct 15 07:29:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Oct 2014 07:29:52 -0400
Subject: [keycloak-dev] Is cluster secured?
Message-ID: <543E5AB0.2060106@redhat.com>

I can't seem to find any configuration file for infinispan caches.  Are 
they set up to be secured?

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

From stian at redhat.com  Wed Oct 15 07:36:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Oct 2014 07:36:00 -0400 (EDT)
Subject: [keycloak-dev] Is it ok to support multiple managementUrls	per
 application?
In-Reply-To: <543E49A4.6080209@redhat.com>
References: <5437F643.5010803@redhat.com> <5437F67C.1060604@redhat.com>
	<1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>
	<1236833049.68395121.1413308960920.JavaMail.zimbra@redhat.com>
	<543E49A4.6080209@redhat.com>
Message-ID: <1563526678.68885241.1413372960642.JavaMail.zimbra@redhat.com>

We need to do something better than requiring users to manually register/unregister nodes with Keycloak. That's just to clunky if you ask me.

What about adding an option where nodes self-register? Nodes could authenticate with the client credentials to be allowed to register. We could also require adapters to "re-register" after a certain amount of time so we don't end up with a bunch of dead nodes. 

There might be something already in the OpenID Connect Dynamic Registration spec for this. Worth looking at that before we do anything.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 15 October, 2014 12:17:08 PM
> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls	per application?
> 
> That's an option, but it would require that adapters would need to be
> aware of that and have support for jgroups/jms/infinispan ? Perhaps we
> can add sender/receiver SPI for that?
> 
> I know that having more managementUrls is not ideal solution and have
> many pitfalls as you mentioned:-\ However it doesn't have any further
> requirements on adapters (like being capable to receive jgroups/jms
> message). I think that many adapters might want to rely just on
> sticky-session provided by LB and don't want to have any additional
> communication among each other. So setup with more managementUrls might
> be still the best option for some deployments.
> 
> I am not sure tbh. Maybe for Beta-1 we can keep just multiple
> managementUrls and add sender/receiver SPI with possibility for
> jgroups/jms to Beta-2 ?
> 
> Marek
> 
> On 14.10.2014 19:49, Stian Thorgersen wrote:
> > Would it be an idea to add more options on how admin events are delivered?
> > We could for example add jgroups and jms. Either of those would be more
> > efficient in a cluster and wouldn't require managing nodes.
> >
> > ----- 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, 13 October, 2014 9:59:26 AM
> >> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls
> >> 	per	application?
> >>
> >> Adding multiple management URLs to an application is going to be
> >> cumbersome
> >> to maintain. It would require manually registering/unregistering nodes
> >> with
> >> Keycloak.
> >>
> >> WildFly for example automatically detects cluster members, and add/removes
> >> nodes to Apache. Introducing KC would then add a cumbersome manual
> >> registration process. Even worse with automatic provisioning of nodes it
> >> simply won't work (think cloud).
> >>
> >> Another issue is that we'd have to deal with making sure new nodes and
> >> temporarily unavailable nodes retrieve the updates as well. We probably
> >> need
> >> to improve on this in either case, a single node can also be temporarily
> >> unavailable (and miss notBefore or logout notifications), but doing it for
> >> a
> >> cluster is harder than for a single node.
> >>
> >> There's also the use-case when KC and applications are on different
> >> subnets
> >> where only the load balancer is visible to Keycloak.
> >>
> >> ----- Original Message -----
> >>> From: "Marek Posolda" <mposolda at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Friday, 10 October, 2014 5:08:44 PM
> >>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls
> >>> per
> >>> 	application?
> >>>
> >>> On 10.10.2014 17:07, Marek Posolda wrote:
> >>>> The problem I am looking at is sending "Push NotBefore" from keycloak
> >>>> to adapters in cluster. Basically the info about push notBefore should
> >>>> be propagated to all cluster nodes where application is deployed.
> >>>>
> >>>> ATM I am seeing 2 possibilities:
> >>>>
> >>>> a) More managementUrls per ApplicationModel. People would need to
> >>>> configure all nodes where adapter is deployed . Then Keycloak (
> >>>> ResourceAdminManager ) will be able to send "global" events like
> >>>> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
> >>>> be sent just to single node like now .
> >>>>
> >>>> b) Ensure that notBefore can be replicated on adapters side. I don't
> >>>> like this tbh. It requires adapters to be in replicated cluster, which
> >>>> may not be an option for many deployments, who want to rely just on
> >>>> sticky session.
> >>>>
> >>>> Any of those is not super-ideal, but I don't have better idea to
> >>>> ensure cluster-safe propagation of NotBefore and global logout to all
> >>>> cluster nodes.
> >>>>
> >>>> Better ideas?
> >>>>
> >>>> I have (b) already prototyped and working, but wanted to have ack from
> >>>> you before go further, cleanup, start changing admin console etc.
> >>> oops, sorry. I have (a) working (model change to support multiple
> >>> managementUrls)
> >>>> 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  Wed Oct 15 07:38:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Oct 2014 07:38:42 -0400 (EDT)
Subject: [keycloak-dev] Is cluster secured?
In-Reply-To: <543E5AB0.2060106@redhat.com>
References: <543E5AB0.2060106@redhat.com>
Message-ID: <2062162810.68887111.1413373122710.JavaMail.zimbra@redhat.com>

I've added a clustering section in the documentation, that describes how to configure it. JGroups can be configured to encrypt messages.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 15 October, 2014 1:29:52 PM
> Subject: [keycloak-dev] Is cluster secured?
> 
> I can't seem to find any configuration file for infinispan caches.  Are
> they set up to be secured?
> 
> --
> 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  Wed Oct 15 11:20:25 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 15 Oct 2014 17:20:25 +0200
Subject: [keycloak-dev] Refresh token expires too
Message-ID: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>

Hello Keycloak

Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are:
- renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4, 
- expirable, which is more a surprise to me. (nothing like that in oauth2 spec)

So for iOS sdk we?ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we?ll need to go through grant ptopup again.
To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired? or decode refresh token as done in key cloak.js [3]. 

Thanks @mposolda for the links.

@summers @passos: I guess it?s something you?ll need to consider too for Android sdk.

++
Corinne
??????
AeroGear iOS tech lead

[1] https://issues.jboss.org/browse/AGIOS-294
[2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth2/OAuth2Module.swift#L145
[3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L216, https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L462
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141015/74e2429d/attachment.bin 

From bburke at redhat.com  Wed Oct 15 11:35:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Oct 2014 11:35:44 -0400
Subject: [keycloak-dev] Refresh token expires too
In-Reply-To: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>
References: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>
Message-ID: <543E9450.5050707@redhat.com>

There's a few things we could do:

* Expand the public realm REST interface to include information about 
timeouts
* oauth alreayd requires that access token response json document 
contains an access token timeout, we could include the refresh tieout too.
* Then again, you could just decode the refresh token :)

On 10/15/2014 11:20 AM, Corinne Krych wrote:
> Hello Keycloak
>
> Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are:
> - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4,
> - expirable, which is more a surprise to me. (nothing like that in oauth2 spec)
>
> So for iOS sdk we?ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we?ll need to go through grant ptopup again.
> To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired? or decode refresh token as done in key cloak.js [3].
>
> Thanks @mposolda for the links.
>
> @summers @passos: I guess it?s something you?ll need to consider too for Android sdk.
>
> ++
> Corinne
> ??????
> AeroGear iOS tech lead
>
> [1] https://issues.jboss.org/browse/AGIOS-294
> [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth2/OAuth2Module.swift#L145
> [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L216, https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L462
>
>
>
> _______________________________________________
> 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 corinnekrych at gmail.com  Wed Oct 15 12:04:19 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 15 Oct 2014 18:04:19 +0200
Subject: [keycloak-dev] Refresh token expires too
In-Reply-To: <543E9450.5050707@redhat.com>
References: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>
	<543E9450.5050707@redhat.com>
Message-ID: <A6EB1654-A2D6-44C8-A295-10124891E7DB@gmail.com>

if you asked me, i think providing expiration date in json response (i.e.: second choice in your list) makes it clear that refresh tokens do expire and it's easier on client side refersh token dealing (not need to decode tokens etc?).

++
Corinne

On 15 Oct 2014, at 17:35, Bill Burke <bburke at redhat.com> wrote:

> There's a few things we could do:
> 
> * Expand the public realm REST interface to include information about 
> timeouts
> * oauth alreayd requires that access token response json document 
> contains an access token timeout, we could include the refresh tieout too.
> * Then again, you could just decode the refresh token :)
> 
> On 10/15/2014 11:20 AM, Corinne Krych wrote:
>> Hello Keycloak
>> 
>> Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are:
>> - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4,
>> - expirable, which is more a surprise to me. (nothing like that in oauth2 spec)
>> 
>> So for iOS sdk we?ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we?ll need to go through grant ptopup again.
>> To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired? or decode refresh token as done in key cloak.js [3].
>> 
>> Thanks @mposolda for the links.
>> 
>> @summers @passos: I guess it?s something you?ll need to consider too for Android sdk.
>> 
>> ++
>> Corinne
>> ??????
>> AeroGear iOS tech lead
>> 
>> [1] https://issues.jboss.org/browse/AGIOS-294
>> [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth2/OAuth2Module.swift#L145
>> [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L216, https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L462
>> 
>> 
>> 
>> _______________________________________________
>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141015/9319e536/attachment.bin 

From bburke at redhat.com  Wed Oct 15 12:11:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Oct 2014 12:11:19 -0400
Subject: [keycloak-dev] Refresh token expires too
In-Reply-To: <A6EB1654-A2D6-44C8-A295-10124891E7DB@gmail.com>
References: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>
	<543E9450.5050707@redhat.com>
	<A6EB1654-A2D6-44C8-A295-10124891E7DB@gmail.com>
Message-ID: <543E9CA7.4070408@redhat.com>

Submit a jira please.

On 10/15/2014 12:04 PM, Corinne Krych wrote:
> if you asked me, i think providing expiration date in json response (i.e.: second choice in your list) makes it clear that refresh tokens do expire and it's easier on client side refersh token dealing (not need to decode tokens etc?).
>
> ++
> Corinne
>
> On 15 Oct 2014, at 17:35, Bill Burke <bburke at redhat.com> wrote:
>
>> There's a few things we could do:
>>
>> * Expand the public realm REST interface to include information about
>> timeouts
>> * oauth alreayd requires that access token response json document
>> contains an access token timeout, we could include the refresh tieout too.
>> * Then again, you could just decode the refresh token :)
>>
>> On 10/15/2014 11:20 AM, Corinne Krych wrote:
>>> Hello Keycloak
>>>
>>> Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are:
>>> - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4,
>>> - expirable, which is more a surprise to me. (nothing like that in oauth2 spec)
>>>
>>> So for iOS sdk we?ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we?ll need to go through grant ptopup again.
>>> To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired? or decode refresh token as done in key cloak.js [3].
>>>
>>> Thanks @mposolda for the links.
>>>
>>> @summers @passos: I guess it?s something you?ll need to consider too for Android sdk.
>>>
>>> ++
>>> Corinne
>>> ??????
>>> AeroGear iOS tech lead
>>>
>>> [1] https://issues.jboss.org/browse/AGIOS-294
>>> [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth2/OAuth2Module.swift#L145
>>> [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L216, https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L462
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 corinnekrych at gmail.com  Wed Oct 15 14:28:57 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Wed, 15 Oct 2014 20:28:57 +0200
Subject: [keycloak-dev] Refresh token expires too
In-Reply-To: <543E9CA7.4070408@redhat.com>
References: <AB3E6839-4060-411E-9077-CF64E9F17543@gmail.com>
	<543E9450.5050707@redhat.com>
	<A6EB1654-A2D6-44C8-A295-10124891E7DB@gmail.com>
	<543E9CA7.4070408@redhat.com>
Message-ID: <41DC34F6-5CF1-4DBD-92EE-6EC86159A197@gmail.com>

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

On 15 Oct 2014, at 18:11, Bill Burke <bburke at redhat.com> wrote:

> Submit a jira please.
> 
> On 10/15/2014 12:04 PM, Corinne Krych wrote:
>> if you asked me, i think providing expiration date in json response (i.e.: second choice in your list) makes it clear that refresh tokens do expire and it's easier on client side refersh token dealing (not need to decode tokens etc?).
>> 
>> ++
>> Corinne
>> 
>> On 15 Oct 2014, at 17:35, Bill Burke <bburke at redhat.com> wrote:
>> 
>>> There's a few things we could do:
>>> 
>>> * Expand the public realm REST interface to include information about
>>> timeouts
>>> * oauth alreayd requires that access token response json document
>>> contains an access token timeout, we could include the refresh tieout too.
>>> * Then again, you could just decode the refresh token :)
>>> 
>>> On 10/15/2014 11:20 AM, Corinne Krych wrote:
>>>> Hello Keycloak
>>>> 
>>>> Today I run into an issue [1] related to the fact that in Keycloak server, refresh tokens are:
>>>> - renewed after each refresh token request. as described in second paragraph here http://tools.ietf.org/html/rfc6749#section-10.4,
>>>> - expirable, which is more a surprise to me. (nothing like that in oauth2 spec)
>>>> 
>>>> So for iOS sdk we?ll need to adjust our logic in here [2] and cater to the fact that if refresh token is expired we?ll need to go through grant ptopup again.
>>>> To get refresh token expriation date one way is ask to renew refresh and hit a 400, "Refresh token expired? or decode refresh token as done in key cloak.js [3].
>>>> 
>>>> Thanks @mposolda for the links.
>>>> 
>>>> @summers @passos: I guess it?s something you?ll need to consider too for Android sdk.
>>>> 
>>>> ++
>>>> Corinne
>>>> ??????
>>>> AeroGear iOS tech lead
>>>> 
>>>> [1] https://issues.jboss.org/browse/AGIOS-294
>>>> [2] https://github.com/aerogear/aerogear-ios-oauth2/blob/master/AeroGearOAuth2/OAuth2Module.swift#L145
>>>> [3] https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L216, https://github.com/keycloak/keycloak/blob/master/integration/js/src/main/resources/keycloak.js#L462
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141015/5d23ab1b/attachment-0001.bin 

From mposolda at redhat.com  Wed Oct 15 17:19:39 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 15 Oct 2014 23:19:39 +0200
Subject: [keycloak-dev] Is it ok to support multiple managementUrls	per
 application?
In-Reply-To: <1563526678.68885241.1413372960642.JavaMail.zimbra@redhat.com>
References: <5437F643.5010803@redhat.com> <5437F67C.1060604@redhat.com>
	<1683732650.66655177.1413187166958.JavaMail.zimbra@redhat.com>
	<1236833049.68395121.1413308960920.JavaMail.zimbra@redhat.com>
	<543E49A4.6080209@redhat.com>
	<1563526678.68885241.1413372960642.JavaMail.zimbra@redhat.com>
Message-ID: <543EE4EB.9060604@redhat.com>

I've created JIRA with some additional details about this: 
https://issues.jboss.org/browse/KEYCLOAK-759 and I am working on it. 
Feel free to add more thoughts.

Marek

On 15.10.2014 13:36, Stian Thorgersen wrote:
> We need to do something better than requiring users to manually register/unregister nodes with Keycloak. That's just to clunky if you ask me.
>
> What about adding an option where nodes self-register? Nodes could authenticate with the client credentials to be allowed to register. We could also require adapters to "re-register" after a certain amount of time so we don't end up with a bunch of dead nodes.
>
> There might be something already in the OpenID Connect Dynamic Registration spec for this. Worth looking at that before we do anything.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 15 October, 2014 12:17:08 PM
>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls	per application?
>>
>> That's an option, but it would require that adapters would need to be
>> aware of that and have support for jgroups/jms/infinispan ? Perhaps we
>> can add sender/receiver SPI for that?
>>
>> I know that having more managementUrls is not ideal solution and have
>> many pitfalls as you mentioned:-\ However it doesn't have any further
>> requirements on adapters (like being capable to receive jgroups/jms
>> message). I think that many adapters might want to rely just on
>> sticky-session provided by LB and don't want to have any additional
>> communication among each other. So setup with more managementUrls might
>> be still the best option for some deployments.
>>
>> I am not sure tbh. Maybe for Beta-1 we can keep just multiple
>> managementUrls and add sender/receiver SPI with possibility for
>> jgroups/jms to Beta-2 ?
>>
>> Marek
>>
>> On 14.10.2014 19:49, Stian Thorgersen wrote:
>>> Would it be an idea to add more options on how admin events are delivered?
>>> We could for example add jgroups and jms. Either of those would be more
>>> efficient in a cluster and wouldn't require managing nodes.
>>>
>>> ----- 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, 13 October, 2014 9:59:26 AM
>>>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls
>>>> 	per	application?
>>>>
>>>> Adding multiple management URLs to an application is going to be
>>>> cumbersome
>>>> to maintain. It would require manually registering/unregistering nodes
>>>> with
>>>> Keycloak.
>>>>
>>>> WildFly for example automatically detects cluster members, and add/removes
>>>> nodes to Apache. Introducing KC would then add a cumbersome manual
>>>> registration process. Even worse with automatic provisioning of nodes it
>>>> simply won't work (think cloud).
>>>>
>>>> Another issue is that we'd have to deal with making sure new nodes and
>>>> temporarily unavailable nodes retrieve the updates as well. We probably
>>>> need
>>>> to improve on this in either case, a single node can also be temporarily
>>>> unavailable (and miss notBefore or logout notifications), but doing it for
>>>> a
>>>> cluster is harder than for a single node.
>>>>
>>>> There's also the use-case when KC and applications are on different
>>>> subnets
>>>> where only the load balancer is visible to Keycloak.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 10 October, 2014 5:08:44 PM
>>>>> Subject: Re: [keycloak-dev] Is it ok to support multiple managementUrls
>>>>> per
>>>>> 	application?
>>>>>
>>>>> On 10.10.2014 17:07, Marek Posolda wrote:
>>>>>> The problem I am looking at is sending "Push NotBefore" from keycloak
>>>>>> to adapters in cluster. Basically the info about push notBefore should
>>>>>> be propagated to all cluster nodes where application is deployed.
>>>>>>
>>>>>> ATM I am seeing 2 possibilities:
>>>>>>
>>>>>> a) More managementUrls per ApplicationModel. People would need to
>>>>>> configure all nodes where adapter is deployed . Then Keycloak (
>>>>>> ResourceAdminManager ) will be able to send "global" events like
>>>>>> pushNotBefore or "logoutAll" to all those nodes. "Normal" logouts will
>>>>>> be sent just to single node like now .
>>>>>>
>>>>>> b) Ensure that notBefore can be replicated on adapters side. I don't
>>>>>> like this tbh. It requires adapters to be in replicated cluster, which
>>>>>> may not be an option for many deployments, who want to rely just on
>>>>>> sticky session.
>>>>>>
>>>>>> Any of those is not super-ideal, but I don't have better idea to
>>>>>> ensure cluster-safe propagation of NotBefore and global logout to all
>>>>>> cluster nodes.
>>>>>>
>>>>>> Better ideas?
>>>>>>
>>>>>> I have (b) already prototyped and working, but wanted to have ack from
>>>>>> you before go further, cleanup, start changing admin console etc.
>>>>> oops, sorry. I have (a) working (model change to support multiple
>>>>> managementUrls)
>>>>>> 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  Thu Oct 16 04:24:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Oct 2014 04:24:00 -0400 (EDT)
Subject: [keycloak-dev] Adapters and PicketLink
In-Reply-To: <530990474.69598868.1413447445743.JavaMail.zimbra@redhat.com>
Message-ID: <1848428721.69602639.1413447840272.JavaMail.zimbra@redhat.com>

We want adapters, PicketLink already has quite a few, can we utilise that?

Can we provide a single Keycloak PicketLink adapter for everything Java, and then get the correct level of integration and features for:

* Fuse
* BRMS
* WildFly/EAP (Elytron)
* JavaEE (WildFly/EAP, Tomcat, Jetty)
* Spring
* Anything else?

Obviously the main benefit is that we don't have to write our own, but would potentially also allow users to switch to another IdP without recoding.

From stian at redhat.com  Thu Oct 16 06:54:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Oct 2014 06:54:53 -0400 (EDT)
Subject: [keycloak-dev] Documenting SPIs, providers and keycloak-server.json
In-Reply-To: <2074792542.69711126.1413456032332.JavaMail.zimbra@redhat.com>
Message-ID: <1655744727.69717845.1413456893236.JavaMail.zimbra@redhat.com>

To make it easier for users to configure Keycloak I propose we add a self-documenting feature to SPIs and Providers. 

This would also allow us to do some sanity check on keycloak-server.json.

To achieve this we would do the following:

1. Add Spi#getDescription and update all implementations to have a short description about the Spi
2. Add ProviderDescription[1] interface, ProviderFactory implementations can optionally implement this interface. All our built-in providers should implement ProviderDescription
3. Add some sanity check of keycloak-server.json
4. Fix config in keycloak-server.json that doesn't follow the spi/provider format (applies to scheduled and theme)

Using the above details we can generate a reference guide to include in the documentation. In the future we could also make it possible to configure through the admin console.

It's only a couple hours work and I'd like to include it in 1.1.0.Beta1.

More details below.

--------------
#2 Add ProviderDescription

ProviderDescription:
* String getDescription
* ConfigOption[] getConfigOptions()

ConfigOption:
* String getName
* String getDescription
* boolean isRequired
* Type getType

Type (enum)
* STRING
* NUMBER
* BOOLEAN
* OPTIONS(String.. options)

--------------
#4 Fix config in keycloak-server.json

Change:

    "scheduled": {
        "interval": 900
    }

To:

    "timer": {
        "basic": 
          "defaultInterval: 900
        }
    }

Change:

    "theme": {
        "default": "keycloak",
        "staticMaxAge": 2592000,
        "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
        "cacheThemes": "${keycloak.theme.cacheThemes:true}",
        "folder": {
            "dir": "${keycloak.theme.dir}"
        }
    }

To:

    "theme": {
        "provider": "default",
        "default": {
            "defaultTheme": "keycloak",
            "staticMaxAge": 2592000,
            "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
            "cacheThemes": "${keycloak.theme.cacheThemes:true}",
            "themeDir": "${keycloak.theme.dir}"
        }
    }

From ssilvert at redhat.com  Thu Oct 16 09:26:36 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 16 Oct 2014 09:26:36 -0400
Subject: [keycloak-dev] Documenting SPIs,
	providers and keycloak-server.json
In-Reply-To: <1655744727.69717845.1413456893236.JavaMail.zimbra@redhat.com>
References: <1655744727.69717845.1413456893236.JavaMail.zimbra@redhat.com>
Message-ID: <543FC78C.1050404@redhat.com>

+1 overall.  Comments below.

On 10/16/2014 6:54 AM, Stian Thorgersen wrote:
> To make it easier for users to configure Keycloak I propose we add a self-documenting feature to SPIs and Providers.
>
> This would also allow us to do some sanity check on keycloak-server.json.
>
> To achieve this we would do the following:
>
> 1. Add Spi#getDescription and update all implementations to have a short description about the Spi
This part is a no-brainer.  I think we should do it right away.
> 2. Add ProviderDescription[1] interface, ProviderFactory implementations can optionally implement this interface. All our built-in providers should implement ProviderDescription
I'd like us to give this more thought before we commit.  One of the 
problems I ran into with tighter WildFly integration was that 
keycloak-server.json doesn't translate very well into DMR.   So I'd like 
to see that our config options and types will work with that.

DMR already has two-way JSON translation built in because JSON is used 
as its wire format.  Perhaps we should adopt that as our standard.  It's 
a tiny library and it's very nice to work with.  The public API is only 
three classes.

We would just need to make sure our JSON is readable with 
ModelNode.fromJSONStream().
> 3. Add some sanity check of keycloak-server.json
> 4. Fix config in keycloak-server.json that doesn't follow the spi/provider format (applies to scheduled and theme)
>
> Using the above details we can generate a reference guide to include in the documentation. In the future we could also make it possible to configure through the admin console.
>
> It's only a couple hours work and I'd like to include it in 1.1.0.Beta1.
>
> More details below.
>
> --------------
> #2 Add ProviderDescription
>
> ProviderDescription:
> * String getDescription
> * ConfigOption[] getConfigOptions()
>
> ConfigOption:
> * String getName
> * String getDescription
> * boolean isRequired
> * Type getType
>
> Type (enum)
> * STRING
> * NUMBER
> * BOOLEAN
> * OPTIONS(String.. options)
You'll also need lists, arrays, a "type" type, etc.  DMR already has 
this stuff and it's mature.  I think it would fit perfectly.  Just use 
DMR's ModelType.Type enum instead of your custom enum.

You might also want to think about things like localization of 
getDescription() and using a validation framework in case "isRequired" 
isn't enough.  WildFly has libraries for all that stuff too if we want 
to use it.
>
> --------------
> #4 Fix config in keycloak-server.json
>
> Change:
>
>      "scheduled": {
>          "interval": 900
>      }
>
> To:
>
>      "timer": {
>          "basic":
>            "defaultInterval: 900
>          }
>      }
>
> Change:
>
>      "theme": {
>          "default": "keycloak",
>          "staticMaxAge": 2592000,
>          "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
>          "cacheThemes": "${keycloak.theme.cacheThemes:true}",
>          "folder": {
>              "dir": "${keycloak.theme.dir}"
>          }
>      }
>
> To:
>
>      "theme": {
>          "provider": "default",
>          "default": {
>              "defaultTheme": "keycloak",
>              "staticMaxAge": 2592000,
>              "cacheTemplates": "${keycloak.theme.cacheTemplates:true}",
>              "cacheThemes": "${keycloak.theme.cacheThemes:true}",
>              "themeDir": "${keycloak.theme.dir}"
>          }
>      }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From matzew at apache.org  Fri Oct 17 02:10:25 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 17 Oct 2014 08:10:25 +0200
Subject: [keycloak-dev] Running behind a nginx proxy?
Message-ID: <CAAg5f2TOADH8fw9Ja3eoK22kT1YPj+Oqvo0=2sZ+UOdBZ3W_Xg@mail.gmail.com>

Hello,

on our community list, we got a question regarding running behind a nginx
proxy.
http://aerogear-dev.1069024.n5.nabble.com/setting-up-aerogear-behind-nginx-proxy-td9489.html

wondering if you have any experience on that configuration.

Thanks,
Matthias

-- 
Matthias Wessendorf

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

From bburke at redhat.com  Fri Oct 17 08:40:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Oct 2014 08:40:10 -0400
Subject: [keycloak-dev] Running behind a nginx proxy?
In-Reply-To: <CAAg5f2TOADH8fw9Ja3eoK22kT1YPj+Oqvo0=2sZ+UOdBZ3W_Xg@mail.gmail.com>
References: <CAAg5f2TOADH8fw9Ja3eoK22kT1YPj+Oqvo0=2sZ+UOdBZ3W_Xg@mail.gmail.com>
Message-ID: <54410E2A.4080404@redhat.com>

There's something in our docs about using SSL with a reverse proxy, 
section 3.3.5.2

On 10/17/2014 2:10 AM, Matthias Wessendorf wrote:
> Hello,
>
> on our community list, we got a question regarding running behind a
> nginx proxy.
> http://aerogear-dev.1069024.n5.nabble.com/setting-up-aerogear-behind-nginx-proxy-td9489.html
>
> wondering if you have any experience on that configuration.
>
> Thanks,
> Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Oct 21 03:08:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Oct 2014 03:08:56 -0400 (EDT)
Subject: [keycloak-dev] key and code in emails
Message-ID: <704395009.73378204.1413875336245.JavaMail.zimbra@redhat.com>

Why is there a key as well as the code query params in links sent in emails?

From stian at redhat.com  Tue Oct 21 03:42:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Oct 2014 03:42:03 -0400 (EDT)
Subject: [keycloak-dev] key and code in emails
In-Reply-To: <704395009.73378204.1413875336245.JavaMail.zimbra@redhat.com>
References: <704395009.73378204.1413875336245.JavaMail.zimbra@redhat.com>
Message-ID: <802728965.73390944.1413877323603.JavaMail.zimbra@redhat.com>

I guess it's added as an additional security check. This would be applicable to all codes though.

I propose in ClientSessionCode#getAction we create a new key and set it on the ClientSession. Then we add the key to the signature part of the code. This would make each code more unique and harder to generate, while at the same time we could remove the key query param for emails.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 21 October, 2014 9:08:56 AM
> Subject: [keycloak-dev] key and code in emails
> 
> Why is there a key as well as the code query params in links sent in emails?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From juraci at kroehling.de  Tue Oct 21 05:47:28 2014
From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Tue, 21 Oct 2014 11:47:28 +0200
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
Message-ID: <54462BB0.4060508@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello,

As part of a task for another project that could benefit from having
multi tenancy support in Keycloak, I scratched a proposal for this
feature and sent it as a PR (it's now on the 'multi-tenant-adapter'
branch).

In my view, multi tenancy is defined as "a way to determine the realm
of an application based on the incoming request". So, a single
application is deployed to a single application server, but the users
could belong to different realms, depending on the hostname, or an
HTTP header, or path, ... This is a typical SaaS scenario.

There's already a good "multi tenant" support at the server level, in
the form of a realm, so, I haven't bothered much in checking if it
would make sense to add this kind of support on the server (ie: a
"tenants" property in a realm).

The commit [1] adds a new abstract class, KeycloakConfigResolver, that
is meant to be extended by an application developer and builds a
KeycloakDeployment.

If an application (war) contains the context parameter
"keycloak.config.resolver" and points to a class existing on the
deployed WAR, it uses that on the AdapterDeploymentContext. On each
incoming request, this resolver is used to build a KeycloakDeployment,
used during the actual authentication/authorization, not changed by
this commit except for adding the HttpFacade.Request in some places.

When doing a rebase this morning to send the PR, I got a few conflicts
due to the clustering support. I don't know the implications of that
yet, as I'm not familiar with the clustering support, but I think a
proper final solution is to split KeycloakDeployment , so that
information about the target Keycloak server is stored in a different
place than the realm information.

I have tested this with a custom application, available at [2]. It was
tested with a Keycloak 1.0.1.Final server and with the custom adapters
deployed on Wildfly 8.1.0.Final and seem to work fine.

What I'm particularly interested in knowing is:

- - Is this the right direction to implement this feature? I have mixed
feelings about doing this at the "AdapterDeploymentContext" level
(mixed, but more on the positive side).
- - Should I refactor KeycloakDeployment , to split the server from the
realm information?

1 -
https://github.com/keycloak/keycloak/commit/37a48d49e10798d10f4509848c04ecb257f38d0f

2 - https://github.com/jpkrohling/keycloak-tenants-poc

Best,
Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJURiuwAAoJEDnJtskdmzLMx+AH/1pMBIeB40Tq5BTj6vciXJIc
ZJgcdgU+UXJbW0GLO4Nio6llSR4IprKfzkXUe/JRgfUdTFEeO90plWFCJ9k0YfZP
GaldCUdNZKwqWqiw6ZcQWIRzDeyruX0nyv08XGJ44VDtUUhXdNLv3kDDCO4hHnHd
gt5uFISj0U+JsgXR/1vXnHXzGE8hNORTe/uw+RSkjhpk6bmgbpUBSE5760RKMKNN
IhzS1AgU/9SRUBs7yaV9w2KOs9+KUQ2aAu1ABqPt5+T2EDqWfqD+chCuM5lz91te
GwXN/ZsRLTlSbb68EkyMOaWV5sM+FUA+RBG2EN5SPJcrjYxnqXp4I9TJdVa57t0=
=9d5O
-----END PGP SIGNATURE-----

From ssilvert at redhat.com  Tue Oct 21 08:45:02 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 21 Oct 2014 08:45:02 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <54462BB0.4060508@kroehling.de>
References: <54462BB0.4060508@kroehling.de>
Message-ID: <5446554E.3090806@redhat.com>

I don't know if this helps your use case, but you will soon be able to 
deploy more than one Keycloak Auth Server in the same WildFly instance.  
Each server will have a different web context and be completely independent.

So you would have something like:
http://localhost:8080/authserverone/admin/index.html
http://localhost:8080/authservertwo/admin/index.html

In standalone.xml, you will have:
         <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
             <auth-server name="authserverone">
                 <enabled>true</enabled>
<web-context>authserverone</web-context>
             </auth-server>
             <auth-server name="authservertwo">
                 <enabled>true</enabled>
<web-context>authservertwo</web-context>
             </auth-server>
         </subsystem>

You will also need to associate each one with a different datasource 
using keycloak-server.json.

On 10/21/2014 5:47 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> As part of a task for another project that could benefit from having
> multi tenancy support in Keycloak, I scratched a proposal for this
> feature and sent it as a PR (it's now on the 'multi-tenant-adapter'
> branch).
>
> In my view, multi tenancy is defined as "a way to determine the realm
> of an application based on the incoming request". So, a single
> application is deployed to a single application server, but the users
> could belong to different realms, depending on the hostname, or an
> HTTP header, or path, ... This is a typical SaaS scenario.
>
> There's already a good "multi tenant" support at the server level, in
> the form of a realm, so, I haven't bothered much in checking if it
> would make sense to add this kind of support on the server (ie: a
> "tenants" property in a realm).
>
> The commit [1] adds a new abstract class, KeycloakConfigResolver, that
> is meant to be extended by an application developer and builds a
> KeycloakDeployment.
>
> If an application (war) contains the context parameter
> "keycloak.config.resolver" and points to a class existing on the
> deployed WAR, it uses that on the AdapterDeploymentContext. On each
> incoming request, this resolver is used to build a KeycloakDeployment,
> used during the actual authentication/authorization, not changed by
> this commit except for adding the HttpFacade.Request in some places.
>
> When doing a rebase this morning to send the PR, I got a few conflicts
> due to the clustering support. I don't know the implications of that
> yet, as I'm not familiar with the clustering support, but I think a
> proper final solution is to split KeycloakDeployment , so that
> information about the target Keycloak server is stored in a different
> place than the realm information.
>
> I have tested this with a custom application, available at [2]. It was
> tested with a Keycloak 1.0.1.Final server and with the custom adapters
> deployed on Wildfly 8.1.0.Final and seem to work fine.
>
> What I'm particularly interested in knowing is:
>
> - - Is this the right direction to implement this feature? I have mixed
> feelings about doing this at the "AdapterDeploymentContext" level
> (mixed, but more on the positive side).
> - - Should I refactor KeycloakDeployment , to split the server from the
> realm information?
>
> 1 -
> https://github.com/keycloak/keycloak/commit/37a48d49e10798d10f4509848c04ecb257f38d0f
>
> 2 - https://github.com/jpkrohling/keycloak-tenants-poc
>
> Best,
> Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJURiuwAAoJEDnJtskdmzLMx+AH/1pMBIeB40Tq5BTj6vciXJIc
> ZJgcdgU+UXJbW0GLO4Nio6llSR4IprKfzkXUe/JRgfUdTFEeO90plWFCJ9k0YfZP
> GaldCUdNZKwqWqiw6ZcQWIRzDeyruX0nyv08XGJ44VDtUUhXdNLv3kDDCO4hHnHd
> gt5uFISj0U+JsgXR/1vXnHXzGE8hNORTe/uw+RSkjhpk6bmgbpUBSE5760RKMKNN
> IhzS1AgU/9SRUBs7yaV9w2KOs9+KUQ2aAu1ABqPt5+T2EDqWfqD+chCuM5lz91te
> GwXN/ZsRLTlSbb68EkyMOaWV5sM+FUA+RBG2EN5SPJcrjYxnqXp4I9TJdVa57t0=
> =9d5O
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Oct 21 08:49:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Oct 2014 08:49:43 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <54462BB0.4060508@kroehling.de>
References: <54462BB0.4060508@kroehling.de>
Message-ID: <54465667.8000102@redhat.com>



On 10/21/2014 5:47 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello,
>
> As part of a task for another project that could benefit from having
> multi tenancy support in Keycloak, I scratched a proposal for this
> feature and sent it as a PR (it's now on the 'multi-tenant-adapter'
> branch).
>
> In my view, multi tenancy is defined as "a way to determine the realm
> of an application based on the incoming request". So, a single
> application is deployed to a single application server, but the users
> could belong to different realms, depending on the hostname, or an
> HTTP header, or path, ... This is a typical SaaS scenario.
>
> There's already a good "multi tenant" support at the server level, in
> the form of a realm, so, I haven't bothered much in checking if it
> would make sense to add this kind of support on the server (ie: a
> "tenants" property in a realm).
>
> The commit [1] adds a new abstract class, KeycloakConfigResolver, that
> is meant to be extended by an application developer and builds a
> KeycloakDeployment.
>
> If an application (war) contains the context parameter
> "keycloak.config.resolver" and points to a class existing on the
> deployed WAR, it uses that on the AdapterDeploymentContext. On each
> incoming request, this resolver is used to build a KeycloakDeployment,
> used during the actual authentication/authorization, not changed by
> this commit except for adding the HttpFacade.Request in some places.
>
> When doing a rebase this morning to send the PR, I got a few conflicts
> due to the clustering support. I don't know the implications of that
> yet, as I'm not familiar with the clustering support, but I think a
> proper final solution is to split KeycloakDeployment , so that
> information about the target Keycloak server is stored in a different
> place than the realm information.
>
> I have tested this with a custom application, available at [2]. It was
> tested with a Keycloak 1.0.1.Final server and with the custom adapters
> deployed on Wildfly 8.1.0.Final and seem to work fine.
>
> What I'm particularly interested in knowing is:
>
> - - Is this the right direction to implement this feature? I have mixed
> feelings about doing this at the "AdapterDeploymentContext" level
> (mixed, but more on the positive side).

AdapterDeploymentContext was written to support your multi-tenant use 
case in mind.  I had hoped it was a good enough SPI.  Get your conflicts 
cleaned up and we'll merge your PR.  Great work, thanks.

Bill

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

From juraci at kroehling.de  Tue Oct 21 09:43:07 2014
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Tue, 21 Oct 2014 15:43:07 +0200
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5446554E.3090806@redhat.com>
References: <54462BB0.4060508@kroehling.de> <5446554E.3090806@redhat.com>
Message-ID: <544662EB.50606@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/21/2014 02:45 PM, Stan Silvert wrote:
> I don't know if this helps your use case, but you will soon be able
> to deploy more than one Keycloak Auth Server in the same WildFly
> instance. Each server will have a different web context and be
> completely independent.
> 
> So you would have something like: 
> http://localhost:8080/authserverone/admin/index.html 
> http://localhost:8080/authservertwo/admin/index.html
> 
> In standalone.xml, you will have: <subsystem
> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server
> name="authserverone"> <enabled>true</enabled> 
> <web-context>authserverone</web-context> </auth-server> 
> <auth-server name="authservertwo"> <enabled>true</enabled> 
> <web-context>authservertwo</web-context> </auth-server> 
> </subsystem>
> 
> You will also need to associate each one with a different
> datasource using keycloak-server.json.

That sounds like an interesting scenario, but won't help on this case,
as the users would register an account themselves. So, either we would
need to provision Keycloak servers on demand, or we would use one
realm per account, which is the approach I was thinking.

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJURmLrAAoJEDnJtskdmzLMjKQIAI65gLH+J8o2bX6HpESeWey9
KTVv7y29Le/oTtzbCQy3TOdGD0YYm8f0jZLjG6d7hvYPi6Mfc9DF7NiVjpFtRh/m
5EaZe8EoXNZBoWPELKR3xKxIxEzWeujvRVyRl6BYRoPlmSZV1Gb73BINjckABW+D
ovZk/8WoFy3XMT2EmpLBcwZaWR70IPd7ELFcK/mmPz7emJQD1l7q8zAue8//Y0kr
U4Lxo1LXG5Fbm48JIs1dY2xIq3X8EAAxJt3g8llM4/uwc9kb6DxsmkU+g8wXMgTV
Vy6Klw0RKj6jjl3/Q4/gYVdmF6BgtSWqhlqaj+5ajeqWdH4MykcYPbUPek5e6iE=
=Z5ws
-----END PGP SIGNATURE-----

From bburke at redhat.com  Tue Oct 21 17:26:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Oct 2014 17:26:59 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <544662EB.50606@kroehling.de>
References: <54462BB0.4060508@kroehling.de> <5446554E.3090806@redhat.com>
	<544662EB.50606@kroehling.de>
Message-ID: <5446CFA3.8040406@redhat.com>

Would be cool if you added a unit test and documentation for this 
feature.  If you need some help with that, let me know.

On 10/21/2014 9:43 AM, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 10/21/2014 02:45 PM, Stan Silvert wrote:
>> I don't know if this helps your use case, but you will soon be able
>> to deploy more than one Keycloak Auth Server in the same WildFly
>> instance. Each server will have a different web context and be
>> completely independent.
>>
>> So you would have something like:
>> http://localhost:8080/authserverone/admin/index.html
>> http://localhost:8080/authservertwo/admin/index.html
>>
>> In standalone.xml, you will have: <subsystem
>> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server
>> name="authserverone"> <enabled>true</enabled>
>> <web-context>authserverone</web-context> </auth-server>
>> <auth-server name="authservertwo"> <enabled>true</enabled>
>> <web-context>authservertwo</web-context> </auth-server>
>> </subsystem>
>>
>> You will also need to associate each one with a different
>> datasource using keycloak-server.json.
>
> That sounds like an interesting scenario, but won't help on this case,
> as the users would register an account themselves. So, either we would
> need to provision Keycloak servers on demand, or we would use one
> realm per account, which is the approach I was thinking.
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJURmLrAAoJEDnJtskdmzLMjKQIAI65gLH+J8o2bX6HpESeWey9
> KTVv7y29Le/oTtzbCQy3TOdGD0YYm8f0jZLjG6d7hvYPi6Mfc9DF7NiVjpFtRh/m
> 5EaZe8EoXNZBoWPELKR3xKxIxEzWeujvRVyRl6BYRoPlmSZV1Gb73BINjckABW+D
> ovZk/8WoFy3XMT2EmpLBcwZaWR70IPd7ELFcK/mmPz7emJQD1l7q8zAue8//Y0kr
> U4Lxo1LXG5Fbm48JIs1dY2xIq3X8EAAxJt3g8llM4/uwc9kb6DxsmkU+g8wXMgTV
> Vy6Klw0RKj6jjl3/Q4/gYVdmF6BgtSWqhlqaj+5ajeqWdH4MykcYPbUPek5e6iE=
> =Z5ws
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 Oct 22 07:49:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Oct 2014 07:49:45 -0400 (EDT)
Subject: [keycloak-dev] Increase 'SSO Session Idle Timeout' on master realm
In-Reply-To: <484831953.74311794.1413978498832.JavaMail.zimbra@redhat.com>
Message-ID: <970487521.74312404.1413978585094.JavaMail.zimbra@redhat.com>

Working with the admin console you often get logged-out while doing something (for example looking at documentation or configuring Google).

I propose we increase 'SSO Session Idle Timeout' on the master realm and new realms to 30 minutes. 

From ssilvert at redhat.com  Wed Oct 22 07:51:09 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 22 Oct 2014 07:51:09 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5446CFA3.8040406@redhat.com>
References: <54462BB0.4060508@kroehling.de> <5446554E.3090806@redhat.com>
	<544662EB.50606@kroehling.de> <5446CFA3.8040406@redhat.com>
Message-ID: <54479A2D.1050408@redhat.com>

On 10/21/2014 5:26 PM, Bill Burke wrote:
> Would be cool if you added a unit test and documentation for this
> feature.  If you need some help with that, let me know.
I'll definitely be writing doco for this and the rest of the subsystem 
changes.  I will let you know if I need help with unit tests.
>
> On 10/21/2014 9:43 AM, Juraci Paix?o Kr?hling wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> On 10/21/2014 02:45 PM, Stan Silvert wrote:
>>> I don't know if this helps your use case, but you will soon be able
>>> to deploy more than one Keycloak Auth Server in the same WildFly
>>> instance. Each server will have a different web context and be
>>> completely independent.
>>>
>>> So you would have something like:
>>> http://localhost:8080/authserverone/admin/index.html
>>> http://localhost:8080/authservertwo/admin/index.html
>>>
>>> In standalone.xml, you will have: <subsystem
>>> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server
>>> name="authserverone"> <enabled>true</enabled>
>>> <web-context>authserverone</web-context> </auth-server>
>>> <auth-server name="authservertwo"> <enabled>true</enabled>
>>> <web-context>authservertwo</web-context> </auth-server>
>>> </subsystem>
>>>
>>> You will also need to associate each one with a different
>>> datasource using keycloak-server.json.
>> That sounds like an interesting scenario, but won't help on this case,
>> as the users would register an account themselves. So, either we would
>> need to provision Keycloak servers on demand, or we would use one
>> realm per account, which is the approach I was thinking.
>>
>> - - Juca.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBCgAGBQJURmLrAAoJEDnJtskdmzLMjKQIAI65gLH+J8o2bX6HpESeWey9
>> KTVv7y29Le/oTtzbCQy3TOdGD0YYm8f0jZLjG6d7hvYPi6Mfc9DF7NiVjpFtRh/m
>> 5EaZe8EoXNZBoWPELKR3xKxIxEzWeujvRVyRl6BYRoPlmSZV1Gb73BINjckABW+D
>> ovZk/8WoFy3XMT2EmpLBcwZaWR70IPd7ELFcK/mmPz7emJQD1l7q8zAue8//Y0kr
>> U4Lxo1LXG5Fbm48JIs1dY2xIq3X8EAAxJt3g8llM4/uwc9kb6DxsmkU+g8wXMgTV
>> Vy6Klw0RKj6jjl3/Q4/gYVdmF6BgtSWqhlqaj+5ajeqWdH4MykcYPbUPek5e6iE=
>> =Z5ws
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Wed Oct 22 08:35:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 22 Oct 2014 08:35:14 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <54479A2D.1050408@redhat.com>
References: <54462BB0.4060508@kroehling.de>
	<5446554E.3090806@redhat.com>	<544662EB.50606@kroehling.de>
	<5446CFA3.8040406@redhat.com> <54479A2D.1050408@redhat.com>
Message-ID: <5447A482.70308@redhat.com>

I was talking to Juraci. :)

On 10/22/2014 7:51 AM, Stan Silvert wrote:
> On 10/21/2014 5:26 PM, Bill Burke wrote:
>> Would be cool if you added a unit test and documentation for this
>> feature.  If you need some help with that, let me know.
> I'll definitely be writing doco for this and the rest of the subsystem
> changes.  I will let you know if I need help with unit tests.
>>
>> On 10/21/2014 9:43 AM, Juraci Paix?o Kr?hling wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA512
>>>
>>> On 10/21/2014 02:45 PM, Stan Silvert wrote:
>>>> I don't know if this helps your use case, but you will soon be able
>>>> to deploy more than one Keycloak Auth Server in the same WildFly
>>>> instance. Each server will have a different web context and be
>>>> completely independent.
>>>>
>>>> So you would have something like:
>>>> http://localhost:8080/authserverone/admin/index.html
>>>> http://localhost:8080/authservertwo/admin/index.html
>>>>
>>>> In standalone.xml, you will have: <subsystem
>>>> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server
>>>> name="authserverone"> <enabled>true</enabled>
>>>> <web-context>authserverone</web-context> </auth-server>
>>>> <auth-server name="authservertwo"> <enabled>true</enabled>
>>>> <web-context>authservertwo</web-context> </auth-server>
>>>> </subsystem>
>>>>
>>>> You will also need to associate each one with a different
>>>> datasource using keycloak-server.json.
>>> That sounds like an interesting scenario, but won't help on this case,
>>> as the users would register an account themselves. So, either we would
>>> need to provision Keycloak servers on demand, or we would use one
>>> realm per account, which is the approach I was thinking.
>>>
>>> - - Juca.
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1
>>>
>>> iQEcBAEBCgAGBQJURmLrAAoJEDnJtskdmzLMjKQIAI65gLH+J8o2bX6HpESeWey9
>>> KTVv7y29Le/oTtzbCQy3TOdGD0YYm8f0jZLjG6d7hvYPi6Mfc9DF7NiVjpFtRh/m
>>> 5EaZe8EoXNZBoWPELKR3xKxIxEzWeujvRVyRl6BYRoPlmSZV1Gb73BINjckABW+D
>>> ovZk/8WoFy3XMT2EmpLBcwZaWR70IPd7ELFcK/mmPz7emJQD1l7q8zAue8//Y0kr
>>> U4Lxo1LXG5Fbm48JIs1dY2xIq3X8EAAxJt3g8llM4/uwc9kb6DxsmkU+g8wXMgTV
>>> Vy6Klw0RKj6jjl3/Q4/gYVdmF6BgtSWqhlqaj+5ajeqWdH4MykcYPbUPek5e6iE=
>>> =Z5ws
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> 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 Oct 22 08:56:46 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 22 Oct 2014 08:56:46 -0400
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5447A482.70308@redhat.com>
References: <54462BB0.4060508@kroehling.de>
	<5446554E.3090806@redhat.com>	<544662EB.50606@kroehling.de>
	<5446CFA3.8040406@redhat.com> <54479A2D.1050408@redhat.com>
	<5447A482.70308@redhat.com>
Message-ID: <5447A98E.9010204@redhat.com>

And I thought you were being so kind to offer help.  :-)

On 10/22/2014 8:35 AM, Bill Burke wrote:
> I was talking to Juraci. :)
>
> On 10/22/2014 7:51 AM, Stan Silvert wrote:
>> On 10/21/2014 5:26 PM, Bill Burke wrote:
>>> Would be cool if you added a unit test and documentation for this
>>> feature.  If you need some help with that, let me know.
>> I'll definitely be writing doco for this and the rest of the subsystem
>> changes.  I will let you know if I need help with unit tests.
>>> On 10/21/2014 9:43 AM, Juraci Paix?o Kr?hling wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA512
>>>>
>>>> On 10/21/2014 02:45 PM, Stan Silvert wrote:
>>>>> I don't know if this helps your use case, but you will soon be able
>>>>> to deploy more than one Keycloak Auth Server in the same WildFly
>>>>> instance. Each server will have a different web context and be
>>>>> completely independent.
>>>>>
>>>>> So you would have something like:
>>>>> http://localhost:8080/authserverone/admin/index.html
>>>>> http://localhost:8080/authservertwo/admin/index.html
>>>>>
>>>>> In standalone.xml, you will have: <subsystem
>>>>> xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server
>>>>> name="authserverone"> <enabled>true</enabled>
>>>>> <web-context>authserverone</web-context> </auth-server>
>>>>> <auth-server name="authservertwo"> <enabled>true</enabled>
>>>>> <web-context>authservertwo</web-context> </auth-server>
>>>>> </subsystem>
>>>>>
>>>>> You will also need to associate each one with a different
>>>>> datasource using keycloak-server.json.
>>>> That sounds like an interesting scenario, but won't help on this case,
>>>> as the users would register an account themselves. So, either we would
>>>> need to provision Keycloak servers on demand, or we would use one
>>>> realm per account, which is the approach I was thinking.
>>>>
>>>> - - Juca.
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1
>>>>
>>>> iQEcBAEBCgAGBQJURmLrAAoJEDnJtskdmzLMjKQIAI65gLH+J8o2bX6HpESeWey9
>>>> KTVv7y29Le/oTtzbCQy3TOdGD0YYm8f0jZLjG6d7hvYPi6Mfc9DF7NiVjpFtRh/m
>>>> 5EaZe8EoXNZBoWPELKR3xKxIxEzWeujvRVyRl6BYRoPlmSZV1Gb73BINjckABW+D
>>>> ovZk/8WoFy3XMT2EmpLBcwZaWR70IPd7ELFcK/mmPz7emJQD1l7q8zAue8//Y0kr
>>>> U4Lxo1LXG5Fbm48JIs1dY2xIq3X8EAAxJt3g8llM4/uwc9kb6DxsmkU+g8wXMgTV
>>>> Vy6Klw0RKj6jjl3/Q4/gYVdmF6BgtSWqhlqaj+5ajeqWdH4MykcYPbUPek5e6iE=
>>>> =Z5ws
>>>> -----END PGP SIGNATURE-----
>>>> _______________________________________________
>>>> 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  Wed Oct 22 11:23:06 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 22 Oct 2014 17:23:06 +0200
Subject: [keycloak-dev] Increase 'SSO Session Idle Timeout' on master
 realm
In-Reply-To: <970487521.74312404.1413978585094.JavaMail.zimbra@redhat.com>
References: <970487521.74312404.1413978585094.JavaMail.zimbra@redhat.com>
Message-ID: <5447CBDA.4050809@redhat.com>

+1

Also we can update default settings of this timeout for newly created 
realms to 30 mins too? Seems to be good default also due that default 
httpSession timeout is 30 mins too on AS7 and Undertow afaik.

For long term, we still want to handle it in keycloak.js (use JS storage 
to temprarily persist values, so if you click to "Save Social provider" 
and your session is expired, you won't lose all values you previously 
filled) ?

Marek


On 22.10.2014 13:49, Stian Thorgersen wrote:
> Working with the admin console you often get logged-out while doing something (for example looking at documentation or configuring Google).
>
> I propose we increase 'SSO Session Idle Timeout' on the master realm and new realms to 30 minutes.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Wed Oct 22 12:18:18 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 22 Oct 2014 12:18:18 -0400
Subject: [keycloak-dev] add-provider or add-service?
Message-ID: <5447D8CA.50603@redhat.com>

When you drop a service jar into the WEB-INF/lib of the auth server, is 
this always called a "provider"?

I'm making a subsystem management operation to upload a jar into the 
auth server and I'd like to know if I can call it "add-provider" or if I 
should go with the more generic "add-service"?

Stan

From stian at redhat.com  Wed Oct 22 12:53:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Oct 2014 12:53:21 -0400 (EDT)
Subject: [keycloak-dev] Increase 'SSO Session Idle Timeout' on master
 realm
In-Reply-To: <5447CBDA.4050809@redhat.com>
References: <970487521.74312404.1413978585094.JavaMail.zimbra@redhat.com>
	<5447CBDA.4050809@redhat.com>
Message-ID: <288663091.74686654.1413996801475.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, October 22, 2014 5:23:06 PM
> Subject: Re: [keycloak-dev] Increase 'SSO Session Idle Timeout' on master realm
> 
> +1
> 
> Also we can update default settings of this timeout for newly created
> realms to 30 mins too? Seems to be good default also due that default
> httpSession timeout is 30 mins too on AS7 and Undertow afaik.

+1 To default for new realms

> 
> For long term, we still want to handle it in keycloak.js (use JS storage
> to temprarily persist values, so if you click to "Save Social provider"
> and your session is expired, you won't lose all values you previously
> filled) ?

It would be a nice feature. One thing I was worried about was if there's any sensitive data in the form (for example smtp credentials). Maybe we could do something clever like encrypting it, then send the encryption key as the state variable.

> 
> Marek
> 
> 
> On 22.10.2014 13:49, Stian Thorgersen wrote:
> > Working with the admin console you often get logged-out while doing
> > something (for example looking at documentation or configuring Google).
> >
> > I propose we increase 'SSO Session Idle Timeout' on the master realm and
> > new realms to 30 minutes.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Wed Oct 22 13:28:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Oct 2014 13:28:52 -0400 (EDT)
Subject: [keycloak-dev] add-provider or add-service?
In-Reply-To: <5447D8CA.50603@redhat.com>
References: <5447D8CA.50603@redhat.com>
Message-ID: <1465987172.74719797.1413998932692.JavaMail.zimbra@redhat.com>

+1 To "add-provider"

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, October 22, 2014 6:18:18 PM
> Subject: [keycloak-dev] add-provider or add-service?
> 
> When you drop a service jar into the WEB-INF/lib of the auth server, is
> this always called a "provider"?
> 
> I'm making a subsystem management operation to upload a jar into the
> auth server and I'd like to know if I can call it "add-provider" or if I
> should go with the more generic "add-service"?
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From juraci at kroehling.de  Wed Oct 22 13:29:46 2014
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 22 Oct 2014 19:29:46 +0200
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5446CFA3.8040406@redhat.com>
References: <54462BB0.4060508@kroehling.de>
	<5446554E.3090806@redhat.com>	<544662EB.50606@kroehling.de>
	<5446CFA3.8040406@redhat.com>
Message-ID: <5447E98A.8080106@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/21/2014 11:26 PM, Bill Burke wrote:
> Would be cool if you added a unit test and documentation for this 
> feature.  If you need some help with that, let me know.

I've pushed some updates to a branch in my fork[1], which includes a
sample application (multi-tenants), documentation and some javadoc.
I'm planning on working on an integration test tomorrow.

This branch is also already integrated with Marek's clustering
feature, which caused some conflicts during the first rebase.

A question I've got when improving the sample application is regarding
some permissions.

On the sample application, the "registration" part contacts the server
as "registration" user, which has the "create-realm" permission. It
creates a new realm, say, "acme". Inside this new realm, there's an
application named "metrics", of which I want to retrieve the
keycloak.json and add to the response to the registration.

Unfortunately, I couldn't figure out which permission this user has to
have in order to retrieve this application's keycloak.json
installation file. Note that this is an user on the "master" realm,
trying to access a JSON from an application in another realm.

I've tried "view-realm" and "view-applications" from the
"master-realm" application, but I'm trying to access the application
from the new realm (not from master). As a result, I get a "forbidden"
error. I've tried several combinations, but I could only bypass it by
using the "admin" role, which is certainly *not* something I would
want to have on the registration application :-)

One more thing to note is that there seem to be a new "application" in
the roles combo, named "acme-realm". A possible solution would be to
add the original user to the "view-realm" on this new application, but
I guess only an admin can do that (chicken-egg problem).

So, would it make sense to clone the master-realm permissions from one
user when this user creates a new realm? I think it would make sense
to give "read" permissions to an user on the realm that it itself
created, no?

This is certainly not a blocker, but I'm afraid that users would just
copy/paste things and this might lead to a bigger problem in the future.

[1] http://git.io/GkVyyQ

- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUR+mJAAoJEDnJtskdmzLM2IkIAKn/My0zyKTCe6aElFRXER83
T+vCsEHEgNUN+emPp7LigvOU3l/V1jInEbSVnQwQKDoDQm4R79SXGSQBiFa4DLFJ
1lHN/kIQI3DG+B0+CyUlq3pyHOTcpLc+FqFfV5RyBYuhH+JYH82v0FZia98wCMLF
XVBbw3jesMTOiQvHnWXq4qYCDh1zKVs+rv6BpKLp8s3ikC4hEtwjoPrm5/KYQoJI
LagFEhq/kQ1KQH/aQDn3qrVwPcvel4vSU1KbO2z/mE9+YdH80PY/nLwykZK4QX7J
wi76NjpZjB2+b3GhnxE3mfxRgeHwEpe04jUYxF8aPY3zsM4auGB958wQJ9W6Dus=
=s4Lp
-----END PGP SIGNATURE-----

From mposolda at redhat.com  Thu Oct 23 04:28:12 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Oct 2014 10:28:12 +0200
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5447E98A.8080106@kroehling.de>
References: <54462BB0.4060508@kroehling.de>	<5446554E.3090806@redhat.com>	<544662EB.50606@kroehling.de>	<5446CFA3.8040406@redhat.com>
	<5447E98A.8080106@kroehling.de>
Message-ID: <5448BC1C.1060408@redhat.com>

On 22.10.2014 19:29, Juraci Paix?o Kr?hling wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 10/21/2014 11:26 PM, Bill Burke wrote:
>> Would be cool if you added a unit test and documentation for this
>> feature.  If you need some help with that, let me know.
> I've pushed some updates to a branch in my fork[1], which includes a
> sample application (multi-tenants), documentation and some javadoc.
> I'm planning on working on an integration test tomorrow.
>
> This branch is also already integrated with Marek's clustering
> feature, which caused some conflicts during the first rebase.
>
> A question I've got when improving the sample application is regarding
> some permissions.
>
> On the sample application, the "registration" part contacts the server
> as "registration" user, which has the "create-realm" permission. It
> creates a new realm, say, "acme". Inside this new realm, there's an
> application named "metrics", of which I want to retrieve the
> keycloak.json and add to the response to the registration.
>
> Unfortunately, I couldn't figure out which permission this user has to
> have in order to retrieve this application's keycloak.json
> installation file. Note that this is an user on the "master" realm,
> trying to access a JSON from an application in another realm.
When you create new realm "foo", keycloak automatically creates 
application in master realm called "foo-realm" and it creates set of 
'admin' roles for this application.

 From what I can see, for retrieve keycloak.json from admin console, you 
should be either in role "view-applications" or "manage-applications" of 
this "foo-realm" application. Actually the realm creator is 
automatically granted to all roles of the "foo-realm" application (see 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/RealmsAdminResource.java#L134 
) so he should be able to do everything in realm, which he just created. 
So it's a bit strange to me that you're seeing issues.

Actually isn't problem in scopes? The client application, which you are 
using to access KC should be in scopes for those "view-applications" or 
"manage-applications" roles. Admin console is using application 
"Security-admin-console", which has scope to realm role "admin" so it 
has defacto scope to everything. Maybe you can also use this scope or 
use "Full scope allowed" switch for your app.

Marek
>
> I've tried "view-realm" and "view-applications" from the
> "master-realm" application, but I'm trying to access the application
> from the new realm (not from master). As a result, I get a "forbidden"
> error. I've tried several combinations, but I could only bypass it by
> using the "admin" role, which is certainly *not* something I would
> want to have on the registration application :-)
>
> One more thing to note is that there seem to be a new "application" in
> the roles combo, named "acme-realm". A possible solution would be to
> add the original user to the "view-realm" on this new application, but
> I guess only an admin can do that (chicken-egg problem).
>
> So, would it make sense to clone the master-realm permissions from one
> user when this user creates a new realm? I think it would make sense
> to give "read" permissions to an user on the realm that it itself
> created, no?
>
> This is certainly not a blocker, but I'm afraid that users would just
> copy/paste things and this might lead to a bigger problem in the future.
>
> [1] http://git.io/GkVyyQ
>
> - - Juca.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJUR+mJAAoJEDnJtskdmzLM2IkIAKn/My0zyKTCe6aElFRXER83
> T+vCsEHEgNUN+emPp7LigvOU3l/V1jInEbSVnQwQKDoDQm4R79SXGSQBiFa4DLFJ
> 1lHN/kIQI3DG+B0+CyUlq3pyHOTcpLc+FqFfV5RyBYuhH+JYH82v0FZia98wCMLF
> XVBbw3jesMTOiQvHnWXq4qYCDh1zKVs+rv6BpKLp8s3ikC4hEtwjoPrm5/KYQoJI
> LagFEhq/kQ1KQH/aQDn3qrVwPcvel4vSU1KbO2z/mE9+YdH80PY/nLwykZK4QX7J
> wi76NjpZjB2+b3GhnxE3mfxRgeHwEpe04jUYxF8aPY3zsM4auGB958wQJ9W6Dus=
> =s4Lp
> -----END PGP SIGNATURE-----
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From juraci at kroehling.de  Thu Oct 23 04:42:22 2014
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Thu, 23 Oct 2014 10:42:22 +0200
Subject: [keycloak-dev] Multi tenancy support - a proposal to discuss
In-Reply-To: <5448BC1C.1060408@redhat.com>
References: <54462BB0.4060508@kroehling.de>	<5446554E.3090806@redhat.com>	<544662EB.50606@kroehling.de>	<5446CFA3.8040406@redhat.com>
	<5447E98A.8080106@kroehling.de> <5448BC1C.1060408@redhat.com>
Message-ID: <5448BF6E.5060709@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/23/2014 10:28 AM, Marek Posolda wrote:
>> Actually isn't problem in scopes? The client application, which
>> you are using to access KC should be in scopes for those
>> "view-applications" or "manage-applications" roles. Admin console
>> is using application "Security-admin-console", which has scope to
>> realm role "admin" so it has defacto scope to everything. Maybe
>> you can also use this scope or use "Full scope allowed" switch
>> for your app.

You nailed it: setting the OAuth Client with Full Scope did the trick.
The user that created the realm indeed gets full permission for the
realm, the problem was just that the OAuth Client scope wasn't allowed
for that.

Thanks a lot, I'll update the README for the example to use it instead.

Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUSL9uAAoJEDnJtskdmzLM04MIAJ2eMtlKJ471hlx78aEC21eh
z36j8xbwlC9QjNnlA505vIg5L8ZGNui9r+itH661rdR4GdVEdGepCWLiXdVlkHBf
gzdboMvlNeocW+PxyBIm2FMS2c3tJ25S2kQ+8bOcQcoshs0QMpyeZ8ydgvXysXsG
t696OoSEJ1B97R3d6Wos565ardVcoDDiPq32dpcsEDIV2vK7P3S98OEB/xr6kIja
kNqc3b0YpLCV//CuId9hKYVSmv/sxZXHmnvi1ICIdyjb4jiQ4lixUZf7KCIf0O9P
Y+PLHqZqPV1Qqj6H+gH2MNxYRGEyCsJeGsgEyXHv8g22e5dj0PQblTiDL2OdWFg=
=jSg0
-----END PGP SIGNATURE-----

From stian at redhat.com  Thu Oct 23 15:02:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Oct 2014 15:02:23 -0400 (EDT)
Subject: [keycloak-dev] Any more issues for 1.0.3.Final
In-Reply-To: <1725436906.75558684.1414090906850.JavaMail.zimbra@redhat.com>
Message-ID: <1967228117.75559055.1414090943834.JavaMail.zimbra@redhat.com>

Is there any more issues that needs resolving for 1.0.3.Final or are we ready to release?

If there's nothing more I'm releasing tomorrow.

From matzew at apache.org  Fri Oct 24 06:54:12 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 24 Oct 2014 12:54:12 +0200
Subject: [keycloak-dev] Keycloak 1.0.3 branch
Message-ID: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>

Hi,

I tried picking up KC 1.0.3.Final on our 1.0.x branch:

* deployment of both WARs went fine
* accessing the `http://localhost:8080/ag-push` offers me the initial
login for admin:123
* clicking login did _NOT_ redirect me to the form where I am supposed
to update the default password.


On WildFly, I got a blank page and this stack-trace:
```
12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
task-10) Failed executing POST
/realms/aerogear/tokens/auth/request/login:
org.keycloak.services.ForbiddenException
	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
[keycloak-services-1.0.3.Final.jar:]
	at org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
[keycloak-services-1.0.3.Final.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_65]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_65]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_65]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
[resteasy-jaxrs-3.0.8.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
[jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
[keycloak-services-1.0.3.Final.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
[keycloak-services-1.0.3.Final.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
[undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_65]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_65]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
```

On EAP 6.3. I got a 403, with this stack-trace:
```
12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
(http-/0.0.0.0:8080-3) Failed executing POST
/realms/aerogear/tokens/auth/request/login:
org.keycloak.services.ForbiddenException
	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
[keycloak-services-1.0.3.Final.jar:]
	at org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
[keycloak-services-1.0.3.Final.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.7.0_65]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[rt.jar:1.7.0_65]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_65]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
[keycloak-services-1.0.3.Final.jar:]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
[keycloak-services-1.0.3.Final.jar:]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
[jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
```



-- 
Matthias Wessendorf

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

From bburke at redhat.com  Fri Oct 24 08:41:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Oct 2014 08:41:05 -0400
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
Message-ID: <544A48E1.5070308@redhat.com>

Why is there a CSRF check in processLogin?  The user isn't even logged 
in yet and no credentials have been processed.

On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
> Hi,
>
> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
>
> * deployment of both WARs went fine
> * accessing the `http://localhost:8080/ag-push`  offers me the initial login for admin:123
> * clicking login did _NOT_ redirect me to the form where I am supposed to update the default password.
>
>
> On WildFly, I got a blank page and this stack-trace:
> ```
> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-10) Failed executing POST /realms/aerogear/tokens/auth/request/login: org.keycloak.services.ForbiddenException
> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39) [keycloak-services-1.0.3.Final.jar:]
> 	at org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479) [keycloak-services-1.0.3.Final.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0.3.Final.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.0.3.Final.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> ```
>
> On EAP 6.3. I got a 403, with this stack-trace:
> ```
> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher] (http-/0.0.0.0:8080-3) Failed executing POST /realms/aerogear/tokens/auth/request/login: org.keycloak.services.ForbiddenException
> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39) [keycloak-services-1.0.3.Final.jar:]
> 	at org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479) [keycloak-services-1.0.3.Final.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0.3.Final.jar:]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.0.3.Final.jar:]
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> 	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> ```
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Oct 24 09:47:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Oct 2014 09:47:16 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <544A48E1.5070308@redhat.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
Message-ID: <1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>

Not sure TBH

I was thinking that someone could post from an external page and inject a JS script to capture the username/password. Basically post an invalid username (<script>...</script>) where the script also removes the invalid user/password warning. Then when the user enters username/password the script could capture the username/password and send it somewhere.

But, then once I'd done that I realised that we should escape any html entered in input fields any ways so I fixed that, which kinda made the other fix pointless.

I reckon I'll remove it! Unless for some reason we want to prevent folks from posting directly to login/registration endpoints?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 October, 2014 2:41:05 PM
> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> 
> Why is there a CSRF check in processLogin?  The user isn't even logged
> in yet and no credentials have been processed.
> 
> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
> > Hi,
> >
> > I tried picking up KC 1.0.3.Final on our 1.0.x branch:
> >
> > * deployment of both WARs went fine
> > * accessing the `http://localhost:8080/ag-push`  offers me the initial
> > login for admin:123
> > * clicking login did _NOT_ redirect me to the form where I am supposed to
> > update the default password.
> >
> >
> > On WildFly, I got a blank page and this stack-trace:
> > ```
> > 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
> > task-10) Failed executing POST /realms/aerogear/tokens/auth/request/login:
> > org.keycloak.services.ForbiddenException
> > 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at
> > 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	[rt.jar:1.7.0_65]
> > 	at
> > 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > 	[rt.jar:1.7.0_65]
> > 	at
> > 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 	[rt.jar:1.7.0_65]
> > 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> > 	at
> > 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > 	[resteasy-jaxrs-3.0.8.Final.jar:]
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > 	[jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> > 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > 	at
> > 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > 	[rt.jar:1.7.0_65]
> > 	at
> > 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > 	[rt.jar:1.7.0_65]
> > 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > ```
> >
> > On EAP 6.3. I got a 403, with this stack-trace:
> > ```
> > 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
> > (http-/0.0.0.0:8080-3) Failed executing POST
> > /realms/aerogear/tokens/auth/request/login:
> > org.keycloak.services.ForbiddenException
> > 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at
> > 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > 	[rt.jar:1.7.0_65]
> > 	at
> > 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > 	[rt.jar:1.7.0_65]
> > 	at
> > 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > 	[rt.jar:1.7.0_65]
> > 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> > 	at
> > 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at
> > 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> > 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> > 	[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> > 	[keycloak-services-1.0.3.Final.jar:]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> > 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > 	at
> > 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> > 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > 	at
> > 	org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> > 	[jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > 	at
> > 	org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at
> > 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> > 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > ```
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Oct 24 10:09:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Oct 2014 10:09:57 -0400
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
	<1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
Message-ID: <544A5DB5.7030804@redhat.com>

What you're describing isn't CSRF, it is an injection attack.  So CSRF 
doesn't apply.

In 1.1 you can't post directly to processLogin or processRegister as you 
have to have a client session set up and the client session's state must 
be AUTHENTICATE




On 10/24/2014 9:47 AM, Stian Thorgersen wrote:
> Not sure TBH
>
> I was thinking that someone could post from an external page and inject a JS script to capture the username/password. Basically post an invalid username (<script>...</script>) where the script also removes the invalid user/password warning. Then when the user enters username/password the script could capture the username/password and send it somewhere.
>
> But, then once I'd done that I realised that we should escape any html entered in input fields any ways so I fixed that, which kinda made the other fix pointless.
>
> I reckon I'll remove it! Unless for some reason we want to prevent folks from posting directly to login/registration endpoints?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 24 October, 2014 2:41:05 PM
>> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
>>
>> Why is there a CSRF check in processLogin?  The user isn't even logged
>> in yet and no credentials have been processed.
>>
>> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
>>> Hi,
>>>
>>> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
>>>
>>> * deployment of both WARs went fine
>>> * accessing the `http://localhost:8080/ag-push`  offers me the initial
>>> login for admin:123
>>> * clicking login did _NOT_ redirect me to the form where I am supposed to
>>> update the default password.
>>>
>>>
>>> On WildFly, I got a blank page and this stack-trace:
>>> ```
>>> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
>>> task-10) Failed executing POST /realms/aerogear/tokens/auth/request/login:
>>> org.keycloak.services.ForbiddenException
>>> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at
>>> 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 	[rt.jar:1.7.0_65]
>>> 	at
>>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> 	[rt.jar:1.7.0_65]
>>> 	at
>>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> 	[rt.jar:1.7.0_65]
>>> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
>>> 	at
>>> 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
>>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>> 	[jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>> 	at
>>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>> 	at
>>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
>>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
>>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>> 	at
>>> 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> 	[rt.jar:1.7.0_65]
>>> 	at
>>> 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> 	[rt.jar:1.7.0_65]
>>> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>>> ```
>>>
>>> On EAP 6.3. I got a 403, with this stack-trace:
>>> ```
>>> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
>>> (http-/0.0.0.0:8080-3) Failed executing POST
>>> /realms/aerogear/tokens/auth/request/login:
>>> org.keycloak.services.ForbiddenException
>>> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at
>>> 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> 	[rt.jar:1.7.0_65]
>>> 	at
>>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> 	[rt.jar:1.7.0_65]
>>> 	at
>>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> 	[rt.jar:1.7.0_65]
>>> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
>>> 	at
>>> 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at
>>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>>> 	[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
>>> 	[keycloak-services-1.0.3.Final.jar:]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
>>> 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>>> 	at
>>> 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
>>> 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>>> 	at
>>> 	org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>>> 	[jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>>> 	at
>>> 	org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at
>>> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>>> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>>> ```
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> sessions: http://www.slideshare.net/mwessendorf
>>> twitter: http://twitter.com/mwessendorf
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Mon Oct 27 03:21:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Oct 2014 03:21:13 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <544A5DB5.7030804@redhat.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
	<1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
	<544A5DB5.7030804@redhat.com>
Message-ID: <1805880846.497049.1414394473464.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: Friday, 24 October, 2014 4:09:57 PM
> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> 
> What you're describing isn't CSRF, it is an injection attack.  So CSRF
> doesn't apply.

Yep, I know. It was a moment of brain malfunctioning!

> 
> In 1.1 you can't post directly to processLogin or processRegister as you
> have to have a client session set up and the client session's state must
> be AUTHENTICATE

I'll remove it - as you say it's being added in 1.1 in any case, and 1.0.x shouldn't change how things functions any ways.

> 
> 
> 
> 
> On 10/24/2014 9:47 AM, Stian Thorgersen wrote:
> > Not sure TBH
> >
> > I was thinking that someone could post from an external page and inject a
> > JS script to capture the username/password. Basically post an invalid
> > username (<script>...</script>) where the script also removes the invalid
> > user/password warning. Then when the user enters username/password the
> > script could capture the username/password and send it somewhere.
> >
> > But, then once I'd done that I realised that we should escape any html
> > entered in input fields any ways so I fixed that, which kinda made the
> > other fix pointless.
> >
> > I reckon I'll remove it! Unless for some reason we want to prevent folks
> > from posting directly to login/registration endpoints?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 24 October, 2014 2:41:05 PM
> >> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> >>
> >> Why is there a CSRF check in processLogin?  The user isn't even logged
> >> in yet and no credentials have been processed.
> >>
> >> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
> >>> Hi,
> >>>
> >>> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
> >>>
> >>> * deployment of both WARs went fine
> >>> * accessing the `http://localhost:8080/ag-push`  offers me the initial
> >>> login for admin:123
> >>> * clicking login did _NOT_ redirect me to the form where I am supposed to
> >>> update the default password.
> >>>
> >>>
> >>> On WildFly, I got a blank page and this stack-trace:
> >>> ```
> >>> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
> >>> task-10) Failed executing POST
> >>> /realms/aerogear/tokens/auth/request/login:
> >>> org.keycloak.services.ForbiddenException
> >>> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at
> >>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at
> >>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> >>> 	at
> >>> 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> >>> 	[resteasy-jaxrs-3.0.8.Final.jar:]
> >>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> >>> 	[jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> >>> 	at
> >>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> >>> 	at
> >>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> >>> 	[undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> >>> 	[undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >>> 	at
> >>> 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at
> >>> 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> >>> ```
> >>>
> >>> On EAP 6.3. I got a 403, with this stack-trace:
> >>> ```
> >>> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
> >>> (http-/0.0.0.0:8080-3) Failed executing POST
> >>> /realms/aerogear/tokens/auth/request/login:
> >>> org.keycloak.services.ForbiddenException
> >>> 	at org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at
> >>> 	sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at
> >>> 	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>> 	[rt.jar:1.7.0_65]
> >>> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> >>> 	at
> >>> 	org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at
> >>> 	org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> >>> 	[resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> >>> 	[jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> >>> 	[keycloak-services-1.0.3.Final.jar:]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> >>> 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >>> 	at
> >>> 	org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> >>> 	[jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >>> 	at
> >>> 	org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> >>> 	[jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >>> 	at
> >>> 	org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at
> >>> 	org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> >>> 	[jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >>> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> >>> ```
> >>>
> >>>
> >>>
> >>> --
> >>> Matthias Wessendorf
> >>>
> >>> blog: http://matthiaswessendorf.wordpress.com/
> >>> sessions: http://www.slideshare.net/mwessendorf
> >>> twitter: http://twitter.com/mwessendorf
> >>>
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From matzew at apache.org  Mon Oct 27 05:00:23 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 27 Oct 2014 10:00:23 +0100
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <1805880846.497049.1414394473464.JavaMail.zimbra@redhat.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
	<1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
	<544A5DB5.7030804@redhat.com>
	<1805880846.497049.1414394473464.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2T4hwmN0oq23BYE8H=qLd3P0ZT9VubCn7VcVX8hngAQzA@mail.gmail.com>

On Mon, Oct 27, 2014 at 8:21 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Friday, 24 October, 2014 4:09:57 PM
> > Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> >
> > What you're describing isn't CSRF, it is an injection attack.  So CSRF
> > doesn't apply.
>
> Yep, I know. It was a moment of brain malfunctioning!
>
> >
> > In 1.1 you can't post directly to processLogin or processRegister as you
> > have to have a client session set up and the client session's state must
> > be AUTHENTICATE
>
> I'll remove it - as you say it's being added in 1.1 in any case, and 1.0.x
> shouldn't change how things functions any ways.
>

Hi all,

I tested the 'new' 1.0.x branch -> works all fine now


>
> >
> >
> >
> >
> > On 10/24/2014 9:47 AM, Stian Thorgersen wrote:
> > > Not sure TBH
> > >
> > > I was thinking that someone could post from an external page and
> inject a
> > > JS script to capture the username/password. Basically post an invalid
> > > username (<script>...</script>) where the script also removes the
> invalid
> > > user/password warning. Then when the user enters username/password the
> > > script could capture the username/password and send it somewhere.
> > >
> > > But, then once I'd done that I realised that we should escape any html
> > > entered in input fields any ways so I fixed that, which kinda made the
> > > other fix pointless.
> > >
> > > I reckon I'll remove it! Unless for some reason we want to prevent
> folks
> > > from posting directly to login/registration endpoints?
> > >
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: keycloak-dev at lists.jboss.org
> > >> Sent: Friday, 24 October, 2014 2:41:05 PM
> > >> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> > >>
> > >> Why is there a CSRF check in processLogin?  The user isn't even logged
> > >> in yet and no credentials have been processed.
> > >>
> > >> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
> > >>> Hi,
> > >>>
> > >>> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
> > >>>
> > >>> * deployment of both WARs went fine
> > >>> * accessing the `http://localhost:8080/ag-push`  offers me the
> initial
> > >>> login for admin:123
> > >>> * clicking login did _NOT_ redirect me to the form where I am
> supposed to
> > >>> update the default password.
> > >>>
> > >>>
> > >>> On WildFly, I got a blank page and this stack-trace:
> > >>> ```
> > >>> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler]
> (default
> > >>> task-10) Failed executing POST
> > >>> /realms/aerogear/tokens/auth/request/login:
> > >>> org.keycloak.services.ForbiddenException
> > >>>   at
> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
> [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > >>>   [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> > >>>   at
> > >>>
>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> > >>>   at
> > >>>
>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> > >>>   at
> > >>>
>  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > >>> ```
> > >>>
> > >>> On EAP 6.3. I got a 403, with this stack-trace:
> > >>> ```
> > >>> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
> > >>> (http-/0.0.0.0:8080-3) Failed executing POST
> > >>> /realms/aerogear/tokens/auth/request/login:
> > >>> org.keycloak.services.ForbiddenException
> > >>>   at
> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >>>   [rt.jar:1.7.0_65]
> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
> [rt.jar:1.7.0_65]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at
> > >>>
>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> > >>>
>  [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> > >>>   [keycloak-services-1.0.3.Final.jar:]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > >>>   at
> > >>>
>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > >>>   at
> > >>>
>  org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> > >>>   [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> > >>>   at
> > >>>
>  org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at
> > >>>
>  org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> > >>> ```
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Matthias Wessendorf
> > >>>
> > >>> blog: http://matthiaswessendorf.wordpress.com/
> > >>> sessions: http://www.slideshare.net/mwessendorf
> > >>> twitter: http://twitter.com/mwessendorf
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > >> --
> > >> Bill Burke
> > >> JBoss, a division of Red Hat
> > >> http://bill.burkecentral.com
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Matthias Wessendorf

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

From bburke at redhat.com  Mon Oct 27 12:53:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Oct 2014 12:53:58 -0400
Subject: [keycloak-dev] Making "hello world" with Wildfly easier
Message-ID: <544E78A6.1040301@redhat.com>

Bolek made a good point to me privately.  If you were creating a simple 
"hello world" app, would you use Keycloak?  Right now, there's a lot of 
configuration steps.

1. Install keycloak server and/or adapter (unless you are using the 
appliance distro.
2. Log into admin console
3. Create a realm
4. Create an application
5. Enter in all the configuration items
6. Extract a keycloak.json file (or service.xml)
7. Edit the WAR or add service.xml to standalone.xml
8. Back to admin console
9. Create some users

How could we make it better?

* Have a test realm pre-set up
* Keycloak adapter is aware of a locally installed server and of the 
test realm
* adapter an automatically registers the web app with the locally 
installed test realm.
* Have a JAAS User Federation SPI plugin and have it pre set up with the 
test realm.
* Have IP ACL per realm so that the test realm can't be accessed outside 
of localhost.

Other ideas?


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

From ssilvert at redhat.com  Mon Oct 27 13:21:04 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 27 Oct 2014 13:21:04 -0400
Subject: [keycloak-dev] Making "hello world" with Wildfly easier
In-Reply-To: <544E78A6.1040301@redhat.com>
References: <544E78A6.1040301@redhat.com>
Message-ID: <544E7F00.9040705@redhat.com>

It could be as simple as adding a single servlet context param to web.xml.

<context-param>
    <param-name>keycloak-realm</param-name>
    <param-value>myrealm</param-value>
</context-param>

The Keycloak subsystem sees that and sets up all the defaults you need.  
It could create the realm, secure-deployment, datasource, start an auth 
server instance, etc.

<
On 10/27/2014 12:53 PM, Bill Burke wrote:
> Bolek made a good point to me privately.  If you were creating a simple
> "hello world" app, would you use Keycloak?  Right now, there's a lot of
> configuration steps.
>
> 1. Install keycloak server and/or adapter (unless you are using the
> appliance distro.
> 2. Log into admin console
> 3. Create a realm
> 4. Create an application
> 5. Enter in all the configuration items
> 6. Extract a keycloak.json file (or service.xml)
> 7. Edit the WAR or add service.xml to standalone.xml
> 8. Back to admin console
> 9. Create some users
>
> How could we make it better?
>
> * Have a test realm pre-set up
> * Keycloak adapter is aware of a locally installed server and of the
> test realm
> * adapter an automatically registers the web app with the locally
> installed test realm.
> * Have a JAAS User Federation SPI plugin and have it pre set up with the
> test realm.
> * Have IP ACL per realm so that the test realm can't be accessed outside
> of localhost.
>
> Other ideas?
>
>


From bburke at redhat.com  Mon Oct 27 14:17:05 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Oct 2014 14:17:05 -0400
Subject: [keycloak-dev] Making "hello world" with Wildfly easier
In-Reply-To: <544E7F00.9040705@redhat.com>
References: <544E78A6.1040301@redhat.com> <544E7F00.9040705@redhat.com>
Message-ID: <544E8C21.1040505@redhat.com>

Why that?  Just do this:

     <login-config>
         <auth-method>KEYCLOAK</auth-method>
         <realm-name>myrealm</realm-name>
     </login-config>

Then automatically register the app using the war service name.

We could extend this to a URL:

     <login-config>
         <auth-method>KEYCLOAK</auth-method>
 
<realm-name>https://keycloak.idp.com/auth/realms/myrealm</realm-name>
     </login-config>









On 10/27/2014 1:21 PM, Stan Silvert wrote:
> It could be as simple as adding a single servlet context param to web.xml.
>
> <context-param>
>      <param-name>keycloak-realm</param-name>
>      <param-value>myrealm</param-value>
> </context-param>
>
> The Keycloak subsystem sees that and sets up all the defaults you need.
> It could create the realm, secure-deployment, datasource, start an auth
> server instance, etc.
>
> <
> On 10/27/2014 12:53 PM, Bill Burke wrote:
>> Bolek made a good point to me privately.  If you were creating a simple
>> "hello world" app, would you use Keycloak?  Right now, there's a lot of
>> configuration steps.
>>
>> 1. Install keycloak server and/or adapter (unless you are using the
>> appliance distro.
>> 2. Log into admin console
>> 3. Create a realm
>> 4. Create an application
>> 5. Enter in all the configuration items
>> 6. Extract a keycloak.json file (or service.xml)
>> 7. Edit the WAR or add service.xml to standalone.xml
>> 8. Back to admin console
>> 9. Create some users
>>
>> How could we make it better?
>>
>> * Have a test realm pre-set up
>> * Keycloak adapter is aware of a locally installed server and of the
>> test realm
>> * adapter an automatically registers the web app with the locally
>> installed test realm.
>> * Have a JAAS User Federation SPI plugin and have it pre set up with the
>> test realm.
>> * Have IP ACL per realm so that the test realm can't be accessed outside
>> of localhost.
>>
>> Other ideas?
>>
>>
>
> _______________________________________________
> 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  Mon Oct 27 14:38:39 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 27 Oct 2014 14:38:39 -0400
Subject: [keycloak-dev] Making "hello world" with Wildfly easier
In-Reply-To: <544E8C21.1040505@redhat.com>
References: <544E78A6.1040301@redhat.com> <544E7F00.9040705@redhat.com>
	<544E8C21.1040505@redhat.com>
Message-ID: <544E912F.5080904@redhat.com>

I agree.  Using login-config makes more sense.

We just need to put together a wish list of what we want the subsystem 
to do when it sees that.

On 10/27/2014 2:17 PM, Bill Burke wrote:
> Why that?  Just do this:
>
>       <login-config>
>           <auth-method>KEYCLOAK</auth-method>
>           <realm-name>myrealm</realm-name>
>       </login-config>
>
> Then automatically register the app using the war service name.
>
> We could extend this to a URL:
>
>       <login-config>
>           <auth-method>KEYCLOAK</auth-method>
>   
> <realm-name>https://keycloak.idp.com/auth/realms/myrealm</realm-name>
>       </login-config>
>
>
>
>
>
>
>
>
>
> On 10/27/2014 1:21 PM, Stan Silvert wrote:
>> It could be as simple as adding a single servlet context param to web.xml.
>>
>> <context-param>
>>       <param-name>keycloak-realm</param-name>
>>       <param-value>myrealm</param-value>
>> </context-param>
>>
>> The Keycloak subsystem sees that and sets up all the defaults you need.
>> It could create the realm, secure-deployment, datasource, start an auth
>> server instance, etc.
>>
>> <
>> On 10/27/2014 12:53 PM, Bill Burke wrote:
>>> Bolek made a good point to me privately.  If you were creating a simple
>>> "hello world" app, would you use Keycloak?  Right now, there's a lot of
>>> configuration steps.
>>>
>>> 1. Install keycloak server and/or adapter (unless you are using the
>>> appliance distro.
>>> 2. Log into admin console
>>> 3. Create a realm
>>> 4. Create an application
>>> 5. Enter in all the configuration items
>>> 6. Extract a keycloak.json file (or service.xml)
>>> 7. Edit the WAR or add service.xml to standalone.xml
>>> 8. Back to admin console
>>> 9. Create some users
>>>
>>> How could we make it better?
>>>
>>> * Have a test realm pre-set up
>>> * Keycloak adapter is aware of a locally installed server and of the
>>> test realm
>>> * adapter an automatically registers the web app with the locally
>>> installed test realm.
>>> * Have a JAAS User Federation SPI plugin and have it pre set up with the
>>> test realm.
>>> * Have IP ACL per realm so that the test realm can't be accessed outside
>>> of localhost.
>>>
>>> Other ideas?
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From mposolda at redhat.com  Mon Oct 27 18:40:37 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 27 Oct 2014 23:40:37 +0100
Subject: [keycloak-dev] Making "hello world" with Wildfly easier
In-Reply-To: <544E78A6.1040301@redhat.com>
References: <544E78A6.1040301@redhat.com>
Message-ID: <544EC9E5.8040105@redhat.com>

On 27.10.2014 17:53, Bill Burke wrote:
> Bolek made a good point to me privately.  If you were creating a simple
> "hello world" app, would you use Keycloak?  Right now, there's a lot of
> configuration steps.
>
> 1. Install keycloak server and/or adapter (unless you are using the
> appliance distro.
> 2. Log into admin console
> 3. Create a realm
> 4. Create an application
> 5. Enter in all the configuration items
> 6. Extract a keycloak.json file (or service.xml)
> 7. Edit the WAR or add service.xml to standalone.xml
> 8. Back to admin console
> 9. Create some users
>
> How could we make it better?
>
> * Have a test realm pre-set up
I wonder that we can do this as part of keycloak-bootstrap.json for 
this? We can remove ApplianceBootstrap and add this 
keycloak-bootstrap.json file with basic data for both "master" and 
"test" realm. This will allow people that they can add more users into 
'master' or 'test' realm, or in production they can remove 'test' realm 
entirely etc.
> * Keycloak adapter is aware of a locally installed server and of the
> test realm
> * adapter an automatically registers the web app with the locally
> installed test realm.
Maybe we can partially support specification 
http://openid.net/specs/openid-connect-registration-1_0.html ? Not sure 
how far we want to go with that. If we allow this auto-registration just 
for the "test" realm (just development setup), then we may not need any 
additional security of adapters to keycloak.

Marek
> * Have a JAAS User Federation SPI plugin and have it pre set up with the
> test realm.
> * Have IP ACL per realm so that the test realm can't be accessed outside
> of localhost.
>
> Other ideas?
>
>


From mposolda at redhat.com  Mon Oct 27 18:49:43 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 27 Oct 2014 23:49:43 +0100
Subject: [keycloak-dev] Pushed docs for adapters clustering
Message-ID: <544ECC07.3000208@redhat.com>

I've pushed docs for adapters clustering and support for store account 
info in cookie https://issues.jboss.org/browse/KEYCLOAK-702, which seems 
to be last major thing for clustering support on adapters side required 
for release.

I am out tomorrow on public holidays, but back on Wednesday ready to 
help with whatever is needed for release (there is some probability to 
being stucked on portal again, but hopefully not...)

Marek

From stian at redhat.com  Tue Oct 28 03:08:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 03:08:09 -0400 (EDT)
Subject: [keycloak-dev] Pushed docs for adapters clustering
In-Reply-To: <544ECC07.3000208@redhat.com>
References: <544ECC07.3000208@redhat.com>
Message-ID: <943703585.1390118.1414480089259.JavaMail.zimbra@redhat.com>

Great, thanks :)

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 October, 2014 11:49:43 PM
> Subject: [keycloak-dev] Pushed docs for adapters clustering
> 
> I've pushed docs for adapters clustering and support for store account
> info in cookie https://issues.jboss.org/browse/KEYCLOAK-702, which seems
> to be last major thing for clustering support on adapters side required
> for release.
> 
> I am out tomorrow on public holidays, but back on Wednesday ready to
> help with whatever is needed for release (there is some probability to
> being stucked on portal again, but hopefully not...)
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From matzew at apache.org  Tue Oct 28 08:30:30 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 28 Oct 2014 13:30:30 +0100
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <CAAg5f2T4hwmN0oq23BYE8H=qLd3P0ZT9VubCn7VcVX8hngAQzA@mail.gmail.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
	<1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
	<544A5DB5.7030804@redhat.com>
	<1805880846.497049.1414394473464.JavaMail.zimbra@redhat.com>
	<CAAg5f2T4hwmN0oq23BYE8H=qLd3P0ZT9VubCn7VcVX8hngAQzA@mail.gmail.com>
Message-ID: <CAAg5f2SQON8+EDeTE+3QS81friyyyBFB0WBtJw4ed=opfpQ45A@mail.gmail.com>

Hi,

I tested the branch again, with our recent changes, where we are
introducing an new role, besides the previous admin

The Branch_1_0 (1.0.3) works perfectly fine with our stuff (tested
WildFly8.1 and EAP 6.3)

On Mon, Oct 27, 2014 at 10:00 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Mon, Oct 27, 2014 at 8:21 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Bill Burke" <bburke at redhat.com>
>> > To: "Stian Thorgersen" <stian at redhat.com>
>> > Cc: keycloak-dev at lists.jboss.org
>> > Sent: Friday, 24 October, 2014 4:09:57 PM
>> > Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
>> >
>> > What you're describing isn't CSRF, it is an injection attack.  So CSRF
>> > doesn't apply.
>>
>> Yep, I know. It was a moment of brain malfunctioning!
>>
>> >
>> > In 1.1 you can't post directly to processLogin or processRegister as you
>> > have to have a client session set up and the client session's state must
>> > be AUTHENTICATE
>>
>> I'll remove it - as you say it's being added in 1.1 in any case, and
>> 1.0.x shouldn't change how things functions any ways.
>>
>
> Hi all,
>
> I tested the 'new' 1.0.x branch -> works all fine now
>
>
>>
>> >
>> >
>> >
>> >
>> > On 10/24/2014 9:47 AM, Stian Thorgersen wrote:
>> > > Not sure TBH
>> > >
>> > > I was thinking that someone could post from an external page and
>> inject a
>> > > JS script to capture the username/password. Basically post an invalid
>> > > username (<script>...</script>) where the script also removes the
>> invalid
>> > > user/password warning. Then when the user enters username/password the
>> > > script could capture the username/password and send it somewhere.
>> > >
>> > > But, then once I'd done that I realised that we should escape any html
>> > > entered in input fields any ways so I fixed that, which kinda made the
>> > > other fix pointless.
>> > >
>> > > I reckon I'll remove it! Unless for some reason we want to prevent
>> folks
>> > > from posting directly to login/registration endpoints?
>> > >
>> > > ----- Original Message -----
>> > >> From: "Bill Burke" <bburke at redhat.com>
>> > >> To: keycloak-dev at lists.jboss.org
>> > >> Sent: Friday, 24 October, 2014 2:41:05 PM
>> > >> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
>> > >>
>> > >> Why is there a CSRF check in processLogin?  The user isn't even
>> logged
>> > >> in yet and no credentials have been processed.
>> > >>
>> > >> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
>> > >>> Hi,
>> > >>>
>> > >>> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
>> > >>>
>> > >>> * deployment of both WARs went fine
>> > >>> * accessing the `http://localhost:8080/ag-push`
>> <http://localhost:8080/ag-push>  offers me the initial
>> > >>> login for admin:123
>> > >>> * clicking login did _NOT_ redirect me to the form where I am
>> supposed to
>> > >>> update the default password.
>> > >>>
>> > >>>
>> > >>> On WildFly, I got a blank page and this stack-trace:
>> > >>> ```
>> > >>> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler]
>> (default
>> > >>> task-10) Failed executing POST
>> > >>> /realms/aerogear/tokens/auth/request/login:
>> > >>> org.keycloak.services.ForbiddenException
>> > >>>   at
>> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
>> [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
>> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> > >>>   [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>> > >>>   at
>> > >>>
>>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>> > >>>   at
>> > >>>
>>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
>> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
>> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>> > >>>   at
>> > >>>
>>  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>> > >>> ```
>> > >>>
>> > >>> On EAP 6.3. I got a 403, with this stack-trace:
>> > >>> ```
>> > >>> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
>> > >>> (http-/0.0.0.0:8080-3) Failed executing POST
>> > >>> /realms/aerogear/tokens/auth/request/login:
>> > >>> org.keycloak.services.ForbiddenException
>> > >>>   at
>> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> > >>>   [rt.jar:1.7.0_65]
>> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
>> [rt.jar:1.7.0_65]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at
>> > >>>
>>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
>> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
>> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
>> > >>>
>>  [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
>> > >>>   [keycloak-services-1.0.3.Final.jar:]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
>> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>> > >>>   at
>> > >>>
>>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
>> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>> > >>>   at
>> > >>>
>>  org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
>> > >>>   [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at
>> > >>>
>>  org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
>> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
>> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
>> > >>> ```
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Matthias Wessendorf
>> > >>>
>> > >>> blog: http://matthiaswessendorf.wordpress.com/
>> > >>> sessions: http://www.slideshare.net/mwessendorf
>> > >>> twitter: http://twitter.com/mwessendorf
>> > >>>
>> > >>>
>> > >>> _______________________________________________
>> > >>> keycloak-dev mailing list
>> > >>> keycloak-dev at lists.jboss.org
>> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > >>
>> > >> --
>> > >> Bill Burke
>> > >> JBoss, a division of Red Hat
>> > >> http://bill.burkecentral.com
>> > >> _______________________________________________
>> > >> keycloak-dev mailing list
>> > >> keycloak-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>
>> >
>> > --
>> > Bill Burke
>> > JBoss, a division of Red Hat
>> > http://bill.burkecentral.com
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

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

From stian at redhat.com  Tue Oct 28 08:36:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 08:36:04 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.3 branch problem
In-Reply-To: <CAAg5f2SQON8+EDeTE+3QS81friyyyBFB0WBtJw4ed=opfpQ45A@mail.gmail.com>
References: <CAAg5f2QHDfN51we_F9Qp0UY4U=bsrQ=wKH=dU0MwqECdWOOxhQ@mail.gmail.com>
	<544A48E1.5070308@redhat.com>
	<1655650033.76072525.1414158436077.JavaMail.zimbra@redhat.com>
	<544A5DB5.7030804@redhat.com>
	<1805880846.497049.1414394473464.JavaMail.zimbra@redhat.com>
	<CAAg5f2T4hwmN0oq23BYE8H=qLd3P0ZT9VubCn7VcVX8hngAQzA@mail.gmail.com>
	<CAAg5f2SQON8+EDeTE+3QS81friyyyBFB0WBtJw4ed=opfpQ45A@mail.gmail.com>
Message-ID: <1392294517.1613234.1414499764955.JavaMail.zimbra@redhat.com>

Great, thanks for the update.

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 28 October, 2014 1:30:30 PM
> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> 
> Hi,
> 
> I tested the branch again, with our recent changes, where we are
> introducing an new role, besides the previous admin
> 
> The Branch_1_0 (1.0.3) works perfectly fine with our stuff (tested
> WildFly8.1 and EAP 6.3)
> 
> On Mon, Oct 27, 2014 at 10:00 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> 
> >
> >
> > On Mon, Oct 27, 2014 at 8:21 AM, Stian Thorgersen <stian at redhat.com>
> > wrote:
> >
> >>
> >>
> >> ----- Original Message -----
> >> > From: "Bill Burke" <bburke at redhat.com>
> >> > To: "Stian Thorgersen" <stian at redhat.com>
> >> > Cc: keycloak-dev at lists.jboss.org
> >> > Sent: Friday, 24 October, 2014 4:09:57 PM
> >> > Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> >> >
> >> > What you're describing isn't CSRF, it is an injection attack.  So CSRF
> >> > doesn't apply.
> >>
> >> Yep, I know. It was a moment of brain malfunctioning!
> >>
> >> >
> >> > In 1.1 you can't post directly to processLogin or processRegister as you
> >> > have to have a client session set up and the client session's state must
> >> > be AUTHENTICATE
> >>
> >> I'll remove it - as you say it's being added in 1.1 in any case, and
> >> 1.0.x shouldn't change how things functions any ways.
> >>
> >
> > Hi all,
> >
> > I tested the 'new' 1.0.x branch -> works all fine now
> >
> >
> >>
> >> >
> >> >
> >> >
> >> >
> >> > On 10/24/2014 9:47 AM, Stian Thorgersen wrote:
> >> > > Not sure TBH
> >> > >
> >> > > I was thinking that someone could post from an external page and
> >> inject a
> >> > > JS script to capture the username/password. Basically post an invalid
> >> > > username (<script>...</script>) where the script also removes the
> >> invalid
> >> > > user/password warning. Then when the user enters username/password the
> >> > > script could capture the username/password and send it somewhere.
> >> > >
> >> > > But, then once I'd done that I realised that we should escape any html
> >> > > entered in input fields any ways so I fixed that, which kinda made the
> >> > > other fix pointless.
> >> > >
> >> > > I reckon I'll remove it! Unless for some reason we want to prevent
> >> folks
> >> > > from posting directly to login/registration endpoints?
> >> > >
> >> > > ----- Original Message -----
> >> > >> From: "Bill Burke" <bburke at redhat.com>
> >> > >> To: keycloak-dev at lists.jboss.org
> >> > >> Sent: Friday, 24 October, 2014 2:41:05 PM
> >> > >> Subject: Re: [keycloak-dev] Keycloak 1.0.3 branch problem
> >> > >>
> >> > >> Why is there a CSRF check in processLogin?  The user isn't even
> >> logged
> >> > >> in yet and no credentials have been processed.
> >> > >>
> >> > >> On 10/24/2014 6:54 AM, Matthias Wessendorf wrote:
> >> > >>> Hi,
> >> > >>>
> >> > >>> I tried picking up KC 1.0.3.Final on our 1.0.x branch:
> >> > >>>
> >> > >>> * deployment of both WARs went fine
> >> > >>> * accessing the `http://localhost:8080/ag-push`
> >> <http://localhost:8080/ag-push>  offers me the initial
> >> > >>> login for admin:123
> >> > >>> * clicking login did _NOT_ redirect me to the form where I am
> >> supposed to
> >> > >>> update the default password.
> >> > >>>
> >> > >>>
> >> > >>> On WildFly, I got a blank page and this stack-trace:
> >> > >>> ```
> >> > >>> 12:47:35,859 WARN  [org.jboss.resteasy.core.ExceptionHandler]
> >> (default
> >> > >>> task-10) Failed executing POST
> >> > >>> /realms/aerogear/tokens/auth/request/login:
> >> > >>> org.keycloak.services.ForbiddenException
> >> > >>>   at
> >> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
> >> [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> >> > >>>   [resteasy-jaxrs-3.0.8.Final.jar:]
> >> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> >> > >>>   [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> >> > >>>   [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> >> > >>>   [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> >> > >>>   at
> >> > >>>
> >>  java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> >> > >>> ```
> >> > >>>
> >> > >>> On EAP 6.3. I got a 403, with this stack-trace:
> >> > >>> ```
> >> > >>> 12:50:06,377 WARN  [org.jboss.resteasy.core.SynchronousDispatcher]
> >> > >>> (http-/0.0.0.0:8080-3) Failed executing POST
> >> > >>> /realms/aerogear/tokens/auth/request/login:
> >> > >>> org.keycloak.services.ForbiddenException
> >> > >>>   at
> >> org.keycloak.services.util.CsrfHelper.csrfCheck(CsrfHelper.java:39)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.resources.TokenService.processLogin(TokenService.java:479)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> > >>>   [rt.jar:1.7.0_65]
> >> > >>>   at java.lang.reflect.Method.invoke(Method.java:606)
> >> [rt.jar:1.7.0_65]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:159)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:92)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
> >> > >>>   [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:]
> >> > >>>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
> >> > >>>
> >>  [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40)
> >> > >>>   [keycloak-services-1.0.3.Final.jar:]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> >> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
> >> > >>>   [jboss-as-jpa-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >> > >>>   at
> >> > >>>
> >>  org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
> >> > >>>   [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at
> >> > >>>
> >>  org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926)
> >> > >>>   [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4]
> >> > >>>   at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> >> > >>> ```
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>> Matthias Wessendorf
> >> > >>>
> >> > >>> blog: http://matthiaswessendorf.wordpress.com/
> >> > >>> sessions: http://www.slideshare.net/mwessendorf
> >> > >>> twitter: http://twitter.com/mwessendorf
> >> > >>>
> >> > >>>
> >> > >>> _______________________________________________
> >> > >>> keycloak-dev mailing list
> >> > >>> keycloak-dev at lists.jboss.org
> >> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> > >>>
> >> > >>
> >> > >> --
> >> > >> Bill Burke
> >> > >> JBoss, a division of Red Hat
> >> > >> http://bill.burkecentral.com
> >> > >> _______________________________________________
> >> > >> keycloak-dev mailing list
> >> > >> keycloak-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> > >>
> >> >
> >> > --
> >> > Bill Burke
> >> > JBoss, a division of Red Hat
> >> > http://bill.burkecentral.com
> >> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> 
> 
> 
> --
> Matthias Wessendorf
> 
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> 

From stian at redhat.com  Tue Oct 28 08:49:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 08:49:32 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.3.Final released
In-Reply-To: <4452794.1620122.1414500547828.JavaMail.zimbra@redhat.com>
Message-ID: <420032169.1620303.1414500572845.JavaMail.zimbra@redhat.com>

Another security and bug fix release in the 1.0 series.

For full details look in JIRA (https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20%3D%201.0.3.Final%20AND%20resolution%20%3D%20Done).

From stian at redhat.com  Tue Oct 28 09:09:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 09:09:29 -0400 (EDT)
Subject: [keycloak-dev] Proposed changes to access code
In-Reply-To: <639168591.1626974.1414501041880.JavaMail.zimbra@redhat.com>
Message-ID: <1129332998.1633705.1414501769986.JavaMail.zimbra@redhat.com>

We have a few issues with how we generate access codes:

* Abuse of RSA
* SHA-1 is no good
* Action + timestamp is guessable (this may just be theoretical)
* Both key and code query params sent in emails (making the links longer that necessary)

To resolve these issues I propose:

* When realm keys are updated we generate a realm code secret (UUID) - this is a secret required to create valid codes
* When the action and timestamp is updated we generate a action key (UUID) - this is a unique identifier for that specific action

Then an access code is created with:

    MessageDigest digest = MessageDigest.getInstance("sha-256");
    digest.update(realm.getCodeSecret());
    digest.update("/".getBytes());
    digest.update(clientSession.getActionKey());
            
    String hash = Base64Url.encode(digest.digest());

    StringBuilder sb = new StringBuilder();
    sb.append(hash);
    sb.append(".");
    sb.append(clientSession.getId());
            
    String code = sb.toString();

An example access code will now be:

    Ld_L-Ta-tSpQMxGimEIpM4rq57KoplcN_3QxujUsMlM.6d102340-a7fd-44b8-93fd-ed6a8e8a4a15

From stian at redhat.com  Tue Oct 28 11:54:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 11:54:35 -0400 (EDT)
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <1077402503.1902082.1414510785456.JavaMail.zimbra@redhat.com>
Message-ID: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>

Hi,

I merged the PR into multi-tenant-adapter branch. It looks good, but I've got a few comments/suggestions:

Adapter:

1. Change <name> in integration/adapter-core/pom.xml - can you send this as a separate PR directly to master?
2. With the updates to AdapterDeploymentContext it's always required to pass request, so we can just remove getDeployment and always use resolveDeployment
3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out the realm if the session was serialized? when adapter is clustered we support serializing the session
4. KeycloakAuthenticatorValve.initInternal - just do a warn + unconfigured to make it behave same as if keycloak-server.json is missing, and drop the comment
5. KeycloakServletExtension.handleDeployment - same as above
6. CatalinaCookieTokenStore.checkPrincipalFromCookie - if cookie has different realm I'd say the log should at least be a warn, is this not a significant problem?
7. CatalinaSessionTokenStore.checkCurrentToken - same as above isn't cookie with different realm a pretty big issue?

Docs:

1. Move multi-tenancy documentation into adapters section

Examples:

1. Remove multi-tenant example (it's just to complex for us to maintain it)
2. Rename simple-multi-tenant example to multi-tenant
3. In simple-multi-tenant/README.MD can you remove instructions on starting server (we have separate instructions for that, and assume a user can do it by the time they're looking at examples), also remove comments about docker (we need to focus examples and not confuse users by introducing other concepts). Also, why does it instruct the user to start on 8180?
4. Remove/improve "hackish" comment in PathBasedKeycloakConfigResolver
5. PathBasedKeycloakConfigResolver loads adapter settings from json on every request - this will be relatively expensive

From bburke at redhat.com  Tue Oct 28 12:07:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Oct 2014 12:07:28 -0400
Subject: [keycloak-dev] application importers SPI
Message-ID: <544FBF40.90604@redhat.com>

I created an admin SPI for importing applications.  ApplicationImporter. 
  Basically it will allocate a JAX-RS service that can be referenced 
under root/admin/realms/{realm}/application-importers/{id}

Admin console applicaiton list page now has a "import" button.  This 
brings you to a page where you can import one or more applications from 
a selected format.  Right now, I only support "SAML 2.0 Entity 
Descriptor", but we should add one for our own JSON format, and OIDC too.

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

From stian at redhat.com  Tue Oct 28 14:47:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Oct 2014 14:47:21 -0400 (EDT)
Subject: [keycloak-dev] runit()
Message-ID: <1411652114.2061681.1414522041875.JavaMail.zimbra@redhat.com>

Out of curiosity what is:

    @Test
    @Ignore
    public void runit() throws Exception {
        Thread.sleep(10000000);
    }

My poor brain can't come up with a single use for it ;)

From bburke at redhat.com  Tue Oct 28 16:16:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Oct 2014 16:16:14 -0400
Subject: [keycloak-dev] runit()
In-Reply-To: <1411652114.2061681.1414522041875.JavaMail.zimbra@redhat.com>
References: <1411652114.2061681.1414522041875.JavaMail.zimbra@redhat.com>
Message-ID: <544FF98E.4030103@redhat.com>

running or debugging from the IDE within the test's environment.

On 10/28/2014 2:47 PM, Stian Thorgersen wrote:
> Out of curiosity what is:
>
>      @Test
>      @Ignore
>      public void runit() throws Exception {
>          Thread.sleep(10000000);
>      }
>
> My poor brain can't come up with a single use for it ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Oct 28 18:48:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Oct 2014 18:48:16 -0400
Subject: [keycloak-dev] ClientsManagementService explanation?
Message-ID: <54501D30.7050105@redhat.com>

Did you send out an email explaining what ClientsManagementService is? 
Also what changes you made to the adapters?  I'd like to review it.

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

From stian at redhat.com  Wed Oct 29 03:56:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 03:56:33 -0400 (EDT)
Subject: [keycloak-dev] runit()
In-Reply-To: <544FF98E.4030103@redhat.com>
References: <1411652114.2061681.1414522041875.JavaMail.zimbra@redhat.com>
	<544FF98E.4030103@redhat.com>
Message-ID: <1383816679.2393862.1414569393313.JavaMail.zimbra@redhat.com>

Ah, makes sense - could you in the future comment out the @Test instead of adding @Ignore? @Ignore'd tests are shown in test results, IMO they should be used for tests that are not currently passing (for example a bug that hasn't been fixed).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 28 October, 2014 9:16:14 PM
> Subject: Re: [keycloak-dev] runit()
> 
> running or debugging from the IDE within the test's environment.
> 
> On 10/28/2014 2:47 PM, Stian Thorgersen wrote:
> > Out of curiosity what is:
> >
> >      @Test
> >      @Ignore
> >      public void runit() throws Exception {
> >          Thread.sleep(10000000);
> >      }
> >
> > My poor brain can't come up with a single use for it ;)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Oct 29 03:58:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 03:58:59 -0400 (EDT)
Subject: [keycloak-dev] Summary emails of work (especially refactoring)
In-Reply-To: <1438246665.2394002.1414569422768.JavaMail.zimbra@redhat.com>
Message-ID: <1999577114.2394785.1414569539202.JavaMail.zimbra@redhat.com>

All,

Can we please write a summary of work that has been done and send to mailing lists? This especially applies to any refactoring or changing existing functionality.

From mposolda at redhat.com  Wed Oct 29 05:20:23 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Oct 2014 10:20:23 +0100
Subject: [keycloak-dev] ClientsManagementService explanation?
In-Reply-To: <54501D30.7050105@redhat.com>
References: <54501D30.7050105@redhat.com>
Message-ID: <5450B157.5060102@redhat.com>

Sure, it's about dynamic registration of application cluster nodes to 
Keycloak, so once admin wants to send global admin event (like push new 
notBefore for the realm), it's send to all cluster nodes. I figured out 
we discussed just the idea on ML, but I did not send summary after it's 
done. Sorry for that.

So changes:
* In AdapterConfig, there are options "register-node-at-startup" 
(true,false) and "register-node-period" (interval in seconds) where 
people could specify that application registers itself to Keycloak at 
startup and re-registers after specified interval. It's false by default 
as useful just for cluster.

* On adapters side, there is new component NodesRegistrationManagement, 
which is used to send those "registration" requests. It's actually not 
send at startup of application but at 1st request, so 
NodesRegistrationManagement has fully resolved KeycloakDeployment to 
send request against. Sending at 1st request also works well with 
multi-tenant (it allows that registration request is sent for each realm 
resolved by KeycloakConfigResolver in any request) . At shutdown (or app 
undeployment) it sends "unregistration" request to Keycloak to inform 
that particular cluster node is down. Requests are authenticated by 
client credentials of particular application (feature is not supported 
for public clients for now)

* On Keycloak side, there is ClientsManagementService, which handles 
those registration/unregistration requests and registers/unregisters 
nodes at Keycloak side.

* Model changes on ApplicationModel for support this are new methods:

     Map<String, Integer> getRegisteredNodes();
     void registerNode(String nodeHost, int registrationTime);
     void unregisterNode(String nodeHost);
     int getNodeReRegistrationTimeout();
     void setNodeReRegistrationTimeout(int timeout);

Node re-registration timeout is the interval for which node needs to 
re-register itself in Keycloak, otherwise Keycloak will unregister it.

* Once new admin request is send to Keycloak for admin events (like push 
notBefore or logoutAll on realm or application) it's sent to all 
registered cluster nodes. ResourceAdminManager was refactored  to 
support this. Note that this applies just for "global" events like push 
notBefore. Normal user logouts are still sent just to single node (node 
where particular HTTP Session invalidation should happen).

Example of usage:
* Application is deployed on 2 cluster nodes "http://node1:8080/myapp" 
and "http://node2:8080/myapp" . Those 2 nodes are started and registered 
to Keycloak at startup

* Admin wants to push notBefore for the "myapp" application. So Keycloak 
will handle it by sending request to 
"http://node1:8080/myapp/k_push_not_before" and 
"http://node2:8080/myapp/k_push_not_before"

* Node1 is going to shutdown and send unregistration request to 
Keycloak. Next time admin wants to push notBefore, it will be send just 
to node2 at "http://node2:8080/myapp/k_push_not_before" .

* In Keycloak admin console, admin has possibility to test availability 
(ping) registered cluster nodes (new preAuth request type 
"k_test_available" added to PreAuthActionsHandler. It is not doing 
anything, just replies 204) . Admin has also possibility to manually 
de-register stale nodes in admin console if automatic unregistration 
fails for instance.


In the end, there are fair amount of changes but it affects just 
clustering and everything should be backwards compatible. Existing 1.0.X 
applications will still work after update to 1.1.X without need to 
change anything in their configuration.

Marek


On 28.10.2014 23:48, Bill Burke wrote:
> Did you send out an email explaining what ClientsManagementService is?
> Also what changes you made to the adapters?  I'd like to review it.
>


From mposolda at redhat.com  Wed Oct 29 05:32:12 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Oct 2014 10:32:12 +0100
Subject: [keycloak-dev] AdapterTokenStore change
Message-ID: <5450B41C.4040707@redhat.com>

Another change which worth mention on ML is AdapterTokenStore introduced 
for https://issues.jboss.org/browse/KEYCLOAK-702 .

* There is new option "token-store" in adapter-configuration with 
possible values "session" and "cookie" .

* Default value is "session", which means that info about authenticated 
user are saved in Adapter in HttpSession (same behaviour like it was before)

* Alternative "cookie" means that all token info is stored in cookie, 
which means that HttpSession is not created at all for particular 
application. It's alternative useful for stateless applications, which 
doesn't need HttpSession.

I've added AdapterTokenStore as an abstraction to handle 
saving/loading/removing this account info.

Everything is again backwards compatible (existing apps are still saving 
info in Http Session and are not affected at all, as default value is 
"session", which is used if nothing is specified in config)

Marek

From jcosta at redhat.com  Wed Oct 29 06:23:08 2014
From: jcosta at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=)
Date: Wed, 29 Oct 2014 11:23:08 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
Message-ID: <5450C00C.8040704@redhat.com>

Stian,

Agree with all the comments. I'm doing the changes, but I've got a
question and a few comments. See below.

On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
> 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out the realm if the session was serialized? when adapter is clustered we support serializing the session

I'm then changing one of the SecurityContext's to include the realm, so
that it gets de-serialized with this information. Now, the question is
whether it is more appropriate to add it to KeycloakSecurityContext or
RefreshableKeycloakSecurityContext. On the superclass
(KeycloakSecurityContext), I have access only to IdToken and
AccessToken. I believe both have ways to retrieve the realm (issuer, I
believe), but I don't know how reliable this is. I remember seeing a
post from Bill on keycloak-user that it should be changed to an URL, not
the realm name. On the subclass, however, I have access to the
KeycloakDeployment, which provides the realm on the exact way that it
was originally configured.

> 4. KeycloakAuthenticatorValve.initInternal - just do a warn + unconfigured to make it behave same as if keycloak-server.json is missing, and drop the comment

Ok, but just to confirm: I should add a new warn with the same text as
the other and *not* attempt to load a keycloak.json, right? The question
is because there might be a non-existing resolver specified *and* a
keycloak.json . As it is, there will be a warn on the log, saying that
the resolver will not be used, but as there is a keycloak.json, a
KeycloakDeployment is available.

Based on your comment, I assume that this is a configuration problem,
hence, it should not attempt to load keycloak.json if a resolver is
specified.

> 6. CatalinaCookieTokenStore.checkPrincipalFromCookie - if cookie has different realm I'd say the log should at least be a warn, is this not a significant problem?
> 7. CatalinaSessionTokenStore.checkCurrentToken - same as above isn't
cookie with different realm a pretty big issue?

I don't think it's a significant problem. It will happen when one user
has access to two realms, is logged in on the first and then tries to
access the same application on a second tenant. On this case, the cookie
sent is for the first tenant, so, we should consider it invalid for this
request, meaning, the principal for this cookie for this realm is
unknown (return null). On this scenario, Keycloak will redirect the user
for logging in on the second realm, which will effectively override the
first cookie. This scenario is tested on
MultiTenancyTest#testTenantsWithoutLoggingOut .

- Juca.





From mposolda at redhat.com  Wed Oct 29 06:27:32 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Oct 2014 11:27:32 +0100
Subject: [keycloak-dev] Proposed changes to access code
In-Reply-To: <1129332998.1633705.1414501769986.JavaMail.zimbra@redhat.com>
References: <1129332998.1633705.1414501769986.JavaMail.zimbra@redhat.com>
Message-ID: <5450C114.9050300@redhat.com>

Yep, it seems that signing and then computing hash of the signature is 
quite an overhead, which is not needed. Especially with additionally 
added uniqueness of ActionKey. So +1 from me

Marek

On 28.10.2014 14:09, Stian Thorgersen wrote:
> We have a few issues with how we generate access codes:
>
> * Abuse of RSA
> * SHA-1 is no good
> * Action + timestamp is guessable (this may just be theoretical)
> * Both key and code query params sent in emails (making the links longer that necessary)
>
> To resolve these issues I propose:
>
> * When realm keys are updated we generate a realm code secret (UUID) - this is a secret required to create valid codes
> * When the action and timestamp is updated we generate a action key (UUID) - this is a unique identifier for that specific action
>
> Then an access code is created with:
>
>      MessageDigest digest = MessageDigest.getInstance("sha-256");
>      digest.update(realm.getCodeSecret());
>      digest.update("/".getBytes());
>      digest.update(clientSession.getActionKey());
>              
>      String hash = Base64Url.encode(digest.digest());
>
>      StringBuilder sb = new StringBuilder();
>      sb.append(hash);
>      sb.append(".");
>      sb.append(clientSession.getId());
>              
>      String code = sb.toString();
>
> An example access code will now be:
>
>      Ld_L-Ta-tSpQMxGimEIpM4rq57KoplcN_3QxujUsMlM.6d102340-a7fd-44b8-93fd-ed6a8e8a4a15
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From juraci at kroehling.de  Wed Oct 29 06:56:31 2014
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 29 Oct 2014 11:56:31 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <5450C00C.8040704@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com>
Message-ID: <5450C7DF.7090803@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 10/29/2014 11:23 AM, Juraci Paix?o Kr?hling wrote:
> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
>> 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure
>> out the realm if the session was serialized? when adapter is
>> clustered we support serializing the session
> 
> I'm then changing one of the SecurityContext's to include the
> realm, so that it gets de-serialized with this information. Now,
> the question is whether it is more appropriate to add it to
> KeycloakSecurityContext or RefreshableKeycloakSecurityContext. On
> the superclass (KeycloakSecurityContext), I have access only to
> IdToken and AccessToken. I believe both have ways to retrieve the
> realm (issuer, I believe), but I don't know how reliable this is. I
> remember seeing a post from Bill on keycloak-user that it should be
> changed to an URL, not the realm name. On the subclass, however, I
> have access to the KeycloakDeployment, which provides the realm on
> the exact way that it was originally configured.

About this one: I added a new constructor parameter to the superclass,
as all callers did have access to the realm name. So, provided that
storing the realm on the security context is appropriate, this is solved.

- - Juca.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUUMffAAoJEDnJtskdmzLMA5kIAJSFLqowZHs9Qdb6D4gtd7Fn
tqDyL8g+UXsa0XaCHeXEBmOFalyJ9dsANvsliQE1yOjTyZr3nJUHsbwFbH3ALjyZ
UB1D/TLeQRE5nhW3FAs9VlgvLuDRsZKsVaasu0NptjhOyE++x8EuToJ2YJpu3cCA
2Gaeb1QmqNO3svc8x46t6k7btZ7FXDPuXZQFGF6KDlUYGwKBx/8sIp2mA6h5gvX+
3EuFKDh65dJE+t9SoZy0/7lNOsjVuCsCWV7Be99WLbTFnVZSMlXtTP2+sbOSd5xB
saipMZ43/Oz9vaIy2wGbf8kTAZumL2PIpcegkpvyMC2c8SD/AhdNkZ7RxdOMQ9E=
=sDEU
-----END PGP SIGNATURE-----

From bburke at redhat.com  Wed Oct 29 08:44:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 08:44:38 -0400
Subject: [keycloak-dev] Proposed changes to access code
In-Reply-To: <5450C114.9050300@redhat.com>
References: <1129332998.1633705.1414501769986.JavaMail.zimbra@redhat.com>
	<5450C114.9050300@redhat.com>
Message-ID: <5450E136.4010803@redhat.com>

Should clientSession.id be added to the hash?

On 10/29/2014 6:27 AM, Marek Posolda wrote:
> Yep, it seems that signing and then computing hash of the signature is
> quite an overhead, which is not needed. Especially with additionally
> added uniqueness of ActionKey. So +1 from me
>
> Marek
>
> On 28.10.2014 14:09, Stian Thorgersen wrote:
>> We have a few issues with how we generate access codes:
>>
>> * Abuse of RSA
>> * SHA-1 is no good
>> * Action + timestamp is guessable (this may just be theoretical)
>> * Both key and code query params sent in emails (making the links longer that necessary)
>>
>> To resolve these issues I propose:
>>
>> * When realm keys are updated we generate a realm code secret (UUID) - this is a secret required to create valid codes
>> * When the action and timestamp is updated we generate a action key (UUID) - this is a unique identifier for that specific action
>>
>> Then an access code is created with:
>>
>>       MessageDigest digest = MessageDigest.getInstance("sha-256");
>>       digest.update(realm.getCodeSecret());
>>       digest.update("/".getBytes());
>>       digest.update(clientSession.getActionKey());
>>
>>       String hash = Base64Url.encode(digest.digest());
>>
>>       StringBuilder sb = new StringBuilder();
>>       sb.append(hash);
>>       sb.append(".");
>>       sb.append(clientSession.getId());
>>
>>       String code = sb.toString();
>>
>> An example access code will now be:
>>
>>       Ld_L-Ta-tSpQMxGimEIpM4rq57KoplcN_3QxujUsMlM.6d102340-a7fd-44b8-93fd-ed6a8e8a4a15
>> _______________________________________________
>> 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 Oct 29 08:47:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 08:47:08 -0400 (EDT)
Subject: [keycloak-dev] Proposed changes to access code
In-Reply-To: <5450E136.4010803@redhat.com>
References: <1129332998.1633705.1414501769986.JavaMail.zimbra@redhat.com>
	<5450C114.9050300@redhat.com> <5450E136.4010803@redhat.com>
Message-ID: <1167358348.2628819.1414586828085.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 October, 2014 1:44:38 PM
> Subject: Re: [keycloak-dev] Proposed changes to access code
> 
> Should clientSession.id be added to the hash?

Sure

> 
> On 10/29/2014 6:27 AM, Marek Posolda wrote:
> > Yep, it seems that signing and then computing hash of the signature is
> > quite an overhead, which is not needed. Especially with additionally
> > added uniqueness of ActionKey. So +1 from me
> >
> > Marek
> >
> > On 28.10.2014 14:09, Stian Thorgersen wrote:
> >> We have a few issues with how we generate access codes:
> >>
> >> * Abuse of RSA
> >> * SHA-1 is no good
> >> * Action + timestamp is guessable (this may just be theoretical)
> >> * Both key and code query params sent in emails (making the links longer
> >> that necessary)
> >>
> >> To resolve these issues I propose:
> >>
> >> * When realm keys are updated we generate a realm code secret (UUID) -
> >> this is a secret required to create valid codes
> >> * When the action and timestamp is updated we generate a action key (UUID)
> >> - this is a unique identifier for that specific action
> >>
> >> Then an access code is created with:
> >>
> >>       MessageDigest digest = MessageDigest.getInstance("sha-256");
> >>       digest.update(realm.getCodeSecret());
> >>       digest.update("/".getBytes());
> >>       digest.update(clientSession.getActionKey());
> >>
> >>       String hash = Base64Url.encode(digest.digest());
> >>
> >>       StringBuilder sb = new StringBuilder();
> >>       sb.append(hash);
> >>       sb.append(".");
> >>       sb.append(clientSession.getId());
> >>
> >>       String code = sb.toString();
> >>
> >> An example access code will now be:
> >>
> >>       Ld_L-Ta-tSpQMxGimEIpM4rq57KoplcN_3QxujUsMlM.6d102340-a7fd-44b8-93fd-ed6a8e8a4a15
> >> _______________________________________________
> >> 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 stian at redhat.com  Wed Oct 29 08:52:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 08:52:03 -0400 (EDT)
Subject: [keycloak-dev] 1.0.4.Final coming soon
In-Reply-To: <305098763.2629963.1414586908617.JavaMail.zimbra@redhat.com>
Message-ID: <1382015280.2631786.1414587123170.JavaMail.zimbra@redhat.com>

While fixing one security issue for 1.0.3.Final I broke something. 

If there's a hyphen in the domain name (for example OpenShift) login-status-iframe.html fails to load. Fix and release coming asap!

From ssilvert at redhat.com  Wed Oct 29 09:28:52 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 29 Oct 2014 09:28:52 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
	subsystem
Message-ID: <5450EB94.9090404@redhat.com>

I've sent a PR for this:
https://github.com/keycloak/keycloak/pull/811

It's a pretty big change in the way the Auth Server is started when the 
KeyCloak subsystem is used.  The WAR is no longer dropped into the 
standalone/deployments directory.   This is especially helpful for 
domain deployments, but it makes standalone cleaner as well.  It will 
also be important for Feature Pack installation.

The main difference you will see right away with this PR is that the 
appliance dist now uses the subsystem to launch the Auth Server.

Here are some notes about how everything turned out.  Next, I'll update 
the documentation if there is no major rework that needs to be done 
after the PR is reviewed.

  * The WAR for the auth server now lives in
    modules/.../keycloak-wildfly-subsystem/main/auth-server.  By
    default, it is unexploded.  If you want it to be exploded you can
    unzip it into that same directory and set the "auth-server-exploded"
    property in module.xml.
  * A new Auth Server is declared in standalone.xml/domain.xml. You can
    have more than one Auth Server in the same WildFly instance.
  * <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
                 <auth-server name="main-auth-server">
                     <enabled>true</enabled>
                     <web-context>auth</web-context>
                 </auth-server>

  * The "enabled" attribute can be toggled at runtime to make the auth
    server undeploy/redeploy.
  * If you have more than one auth-server, the web-context must be unique.
  * In a domain environment, all specified Auth Server deployments are
    propagated to all servers using that profile.  The same is true for
    overlays uploaded through the new CLI operations.
  * There are two new CLI operations that act on an auth-server. They
    are "add-provider" and "update-server-config".  Currently, you can
    only execute these operations in the latest version of CLI GUI.   We
    should discuss if we need to add support in plain CLI.  The long
    term goal would be to add this functionality to the Keycloak Admin
    Console.
  * "add-provider" adds a provider jar to an auth-server
  * "update-server-config" overlays the keycloak-server.json for an
    auth-server.
  * If a keycloak-server.json file is found in standalone/configuration
    directory, all auth-server instances will still use it regardless of
    any update-server-config operations.
  * EAP6 does not yet support all this.  We should discuss whether or
    not this functionality should be backported.

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

From juraci at kroehling.de  Wed Oct 29 09:36:01 2014
From: juraci at kroehling.de (=?windows-1252?Q?Juraci_Paix=E3o_Kr=F6hling?=)
Date: Wed, 29 Oct 2014 14:36:01 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <5450C00C.8040704@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com>
Message-ID: <5450ED41.3030206@kroehling.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Stian,

I went ahead and did the changes based on the following assumptions:

3) KeycloakSecurityContext should have a "realm" property. Added test
for this and changed the callers to pass the realm to the constructor.

4) Leave the adapter unconfigured in case of configuration mismatch
(ie: resolver specified but invalid + keycloak.json present). The
cases are described as comments in the code

6 and 7) I assume this is not a problem. I cannot find a situation
where this would lead to a non-existing user in one tenant to
successfully access an unauthorized resource. In any case, I've added
a couple of test cases, where an user from tenant1 tries to login to
tenant2 and where an already logged in user from tenant1 tries to
access tenant2.

A new PR was sent with all the changes from your review.

- - Juca.

On 10/29/2014 11:23 AM, Juraci Paix?o Kr?hling wrote:
> Stian,
> 
> Agree with all the comments. I'm doing the changes, but I've got a 
> question and a few comments. See below.
> 
> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
>> 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure
>> out the realm if the session was serialized? when adapter is
>> clustered we support serializing the session
> 
> I'm then changing one of the SecurityContext's to include the
> realm, so that it gets de-serialized with this information. Now,
> the question is whether it is more appropriate to add it to
> KeycloakSecurityContext or RefreshableKeycloakSecurityContext. On
> the superclass (KeycloakSecurityContext), I have access only to
> IdToken and AccessToken. I believe both have ways to retrieve the
> realm (issuer, I believe), but I don't know how reliable this is. I
> remember seeing a post from Bill on keycloak-user that it should be
> changed to an URL, not the realm name. On the subclass, however, I
> have access to the KeycloakDeployment, which provides the realm on
> the exact way that it was originally configured.
> 
>> 4. KeycloakAuthenticatorValve.initInternal - just do a warn +
>> unconfigured to make it behave same as if keycloak-server.json is
>> missing, and drop the comment
> 
> Ok, but just to confirm: I should add a new warn with the same text
> as the other and *not* attempt to load a keycloak.json, right? The
> question is because there might be a non-existing resolver
> specified *and* a keycloak.json . As it is, there will be a warn on
> the log, saying that the resolver will not be used, but as there is
> a keycloak.json, a KeycloakDeployment is available.
> 
> Based on your comment, I assume that this is a configuration
> problem, hence, it should not attempt to load keycloak.json if a
> resolver is specified.
> 
>> 6. CatalinaCookieTokenStore.checkPrincipalFromCookie - if cookie
>> has different realm I'd say the log should at least be a warn, is
>> this not a significant problem? 7.
>> CatalinaSessionTokenStore.checkCurrentToken - same as above
>> isn't
> cookie with different realm a pretty big issue?
> 
> I don't think it's a significant problem. It will happen when one
> user has access to two realms, is logged in on the first and then
> tries to access the same application on a second tenant. On this
> case, the cookie sent is for the first tenant, so, we should
> consider it invalid for this request, meaning, the principal for
> this cookie for this realm is unknown (return null). On this
> scenario, Keycloak will redirect the user for logging in on the
> second realm, which will effectively override the first cookie.
> This scenario is tested on 
> MultiTenancyTest#testTenantsWithoutLoggingOut .
> 
> - Juca.
> 
> 
> 
> 
> _______________________________________________ keycloak-dev
> mailing list keycloak-dev at lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUUO1BAAoJEDnJtskdmzLMIv4H/R0NTJ46mK0dbDXkwNb68xQS
W6zeQ+jzBmAvwu7/i8/kSu7AXSPaGxR/EBbjSBKj6l5zVQLjlPQ0CFUzQSDGDASy
WKyMEKk64Df0dNZlkuqHHFaCyuZ+3rz2k9XiGRmpIXej/uzUjvXUpIKBmUOpDxR6
dmqViOkRBuLFbBvwbCgid85Mip92wd2YXUHl0dmPNZN/j9bJPp8GYTHinJgv1pZs
j6hTYduasl/T4jcgWWHYKftuOpbpOWtusjCwuGwxIS1TsIYNZt4G88LL6tWTD9WF
8LznY1cxXuRA7YAvGKOrZY/e9yECQGJokWSZxkQrjNuvzLx1TXkaU7bM7E1oPXs=
=Vpjp
-----END PGP SIGNATURE-----

From bburke at redhat.com  Wed Oct 29 10:07:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 10:07:58 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <5450EB94.9090404@redhat.com>
References: <5450EB94.9090404@redhat.com>
Message-ID: <5450F4BE.4030801@redhat.com>



On 10/29/2014 9:28 AM, Stan Silvert wrote:
>   * EAP6 does not yet support all this.  We should discuss whether or
>     not this functionality should be backported.
>

+1 for this, but maybe some focus should be on getting a more seamless 
"hello world" like we discussed in a previous thread?

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

From ssilvert at redhat.com  Wed Oct 29 10:25:55 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 29 Oct 2014 10:25:55 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <5450F4BE.4030801@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
Message-ID: <5450F8F3.7020301@redhat.com>

On 10/29/2014 10:07 AM, Bill Burke wrote:
>
> On 10/29/2014 9:28 AM, Stan Silvert wrote:
>>    * EAP6 does not yet support all this.  We should discuss whether or
>>      not this functionality should be backported.
>>
> +1 for this, but maybe some focus should be on getting a more seamless
> "hello world" like we discussed in a previous thread?
>
I agree.  IMO, the next step should be Feature Pack installation and the 
seamless "hello world".   Then we look at EAP6.

From stian at redhat.com  Wed Oct 29 10:56:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 10:56:18 -0400 (EDT)
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <5450F8F3.7020301@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
Message-ID: <1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>

I'd like to have a look at this before we merge it, but won't have time until tomorrow (maybe Friday).

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 October, 2014 3:25:55 PM
> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
> 
> On 10/29/2014 10:07 AM, Bill Burke wrote:
> >
> > On 10/29/2014 9:28 AM, Stan Silvert wrote:
> >>    * EAP6 does not yet support all this.  We should discuss whether or
> >>      not this functionality should be backported.
> >>
> > +1 for this, but maybe some focus should be on getting a more seamless
> > "hello world" like we discussed in a previous thread?
> >
> I agree.  IMO, the next step should be Feature Pack installation and the
> seamless "hello world".   Then we look at EAP6.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Oct 29 11:23:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 11:23:44 -0400 (EDT)
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <1004175690.2784553.1414596153626.JavaMail.zimbra@redhat.com>
Message-ID: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>

As new client sessions are initially detached there's a chance they are never linked to a user session (for example user closes browser when login page is displayed). These client sessions are never removed. I reckon we need to have a similar garbage collection of client sessions as we do for user sessions.

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

From mposolda at redhat.com  Wed Oct 29 12:28:10 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Oct 2014 17:28:10 +0100
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
Message-ID: <5451159A.5060801@redhat.com>

Right now we are already doing the cleanup of expired ClientSessions in 
UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo 
providers.

So it seems that only one missing is InfinispanUserSessionProvider.

Maybe it's better to introduce new method on UserSessionProvider like 
"removeExpiredClientSessions()" and move the removal of expired client 
sessions there? Or we can keep as it is and just fix the infinispan 
provider? Not sure which possibility is better.

Marek

On 29.10.2014 16:23, Stian Thorgersen wrote:
> As new client sessions are initially detached there's a chance they are never linked to a user session (for example user closes browser when login page is displayed). These client sessions are never removed. I reckon we need to have a similar garbage collection of client sessions as we do for user sessions.
>
> https://issues.jboss.org/browse/KEYCLOAK-788
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Oct 29 14:03:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 14:03:00 -0400 (EDT)
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <5451159A.5060801@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
	<5451159A.5060801@redhat.com>
Message-ID: <594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>

Looks like it's only Mongo and JPA that's doing this, while both mem and Infinispan are not.

I reckon we just fix it for mem and Infinispan, there's not really any need for two separate methods.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 29 October, 2014 5:28:10 PM
> Subject: Re: [keycloak-dev] ClientSessions may never be removed
> 
> Right now we are already doing the cleanup of expired ClientSessions in
> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
> providers.
> 
> So it seems that only one missing is InfinispanUserSessionProvider.
> 
> Maybe it's better to introduce new method on UserSessionProvider like
> "removeExpiredClientSessions()" and move the removal of expired client
> sessions there? Or we can keep as it is and just fix the infinispan
> provider? Not sure which possibility is better.
> 
> Marek
> 
> On 29.10.2014 16:23, Stian Thorgersen wrote:
> > As new client sessions are initially detached there's a chance they are
> > never linked to a user session (for example user closes browser when login
> > page is displayed). These client sessions are never removed. I reckon we
> > need to have a similar garbage collection of client sessions as we do for
> > user sessions.
> >
> > https://issues.jboss.org/browse/KEYCLOAK-788
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Wed Oct 29 14:19:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 14:19:08 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.0.4.Final released
Message-ID: <1672606176.2966600.1414606748490.JavaMail.zimbra@redhat.com>

Fixes a bug introduced in 1.0.3.Final that causes problems if your domain includes a hypen.

From mposolda at redhat.com  Wed Oct 29 14:26:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Oct 2014 19:26:05 +0100
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
	<5451159A.5060801@redhat.com>
	<594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>
Message-ID: <5451313D.7010501@redhat.com>

+1

For mem we seem to be doing it too here: 
https://github.com/keycloak/keycloak/blob/master/model/sessions-mem/src/main/java/org/keycloak/models/sessions/mem/MemUserSessionProvider.java#L197 

However it looks to me that there is bug in it. It's checking 
ClientSessions without associated UserSession (which is ok to me as 
those associated with UserSessionModel were cleaned previously), but the 
bug is that it's not checking realm. So if realm 'foo' has idleTimeout 
30 secs, then it will cleanup all ClientSessions older than 30 seconds, 
even from different realms...

Marek

On 29.10.2014 19:03, Stian Thorgersen wrote:
> Looks like it's only Mongo and JPA that's doing this, while both mem and Infinispan are not.
>
> I reckon we just fix it for mem and Infinispan, there's not really any need for two separate methods.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, 29 October, 2014 5:28:10 PM
>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>
>> Right now we are already doing the cleanup of expired ClientSessions in
>> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
>> providers.
>>
>> So it seems that only one missing is InfinispanUserSessionProvider.
>>
>> Maybe it's better to introduce new method on UserSessionProvider like
>> "removeExpiredClientSessions()" and move the removal of expired client
>> sessions there? Or we can keep as it is and just fix the infinispan
>> provider? Not sure which possibility is better.
>>
>> Marek
>>
>> On 29.10.2014 16:23, Stian Thorgersen wrote:
>>> As new client sessions are initially detached there's a chance they are
>>> never linked to a user session (for example user closes browser when login
>>> page is displayed). These client sessions are never removed. I reckon we
>>> need to have a similar garbage collection of client sessions as we do for
>>> user sessions.
>>>
>>> https://issues.jboss.org/browse/KEYCLOAK-788
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Wed Oct 29 14:29:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 14:29:11 -0400 (EDT)
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <5451313D.7010501@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
	<5451159A.5060801@redhat.com>
	<594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>
	<5451313D.7010501@redhat.com>
Message-ID: <2134121359.2972677.1414607351843.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 29 October, 2014 7:26:05 PM
> Subject: Re: [keycloak-dev] ClientSessions may never be removed
> 
> +1
> 
> For mem we seem to be doing it too here:
> https://github.com/keycloak/keycloak/blob/master/model/sessions-mem/src/main/java/org/keycloak/models/sessions/mem/MemUserSessionProvider.java#L197
> 
> However it looks to me that there is bug in it. It's checking
> ClientSessions without associated UserSession (which is ok to me as
> those associated with UserSessionModel were cleaned previously), but the
> bug is that it's not checking realm. So if realm 'foo' has idleTimeout
> 30 secs, then it will cleanup all ClientSessions older than 30 seconds,
> even from different realms...

You're right, I miss-read the code ;)

> 
> Marek
> 
> On 29.10.2014 19:03, Stian Thorgersen wrote:
> > Looks like it's only Mongo and JPA that's doing this, while both mem and
> > Infinispan are not.
> >
> > I reckon we just fix it for mem and Infinispan, there's not really any need
> > for two separate methods.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >> <keycloak-dev at lists.jboss.org>
> >> Sent: Wednesday, 29 October, 2014 5:28:10 PM
> >> Subject: Re: [keycloak-dev] ClientSessions may never be removed
> >>
> >> Right now we are already doing the cleanup of expired ClientSessions in
> >> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
> >> providers.
> >>
> >> So it seems that only one missing is InfinispanUserSessionProvider.
> >>
> >> Maybe it's better to introduce new method on UserSessionProvider like
> >> "removeExpiredClientSessions()" and move the removal of expired client
> >> sessions there? Or we can keep as it is and just fix the infinispan
> >> provider? Not sure which possibility is better.
> >>
> >> Marek
> >>
> >> On 29.10.2014 16:23, Stian Thorgersen wrote:
> >>> As new client sessions are initially detached there's a chance they are
> >>> never linked to a user session (for example user closes browser when
> >>> login
> >>> page is displayed). These client sessions are never removed. I reckon we
> >>> need to have a similar garbage collection of client sessions as we do for
> >>> user sessions.
> >>>
> >>> https://issues.jboss.org/browse/KEYCLOAK-788
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From bburke at redhat.com  Wed Oct 29 14:49:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 14:49:28 -0400
Subject: [keycloak-dev] tomcat 7 adapter
Message-ID: <545136B8.3030207@redhat.com>

I added the tomcat 7 adapter to the distro as well as some docbook docs 
for it.  This is shaping up to a really nice release!


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

From bburke at redhat.com  Wed Oct 29 14:55:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 14:55:54 -0400
Subject: [keycloak-dev] Multi-tenant done?
In-Reply-To: <5450ED41.3030206@kroehling.de>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>	<5450C00C.8040704@redhat.com>
	<5450ED41.3030206@kroehling.de>
Message-ID: <5451383A.1090402@redhat.com>

Would be cool if we could include this in the next release.  Will this 
be merged to master soon?

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

From bburke at redhat.com  Wed Oct 29 14:58:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 14:58:02 -0400
Subject: [keycloak-dev] 1.1 Beta 1 monday?
Message-ID: <545138BA.90500@redhat.com>

Finish up as many jiras as possible then release 1.1.Beta1 on Monday? 
Nice feature list:

* Deep clustering support
* SAML 2.0 support
* Tomcat 7 adapter
* Multi-tenant adapter???


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

From stian at redhat.com  Wed Oct 29 15:02:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 15:02:24 -0400 (EDT)
Subject: [keycloak-dev] Multi-tenant done?
In-Reply-To: <5451383A.1090402@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com> <5450ED41.3030206@kroehling.de>
	<5451383A.1090402@redhat.com>
Message-ID: <458514911.2993890.1414609344203.JavaMail.zimbra@redhat.com>

It's pretty much ready, should be merged tomorrow or Friday

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org, "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
> Sent: Wednesday, 29 October, 2014 7:55:54 PM
> Subject: [keycloak-dev] Multi-tenant done?
> 
> Would be cool if we could include this in the next release.  Will this
> be merged to master soon?
> 
> --
> 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 Oct 29 15:14:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 29 Oct 2014 15:14:30 -0400 (EDT)
Subject: [keycloak-dev] 1.1 Beta 1 monday?
In-Reply-To: <545138BA.90500@redhat.com>
References: <545138BA.90500@redhat.com>
Message-ID: <1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>

Monday should be OK.

I've got to review and merge the multi-tenant adapter support and also add the proposed changes to access codes, but shouldn't be a problem to finish those in time.

For https://issues.jboss.org/browse/KEYCLOAK-708 I think we should just make sure the adapters checks sql-required before talking to KC. Currently I think the adapters will fetch the realm key from http://keycloak even if sql-required is set to all.

How about Stan's work? If we're including that I'd prefer a few more days to try it out. It's a relatively big change to the appliance-dist right?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 October, 2014 7:58:02 PM
> Subject: [keycloak-dev] 1.1 Beta 1 monday?
> 
> Finish up as many jiras as possible then release 1.1.Beta1 on Monday?
> Nice feature list:
> 
> * Deep clustering support
> * SAML 2.0 support
> * Tomcat 7 adapter
> * Multi-tenant adapter???
> 
> 
> --
> 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 Oct 29 15:18:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 15:18:38 -0400
Subject: [keycloak-dev] 1.1 Beta 1 monday?
In-Reply-To: <1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>
References: <545138BA.90500@redhat.com>
	<1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>
Message-ID: <54513D8E.1080907@redhat.com>



On 10/29/2014 3:14 PM, Stian Thorgersen wrote:
> Monday should be OK.
>
> I've got to review and merge the multi-tenant adapter support and also add the proposed changes to access codes, but shouldn't be a problem to finish those in time.
>
> For https://issues.jboss.org/browse/KEYCLOAK-708 I think we should just make sure the adapters checks sql-required before talking to KC. Currently I think the adapters will fetch the realm key from http://keycloak even if sql-required is set to all.
>

The server url needs to be specified correctly (with HTTPS).  This is 
not a bug.  I rejected it.

> How about Stan's work? If we're including that I'd prefer a few more days to try it out. It's a relatively big change to the appliance-dist right?
>

Did he merge it?



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

From ssilvert at redhat.com  Wed Oct 29 15:38:54 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 29 Oct 2014 15:38:54 -0400
Subject: [keycloak-dev] 1.1 Beta 1 monday?
In-Reply-To: <54513D8E.1080907@redhat.com>
References: <545138BA.90500@redhat.com>
	<1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>
	<54513D8E.1080907@redhat.com>
Message-ID: <5451424E.5080102@redhat.com>

On 10/29/2014 3:18 PM, Bill Burke wrote:
>
> On 10/29/2014 3:14 PM, Stian Thorgersen wrote:
>> Monday should be OK.
>>
>> I've got to review and merge the multi-tenant adapter support and also add the proposed changes to access codes, but shouldn't be a problem to finish those in time.
>>
>> For https://issues.jboss.org/browse/KEYCLOAK-708 I think we should just make sure the adapters checks sql-required before talking to KC. Currently I think the adapters will fetch the realm key from http://keycloak even if sql-required is set to all.
>>
> The server url needs to be specified correctly (with HTTPS).  This is
> not a bug.  I rejected it.
>
>> How about Stan's work? If we're including that I'd prefer a few more days to try it out. It's a relatively big change to the appliance-dist right?
>>
> Did he merge it?
I did a PR, but Stain said he wanted to look it over first before merging.

It's probably not a bad idea to have one or two folks try it out before 
we do a release.
>
>
>


From bburke at redhat.com  Wed Oct 29 15:58:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 15:58:40 -0400
Subject: [keycloak-dev] 1.1 Beta 1 monday?
In-Reply-To: <5451424E.5080102@redhat.com>
References: <545138BA.90500@redhat.com>	<1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>	<54513D8E.1080907@redhat.com>
	<5451424E.5080102@redhat.com>
Message-ID: <545146F0.5010900@redhat.com>



On 10/29/2014 3:38 PM, Stan Silvert wrote:
> On 10/29/2014 3:18 PM, Bill Burke wrote:
>>
>> On 10/29/2014 3:14 PM, Stian Thorgersen wrote:
>>> Monday should be OK.
>>>
>>> I've got to review and merge the multi-tenant adapter support and also add the proposed changes to access codes, but shouldn't be a problem to finish those in time.
>>>
>>> For https://issues.jboss.org/browse/KEYCLOAK-708 I think we should just make sure the adapters checks sql-required before talking to KC. Currently I think the adapters will fetch the realm key from http://keycloak even if sql-required is set to all.
>>>
>> The server url needs to be specified correctly (with HTTPS).  This is
>> not a bug.  I rejected it.
>>
>>> How about Stan's work? If we're including that I'd prefer a few more days to try it out. It's a relatively big change to the appliance-dist right?
>>>
>> Did he merge it?
> I did a PR, but Stain said he wanted to look it over first before merging.
>
> It's probably not a bad idea to have one or two folks try it out before
> we do a release.

Is this usable with Wildfly 8.1.0?



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

From bburke at redhat.com  Wed Oct 29 16:02:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Oct 2014 16:02:24 -0400
Subject: [keycloak-dev] 1.1 adapters no longer backward compatible
Message-ID: <545147D0.1090200@redhat.com>

Because of this bug:

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

I changed the aud to point ot clientid and iss to be the realm name.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From ssilvert at redhat.com  Wed Oct 29 19:30:02 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 29 Oct 2014 19:30:02 -0400
Subject: [keycloak-dev] 1.1 Beta 1 monday?
In-Reply-To: <545146F0.5010900@redhat.com>
References: <545138BA.90500@redhat.com>	<1279403315.3002390.1414610070839.JavaMail.zimbra@redhat.com>	<54513D8E.1080907@redhat.com>
	<5451424E.5080102@redhat.com> <545146F0.5010900@redhat.com>
Message-ID: <5451787A.8020202@redhat.com>

On 10/29/2014 3:58 PM, Bill Burke wrote:
>
> On 10/29/2014 3:38 PM, Stan Silvert wrote:
>> On 10/29/2014 3:18 PM, Bill Burke wrote:
>>> On 10/29/2014 3:14 PM, Stian Thorgersen wrote:
>>>> Monday should be OK.
>>>>
>>>> I've got to review and merge the multi-tenant adapter support and also add the proposed changes to access codes, but shouldn't be a problem to finish those in time.
>>>>
>>>> For https://issues.jboss.org/browse/KEYCLOAK-708 I think we should just make sure the adapters checks sql-required before talking to KC. Currently I think the adapters will fetch the realm key from http://keycloak even if sql-required is set to all.
>>>>
>>> The server url needs to be specified correctly (with HTTPS).  This is
>>> not a bug.  I rejected it.
>>>
>>>> How about Stan's work? If we're including that I'd prefer a few more days to try it out. It's a relatively big change to the appliance-dist right?
>>>>
>>> Did he merge it?
>> I did a PR, but Stain said he wanted to look it over first before merging.
>>
>> It's probably not a bad idea to have one or two folks try it out before
>> we do a release.
> Is this usable with Wildfly 8.1.0?
>
>
>
Yes, definitely.   The PR includes changing the appliance dist to use 
this and the appliance dist is still on 8.1.0.  That's what I've been 
testing on.

From stian at redhat.com  Thu Oct 30 02:51:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Oct 2014 02:51:16 -0400 (EDT)
Subject: [keycloak-dev] 1.1 adapters no longer backward compatible
In-Reply-To: <545147D0.1090200@redhat.com>
References: <545147D0.1090200@redhat.com>
Message-ID: <1456217365.3249179.1414651876935.JavaMail.zimbra@redhat.com>

Should we fix iss to return the "realm" url at the same time?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 October, 2014 9:02:24 PM
> Subject: [keycloak-dev] 1.1 adapters no longer backward compatible
> 
> Because of this bug:
> 
> https://issues.jboss.org/browse/KEYCLOAK-767
> 
> I changed the aud to point ot clientid and iss to be the realm name.
> --
> 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  Thu Oct 30 04:05:42 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Oct 2014 09:05:42 +0100
Subject: [keycloak-dev] tomcat 7 adapter
In-Reply-To: <545136B8.3030207@redhat.com>
References: <545136B8.3030207@redhat.com>
Message-ID: <5451F156.6000007@redhat.com>

Great, however the fact that Tomcat7 adapter is defacto copy/paste of 
AS7 adapter means that every change needs to be done on 2 places.

I wonder if we can try to create some common "jboss-web" module and then 
tomcat7 and jboss7 specific submodules? Those will handle just specific 
differences among AS7 and Tomcat7
(For example common project will have simple logging abstraction, which 
will delegate to jboss-logging on AS7 or JDK-logging on Tomcat, The 
differences for establish security context on 
CatalinaSecurityContextHelper will be always abstractized etc)

There are differences in dependencies, but class-names are the same (For 
example org.apache.catalina.authenticator.FormAuthenticator has same 
name and package in both tomcat and jboss-web dependency), so I believe 
that it's not a problem to compile common project against jboss-web and 
then use runtime dependency on tomcat-catalina (For Tomcat7 environment)?

I am not sure myself if it's way to go, maybe it's just over-simplifying 
as the code is not big anyway. Just possible idea to think about;-)

Marek

On 29.10.2014 19:49, Bill Burke wrote:
> I added the tomcat 7 adapter to the distro as well as some docbook docs
> for it.  This is shaping up to a really nice release!
>
>


From bburke at redhat.com  Thu Oct 30 08:30:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 08:30:21 -0400
Subject: [keycloak-dev] tomcat 7 adapter
In-Reply-To: <5451F156.6000007@redhat.com>
References: <545136B8.3030207@redhat.com> <5451F156.6000007@redhat.com>
Message-ID: <54522F5D.4080501@redhat.com>

Its not a perfect match.  Constructors are different in a few classes too :(

On 10/30/2014 4:05 AM, Marek Posolda wrote:
> Great, however the fact that Tomcat7 adapter is defacto copy/paste of
> AS7 adapter means that every change needs to be done on 2 places.
>
> I wonder if we can try to create some common "jboss-web" module and then
> tomcat7 and jboss7 specific submodules? Those will handle just specific
> differences among AS7 and Tomcat7
> (For example common project will have simple logging abstraction, which
> will delegate to jboss-logging on AS7 or JDK-logging on Tomcat, The
> differences for establish security context on
> CatalinaSecurityContextHelper will be always abstractized etc)
>
> There are differences in dependencies, but class-names are the same (For
> example org.apache.catalina.authenticator.FormAuthenticator has same
> name and package in both tomcat and jboss-web dependency), so I believe
> that it's not a problem to compile common project against jboss-web and
> then use runtime dependency on tomcat-catalina (For Tomcat7 environment)?
>
> I am not sure myself if it's way to go, maybe it's just over-simplifying
> as the code is not big anyway. Just possible idea to think about;-)
>
> Marek
>
> On 29.10.2014 19:49, Bill Burke wrote:
>> I added the tomcat 7 adapter to the distro as well as some docbook docs
>> for it.  This is shaping up to a really nice release!
>>
>>
>

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

From bburke at redhat.com  Thu Oct 30 08:34:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 08:34:31 -0400
Subject: [keycloak-dev] 1.1 adapters no longer backward compatible
In-Reply-To: <1456217365.3249179.1414651876935.JavaMail.zimbra@redhat.com>
References: <545147D0.1090200@redhat.com>
	<1456217365.3249179.1414651876935.JavaMail.zimbra@redhat.com>
Message-ID: <54523057.9050801@redhat.com>

I didn't do it because I'm not sure yet what the URL should be or that I 
even want it to be a URL.  Some oidc libraries seem to have the option 
to validate that the ISS url is the same URL they forwarded the browser 
to.  I don't like that idea at all.  All the OIDC spec says is that the 
issuer must be an HTTPS url that uniquely identifies the issuer of the 
IDToken.

On 10/30/2014 2:51 AM, Stian Thorgersen wrote:
> Should we fix iss to return the "realm" url at the same time?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 29 October, 2014 9:02:24 PM
>> Subject: [keycloak-dev] 1.1 adapters no longer backward compatible
>>
>> Because of this bug:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-767
>>
>> I changed the aud to point ot clientid and iss to be the realm name.
>> --
>> 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  Thu Oct 30 09:26:02 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Oct 2014 14:26:02 +0100
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <2134121359.2972677.1414607351843.JavaMail.zimbra@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>
	<5451159A.5060801@redhat.com>
	<594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>
	<5451313D.7010501@redhat.com>
	<2134121359.2972677.1414607351843.JavaMail.zimbra@redhat.com>
Message-ID: <54523C6A.5030704@redhat.com>

Few more points when looking at this:

* I wonder if we can optimize removeExpiredUserSessions(realm) a bit? 
For now it's called from periodic cleaner thread (if I not count unit 
test) separately for each realm. And specifically for 'mem' provider it 
needs to iterate over all UserSessions and ClientSessions for each call. 
So for example if we have 4 realms, then periodic cleaner needs to 
iterate 4 times over UserSessions and ClientSessions. Similarly  for 
infinispan, there are 4 MapReduce calls, which could be also a bit 
expensive. I wonder if it worth to change signature to either:
"removeExpiredUserSessions()" or 
"removeExpiredUserSessions(List<RealmModel> realms)" - both cases will 
handle cleanup of all the realms. This would mean that for 'mem' we need 
to iterate just once and for infinispan, we might have just 1 MapReduce 
call.

My assumption is that in highly concurrent envs could be count of 
UserSessions and ClientSessions quite big (also 95% of people will 
likely use either 'mem' or 'infinispan' provider for this, so worth 
optimization imo?

* For InfinispanUserSessionProvider, isn't better for performance if we 
use separate cache for UserSessions and separate for ClientSessions? 
Having all in one means that MapReduce needs to filter either all 
UserSessions if you are looking for ClientSessions and viceversa. Only 
place where you can use both in same MapReduce is 
"removeUserSessions(realm)" which is likely not called often

* InfinispanUserSessionProvider is using "loginFailures" cache for login 
failures, but this one is not defined in 
DefaultInfinispanConnectionProviderFactory and also in docs for 
infinispan subsystem integration (defining cache in standalone-ha.xml). 
I believe that this should be distributable or replicated cache too 
(invalidation won't work here). Should I create separate jira for that?

thoughts?
Marek

On 29.10.2014 19:29, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, 29 October, 2014 7:26:05 PM
>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>
>> +1
>>
>> For mem we seem to be doing it too here:
>> https://github.com/keycloak/keycloak/blob/master/model/sessions-mem/src/main/java/org/keycloak/models/sessions/mem/MemUserSessionProvider.java#L197
>>
>> However it looks to me that there is bug in it. It's checking
>> ClientSessions without associated UserSession (which is ok to me as
>> those associated with UserSessionModel were cleaned previously), but the
>> bug is that it's not checking realm. So if realm 'foo' has idleTimeout
>> 30 secs, then it will cleanup all ClientSessions older than 30 seconds,
>> even from different realms...
> You're right, I miss-read the code ;)
>
>> Marek
>>
>> On 29.10.2014 19:03, Stian Thorgersen wrote:
>>> Looks like it's only Mongo and JPA that's doing this, while both mem and
>>> Infinispan are not.
>>>
>>> I reckon we just fix it for mem and Infinispan, there's not really any need
>>> for two separate methods.
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>> <keycloak-dev at lists.jboss.org>
>>>> Sent: Wednesday, 29 October, 2014 5:28:10 PM
>>>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>>>
>>>> Right now we are already doing the cleanup of expired ClientSessions in
>>>> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
>>>> providers.
>>>>
>>>> So it seems that only one missing is InfinispanUserSessionProvider.
>>>>
>>>> Maybe it's better to introduce new method on UserSessionProvider like
>>>> "removeExpiredClientSessions()" and move the removal of expired client
>>>> sessions there? Or we can keep as it is and just fix the infinispan
>>>> provider? Not sure which possibility is better.
>>>>
>>>> Marek
>>>>
>>>> On 29.10.2014 16:23, Stian Thorgersen wrote:
>>>>> As new client sessions are initially detached there's a chance they are
>>>>> never linked to a user session (for example user closes browser when
>>>>> login
>>>>> page is displayed). These client sessions are never removed. I reckon we
>>>>> need to have a similar garbage collection of client sessions as we do for
>>>>> user sessions.
>>>>>
>>>>> https://issues.jboss.org/browse/KEYCLOAK-788
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Thu Oct 30 09:32:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 09:32:32 -0400
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <54523C6A.5030704@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>	<5451159A.5060801@redhat.com>	<594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>	<5451313D.7010501@redhat.com>	<2134121359.2972677.1414607351843.JavaMail.zimbra@redhat.com>
	<54523C6A.5030704@redhat.com>
Message-ID: <54523DF0.9070600@redhat.com>

Looks good.

On 10/30/2014 9:26 AM, Marek Posolda wrote:
> Few more points when looking at this:
>
> * I wonder if we can optimize removeExpiredUserSessions(realm) a bit?
> For now it's called from periodic cleaner thread (if I not count unit
> test) separately for each realm. And specifically for 'mem' provider it
> needs to iterate over all UserSessions and ClientSessions for each call.
> So for example if we have 4 realms, then periodic cleaner needs to
> iterate 4 times over UserSessions and ClientSessions. Similarly  for
> infinispan, there are 4 MapReduce calls, which could be also a bit
> expensive. I wonder if it worth to change signature to either:
> "removeExpiredUserSessions()" or
> "removeExpiredUserSessions(List<RealmModel> realms)" - both cases will
> handle cleanup of all the realms. This would mean that for 'mem' we need
> to iterate just once and for infinispan, we might have just 1 MapReduce
> call.
>
> My assumption is that in highly concurrent envs could be count of
> UserSessions and ClientSessions quite big (also 95% of people will
> likely use either 'mem' or 'infinispan' provider for this, so worth
> optimization imo?
>
> * For InfinispanUserSessionProvider, isn't better for performance if we
> use separate cache for UserSessions and separate for ClientSessions?
> Having all in one means that MapReduce needs to filter either all
> UserSessions if you are looking for ClientSessions and viceversa. Only
> place where you can use both in same MapReduce is
> "removeUserSessions(realm)" which is likely not called often
>
> * InfinispanUserSessionProvider is using "loginFailures" cache for login
> failures, but this one is not defined in
> DefaultInfinispanConnectionProviderFactory and also in docs for
> infinispan subsystem integration (defining cache in standalone-ha.xml).
> I believe that this should be distributable or replicated cache too
> (invalidation won't work here). Should I create separate jira for that?
>
> thoughts?
> Marek
>
> On 29.10.2014 19:29, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Wednesday, 29 October, 2014 7:26:05 PM
>>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>>
>>> +1
>>>
>>> For mem we seem to be doing it too here:
>>> https://github.com/keycloak/keycloak/blob/master/model/sessions-mem/src/main/java/org/keycloak/models/sessions/mem/MemUserSessionProvider.java#L197
>>>
>>> However it looks to me that there is bug in it. It's checking
>>> ClientSessions without associated UserSession (which is ok to me as
>>> those associated with UserSessionModel were cleaned previously), but the
>>> bug is that it's not checking realm. So if realm 'foo' has idleTimeout
>>> 30 secs, then it will cleanup all ClientSessions older than 30 seconds,
>>> even from different realms...
>> You're right, I miss-read the code ;)
>>
>>> Marek
>>>
>>> On 29.10.2014 19:03, Stian Thorgersen wrote:
>>>> Looks like it's only Mongo and JPA that's doing this, while both mem and
>>>> Infinispan are not.
>>>>
>>>> I reckon we just fix it for mem and Infinispan, there's not really any need
>>>> for two separate methods.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>>> <keycloak-dev at lists.jboss.org>
>>>>> Sent: Wednesday, 29 October, 2014 5:28:10 PM
>>>>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>>>>
>>>>> Right now we are already doing the cleanup of expired ClientSessions in
>>>>> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
>>>>> providers.
>>>>>
>>>>> So it seems that only one missing is InfinispanUserSessionProvider.
>>>>>
>>>>> Maybe it's better to introduce new method on UserSessionProvider like
>>>>> "removeExpiredClientSessions()" and move the removal of expired client
>>>>> sessions there? Or we can keep as it is and just fix the infinispan
>>>>> provider? Not sure which possibility is better.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 29.10.2014 16:23, Stian Thorgersen wrote:
>>>>>> As new client sessions are initially detached there's a chance they are
>>>>>> never linked to a user session (for example user closes browser when
>>>>>> login
>>>>>> page is displayed). These client sessions are never removed. I reckon we
>>>>>> need to have a similar garbage collection of client sessions as we do for
>>>>>> user sessions.
>>>>>>
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-788
>>>>>> _______________________________________________
>>>>>> 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  Thu Oct 30 10:25:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Oct 2014 10:25:48 -0400 (EDT)
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <5450C00C.8040704@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com>
Message-ID: <1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Juraci Paix?o Kr?hling" <jcosta at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 29 October, 2014 11:23:08 AM
> Subject: Re: Multi tenant review
> 
> Stian,
> 
> Agree with all the comments. I'm doing the changes, but I've got a
> question and a few comments. See below.
> 
> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
> > 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out the
> > realm if the session was serialized? when adapter is clustered we support
> > serializing the session
> 
> I'm then changing one of the SecurityContext's to include the realm, so
> that it gets de-serialized with this information. Now, the question is
> whether it is more appropriate to add it to KeycloakSecurityContext or
> RefreshableKeycloakSecurityContext. On the superclass
> (KeycloakSecurityContext), I have access only to IdToken and
> AccessToken. I believe both have ways to retrieve the realm (issuer, I
> believe), but I don't know how reliable this is. I remember seeing a
> post from Bill on keycloak-user that it should be changed to an URL, not
> the realm name. On the subclass, however, I have access to the
> KeycloakDeployment, which provides the realm on the exact way that it
> was originally configured.

TBH I have no idea - Marek can hopefully elaborate on this

> 
> > 4. KeycloakAuthenticatorValve.initInternal - just do a warn + unconfigured
> > to make it behave same as if keycloak-server.json is missing, and drop the
> > comment
> 
> Ok, but just to confirm: I should add a new warn with the same text as
> the other and *not* attempt to load a keycloak.json, right? The question
> is because there might be a non-existing resolver specified *and* a
> keycloak.json . As it is, there will be a warn on the log, saying that
> the resolver will not be used, but as there is a keycloak.json, a
> KeycloakDeployment is available.
> 
> Based on your comment, I assume that this is a configuration problem,
> hence, it should not attempt to load keycloak.json if a resolver is
> specified.

Yes, it should ignore 'keycloak.json' in this case. It could be debatable whether or not throwing an exception would be a better option, but I think it's simpler to just match existing functionality

> 
> > 6. CatalinaCookieTokenStore.checkPrincipalFromCookie - if cookie has
> > different realm I'd say the log should at least be a warn, is this not a
> > significant problem?
> > 7. CatalinaSessionTokenStore.checkCurrentToken - same as above isn't
> cookie with different realm a pretty big issue?
> 
> I don't think it's a significant problem. It will happen when one user
> has access to two realms, is logged in on the first and then tries to
> access the same application on a second tenant. On this case, the cookie
> sent is for the first tenant, so, we should consider it invalid for this
> request, meaning, the principal for this cookie for this realm is
> unknown (return null). On this scenario, Keycloak will redirect the user
> for logging in on the second realm, which will effectively override the
> first cookie. This scenario is tested on
> MultiTenancyTest#testTenantsWithoutLoggingOut .

Hmm.. So basically a user can only be logged-in to one tenant at the time? I think we'd need some fix for that.

> 
> - Juca.
> 
> 
> 
> 
> 


From stian at redhat.com  Thu Oct 30 11:56:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Oct 2014 11:56:14 -0400 (EDT)
Subject: [keycloak-dev] Multi-tenancy support for adapters merged
In-Reply-To: <1421008879.4200218.1414684535280.JavaMail.zimbra@redhat.com>
Message-ID: <862998831.4200622.1414684574331.JavaMail.zimbra@redhat.com>

Thanks to Juraci Paix?o Kr?hling we now have support for multi-tenancy in adapters


From mposolda at redhat.com  Thu Oct 30 15:05:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Oct 2014 20:05:52 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>	<5450C00C.8040704@redhat.com>
	<1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>
Message-ID: <54528C10.7060307@redhat.com>

On 30.10.2014 15:25, Stian Thorgersen wrote:
>> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
>>> > >3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out the
>>> > >realm if the session was serialized? when adapter is clustered we support
>>> > >serializing the session
>> >
>> >I'm then changing one of the SecurityContext's to include the realm, so
>> >that it gets de-serialized with this information. Now, the question is
>> >whether it is more appropriate to add it to KeycloakSecurityContext or
>> >RefreshableKeycloakSecurityContext. On the superclass
>> >(KeycloakSecurityContext), I have access only to IdToken and
>> >AccessToken. I believe both have ways to retrieve the realm (issuer, I
>> >believe), but I don't know how reliable this is. I remember seeing a
>> >post from Bill on keycloak-user that it should be changed to an URL, not
>> >the realm name. On the subclass, however, I have access to the
>> >KeycloakDeployment, which provides the realm on the exact way that it
>> >was originally configured.
> TBH I have no idea - Marek can hopefully elaborate on this
>
I am not sure too TBH:-)

Right now we have realm name available on AccessToken in "iss", so atm 
the realm property on KeycloakSecurityContext is redundant. However it's 
unclear if we still have it as it's possible that it's not compatible 
with some 3rd party OIDC providers like Google, so in the future, we 
would need to change this to URL. Quite related to parallel thread "1.1 
adapters no longer backward compatible" .

My vote is to remove realm property from KeycloakSecurityContext for now 
and implement getRealm method like:

     public String getRealm() {
         return token.getIssuer();
     }

I think that if we need in the future issuer to contain URL, we will 
probably anyway add another "custom" property to AccessToken containing 
realm name.

Thoughts?

Marek

From bburke at redhat.com  Thu Oct 30 18:29:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 18:29:59 -0400
Subject: [keycloak-dev] Create Principal instance with username instead?
Message-ID: <5452BBE7.1000303@redhat.com>

Right no UserPrincipal is created in the adapters using the user id. 
For strictly pure Servlet apps, an ID is pretty ugly.  I don't want to 
force them to use keycloak code.

So...is it ok to populate the principal name with 
accessToken.getPreferredUsername()?

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

From bburke at redhat.com  Thu Oct 30 18:38:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 18:38:29 -0400
Subject: [keycloak-dev] BRMS Good news/ Bad news
Message-ID: <5452BDE5.1050009@redhat.com>

Looked into security JBoss BRMS 6.0.2 with Keycloak.

Good news is that I can secure brms console login just by installing the 
keycloak adapter and turning it on in the WAR of BRMS.  Bad news is that 
keycloak initiated logout doesn't work that great.  It just disables the 
console.

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

From ssilvert at redhat.com  Thu Oct 30 18:58:51 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 30 Oct 2014 18:58:51 -0400
Subject: [keycloak-dev] BRMS Good news/ Bad news
In-Reply-To: <5452BDE5.1050009@redhat.com>
References: <5452BDE5.1050009@redhat.com>
Message-ID: <5452C2AB.8000006@redhat.com>

On 10/30/2014 6:38 PM, Bill Burke wrote:
> Looked into security JBoss BRMS 6.0.2 with Keycloak.
>
> Good news is that I can secure brms console login just by installing the
> keycloak adapter and turning it on in the WAR of BRMS.  Bad news is that
> keycloak initiated logout doesn't work that great.  It just disables the
> console.
>
Yea, we're going to have the same problem with the EAP Console, except 
it's even worse because there is no WAR at all.  It will require some 
special logic in the console.

From bburke at redhat.com  Thu Oct 30 19:34:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 19:34:32 -0400
Subject: [keycloak-dev] BRMS Good news/ Bad news
In-Reply-To: <5452C2AB.8000006@redhat.com>
References: <5452BDE5.1050009@redhat.com> <5452C2AB.8000006@redhat.com>
Message-ID: <5452CB08.8000806@redhat.com>

Worse than that for BRMS.  BRMS logout from their console doesn't work 
with Keycloak enabled...

On 10/30/2014 6:58 PM, Stan Silvert wrote:
> On 10/30/2014 6:38 PM, Bill Burke wrote:
>> Looked into security JBoss BRMS 6.0.2 with Keycloak.
>>
>> Good news is that I can secure brms console login just by installing the
>> keycloak adapter and turning it on in the WAR of BRMS.  Bad news is that
>> keycloak initiated logout doesn't work that great.  It just disables the
>> console.
>>
> Yea, we're going to have the same problem with the EAP Console, except
> it's even worse because there is no WAR at all.  It will require some
> special logic in the console.
> _______________________________________________
> 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  Thu Oct 30 18:43:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 30 Oct 2014 23:43:14 +0100
Subject: [keycloak-dev] ClientSessions may never be removed
In-Reply-To: <54523DF0.9070600@redhat.com>
References: <1824106610.2784947.1414596224910.JavaMail.zimbra@redhat.com>	<5451159A.5060801@redhat.com>	<594216559.2958691.1414605780504.JavaMail.zimbra@redhat.com>	<5451313D.7010501@redhat.com>	<2134121359.2972677.1414607351843.JavaMail.zimbra@redhat.com>	<54523C6A.5030704@redhat.com>
	<54523DF0.9070600@redhat.com>
Message-ID: <5452BF02.8090701@redhat.com>

I've fixed some issues, but just created JIRAs for the performance 
optimizations with fix version 1.X.
https://issues.jboss.org/browse/KEYCLOAK-801
https://issues.jboss.org/browse/KEYCLOAK-802

These are not the bugs, so I can look at them later, probably after 
release (will first finish setup of performance test, which will use 
bigger number of UserSessions + ClientSessions and then try search them).

Marek

On 30.10.2014 14:32, Bill Burke wrote:
> Looks good.
>
> On 10/30/2014 9:26 AM, Marek Posolda wrote:
>> Few more points when looking at this:
>>
>> * I wonder if we can optimize removeExpiredUserSessions(realm) a bit?
>> For now it's called from periodic cleaner thread (if I not count unit
>> test) separately for each realm. And specifically for 'mem' provider it
>> needs to iterate over all UserSessions and ClientSessions for each call.
>> So for example if we have 4 realms, then periodic cleaner needs to
>> iterate 4 times over UserSessions and ClientSessions. Similarly  for
>> infinispan, there are 4 MapReduce calls, which could be also a bit
>> expensive. I wonder if it worth to change signature to either:
>> "removeExpiredUserSessions()" or
>> "removeExpiredUserSessions(List<RealmModel> realms)" - both cases will
>> handle cleanup of all the realms. This would mean that for 'mem' we need
>> to iterate just once and for infinispan, we might have just 1 MapReduce
>> call.
>>
>> My assumption is that in highly concurrent envs could be count of
>> UserSessions and ClientSessions quite big (also 95% of people will
>> likely use either 'mem' or 'infinispan' provider for this, so worth
>> optimization imo?
>>
>> * For InfinispanUserSessionProvider, isn't better for performance if we
>> use separate cache for UserSessions and separate for ClientSessions?
>> Having all in one means that MapReduce needs to filter either all
>> UserSessions if you are looking for ClientSessions and viceversa. Only
>> place where you can use both in same MapReduce is
>> "removeUserSessions(realm)" which is likely not called often
>>
>> * InfinispanUserSessionProvider is using "loginFailures" cache for login
>> failures, but this one is not defined in
>> DefaultInfinispanConnectionProviderFactory and also in docs for
>> infinispan subsystem integration (defining cache in standalone-ha.xml).
>> I believe that this should be distributable or replicated cache too
>> (invalidation won't work here). Should I create separate jira for that?
>>
>> thoughts?
>> Marek
>>
>> On 29.10.2014 19:29, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Wednesday, 29 October, 2014 7:26:05 PM
>>>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>>>
>>>> +1
>>>>
>>>> For mem we seem to be doing it too here:
>>>> https://github.com/keycloak/keycloak/blob/master/model/sessions-mem/src/main/java/org/keycloak/models/sessions/mem/MemUserSessionProvider.java#L197
>>>>
>>>> However it looks to me that there is bug in it. It's checking
>>>> ClientSessions without associated UserSession (which is ok to me as
>>>> those associated with UserSessionModel were cleaned previously), but the
>>>> bug is that it's not checking realm. So if realm 'foo' has idleTimeout
>>>> 30 secs, then it will cleanup all ClientSessions older than 30 seconds,
>>>> even from different realms...
>>> You're right, I miss-read the code ;)
>>>
>>>> Marek
>>>>
>>>> On 29.10.2014 19:03, Stian Thorgersen wrote:
>>>>> Looks like it's only Mongo and JPA that's doing this, while both mem and
>>>>> Infinispan are not.
>>>>>
>>>>> I reckon we just fix it for mem and Infinispan, there's not really any need
>>>>> for two separate methods.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>>>> <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Wednesday, 29 October, 2014 5:28:10 PM
>>>>>> Subject: Re: [keycloak-dev] ClientSessions may never be removed
>>>>>>
>>>>>> Right now we are already doing the cleanup of expired ClientSessions in
>>>>>> UserSessionProvider.removeExpiredUserSessions() for mem, jpa and mongo
>>>>>> providers.
>>>>>>
>>>>>> So it seems that only one missing is InfinispanUserSessionProvider.
>>>>>>
>>>>>> Maybe it's better to introduce new method on UserSessionProvider like
>>>>>> "removeExpiredClientSessions()" and move the removal of expired client
>>>>>> sessions there? Or we can keep as it is and just fix the infinispan
>>>>>> provider? Not sure which possibility is better.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 29.10.2014 16:23, Stian Thorgersen wrote:
>>>>>>> As new client sessions are initially detached there's a chance they are
>>>>>>> never linked to a user session (for example user closes browser when
>>>>>>> login
>>>>>>> page is displayed). These client sessions are never removed. I reckon we
>>>>>>> need to have a similar garbage collection of client sessions as we do for
>>>>>>> user sessions.
>>>>>>>
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-788
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Thu Oct 30 19:47:27 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 30 Oct 2014 19:47:27 -0400
Subject: [keycloak-dev] BRMS Good news/ Bad news
In-Reply-To: <5452CB08.8000806@redhat.com>
References: <5452BDE5.1050009@redhat.com> <5452C2AB.8000006@redhat.com>
	<5452CB08.8000806@redhat.com>
Message-ID: <5452CE0F.8080004@redhat.com>

On 10/30/2014 7:34 PM, Bill Burke wrote:
> Worse than that for BRMS.  BRMS logout from their console doesn't work
> with Keycloak enabled...
You win.
>
> On 10/30/2014 6:58 PM, Stan Silvert wrote:
>> On 10/30/2014 6:38 PM, Bill Burke wrote:
>>> Looked into security JBoss BRMS 6.0.2 with Keycloak.
>>>
>>> Good news is that I can secure brms console login just by installing the
>>> keycloak adapter and turning it on in the WAR of BRMS.  Bad news is that
>>> keycloak initiated logout doesn't work that great.  It just disables the
>>> console.
>>>
>> Yea, we're going to have the same problem with the EAP Console, except
>> it's even worse because there is no WAR at all.  It will require some
>> special logic in the console.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Thu Oct 30 19:59:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Oct 2014 19:59:17 -0400
Subject: [keycloak-dev] BRMS Good news/ Bad news
In-Reply-To: <5452CE0F.8080004@redhat.com>
References: <5452BDE5.1050009@redhat.com>
	<5452C2AB.8000006@redhat.com>	<5452CB08.8000806@redhat.com>
	<5452CE0F.8080004@redhat.com>
Message-ID: <5452D0D5.9090804@redhat.com>

Meh, figured out one of the problems.  Uberfire is invalidating the 
session before calling HttpServletRequest.logout().  Keycloak adapter is 
storing information in session so can't communicate with auth server to 
perform user session logout.

On 10/30/2014 7:47 PM, Stan Silvert wrote:
> On 10/30/2014 7:34 PM, Bill Burke wrote:
>> Worse than that for BRMS.  BRMS logout from their console doesn't work
>> with Keycloak enabled...
> You win.
>>
>> On 10/30/2014 6:58 PM, Stan Silvert wrote:
>>> On 10/30/2014 6:38 PM, Bill Burke wrote:
>>>> Looked into security JBoss BRMS 6.0.2 with Keycloak.
>>>>
>>>> Good news is that I can secure brms console login just by installing the
>>>> keycloak adapter and turning it on in the WAR of BRMS.  Bad news is that
>>>> keycloak initiated logout doesn't work that great.  It just disables the
>>>> console.
>>>>
>>> Yea, we're going to have the same problem with the EAP Console, except
>>> it's even worse because there is no WAR at all.  It will require some
>>> special logic in the console.
>>> _______________________________________________
>>> 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  Fri Oct 31 03:00:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 03:00:33 -0400 (EDT)
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <54528C10.7060307@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com>
	<1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>
	<54528C10.7060307@redhat.com>
Message-ID: <1824912737.4612825.1414738833883.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, jpkroehling at redhat.com
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 30 October, 2014 8:05:52 PM
> Subject: Re: [keycloak-dev] Multi tenant review
> 
> On 30.10.2014 15:25, Stian Thorgersen wrote:
> >> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
> >>> > >3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out
> >>> > >the
> >>> > >realm if the session was serialized? when adapter is clustered we
> >>> > >support
> >>> > >serializing the session
> >> >
> >> >I'm then changing one of the SecurityContext's to include the realm, so
> >> >that it gets de-serialized with this information. Now, the question is
> >> >whether it is more appropriate to add it to KeycloakSecurityContext or
> >> >RefreshableKeycloakSecurityContext. On the superclass
> >> >(KeycloakSecurityContext), I have access only to IdToken and
> >> >AccessToken. I believe both have ways to retrieve the realm (issuer, I
> >> >believe), but I don't know how reliable this is. I remember seeing a
> >> >post from Bill on keycloak-user that it should be changed to an URL, not
> >> >the realm name. On the subclass, however, I have access to the
> >> >KeycloakDeployment, which provides the realm on the exact way that it
> >> >was originally configured.
> > TBH I have no idea - Marek can hopefully elaborate on this
> >
> I am not sure too TBH:-)
> 
> Right now we have realm name available on AccessToken in "iss", so atm
> the realm property on KeycloakSecurityContext is redundant. However it's
> unclear if we still have it as it's possible that it's not compatible
> with some 3rd party OIDC providers like Google, so in the future, we
> would need to change this to URL. Quite related to parallel thread "1.1
> adapters no longer backward compatible" .
> 
> My vote is to remove realm property from KeycloakSecurityContext for now
> and implement getRealm method like:
> 
>      public String getRealm() {
>          return token.getIssuer();
>      }
> 
> I think that if we need in the future issuer to contain URL, we will
> probably anyway add another "custom" property to AccessToken containing
> realm name.
> 
> Thoughts?

Sounds sensible to me

> 
> Marek
> 

From stian at redhat.com  Fri Oct 31 03:11:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 03:11:23 -0400 (EDT)
Subject: [keycloak-dev] Create Principal instance with username instead?
In-Reply-To: <5452BBE7.1000303@redhat.com>
References: <5452BBE7.1000303@redhat.com>
Message-ID: <2007654044.4614550.1414739483532.JavaMail.zimbra@redhat.com>

-1

We should stick with ID as we can guarantee that it's unique (in the future).

If app starts using the username in their dbs you can end up with situations where the wrong user gets access to things he shouldn't. For example:

* If user with username userA is removed from Keycloak, then later a new user is registered as userA
* If we support changing username in the future (this is on the road-map, and IMO it makes sense to add this with a toggle in the realm to enable/disable)

What difference does it make if it's ugly? If apps wants to display details about the user they should get the profile. Sadly there's no direct support for this in Principal.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 30 October, 2014 11:29:59 PM
> Subject: [keycloak-dev] Create Principal instance with username instead?
> 
> Right no UserPrincipal is created in the adapters using the user id.
> For strictly pure Servlet apps, an ID is pretty ugly.  I don't want to
> force them to use keycloak code.
> 
> So...is it ok to populate the principal name with
> accessToken.getPreferredUsername()?
> 
> --
> 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 Oct 31 04:15:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 04:15:22 -0400 (EDT)
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
Message-ID: <862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>

Looks good to me. We should include this in Beta1.

A few comments/questions:

* Can we support enabling confidential transport-guarantee (auth-server/WEB-INF/web.xml) without cracking open the WAR? This seems to be the last requirement for an exploded WAR
* How to manually add a provider?
* How to use add-provider and update-server-config? I'm still a bit unclear on how the 'update-server-config' works, can you elaborate a bit on this?
* What's the "new CLI GUI"? Why doesn't it work with the old CLI?
* How to add themes in domain mode? Is that with provider jar?

Documentation obviously needs updating before Beta1 is released. We also need to test that it works with the OpenShift Cartridge.

Stan, can we get rid of these:
  08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is using a private module ...

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 October, 2014 3:56:18 PM
> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
> 
> I'd like to have a look at this before we merge it, but won't have time until
> tomorrow (maybe Friday).
> 
> ----- Original Message -----
> > From: "Stan Silvert" <ssilvert at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 29 October, 2014 3:25:55 PM
> > Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
> > subsystem
> > 
> > On 10/29/2014 10:07 AM, Bill Burke wrote:
> > >
> > > On 10/29/2014 9:28 AM, Stan Silvert wrote:
> > >>    * EAP6 does not yet support all this.  We should discuss whether or
> > >>      not this functionality should be backported.
> > >>
> > > +1 for this, but maybe some focus should be on getting a more seamless
> > > "hello world" like we discussed in a previous thread?
> > >
> > I agree.  IMO, the next step should be Feature Pack installation and the
> > seamless "hello world".   Then we look at EAP6.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Fri Oct 31 05:56:04 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 31 Oct 2014 10:56:04 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <1824912737.4612825.1414738833883.JavaMail.zimbra@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>
	<5450C00C.8040704@redhat.com>
	<1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>
	<54528C10.7060307@redhat.com>
	<1824912737.4612825.1414738833883.JavaMail.zimbra@redhat.com>
Message-ID: <54535CB4.4080600@redhat.com>

On 31.10.2014 08:00, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, jpkroehling at redhat.com
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 30 October, 2014 8:05:52 PM
>> Subject: Re: [keycloak-dev] Multi tenant review
>>
>> On 30.10.2014 15:25, Stian Thorgersen wrote:
>>>> On 10/28/2014 04:54 PM, Stian Thorgersen wrote:
>>>>>>> 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out
>>>>>>> the
>>>>>>> realm if the session was serialized? when adapter is clustered we
>>>>>>> support
>>>>>>> serializing the session
>>>>> I'm then changing one of the SecurityContext's to include the realm, so
>>>>> that it gets de-serialized with this information. Now, the question is
>>>>> whether it is more appropriate to add it to KeycloakSecurityContext or
>>>>> RefreshableKeycloakSecurityContext. On the superclass
>>>>> (KeycloakSecurityContext), I have access only to IdToken and
>>>>> AccessToken. I believe both have ways to retrieve the realm (issuer, I
>>>>> believe), but I don't know how reliable this is. I remember seeing a
>>>>> post from Bill on keycloak-user that it should be changed to an URL, not
>>>>> the realm name. On the subclass, however, I have access to the
>>>>> KeycloakDeployment, which provides the realm on the exact way that it
>>>>> was originally configured.
>>> TBH I have no idea - Marek can hopefully elaborate on this
>>>
>> I am not sure too TBH:-)
>>
>> Right now we have realm name available on AccessToken in "iss", so atm
>> the realm property on KeycloakSecurityContext is redundant. However it's
>> unclear if we still have it as it's possible that it's not compatible
>> with some 3rd party OIDC providers like Google, so in the future, we
>> would need to change this to URL. Quite related to parallel thread "1.1
>> adapters no longer backward compatible" .
>>
>> My vote is to remove realm property from KeycloakSecurityContext for now
>> and implement getRealm method like:
>>
>>       public String getRealm() {
>>           return token.getIssuer();
>>       }
>>
>> I think that if we need in the future issuer to contain URL, we will
>> probably anyway add another "custom" property to AccessToken containing
>> realm name.
>>
>> Thoughts?
> Sounds sensible to me
Great, I am going to change it this way.

Marek
>
>> Marek
>>


From ssilvert at redhat.com  Fri Oct 31 07:43:16 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 31 Oct 2014 07:43:16 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
Message-ID: <545375D4.8060905@redhat.com>

On 10/31/2014 4:15 AM, Stian Thorgersen wrote:
> Looks good to me. We should include this in Beta1.
>
> A few comments/questions:
>
> * Can we support enabling confidential transport-guarantee (auth-server/WEB-INF/web.xml) without cracking open the WAR? This seems to be the last requirement for an exploded WAR
I didn't know about that.  I can add it.
> * How to manually add a provider?
> * How to use add-provider and update-server-config? I'm still a bit unclear on how the 'update-server-config' works, can you elaborate a bit on this?
I should be done with updating the doc today.  These questions will be 
answered there.
> * What's the "new CLI GUI"? Why doesn't it work with the old CLI?
This is CLI GUI: 
https://developer.jboss.org/wiki/AGUIForTheCommandLineInterface
It's been around almost three years and I'm quite proud of it, but a lot 
of people don't know it exists.  I just added a new feature to CLI GUI 
that automatically uploads bytes for operations that require uploads.  
To do this in regular CLI, you would need to write code for a 
meta-command like "deploy".  Soon I'll talk to Alexey about adding this 
feature to regular CLI as well.

The new feature will be available with WildFly Core 1.0.0.Alpha11. 
Should be out soon.  For now you have to build from master to get it.  
You just need a single jar and it works with older WildFly/EAP versions. 
https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar
> * How to add themes in domain mode? Is that with provider jar?
Yes.
> Documentation obviously needs updating before Beta1 is released. We also need to test that it works with the OpenShift Cartridge.
I can't think of a reason why it wouldn't work.  I know CLI GUI works 
with OpenShift.  But yea, we need to test it.

BTW, using CLI GUI is just temporary.  I think it won't be long before 
we can front-end the Keycloak subsystem in Keycloak admin.
>
> Stan, can we get rid of these:
>    08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service thread 1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is using a private module ...
I don't think that's related to my PR.  I think you'll see those when 
you deploy from the /deployments directory as well.

The messages are for the jackson and httpcomponents modules.  I think I 
can get rid of the messages if we remove the <dependencies> section from 
jboss-deployment-structure.xml. Those dependencies should be added using 
KeycloakDependencyProcessor instead.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Stan Silvert" <ssilvert at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
>>
>> I'd like to have a look at this before we merge it, but won't have time until
>> tomorrow (maybe Friday).
>>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
>>> subsystem
>>>
>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
>>>>>     * EAP6 does not yet support all this.  We should discuss whether or
>>>>>       not this functionality should be backported.
>>>>>
>>>> +1 for this, but maybe some focus should be on getting a more seamless
>>>> "hello world" like we discussed in a previous thread?
>>>>
>>> I agree.  IMO, the next step should be Feature Pack installation and the
>>> seamless "hello world".   Then we look at EAP6.
>>> _______________________________________________
>>> 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  Fri Oct 31 07:55:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 07:55:18 -0400 (EDT)
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <545375D4.8060905@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
Message-ID: <1862791896.4758552.1414756518293.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: Friday, 31 October, 2014 12:43:16 PM
> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
> 
> On 10/31/2014 4:15 AM, Stian Thorgersen wrote:
> > Looks good to me. We should include this in Beta1.
> >
> > A few comments/questions:
> >
> > * Can we support enabling confidential transport-guarantee
> > (auth-server/WEB-INF/web.xml) without cracking open the WAR? This seems to
> > be the last requirement for an exploded WAR
> I didn't know about that.  I can add it.
> > * How to manually add a provider?
> > * How to use add-provider and update-server-config? I'm still a bit unclear
> > on how the 'update-server-config' works, can you elaborate a bit on this?
> I should be done with updating the doc today.  These questions will be
> answered there.
> > * What's the "new CLI GUI"? Why doesn't it work with the old CLI?
> This is CLI GUI:
> https://developer.jboss.org/wiki/AGUIForTheCommandLineInterface
> It's been around almost three years and I'm quite proud of it, but a lot
> of people don't know it exists.  I just added a new feature to CLI GUI
> that automatically uploads bytes for operations that require uploads.
> To do this in regular CLI, you would need to write code for a
> meta-command like "deploy".  Soon I'll talk to Alexey about adding this
> feature to regular CLI as well.
> 
> The new feature will be available with WildFly Core 1.0.0.Alpha11.
> Should be out soon.  For now you have to build from master to get it.
> You just need a single jar and it works with older WildFly/EAP versions.
> https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar
> > * How to add themes in domain mode? Is that with provider jar?
> Yes.
> > Documentation obviously needs updating before Beta1 is released. We also
> > need to test that it works with the OpenShift Cartridge.
> I can't think of a reason why it wouldn't work.  I know CLI GUI works
> with OpenShift.  But yea, we need to test it.

I can update and test the cartridge

> 
> BTW, using CLI GUI is just temporary.  I think it won't be long before
> we can front-end the Keycloak subsystem in Keycloak admin.
> >
> > Stan, can we get rid of these:
> >    08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service thread
> >    1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is using
> >    a private module ...
> I don't think that's related to my PR.  I think you'll see those when
> you deploy from the /deployments directory as well.
> 
> The messages are for the jackson and httpcomponents modules.  I think I
> can get rid of the messages if we remove the <dependencies> section from
> jboss-deployment-structure.xml. Those dependencies should be added using
> KeycloakDependencyProcessor instead.

Yes, it's not caused by your PR (I should have clarified that), was just hoping there was some magic we could do in the subsystem to get rid of those.

Removing dependencies section would brake it when deployed as WAR though. Can you modify the dependencies in the deployment-process instead?

> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Stan Silvert" <ssilvert at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 29 October, 2014 3:56:18 PM
> >> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
> >> KC subsystem
> >>
> >> I'd like to have a look at this before we merge it, but won't have time
> >> until
> >> tomorrow (maybe Friday).
> >>
> >> ----- Original Message -----
> >>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
> >>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
> >>> KC
> >>> subsystem
> >>>
> >>> On 10/29/2014 10:07 AM, Bill Burke wrote:
> >>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
> >>>>>     * EAP6 does not yet support all this.  We should discuss whether or
> >>>>>       not this functionality should be backported.
> >>>>>
> >>>> +1 for this, but maybe some focus should be on getting a more seamless
> >>>> "hello world" like we discussed in a previous thread?
> >>>>
> >>> I agree.  IMO, the next step should be Feature Pack installation and the
> >>> seamless "hello world".   Then we look at EAP6.
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From bburke at redhat.com  Fri Oct 31 08:29:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 31 Oct 2014 08:29:47 -0400
Subject: [keycloak-dev] Create Principal instance with username instead?
In-Reply-To: <2007654044.4614550.1414739483532.JavaMail.zimbra@redhat.com>
References: <5452BBE7.1000303@redhat.com>
	<2007654044.4614550.1414739483532.JavaMail.zimbra@redhat.com>
Message-ID: <545380BB.60906@redhat.com>

I'll add a flag to the adapter then.  The reason is, again, pure servlet 
apps, like BRMS that display the principal name in their UI.

On 10/31/2014 3:11 AM, Stian Thorgersen wrote:
> -1
>
> We should stick with ID as we can guarantee that it's unique (in the future).
>
> If app starts using the username in their dbs you can end up with situations where the wrong user gets access to things he shouldn't. For example:
>
> * If user with username userA is removed from Keycloak, then later a new user is registered as userA
> * If we support changing username in the future (this is on the road-map, and IMO it makes sense to add this with a toggle in the realm to enable/disable)
>
> What difference does it make if it's ugly? If apps wants to display details about the user they should get the profile. Sadly there's no direct support for this in Principal.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 30 October, 2014 11:29:59 PM
>> Subject: [keycloak-dev] Create Principal instance with username instead?
>>
>> Right no UserPrincipal is created in the adapters using the user id.
>> For strictly pure Servlet apps, an ID is pretty ugly.  I don't want to
>> force them to use keycloak code.
>>
>> So...is it ok to populate the principal name with
>> accessToken.getPreferredUsername()?
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From mposolda at redhat.com  Fri Oct 31 08:32:48 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 31 Oct 2014 13:32:48 +0100
Subject: [keycloak-dev] Multi tenant review
In-Reply-To: <54535CB4.4080600@redhat.com>
References: <1101731711.1914184.1414511675585.JavaMail.zimbra@redhat.com>	<5450C00C.8040704@redhat.com>	<1639116376.4140698.1414679148073.JavaMail.zimbra@redhat.com>	<54528C10.7060307@redhat.com>	<1824912737.4612825.1414738833883.JavaMail.zimbra@redhat.com>
	<54535CB4.4080600@redhat.com>
Message-ID: <54538170.4020101@redhat.com>

I've pushed the changes to master. It was also an opportunity to re-test 
our new multitenancy feature! I fixed few things, so now multitenancy 
should work on EAP 6.3 too (it seems it was tested just on wildfly 8.1 
until now) .

Marek

On 31.10.2014 10:56, Marek Posolda wrote:
>>> I am not sure too TBH:-)
>>> >>
>>> >>Right now we have realm name available on AccessToken in "iss", so atm
>>> >>the realm property on KeycloakSecurityContext is redundant. However it's
>>> >>unclear if we still have it as it's possible that it's not compatible
>>> >>with some 3rd party OIDC providers like Google, so in the future, we
>>> >>would need to change this to URL. Quite related to parallel thread "1.1
>>> >>adapters no longer backward compatible" .
>>> >>
>>> >>My vote is to remove realm property from KeycloakSecurityContext for now
>>> >>and implement getRealm method like:
>>> >>
>>> >>       public String getRealm() {
>>> >>           return token.getIssuer();
>>> >>       }
>>> >>
>>> >>I think that if we need in the future issuer to contain URL, we will
>>> >>probably anyway add another "custom" property to AccessToken containing
>>> >>realm name.
>>> >>
>>> >>Thoughts?
>> >Sounds sensible to me
> Great, I am going to change it this way.
>
> Marek


From ssilvert at redhat.com  Fri Oct 31 08:41:59 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 31 Oct 2014 08:41:59 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
	<1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
Message-ID: <54538397.40706@redhat.com>

On 10/31/2014 7:55 AM, Stian Thorgersen wrote:
>
>>> Stan, can we get rid of these:
>>>     08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service thread
>>>     1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is using
>>>     a private module ...
>> I don't think that's related to my PR.  I think you'll see those when
>> you deploy from the /deployments directory as well.
>>
>> The messages are for the jackson and httpcomponents modules.  I think I
>> can get rid of the messages if we remove the <dependencies> section from
>> jboss-deployment-structure.xml. Those dependencies should be added using
>> KeycloakDependencyProcessor instead.
> Yes, it's not caused by your PR (I should have clarified that), was just hoping there was some magic we could do in the subsystem to get rid of those.
>
> Removing dependencies section would brake it when deployed as WAR though. Can you modify the dependencies in the deployment-process instead?
It would only brake when the Keycloak subsystem is not installed. You 
can still deploy as a WAR.  Don't we require that anyway on WildFly/EAP 
deployments?

The other thing we could do is to install our own versions of 
httpcomponents and jackson.
>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
>>>> KC subsystem
>>>>
>>>> I'd like to have a look at this before we merge it, but won't have time
>>>> until
>>>> tomorrow (maybe Friday).
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
>>>>> KC
>>>>> subsystem
>>>>>
>>>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
>>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
>>>>>>>      * EAP6 does not yet support all this.  We should discuss whether or
>>>>>>>        not this functionality should be backported.
>>>>>>>
>>>>>> +1 for this, but maybe some focus should be on getting a more seamless
>>>>>> "hello world" like we discussed in a previous thread?
>>>>>>
>>>>> I agree.  IMO, the next step should be Feature Pack installation and the
>>>>> seamless "hello world".   Then we look at EAP6.
>>>>> _______________________________________________
>>>>> 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  Fri Oct 31 08:47:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 08:47:20 -0400 (EDT)
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <54538397.40706@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
	<1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
	<54538397.40706@redhat.com>
Message-ID: <1950519939.4789756.1414759640083.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: Friday, 31 October, 2014 1:41:59 PM
> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
> 
> On 10/31/2014 7:55 AM, Stian Thorgersen wrote:
> >
> >>> Stan, can we get rid of these:
> >>>     08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service
> >>>     thread
> >>>     1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is
> >>>     using
> >>>     a private module ...
> >> I don't think that's related to my PR.  I think you'll see those when
> >> you deploy from the /deployments directory as well.
> >>
> >> The messages are for the jackson and httpcomponents modules.  I think I
> >> can get rid of the messages if we remove the <dependencies> section from
> >> jboss-deployment-structure.xml. Those dependencies should be added using
> >> KeycloakDependencyProcessor instead.
> > Yes, it's not caused by your PR (I should have clarified that), was just
> > hoping there was some magic we could do in the subsystem to get rid of
> > those.
> >
> > Removing dependencies section would brake it when deployed as WAR though.
> > Can you modify the dependencies in the deployment-process instead?
> It would only brake when the Keycloak subsystem is not installed. You
> can still deploy as a WAR.  Don't we require that anyway on WildFly/EAP
> deployments?

How about when we deploy to AS7 and EAP6?

> 
> The other thing we could do is to install our own versions of
> httpcomponents and jackson.

Or just put them in WEB-INF/lib? We already have a few deps in there

> >
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "Stan Silvert" <ssilvert at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
> >>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
> >>>> KC subsystem
> >>>>
> >>>> I'd like to have a look at this before we merge it, but won't have time
> >>>> until
> >>>> tomorrow (maybe Friday).
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>> To: keycloak-dev at lists.jboss.org
> >>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
> >>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
> >>>>> into
> >>>>> KC
> >>>>> subsystem
> >>>>>
> >>>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
> >>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
> >>>>>>>      * EAP6 does not yet support all this.  We should discuss whether
> >>>>>>>      or
> >>>>>>>        not this functionality should be backported.
> >>>>>>>
> >>>>>> +1 for this, but maybe some focus should be on getting a more seamless
> >>>>>> "hello world" like we discussed in a previous thread?
> >>>>>>
> >>>>> I agree.  IMO, the next step should be Feature Pack installation and
> >>>>> the
> >>>>> seamless "hello world".   Then we look at EAP6.
> >>>>> _______________________________________________
> >>>>> 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  Fri Oct 31 09:10:06 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 31 Oct 2014 09:10:06 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <1950519939.4789756.1414759640083.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
	<1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
	<54538397.40706@redhat.com>
	<1950519939.4789756.1414759640083.JavaMail.zimbra@redhat.com>
Message-ID: <54538A2E.70704@redhat.com>

On 10/31/2014 8:47 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: Friday, 31 October, 2014 1:41:59 PM
>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
>>
>> On 10/31/2014 7:55 AM, Stian Thorgersen wrote:
>>>>> Stan, can we get rid of these:
>>>>>      08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service
>>>>>      thread
>>>>>      1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is
>>>>>      using
>>>>>      a private module ...
>>>> I don't think that's related to my PR.  I think you'll see those when
>>>> you deploy from the /deployments directory as well.
>>>>
>>>> The messages are for the jackson and httpcomponents modules.  I think I
>>>> can get rid of the messages if we remove the <dependencies> section from
>>>> jboss-deployment-structure.xml. Those dependencies should be added using
>>>> KeycloakDependencyProcessor instead.
>>> Yes, it's not caused by your PR (I should have clarified that), was just
>>> hoping there was some magic we could do in the subsystem to get rid of
>>> those.
>>>
>>> Removing dependencies section would brake it when deployed as WAR though.
>>> Can you modify the dependencies in the deployment-process instead?
>> It would only brake when the Keycloak subsystem is not installed. You
>> can still deploy as a WAR.  Don't we require that anyway on WildFly/EAP
>> deployments?
> How about when we deploy to AS7 and EAP6?
We have a subsystem for that.  So we would just have to require that 
it's installed.
>
>> The other thing we could do is to install our own versions of
>> httpcomponents and jackson.
> Or just put them in WEB-INF/lib? We already have a few deps in there
That would work too.  Do we use the same WAR for WildFly and Tomcat?  If 
so, then that's probably how we should handle it.
>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
>>>>>> KC subsystem
>>>>>>
>>>>>> I'd like to have a look at this before we merge it, but won't have time
>>>>>> until
>>>>>> tomorrow (maybe Friday).
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
>>>>>>> into
>>>>>>> KC
>>>>>>> subsystem
>>>>>>>
>>>>>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
>>>>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
>>>>>>>>>       * EAP6 does not yet support all this.  We should discuss whether
>>>>>>>>>       or
>>>>>>>>>         not this functionality should be backported.
>>>>>>>>>
>>>>>>>> +1 for this, but maybe some focus should be on getting a more seamless
>>>>>>>> "hello world" like we discussed in a previous thread?
>>>>>>>>
>>>>>>> I agree.  IMO, the next step should be Feature Pack installation and
>>>>>>> the
>>>>>>> seamless "hello world".   Then we look at EAP6.
>>>>>>> _______________________________________________
>>>>>>> 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  Fri Oct 31 09:17:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 09:17:51 -0400 (EDT)
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <54538A2E.70704@redhat.com>
References: <5450EB94.9090404@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
	<1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
	<54538397.40706@redhat.com>
	<1950519939.4789756.1414759640083.JavaMail.zimbra@redhat.com>
	<54538A2E.70704@redhat.com>
Message-ID: <1179290484.4809155.1414761471880.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: Friday, 31 October, 2014 2:10:06 PM
> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
> 
> On 10/31/2014 8:47 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: Friday, 31 October, 2014 1:41:59 PM
> >> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
> >> KC subsystem
> >>
> >> On 10/31/2014 7:55 AM, Stian Thorgersen wrote:
> >>>>> Stan, can we get rid of these:
> >>>>>      08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service
> >>>>>      thread
> >>>>>      1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is
> >>>>>      using
> >>>>>      a private module ...
> >>>> I don't think that's related to my PR.  I think you'll see those when
> >>>> you deploy from the /deployments directory as well.
> >>>>
> >>>> The messages are for the jackson and httpcomponents modules.  I think I
> >>>> can get rid of the messages if we remove the <dependencies> section from
> >>>> jboss-deployment-structure.xml. Those dependencies should be added using
> >>>> KeycloakDependencyProcessor instead.
> >>> Yes, it's not caused by your PR (I should have clarified that), was just
> >>> hoping there was some magic we could do in the subsystem to get rid of
> >>> those.
> >>>
> >>> Removing dependencies section would brake it when deployed as WAR though.
> >>> Can you modify the dependencies in the deployment-process instead?
> >> It would only brake when the Keycloak subsystem is not installed. You
> >> can still deploy as a WAR.  Don't we require that anyway on WildFly/EAP
> >> deployments?
> > How about when we deploy to AS7 and EAP6?
> We have a subsystem for that.  So we would just have to require that
> it's installed.
> >
> >> The other thing we could do is to install our own versions of
> >> httpcomponents and jackson.
> > Or just put them in WEB-INF/lib? We already have a few deps in there
> That would work too.  Do we use the same WAR for WildFly and Tomcat?  If
> so, then that's probably how we should handle it.

Tomcat and Jetty is more of a "should work" atm rather than something we directly support. I've got this branch, which allows deploying to Jetty and WildFly lite (should work with Tomcat as well I guess):

  https://github.com/stianst/keycloak/tree/jetty

I wonder if the best solution would be to include all required deps in the war-dist. Then in the appliance-dist we remove all jars from WEB-INF/lib and use modules instead?

> >
> >>>>> ----- Original Message -----
> >>>>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> To: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
> >>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
> >>>>>> into
> >>>>>> KC subsystem
> >>>>>>
> >>>>>> I'd like to have a look at this before we merge it, but won't have
> >>>>>> time
> >>>>>> until
> >>>>>> tomorrow (maybe Friday).
> >>>>>>
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
> >>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
> >>>>>>> into
> >>>>>>> KC
> >>>>>>> subsystem
> >>>>>>>
> >>>>>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
> >>>>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
> >>>>>>>>>       * EAP6 does not yet support all this.  We should discuss
> >>>>>>>>>       whether
> >>>>>>>>>       or
> >>>>>>>>>         not this functionality should be backported.
> >>>>>>>>>
> >>>>>>>> +1 for this, but maybe some focus should be on getting a more
> >>>>>>>> seamless
> >>>>>>>> "hello world" like we discussed in a previous thread?
> >>>>>>>>
> >>>>>>> I agree.  IMO, the next step should be Feature Pack installation and
> >>>>>>> the
> >>>>>>> seamless "hello world".   Then we look at EAP6.
> >>>>>>> _______________________________________________
> >>>>>>> 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 redsamh at gmail.com  Fri Oct 31 09:24:37 2014
From: redsamh at gmail.com (Red Samh)
Date: Fri, 31 Oct 2014 09:24:37 -0400
Subject: [keycloak-dev] Create Principal instance with username instead?
In-Reply-To: <545380BB.60906@redhat.com>
References: <5452BBE7.1000303@redhat.com>
	<2007654044.4614550.1414739483532.JavaMail.zimbra@redhat.com>
	<545380BB.60906@redhat.com>
Message-ID: <CAHh5fuzTw7Wxpa+s4dFV3w0f3e70ot1-dtHfLiejY0G-RmkToQ@mail.gmail.com>

I was going to email regarding this.

Thanks for bringing this up.  We see the guid or something where it should
be the username. Can this be configurable to use the email address?

Thanks
Sam
On Oct 31, 2014 8:29 AM, "Bill Burke" <bburke at redhat.com> wrote:

> I'll add a flag to the adapter then.  The reason is, again, pure servlet
> apps, like BRMS that display the principal name in their UI.
>
> On 10/31/2014 3:11 AM, Stian Thorgersen wrote:
> > -1
> >
> > We should stick with ID as we can guarantee that it's unique (in the
> future).
> >
> > If app starts using the username in their dbs you can end up with
> situations where the wrong user gets access to things he shouldn't. For
> example:
> >
> > * If user with username userA is removed from Keycloak, then later a new
> user is registered as userA
> > * If we support changing username in the future (this is on the
> road-map, and IMO it makes sense to add this with a toggle in the realm to
> enable/disable)
> >
> > What difference does it make if it's ugly? If apps wants to display
> details about the user they should get the profile. Sadly there's no direct
> support for this in Principal.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 30 October, 2014 11:29:59 PM
> >> Subject: [keycloak-dev] Create Principal instance with username instead?
> >>
> >> Right no UserPrincipal is created in the adapters using the user id.
> >> For strictly pure Servlet apps, an ID is pretty ugly.  I don't want to
> >> force them to use keycloak code.
> >>
> >> So...is it ok to populate the principal name with
> >> accessToken.getPreferredUsername()?
> >>
> >> --
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141031/8e3ccc50/attachment.html 

From ssilvert at redhat.com  Fri Oct 31 09:24:43 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 31 Oct 2014 09:24:43 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <1179290484.4809155.1414761471880.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<545375D4.8060905@redhat.com>
	<1862791896.4758552.1414756518293.JavaMail.zimbra@redhat.com>
	<54538397.40706@redhat.com>
	<1950519939.4789756.1414759640083.JavaMail.zimbra@redhat.com>
	<54538A2E.70704@redhat.com>
	<1179290484.4809155.1414761471880.JavaMail.zimbra@redhat.com>
Message-ID: <54538D9B.10508@redhat.com>

On 10/31/2014 9:17 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: Friday, 31 October, 2014 2:10:06 PM
>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem
>>
>> On 10/31/2014 8:47 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: Friday, 31 October, 2014 1:41:59 PM
>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into
>>>> KC subsystem
>>>>
>>>> On 10/31/2014 7:55 AM, Stian Thorgersen wrote:
>>>>>>> Stan, can we get rid of these:
>>>>>>>       08:30:02,004 WARN  [org.jboss.as.dependency.private] (MSC service
>>>>>>>       thread
>>>>>>>       1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is
>>>>>>>       using
>>>>>>>       a private module ...
>>>>>> I don't think that's related to my PR.  I think you'll see those when
>>>>>> you deploy from the /deployments directory as well.
>>>>>>
>>>>>> The messages are for the jackson and httpcomponents modules.  I think I
>>>>>> can get rid of the messages if we remove the <dependencies> section from
>>>>>> jboss-deployment-structure.xml. Those dependencies should be added using
>>>>>> KeycloakDependencyProcessor instead.
>>>>> Yes, it's not caused by your PR (I should have clarified that), was just
>>>>> hoping there was some magic we could do in the subsystem to get rid of
>>>>> those.
>>>>>
>>>>> Removing dependencies section would brake it when deployed as WAR though.
>>>>> Can you modify the dependencies in the deployment-process instead?
>>>> It would only brake when the Keycloak subsystem is not installed. You
>>>> can still deploy as a WAR.  Don't we require that anyway on WildFly/EAP
>>>> deployments?
>>> How about when we deploy to AS7 and EAP6?
>> We have a subsystem for that.  So we would just have to require that
>> it's installed.
>>>> The other thing we could do is to install our own versions of
>>>> httpcomponents and jackson.
>>> Or just put them in WEB-INF/lib? We already have a few deps in there
>> That would work too.  Do we use the same WAR for WildFly and Tomcat?  If
>> so, then that's probably how we should handle it.
> Tomcat and Jetty is more of a "should work" atm rather than something we directly support. I've got this branch, which allows deploying to Jetty and WildFly lite (should work with Tomcat as well I guess):
>
>    https://github.com/stianst/keycloak/tree/jetty
>
> I wonder if the best solution would be to include all required deps in the war-dist. Then in the appliance-dist we remove all jars from WEB-INF/lib and use modules instead?
Whatever the adapter needs must still be in modules.  Do we require the 
subsystem for all WildFly and EAP deployments?
>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Wednesday, 29 October, 2014 3:56:18 PM
>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
>>>>>>>> into
>>>>>>>> KC subsystem
>>>>>>>>
>>>>>>>> I'd like to have a look at this before we merge it, but won't have
>>>>>>>> time
>>>>>>>> until
>>>>>>>> tomorrow (maybe Friday).
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM
>>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server
>>>>>>>>> into
>>>>>>>>> KC
>>>>>>>>> subsystem
>>>>>>>>>
>>>>>>>>> On 10/29/2014 10:07 AM, Bill Burke wrote:
>>>>>>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote:
>>>>>>>>>>>        * EAP6 does not yet support all this.  We should discuss
>>>>>>>>>>>        whether
>>>>>>>>>>>        or
>>>>>>>>>>>          not this functionality should be backported.
>>>>>>>>>>>
>>>>>>>>>> +1 for this, but maybe some focus should be on getting a more
>>>>>>>>>> seamless
>>>>>>>>>> "hello world" like we discussed in a previous thread?
>>>>>>>>>>
>>>>>>>>> I agree.  IMO, the next step should be Feature Pack installation and
>>>>>>>>> the
>>>>>>>>> seamless "hello world".   Then we look at EAP6.
>>>>>>>>> _______________________________________________
>>>>>>>>> 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  Fri Oct 31 09:43:52 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 31 Oct 2014 09:43:52 -0400 (EDT)
Subject: [keycloak-dev] Added overview section to migration docs
In-Reply-To: <1773628425.4839416.1414763015962.JavaMail.zimbra@redhat.com>
Message-ID: <226827975.4839728.1414763032743.JavaMail.zimbra@redhat.com>

I added an overview section to the migration docs:

https://github.com/keycloak/keycloak/commit/c43040a08e78fe78b0620da9c49740ac0ee6e6df

From bburke at redhat.com  Fri Oct 31 11:42:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 31 Oct 2014 11:42:24 -0400
Subject: [keycloak-dev] Create Principal instance with username instead?
In-Reply-To: <CAHh5fuzTw7Wxpa+s4dFV3w0f3e70ot1-dtHfLiejY0G-RmkToQ@mail.gmail.com>
References: <5452BBE7.1000303@redhat.com>	<2007654044.4614550.1414739483532.JavaMail.zimbra@redhat.com>	<545380BB.60906@redhat.com>
	<CAHh5fuzTw7Wxpa+s4dFV3w0f3e70ot1-dtHfLiejY0G-RmkToQ@mail.gmail.com>
Message-ID: <5453ADE0.3030405@redhat.com>

For the principal name right?  Yeah, I can make it configurable.

On 10/31/2014 9:24 AM, Red Samh wrote:
>
> I was going to email regarding this.
>
> Thanks for bringing this up.  We see the guid or something where it
> should be the username. Can this be configurable to use the email address?
>
> Thanks
> Sam
>
> On Oct 31, 2014 8:29 AM, "Bill Burke" <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     I'll add a flag to the adapter then.  The reason is, again, pure servlet
>     apps, like BRMS that display the principal name in their UI.
>
>     On 10/31/2014 3:11 AM, Stian Thorgersen wrote:
>      > -1
>      >
>      > We should stick with ID as we can guarantee that it's unique (in
>     the future).
>      >
>      > If app starts using the username in their dbs you can end up with
>     situations where the wrong user gets access to things he shouldn't.
>     For example:
>      >
>      > * If user with username userA is removed from Keycloak, then
>     later a new user is registered as userA
>      > * If we support changing username in the future (this is on the
>     road-map, and IMO it makes sense to add this with a toggle in the
>     realm to enable/disable)
>      >
>      > What difference does it make if it's ugly? If apps wants to
>     display details about the user they should get the profile. Sadly
>     there's no direct support for this in Principal.
>      >
>      > ----- Original Message -----
>      >> From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>      >> To: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>      >> Sent: Thursday, 30 October, 2014 11:29:59 PM
>      >> Subject: [keycloak-dev] Create Principal instance with username
>     instead?
>      >>
>      >> Right no UserPrincipal is created in the adapters using the user id.
>      >> For strictly pure Servlet apps, an ID is pretty ugly.  I don't
>     want to
>      >> force them to use keycloak code.
>      >>
>      >> So...is it ok to populate the principal name with
>      >> accessToken.getPreferredUsername()?
>      >>
>      >> --
>      >> Bill Burke
>      >> JBoss, a division of Red Hat
>      >> http://bill.burkecentral.com
>      >> _______________________________________________
>      >> keycloak-dev mailing list
>      >> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>      >>
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Fri Oct 31 14:42:34 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 31 Oct 2014 14:42:34 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
References: <5450EB94.9090404@redhat.com> <5450F4BE.4030801@redhat.com>
	<5450F8F3.7020301@redhat.com>
	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>
	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
Message-ID: <5453D81A.4000408@redhat.com>

On 10/31/2014 4:15 AM, Stian Thorgersen wrote:
> Looks good to me. We should include this in Beta1.
>
> A few comments/questions:
>
> * Can we support enabling confidential transport-guarantee (auth-server/WEB-INF/web.xml) without cracking open the WAR? This seems to be the last requirement for an exploded WAR
Looking this over, it seems pretty important!  I think I'd like to go 
ahead and implement this option before we merge.  I should be able to do 
that and also finish the doc updates by the middle of next week.  Just 
go ahead and release the Beta if you want.  I can catch the next release 
train.

I plan to implement this as a boolean value on on the server called 
"https-required".   Is there a better name for it?
<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
             <auth-server name="foo">
                 <enabled>true</enabled>
                 <web-context>auth</web-context>
                 <https-required>true</https-required>
             </auth-server>
</subsystem>

Should the default be false?  I realize that the default in the 
appliance dist is false, but should the default always be false?

If true, this will be automatically added to auth-server.war at deploy time:

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



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

From bburke at redhat.com  Fri Oct 31 15:09:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 31 Oct 2014 15:09:31 -0400
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <5453D81A.4000408@redhat.com>
References: <5450EB94.9090404@redhat.com>
	<5450F4BE.4030801@redhat.com>	<5450F8F3.7020301@redhat.com>	<1127902957.2760201.1414594578492.JavaMail.zimbra@redhat.com>	<862337823.4657452.1414743322139.JavaMail.zimbra@redhat.com>
	<5453D81A.4000408@redhat.com>
Message-ID: <5453DE6B.5030709@redhat.com>

How about confidential-transport-guarantee


On 10/31/2014 2:42 PM, Stan Silvert wrote:
> On 10/31/2014 4:15 AM, Stian Thorgersen wrote:
>> Looks good to me. We should include this in Beta1.
>>
>> A few comments/questions:
>>
>> * Can we support enabling confidential transport-guarantee (auth-server/WEB-INF/web.xml) without cracking open the WAR? This seems to be the last requirement for an exploded WAR
> Looking this over, it seems pretty important!  I think I'd like to go
> ahead and implement this option before we merge.  I should be able to do
> that and also finish the doc updates by the middle of next week.  Just
> go ahead and release the Beta if you want.  I can catch the next release
> train.
>
> I plan to implement this as a boolean value on on the server called
> "https-required".   Is there a better name for it?
> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>              <auth-server name="foo">
>                  <enabled>true</enabled>
>                  <web-context>auth</web-context>
>                  <https-required>true</https-required>
>              </auth-server>
> </subsystem>
>
> Should the default be false?  I realize that the default in the
> appliance dist is false, but should the default always be false?
>
> If true, this will be automatically added to auth-server.war at deploy time:
>
> <security-constraint>
>     <web-resource-collection>
>        <url-pattern>/*</url-pattern>
>     </web-resource-collection>
>     <user-data-constraint>
>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>     </user-data-constraint>
> </security-constraint>
>
>
>
>
>
> _______________________________________________
> 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 Oct 31 16:51:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 31 Oct 2014 16:51:07 -0400
Subject: [keycloak-dev] KC Auth Server Subsystem questions
Message-ID: <5453F63B.8040703@redhat.com>

* What are the benefits of it.  Specifically.  I'll need to state this 
in the release blog.

* Where is the documentation for it?  Benefits, how to configure, 
manage?  How to add new providers?  Modify keycloak-server.json, etc...

This can't be released or brought into the appliance until it is 
documented thoroughly.




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

From mposolda at redhat.com  Fri Oct 31 17:33:25 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 31 Oct 2014 22:33:25 +0100
Subject: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC
 subsystem
In-Reply-To: <5450EB94.9090404@redhat.com>
References: <5450EB94.9090404@redhat.com>
Message-ID: <54540025.4060908@redhat.com>

Hi Stan,

did you already tried to test with more auth-servers per Wildfly 
instance? I am seeing some potential issue in the fact that some stuff 
is static (at least KeycloakApplication.loadConfig() is static method 
and configProvider field in org.keycloak.Config is static too). It looks 
that this might need some refactoring (unless we want to share the same 
config among all auth-servers, which seems as bad solution to me)

I did not try myself yet to test with more auth-servers, just raising 
potential issue;-)

Marek

On 29.10.2014 14:28, Stan Silvert wrote:
> I've sent a PR for this:
> https://github.com/keycloak/keycloak/pull/811
>
> It's a pretty big change in the way the Auth Server is started when 
> the KeyCloak subsystem is used.  The WAR is no longer dropped into the 
> standalone/deployments directory.   This is especially helpful for 
> domain deployments, but it makes standalone cleaner as well.  It will 
> also be important for Feature Pack installation.
>
> The main difference you will see right away with this PR is that the 
> appliance dist now uses the subsystem to launch the Auth Server.
>
> Here are some notes about how everything turned out.  Next, I'll 
> update the documentation if there is no major rework that needs to be 
> done after the PR is reviewed.
>
>   * The WAR for the auth server now lives in
>     modules/.../keycloak-wildfly-subsystem/main/auth-server.  By
>     default, it is unexploded.  If you want it to be exploded you can
>     unzip it into that same directory and set the
>     "auth-server-exploded" property in module.xml.
>   * A new Auth Server is declared in standalone.xml/domain.xml. You
>     can have more than one Auth Server in the same WildFly instance.
>   * <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>                 <auth-server name="main-auth-server">
>                     <enabled>true</enabled>
>                     <web-context>auth</web-context>
>                 </auth-server>
>
>   * The "enabled" attribute can be toggled at runtime to make the auth
>     server undeploy/redeploy.
>   * If you have more than one auth-server, the web-context must be unique.
>   * In a domain environment, all specified Auth Server deployments are
>     propagated to all servers using that profile. The same is true for
>     overlays uploaded through the new CLI operations.
>   * There are two new CLI operations that act on an auth-server.  They
>     are "add-provider" and "update-server-config".  Currently, you can
>     only execute these operations in the latest version of CLI GUI.  
>     We should discuss if we need to add support in plain CLI.  The
>     long term goal would be to add this functionality to the Keycloak
>     Admin Console.
>   * "add-provider" adds a provider jar to an auth-server
>   * "update-server-config" overlays the keycloak-server.json for an
>     auth-server.
>   * If a keycloak-server.json file is found in
>     standalone/configuration directory, all auth-server instances will
>     still use it regardless of any update-server-config operations.
>   * EAP6 does not yet support all this.  We should discuss whether or
>     not this functionality should be backported.
>
>
>
> _______________________________________________
> 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/20141031/7786fb37/attachment.html