From bruno at abstractj.org  Tue Mar  1 15:25:05 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 01 Mar 2016 20:25:05 +0000
Subject: [keycloak-dev] Blacklisting/document broken protocols
Message-ID: <CAM5SUC448G1jUun6Loh5v60tw=E6bBQRHGZyrmZ1pCUABGdesA@mail.gmail.com>

Ahoy, today I was reading about this "new" vulnerability on TLS (
http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html).
And was wondering if we should blacklist or document broken protocols.
Preventing people to deploy Keycloak in non secure environments.

Something like was already suggested for Poodle here:
http://www.oracle.com/technetwork/java/javase/documentation/cve-2014-3566-2342133.html

Snippet:


SSLSocket sslSocket = sslSocketFactory.createSocket(...);

        // Strip "SSLv3" from the current enabled protocols.
        String[] protocols = sslSocket.getEnabledProtocols();
        Set<String> set = new HashSet<>();
        for (String s : protocols) {
             if (s.equals("SSLv3") || s.equals("SSLv2Hello")) {
                continue;
            }
            set.add(s);
        }
        sslSocket.setEnabledProtocols(set.toArray(new String[0]));


Should we document? Blacklist? Or leave it as is?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160301/7c18f2ca/attachment.html 

From jpkroehling at redhat.com  Wed Mar  2 03:34:19 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 2 Mar 2016 09:34:19 +0100
Subject: [keycloak-dev] Blacklisting/document broken protocols
In-Reply-To: <CAM5SUC448G1jUun6Loh5v60tw=E6bBQRHGZyrmZ1pCUABGdesA@mail.gmail.com>
References: <CAM5SUC448G1jUun6Loh5v60tw=E6bBQRHGZyrmZ1pCUABGdesA@mail.gmail.com>
Message-ID: <56D6A58B.5000203@redhat.com>

On 01.03.2016 21:25, Bruno Oliveira wrote:
>
> Ahoy, today I was reading about this "new" vulnerability on TLS
> (http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html).
> And was wondering if we should blacklist or document broken protocols.
> Preventing people to deploy Keycloak in non secure environments.
>
...
>
> Should we document? Blacklist? Or leave it as is?

I'd say "do nothing". Good system admins already have something in place 
that would alert them in those cases, ranging from monitoring 
vulnerabilities databases to scripting the score check via ssllabs.com.

The main problem that I see with adding some sort of support like this 
directly into Keycloak is that you'd need a lot of effort to keep it up 
to date. If a comprehensive check cannot be done, people would either 
ignore it, or people will trust it because of the false sense of 
security it gives.

- Juca.


From sthorger at redhat.com  Wed Mar  2 03:45:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Mar 2016 09:45:57 +0100
Subject: [keycloak-dev] Blacklisting/document broken protocols
In-Reply-To: <56D6A58B.5000203@redhat.com>
References: <CAM5SUC448G1jUun6Loh5v60tw=E6bBQRHGZyrmZ1pCUABGdesA@mail.gmail.com>
	<56D6A58B.5000203@redhat.com>
Message-ID: <CAJgngAeU1qedvswh-s9HTwGCSq0qQhh+RLrkaKMO_RU2=Z7D4A@mail.gmail.com>

+1 To do nothing

SSL for KC itself is provided by WildFly, so this is WildFly/Undertow's
responsibility. For outgoing SSL connections (db, ldap, etc..) it's up to
the admin to configure those resources correctly.

On 2 March 2016 at 09:34, Juraci Paix?o Kr?hling <jpkroehling at redhat.com>
wrote:

> On 01.03.2016 21:25, Bruno Oliveira wrote:
> >
> > Ahoy, today I was reading about this "new" vulnerability on TLS
> > (
> http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html
> ).
> > And was wondering if we should blacklist or document broken protocols.
> > Preventing people to deploy Keycloak in non secure environments.
> >
> ...
> >
> > Should we document? Blacklist? Or leave it as is?
>
> I'd say "do nothing". Good system admins already have something in place
> that would alert them in those cases, ranging from monitoring
> vulnerabilities databases to scripting the score check via ssllabs.com.
>
> The main problem that I see with adding some sort of support like this
> directly into Keycloak is that you'd need a lot of effort to keep it up
> to date. If a comprehensive check cannot be done, people would either
> ignore it, or people will trust it because of the false sense of
> security it gives.
>
> - Juca.
>
> _______________________________________________
> 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/20160302/6d0d99e0/attachment.html 

From michal.drela at gmail.com  Wed Mar  2 04:07:20 2016
From: michal.drela at gmail.com (=?UTF-8?Q?Micha=C5=82_Drela?=)
Date: Wed, 2 Mar 2016 10:07:20 +0100
Subject: [keycloak-dev] functionality: Prevent simultaneously user logging.
Message-ID: <CAG-D=4z-us+Dr-3n3nHsUW9=ZqLiih1p7RNrT-f_ULifHyRAoA@mail.gmail.com>

Hi,

Is there planned or perhaps someone is already working on preventing users
from concurrent/simultaneously logging ?


Best Regards,

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

From bruno at abstractj.org  Wed Mar  2 04:18:31 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 02 Mar 2016 09:18:31 +0000
Subject: [keycloak-dev] Blacklisting/document broken protocols
In-Reply-To: <CAJgngAeU1qedvswh-s9HTwGCSq0qQhh+RLrkaKMO_RU2=Z7D4A@mail.gmail.com>
References: <CAM5SUC448G1jUun6Loh5v60tw=E6bBQRHGZyrmZ1pCUABGdesA@mail.gmail.com>
	<56D6A58B.5000203@redhat.com>
	<CAJgngAeU1qedvswh-s9HTwGCSq0qQhh+RLrkaKMO_RU2=Z7D4A@mail.gmail.com>
Message-ID: <CAM5SUC65BUgzWmjRz-JAoikb-Ekv49Zi3bh=X4QpkuYwqxMytQ@mail.gmail.com>

+1 Makes sense

On Wed, Mar 2, 2016, 5:46 AM Stian Thorgersen <sthorger at redhat.com> wrote:

> +1 To do nothing
>
> SSL for KC itself is provided by WildFly, so this is WildFly/Undertow's
> responsibility. For outgoing SSL connections (db, ldap, etc..) it's up to
> the admin to configure those resources correctly.
>
> On 2 March 2016 at 09:34, Juraci Paix?o Kr?hling <jpkroehling at redhat.com>
> wrote:
>
>> On 01.03.2016 21:25, Bruno Oliveira wrote:
>> >
>> > Ahoy, today I was reading about this "new" vulnerability on TLS
>> > (
>> http://blog.cryptographyengineering.com/2016/03/attack-of-week-drown.html
>> ).
>> > And was wondering if we should blacklist or document broken protocols.
>> > Preventing people to deploy Keycloak in non secure environments.
>> >
>> ...
>> >
>> > Should we document? Blacklist? Or leave it as is?
>>
>> I'd say "do nothing". Good system admins already have something in place
>> that would alert them in those cases, ranging from monitoring
>> vulnerabilities databases to scripting the score check via ssllabs.com.
>>
>> The main problem that I see with adding some sort of support like this
>> directly into Keycloak is that you'd need a lot of effort to keep it up
>> to date. If a comprehensive check cannot be done, people would either
>> ignore it, or people will trust it because of the false sense of
>> security it gives.
>>
>> - Juca.
>>
>> _______________________________________________
>> 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/20160302/4fd9ccb8/attachment.html 

From sthorger at redhat.com  Wed Mar  2 05:02:38 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Mar 2016 11:02:38 +0100
Subject: [keycloak-dev] functionality: Prevent simultaneously user
	logging.
In-Reply-To: <CAG-D=4z-us+Dr-3n3nHsUW9=ZqLiih1p7RNrT-f_ULifHyRAoA@mail.gmail.com>
References: <CAG-D=4z-us+Dr-3n3nHsUW9=ZqLiih1p7RNrT-f_ULifHyRAoA@mail.gmail.com>
Message-ID: <CAJgngAdNqBpCC0QDCC+D31eoThhtqGQDTMM6qfX_hx_W+tbHRA@mail.gmail.com>

This is not a feature we've considered  adding. However, it can be done
with a custom authenticator.
On 2 Mar 2016 10:07, "Micha? Drela" <michal.drela at gmail.com> wrote:

>
> Hi,
>
> Is there planned or perhaps someone is already working on preventing users
> from concurrent/simultaneously logging ?
>
>
> Best Regards,
>
> Michal.
>
> _______________________________________________
> 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/20160302/297c402f/attachment-0001.html 

From jm85martins at gmail.com  Wed Mar  2 05:30:46 2016
From: jm85martins at gmail.com (Jorge M.)
Date: Wed, 2 Mar 2016 10:30:46 +0000
Subject: [keycloak-dev] Custom locales
Message-ID: <CAHEpHRJ-sev7iH=Xr=zj_99JjH_0qnx-jiH92+arV-a5+1W_1g@mail.gmail.com>

Hi,

I'm not being able to add custom locales in version 1.9.0.final.
In previous versions I used to add custom locales files under
base/login/messages folder. This behavior has changed in the new version ?
I can see that there is an issue related with that for this version
https://issues.jboss.org/browse/KEYCLOAK-2237 but I'm not getting there.
Any help?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160302/fd768a5d/attachment.html 

From sthorger at redhat.com  Wed Mar  2 06:54:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 2 Mar 2016 12:54:49 +0100
Subject: [keycloak-dev] Custom locales
In-Reply-To: <CAHEpHRJ-sev7iH=Xr=zj_99JjH_0qnx-jiH92+arV-a5+1W_1g@mail.gmail.com>
References: <CAHEpHRJ-sev7iH=Xr=zj_99JjH_0qnx-jiH92+arV-a5+1W_1g@mail.gmail.com>
Message-ID: <CAJgngAe7GgvwCttzRUTYN-QwbVr+_HNc5-sOuJj0pq4WMcnoRg@mail.gmail.com>

To add a custom local in 1.9.0 you need to create a custom theme that adds
the custom locale, in theme.properties you should set what locale are
supported by the theme. You also need to add a key for the locale itself in
messages_en.properties (like so
https://github.com/keycloak/keycloak/pull/2099/files#diff-212b66440fb033927a3a24caf41983c9R151
).

On 2 March 2016 at 11:30, Jorge M. <jm85martins at gmail.com> wrote:

> Hi,
>
> I'm not being able to add custom locales in version 1.9.0.final.
> In previous versions I used to add custom locales files under
> base/login/messages folder. This behavior has changed in the new version ?
> I can see that there is an issue related with that for this version
> https://issues.jboss.org/browse/KEYCLOAK-2237 but I'm not getting there.
> Any help?
>
> Thank you
>
> _______________________________________________
> 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/20160302/783d18a8/attachment.html 

From jm85martins at gmail.com  Wed Mar  2 08:40:07 2016
From: jm85martins at gmail.com (Jorge M.)
Date: Wed, 2 Mar 2016 13:40:07 +0000
Subject: [keycloak-dev] Custom locales
In-Reply-To: <CAJgngAe7GgvwCttzRUTYN-QwbVr+_HNc5-sOuJj0pq4WMcnoRg@mail.gmail.com>
References: <CAHEpHRJ-sev7iH=Xr=zj_99JjH_0qnx-jiH92+arV-a5+1W_1g@mail.gmail.com>
	<CAJgngAe7GgvwCttzRUTYN-QwbVr+_HNc5-sOuJj0pq4WMcnoRg@mail.gmail.com>
Message-ID: <CAHEpHR+tE8T=PzkEx1U5xe9kemL-7Nt=Dedv6p-9nH-075sTuA@mail.gmail.com>

Hi,

I already did that but the locale is not listed. Any idea?
As my theme extends the base theme, I just to need to add the new locale
file under base/login/messages right? And update the themes.properties of
the base and my theme.

Thank you.

2016-03-02 11:54 GMT+00:00 Stian Thorgersen <sthorger at redhat.com>:

> To add a custom local in 1.9.0 you need to create a custom theme that adds
> the custom locale, in theme.properties you should set what locale are
> supported by the theme. You also need to add a key for the locale itself in
> messages_en.properties (like so
> https://github.com/keycloak/keycloak/pull/2099/files#diff-212b66440fb033927a3a24caf41983c9R151
> ).
>
> On 2 March 2016 at 11:30, Jorge M. <jm85martins at gmail.com> wrote:
>
>> Hi,
>>
>> I'm not being able to add custom locales in version 1.9.0.final.
>> In previous versions I used to add custom locales files under
>> base/login/messages folder. This behavior has changed in the new version ?
>> I can see that there is an issue related with that for this version
>> https://issues.jboss.org/browse/KEYCLOAK-2237 but I'm not getting there.
>> Any help?
>>
>> Thank you
>>
>> _______________________________________________
>> 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/20160302/b5730355/attachment.html 

From bburke at redhat.com  Wed Mar  2 10:09:27 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Mar 2016 10:09:27 -0500
Subject: [keycloak-dev] functionality: Prevent simultaneously user
 logging.
In-Reply-To: <CAJgngAdNqBpCC0QDCC+D31eoThhtqGQDTMM6qfX_hx_W+tbHRA@mail.gmail.com>
References: <CAG-D=4z-us+Dr-3n3nHsUW9=ZqLiih1p7RNrT-f_ULifHyRAoA@mail.gmail.com>
	<CAJgngAdNqBpCC0QDCC+D31eoThhtqGQDTMM6qfX_hx_W+tbHRA@mail.gmail.com>
Message-ID: <56D70227.3030707@redhat.com>

What do you mean by concurrent/simultaneous?  What are you trying to 
accomplish/prevent?  Trying to enforce one session per user?

This wouldn't be hard to implement, but we are in feature freeze so 
you'd have to implement it yourself through our Auth SPI.

On 3/2/2016 5:02 AM, Stian Thorgersen wrote:
>
> This is not a feature we've considered  adding. However, it can be 
> done with a custom authenticator.
>
> On 2 Mar 2016 10:07, "Micha? Drela" <michal.drela at gmail.com 
> <mailto:michal.drela at gmail.com>> wrote:
>
>
>     Hi,
>
>     Is there planned or perhaps someone is already working on
>     preventing users from concurrent/simultaneously logging ?
>
>
>     Best Regards,
>
>     Michal.
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Thu Mar  3 01:03:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 3 Mar 2016 07:03:08 +0100
Subject: [keycloak-dev] Message bundles and translations
Message-ID: <CAJgngAeQA8OkDcU3r-LnanrW5YYT3nT7EXJNviW9gs7eQdEQfQ@mail.gmail.com>

The German admin console message bundle contained the English translations
prefixed with 'de'. There was also a number of English translations found
in other message bundles (for example German email message bundle).

Do NOT add keys in a bundle unless it's the proper translation. It will
fallback to using the English bundle if a key is not found.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/4da76dab/attachment.html 

From michal.drela at gmail.com  Thu Mar  3 03:52:24 2016
From: michal.drela at gmail.com (=?UTF-8?Q?Micha=C5=82_Drela?=)
Date: Thu, 3 Mar 2016 09:52:24 +0100
Subject: [keycloak-dev] functionality: Prevent simultaneously user
	logging.
In-Reply-To: <56D70227.3030707@redhat.com>
References: <CAG-D=4z-us+Dr-3n3nHsUW9=ZqLiih1p7RNrT-f_ULifHyRAoA@mail.gmail.com>
	<CAJgngAdNqBpCC0QDCC+D31eoThhtqGQDTMM6qfX_hx_W+tbHRA@mail.gmail.com>
	<56D70227.3030707@redhat.com>
Message-ID: <CAG-D=4wJqhOMrcwtibtexHXKV28VuzxCCrugnRURDdoiKrnS=w@mail.gmail.com>

Yes exactly, I want to enforce one session per user. I'm already
familiarized with the Auth SPI.. Thanks for information.
I just wanted to ensure if such functionality is planned or not planned to
be released in the nearest future.

Best Regards.
Michal.

2016-03-02 16:09 GMT+01:00 Bill Burke <bburke at redhat.com>:

> What do you mean by concurrent/simultaneous?  What are you trying to
> accomplish/prevent?  Trying to enforce one session per user?
>
> This wouldn't be hard to implement, but we are in feature freeze so you'd
> have to implement it yourself through our Auth SPI.
>
>
> On 3/2/2016 5:02 AM, Stian Thorgersen wrote:
>
> This is not a feature we've considered  adding. However, it can be done
> with a custom authenticator.
> On 2 Mar 2016 10:07, "Micha? Drela" < <michal.drela at gmail.com>
> michal.drela at gmail.com> wrote:
>
>>
>> Hi,
>>
>> Is there planned or perhaps someone is already working on preventing
>> users from concurrent/simultaneously logging ?
>>
>>
>> Best Regards,
>>
>> Michal.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Pozdrawiam,

Micha? Drela
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/3ec0f2c4/attachment-0001.html 

From bruno at abstractj.org  Thu Mar  3 07:10:47 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 03 Mar 2016 12:10:47 +0000
Subject: [keycloak-dev] Brute force flow
Message-ID: <CAM5SUC5eBBGcA=iCd2rp63mpn3uruGwJO6MAQ8JUP745Va5jdA@mail.gmail.com>

Good morning, today I was thinking about our brute force flow and was
wondering if we could change it.

I know it's not our job to be a firewall or IDS. At the same time, our
current flow today make passwords guessable for attackers. A successful
login attempt is clearly distinguishable based on the error response.

TL;DR if a password is invalid we get "Invalid username and password", but
if it's valid we get "Account is temporarily disabled, contact admin or try
again later.". Which pretty much means that an attacker could complete the
attack from another machine or later, because now she knows that such
account exists and it's valid.

What I would like to suggest, it's just to remove the error message for
account disabled. This information is relevant for the Keycloak
administrator, but I don't think it's necessary for the final user. People
will contact the admin anyways.

Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/d8572d82/attachment.html 

From sthorger at redhat.com  Thu Mar  3 07:19:05 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 3 Mar 2016 13:19:05 +0100
Subject: [keycloak-dev] Brute force flow
In-Reply-To: <CAM5SUC5eBBGcA=iCd2rp63mpn3uruGwJO6MAQ8JUP745Va5jdA@mail.gmail.com>
References: <CAM5SUC5eBBGcA=iCd2rp63mpn3uruGwJO6MAQ8JUP745Va5jdA@mail.gmail.com>
Message-ID: <CAJgngAdNCVAfBs0aPXDdRokE9+tezmfd+DE52Dre=eFUsNs_bg@mail.gmail.com>

+1

On 3 March 2016 at 13:10, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, today I was thinking about our brute force flow and was
> wondering if we could change it.
>
> I know it's not our job to be a firewall or IDS. At the same time, our
> current flow today make passwords guessable for attackers. A successful
> login attempt is clearly distinguishable based on the error response.
>
> TL;DR if a password is invalid we get "Invalid username and password", but
> if it's valid we get "Account is temporarily disabled, contact admin or try
> again later.". Which pretty much means that an attacker could complete the
> attack from another machine or later, because now she knows that such
> account exists and it's valid.
>
> What I would like to suggest, it's just to remove the error message for
> account disabled. This information is relevant for the Keycloak
> administrator, but I don't think it's necessary for the final user. People
> will contact the admin anyways.
>
> Thoughts?
>
> _______________________________________________
> 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/20160303/5b676579/attachment.html 

From sthorger at redhat.com  Thu Mar  3 14:09:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 3 Mar 2016 20:09:11 +0100
Subject: [keycloak-dev] Thoughts on improving the model for 2.x
Message-ID: <CAJgngAeD3uZOSmerzn-3wHVBhuiCz6ir4T3AAeYA2jk6-TzPYg@mail.gmail.com>

I've written up some thoughts on improving the model for 2.x at
https://docs.google.com/a/redhat.com/document/d/1ZmPjlJYvk_fwYvnWxz1E49ioZFZa3kfYCI1xE5gVClc/pub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/26e98dfd/attachment.html 

From sthorger at redhat.com  Thu Mar  3 14:21:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 3 Mar 2016 20:21:45 +0100
Subject: [keycloak-dev] Commercial support
Message-ID: <CAJgngAc8P9HMXaWmJg_V-chqvm=tvtO667dKYTGmV7N18bD4LA@mail.gmail.com>

We're very pleased to announce that Red Hat is working on a commercially
supported version of Keycloak. At the moment we can't give any details
around product name, release date or subscription model. What we can tell
you is that the supported version will be based on Keycloak 1.9.x.
Rather than working on new features we're currently focusing on
performance, bug fixes and general polishing. We will be releasing minor
releases of 1.9.x every few weeks going forward. This means that we highly
recommend you upgrade to 1.9.x now. It will get continuous fixes, including
security fixes, until the commercially supported version is ready. Going
forwards we'll also be very unlikely to answer questions or help with
problems unless you've upgraded to 1.9.x. We'd also appreciate all the
review and feedback we can get on this release. We want to make it as good
as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/0209dc37/attachment.html 

From bburke at redhat.com  Thu Mar  3 20:45:47 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Mar 2016 20:45:47 -0500
Subject: [keycloak-dev] Thoughts on improving the model for 2.x
In-Reply-To: <CAJgngAeD3uZOSmerzn-3wHVBhuiCz6ir4T3AAeYA2jk6-TzPYg@mail.gmail.com>
References: <CAJgngAeD3uZOSmerzn-3wHVBhuiCz6ir4T3AAeYA2jk6-TzPYg@mail.gmail.com>
Message-ID: <56D8E8CB.5020605@redhat.com>

Some additional thoughts:
* All user and realm metadata (group, roles, etc..) needs to be 
referenced by a URI.  URI would have a schema like this: 
{provider}:{identifier}.  Identifier can be anything.  A keycloak 
datastore would just be a primary key id, for LDAP it might be the 
username, rolename, group name.  You get the picture.  Then a manager 
service ould be used to resolve the URI into an actual Model interface.  
User reference URIs could point to a broker (social or parent IDP),an 
LDAP store, local keycloak db, etc.
* For social login and brokering you would assign a user storage 
mechanism to import the user into.  We would have 3 possible built-in 
options, JPA or Mongo, and Infinispan clustered in-memory cache.

On 3/3/2016 2:09 PM, Stian Thorgersen wrote:
> I've written up some thoughts on improving the model for 2.x at 
> https://docs.google.com/a/redhat.com/document/d/1ZmPjlJYvk_fwYvnWxz1E49ioZFZa3kfYCI1xE5gVClc/pub 
>
>
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160303/96d15b0b/attachment.html 

From sthorger at redhat.com  Fri Mar  4 02:50:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 4 Mar 2016 08:50:35 +0100
Subject: [keycloak-dev] Thoughts on improving the model for 2.x
In-Reply-To: <56D8E8CB.5020605@redhat.com>
References: <CAJgngAeD3uZOSmerzn-3wHVBhuiCz6ir4T3AAeYA2jk6-TzPYg@mail.gmail.com>
	<56D8E8CB.5020605@redhat.com>
Message-ID: <CAJgngAeB34T9C3VsNgfiU4ECN4NZcTg2Kj377Eo-xJpGDnKrrQ@mail.gmail.com>

Added to the doc

On 4 March 2016 at 02:45, Bill Burke <bburke at redhat.com> wrote:

> Some additional thoughts:
> * All user and realm metadata (group, roles, etc..) needs to be referenced
> by a URI.  URI would have a schema like this:  {provider}:{identifier}.
> Identifier can be anything.  A keycloak datastore would just be a primary
> key id, for LDAP it might be the username, rolename, group name.  You get
> the picture.  Then a manager service ould be used to resolve the URI into
> an actual Model interface.  User reference URIs could point to a broker
> (social or parent IDP),an LDAP store, local keycloak db, etc.
> * For social login and brokering you would assign a user storage mechanism
> to import the user into.  We would have 3 possible built-in options, JPA or
> Mongo, and Infinispan clustered in-memory cache.
>
> On 3/3/2016 2:09 PM, Stian Thorgersen wrote:
>
> I've written up some thoughts on improving the model for 2.x at
> https://docs.google.com/a/redhat.com/document/d/1ZmPjlJYvk_fwYvnWxz1E49ioZFZa3kfYCI1xE5gVClc/pub
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160304/8dc9b527/attachment-0001.html 

From sthorger at redhat.com  Fri Mar  4 07:15:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 4 Mar 2016 13:15:30 +0100
Subject: [keycloak-dev] Supporting sticky sessions
Message-ID: <CAJgngAfaG-UiKhCQpDBBmhxB62rTMuzS2kJGLVvwdWU-yDvRNw@mail.gmail.com>

Eventually it would be nice to support the ability for load balancers to
send all requests for a particular user session to the same node (browser
as well as client requests).

More details here: https://issues.jboss.org/browse/KEYCLOAK-2352

Is this a high priority for 1.9 or should it be 2.x? We may be able to put
it into 1.9.2 if required.

I'd like feedback on how useful folks think it would be as well as feedback
on the proposed implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160304/45274791/attachment.html 

From bburke at redhat.com  Fri Mar  4 10:32:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 4 Mar 2016 10:32:52 -0500
Subject: [keycloak-dev] arquillian tests failing
Message-ID: <56D9AAA4.3050807@redhat.com>

I don't think its my changes.  It runs fine in the IDE, but not from 
maven command line:

Caused by: java.lang.RuntimeException: Provider for type class 
java.net.URL returned a null value: 
org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
         at 
org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
         at 
org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
         at 
org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
         at 
org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
         at 
org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
         at 
org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
         at 
org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
         at 
org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)

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


From bburke at redhat.com  Fri Mar  4 11:08:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 4 Mar 2016 11:08:56 -0500
Subject: [keycloak-dev] arquillian tests failing
In-Reply-To: <56D9AAA4.3050807@redhat.com>
References: <56D9AAA4.3050807@redhat.com>
Message-ID: <56D9B318.9080001@redhat.com>

Yeah, something weird is going on.  This passes travis build.

On 3/4/2016 10:32 AM, Bill Burke wrote:
> I don't think its my changes.  It runs fine in the IDE, but not from
> maven command line:
>
> Caused by: java.lang.RuntimeException: Provider for type class
> java.net.URL returned a null value:
> org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
>           at
> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
>           at
> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
>           at
> org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
>           at
> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
>           at
> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
>           at
> org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
>           at
> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
>           at
> org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
>

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


From ayoung at redhat.com  Fri Mar  4 21:49:54 2016
From: ayoung at redhat.com (Adam Young)
Date: Fri, 4 Mar 2016 21:49:54 -0500
Subject: [keycloak-dev] Setting up AJP proxy from Apache?
Message-ID: <56DA4952.8050004@redhat.com>

keycloak-1.9.0.Final

Having trouble finding the right notes for setting up AJP.  This is to 
run alongside a FreeIPA server which is already set up with 
mod_proxy_ajp talking to Tomcat, so I want to keep using the same set of 
modules.



I can see keycloak-1.9.0.Final/standalone/configuration/standalone.xml


<subsystem xmlns="urn:jboss:domain:undertow:3.0">
             <buffer-cache name="default"/>
             <server name="default-server">
                 <http-listener name="default" socket-binding="http" 
redirect-socket="https"/>

                 <host name="default-host" alias="localhost">
                     <location name="/" handler="welcome-content"/>
                     <filter-ref name="server-header"/>
                     <filter-ref name="x-powered-by-header"/>
                 </host>
             </server>


I'm assuming I need a line comparable to <http-listener name="default" 
socket-binding="http" redirect-socket="https"/> But for the AJP 
protocol. Perhaps ajp-listener?

A line like this, perhaps?

      <http-listener name="default-ajp" socket-binding="ajp" 
scheme="http"  />






https://docs.jboss.org/author/display/WFLY8/AJP+listeners

I see at the bottom of the file:

     <socket-binding-group name="standard-sockets" 
default-interface="public" 
port-offset="${jboss.socket.binding.port-offset:0}">
         <socket-binding name="management-http" interface="management" 
port="${jboss.management.http.port:9990}"/>
         <socket-binding name="management-https" interface="management" 
port="${jboss.management.https.port:9993}"/>
         <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>


From bburke at redhat.com  Sat Mar  5 07:27:37 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 5 Mar 2016 07:27:37 -0500
Subject: [keycloak-dev] Setting up AJP proxy from Apache?
In-Reply-To: <56DA4952.8050004@redhat.com>
References: <56DA4952.8050004@redhat.com>
Message-ID: <56DAD0B9.3030701@redhat.com>

The only thing I can think of is that the server is binding to localhost 
and not a real IP address?

BTW, why would you want to put Apache in front of Keycloak?  Or is this 
just an application?  Last time I looked at bench, undertow/wildfly 
performs and scales better than Apache HTTPD even for static content.

https://www.techempower.com/benchmarks/

On 3/4/2016 9:49 PM, Adam Young wrote:
> keycloak-1.9.0.Final
>
> Having trouble finding the right notes for setting up AJP.  This is to
> run alongside a FreeIPA server which is already set up with
> mod_proxy_ajp talking to Tomcat, so I want to keep using the same set of
> modules.
>
>
>
> I can see keycloak-1.9.0.Final/standalone/configuration/standalone.xml
>
>
> <subsystem xmlns="urn:jboss:domain:undertow:3.0">
>               <buffer-cache name="default"/>
>               <server name="default-server">
>                   <http-listener name="default" socket-binding="http"
> redirect-socket="https"/>
>
>                   <host name="default-host" alias="localhost">
>                       <location name="/" handler="welcome-content"/>
>                       <filter-ref name="server-header"/>
>                       <filter-ref name="x-powered-by-header"/>
>                   </host>
>               </server>
>
>
> I'm assuming I need a line comparable to <http-listener name="default"
> socket-binding="http" redirect-socket="https"/> But for the AJP
> protocol. Perhaps ajp-listener?
>
> A line like this, perhaps?
>
>        <http-listener name="default-ajp" socket-binding="ajp"
> scheme="http"  />
>
>
>
>
>
>
> https://docs.jboss.org/author/display/WFLY8/AJP+listeners
>
> I see at the bottom of the file:
>
>       <socket-binding-group name="standard-sockets"
> default-interface="public"
> port-offset="${jboss.socket.binding.port-offset:0}">
>           <socket-binding name="management-http" interface="management"
> port="${jboss.management.http.port:9990}"/>
>           <socket-binding name="management-https" interface="management"
> port="${jboss.management.https.port:9993}"/>
>           <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
>
> _______________________________________________
> 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 ayoung at redhat.com  Sat Mar  5 10:55:34 2016
From: ayoung at redhat.com (Adam Young)
Date: Sat, 5 Mar 2016 10:55:34 -0500
Subject: [keycloak-dev] Setting up AJP proxy from Apache?
In-Reply-To: <56DAD0B9.3030701@redhat.com>
References: <56DA4952.8050004@redhat.com> <56DAD0B9.3030701@redhat.com>
Message-ID: <56DB0176.7080902@redhat.com>

On 03/05/2016 07:27 AM, Bill Burke wrote:
> The only thing I can think of is that the server is binding to localhost
> and not a real IP address?
>
> BTW, why would you want to put Apache in front of Keycloak?  Or is this
> just an application?  Last time I looked at bench, undertow/wildfly
> performs and scales better than Apache HTTPD even for static content.

This is for the OpenStack undercloud.  Scalability is not the issue. 
Limiting the number of VMs required is the constraint.  I am deploying 
Keycloak on the FreeIPA (RH IdM) server which already owns ports 80/443 
and has TLS setup.  Keycloak has to co-exist with both the WSGI apps for 
IPA management and the Java Tomcat app for Dogtag/Certificates.

I'd love it if systemd provided a means to do socket activation for Java 
Apps running in JBoss. Until then,  JBoss is going to be proxied behind 
something that can listen on 443 as a non-privileged user.  The rest of 
OpenStack that runs on non-httpd Python webservers is fronted with HA 
proxy.  But we don't do HA proxy for the undercloud.




>
> https://www.techempower.com/benchmarks/
>
> On 3/4/2016 9:49 PM, Adam Young wrote:
>> keycloak-1.9.0.Final
>>
>> Having trouble finding the right notes for setting up AJP.  This is to
>> run alongside a FreeIPA server which is already set up with
>> mod_proxy_ajp talking to Tomcat, so I want to keep using the same set of
>> modules.
>>
>>
>>
>> I can see keycloak-1.9.0.Final/standalone/configuration/standalone.xml
>>
>>
>> <subsystem xmlns="urn:jboss:domain:undertow:3.0">
>>                <buffer-cache name="default"/>
>>                <server name="default-server">
>>                    <http-listener name="default" socket-binding="http"
>> redirect-socket="https"/>
>>
>>                    <host name="default-host" alias="localhost">
>>                        <location name="/" handler="welcome-content"/>
>>                        <filter-ref name="server-header"/>
>>                        <filter-ref name="x-powered-by-header"/>
>>                    </host>
>>                </server>
>>
>>
>> I'm assuming I need a line comparable to <http-listener name="default"
>> socket-binding="http" redirect-socket="https"/> But for the AJP
>> protocol. Perhaps ajp-listener?
>>
>> A line like this, perhaps?
>>
>>         <http-listener name="default-ajp" socket-binding="ajp"
>> scheme="http"  />
>>
>>
>>
>>
>>
>>
>> https://docs.jboss.org/author/display/WFLY8/AJP+listeners
>>
>> I see at the bottom of the file:
>>
>>        <socket-binding-group name="standard-sockets"
>> default-interface="public"
>> port-offset="${jboss.socket.binding.port-offset:0}">
>>            <socket-binding name="management-http" interface="management"
>> port="${jboss.management.http.port:9990}"/>
>>            <socket-binding name="management-https" interface="management"
>> port="${jboss.management.https.port:9993}"/>
>>            <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ayoung at redhat.com  Sat Mar  5 19:21:14 2016
From: ayoung at redhat.com (Adam Young)
Date: Sat, 5 Mar 2016 19:21:14 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D47BF3.1040900@kroehling.de>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
	<56D47062.1000905@redhat.com> <56D4743C.3000109@redhat.com>
	<56D47BF3.1040900@kroehling.de>
Message-ID: <56DB77FA.6040707@redhat.com>

On 02/29/2016 12:12 PM, Juraci Paix?o Kr?hling wrote:
> On 29.02.2016 17:39, Marek Posolda wrote:
>> git push origin master --force
> Just be extra careful on this command, as it is potentially destructive
> when applied to the "main" repository. As a general rule, I use
> "--force" only on my branches, and never on master (even less on the
> "real" origin/upstream).

NOte that you can always get back to a previsous committed state in 
git.  Run

git reflog and you will see commits all the way back.

A rebase will often fail on a merge, and you can either fix it and roll 
forward with


git rebase --continue

or abort it and be back in your previous state with

git rebase --abort


>
> By the way: this is a good time to check if the main repository is
> protected against force-pushes: http://snag.gy/2KjLY.jpg
>
> - Juca.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ayoung at redhat.com  Sat Mar  5 19:22:25 2016
From: ayoung at redhat.com (Adam Young)
Date: Sat, 5 Mar 2016 19:22:25 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D4884C.5090806@redhat.com>
References: <56D45B93.20706@redhat.com> <56D4884C.5090806@redhat.com>
Message-ID: <56DB7841.8000501@redhat.com>

On 02/29/2016 01:05 PM, Stan Silvert wrote:
> On 2/29/2016 9:54 AM, Bill Burke wrote:
>> How you guys do this?  I did a rebase -i and squashed everything but the
>> PR contained diffs of merged files and not just my changes.
>>
> I've always followed the WildFly team procedures from here:
> https://developer.jboss.org/wiki/HackingOnWildFly
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
BTW, this is one reason why I really like Gerrit and the automated CI 
runs hapening before any commit, with commits to master only being done 
in an automated fashion.   Openstack has its issues, but the dev process 
has been made to scale.

From ayoung at redhat.com  Sat Mar  5 22:36:29 2016
From: ayoung at redhat.com (Adam Young)
Date: Sat, 5 Mar 2016 22:36:29 -0500
Subject: [keycloak-dev] Setting up AJP proxy from Apache?
In-Reply-To: <56DB0176.7080902@redhat.com>
References: <56DA4952.8050004@redhat.com> <56DAD0B9.3030701@redhat.com>
	<56DB0176.7080902@redhat.com>
Message-ID: <56DBA5BD.6000302@redhat.com>

On 03/05/2016 10:55 AM, Adam Young wrote:
> On 03/05/2016 07:27 AM, Bill Burke wrote:
>> The only thing I can think of is that the server is binding to localhost
>> and not a real IP address?
>>
>> BTW, why would you want to put Apache in front of Keycloak?  Or is this
>> just an application?  Last time I looked at bench, undertow/wildfly
>> performs and scales better than Apache HTTPD even for static content.
> This is for the OpenStack undercloud.  Scalability is not the issue.
> Limiting the number of VMs required is the constraint.  I am deploying
> Keycloak on the FreeIPA (RH IdM) server which already owns ports 80/443
> and has TLS setup.  Keycloak has to co-exist with both the WSGI apps for
> IPA management and the Java Tomcat app for Dogtag/Certificates.
>
> I'd love it if systemd provided a means to do socket activation for Java
> Apps running in JBoss. Until then,  JBoss is going to be proxied behind
> something that can listen on 443 as a non-privileged user.  The rest of
> OpenStack that runs on non-httpd Python webservers is fronted with HA
> proxy.  But we don't do HA proxy for the undercloud.

And turns out it is already set up if you use the ha configuration


I am using the following line to run Keycloak from systemd:


ExecStart=/var/lib/keycloak/keycloak-1.9.0.Final/bin/standalone.sh 
-Djboss.socket.binding.port-offset=100  -c standalone-ha.xml

Seems to work OK.  I something is wrong if I do a restart, as it does 
not seem to let the As copletely shut down before starting up again, but 
systemctl stop and systemctl start work OK.

>
>
>
>
>> https://www.techempower.com/benchmarks/
>>
>> On 3/4/2016 9:49 PM, Adam Young wrote:
>>> keycloak-1.9.0.Final
>>>
>>> Having trouble finding the right notes for setting up AJP.  This is to
>>> run alongside a FreeIPA server which is already set up with
>>> mod_proxy_ajp talking to Tomcat, so I want to keep using the same set of
>>> modules.
>>>
>>>
>>>
>>> I can see keycloak-1.9.0.Final/standalone/configuration/standalone.xml
>>>
>>>
>>> <subsystem xmlns="urn:jboss:domain:undertow:3.0">
>>>                 <buffer-cache name="default"/>
>>>                 <server name="default-server">
>>>                     <http-listener name="default" socket-binding="http"
>>> redirect-socket="https"/>
>>>
>>>                     <host name="default-host" alias="localhost">
>>>                         <location name="/" handler="welcome-content"/>
>>>                         <filter-ref name="server-header"/>
>>>                         <filter-ref name="x-powered-by-header"/>
>>>                     </host>
>>>                 </server>
>>>
>>>
>>> I'm assuming I need a line comparable to <http-listener name="default"
>>> socket-binding="http" redirect-socket="https"/> But for the AJP
>>> protocol. Perhaps ajp-listener?
>>>
>>> A line like this, perhaps?
>>>
>>>          <http-listener name="default-ajp" socket-binding="ajp"
>>> scheme="http"  />
>>>
>>>
>>>
>>>
>>>
>>>
>>> https://docs.jboss.org/author/display/WFLY8/AJP+listeners
>>>
>>> I see at the bottom of the file:
>>>
>>>         <socket-binding-group name="standard-sockets"
>>> default-interface="public"
>>> port-offset="${jboss.socket.binding.port-offset:0}">
>>>             <socket-binding name="management-http" interface="management"
>>> port="${jboss.management.http.port:9990}"/>
>>>             <socket-binding name="management-https" interface="management"
>>> port="${jboss.management.https.port:9993}"/>
>>>             <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
>>>
>>> _______________________________________________
>>> 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 sthorger at redhat.com  Mon Mar  7 01:01:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 07:01:45 +0100
Subject: [keycloak-dev] arquillian tests failing
In-Reply-To: <56D9B318.9080001@redhat.com>
References: <56D9AAA4.3050807@redhat.com>
	<56D9B318.9080001@redhat.com>
Message-ID: <CAJgngAcS=CZDgyM2vdwMMDyy-Bjjk4W5D_u0C1wgytv2VKSUSA@mail.gmail.com>

Still not working? What did you run from Maven, it seems to work here as
well.

On 4 March 2016 at 17:08, Bill Burke <bburke at redhat.com> wrote:

> Yeah, something weird is going on.  This passes travis build.
>
> On 3/4/2016 10:32 AM, Bill Burke wrote:
> > I don't think its my changes.  It runs fine in the IDE, but not from
> > maven command line:
> >
> > Caused by: java.lang.RuntimeException: Provider for type class
> > java.net.URL returned a null value:
> >
> org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
> >           at
> >
> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
> >           at
> >
> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
> >           at
> >
> org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
> >           at
> >
> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
> >           at
> >
> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
> >           at
> >
> org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
> >           at
> >
> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
> >           at
> >
> org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
> >
>
> --
> 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/20160307/6bc45b30/attachment.html 

From sthorger at redhat.com  Mon Mar  7 01:04:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 07:04:15 +0100
Subject: [keycloak-dev] rebasing
In-Reply-To: <56DB7841.8000501@redhat.com>
References: <56D45B93.20706@redhat.com> <56D4884C.5090806@redhat.com>
	<56DB7841.8000501@redhat.com>
Message-ID: <CAJgngAc+Q0o3LUrHJQXxwfasLp=fkPvR8Y9berYeCzvw4srgxg@mail.gmail.com>

We do that as well. Commits to main repository is only done through GitHub
PRs and all PRs run through automated CI by Travis prior to being merged.

On 6 March 2016 at 01:22, Adam Young <ayoung at redhat.com> wrote:

> On 02/29/2016 01:05 PM, Stan Silvert wrote:
> > On 2/29/2016 9:54 AM, Bill Burke wrote:
> >> How you guys do this?  I did a rebase -i and squashed everything but the
> >> PR contained diffs of merged files and not just my changes.
> >>
> > I've always followed the WildFly team procedures from here:
> > https://developer.jboss.org/wiki/HackingOnWildFly
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> BTW, this is one reason why I really like Gerrit and the automated CI
> runs hapening before any commit, with commits to master only being done
> in an automated fashion.   Openstack has its issues, but the dev process
> has been made to scale.
> _______________________________________________
> 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/20160307/dbb4ff4c/attachment.html 

From sthorger at redhat.com  Mon Mar  7 01:20:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 07:20:07 +0100
Subject: [keycloak-dev] arquillian tests failing
In-Reply-To: <CAJgngAcS=CZDgyM2vdwMMDyy-Bjjk4W5D_u0C1wgytv2VKSUSA@mail.gmail.com>
References: <56D9AAA4.3050807@redhat.com> <56D9B318.9080001@redhat.com>
	<CAJgngAcS=CZDgyM2vdwMMDyy-Bjjk4W5D_u0C1wgytv2VKSUSA@mail.gmail.com>
Message-ID: <CAJgngAcdrs--y+7tmAff7o1m01OM_3+DzkxmZB62X9LayPXVUQ@mail.gmail.com>

Nah, it's failing here as well now

On 7 March 2016 at 07:01, Stian Thorgersen <sthorger at redhat.com> wrote:

> Still not working? What did you run from Maven, it seems to work here as
> well.
>
> On 4 March 2016 at 17:08, Bill Burke <bburke at redhat.com> wrote:
>
>> Yeah, something weird is going on.  This passes travis build.
>>
>> On 3/4/2016 10:32 AM, Bill Burke wrote:
>> > I don't think its my changes.  It runs fine in the IDE, but not from
>> > maven command line:
>> >
>> > Caused by: java.lang.RuntimeException: Provider for type class
>> > java.net.URL returned a null value:
>> >
>> org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
>> >           at
>> >
>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
>> >           at
>> >
>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
>> >           at
>> >
>> org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
>> >           at
>> >
>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
>> >           at
>> >
>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
>> >           at
>> >
>> org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
>> >           at
>> >
>> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
>> >           at
>> >
>> org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
>> >
>>
>> --
>> 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/20160307/53e4f919/attachment.html 

From sthorger at redhat.com  Mon Mar  7 01:21:14 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 07:21:14 +0100
Subject: [keycloak-dev] arquillian tests failing
In-Reply-To: <CAJgngAcdrs--y+7tmAff7o1m01OM_3+DzkxmZB62X9LayPXVUQ@mail.gmail.com>
References: <56D9AAA4.3050807@redhat.com> <56D9B318.9080001@redhat.com>
	<CAJgngAcS=CZDgyM2vdwMMDyy-Bjjk4W5D_u0C1wgytv2VKSUSA@mail.gmail.com>
	<CAJgngAcdrs--y+7tmAff7o1m01OM_3+DzkxmZB62X9LayPXVUQ@mail.gmail.com>
Message-ID: <CAJgngAd_cMWUndZr8Ptw5aykNpb3y3uAAn5qPA5fawyuErheqw@mail.gmail.com>

Added https://issues.jboss.org/browse/KEYCLOAK-2605

On 7 March 2016 at 07:20, Stian Thorgersen <sthorger at redhat.com> wrote:

> Nah, it's failing here as well now
>
> On 7 March 2016 at 07:01, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Still not working? What did you run from Maven, it seems to work here as
>> well.
>>
>> On 4 March 2016 at 17:08, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Yeah, something weird is going on.  This passes travis build.
>>>
>>> On 3/4/2016 10:32 AM, Bill Burke wrote:
>>> > I don't think its my changes.  It runs fine in the IDE, but not from
>>> > maven command line:
>>> >
>>> > Caused by: java.lang.RuntimeException: Provider for type class
>>> > java.net.URL returned a null value:
>>> >
>>> org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
>>> >           at
>>> >
>>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
>>> >           at
>>> >
>>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
>>> >           at
>>> >
>>> org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
>>> >           at
>>> >
>>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
>>> >           at
>>> >
>>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
>>> >           at
>>> >
>>> org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
>>> >           at
>>> >
>>> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
>>> >           at
>>> >
>>> org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
>>> >
>>>
>>> --
>>> 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/20160307/16a12961/attachment.html 

From sthorger at redhat.com  Mon Mar  7 02:40:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 08:40:21 +0100
Subject: [keycloak-dev] arquillian tests failing
In-Reply-To: <CAJgngAd_cMWUndZr8Ptw5aykNpb3y3uAAn5qPA5fawyuErheqw@mail.gmail.com>
References: <56D9AAA4.3050807@redhat.com> <56D9B318.9080001@redhat.com>
	<CAJgngAcS=CZDgyM2vdwMMDyy-Bjjk4W5D_u0C1wgytv2VKSUSA@mail.gmail.com>
	<CAJgngAcdrs--y+7tmAff7o1m01OM_3+DzkxmZB62X9LayPXVUQ@mail.gmail.com>
	<CAJgngAd_cMWUndZr8Ptw5aykNpb3y3uAAn5qPA5fawyuErheqw@mail.gmail.com>
Message-ID: <CAJgngAdVRti_mtZ5pu3ej+7iaWmCgor-56An-w1AZCccjxsBhg@mail.gmail.com>

Caused by upgrade to Arquillian Graphene, reverting to previous version on
it's way: https://github.com/keycloak/keycloak/pull/2330

On 7 March 2016 at 07:21, Stian Thorgersen <sthorger at redhat.com> wrote:

> Added https://issues.jboss.org/browse/KEYCLOAK-2605
>
> On 7 March 2016 at 07:20, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Nah, it's failing here as well now
>>
>> On 7 March 2016 at 07:01, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>>> Still not working? What did you run from Maven, it seems to work here as
>>> well.
>>>
>>> On 4 March 2016 at 17:08, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> Yeah, something weird is going on.  This passes travis build.
>>>>
>>>> On 3/4/2016 10:32 AM, Bill Burke wrote:
>>>> > I don't think its my changes.  It runs fine in the IDE, but not from
>>>> > maven command line:
>>>> >
>>>> > Caused by: java.lang.RuntimeException: Provider for type class
>>>> > java.net.URL returned a null value:
>>>> >
>>>> org.jboss.arquillian.graphene.location.ContainerCustomizableURLResourceProvider at 7e916dc2
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.lookup(ArquillianResourceTestEnricher.java:133)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.test.impl.enricher.resource.ArquillianResourceTestEnricher.enrich(ArquillianResourceTestEnricher.java:67)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.graphene.enricher.AbstractSearchContextEnricher.enrichRecursively(AbstractSearchContextEnricher.java:69)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.setupPage(PageObjectEnricher.java:97)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.graphene.enricher.PageObjectEnricher.enrich(PageObjectEnricher.java:75)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.graphene.enricher.GrapheneEnricher.enrich(GrapheneEnricher.java:55)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:55)
>>>> >           at
>>>> >
>>>> org.jboss.arquillian.container.test.impl.ClientTestInstanceEnricher.enrich(ClientTestInstanceEnricher.java:51)
>>>> >
>>>>
>>>> --
>>>> 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/20160307/85e26006/attachment-0001.html 

From sthorger at redhat.com  Mon Mar  7 03:11:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 09:11:25 +0100
Subject: [keycloak-dev] Best practices for securing sign-in on mobile
Message-ID: <CAJgngAeiXjFWVwz-v=Aaw16YQCS1uqZHDvu_xDF2aZq03AANjw@mail.gmail.com>

Our Cordova apapter uses a webview (via cordova-plugin-inappbrowser) to
open the login page. This results in no SSO between applications and it
also has some security implications. A better approach is to use in app
browser tabs when supported or fallback to the system browser.

See https://www.youtube.com/watch?v=ppeU8yeI_ks for more details.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160307/0cbcdf89/attachment.html 

From mposolda at redhat.com  Mon Mar  7 05:03:55 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 7 Mar 2016 11:03:55 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
Message-ID: <56DD520B.8060205@redhat.com>

Send PR with added support for $subject . 
https://github.com/keycloak/keycloak/pull/2332 .

Few details:
- Added DBLockProvider, which handles acquire and release of DB lock. 
When lock is acquired, the cluster node2 needs to wait until node1 
release the lock

- The lock is acquired at startup for the migrating model (both model 
specific and generic migration), importing realms and adding initial 
admin user. So this can be done always just by one node at a time.

- The lock is implemented at DB level, so it works even if infinispan 
cluster is not correctly configured. For the JPA, I've added 
implementation, which is reusing liquibase DB locking with the bugfix, 
which prevented builtin liquibase lock to work correctly. I've added 
implementation for Mongo too.

- Added DBLockTest, which simulates 20 threads racing for acquire lock 
concurrently. It's passing with all databases.

- Default timeout for acquire lock is 900 seconds and the time for lock 
recheck is 2 seconds. So if node2 is not able to acquire lock within 900 
seconds, it fails to start. There is possibility to change in 
keycloak-server.json. Is 900 seconds too much? I was thinking about the 
case when there is some large realm file importing at startup.

Marek

From mposolda at redhat.com  Mon Mar  7 05:59:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 7 Mar 2016 11:59:24 +0100
Subject: [keycloak-dev] Should we add version to JSON during export?
Message-ID: <56DD5F0C.2090700@redhat.com>

Currently there is an issue, that when we import JSON file, we don't 
know in which Keycloak version was this JSON file exported. This can 
cause some issues. For example you don't know which builtin objects 
exactly you should add - some example in the JIRA: 
https://issues.jboss.org/browse/KEYCLOAK-1982

Adding version may not help in all cases as there is also hand-written 
JSON files and partial-import etc, so you don't know if version is 
really presented in the imported JSON file. On the other hand, in some 
cases it may be helpful.

Question is, should we aim to add it to 1.9.2?

Marek

From bburke at redhat.com  Mon Mar  7 11:12:09 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 7 Mar 2016 11:12:09 -0500
Subject: [keycloak-dev] Should we add version to JSON during export?
In-Reply-To: <56DD5F0C.2090700@redhat.com>
References: <56DD5F0C.2090700@redhat.com>
Message-ID: <56DDA859.2090101@redhat.com>

Yes, we need to do this.

On 3/7/2016 5:59 AM, Marek Posolda wrote:
> Currently there is an issue, that when we import JSON file, we don't
> know in which Keycloak version was this JSON file exported. This can
> cause some issues. For example you don't know which builtin objects
> exactly you should add - some example in the JIRA:
> https://issues.jboss.org/browse/KEYCLOAK-1982
>
> Adding version may not help in all cases as there is also hand-written
> JSON files and partial-import etc, so you don't know if version is
> really presented in the imported JSON file. On the other hand, in some
> cases it may be helpful.
>
> Question is, should we aim to add it to 1.9.2?
>
> 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 sthorger at redhat.com  Mon Mar  7 13:46:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 19:46:55 +0100
Subject: [keycloak-dev] Should we add version to JSON during export?
In-Reply-To: <56DDA859.2090101@redhat.com>
References: <56DD5F0C.2090700@redhat.com>
	<56DDA859.2090101@redhat.com>
Message-ID: <CAJgngAddrQaby9mjqEBFdeHCSiMM37D-0hZC1h+H=0HPN44fVw@mail.gmail.com>

Ok, JIRA and add for 1.9.2

On 7 March 2016 at 17:12, Bill Burke <bburke at redhat.com> wrote:

> Yes, we need to do this.
>
> On 3/7/2016 5:59 AM, Marek Posolda wrote:
> > Currently there is an issue, that when we import JSON file, we don't
> > know in which Keycloak version was this JSON file exported. This can
> > cause some issues. For example you don't know which builtin objects
> > exactly you should add - some example in the JIRA:
> > https://issues.jboss.org/browse/KEYCLOAK-1982
> >
> > Adding version may not help in all cases as there is also hand-written
> > JSON files and partial-import etc, so you don't know if version is
> > really presented in the imported JSON file. On the other hand, in some
> > cases it may be helpful.
> >
> > Question is, should we aim to add it to 1.9.2?
> >
> > 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
>
> _______________________________________________
> 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/20160307/0f370d3b/attachment.html 

From sthorger at redhat.com  Mon Mar  7 13:50:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 7 Mar 2016 19:50:25 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <56DD520B.8060205@redhat.com>
References: <56DD520B.8060205@redhat.com>
Message-ID: <CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>

900 seconds is probably ok, but what happens if the node holding the lock
dies?

On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com> wrote:

> Send PR with added support for $subject .
> https://github.com/keycloak/keycloak/pull/2332 .
>
> Few details:
> - Added DBLockProvider, which handles acquire and release of DB lock.
> When lock is acquired, the cluster node2 needs to wait until node1
> release the lock
>
> - The lock is acquired at startup for the migrating model (both model
> specific and generic migration), importing realms and adding initial
> admin user. So this can be done always just by one node at a time.
>
> - The lock is implemented at DB level, so it works even if infinispan
> cluster is not correctly configured. For the JPA, I've added
> implementation, which is reusing liquibase DB locking with the bugfix,
> which prevented builtin liquibase lock to work correctly. I've added
> implementation for Mongo too.
>
> - Added DBLockTest, which simulates 20 threads racing for acquire lock
> concurrently. It's passing with all databases.
>
> - Default timeout for acquire lock is 900 seconds and the time for lock
> recheck is 2 seconds. So if node2 is not able to acquire lock within 900
> seconds, it fails to start. There is possibility to change in
> keycloak-server.json. Is 900 seconds too much? I was thinking about the
> case when there is some large realm file importing at startup.
>
> Marek
> _______________________________________________
> 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/20160307/c83f0ec5/attachment.html 

From mposolda at redhat.com  Mon Mar  7 15:59:46 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 7 Mar 2016 21:59:46 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
References: <56DD520B.8060205@redhat.com>
	<CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
Message-ID: <56DDEBC2.8080302@redhat.com>

Then the record in DB will remain locked and needs to be fixed manually. 
Actually the same behaviour like liquibase. The possibilities to repair 
from this state is:
- Run keycloak with system property "-Dkeycloak.dblock.forceUnlock=true" 
. Then Keycloak will release the existing lock at startup and acquire 
new lock. The warning is written to server.log that this property should 
be used carefully just to repair DB
- Manually delete lock record from DATABASECHANGELOGLOCK table (or 
"dblock" collection in mongo)

The other possibility is that after timeout, node2 will assume the 
current lock is timed-out and will forcefully release existing lock and 
replace with it's own lock. However I didn't it this way as it's 
potentially dangerous though - there is some chance that 2 nodes run 
migration or import at the same time and DB will end in inconsistent 
state. Or is it acceptable risk?

Marek


On 07/03/16 19:50, Stian Thorgersen wrote:
> 900 seconds is probably ok, but what happens if the node holding the 
> lock dies?
>
> On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Send PR with added support for $subject .
>     https://github.com/keycloak/keycloak/pull/2332 .
>
>     Few details:
>     - Added DBLockProvider, which handles acquire and release of DB lock.
>     When lock is acquired, the cluster node2 needs to wait until node1
>     release the lock
>
>     - The lock is acquired at startup for the migrating model (both model
>     specific and generic migration), importing realms and adding initial
>     admin user. So this can be done always just by one node at a time.
>
>     - The lock is implemented at DB level, so it works even if infinispan
>     cluster is not correctly configured. For the JPA, I've added
>     implementation, which is reusing liquibase DB locking with the bugfix,
>     which prevented builtin liquibase lock to work correctly. I've added
>     implementation for Mongo too.
>
>     - Added DBLockTest, which simulates 20 threads racing for acquire lock
>     concurrently. It's passing with all databases.
>
>     - Default timeout for acquire lock is 900 seconds and the time for
>     lock
>     recheck is 2 seconds. So if node2 is not able to acquire lock
>     within 900
>     seconds, it fails to start. There is possibility to change in
>     keycloak-server.json. Is 900 seconds too much? I was thinking
>     about the
>     case when there is some large realm file importing at startup.
>
>     Marek
>     _______________________________________________
>     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/20160307/d426e6ae/attachment-0001.html 

From jdennis at redhat.com  Mon Mar  7 19:14:40 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 7 Mar 2016 19:14:40 -0500
Subject: [keycloak-dev] client creation using bearer token
Message-ID: <56DE1970.4090208@redhat.com>

Chapter 9.1.1 of the Keycloak Reference Guide
(http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
says that a bearer token can be used to register a client provided the
user has the create-client or manage-client role on the realm.

Chapter 6 discusses how to create a user in the master realm who can
administer a specific realm. I followed those instructions and created
a user and assigned them the create-client role in the desired realm.

I then obtained a token for that user by posting to
auth/realms/master/protocol/openid-connect/token with the username and
password for the realm administrator I created along with the
client-id of "admin-cli" (not sure if this is the right client id for
this purpose, can someone explain selecting the proper client id?).

I received back a token and then used this as an authorization bearer
token when POSTing to the
auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
SP client in the realm. However this fails with an 403 Forbidden
response and the message "Invalid signature".

This error seems to be generated by the ClientRegistrationTokenUtils
class in the method parseToken() which is called in the init() method
of the ClientRegistrationAuth class. As far as I can tell the
parseToken() method is using the public key for the realm. But the
token is not from the realm, the token is from the master realm where
the realm's admin is located.

For the bearer token to work when registering a client it would seem
the token would have belong to a user in the realm, not the master
realm as discussed in Chapter 6.

How is client creation supposed to work with a bearer token instead of
using an initial access token?

-- 
John

From sthorger at redhat.com  Tue Mar  8 00:48:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 06:48:20 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <56DDEBC2.8080302@redhat.com>
References: <56DD520B.8060205@redhat.com>
	<CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
	<56DDEBC2.8080302@redhat.com>
Message-ID: <CAJgngAfhB6T-Ts9d4NFj4LT2-sqh3CrJk9sMxe9x+ueZ=tezGg@mail.gmail.com>

What about obtaining a database lock on a table/column? That would
automatically be freed if the transaction dies.

-1 To having a timeout, I agree it's dangerous and could leave the DB
inconsistent so we shouldn't do it

On 7 March 2016 at 21:59, Marek Posolda <mposolda at redhat.com> wrote:

> Then the record in DB will remain locked and needs to be fixed manually.
> Actually the same behaviour like liquibase. The possibilities to repair
> from this state is:
> - Run keycloak with system property "-Dkeycloak.dblock.forceUnlock=true" .
> Then Keycloak will release the existing lock at startup and acquire new
> lock. The warning is written to server.log that this property should be
> used carefully just to repair DB
> - Manually delete lock record from DATABASECHANGELOGLOCK table (or
> "dblock" collection in mongo)
>
> The other possibility is that after timeout, node2 will assume the current
> lock is timed-out and will forcefully release existing lock and replace
> with it's own lock. However I didn't it this way as it's potentially
> dangerous though - there is some chance that 2 nodes run migration or
> import at the same time and DB will end in inconsistent state. Or is it
> acceptable risk?
>
> Marek
>
>
>
> On 07/03/16 19:50, Stian Thorgersen wrote:
>
> 900 seconds is probably ok, but what happens if the node holding the lock
> dies?
>
> On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Send PR with added support for $subject .
>> https://github.com/keycloak/keycloak/pull/2332 .
>>
>> Few details:
>> - Added DBLockProvider, which handles acquire and release of DB lock.
>> When lock is acquired, the cluster node2 needs to wait until node1
>> release the lock
>>
>> - The lock is acquired at startup for the migrating model (both model
>> specific and generic migration), importing realms and adding initial
>> admin user. So this can be done always just by one node at a time.
>>
>> - The lock is implemented at DB level, so it works even if infinispan
>> cluster is not correctly configured. For the JPA, I've added
>> implementation, which is reusing liquibase DB locking with the bugfix,
>> which prevented builtin liquibase lock to work correctly. I've added
>> implementation for Mongo too.
>>
>> - Added DBLockTest, which simulates 20 threads racing for acquire lock
>> concurrently. It's passing with all databases.
>>
>> - Default timeout for acquire lock is 900 seconds and the time for lock
>> recheck is 2 seconds. So if node2 is not able to acquire lock within 900
>> seconds, it fails to start. There is possibility to change in
>> keycloak-server.json. Is 900 seconds too much? I was thinking about the
>> case when there is some large realm file importing at startup.
>>
>> Marek
>> _______________________________________________
>> 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/20160308/f98488c9/attachment.html 

From sthorger at redhat.com  Tue Mar  8 00:51:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 06:51:11 +0100
Subject: [keycloak-dev] client creation using bearer token
In-Reply-To: <56DE1970.4090208@redhat.com>
References: <56DE1970.4090208@redhat.com>
Message-ID: <CAJgngAfG07GfbkyQyqWz2jex0XyOK8DvFNw5ueHWa1SMsVFjag@mail.gmail.com>

Client registration service can only be invoked by a user from the realm
you are creating a client in, so users in the master realm can only create
clients in the master realm.

IMO you should use the client registration services, supported initial
access tokens and leave realm creation to another process. Creating a realm
is part of installing the Keycloak server, not installing the client.

On 8 March 2016 at 01:14, John Dennis <jdennis at redhat.com> wrote:

> Chapter 9.1.1 of the Keycloak Reference Guide
> (http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
> says that a bearer token can be used to register a client provided the
> user has the create-client or manage-client role on the realm.
>
> Chapter 6 discusses how to create a user in the master realm who can
> administer a specific realm. I followed those instructions and created
> a user and assigned them the create-client role in the desired realm.
>
> I then obtained a token for that user by posting to
> auth/realms/master/protocol/openid-connect/token with the username and
> password for the realm administrator I created along with the
> client-id of "admin-cli" (not sure if this is the right client id for
> this purpose, can someone explain selecting the proper client id?).
>
> I received back a token and then used this as an authorization bearer
> token when POSTing to the
> auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
> SP client in the realm. However this fails with an 403 Forbidden
> response and the message "Invalid signature".
>
> This error seems to be generated by the ClientRegistrationTokenUtils
> class in the method parseToken() which is called in the init() method
> of the ClientRegistrationAuth class. As far as I can tell the
> parseToken() method is using the public key for the realm. But the
> token is not from the realm, the token is from the master realm where
> the realm's admin is located.
>
> For the bearer token to work when registering a client it would seem
> the token would have belong to a user in the realm, not the master
> realm as discussed in Chapter 6.
>
> How is client creation supposed to work with a bearer token instead of
> using an initial access token?
>
> --
> John
> _______________________________________________
> 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/20160308/4eb8d45a/attachment.html 

From sthorger at redhat.com  Tue Mar  8 01:28:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 07:28:07 +0100
Subject: [keycloak-dev] [keycloak-user] Best practices for securing
	sign-in on mobile
In-Reply-To: <718327EA-EE14-41C1-80F4-44CD71B9CC36@expedia.com>
References: <CAJgngAeiXjFWVwz-v=Aaw16YQCS1uqZHDvu_xDF2aZq03AANjw@mail.gmail.com>
	<718327EA-EE14-41C1-80F4-44CD71B9CC36@expedia.com>
Message-ID: <CAJgngAcTY5sZuFHm28epHsjWqo128W5vTCXR-tOZRXgVWO9P5A@mail.gmail.com>

Have you tried AppAuth with Keycloak? If so I'd love to know how you got on
with it.

On 7 March 2016 at 18:28, Jason Axley <jaxley at expedia.com> wrote:

> The Google Identity team just open sourced some Open ID Connect libraries
> that use In-app tabs on Android and SFSafariViewController on iOS for
> secure, streamlined web workflows in-app.
>
> https://openid.github.io/AppAuth-Android
> https://openid.github.io/AppAuth-iOS
>
> -Jason
>
> From: <keycloak-user-bounces at lists.jboss.org> on behalf of Stian
> Thorgersen <sthorger at redhat.com>
> Reply-To: "stian at redhat.com" <stian at redhat.com>
> Date: Monday, March 7, 2016 at 12:11 AM
> To: keycloak-dev <keycloak-dev at lists.jboss.org>, "
> keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org>
> Subject: [keycloak-user] Best practices for securing sign-in on mobile
>
> Our Cordova apapter uses a webview (via cordova-plugin-inappbrowser) to
> open the login page. This results in no SSO between applications and it
> also has some security implications. A better approach is to use in app
> browser tabs when supported or fallback to the system browser.
>
> See https://www.youtube.com/watch?v=ppeU8yeI_ks for more details.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160308/142d4ad9/attachment-0001.html 

From mposolda at redhat.com  Tue Mar  8 02:53:11 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 8 Mar 2016 08:53:11 +0100
Subject: [keycloak-dev] Should we add version to JSON during export?
In-Reply-To: <CAJgngAddrQaby9mjqEBFdeHCSiMM37D-0hZC1h+H=0HPN44fVw@mail.gmail.com>
References: <56DD5F0C.2090700@redhat.com> <56DDA859.2090101@redhat.com>
	<CAJgngAddrQaby9mjqEBFdeHCSiMM37D-0hZC1h+H=0HPN44fVw@mail.gmail.com>
Message-ID: <56DE84E7.2030805@redhat.com>

Added https://issues.jboss.org/browse/KEYCLOAK-2613

On 07/03/16 19:46, Stian Thorgersen wrote:
> Ok, JIRA and add for 1.9.2
>
> On 7 March 2016 at 17:12, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Yes, we need to do this.
>
>     On 3/7/2016 5:59 AM, Marek Posolda wrote:
>     > Currently there is an issue, that when we import JSON file, we don't
>     > know in which Keycloak version was this JSON file exported. This can
>     > cause some issues. For example you don't know which builtin objects
>     > exactly you should add - some example in the JIRA:
>     > https://issues.jboss.org/browse/KEYCLOAK-1982
>     >
>     > Adding version may not help in all cases as there is also
>     hand-written
>     > JSON files and partial-import etc, so you don't know if version is
>     > really presented in the imported JSON file. On the other hand,
>     in some
>     > cases it may be helpful.
>     >
>     > Question is, should we aim to add it to 1.9.2?
>     >
>     > Marek
>     > _______________________________________________
>     > 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
>
>
>
>
> _______________________________________________
> 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/20160308/b91cfad4/attachment.html 

From sthorger at redhat.com  Tue Mar  8 03:08:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 09:08:04 +0100
Subject: [keycloak-dev] Remove auth-server-url-for-backend-requests from
	adapters
Message-ID: <CAJgngAc6uh7TfKYMT1BP=sCGUbe4Z4_nD2rBv5QaPdDJ14+2PA@mail.gmail.com>

Currently we allow adapters to configure two urls for Keycloak
(auth-server-url and auth-server-url-for-backend-requests). I propose we
remove auth-server-url-for-backend-requests.

The auth-server-url-for-backend-requests property was added as a way for
adapters to invoke Keycloak directly without having to go through a load
balancer or reverse proxy.

The issue with auth-server-url-for-backend-requests is that the Keycloak
server will not know the adapter is invoking Keycloak from a different URL,
which results in invalid URLs in tokens and also if any links are generated
(for example verify email).

It also means that there's a need to have two separate certificates
configured for Keycloak as there are different hostnames.

The currently proposed solution is to add a way to configure the hostname
for the Keycloak server. However, this is an extra configuration
requirement and is also a significant amount of work to implement as well
as potentially quite error prone. This could further be problematic if
there is indeed two valid URLs for a server (for example http://company.com
and http://internal.company.com).

We should simply remove auth-server-url-for-backend-requests. If anyone
wants to bypass the load balancer for internal machines that should be
solved at the DNS level or by adding entries to the host file. As the
hostname remains the same there's no need for multiple certificates, nor is
there a need to hardcode the address on the Keycloak server itself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160308/76e8d562/attachment.html 

From mposolda at redhat.com  Tue Mar  8 03:22:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 8 Mar 2016 09:22:12 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <CAJgngAfhB6T-Ts9d4NFj4LT2-sqh3CrJk9sMxe9x+ueZ=tezGg@mail.gmail.com>
References: <56DD520B.8060205@redhat.com>
	<CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
	<56DDEBC2.8080302@redhat.com>
	<CAJgngAfhB6T-Ts9d4NFj4LT2-sqh3CrJk9sMxe9x+ueZ=tezGg@mail.gmail.com>
Message-ID: <56DE8BB4.1020206@redhat.com>

On 08/03/16 06:48, Stian Thorgersen wrote:
> What about obtaining a database lock on a table/column? That would 
> automatically be freed if the transaction dies.
You mean something like "Give me lock for table XY until end of 
transaction" ? I doubt there is some universal solution for something 
like this, which will reliably work with all databases which we need to 
support :/ Otherwise I guess liquibase would already use it too?

Currently it works the way that lock is obtained by updating the column 
in database. Something similar to "UPDATE DATABASECHANGELOGLOCK set 
LOCKED=true where ID=1" .
Note there is always single record in this table with ID=1. Something 
similar is done for Mongo too.

The lock is released in "finally" block if something fails. The only 
possibility how can DB remains locked is if someone force to kill the 
process (like "kill -9" command, then finally blocks are not called) or 
if network connection between server and DB is lost. The chance of this 
is very low IMO and we have option to manually recover from this.

Marek
>
> -1 To having a timeout, I agree it's dangerous and could leave the DB 
> inconsistent so we shouldn't do it
>
> On 7 March 2016 at 21:59, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Then the record in DB will remain locked and needs to be fixed
>     manually. Actually the same behaviour like liquibase. The
>     possibilities to repair from this state is:
>     - Run keycloak with system property
>     "-Dkeycloak.dblock.forceUnlock=true" . Then Keycloak will release
>     the existing lock at startup and acquire new lock. The warning is
>     written to server.log that this property should be used carefully
>     just to repair DB
>     - Manually delete lock record from DATABASECHANGELOGLOCK table (or
>     "dblock" collection in mongo)
>
>     The other possibility is that after timeout, node2 will assume the
>     current lock is timed-out and will forcefully release existing
>     lock and replace with it's own lock. However I didn't it this way
>     as it's potentially dangerous though - there is some chance that 2
>     nodes run migration or import at the same time and DB will end in
>     inconsistent state. Or is it acceptable risk?
>
>     Marek
>
>
>
>     On 07/03/16 19:50, Stian Thorgersen wrote:
>>     900 seconds is probably ok, but what happens if the node holding
>>     the lock dies?
>>
>>     On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Send PR with added support for $subject .
>>         https://github.com/keycloak/keycloak/pull/2332 .
>>
>>         Few details:
>>         - Added DBLockProvider, which handles acquire and release of
>>         DB lock.
>>         When lock is acquired, the cluster node2 needs to wait until
>>         node1
>>         release the lock
>>
>>         - The lock is acquired at startup for the migrating model
>>         (both model
>>         specific and generic migration), importing realms and adding
>>         initial
>>         admin user. So this can be done always just by one node at a
>>         time.
>>
>>         - The lock is implemented at DB level, so it works even if
>>         infinispan
>>         cluster is not correctly configured. For the JPA, I've added
>>         implementation, which is reusing liquibase DB locking with
>>         the bugfix,
>>         which prevented builtin liquibase lock to work correctly.
>>         I've added
>>         implementation for Mongo too.
>>
>>         - Added DBLockTest, which simulates 20 threads racing for
>>         acquire lock
>>         concurrently. It's passing with all databases.
>>
>>         - Default timeout for acquire lock is 900 seconds and the
>>         time for lock
>>         recheck is 2 seconds. So if node2 is not able to acquire lock
>>         within 900
>>         seconds, it fails to start. There is possibility to change in
>>         keycloak-server.json. Is 900 seconds too much? I was thinking
>>         about the
>>         case when there is some large realm file importing at startup.
>>
>>         Marek
>>         _______________________________________________
>>         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/20160308/fdd30eb8/attachment.html 

From sthorger at redhat.com  Tue Mar  8 03:41:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 09:41:47 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <56DE8BB4.1020206@redhat.com>
References: <56DD520B.8060205@redhat.com>
	<CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
	<56DDEBC2.8080302@redhat.com>
	<CAJgngAfhB6T-Ts9d4NFj4LT2-sqh3CrJk9sMxe9x+ueZ=tezGg@mail.gmail.com>
	<56DE8BB4.1020206@redhat.com>
Message-ID: <CAJgngAeCGQW+09Bc8kyd3qRkhqh7Enzn-U-zzp93qor+ejhKAA@mail.gmail.com>

I actually think the chance of someone killing it during upgrade is
relatively high. It could be they forgot to include bind address or used
wrong server config. It could be migration takes longer than they expect.
We shouldn't require users to manually unlock.

The lock should be done in association with the transaction. JPA provides
pessimistic locks so you can do:

DatabaseLockEntity lock = em.find(DatabaseLockEntity.class, "lock",
LockModeType.PESSIMISTIC_WRITE);

That will work for all databases (except Mongo of course). If the process
dies the transaction will timeout and it's safe to run again at that point
because no chances would have been committed to the db.



On 8 March 2016 at 09:22, Marek Posolda <mposolda at redhat.com> wrote:

> On 08/03/16 06:48, Stian Thorgersen wrote:
>
> What about obtaining a database lock on a table/column? That would
> automatically be freed if the transaction dies.
>
> You mean something like "Give me lock for table XY until end of
> transaction" ? I doubt there is some universal solution for something like
> this, which will reliably work with all databases which we need to support
> :/ Otherwise I guess liquibase would already use it too?
>
> Currently it works the way that lock is obtained by updating the column in
> database. Something similar to "UPDATE DATABASECHANGELOGLOCK set
> LOCKED=true where ID=1" .
> Note there is always single record in this table with ID=1. Something
> similar is done for Mongo too.
>
> The lock is released in "finally" block if something fails. The only
> possibility how can DB remains locked is if someone force to kill the
> process (like "kill -9" command, then finally blocks are not called) or if
> network connection between server and DB is lost. The chance of this is
> very low IMO and we have option to manually recover from this.
>
> Marek
>
>
> -1 To having a timeout, I agree it's dangerous and could leave the DB
> inconsistent so we shouldn't do it
>
> On 7 March 2016 at 21:59, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Then the record in DB will remain locked and needs to be fixed manually.
>> Actually the same behaviour like liquibase. The possibilities to repair
>> from this state is:
>> - Run keycloak with system property "-Dkeycloak.dblock.forceUnlock=true"
>> . Then Keycloak will release the existing lock at startup and acquire new
>> lock. The warning is written to server.log that this property should be
>> used carefully just to repair DB
>> - Manually delete lock record from DATABASECHANGELOGLOCK table (or
>> "dblock" collection in mongo)
>>
>> The other possibility is that after timeout, node2 will assume the
>> current lock is timed-out and will forcefully release existing lock and
>> replace with it's own lock. However I didn't it this way as it's
>> potentially dangerous though - there is some chance that 2 nodes run
>> migration or import at the same time and DB will end in inconsistent state.
>> Or is it acceptable risk?
>>
>> Marek
>>
>>
>>
>> On 07/03/16 19:50, Stian Thorgersen wrote:
>>
>> 900 seconds is probably ok, but what happens if the node holding the lock
>> dies?
>>
>> On 7 March 2016 at 11:03, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> Send PR with added support for $subject .
>>> https://github.com/keycloak/keycloak/pull/2332 .
>>>
>>> Few details:
>>> - Added DBLockProvider, which handles acquire and release of DB lock.
>>> When lock is acquired, the cluster node2 needs to wait until node1
>>> release the lock
>>>
>>> - The lock is acquired at startup for the migrating model (both model
>>> specific and generic migration), importing realms and adding initial
>>> admin user. So this can be done always just by one node at a time.
>>>
>>> - The lock is implemented at DB level, so it works even if infinispan
>>> cluster is not correctly configured. For the JPA, I've added
>>> implementation, which is reusing liquibase DB locking with the bugfix,
>>> which prevented builtin liquibase lock to work correctly. I've added
>>> implementation for Mongo too.
>>>
>>> - Added DBLockTest, which simulates 20 threads racing for acquire lock
>>> concurrently. It's passing with all databases.
>>>
>>> - Default timeout for acquire lock is 900 seconds and the time for lock
>>> recheck is 2 seconds. So if node2 is not able to acquire lock within 900
>>> seconds, it fails to start. There is possibility to change in
>>> keycloak-server.json. Is 900 seconds too much? I was thinking about the
>>> case when there is some large realm file importing at startup.
>>>
>>> Marek
>>> _______________________________________________
>>> 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/20160308/86d33261/attachment-0001.html 

From mposolda at redhat.com  Tue Mar  8 03:43:05 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 8 Mar 2016 09:43:05 +0100
Subject: [keycloak-dev] Remove auth-server-url-for-backend-requests from
 adapters
In-Reply-To: <CAJgngAc6uh7TfKYMT1BP=sCGUbe4Z4_nD2rBv5QaPdDJ14+2PA@mail.gmail.com>
References: <CAJgngAc6uh7TfKYMT1BP=sCGUbe4Z4_nD2rBv5QaPdDJ14+2PA@mail.gmail.com>
Message-ID: <56DE9099.2030703@redhat.com>

+1 to remove it.

We can always re-add or add something different if people start to 
complain ;-)

I guess that earlier or later, we may still need a possibility to 
configure hostname for keycloak server. I think that there were people 
with funky deployments having issues even if they don't use 
auth-server-url-for-backend-requests. Other possibility instead of 
introduce hostname might be to introduce list of valid URLs on adapter 
side, which are acceptable as issuers of access token. But who knows, 
maybe everyone can somehow fix his deployment and we won't need anything 
:-)

Marek

On 08/03/16 09:08, Stian Thorgersen wrote:
> Currently we allow adapters to configure two urls for Keycloak 
> (auth-server-url and auth-server-url-for-backend-requests). I propose 
> we remove auth-server-url-for-backend-requests.
>
> The auth-server-url-for-backend-requests property was added as a way 
> for adapters to invoke Keycloak directly without having to go through 
> a load balancer or reverse proxy.
>
> The issue with auth-server-url-for-backend-requests is that the 
> Keycloak server will not know the adapter is invoking Keycloak from a 
> different URL, which results in invalid URLs in tokens and also if any 
> links are generated (for example verify email).
>
> It also means that there's a need to have two separate certificates 
> configured for Keycloak as there are different hostnames.
>
> The currently proposed solution is to add a way to configure the 
> hostname for the Keycloak server. However, this is an extra 
> configuration requirement and is also a significant amount of work to 
> implement as well as potentially quite error prone. This could further 
> be problematic if there is indeed two valid URLs for a server (for 
> example http://company.com and http://internal.company.com).
>
> We should simply remove auth-server-url-for-backend-requests. If 
> anyone wants to bypass the load balancer for internal machines that 
> should be solved at the DNS level or by adding entries to the host 
> file. As the hostname remains the same there's no need for multiple 
> certificates, nor is there a need to hardcode the address on the 
> Keycloak server itself.
>
>
> _______________________________________________
> 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/20160308/8942df88/attachment.html 

From sthorger at redhat.com  Tue Mar  8 03:50:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 09:50:48 +0100
Subject: [keycloak-dev] Remove auth-server-url-for-backend-requests from
	adapters
In-Reply-To: <56DE9099.2030703@redhat.com>
References: <CAJgngAc6uh7TfKYMT1BP=sCGUbe4Z4_nD2rBv5QaPdDJ14+2PA@mail.gmail.com>
	<56DE9099.2030703@redhat.com>
Message-ID: <CAJgngAcpX9dhbUKziqmNNOu3r5_Z5EOGcW8u+LOwmWouDc9Uww@mail.gmail.com>

On 8 March 2016 at 09:43, Marek Posolda <mposolda at redhat.com> wrote:

> +1 to remove it.
>
> We can always re-add or add something different if people start to
> complain ;-)
>
> I guess that earlier or later, we may still need a possibility to
> configure hostname for keycloak server. I think that there were people with
> funky deployments having issues even if they don't use
> auth-server-url-for-backend-requests. Other possibility instead of
> introduce hostname might be to introduce list of valid URLs on adapter
> side, which are acceptable as issuers of access token. But who knows, maybe
> everyone can somehow fix his deployment and we won't need anything :-)
>

I don't think we'll need it, nor do I think we need a list of valid URLs on
adapter side. It's a slippery slope to do that, both in terms of usability
and security. Token should be issued by a specific Keycloak server (and
hostname is important here) and a token issued by one Keycloak server with
one hostname is not equivalent of a token issued by another server.

If someone can't configure DNS or hostnames they'll just have to invoke it
through the reverse proxy or load balancer. In fact in a cluster you most
likely will have to go through the load balancer in either case.


>
>
> Marek
>
>
> On 08/03/16 09:08, Stian Thorgersen wrote:
>
> Currently we allow adapters to configure two urls for Keycloak
> (auth-server-url and auth-server-url-for-backend-requests). I propose we
> remove auth-server-url-for-backend-requests.
>
> The auth-server-url-for-backend-requests property was added as a way for
> adapters to invoke Keycloak directly without having to go through a load
> balancer or reverse proxy.
>
> The issue with auth-server-url-for-backend-requests is that the Keycloak
> server will not know the adapter is invoking Keycloak from a different URL,
> which results in invalid URLs in tokens and also if any links are generated
> (for example verify email).
>
> It also means that there's a need to have two separate certificates
> configured for Keycloak as there are different hostnames.
>
> The currently proposed solution is to add a way to configure the hostname
> for the Keycloak server. However, this is an extra configuration
> requirement and is also a significant amount of work to implement as well
> as potentially quite error prone. This could further be problematic if
> there is indeed two valid URLs for a server (for example
> <http://company.com>http://company.com and http://internal.company.com).
>
> We should simply remove auth-server-url-for-backend-requests. If anyone
> wants to bypass the load balancer for internal machines that should be
> solved at the DNS level or by adding entries to the host file. As the
> hostname remains the same there's no need for multiple certificates, nor is
> there a need to hardcode the address on the Keycloak server itself.
>
>
> _______________________________________________
> 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/20160308/eed6fd7a/attachment.html 

From mposolda at redhat.com  Tue Mar  8 03:51:28 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 8 Mar 2016 09:51:28 +0100
Subject: [keycloak-dev] Support concurrent startup by more cluster nodes
In-Reply-To: <CAJgngAeCGQW+09Bc8kyd3qRkhqh7Enzn-U-zzp93qor+ejhKAA@mail.gmail.com>
References: <56DD520B.8060205@redhat.com>
	<CAJgngAdeRjG1rJ0jL4NSN=mGgpRFhzR=DycYtLNqv2yxr6C5MQ@mail.gmail.com>
	<56DDEBC2.8080302@redhat.com>
	<CAJgngAfhB6T-Ts9d4NFj4LT2-sqh3CrJk9sMxe9x+ueZ=tezGg@mail.gmail.com>
	<56DE8BB4.1020206@redhat.com>
	<CAJgngAeCGQW+09Bc8kyd3qRkhqh7Enzn-U-zzp93qor+ejhKAA@mail.gmail.com>
Message-ID: <56DE9290.7020804@redhat.com>

On 08/03/16 09:41, Stian Thorgersen wrote:
> I actually think the chance of someone killing it during upgrade is 
> relatively high. It could be they forgot to include bind address or 
> used wrong server config. It could be migration takes longer than they 
> expect. We shouldn't require users to manually unlock.
>
> The lock should be done in association with the transaction. JPA 
> provides pessimistic locks so you can do:
>
> DatabaseLockEntity lock = em.find(DatabaseLockEntity.class, "lock", 
> LockModeType.PESSIMISTIC_WRITE);
Ok, I will take a look at this possibility and if reliably works with 
all databases. However it will take some time though...

Marek
>
> That will work for all databases (except Mongo of course). If the 
> process dies the transaction will timeout and it's safe to run again 
> at that point because no chances would have been committed to the db.
>
>
>
> On 8 March 2016 at 09:22, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 08/03/16 06:48, Stian Thorgersen wrote:
>>     What about obtaining a database lock on a table/column? That
>>     would automatically be freed if the transaction dies.
>     You mean something like "Give me lock for table XY until end of
>     transaction" ? I doubt there is some universal solution for
>     something like this, which will reliably work with all databases
>     which we need to support :/ Otherwise I guess liquibase would
>     already use it too?
>
>     Currently it works the way that lock is obtained by updating the
>     column in database. Something similar to "UPDATE
>     DATABASECHANGELOGLOCK set LOCKED=true where ID=1" .
>     Note there is always single record in this table with ID=1.
>     Something similar is done for Mongo too.
>
>     The lock is released in "finally" block if something fails. The
>     only possibility how can DB remains locked is if someone force to
>     kill the process (like "kill -9" command, then finally blocks are
>     not called) or if network connection between server and DB is
>     lost. The chance of this is very low IMO and we have option to
>     manually recover from this.
>
>     Marek
>
>>
>>     -1 To having a timeout, I agree it's dangerous and could leave
>>     the DB inconsistent so we shouldn't do it
>>
>>     On 7 March 2016 at 21:59, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Then the record in DB will remain locked and needs to be
>>         fixed manually. Actually the same behaviour like liquibase.
>>         The possibilities to repair from this state is:
>>         - Run keycloak with system property
>>         "-Dkeycloak.dblock.forceUnlock=true" . Then Keycloak will
>>         release the existing lock at startup and acquire new lock.
>>         The warning is written to server.log that this property
>>         should be used carefully just to repair DB
>>         - Manually delete lock record from DATABASECHANGELOGLOCK
>>         table (or "dblock" collection in mongo)
>>
>>         The other possibility is that after timeout, node2 will
>>         assume the current lock is timed-out and will forcefully
>>         release existing lock and replace with it's own lock. However
>>         I didn't it this way as it's potentially dangerous though -
>>         there is some chance that 2 nodes run migration or import at
>>         the same time and DB will end in inconsistent state. Or is it
>>         acceptable risk?
>>
>>         Marek
>>
>>
>>
>>         On 07/03/16 19:50, Stian Thorgersen wrote:
>>>         900 seconds is probably ok, but what happens if the node
>>>         holding the lock dies?
>>>
>>>         On 7 March 2016 at 11:03, Marek Posolda <mposolda at redhat.com
>>>         <mailto:mposolda at redhat.com>> wrote:
>>>
>>>             Send PR with added support for $subject .
>>>             https://github.com/keycloak/keycloak/pull/2332 .
>>>
>>>             Few details:
>>>             - Added DBLockProvider, which handles acquire and
>>>             release of DB lock.
>>>             When lock is acquired, the cluster node2 needs to wait
>>>             until node1
>>>             release the lock
>>>
>>>             - The lock is acquired at startup for the migrating
>>>             model (both model
>>>             specific and generic migration), importing realms and
>>>             adding initial
>>>             admin user. So this can be done always just by one node
>>>             at a time.
>>>
>>>             - The lock is implemented at DB level, so it works even
>>>             if infinispan
>>>             cluster is not correctly configured. For the JPA, I've added
>>>             implementation, which is reusing liquibase DB locking
>>>             with the bugfix,
>>>             which prevented builtin liquibase lock to work
>>>             correctly. I've added
>>>             implementation for Mongo too.
>>>
>>>             - Added DBLockTest, which simulates 20 threads racing
>>>             for acquire lock
>>>             concurrently. It's passing with all databases.
>>>
>>>             - Default timeout for acquire lock is 900 seconds and
>>>             the time for lock
>>>             recheck is 2 seconds. So if node2 is not able to acquire
>>>             lock within 900
>>>             seconds, it fails to start. There is possibility to
>>>             change in
>>>             keycloak-server.json. Is 900 seconds too much? I was
>>>             thinking about the
>>>             case when there is some large realm file importing at
>>>             startup.
>>>
>>>             Marek
>>>             _______________________________________________
>>>             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/20160308/fcca78d6/attachment-0001.html 

From sthorger at redhat.com  Tue Mar  8 08:37:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 14:37:29 +0100
Subject: [keycloak-dev] Keycloak 1.9.1.Final testing time
Message-ID: <CAJgngAeg89oW8rLtXxihOQMjiJNhgBcCceTd2Xq9nfVTMZjJ3g@mail.gmail.com>

We're ready to start testing for 1.9.1.Final release. The aim is to release
tomorrow.

As usual the testing spreadsheet is:
https://docs.google.com/spreadsheets/d/1uK46z0zQ1bkZi8cQxxF9czQPZ5NPd1jF9R3j-TNV7VY

Build the 1.9.x branch, not master, for testing. For any fixes send PR to
both 1.9.x and master. If you discover any bugs during testing it's only a
priority to fix if it's a regression, otherwise set fix version to 1.9.2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160308/3bf9d855/attachment.html 

From jdennis at redhat.com  Tue Mar  8 09:00:46 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 8 Mar 2016 09:00:46 -0500
Subject: [keycloak-dev] client creation using bearer token
In-Reply-To: <CAJgngAfG07GfbkyQyqWz2jex0XyOK8DvFNw5ueHWa1SMsVFjag@mail.gmail.com>
References: <56DE1970.4090208@redhat.com>
	<CAJgngAfG07GfbkyQyqWz2jex0XyOK8DvFNw5ueHWa1SMsVFjag@mail.gmail.com>
Message-ID: <56DEDB0E.8000300@redhat.com>

On 03/08/2016 12:51 AM, Stian Thorgersen wrote:
> Client registration service can only be invoked by a user from the realm
> you are creating a client in, so users in the master realm can only
> create clients in the master realm.
>
> IMO you should use the client registration services, supported initial
> access tokens and leave realm creation to another process. Creating a
> realm is part of installing the Keycloak server, not installing the client.

I'm not asking about realm creation. Rather I'm following up on your 
suggestion from a couple of days ago where you said instead of using an 
an initial access token:

 > You can also invoke it with the same access token 
(http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html#d4e1458)

This why I referenced Chapter 9.1.1 where it says a bearer token can be 
used to register the client. So my question is how does one do that?

Here are the reasons why I'm pursuing this approach:

* A process which creates a client in a realm should only have 
privileges in the realm, anything that requires super admin privileges 
on the master realm compromises the security of other realms hosted on 
the Keycloak instance (principle of least privilege).

* Initial access tokens make automated provisioning difficult. But more 
to the point far as I can tell using an initial access token still 
requires super admin privileges at some point in the process. Either a 
super admin (human) has to logon to the web UI and copy the initial 
access token into a file for later use (and possibly exposing) or a 
process with super admin privileges has to create an initial access 
token via the REST interface.

Remember the goal here is automated stand-alone provisioning (e.g. via 
ansible or puppet) of realm specific clients *without* super admin 
privileges that could compromise other realms (principle of least 
privilege). This suggests there should be a realm specific admin who can 
register a client (this is the fundamental question at hand).

Thus what I was trying to resolve was how to have a realm specific admin 
who can only administer the realm. Initially I tried to create a user in 
the realm and grant them the necessary administration roles but I was 
unable to get a bearer token for that user using the realm token 
endpoint and passing their credentials. Then I went back re-read the 
documentation on administration privileges (cited below) which states 
realm administrators must be users in the master realm hence a realm 
administrator cannot use their bearer token to register a client because 
cross realm tokens are prohibited.

Does this now make more sense?

>
> On 8 March 2016 at 01:14, John Dennis <jdennis at redhat.com
> <mailto:jdennis at redhat.com>> wrote:
>
>     Chapter 9.1.1 of the Keycloak Reference Guide
>     (http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
>     says that a bearer token can be used to register a client provided the
>     user has the create-client or manage-client role on the realm.
>
>     Chapter 6 discusses how to create a user in the master realm who can
>     administer a specific realm. I followed those instructions and created
>     a user and assigned them the create-client role in the desired realm.
>
>     I then obtained a token for that user by posting to
>     auth/realms/master/protocol/openid-connect/token with the username and
>     password for the realm administrator I created along with the
>     client-id of "admin-cli" (not sure if this is the right client id for
>     this purpose, can someone explain selecting the proper client id?).
>
>     I received back a token and then used this as an authorization bearer
>     token when POSTing to the
>     auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
>     SP client in the realm. However this fails with an 403 Forbidden
>     response and the message "Invalid signature".
>
>     This error seems to be generated by the ClientRegistrationTokenUtils
>     class in the method parseToken() which is called in the init() method
>     of the ClientRegistrationAuth class. As far as I can tell the
>     parseToken() method is using the public key for the realm. But the
>     token is not from the realm, the token is from the master realm where
>     the realm's admin is located.
>
>     For the bearer token to work when registering a client it would seem
>     the token would have belong to a user in the realm, not the master
>     realm as discussed in Chapter 6.
>
>     How is client creation supposed to work with a bearer token instead of
>     using an initial access token?
>
>     --
>     John
>     _______________________________________________
>     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
>
>


-- 
John

From sthorger at redhat.com  Tue Mar  8 09:21:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 8 Mar 2016 15:21:17 +0100
Subject: [keycloak-dev] client creation using bearer token
In-Reply-To: <56DEDB0E.8000300@redhat.com>
References: <56DE1970.4090208@redhat.com>
	<CAJgngAfG07GfbkyQyqWz2jex0XyOK8DvFNw5ueHWa1SMsVFjag@mail.gmail.com>
	<56DEDB0E.8000300@redhat.com>
Message-ID: <CAJgngAe4VSMmXNGdEePeRkMmN96P9FkM_a7j1CT=+B8Mjv09FQ@mail.gmail.com>

On 8 March 2016 at 15:00, John Dennis <jdennis at redhat.com> wrote:

> On 03/08/2016 12:51 AM, Stian Thorgersen wrote:
>
>> Client registration service can only be invoked by a user from the realm
>> you are creating a client in, so users in the master realm can only
>> create clients in the master realm.
>>
>> IMO you should use the client registration services, supported initial
>> access tokens and leave realm creation to another process. Creating a
>> realm is part of installing the Keycloak server, not installing the
>> client.
>>
>
> I'm not asking about realm creation. Rather I'm following up on your
> suggestion from a couple of days ago where you said instead of using an an
> initial access token:
>
> > You can also invoke it with the same access token (
> http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html#d4e1458
> )
>
> This why I referenced Chapter 9.1.1 where it says a bearer token can be
> used to register the client. So my question is how does one do that?
>
> Here are the reasons why I'm pursuing this approach:
>
> * A process which creates a client in a realm should only have privileges
> in the realm, anything that requires super admin privileges on the master
> realm compromises the security of other realms hosted on the Keycloak
> instance (principle of least privilege).
>
> * Initial access tokens make automated provisioning difficult. But more to
> the point far as I can tell using an initial access token still requires
> super admin privileges at some point in the process. Either a super admin
> (human) has to logon to the web UI and copy the initial access token into a
> file for later use (and possibly exposing) or a process with super admin
> privileges has to create an initial access token via the REST interface.
>
> Remember the goal here is automated stand-alone provisioning (e.g. via
> ansible or puppet) of realm specific clients *without* super admin
> privileges that could compromise other realms (principle of least
> privilege). This suggests there should be a realm specific admin who can
> register a client (this is the fundamental question at hand).
>
> Thus what I was trying to resolve was how to have a realm specific admin
> who can only administer the realm. Initially I tried to create a user in
> the realm and grant them the necessary administration roles but I was
> unable to get a bearer token for that user using the realm token endpoint
> and passing their credentials. Then I went back re-read the documentation
> on administration privileges (cited below) which states realm
> administrators must be users in the master realm hence a realm
> administrator cannot use their bearer token to register a client because
> cross realm tokens are prohibited.
>
> Does this now make more sense?
>

Yep, I wrongly made the assumption that you wanted to use the same token to
create a realm and to create the client.

We need to figure out a way to provision initial access tokens or another
way to permit usage of client registration services, as using a user or
service account for it doesn't make to much sense.

In the mean time I'd use a service account rather than a regular user. Then
use the client credentials grant to obtain the token. The service account
only needs a role mapping on the create-client role from the
realm-management client. That way it'll only be able to create clients for
a specific realm and nothing else.


>
>
>> On 8 March 2016 at 01:14, John Dennis <jdennis at redhat.com
>> <mailto:jdennis at redhat.com>> wrote:
>>
>>     Chapter 9.1.1 of the Keycloak Reference Guide
>>     (
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/index.html)
>>     says that a bearer token can be used to register a client provided the
>>     user has the create-client or manage-client role on the realm.
>>
>>     Chapter 6 discusses how to create a user in the master realm who can
>>     administer a specific realm. I followed those instructions and created
>>     a user and assigned them the create-client role in the desired realm.
>>
>>     I then obtained a token for that user by posting to
>>     auth/realms/master/protocol/openid-connect/token with the username and
>>     password for the realm administrator I created along with the
>>     client-id of "admin-cli" (not sure if this is the right client id for
>>     this purpose, can someone explain selecting the proper client id?).
>>
>>     I received back a token and then used this as an authorization bearer
>>     token when POSTing to the
>>     auth/realms/{realm}/clients/saml2-entity-descriptor to create a SAML
>>     SP client in the realm. However this fails with an 403 Forbidden
>>     response and the message "Invalid signature".
>>
>>     This error seems to be generated by the ClientRegistrationTokenUtils
>>     class in the method parseToken() which is called in the init() method
>>     of the ClientRegistrationAuth class. As far as I can tell the
>>     parseToken() method is using the public key for the realm. But the
>>     token is not from the realm, the token is from the master realm where
>>     the realm's admin is located.
>>
>>     For the bearer token to work when registering a client it would seem
>>     the token would have belong to a user in the realm, not the master
>>     realm as discussed in Chapter 6.
>>
>>     How is client creation supposed to work with a bearer token instead of
>>     using an initial access token?
>>
>>     --
>>     John
>>     _______________________________________________
>>     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
>>
>>
>>
>
> --
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160308/563051d2/attachment.html 

From josh.cain at redhat.com  Tue Mar  8 12:41:39 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Tue, 8 Mar 2016 11:41:39 -0600
Subject: [keycloak-dev] Required Action Config?
Message-ID: <CA+z0A8AuooGgW4=Jq+weAtUG4zM=4wc0S7v0Fm94tDJ5Wy5pUw@mail.gmail.com>

Hi all,

I'm working on a required action that needs a bit of configuration.  I'd
ideally like to manage this in the same way that I manage my current
federation provider/authenticator SPI implementations, but I don't see a
way to do so.  Is there a way to configure these via Keycloak?

If not, I'm considering just writing said action as an authenticator and
including it in the authentication flow.  Would there be any downsides to
this approach?

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160308/43f06d4d/attachment-0001.html 

From sthorger at redhat.com  Wed Mar  9 00:54:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 9 Mar 2016 06:54:16 +0100
Subject: [keycloak-dev] Required Action Config?
In-Reply-To: <CA+z0A8AuooGgW4=Jq+weAtUG4zM=4wc0S7v0Fm94tDJ5Wy5pUw@mail.gmail.com>
References: <CA+z0A8AuooGgW4=Jq+weAtUG4zM=4wc0S7v0Fm94tDJ5Wy5pUw@mail.gmail.com>
Message-ID: <CAJgngAfuESh1KMWPhHajAzjyAwbTtbSZiaf3K-ZwpacrL195GA@mail.gmail.com>

You can create a JIRA for the ability to have configurable required
actions. That won't be until 2.x though.

Using an authenticator instead has the downside that it can't be assigned
as a default action, nor can it be assigned to a selected user. I can't see
any other immediate downsides. You could for instance have an attribute on
a user that determines if the action should be executed or not though.

On 8 March 2016 at 18:41, Josh Cain <josh.cain at redhat.com> wrote:

> Hi all,
>
> I'm working on a required action that needs a bit of configuration.  I'd
> ideally like to manage this in the same way that I manage my current
> federation provider/authenticator SPI implementations, but I don't see a
> way to do so.  Is there a way to configure these via Keycloak?
>
> If not, I'm considering just writing said action as an authenticator and
> including it in the authentication flow.  Would there be any downsides to
> this approach?
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735
>
> _______________________________________________
> 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/20160309/ef13c085/attachment.html 

From sthorger at redhat.com  Wed Mar  9 14:26:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 9 Mar 2016 20:26:46 +0100
Subject: [keycloak-dev] Keycloak 1.9.1.Final Released
Message-ID: <CAJgngAd7rSFjN8joASk2D8kFyoXc90ypTE2jfbb-8hW3HB0JHg@mail.gmail.com>

For the full list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.1.Final>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160309/cba1f88b/attachment.html 

From thomas.darimont at googlemail.com  Wed Mar  9 17:49:00 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 9 Mar 2016 23:49:00 +0100
Subject: [keycloak-dev] Required Action Config?
In-Reply-To: <CAJgngAfuESh1KMWPhHajAzjyAwbTtbSZiaf3K-ZwpacrL195GA@mail.gmail.com>
References: <CA+z0A8AuooGgW4=Jq+weAtUG4zM=4wc0S7v0Fm94tDJ5Wy5pUw@mail.gmail.com>
	<CAJgngAfuESh1KMWPhHajAzjyAwbTtbSZiaf3K-ZwpacrL195GA@mail.gmail.com>
Message-ID: <CAK-7U1i0aFSnzOP3Ld=qP-mjSYYaSB94jXM0xzHY_Bk8ALcOTg@mail.gmail.com>

I saw that the RequiredActionProviderRepresentation &
RequiredActionProviderModel already
provide a Map<String,String> config to store additional config settings.

Would it be enough to expose this RequiredActions configuration in the same
way it is done
in the AuthenticationFlows via "actions -> config" in the admin console?

Cheers,
Thomas


2016-03-09 6:54 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> You can create a JIRA for the ability to have configurable required
> actions. That won't be until 2.x though.
>
> Using an authenticator instead has the downside that it can't be assigned
> as a default action, nor can it be assigned to a selected user. I can't see
> any other immediate downsides. You could for instance have an attribute on
> a user that determines if the action should be executed or not though.
>
> On 8 March 2016 at 18:41, Josh Cain <josh.cain at redhat.com> wrote:
>
>> Hi all,
>>
>> I'm working on a required action that needs a bit of configuration.  I'd
>> ideally like to manage this in the same way that I manage my current
>> federation provider/authenticator SPI implementations, but I don't see a
>> way to do so.  Is there a way to configure these via Keycloak?
>>
>> If not, I'm considering just writing said action as an authenticator and
>> including it in the authentication flow.  Would there be any downsides to
>> this approach?
>>
>> Josh Cain | Software Applications Engineer
>> *Identity and Access Management*
>> *Red Hat*
>> +1 843-737-1735
>>
>> _______________________________________________
>> 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/20160309/7031a50f/attachment.html 

From sthorger at redhat.com  Thu Mar 10 02:21:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 10 Mar 2016 08:21:50 +0100
Subject: [keycloak-dev] master and 1.9.x branches
Message-ID: <CAJgngAd3OFoqNqj5C9-mqXQTWs9z++Jc8Hbdyuyb5TsOVPR3mg@mail.gmail.com>

Master is now ready to accept new features for 2.0.0.CR1. We won't be
adding any new features ourselves at the moment as our focus is testing and
bug fixing on 1.9.x. It's primarily intended for external contributions.

1.9.x branch is ready for fixes for 1.9.2.Final. At this point we should be
very careful about any changes to prevent regressions. We are NOT adding
any new features (unless acked by PM, QE, EM and project lead) in 1.9.x. We
also are going to be very careful about fixes and improvements to include
in 1.9.

JIRA issues will have fix version 1.9.2.Final and/or 2.0.0.CR1. If fix
version is only 2.0.0.CR1 then send PR to master. If fix version
is 1.9.2.Final and 2.0.0.CR1 send to both master and 1.9.x. My personal
flow for this is fix in master, then use "git cherry-pick <commit>" to add
to 1.9.x branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160310/287b71fb/attachment.html 

From sthorger at redhat.com  Thu Mar 10 02:29:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 10 Mar 2016 08:29:57 +0100
Subject: [keycloak-dev] Commits/PRs
Message-ID: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>

Please squash commits. The ideal is one commit and one PR per JIRA issue.
If you want to break a JIRA issue into smaller tasks then please create
sub-tasks in JIRA, then do one commit/PR for one sub-task.

Always include JIRA key in the commit message. A good commit message look
example is:
----
KEYCLOAK-1267 add a separate sso_max_lifespan parameter for remember me
----

We have automated linking of PRs in JIRA as long as the JIRA key is
included in the commit message. It doesn't hurt to manually link as this is
generally quicker.

With JIRA key in commit and PRs linked in JIRA we get a good history that
is useful in the future to identify what was changed and why. It's also
important that this history goes both ways. For example if you don't
include JIRA key in commit it's very difficult to find the associated JIRA
issue. If you didn't even link the PR then it's pretty much impossible.

All commits to main repository should be done through PRs, no direct
pushing to repository please.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160310/a9348679/attachment.html 

From bburke at redhat.com  Thu Mar 10 13:03:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 10 Mar 2016 13:03:52 -0500
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
Message-ID: <56E1B708.3050902@redhat.com>

Is there a way to automatically squash everything to your latest 
commit?   FYI, I just screed up the rebase so I have included like 30 
commits in my PR.

On 3/10/2016 2:29 AM, Stian Thorgersen wrote:
> Please squash commits. The ideal is one commit and one PR per JIRA 
> issue. If you want to break a JIRA issue into smaller tasks then 
> please create sub-tasks in JIRA, then do one commit/PR for one sub-task.
>
> Always include JIRA key in the commit message. A good commit message 
> look example is:
> ----
> KEYCLOAK-1267 add a separate sso_max_lifespan parameter for remember me
> ----
>
> We have automated linking of PRs in JIRA as long as the JIRA key is 
> included in the commit message. It doesn't hurt to manually link as 
> this is generally quicker.
>
> With JIRA key in commit and PRs linked in JIRA we get a good history 
> that is useful in the future to identify what was changed and why. 
> It's also important that this history goes both ways. For example if 
> you don't include JIRA key in commit it's very difficult to find the 
> associated JIRA issue. If you didn't even link the PR then it's pretty 
> much impossible.
>
> All commits to main repository should be done through PRs, no direct 
> pushing to repository please.
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160310/20ba3b36/attachment-0001.html 

From jdennis at redhat.com  Thu Mar 10 13:12:31 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 10 Mar 2016 13:12:31 -0500
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E1B708.3050902@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com>
Message-ID: <56E1B90F.3060507@redhat.com>

On 03/10/2016 01:03 PM, Bill Burke wrote:
> Is there a way to automatically squash everything to your latest
> commit?

Maybe not automatically, but the conventional way to squash commits is 
with interactive rebase, e.g.

% git rebase -i commit

where commit is the commit id of the *prior* commit you want to start 
the squashing from. Git will fire up your defined editor and you just 
replace the pick keyword with the squash keyword for each commit to be 
squashed. Many examples on the web. It's not automatic but usually less 
than a minute from start to finish.

HTH,

-- 
John

From ppalaga at redhat.com  Thu Mar 10 16:17:38 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 10 Mar 2016 22:17:38 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E1B90F.3060507@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
Message-ID: <56E1E472.6000304@redhat.com>

Hi Stian,

just a few minor points. Please note that I am speaking primarily from 
the standpoint of somebody who often looks into the history of KC 
branches, because Hawkular (where I am primarily active) uses KC. I am 
not a regular contributor to KC.

(1)
 > With JIRA key in commit and PRs linked in JIRA we get a good history
 > that is useful in the future to identify what was changed and why.

To see *what* was changed, I do not need to go to Jira. Git history is 
the ultimate source of that info.

As for the *why*, the project has to coin some convention. From what you 
say it seems that it should be Jira, right? Yes, that is one of the 
legitimate choices, but not the only possible one. Git commit messages 
may serve the purpose too and I personally find them much more practical 
because they are much closer to where I usually start looking. Jira is 
usually one slooowly loading link further. Therefore, could you please 
explain why you find Jira better?

(2) I want tags in branches.
Your tags are outside branches (such as 1.9.x) and that makes it harder 
to clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. 
You are the second project doing it like this out of ~150 Java projects 
I have ever cloned.

Please consider tagging the usual way.

(3) While I agree that the linking between git history and Jira is 
useful, saying that every commit needs a Jira does not sound reasonable. 
There certainly are commits that do not deserve a Jira, such as:
* upgrades of dependencies
* refactorings
* various formatting and license header fixes
I hope most of you will agree here.

(4) Pro tip for Chrome users:
I created a content script that makes Jiras and BZs on GitHub clickable 
links. This is what it looks like: http://snag.gy/rq6Ja.jpg How to 
install: https://goo.gl/bYUbHS

Thanks,

Peter

On 2016-03-10 19:12, John Dennis wrote:
> On 03/10/2016 01:03 PM, Bill Burke wrote:
>> Is there a way to automatically squash everything to your latest
>> commit?
>
> Maybe not automatically, but the conventional way to squash commits is
> with interactive rebase, e.g.
>
> % git rebase -i commit
>
> where commit is the commit id of the *prior* commit you want to start
> the squashing from. Git will fire up your defined editor and you just
> replace the pick keyword with the squash keyword for each commit to be
> squashed. Many examples on the web. It's not automatic but usually less
> than a minute from start to finish.
>
> HTH,
>


From sthorger at redhat.com  Fri Mar 11 00:53:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Mar 2016 06:53:47 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E1E472.6000304@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
Message-ID: <CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>

On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi Stian,
>
> just a few minor points. Please note that I am speaking primarily from the
> standpoint of somebody who often looks into the history of KC branches,
> because Hawkular (where I am primarily active) uses KC. I am not a regular
> contributor to KC.
>
> (1)
> > With JIRA key in commit and PRs linked in JIRA we get a good history
> > that is useful in the future to identify what was changed and why.
>
> To see *what* was changed, I do not need to go to Jira. Git history is the
> ultimate source of that info.
>
> As for the *why*, the project has to coin some convention. From what you
> say it seems that it should be Jira, right? Yes, that is one of the
> legitimate choices, but not the only possible one. Git commit messages may
> serve the purpose too and I personally find them much more practical
> because they are much closer to where I usually start looking. Jira is
> usually one slooowly loading link further. Therefore, could you please
> explain why you find Jira better?
>

One isn't better than the other. They serve different purposes. Git commit
messages will tell you what code was changed, while JIRA descriptions will
tell you why it was changed. Both are equally important. Making sure you
can go from a JIRA issue to Git commits and the other way around are both
important. Imagine two examples:

* A user searches for a bug in JIRA to see if the problem he's having has
been resolved. He finds the issue and wants to take a look at what changes
was made to understand it better.
* A developer finds some code he wrote 12 months ago was changed, looks at
Git history to see who did it, but has no idea why. He then sees the JIRA
key in the commit message and opens it in JIRA. There he finds a lengthy
description of the bug, including several comments.


>
> (2) I want tags in branches.
> Your tags are outside branches (such as 1.9.x) and that makes it harder to
> clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. You are
> the second project doing it like this out of ~150 Java projects I have ever
> cloned.
>
> Please consider tagging the usual way.
>

You've certainly cloned more repositories than I have.. I'm not sure what
you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
Can you elaborate?


>
> (3) While I agree that the linking between git history and Jira is useful,
> saying that every commit needs a Jira does not sound reasonable. There
> certainly are commits that do not deserve a Jira, such as:
> * upgrades of dependencies
> * refactorings
> * various formatting and license header fixes
> I hope most of you will agree here.
>

I disagree, I want a complete record of what's been done in JIRA. Upgrading
of dependencies should not just be done randomly. It has a reasoning behind
it (for example a security fix, or to re-allign with WF dependencies, or
whatever) without a JIRA you don't have that. Same goes for refactoring,
they either should be done as part of an existing JIRA or there should be a
JIRA describing why it was done. The work has to be scheduled the same as
all other work.

For minor documentation updates (grammar, spelling fixes, etc.) or minor
pure formatting sure they don't need a JIRA.

All rules come with exceptions, that's just the way of life. However, by
defacto all commits should have an associated JIRA. That's even more
important for external contributions.


>
> (4) Pro tip for Chrome users:
> I created a content script that makes Jiras and BZs on GitHub clickable
> links. This is what it looks like: http://snag.gy/rq6Ja.jpg How to
> install: https://goo.gl/bYUbHS
>
> Thanks,
>
> Peter
>
>
> On 2016-03-10 19:12, John Dennis wrote:
>
>> On 03/10/2016 01:03 PM, Bill Burke wrote:
>>
>>> Is there a way to automatically squash everything to your latest
>>> commit?
>>>
>>
>> Maybe not automatically, but the conventional way to squash commits is
>> with interactive rebase, e.g.
>>
>> % git rebase -i commit
>>
>> where commit is the commit id of the *prior* commit you want to start
>> the squashing from. Git will fire up your defined editor and you just
>> replace the pick keyword with the squash keyword for each commit to be
>> squashed. Many examples on the web. It's not automatic but usually less
>> than a minute from start to finish.
>>
>> HTH,
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/051dbd5d/attachment.html 

From ppalaga at redhat.com  Fri Mar 11 08:45:50 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Fri, 11 Mar 2016 14:45:50 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
Message-ID: <56E2CC0E.809@redhat.com>

Hi Stian, inline...

On 2016-03-11 06:53, Stian Thorgersen wrote:
>
>
> On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com 
> <mailto:ppalaga at redhat.com>> wrote:
>
>     Hi Stian,
>
>     just a few minor points. Please note that I am speaking primarily
>     from the standpoint of somebody who often looks into the history
>     of KC branches, because Hawkular (where I am primarily active)
>     uses KC. I am not a regular contributor to KC.
>
>     (1)
>     > With JIRA key in commit and PRs linked in JIRA we get a good history
>     > that is useful in the future to identify what was changed and why.
>
>     To see *what* was changed, I do not need to go to Jira. Git
>     history is the ultimate source of that info.
>
>     As for the *why*, the project has to coin some convention. From
>     what you say it seems that it should be Jira, right? Yes, that is
>     one of the legitimate choices, but not the only possible one. Git
>     commit messages may serve the purpose too and I personally find
>     them much more practical because they are much closer to where I
>     usually start looking. Jira is usually one slooowly loading link
>     further. Therefore, could you please explain why you find Jira better?
>
>
> One isn't better than the other. They serve different purposes. Git 
> commit messages will tell you what code was changed, while JIRA 
> descriptions will tell you why it was changed. Both are equally 
> important. Making sure you can go from a JIRA issue to Git commits and 
> the other way around are both important. Imagine two examples:
>
> * A user searches for a bug in JIRA to see if the problem he's having 
> has been resolved. He finds the issue and wants to take a look at what 
> changes was made to understand it better.
Yes, I fully agree that the linking from Jira to GitHub makes sense.
> * A developer finds some code he wrote 12 months ago was changed, 
> looks at Git history to see who did it, but has no idea why. He then 
> sees the JIRA key in the commit message and opens it in JIRA. There he 
> finds a lengthy description of the bug, including several comments.
No, the explanation why the given commit was necessary may well be 
placed in the commit message itself. In many projects, this is the 
default place for that kind of info. Now, given that the motivation for 
the change can be described in the commit message, the overhead of 
creating a Jira needs to be justified. Writing the "why" to the commit 
message is much faster and more developer friendly than forcing 
contributors to create a Jira for every trivial improvement. I can say 
for myself that having to create a JIra before fixing some stupid bug 
substantially lowers my readiness to fix it at all.

> The work has to be scheduled the same as all other work.
Yes, planning is fully legitimate within your team paid for the work but 
again, it sounds rather discouraging to me, an external contributor, 
when I just want to fix a malfunction in KC that blocks my primary task.

>
>     (2) I want tags in branches.
>     Your tags are outside branches (such as 1.9.x) and that makes it
>     harder to clearly and quickly see what happened between e.g. 1.9.0
>     and 1.9.1. You are the second project doing it like this out of
>     ~150 Java projects I have ever cloned.
>
>     Please consider tagging the usual way.
>
>
> You've certainly cloned more repositories than I have.. I'm not sure 
> what you mean. 1.9.x tags has to come from 1.9.x branch as master is 
> now 2.x. Can you elaborate?
Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are 
*inside* a branch (master branch in this case):


To get the tags from upstream, I do not need to use --tags with git 
fetch, because the in-branch tags are fetched also without --tags. 
Furthermore I can clearly see what happened between the yellow labels 
0.17.Final and 0.16.Final.

OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x 
branch I get only this:


No tags there. Only some hints like "Next is 1.9.2" where the tags are 
perhaps around. Nevermind, I know I have to fetch with --tags:


Still no tags there, because they are out of the 1.9.x branch that I 
have checked out. To see them, I have to "Show all branches and tags" in 
egit. Sadly, that brings also master and other branches, that I do not 
want to see, but let's try to ignore them, and have a look at what 
happened between 1.9.0.Final and 1.9.1.Final:


While it is relatively easy to find out how 1.9.1.Final tag relates to 
1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a 
long fork of 1.9.x that I cannot track down visually at all. If 
1.9.0.Final and 1.9.1.Final tags were a part of 1.9.x history, my eyes 
would be much happier. That's it.

Thanks,

-- Peter
>
>
>     (3) While I agree that the linking between git history and Jira is
>     useful, saying that every commit needs a Jira does not sound
>     reasonable. There certainly are commits that do not deserve a
>     Jira, such as:
>     * upgrades of dependencies
>     * refactorings
>     * various formatting and license header fixes
>     I hope most of you will agree here.
>
>
> I disagree, I want a complete record of what's been done in JIRA. 
> Upgrading of dependencies should not just be done randomly. It has a 
> reasoning behind it (for example a security fix, or to re-allign with 
> WF dependencies, or whatever) without a JIRA you don't have that. Same 
> goes for refactoring, they either should be done as part of an 
> existing JIRA or there should be a JIRA describing why it was done. 
> The work has to be scheduled the same as all other work.
>
> For minor documentation updates (grammar, spelling fixes, etc.) or 
> minor pure formatting sure they don't need a JIRA.
>
> All rules come with exceptions, that's just the way of life. However, 
> by defacto all commits should have an associated JIRA. That's even 
> more important for external contributions.
>
>
>     (4) Pro tip for Chrome users:
>     I created a content script that makes Jiras and BZs on GitHub
>     clickable links. This is what it looks like:
>     http://snag.gy/rq6Ja.jpg How to install: https://goo.gl/bYUbHS
>
>     Thanks,
>
>     Peter
>
>
>     On 2016-03-10 19:12, John Dennis wrote:
>
>         On 03/10/2016 01:03 PM, Bill Burke wrote:
>
>             Is there a way to automatically squash everything to your
>             latest
>             commit?
>
>
>         Maybe not automatically, but the conventional way to squash
>         commits is
>         with interactive rebase, e.g.
>
>         % git rebase -i commit
>
>         where commit is the commit id of the *prior* commit you want
>         to start
>         the squashing from. Git will fire up your defined editor and
>         you just
>         replace the pick keyword with the squash keyword for each
>         commit to be
>         squashed. Many examples on the web. It's not automatic but
>         usually less
>         than a minute from start to finish.
>
>         HTH,
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iffagdhf.png
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icddedjg.png
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehadefhf.png
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: egdifcbj.png
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0007.png 

From bburke at redhat.com  Fri Mar 11 08:55:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Mar 2016 08:55:10 -0500
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E2CC0E.809@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
	<56E2CC0E.809@redhat.com>
Message-ID: <56E2CE3E.9040906@redhat.com>

unsubscribe.  This is about as interesting as code formatting rules.

On 3/11/2016 8:45 AM, Peter Palaga wrote:
> Hi Stian, inline...
>
> On 2016-03-11 06:53, Stian Thorgersen wrote:
>>
>>
>> On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com 
>> <mailto:ppalaga at redhat.com>> wrote:
>>
>>     Hi Stian,
>>
>>     just a few minor points. Please note that I am speaking primarily
>>     from the standpoint of somebody who often looks into the history
>>     of KC branches, because Hawkular (where I am primarily active)
>>     uses KC. I am not a regular contributor to KC.
>>
>>     (1)
>>     > With JIRA key in commit and PRs linked in JIRA we get a good
>>     history
>>     > that is useful in the future to identify what was changed and why.
>>
>>     To see *what* was changed, I do not need to go to Jira. Git
>>     history is the ultimate source of that info.
>>
>>     As for the *why*, the project has to coin some convention. From
>>     what you say it seems that it should be Jira, right? Yes, that is
>>     one of the legitimate choices, but not the only possible one. Git
>>     commit messages may serve the purpose too and I personally find
>>     them much more practical because they are much closer to where I
>>     usually start looking. Jira is usually one slooowly loading link
>>     further. Therefore, could you please explain why you find Jira
>>     better?
>>
>>
>> One isn't better than the other. They serve different purposes. Git 
>> commit messages will tell you what code was changed, while JIRA 
>> descriptions will tell you why it was changed. Both are equally 
>> important. Making sure you can go from a JIRA issue to Git commits 
>> and the other way around are both important. Imagine two examples:
>>
>> * A user searches for a bug in JIRA to see if the problem he's having 
>> has been resolved. He finds the issue and wants to take a look at 
>> what changes was made to understand it better.
> Yes, I fully agree that the linking from Jira to GitHub makes sense.
>> * A developer finds some code he wrote 12 months ago was changed, 
>> looks at Git history to see who did it, but has no idea why. He then 
>> sees the JIRA key in the commit message and opens it in JIRA. There 
>> he finds a lengthy description of the bug, including several comments.
> No, the explanation why the given commit was necessary may well be 
> placed in the commit message itself. In many projects, this is the 
> default place for that kind of info. Now, given that the motivation 
> for the change can be described in the commit message, the overhead of 
> creating a Jira needs to be justified. Writing the "why" to the commit 
> message is much faster and more developer friendly than forcing 
> contributors to create a Jira for every trivial improvement. I can say 
> for myself that having to create a JIra before fixing some stupid bug 
> substantially lowers my readiness to fix it at all.
>
>> The work has to be scheduled the same as all other work.
> Yes, planning is fully legitimate within your team paid for the work 
> but again, it sounds rather discouraging to me, an external 
> contributor, when I just want to fix a malfunction in KC that blocks 
> my primary task.
>
>>
>>     (2) I want tags in branches.
>>     Your tags are outside branches (such as 1.9.x) and that makes it
>>     harder to clearly and quickly see what happened between e.g.
>>     1.9.0 and 1.9.1. You are the second project doing it like this
>>     out of ~150 Java projects I have ever cloned.
>>
>>     Please consider tagging the usual way.
>>
>>
>> You've certainly cloned more repositories than I have.. I'm not sure 
>> what you mean. 1.9.x tags has to come from 1.9.x branch as master is 
>> now 2.x. Can you elaborate?
> Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final 
> are *inside* a branch (master branch in this case):
>
>
> To get the tags from upstream, I do not need to use --tags with git 
> fetch, because the in-branch tags are fetched also without --tags. 
> Furthermore I can clearly see what happened between the yellow labels 
> 0.17.Final and 0.16.Final.
>
> OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x 
> branch I get only this:
>
>
> No tags there. Only some hints like "Next is 1.9.2" where the tags are 
> perhaps around. Nevermind, I know I have to fetch with --tags:
>
>
> Still no tags there, because they are out of the 1.9.x branch that I 
> have checked out. To see them, I have to "Show all branches and tags" 
> in egit. Sadly, that brings also master and other branches, that I do 
> not want to see, but let's try to ignore them, and have a look at what 
> happened between 1.9.0.Final and 1.9.1.Final:
>
>
> While it is relatively easy to find out how 1.9.1.Final tag relates to 
> 1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a 
> long fork of 1.9.x that I cannot track down visually at all. If 
> 1.9.0.Final and 1.9.1.Final tags were a part of 1.9.x history, my eyes 
> would be much happier. That's it.
>
> Thanks,
>
> -- Peter
>>
>>
>>     (3) While I agree that the linking between git history and Jira
>>     is useful, saying that every commit needs a Jira does not sound
>>     reasonable. There certainly are commits that do not deserve a
>>     Jira, such as:
>>     * upgrades of dependencies
>>     * refactorings
>>     * various formatting and license header fixes
>>     I hope most of you will agree here.
>>
>>
>> I disagree, I want a complete record of what's been done in JIRA. 
>> Upgrading of dependencies should not just be done randomly. It has a 
>> reasoning behind it (for example a security fix, or to re-allign with 
>> WF dependencies, or whatever) without a JIRA you don't have that. 
>> Same goes for refactoring, they either should be done as part of an 
>> existing JIRA or there should be a JIRA describing why it was done. 
>> The work has to be scheduled the same as all other work.
>>
>> For minor documentation updates (grammar, spelling fixes, etc.) or 
>> minor pure formatting sure they don't need a JIRA.
>>
>> All rules come with exceptions, that's just the way of life. However, 
>> by defacto all commits should have an associated JIRA. That's even 
>> more important for external contributions.
>>
>>
>>     (4) Pro tip for Chrome users:
>>     I created a content script that makes Jiras and BZs on GitHub
>>     clickable links. This is what it looks like:
>>     http://snag.gy/rq6Ja.jpg How to install: https://goo.gl/bYUbHS
>>
>>     Thanks,
>>
>>     Peter
>>
>>
>>     On 2016-03-10 19:12, John Dennis wrote:
>>
>>         On 03/10/2016 01:03 PM, Bill Burke wrote:
>>
>>             Is there a way to automatically squash everything to your
>>             latest
>>             commit?
>>
>>
>>         Maybe not automatically, but the conventional way to squash
>>         commits is
>>         with interactive rebase, e.g.
>>
>>         % git rebase -i commit
>>
>>         where commit is the commit id of the *prior* commit you want
>>         to start
>>         the squashing from. Git will fire up your defined editor and
>>         you just
>>         replace the pick keyword with the squash keyword for each
>>         commit to be
>>         squashed. Many examples on the web. It's not automatic but
>>         usually less
>>         than a minute from start to finish.
>>
>>         HTH,
>>
>>
>>
>
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/attachment-0007.png 

From sthorger at redhat.com  Fri Mar 11 08:57:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Mar 2016 14:57:47 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E2CC0E.809@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
	<56E2CC0E.809@redhat.com>
Message-ID: <CAJgngAfeW=qt24RPUO=icbARs2bZFaERDYHogTq4c36i6psFvg@mail.gmail.com>

On 11 March 2016 at 14:45, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi Stian, inline...
>
> On 2016-03-11 06:53, Stian Thorgersen wrote:
>
>
>
> On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com> wrote:
>
>> Hi Stian,
>>
>> just a few minor points. Please note that I am speaking primarily from
>> the standpoint of somebody who often looks into the history of KC branches,
>> because Hawkular (where I am primarily active) uses KC. I am not a regular
>> contributor to KC.
>>
>> (1)
>> > With JIRA key in commit and PRs linked in JIRA we get a good history
>> > that is useful in the future to identify what was changed and why.
>>
>> To see *what* was changed, I do not need to go to Jira. Git history is
>> the ultimate source of that info.
>>
>> As for the *why*, the project has to coin some convention. From what you
>> say it seems that it should be Jira, right? Yes, that is one of the
>> legitimate choices, but not the only possible one. Git commit messages may
>> serve the purpose too and I personally find them much more practical
>> because they are much closer to where I usually start looking. Jira is
>> usually one slooowly loading link further. Therefore, could you please
>> explain why you find Jira better?
>>
>
> One isn't better than the other. They serve different purposes. Git commit
> messages will tell you what code was changed, while JIRA descriptions will
> tell you why it was changed. Both are equally important. Making sure you
> can go from a JIRA issue to Git commits and the other way around are both
> important. Imagine two examples:
>
> * A user searches for a bug in JIRA to see if the problem he's having has
> been resolved. He finds the issue and wants to take a look at what changes
> was made to understand it better.
>
> Yes, I fully agree that the linking from Jira to GitHub makes sense.
>
> * A developer finds some code he wrote 12 months ago was changed, looks at
> Git history to see who did it, but has no idea why. He then sees the JIRA
> key in the commit message and opens it in JIRA. There he finds a lengthy
> description of the bug, including several comments.
>
> No, the explanation why the given commit was necessary may well be placed
> in the commit message itself. In many projects, this is the default place
> for that kind of info. Now, given that the motivation for the change can be
> described in the commit message, the overhead of creating a Jira needs to
> be justified. Writing the "why" to the commit message is much faster and
> more developer friendly than forcing contributors to create a Jira for
> every trivial improvement. I can say for myself that having to create a
> JIra before fixing some stupid bug substantially lowers my readiness to fix
> it at all.
>

There's always going to be JIRA issues for bug reports. They will describe
what the problem the user had as well as how to reproduce the bug. This
will be the most common scenario for a bug fix.

It's better to have the information in one place, and since there's no
getting away from JIRA, that's the one place this information belongs.
Commit messages should be short and refer to a JIRA.


>
>
> The work has to be scheduled the same as all other work.
>
> Yes, planning is fully legitimate within your team paid for the work but
> again, it sounds rather discouraging to me, an external contributor, when I
> just want to fix a malfunction in KC that blocks my primary task.
>

We can't just accept any random contribution. Any fix can bring
regressions, etc.. So it's not as simple as just fire off a quick fix to
something.


>
>
>
>> (2) I want tags in branches.
>> Your tags are outside branches (such as 1.9.x) and that makes it harder
>> to clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. You
>> are the second project doing it like this out of ~150 Java projects I have
>> ever cloned.
>>
>> Please consider tagging the usual way.
>>
>
> You've certainly cloned more repositories than I have.. I'm not sure what
> you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
> Can you elaborate?
>
> Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are
> *inside* a branch (master branch in this case):
>
>
> To get the tags from upstream, I do not need to use --tags with git fetch,
> because the in-branch tags are fetched also without --tags. Furthermore I
> can clearly see what happened between the yellow labels 0.17.Final and
> 0.16.Final.
>
> OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x branch
> I get only this:
>
>
> No tags there. Only some hints like "Next is 1.9.2" where the tags are
> perhaps around. Nevermind, I know I have to fetch with --tags:
>
>
> Still no tags there, because they are out of the 1.9.x branch that I have
> checked out. To see them, I have to "Show all branches and tags" in egit.
> Sadly, that brings also master and other branches, that I do not want to
> see, but let's try to ignore them, and have a look at what happened between
> 1.9.0.Final and 1.9.1.Final:
>
>
> While it is relatively easy to find out how 1.9.1.Final tag relates to
> 1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a long
> fork of 1.9.x that I cannot track down visually at all. If 1.9.0.Final and
> 1.9.1.Final tags were a part of 1.9.x history, my eyes would be much
> happier. That's it.
>


I'm lost, can you describe that shorter please?



>
> Thanks,
>
> -- Peter
>
>
>
>>
>> (3) While I agree that the linking between git history and Jira is
>> useful, saying that every commit needs a Jira does not sound reasonable.
>> There certainly are commits that do not deserve a Jira, such as:
>> * upgrades of dependencies
>> * refactorings
>> * various formatting and license header fixes
>> I hope most of you will agree here.
>>
>
> I disagree, I want a complete record of what's been done in JIRA.
> Upgrading of dependencies should not just be done randomly. It has a
> reasoning behind it (for example a security fix, or to re-allign with WF
> dependencies, or whatever) without a JIRA you don't have that. Same goes
> for refactoring, they either should be done as part of an existing JIRA or
> there should be a JIRA describing why it was done. The work has to be
> scheduled the same as all other work.
>
> For minor documentation updates (grammar, spelling fixes, etc.) or minor
> pure formatting sure they don't need a JIRA.
>
> All rules come with exceptions, that's just the way of life. However, by
> defacto all commits should have an associated JIRA. That's even more
> important for external contributions.
>
>
>>
>> (4) Pro tip for Chrome users:
>> I created a content script that makes Jiras and BZs on GitHub clickable
>> links. This is what it looks like: <http://snag.gy/rq6Ja.jpg>
>> http://snag.gy/rq6Ja.jpg How to install: https://goo.gl/bYUbHS
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On 2016-03-10 19:12, John Dennis wrote:
>>
>>> On 03/10/2016 01:03 PM, Bill Burke wrote:
>>>
>>>> Is there a way to automatically squash everything to your latest
>>>> commit?
>>>>
>>>
>>> Maybe not automatically, but the conventional way to squash commits is
>>> with interactive rebase, e.g.
>>>
>>> % git rebase -i commit
>>>
>>> where commit is the commit id of the *prior* commit you want to start
>>> the squashing from. Git will fire up your defined editor and you just
>>> replace the pick keyword with the squash keyword for each commit to be
>>> squashed. Many examples on the web. It's not automatic but usually less
>>> than a minute from start to finish.
>>>
>>> HTH,
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/3b098950/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iffagdhf.png
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/3b098950/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icddedjg.png
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/3b098950/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: egdifcbj.png
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/3b098950/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehadefhf.png
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/3b098950/attachment-0007.png 

From sthorger at redhat.com  Fri Mar 11 09:12:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Mar 2016 15:12:21 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E2CE3E.9040906@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
	<56E2CC0E.809@redhat.com> <56E2CE3E.9040906@redhat.com>
Message-ID: <CAJgngAcOQ6nPrO+52DcJqi8_Yzh-EeWL+FA7yU70_TQD5h9gZQ@mail.gmail.com>

That's a very unhelpful and unnecessary comment. If you don't care, don't
comment. If you object, then comment. To me this is important so there's no
reason to be condescending.

The process I described will be helpful for a number of reasons, including:

* It will make it simpler to maintain 1.9.x branch for product while we
move on to 2.x branch
* Users can search for JIRA issues to see if an issue they are having has
been fixed
* Users can view changes for a particular release, including descriptions
of why it was changed (maybe the change causes problems for them)
* Developers can figure out why something was done (2 years after it was
done)
* We can plan when to fix a bug. Not all bugs need fixing, some can be
postponed others are blocking for a release
* ....

In summary all I ask is squash commits and include KEYCLOAK-XXXX in the
commit message.


On 11 March 2016 at 14:55, Bill Burke <bburke at redhat.com> wrote:

> unsubscribe.  This is about as interesting as code formatting rules.
>
>
> On 3/11/2016 8:45 AM, Peter Palaga wrote:
>
> Hi Stian, inline...
>
> On 2016-03-11 06:53, Stian Thorgersen wrote:
>
>
>
> On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com> wrote:
>
>> Hi Stian,
>>
>> just a few minor points. Please note that I am speaking primarily from
>> the standpoint of somebody who often looks into the history of KC branches,
>> because Hawkular (where I am primarily active) uses KC. I am not a regular
>> contributor to KC.
>>
>> (1)
>> > With JIRA key in commit and PRs linked in JIRA we get a good history
>> > that is useful in the future to identify what was changed and why.
>>
>> To see *what* was changed, I do not need to go to Jira. Git history is
>> the ultimate source of that info.
>>
>> As for the *why*, the project has to coin some convention. From what you
>> say it seems that it should be Jira, right? Yes, that is one of the
>> legitimate choices, but not the only possible one. Git commit messages may
>> serve the purpose too and I personally find them much more practical
>> because they are much closer to where I usually start looking. Jira is
>> usually one slooowly loading link further. Therefore, could you please
>> explain why you find Jira better?
>>
>
> One isn't better than the other. They serve different purposes. Git commit
> messages will tell you what code was changed, while JIRA descriptions will
> tell you why it was changed. Both are equally important. Making sure you
> can go from a JIRA issue to Git commits and the other way around are both
> important. Imagine two examples:
>
> * A user searches for a bug in JIRA to see if the problem he's having has
> been resolved. He finds the issue and wants to take a look at what changes
> was made to understand it better.
>
> Yes, I fully agree that the linking from Jira to GitHub makes sense.
>
> * A developer finds some code he wrote 12 months ago was changed, looks at
> Git history to see who did it, but has no idea why. He then sees the JIRA
> key in the commit message and opens it in JIRA. There he finds a lengthy
> description of the bug, including several comments.
>
> No, the explanation why the given commit was necessary may well be placed
> in the commit message itself. In many projects, this is the default place
> for that kind of info. Now, given that the motivation for the change can be
> described in the commit message, the overhead of creating a Jira needs to
> be justified. Writing the "why" to the commit message is much faster and
> more developer friendly than forcing contributors to create a Jira for
> every trivial improvement. I can say for myself that having to create a
> JIra before fixing some stupid bug substantially lowers my readiness to fix
> it at all.
>
> The work has to be scheduled the same as all other work.
>
> Yes, planning is fully legitimate within your team paid for the work but
> again, it sounds rather discouraging to me, an external contributor, when I
> just want to fix a malfunction in KC that blocks my primary task.
>
>
>> (2) I want tags in branches.
>> Your tags are outside branches (such as 1.9.x) and that makes it harder
>> to clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. You
>> are the second project doing it like this out of ~150 Java projects I have
>> ever cloned.
>>
>> Please consider tagging the usual way.
>>
>
> You've certainly cloned more repositories than I have.. I'm not sure what
> you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
> Can you elaborate?
>
> Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are
> *inside* a branch (master branch in this case):
>
>
> To get the tags from upstream, I do not need to use --tags with git fetch,
> because the in-branch tags are fetched also without --tags. Furthermore I
> can clearly see what happened between the yellow labels 0.17.Final and
> 0.16.Final.
>
> OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x branch
> I get only this:
>
>
> No tags there. Only some hints like "Next is 1.9.2" where the tags are
> perhaps around. Nevermind, I know I have to fetch with --tags:
>
>
> Still no tags there, because they are out of the 1.9.x branch that I have
> checked out. To see them, I have to "Show all branches and tags" in egit.
> Sadly, that brings also master and other branches, that I do not want to
> see, but let's try to ignore them, and have a look at what happened between
> 1.9.0.Final and 1.9.1.Final:
>
>
> While it is relatively easy to find out how 1.9.1.Final tag relates to
> 1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a long
> fork of 1.9.x that I cannot track down visually at all. If 1.9.0.Final and
> 1.9.1.Final tags were a part of 1.9.x history, my eyes would be much
> happier. That's it.
>
> Thanks,
>
> -- Peter
>
>
>
>>
>> (3) While I agree that the linking between git history and Jira is
>> useful, saying that every commit needs a Jira does not sound reasonable.
>> There certainly are commits that do not deserve a Jira, such as:
>> * upgrades of dependencies
>> * refactorings
>> * various formatting and license header fixes
>> I hope most of you will agree here.
>>
>
> I disagree, I want a complete record of what's been done in JIRA.
> Upgrading of dependencies should not just be done randomly. It has a
> reasoning behind it (for example a security fix, or to re-allign with WF
> dependencies, or whatever) without a JIRA you don't have that. Same goes
> for refactoring, they either should be done as part of an existing JIRA or
> there should be a JIRA describing why it was done. The work has to be
> scheduled the same as all other work.
>
> For minor documentation updates (grammar, spelling fixes, etc.) or minor
> pure formatting sure they don't need a JIRA.
>
> All rules come with exceptions, that's just the way of life. However, by
> defacto all commits should have an associated JIRA. That's even more
> important for external contributions.
>
>
>>
>> (4) Pro tip for Chrome users:
>> I created a content script that makes Jiras and BZs on GitHub clickable
>> links. This is what it looks like: <http://snag.gy/rq6Ja.jpg>
>> http://snag.gy/rq6Ja.jpg How to install: https://goo.gl/bYUbHS
>>
>> Thanks,
>>
>> Peter
>>
>>
>> On 2016-03-10 19:12, John Dennis wrote:
>>
>>> On 03/10/2016 01:03 PM, Bill Burke wrote:
>>>
>>>> Is there a way to automatically squash everything to your latest
>>>> commit?
>>>>
>>>
>>> Maybe not automatically, but the conventional way to squash commits is
>>> with interactive rebase, e.g.
>>>
>>> % git rebase -i commit
>>>
>>> where commit is the commit id of the *prior* commit you want to start
>>> the squashing from. Git will fire up your defined editor and you just
>>> replace the pick keyword with the squash keyword for each commit to be
>>> squashed. Many examples on the web. It's not automatic but usually less
>>> than a minute from start to finish.
>>>
>>> HTH,
>>>
>>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://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/20160311/2160809c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0007.png 

From bburke at redhat.com  Fri Mar 11 09:29:20 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Mar 2016 09:29:20 -0500
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <CAJgngAcOQ6nPrO+52DcJqi8_Yzh-EeWL+FA7yU70_TQD5h9gZQ@mail.gmail.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
	<56E2CC0E.809@redhat.com> <56E2CE3E.9040906@redhat.com>
	<CAJgngAcOQ6nPrO+52DcJqi8_Yzh-EeWL+FA7yU70_TQD5h9gZQ@mail.gmail.com>
Message-ID: <56E2D640.7020607@redhat.com>



On 3/11/2016 9:12 AM, Stian Thorgersen wrote:
>
> In summary all I ask is squash commits and include KEYCLOAK-XXXX in 
> the commit message.
>

That's all I needed to hear, not some long drawn out discussion on the 
way GIT history should look and the GIT command tribal dance to get it 
to look that particular way.  I don't understand people's fascination 
with something that is rarely looked at by a very small subset of people 
that we can probably count on one hand.  I've seen the same mind 
numbing, anal retentive, discussions on Wildfly, hibernate, and core 
lists too.

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


From sthorger at redhat.com  Fri Mar 11 09:38:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 11 Mar 2016 15:38:35 +0100
Subject: [keycloak-dev] Commits/PRs
In-Reply-To: <56E2D640.7020607@redhat.com>
References: <CAJgngAdO=mJMivik3-7ctzHNrbc1VAb7fONCmPFmKvBN89=xWw@mail.gmail.com>
	<56E1B708.3050902@redhat.com> <56E1B90F.3060507@redhat.com>
	<56E1E472.6000304@redhat.com>
	<CAJgngAf6CHv07E4HpqPo-B6XoDW4ztrg498nAgp4mkLWgquNpg@mail.gmail.com>
	<56E2CC0E.809@redhat.com> <56E2CE3E.9040906@redhat.com>
	<CAJgngAcOQ6nPrO+52DcJqi8_Yzh-EeWL+FA7yU70_TQD5h9gZQ@mail.gmail.com>
	<56E2D640.7020607@redhat.com>
Message-ID: <CAJgngAcZH-+y-5q1pbCMy-SGtOnga8RPYaxvNF9JeqxS+8eLpw@mail.gmail.com>

On 11 March 2016 at 15:29, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 3/11/2016 9:12 AM, Stian Thorgersen wrote:
>
>>
>> In summary all I ask is squash commits and include KEYCLOAK-XXXX in the
>> commit message.
>>
>>
> That's all I needed to hear, not some long drawn out discussion on the way
> GIT history should look and the GIT command tribal dance to get it to look
> that particular way.  I don't understand people's fascination with
> something that is rarely looked at by a very small subset of people that we
> can probably count on one hand.  I've seen the same mind numbing, anal
> retentive, discussions on Wildfly, hibernate, and core lists too.


I blame the day of the week - I tend to get more caught up in discussions
on a Friday ;)


>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/6c229677/attachment.html 

From prabhalar at yahoo.com  Fri Mar 11 14:34:33 2016
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Fri, 11 Mar 2016 14:34:33 -0500
Subject: [keycloak-dev] Identity brokering bugs
Message-ID: <CD071E4A-7C90-47DB-B797-174C25998702@yahoo.com>

Just wanted to give a heads up that the identity brokering is not working for either saml or oidc - opened a few bugs
Kc2654 2635 2616

The identity brokering needs a lot of testing (I can do that) before KC is released as a product 

Sent from my iPhone

From matzew at apache.org  Mon Mar 14 06:15:13 2016
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 14 Mar 2016 11:15:13 +0100
Subject: [keycloak-dev] 1.9.1.Final
Message-ID: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>

any idea when 1.9.1 is on maven cetnral ?

-- 
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/20160314/4f68b589/attachment.html 

From thomas.darimont at googlemail.com  Mon Mar 14 16:27:47 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 14 Mar 2016 21:27:47 +0100
Subject: [keycloak-dev] Improved ToTP Security example
Message-ID: <CAK-7U1iuez8JvOg-OF2Pc2hr74uy4e6boqbgO-nkqCnr=VY48w@mail.gmail.com>

Hello,

the guys from projectlombok build an example application (see [0]) for ToTP
based
multi-factor authentication which showed at the Javaland 2016 conference in
Germany last week.

In this app they demoed an interesting security feature:

if a user enters a wrong ToTP code (or a far off one) they require the user
to
enter 3 consecutive valid ToTP codes - although I can imagine that this is
a bit annoying
for the user it nevertheless could add an additional level of security to
the
ToTP authentication mechanism.

They show the following message if a user entered a wrong / far-off ToTP
token:

"Due to entering a wrong TOTP confirmation code, you now need to enter 3
consecutive codes
so that we can confirm you're not just guessing codes, and detect issues
with your verification device's clock."

Perhaps keycloak could add such a feature as well.

Cheers,
Thomas

[0] - https://github.com/rzwitserloot/totp-example
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160314/54d3c020/attachment.html 

From matzew at apache.org  Tue Mar 15 04:55:39 2016
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 15 Mar 2016 09:55:39 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
Message-ID: <CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>

Still not on maven central.

Any plans to push 1.9.1 to maven central, or was the release skipped ?

On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> any idea when 1.9.1 is on maven cetnral ?
>
> --
> 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/20160315/a6634b38/attachment.html 

From sthorger at redhat.com  Tue Mar 15 08:33:22 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Mar 2016 13:33:22 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
Message-ID: <CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>

Something has gone wrong syncing from Nexus to Maven Central. We're waiting
for it to be fixed.

On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org> wrote:

> Still not on maven central.
>
> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>
> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> any idea when 1.9.1 is on maven cetnral ?
>>
>> --
>> 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
>
> _______________________________________________
> 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/20160315/0416d8b7/attachment-0001.html 

From sthorger at redhat.com  Tue Mar 15 13:08:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Mar 2016 18:08:16 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
	<CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
Message-ID: <CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>

Looks like it's in maven central:
http://repo1.maven.org/maven2/org/keycloak/keycloak-common/1.9.1.Final/

But doesn't show up on search.maven. org
On 15 Mar 2016 1:33 p.m., "Stian Thorgersen" <sthorger at redhat.com> wrote:

> Something has gone wrong syncing from Nexus to Maven Central. We're
> waiting for it to be fixed.
>
> On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> Still not on maven central.
>>
>> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>>
>> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> any idea when 1.9.1 is on maven cetnral ?
>>>
>>> --
>>> 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
>>
>> _______________________________________________
>> 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/20160315/0be9faa3/attachment.html 

From jdennis at redhat.com  Wed Mar 16 18:35:30 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 16 Mar 2016 18:35:30 -0400
Subject: [keycloak-dev] Conceptual Questions
Message-ID: <56E9DFB2.6070802@redhat.com>

I would appreciate having the following Keycloak concepts
explained. Many thanks in advance!

* What are the predefined clients?

   - When, why and where are you supposed to use these predefined
     clients?

* What is the difference between realm roles and client roles?

   - Why are realm roles and client roles distinct?

   - How do they get assigned and for what purpose?

   - Why aren't roles always visible in the Web UI? For instance
     the available roles drop down box is often unpopulated even
     though they seem to be predefined in the source code. Why
     aren't they available for assignment in the Web UI?

* How does role mapping work?

   - What is being mapped from and being mapped to?

   - What is the intended usage for these mappings?

* What does it mean to create a role in the Web UI? What is it
   bound to?

   - How do roles created in the Web UI relate to the predefined
     roles?

   - Why does the Web UI allow me to create a new role with the
     same name as a predefined role? Are they the same role or is
     there a collision?

* What are effective roles?

   - How are effective roles computed?

   - In the Web UI I see lists for "Available Roles", "Assigned
     Roles" and "Effective Roles". Sometimes I see a role in the
     "Effective Roles" list which is not in the "Assigned Roles"
     list. How and why does this happen?

* What are composite roles?

   - How and where are they defined?

   - How are composite roles meant to be used?

   - When looking at a list of roles in the Web UI how does one
     identify a single role from a composite role?

* What is the relationship between a Keycloak role and an OAuth2
   scope?

* Are roles related to users in any fashion or is a role bound
   exclusively to a client (appearing only in the client's token).

   - How do you authenticate as a user and acquire specific roles?

   - Is it because a user grants a role via an OAuth scope which
     is then conveyed in the client token?)

   - If so how is it determined what roles a user is permitted to
     grant?

   - For example how is an admin user created? How are the fine
     grained admin roles bound to a user and how are these roles
     then conveyed in the token after an admin user authenticates?
     (see next question)

* The ClientRegistrationAuth.requireCreate() method requires the
   bearer token from the realm administrator to have the
   AdminRoles.MANAGE_CLIENTS or AdminRoles.CREATE_CLIENT roles in
   the token, specifically in the resource_access part of the
   token, but no matter what I do to add roles in the Web UI to a
   realm admin the token roles remain unpopulated. How do these
   roles get assigned and propagated in the token?

* How does a client differ from an application?

   - They seem to be closely related. How, why and when do you use
     one vs. the other?

   - The name "application" suggests they are external
     applications which might be secured by Keycloak but that
     doesn't seem to be the case, rather applications seem to be
     internal Keycloak entities. Are applications called
     applications because they are implemented as as servlets in
     Keycloak?

   - If so, is the reason applications are servlets is so their
     endpoints can have their own authn and authz?

* What are adapters?

* What is a service account?

   - How is a service account supposed to be used and for what
     purpose?

   - How is a service account created?

   - How is a service account  authenticated?

* How does OAuth2 client authentication work in Keycloak?

   - Are public clients authenticated? The OAuth2 spec talks a lot
     about the server authenticating the client but if the client
     is a public client it's not clear to me how this is done. How
     are public clients authenticated?


-- 
John

From matzew at apache.org  Fri Mar 18 04:32:35 2016
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 18 Mar 2016 09:32:35 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
	<CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
	<CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>
Message-ID: <CAAg5f2Tzb+QhJcPS_=WFN7+sYJ62oM2Uyx=p5PyQbLdv1D5v=Q@mail.gmail.com>

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-core%22

1.8.2.Final is missing too ?! :)

On Tue, Mar 15, 2016 at 6:08 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Looks like it's in maven central:
> http://repo1.maven.org/maven2/org/keycloak/keycloak-common/1.9.1.Final/
>
> But doesn't show up on search.maven. org
> On 15 Mar 2016 1:33 p.m., "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> Something has gone wrong syncing from Nexus to Maven Central. We're
>> waiting for it to be fixed.
>>
>> On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>>> Still not on maven central.
>>>
>>> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>>>
>>> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <matzew at apache.org
>>> > wrote:
>>>
>>>> any idea when 1.9.1 is on maven cetnral ?
>>>>
>>>> --
>>>> 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
>>>
>>> _______________________________________________
>>> 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/20160318/c4e87fc4/attachment.html 

From sthorger at redhat.com  Fri Mar 18 06:40:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Mar 2016 11:40:25 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAAg5f2Tzb+QhJcPS_=WFN7+sYJ62oM2Uyx=p5PyQbLdv1D5v=Q@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
	<CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
	<CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>
	<CAAg5f2Tzb+QhJcPS_=WFN7+sYJ62oM2Uyx=p5PyQbLdv1D5v=Q@mail.gmail.com>
Message-ID: <CAJgngAeh-zKPQ65YoUNSOQ9MpA3dFyhOT149pseGit3BOYV5Vw@mail.gmail.com>

There's no 1.8.2 final at all ;)

On 18 March 2016 at 09:32, Matthias Wessendorf <matzew at apache.org> wrote:

>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-core%22
>
> 1.8.2.Final is missing too ?! :)
>
> On Tue, Mar 15, 2016 at 6:08 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Looks like it's in maven central:
>> http://repo1.maven.org/maven2/org/keycloak/keycloak-common/1.9.1.Final/
>>
>> But doesn't show up on search.maven. org
>> On 15 Mar 2016 1:33 p.m., "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>>> Something has gone wrong syncing from Nexus to Maven Central. We're
>>> waiting for it to be fixed.
>>>
>>> On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Still not on maven central.
>>>>
>>>> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>>>>
>>>> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <
>>>> matzew at apache.org> wrote:
>>>>
>>>>> any idea when 1.9.1 is on maven cetnral ?
>>>>>
>>>>> --
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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/20160318/5a467109/attachment-0001.html 

From matzew at apache.org  Fri Mar 18 06:54:06 2016
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 18 Mar 2016 11:54:06 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAJgngAeh-zKPQ65YoUNSOQ9MpA3dFyhOT149pseGit3BOYV5Vw@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
	<CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
	<CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>
	<CAAg5f2Tzb+QhJcPS_=WFN7+sYJ62oM2Uyx=p5PyQbLdv1D5v=Q@mail.gmail.com>
	<CAJgngAeh-zKPQ65YoUNSOQ9MpA3dFyhOT149pseGit3BOYV5Vw@mail.gmail.com>
Message-ID: <CAAg5f2REZfZLYE0KD49JeJO8GUwqfczcbnvP7O4JfDsE+dLdpQ@mail.gmail.com>

than GH is wrong :)

https://github.com/keycloak/keycloak/releases/tag/1.8.2.Final

On Fri, Mar 18, 2016 at 11:40 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> There's no 1.8.2 final at all ;)
>
> On 18 March 2016 at 09:32, Matthias Wessendorf <matzew at apache.org> wrote:
>
>>
>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-core%22
>>
>> 1.8.2.Final is missing too ?! :)
>>
>> On Tue, Mar 15, 2016 at 6:08 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Looks like it's in maven central:
>>> http://repo1.maven.org/maven2/org/keycloak/keycloak-common/1.9.1.Final/
>>>
>>> But doesn't show up on search.maven. org
>>> On 15 Mar 2016 1:33 p.m., "Stian Thorgersen" <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Something has gone wrong syncing from Nexus to Maven Central. We're
>>>> waiting for it to be fixed.
>>>>
>>>> On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>>
>>>>> Still not on maven central.
>>>>>
>>>>> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>>>>>
>>>>> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <
>>>>> matzew at apache.org> wrote:
>>>>>
>>>>>> any idea when 1.9.1 is on maven cetnral ?
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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/20160318/5b4c7ad1/attachment.html 

From sthorger at redhat.com  Fri Mar 18 07:11:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Mar 2016 12:11:41 +0100
Subject: [keycloak-dev] 1.9.1.Final
In-Reply-To: <CAAg5f2REZfZLYE0KD49JeJO8GUwqfczcbnvP7O4JfDsE+dLdpQ@mail.gmail.com>
References: <CAAg5f2QMELRijMCPt1pyzL5-KBPjdth7OQy2+PFi9+SO7Q9cBg@mail.gmail.com>
	<CAAg5f2S8oJcQQ-FVbWELCnNMXkxAKaLLwbA6syeaqE082za7KA@mail.gmail.com>
	<CAJgngAdthxyvjko=HQgXfx=wKVTm-mO3syKVu+DxK7j+-o_ZzQ@mail.gmail.com>
	<CAJgngAeJcGBy10Akqy-eUrnsFRag3Egb77k1JTv=TKOaKO-d9w@mail.gmail.com>
	<CAAg5f2Tzb+QhJcPS_=WFN7+sYJ62oM2Uyx=p5PyQbLdv1D5v=Q@mail.gmail.com>
	<CAJgngAeh-zKPQ65YoUNSOQ9MpA3dFyhOT149pseGit3BOYV5Vw@mail.gmail.com>
	<CAAg5f2REZfZLYE0KD49JeJO8GUwqfczcbnvP7O4JfDsE+dLdpQ@mail.gmail.com>
Message-ID: <CAJgngAejv41WBDGtUiGEgR-bZYJZJ2XxsgXFmrRghsE5OMEqJQ@mail.gmail.com>

That was just tagged for product only, not for community release as we
already had 1.9.1 in community

On 18 March 2016 at 11:54, Matthias Wessendorf <matzew at apache.org> wrote:

> than GH is wrong :)
>
> https://github.com/keycloak/keycloak/releases/tag/1.8.2.Final
>
> On Fri, Mar 18, 2016 at 11:40 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> There's no 1.8.2 final at all ;)
>>
>> On 18 March 2016 at 09:32, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>>>
>>> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.keycloak%22%20AND%20a%3A%22keycloak-core%22
>>>
>>> 1.8.2.Final is missing too ?! :)
>>>
>>> On Tue, Mar 15, 2016 at 6:08 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Looks like it's in maven central:
>>>> http://repo1.maven.org/maven2/org/keycloak/keycloak-common/1.9.1.Final/
>>>>
>>>> But doesn't show up on search.maven. org
>>>> On 15 Mar 2016 1:33 p.m., "Stian Thorgersen" <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Something has gone wrong syncing from Nexus to Maven Central. We're
>>>>> waiting for it to be fixed.
>>>>>
>>>>> On 15 March 2016 at 09:55, Matthias Wessendorf <matzew at apache.org>
>>>>> wrote:
>>>>>
>>>>>> Still not on maven central.
>>>>>>
>>>>>> Any plans to push 1.9.1 to maven central, or was the release skipped ?
>>>>>>
>>>>>> On Mon, Mar 14, 2016 at 11:15 AM, Matthias Wessendorf <
>>>>>> matzew at apache.org> wrote:
>>>>>>
>>>>>>> any idea when 1.9.1 is on maven cetnral ?
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20160318/3678e89f/attachment.html 

From velias at redhat.com  Fri Mar 18 08:17:10 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 18 Mar 2016 13:17:10 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
Message-ID: <56EBF1C6.9000606@redhat.com>

Hi,

as part of planned persistence storage SPI changes we talked about on 
f2f we should probably consider removing of first name, last name and 
email from UserModel property, but implement them as normal user 
attributes with predefined names.

This unification should simplify few things, for example separate 
mappers for attributes and properties in Clients and Identity Providers 
configuration, which may be hard to understand for beginners (questions 
like "what the hell is difference between user properties and 
attributes?", "What user properties are available there?").

This should also simplify implementation of User profile validation SPI 
we talked about on f2f meeting.

What do you think?

Vl.

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team


From sthorger at redhat.com  Fri Mar 18 08:36:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Mar 2016 13:36:33 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <56EBF1C6.9000606@redhat.com>
References: <56EBF1C6.9000606@redhat.com>
Message-ID: <CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>

+1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common attributes,
but they would just pass through to attributes rather than separate fields.
On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com> wrote:

> Hi,
>
> as part of planned persistence storage SPI changes we talked about on
> f2f we should probably consider removing of first name, last name and
> email from UserModel property, but implement them as normal user
> attributes with predefined names.
>
> This unification should simplify few things, for example separate
> mappers for attributes and properties in Clients and Identity Providers
> configuration, which may be hard to understand for beginners (questions
> like "what the hell is difference between user properties and
> attributes?", "What user properties are available there?").
>
> This should also simplify implementation of User profile validation SPI
> we talked about on f2f meeting.
>
> What do you think?
>
> Vl.
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
> _______________________________________________
> 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/20160318/5eb179d6/attachment-0001.html 

From velias at redhat.com  Fri Mar 18 09:29:57 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 18 Mar 2016 14:29:57 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
Message-ID: <56EC02D5.2060703@redhat.com>


Yep, only small drawback may be that email uniqueness is checked and 
users are searched by email for login by email address. These DB queries 
will be a bit more complicated.

Vl.

On 18.3.2016 13:36, Stian Thorgersen wrote:
>
> +1 Makes sense to me. Especially the part of not having two different 
> mappers. It could still be useful to have a get/set for common 
> attributes, but they would just pass through to attributes rather than 
> separate fields.
>
> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     as part of planned persistence storage SPI changes we talked about on
>     f2f we should probably consider removing of first name, last name and
>     email from UserModel property, but implement them as normal user
>     attributes with predefined names.
>
>     This unification should simplify few things, for example separate
>     mappers for attributes and properties in Clients and Identity
>     Providers
>     configuration, which may be hard to understand for beginners
>     (questions
>     like "what the hell is difference between user properties and
>     attributes?", "What user properties are available there?").
>
>     This should also simplify implementation of User profile
>     validation SPI
>     we talked about on f2f meeting.
>
>     What do you think?
>
>     Vl.
>
>     --
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>     _______________________________________________
>     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
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From mposolda at redhat.com  Fri Mar 18 09:41:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 18 Mar 2016 14:41:54 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
Message-ID: <56EC05A2.70900@redhat.com>

+1 for have unified mapper for properties and attributes. That's very 
easy to do, we can just fallback to setAttribute/getAttribute if there 
is not property . LDAP UserAttribute mapper is already unified and is 
doing like that.

Having the basic attributes in separate table might theoretically have 
some performance impact. For example if email is stored as attribute, 
then each searching by email needs to join 2 tables instead of one. 
There is also DB constraint to enforce unique email. So maybe at least 
email worth to keep as it is?

Marek


On 18/03/16 13:36, Stian Thorgersen wrote:
>
> +1 Makes sense to me. Especially the part of not having two different 
> mappers. It could still be useful to have a get/set for common 
> attributes, but they would just pass through to attributes rather than 
> separate fields.
>
> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     as part of planned persistence storage SPI changes we talked about on
>     f2f we should probably consider removing of first name, last name and
>     email from UserModel property, but implement them as normal user
>     attributes with predefined names.
>
>     This unification should simplify few things, for example separate
>     mappers for attributes and properties in Clients and Identity
>     Providers
>     configuration, which may be hard to understand for beginners
>     (questions
>     like "what the hell is difference between user properties and
>     attributes?", "What user properties are available there?").
>
>     This should also simplify implementation of User profile
>     validation SPI
>     we talked about on f2f meeting.
>
>     What do you think?
>
>     Vl.
>
>     --
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Fri Mar 18 09:46:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Mar 2016 14:46:54 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <56EC05A2.70900@redhat.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
	<56EC05A2.70900@redhat.com>
Message-ID: <CAJgngAczHEa9CWWbzEeA5f3cBQmXbGWURQRev2yPLcjLTP-5tw@mail.gmail.com>

+1 Primary or "login" email should be left on user entity. We need to
consider how we're going to support having more than one email associated
with one account as well as multiple accounts with same email. I'd say we'd
have a login email, but also contact emails.
On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda at redhat.com> wrote:

> +1 for have unified mapper for properties and attributes. That's very easy
> to do, we can just fallback to setAttribute/getAttribute if there is not
> property . LDAP UserAttribute mapper is already unified and is doing like
> that.
>
> Having the basic attributes in separate table might theoretically have
> some performance impact. For example if email is stored as attribute, then
> each searching by email needs to join 2 tables instead of one. There is
> also DB constraint to enforce unique email. So maybe at least email worth
> to keep as it is?
>
> Marek
>
>
> On 18/03/16 13:36, Stian Thorgersen wrote:
>
> +1 Makes sense to me. Especially the part of not having two different
> mappers. It could still be useful to have a get/set for common attributes,
> but they would just pass through to attributes rather than separate fields.
> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com> wrote:
>
>> Hi,
>>
>> as part of planned persistence storage SPI changes we talked about on
>> f2f we should probably consider removing of first name, last name and
>> email from UserModel property, but implement them as normal user
>> attributes with predefined names.
>>
>> This unification should simplify few things, for example separate
>> mappers for attributes and properties in Clients and Identity Providers
>> configuration, which may be hard to understand for beginners (questions
>> like "what the hell is difference between user properties and
>> attributes?", "What user properties are available there?").
>>
>> This should also simplify implementation of User profile validation SPI
>> we talked about on f2f meeting.
>>
>> What do you think?
>>
>> Vl.
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160318/c0362dc8/attachment.html 

From velias at redhat.com  Fri Mar 18 09:47:52 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 18 Mar 2016 14:47:52 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <56EC05A2.70900@redhat.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
	<56EC05A2.70900@redhat.com>
Message-ID: <56EC0708.1050904@redhat.com>

+1 to keep email directly in user as it has additional logic (but unify 
it in mappers to have only one), but move name fields away as they are 
just common attributes without additional logic. Some instances may even 
work without them.

Vl.

On 18.3.2016 14:41, Marek Posolda wrote:
> +1 for have unified mapper for properties and attributes. That's very 
> easy to do, we can just fallback to setAttribute/getAttribute if there 
> is not property . LDAP UserAttribute mapper is already unified and is 
> doing like that.
>
> Having the basic attributes in separate table might theoretically have 
> some performance impact. For example if email is stored as attribute, 
> then each searching by email needs to join 2 tables instead of one. 
> There is also DB constraint to enforce unique email. So maybe at least 
> email worth to keep as it is?
>
> Marek
>
>
> On 18/03/16 13:36, Stian Thorgersen wrote:
>>
>> +1 Makes sense to me. Especially the part of not having two different 
>> mappers. It could still be useful to have a get/set for common 
>> attributes, but they would just pass through to attributes rather 
>> than separate fields.
>>
>> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com 
>> <mailto:velias at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     as part of planned persistence storage SPI changes we talked about on
>>     f2f we should probably consider removing of first name, last name and
>>     email from UserModel property, but implement them as normal user
>>     attributes with predefined names.
>>
>>     This unification should simplify few things, for example separate
>>     mappers for attributes and properties in Clients and Identity
>>     Providers
>>     configuration, which may be hard to understand for beginners
>>     (questions
>>     like "what the hell is difference between user properties and
>>     attributes?", "What user properties are available there?").
>>
>>     This should also simplify implementation of User profile
>>     validation SPI
>>     we talked about on f2f meeting.
>>
>>     What do you think?
>>
>>     Vl.
>>
>>     --
>>     Vlastimil Elias
>>     Principal Software Engineer
>>     Developer Portal Engineering Team
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160318/3f595b28/attachment-0001.html 

From velias at redhat.com  Fri Mar 18 09:52:56 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 18 Mar 2016 14:52:56 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <CAJgngAczHEa9CWWbzEeA5f3cBQmXbGWURQRev2yPLcjLTP-5tw@mail.gmail.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
	<56EC05A2.70900@redhat.com>
	<CAJgngAczHEa9CWWbzEeA5f3cBQmXbGWURQRev2yPLcjLTP-5tw@mail.gmail.com>
Message-ID: <56EC0838.5020005@redhat.com>

More emails for one account are simple, you need one to be main for 
login purposes and to be used to send "forgot pwd" and similar emails 
to, we have it now. Rest emails may be just in common attribute (it 
allows to store more values). Question is if you want to support 
validation/verification process for these additional emails and consider 
them in uniqueness tests ;-)

More accounts with same email is more tricky ;-)

Vl.

On 18.3.2016 14:46, Stian Thorgersen wrote:
>
> +1 Primary or "login" email should be left on user entity. We need to 
> consider how we're going to support having more than one email 
> associated with one account as well as multiple accounts with same 
> email. I'd say we'd have a login email, but also contact emails.
>
> On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     +1 for have unified mapper for properties and attributes. That's
>     very easy to do, we can just fallback to setAttribute/getAttribute
>     if there is not property . LDAP UserAttribute mapper is already
>     unified and is doing like that.
>
>     Having the basic attributes in separate table might theoretically
>     have some performance impact. For example if email is stored as
>     attribute, then each searching by email needs to join 2 tables
>     instead of one. There is also DB constraint to enforce unique
>     email. So maybe at least email worth to keep as it is?
>
>     Marek
>
>
>     On 18/03/16 13:36, Stian Thorgersen wrote:
>>
>>     +1 Makes sense to me. Especially the part of not having two
>>     different mappers. It could still be useful to have a get/set for
>>     common attributes, but they would just pass through to attributes
>>     rather than separate fields.
>>
>>     On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi,
>>
>>         as part of planned persistence storage SPI changes we talked
>>         about on
>>         f2f we should probably consider removing of first name, last
>>         name and
>>         email from UserModel property, but implement them as normal user
>>         attributes with predefined names.
>>
>>         This unification should simplify few things, for example separate
>>         mappers for attributes and properties in Clients and Identity
>>         Providers
>>         configuration, which may be hard to understand for beginners
>>         (questions
>>         like "what the hell is difference between user properties and
>>         attributes?", "What user properties are available there?").
>>
>>         This should also simplify implementation of User profile
>>         validation SPI
>>         we talked about on f2f meeting.
>>
>>         What do you think?
>>
>>         Vl.
>>
>>         --
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>         _______________________________________________
>>         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
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Fri Mar 18 11:32:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Mar 2016 16:32:16 +0100
Subject: [keycloak-dev] Move email first name,
 last name and email to be stored as user attribute, not UserModel property?
In-Reply-To: <56EC0838.5020005@redhat.com>
References: <56EBF1C6.9000606@redhat.com>
	<CAJgngAf1oGOdc-5OwkkETGhoexMRa3tJgSfAXJvqLRp1EHyvpA@mail.gmail.com>
	<56EC05A2.70900@redhat.com>
	<CAJgngAczHEa9CWWbzEeA5f3cBQmXbGWURQRev2yPLcjLTP-5tw@mail.gmail.com>
	<56EC0838.5020005@redhat.com>
Message-ID: <CAJgngAdp43so7g8X-qy8Xo2xf5=vy+cc0iGkrdazFZ4sNmEyuA@mail.gmail.com>

On 18 Mar 2016 14:52, "Vlastimil Elias" <velias at redhat.com> wrote:
>
> More emails for one account are simple, you need one to be main for login
purposes and to be used to send "forgot pwd" and similar emails to, we have
it now. Rest emails may be just in common attribute (it allows to store
more values). Question is if you want to support validation/verification
process for these additional emails and consider them in uniqueness tests
;-)

No need for uniqueness as long as it's not the login email. Might need
support in account so users can pick contact email to be used for email
flows. Verify email would be nice as well.

>
> More accounts with same email is more tricky ;-)

Is it not just adding contact email as attribute? Then not having login
email?

>
> Vl.
>
>
> On 18.3.2016 14:46, Stian Thorgersen wrote:
>>
>> +1 Primary or "login" email should be left on user entity. We need to
consider how we're going to support having more than one email associated
with one account as well as multiple accounts with same email. I'd say we'd
have a login email, but also contact emails.
>>
>> On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda at redhat.com> wrote:
>>>
>>> +1 for have unified mapper for properties and attributes. That's very
easy to do, we can just fallback to setAttribute/getAttribute if there is
not property . LDAP UserAttribute mapper is already unified and is doing
like that.
>>>
>>> Having the basic attributes in separate table might theoretically have
some performance impact. For example if email is stored as attribute, then
each searching by email needs to join 2 tables instead of one. There is
also DB constraint to enforce unique email. So maybe at least email worth
to keep as it is?
>>>
>>> Marek
>>>
>>>
>>> On 18/03/16 13:36, Stian Thorgersen wrote:
>>>>
>>>> +1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common attributes,
but they would just pass through to attributes rather than separate fields.
>>>>
>>>> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias at redhat.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> as part of planned persistence storage SPI changes we talked about on
>>>>> f2f we should probably consider removing of first name, last name and
>>>>> email from UserModel property, but implement them as normal user
>>>>> attributes with predefined names.
>>>>>
>>>>> This unification should simplify few things, for example separate
>>>>> mappers for attributes and properties in Clients and Identity
Providers
>>>>> configuration, which may be hard to understand for beginners
(questions
>>>>> like "what the hell is difference between user properties and
>>>>> attributes?", "What user properties are available there?").
>>>>>
>>>>> This should also simplify implementation of User profile validation
SPI
>>>>> we talked about on f2f meeting.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Vl.
>>>>>
>>>>> --
>>>>> Vlastimil Elias
>>>>> Principal Software Engineer
>>>>> Developer Portal Engineering Team
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160318/ed118d96/attachment.html 

From mposolda at redhat.com  Mon Mar 21 12:38:50 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Mar 2016 17:38:50 +0100
Subject: [keycloak-dev] Should we remove links from users when
	identityProvider is removed?
Message-ID: <56F0239A.5010201@redhat.com>

Currently when identity (social) provider is removed, the federated 
links on linked users are not removed. It means that we may end with 
user records in DB, which are linked to non-existent identity provider.

On the other hand, the advantage of current behaviour is, that when 
admin user accidentally removes facebook provider and then he decides to 
add it back (or just use another clientId/clientSecret or change 
configuration) the facebook links of users are still alive.

So should we remove the links or rather keep as it is and not remove them?

Marek



From mposolda at redhat.com  Mon Mar 21 12:45:32 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Mar 2016 17:45:32 +0100
Subject: [keycloak-dev] Should we remove links from users when
 identityProvider is removed?
In-Reply-To: <56F0239A.5010201@redhat.com>
References: <56F0239A.5010201@redhat.com>
Message-ID: <56F0252C.6030605@redhat.com>

On 21/03/16 17:38, Marek Posolda wrote:
> Currently when identity (social) provider is removed, the federated
> links on linked users are not removed. It means that we may end with
> user records in DB, which are linked to non-existent identity provider.
>
> On the other hand, the advantage of current behaviour is, that when
> admin user accidentally removes facebook provider and then he decides to
> add it back (or just use another clientId/clientSecret or change
> configuration) the facebook links of users are still alive.
Sorry to not be clear in the previous paragraph. I meant that some admin 
may remove facebook provider and then re-create it again with another 
configuration. Of course, I didn't mean that we should remove links when 
some configuration of identity provider is changed.

Marek
>
> So should we remove the links or rather keep as it is and not remove them?
>
> Marek
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Mon Mar 21 12:46:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Mar 2016 17:46:43 +0100
Subject: [keycloak-dev] Should we remove links from users when
 identityProvider is removed?
In-Reply-To: <56F0239A.5010201@redhat.com>
References: <56F0239A.5010201@redhat.com>
Message-ID: <CAJgngAf_nT9TNd5N-dWZpJFSOeeVrQXOKx37W-RCEmH9fBEmAw@mail.gmail.com>

My vote goes to keep. In the future we should add batch operations for
users and one thing we could support is remove identity provider links.
On 21 Mar 2016 5:39 p.m., "Marek Posolda" <mposolda at redhat.com> wrote:

> Currently when identity (social) provider is removed, the federated
> links on linked users are not removed. It means that we may end with
> user records in DB, which are linked to non-existent identity provider.
>
> On the other hand, the advantage of current behaviour is, that when
> admin user accidentally removes facebook provider and then he decides to
> add it back (or just use another clientId/clientSecret or change
> configuration) the facebook links of users are still alive.
>
> So should we remove the links or rather keep as it is and not remove them?
>
> Marek
>
>
> _______________________________________________
> 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/20160321/ccfdee71/attachment-0001.html 

From sthorger at redhat.com  Tue Mar 22 03:40:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Mar 2016 07:40:09 +0000
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <56E9DFB2.6070802@redhat.com>
References: <56E9DFB2.6070802@redhat.com>
Message-ID: <CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>

That's a very long list of questions. Have you read through our
documentation? I would hope it at least answers some of these questions. If
not then breaking this list into smaller emails would make it easier to
answer. Answering all these questions in one go is a fairly time consuming
job.

On 16 March 2016 at 22:35, John Dennis <jdennis at redhat.com> wrote:

> I would appreciate having the following Keycloak concepts
> explained. Many thanks in advance!
>
> * What are the predefined clients?
>
>    - When, why and where are you supposed to use these predefined
>      clients?
>
> * What is the difference between realm roles and client roles?
>
>    - Why are realm roles and client roles distinct?
>
>    - How do they get assigned and for what purpose?
>
>    - Why aren't roles always visible in the Web UI? For instance
>      the available roles drop down box is often unpopulated even
>      though they seem to be predefined in the source code. Why
>      aren't they available for assignment in the Web UI?
>
> * How does role mapping work?
>
>    - What is being mapped from and being mapped to?
>
>    - What is the intended usage for these mappings?
>
> * What does it mean to create a role in the Web UI? What is it
>    bound to?
>
>    - How do roles created in the Web UI relate to the predefined
>      roles?
>
>    - Why does the Web UI allow me to create a new role with the
>      same name as a predefined role? Are they the same role or is
>      there a collision?
>
> * What are effective roles?
>
>    - How are effective roles computed?
>
>    - In the Web UI I see lists for "Available Roles", "Assigned
>      Roles" and "Effective Roles". Sometimes I see a role in the
>      "Effective Roles" list which is not in the "Assigned Roles"
>      list. How and why does this happen?
>
> * What are composite roles?
>
>    - How and where are they defined?
>
>    - How are composite roles meant to be used?
>
>    - When looking at a list of roles in the Web UI how does one
>      identify a single role from a composite role?
>
> * What is the relationship between a Keycloak role and an OAuth2
>    scope?
>
> * Are roles related to users in any fashion or is a role bound
>    exclusively to a client (appearing only in the client's token).
>
>    - How do you authenticate as a user and acquire specific roles?
>
>    - Is it because a user grants a role via an OAuth scope which
>      is then conveyed in the client token?)
>
>    - If so how is it determined what roles a user is permitted to
>      grant?
>
>    - For example how is an admin user created? How are the fine
>      grained admin roles bound to a user and how are these roles
>      then conveyed in the token after an admin user authenticates?
>      (see next question)
>
> * The ClientRegistrationAuth.requireCreate() method requires the
>    bearer token from the realm administrator to have the
>    AdminRoles.MANAGE_CLIENTS or AdminRoles.CREATE_CLIENT roles in
>    the token, specifically in the resource_access part of the
>    token, but no matter what I do to add roles in the Web UI to a
>    realm admin the token roles remain unpopulated. How do these
>    roles get assigned and propagated in the token?
>
> * How does a client differ from an application?
>
>    - They seem to be closely related. How, why and when do you use
>      one vs. the other?
>
>    - The name "application" suggests they are external
>      applications which might be secured by Keycloak but that
>      doesn't seem to be the case, rather applications seem to be
>      internal Keycloak entities. Are applications called
>      applications because they are implemented as as servlets in
>      Keycloak?
>
>    - If so, is the reason applications are servlets is so their
>      endpoints can have their own authn and authz?
>
> * What are adapters?
>
> * What is a service account?
>
>    - How is a service account supposed to be used and for what
>      purpose?
>
>    - How is a service account created?
>
>    - How is a service account  authenticated?
>
> * How does OAuth2 client authentication work in Keycloak?
>
>    - Are public clients authenticated? The OAuth2 spec talks a lot
>      about the server authenticating the client but if the client
>      is a public client it's not clear to me how this is done. How
>      are public clients authenticated?
>
>
> --
> John
> _______________________________________________
> 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/20160322/fcd9ed5c/attachment.html 

From mposolda at redhat.com  Tue Mar 22 05:42:28 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Mar 2016 10:42:28 +0100
Subject: [keycloak-dev] Caching of identity provider links
Message-ID: <56F11384.8030608@redhat.com>

Until now, we don't have support for caching of identityProvider 
(social) links. So every social login or every going to "federated 
identities" tab in account management needs to send DB queries. I was 
looking at fixing it and I've send PR 
https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit 
tricky because of:

1) Caching needs to be done on both directions. For social login, you 
need to lookup user by social link. But on the other hand, you also need 
to look all social/identityProvider links of particular user when you go 
to account management etc.

2) Because of "store token" option, the link may need to be updated in 
DB quite often (in theory even during each social login).

I was thinking that storing links directly on CachedUser doesn't work 
very well, because during each update of social link (which may be often 
because of "store token") the user would need to be fully invalidated 
from cache. Having separate cache entry for each social link also has 
some downsides (many items in cache, need to have separate entry for 
store the all links of user anyway). So I ended up with having the cache 
entry, which contains list of all links of particular user. It needs to 
be updated when any social link is added,removed or updated. This seemed 
to me like good compromise. WDYT?

There are also entries for lookup user by federated identity, so you 
don't need to query DB during social login.

So ATM there are not DB queries during social login or during go to 
"federated identities" . I hope I handled all corner cases and 
invalidations correctly, but if someone want to take look it will be 
good. I don't want to add new regressions atm :-)

Marek







From sthorger at redhat.com  Tue Mar 22 06:48:22 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Mar 2016 10:48:22 +0000
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
References: <56E9DFB2.6070802@redhat.com>
	<CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
Message-ID: <CAJgngAe8XcD8ewpKMUhDB_ALjHAq3g4rNuBMums+ZMQJGStRrw@mail.gmail.com>

John, we could also schedule a call next week to go trough your questions.
Would be nice to meet in either case.
On 22 Mar 2016 07:40, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> That's a very long list of questions. Have you read through our
> documentation? I would hope it at least answers some of these questions. If
> not then breaking this list into smaller emails would make it easier to
> answer. Answering all these questions in one go is a fairly time consuming
> job.
>
> On 16 March 2016 at 22:35, John Dennis <jdennis at redhat.com> wrote:
>
>> I would appreciate having the following Keycloak concepts
>> explained. Many thanks in advance!
>>
>> * What are the predefined clients?
>>
>>    - When, why and where are you supposed to use these predefined
>>      clients?
>>
>> * What is the difference between realm roles and client roles?
>>
>>    - Why are realm roles and client roles distinct?
>>
>>    - How do they get assigned and for what purpose?
>>
>>    - Why aren't roles always visible in the Web UI? For instance
>>      the available roles drop down box is often unpopulated even
>>      though they seem to be predefined in the source code. Why
>>      aren't they available for assignment in the Web UI?
>>
>> * How does role mapping work?
>>
>>    - What is being mapped from and being mapped to?
>>
>>    - What is the intended usage for these mappings?
>>
>> * What does it mean to create a role in the Web UI? What is it
>>    bound to?
>>
>>    - How do roles created in the Web UI relate to the predefined
>>      roles?
>>
>>    - Why does the Web UI allow me to create a new role with the
>>      same name as a predefined role? Are they the same role or is
>>      there a collision?
>>
>> * What are effective roles?
>>
>>    - How are effective roles computed?
>>
>>    - In the Web UI I see lists for "Available Roles", "Assigned
>>      Roles" and "Effective Roles". Sometimes I see a role in the
>>      "Effective Roles" list which is not in the "Assigned Roles"
>>      list. How and why does this happen?
>>
>> * What are composite roles?
>>
>>    - How and where are they defined?
>>
>>    - How are composite roles meant to be used?
>>
>>    - When looking at a list of roles in the Web UI how does one
>>      identify a single role from a composite role?
>>
>> * What is the relationship between a Keycloak role and an OAuth2
>>    scope?
>>
>> * Are roles related to users in any fashion or is a role bound
>>    exclusively to a client (appearing only in the client's token).
>>
>>    - How do you authenticate as a user and acquire specific roles?
>>
>>    - Is it because a user grants a role via an OAuth scope which
>>      is then conveyed in the client token?)
>>
>>    - If so how is it determined what roles a user is permitted to
>>      grant?
>>
>>    - For example how is an admin user created? How are the fine
>>      grained admin roles bound to a user and how are these roles
>>      then conveyed in the token after an admin user authenticates?
>>      (see next question)
>>
>> * The ClientRegistrationAuth.requireCreate() method requires the
>>    bearer token from the realm administrator to have the
>>    AdminRoles.MANAGE_CLIENTS or AdminRoles.CREATE_CLIENT roles in
>>    the token, specifically in the resource_access part of the
>>    token, but no matter what I do to add roles in the Web UI to a
>>    realm admin the token roles remain unpopulated. How do these
>>    roles get assigned and propagated in the token?
>>
>> * How does a client differ from an application?
>>
>>    - They seem to be closely related. How, why and when do you use
>>      one vs. the other?
>>
>>    - The name "application" suggests they are external
>>      applications which might be secured by Keycloak but that
>>      doesn't seem to be the case, rather applications seem to be
>>      internal Keycloak entities. Are applications called
>>      applications because they are implemented as as servlets in
>>      Keycloak?
>>
>>    - If so, is the reason applications are servlets is so their
>>      endpoints can have their own authn and authz?
>>
>> * What are adapters?
>>
>> * What is a service account?
>>
>>    - How is a service account supposed to be used and for what
>>      purpose?
>>
>>    - How is a service account created?
>>
>>    - How is a service account  authenticated?
>>
>> * How does OAuth2 client authentication work in Keycloak?
>>
>>    - Are public clients authenticated? The OAuth2 spec talks a lot
>>      about the server authenticating the client but if the client
>>      is a public client it's not clear to me how this is done. How
>>      are public clients authenticated?
>>
>>
>> --
>> John
>> _______________________________________________
>> 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/20160322/fc8de5a8/attachment-0001.html 

From bburke at redhat.com  Tue Mar 22 10:18:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Mar 2016 10:18:02 -0400
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <56F11384.8030608@redhat.com>
References: <56F11384.8030608@redhat.com>
Message-ID: <56F1541A.6040706@redhat.com>

Some comments on code:

* Why have a special flag in invalidateUser?  Just invalidate the links 
if they exist.  Aggressive eviction isn't a bad thing, is it?

On a side note, cache needs more refactoring, we're reusing the same 
pattern over and over.  Wonder if functions can help.


On 3/22/2016 5:42 AM, Marek Posolda wrote:
> Until now, we don't have support for caching of identityProvider
> (social) links. So every social login or every going to "federated
> identities" tab in account management needs to send DB queries. I was
> looking at fixing it and I've send PR
> https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
> tricky because of:
>
> 1) Caching needs to be done on both directions. For social login, you
> need to lookup user by social link. But on the other hand, you also need
> to look all social/identityProvider links of particular user when you go
> to account management etc.
>
> 2) Because of "store token" option, the link may need to be updated in
> DB quite often (in theory even during each social login).
>
> I was thinking that storing links directly on CachedUser doesn't work
> very well, because during each update of social link (which may be often
> because of "store token") the user would need to be fully invalidated
> from cache. Having separate cache entry for each social link also has
> some downsides (many items in cache, need to have separate entry for
> store the all links of user anyway). So I ended up with having the cache
> entry, which contains list of all links of particular user. It needs to
> be updated when any social link is added,removed or updated. This seemed
> to me like good compromise. WDYT?
>
> There are also entries for lookup user by federated identity, so you
> don't need to query DB during social login.
>
> So ATM there are not DB queries during social login or during go to
> "federated identities" . I hope I handled all corner cases and
> invalidations correctly, but if someone want to take look it will be
> good. I don't want to add new regressions atm :-)
>
> 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 mposolda at redhat.com  Tue Mar 22 11:36:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Mar 2016 16:36:24 +0100
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <56F1541A.6040706@redhat.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
Message-ID: <56F16678.7020306@redhat.com>

On 22/03/16 15:18, Bill Burke wrote:
> Some comments on code:
>
> * Why have a special flag in invalidateUser?  Just invalidate the links
> if they exist.  Aggressive eviction isn't a bad thing, is it?
The only reason was performance. The flag "false" is used when you're 
adding new user. But this new user is not yet in cache, so calling 
"getFederatedIdentities" will always need to send DB query to get all 
links of user. But when you're adding new user, you know that this user 
doesn't yet have any social links. So in the end, without the flag there 
will be one more DB query, which will always return empty set.

Currently we don't support store/load of social links from federation 
provider. But maybe in the future, if we support it and we chain cache 
on top of federation storage, it could theoretically happen that new 
user have social links at the moment when he is registered. So I can do 
what you proposed as it seems to be a bit safer for the future.

Marek
>
> On a side note, cache needs more refactoring, we're reusing the same
> pattern over and over.  Wonder if functions can help.
>
>
> On 3/22/2016 5:42 AM, Marek Posolda wrote:
>> Until now, we don't have support for caching of identityProvider
>> (social) links. So every social login or every going to "federated
>> identities" tab in account management needs to send DB queries. I was
>> looking at fixing it and I've send PR
>> https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
>> tricky because of:
>>
>> 1) Caching needs to be done on both directions. For social login, you
>> need to lookup user by social link. But on the other hand, you also need
>> to look all social/identityProvider links of particular user when you go
>> to account management etc.
>>
>> 2) Because of "store token" option, the link may need to be updated in
>> DB quite often (in theory even during each social login).
>>
>> I was thinking that storing links directly on CachedUser doesn't work
>> very well, because during each update of social link (which may be often
>> because of "store token") the user would need to be fully invalidated
>> from cache. Having separate cache entry for each social link also has
>> some downsides (many items in cache, need to have separate entry for
>> store the all links of user anyway). So I ended up with having the cache
>> entry, which contains list of all links of particular user. It needs to
>> be updated when any social link is added,removed or updated. This seemed
>> to me like good compromise. WDYT?
>>
>> There are also entries for lookup user by federated identity, so you
>> don't need to query DB during social login.
>>
>> So ATM there are not DB queries during social login or during go to
>> "federated identities" . I hope I handled all corner cases and
>> invalidations correctly, but if someone want to take look it will be
>> good. I don't want to add new regressions atm :-)
>>
>> Marek
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Tue Mar 22 12:18:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Mar 2016 16:18:23 +0000
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <56F16678.7020306@redhat.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
Message-ID: <CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>

Is this really critical for 1.9.x? I'm worried about us intruding more
complexity so late and I'd rather postpone to 2.x.
On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com> wrote:

> On 22/03/16 15:18, Bill Burke wrote:
> > Some comments on code:
> >
> > * Why have a special flag in invalidateUser?  Just invalidate the links
> > if they exist.  Aggressive eviction isn't a bad thing, is it?
> The only reason was performance. The flag "false" is used when you're
> adding new user. But this new user is not yet in cache, so calling
> "getFederatedIdentities" will always need to send DB query to get all
> links of user. But when you're adding new user, you know that this user
> doesn't yet have any social links. So in the end, without the flag there
> will be one more DB query, which will always return empty set.
>
> Currently we don't support store/load of social links from federation
> provider. But maybe in the future, if we support it and we chain cache
> on top of federation storage, it could theoretically happen that new
> user have social links at the moment when he is registered. So I can do
> what you proposed as it seems to be a bit safer for the future.
>
> Marek
> >
> > On a side note, cache needs more refactoring, we're reusing the same
> > pattern over and over.  Wonder if functions can help.
> >
> >
> > On 3/22/2016 5:42 AM, Marek Posolda wrote:
> >> Until now, we don't have support for caching of identityProvider
> >> (social) links. So every social login or every going to "federated
> >> identities" tab in account management needs to send DB queries. I was
> >> looking at fixing it and I've send PR
> >> https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
> >> tricky because of:
> >>
> >> 1) Caching needs to be done on both directions. For social login, you
> >> need to lookup user by social link. But on the other hand, you also need
> >> to look all social/identityProvider links of particular user when you go
> >> to account management etc.
> >>
> >> 2) Because of "store token" option, the link may need to be updated in
> >> DB quite often (in theory even during each social login).
> >>
> >> I was thinking that storing links directly on CachedUser doesn't work
> >> very well, because during each update of social link (which may be often
> >> because of "store token") the user would need to be fully invalidated
> >> from cache. Having separate cache entry for each social link also has
> >> some downsides (many items in cache, need to have separate entry for
> >> store the all links of user anyway). So I ended up with having the cache
> >> entry, which contains list of all links of particular user. It needs to
> >> be updated when any social link is added,removed or updated. This seemed
> >> to me like good compromise. WDYT?
> >>
> >> There are also entries for lookup user by federated identity, so you
> >> don't need to query DB during social login.
> >>
> >> So ATM there are not DB queries during social login or during go to
> >> "federated identities" . I hope I handled all corner cases and
> >> invalidations correctly, but if someone want to take look it will be
> >> good. I don't want to add new regressions atm :-)
> >>
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160322/646fcb96/attachment.html 

From mposolda at redhat.com  Tue Mar 22 12:29:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Mar 2016 17:29:13 +0100
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
	<CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
Message-ID: <56F172D9.2050607@redhat.com>

Yeah, there might be some risk of regression. On the other hand, there 
are DB queries during each social login or every time when you click on 
"federated identities" in account management.

If you think missing caching is acceptable from performance perspective 
etc, I can merge just to master and avoid 1.9.x.

Marek

On 22/03/16 17:18, Stian Thorgersen wrote:
>
> Is this really critical for 1.9.x? I'm worried about us intruding more 
> complexity so late and I'd rather postpone to 2.x.
>
> On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 22/03/16 15:18, Bill Burke wrote:
>     > Some comments on code:
>     >
>     > * Why have a special flag in invalidateUser?  Just invalidate
>     the links
>     > if they exist.  Aggressive eviction isn't a bad thing, is it?
>     The only reason was performance. The flag "false" is used when you're
>     adding new user. But this new user is not yet in cache, so calling
>     "getFederatedIdentities" will always need to send DB query to get all
>     links of user. But when you're adding new user, you know that this
>     user
>     doesn't yet have any social links. So in the end, without the flag
>     there
>     will be one more DB query, which will always return empty set.
>
>     Currently we don't support store/load of social links from federation
>     provider. But maybe in the future, if we support it and we chain cache
>     on top of federation storage, it could theoretically happen that new
>     user have social links at the moment when he is registered. So I
>     can do
>     what you proposed as it seems to be a bit safer for the future.
>
>     Marek
>     >
>     > On a side note, cache needs more refactoring, we're reusing the same
>     > pattern over and over.  Wonder if functions can help.
>     >
>     >
>     > On 3/22/2016 5:42 AM, Marek Posolda wrote:
>     >> Until now, we don't have support for caching of identityProvider
>     >> (social) links. So every social login or every going to "federated
>     >> identities" tab in account management needs to send DB queries.
>     I was
>     >> looking at fixing it and I've send PR
>     >> https://github.com/keycloak/keycloak/pull/2404 . It turned to
>     be a bit
>     >> tricky because of:
>     >>
>     >> 1) Caching needs to be done on both directions. For social
>     login, you
>     >> need to lookup user by social link. But on the other hand, you
>     also need
>     >> to look all social/identityProvider links of particular user
>     when you go
>     >> to account management etc.
>     >>
>     >> 2) Because of "store token" option, the link may need to be
>     updated in
>     >> DB quite often (in theory even during each social login).
>     >>
>     >> I was thinking that storing links directly on CachedUser
>     doesn't work
>     >> very well, because during each update of social link (which may
>     be often
>     >> because of "store token") the user would need to be fully
>     invalidated
>     >> from cache. Having separate cache entry for each social link
>     also has
>     >> some downsides (many items in cache, need to have separate
>     entry for
>     >> store the all links of user anyway). So I ended up with having
>     the cache
>     >> entry, which contains list of all links of particular user. It
>     needs to
>     >> be updated when any social link is added,removed or updated.
>     This seemed
>     >> to me like good compromise. WDYT?
>     >>
>     >> There are also entries for lookup user by federated identity,
>     so you
>     >> don't need to query DB during social login.
>     >>
>     >> So ATM there are not DB queries during social login or during go to
>     >> "federated identities" . I hope I handled all corner cases and
>     >> invalidations correctly, but if someone want to take look it
>     will be
>     >> good. I don't want to add new regressions atm :-)
>     >>
>     >> Marek
>     >>
>     >>
>     >>
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> 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/20160322/d6e65c18/attachment-0001.html 

From sthorger at redhat.com  Tue Mar 22 12:50:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Mar 2016 16:50:58 +0000
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <56F172D9.2050607@redhat.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
	<CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
	<56F172D9.2050607@redhat.com>
Message-ID: <CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>

Ok, if Bill reviews and is happy to include in 1.9.x let's do it.
On 22 Mar 2016 16:29, "Marek Posolda" <mposolda at redhat.com> wrote:

> Yeah, there might be some risk of regression. On the other hand, there are
> DB queries during each social login or every time when you click on
> "federated identities" in account management.
>
> If you think missing caching is acceptable from performance perspective
> etc, I can merge just to master and avoid 1.9.x.
>
> Marek
>
> On 22/03/16 17:18, Stian Thorgersen wrote:
>
> Is this really critical for 1.9.x? I'm worried about us intruding more
> complexity so late and I'd rather postpone to 2.x.
> On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com> wrote:
>
>> On 22/03/16 15:18, Bill Burke wrote:
>> > Some comments on code:
>> >
>> > * Why have a special flag in invalidateUser?  Just invalidate the links
>> > if they exist.  Aggressive eviction isn't a bad thing, is it?
>> The only reason was performance. The flag "false" is used when you're
>> adding new user. But this new user is not yet in cache, so calling
>> "getFederatedIdentities" will always need to send DB query to get all
>> links of user. But when you're adding new user, you know that this user
>> doesn't yet have any social links. So in the end, without the flag there
>> will be one more DB query, which will always return empty set.
>>
>> Currently we don't support store/load of social links from federation
>> provider. But maybe in the future, if we support it and we chain cache
>> on top of federation storage, it could theoretically happen that new
>> user have social links at the moment when he is registered. So I can do
>> what you proposed as it seems to be a bit safer for the future.
>>
>> Marek
>> >
>> > On a side note, cache needs more refactoring, we're reusing the same
>> > pattern over and over.  Wonder if functions can help.
>> >
>> >
>> > On 3/22/2016 5:42 AM, Marek Posolda wrote:
>> >> Until now, we don't have support for caching of identityProvider
>> >> (social) links. So every social login or every going to "federated
>> >> identities" tab in account management needs to send DB queries. I was
>> >> looking at fixing it and I've send PR
>> >> https://github.com/keycloak/keycloak/pull/2404 . It turned to be a bit
>> >> tricky because of:
>> >>
>> >> 1) Caching needs to be done on both directions. For social login, you
>> >> need to lookup user by social link. But on the other hand, you also
>> need
>> >> to look all social/identityProvider links of particular user when you
>> go
>> >> to account management etc.
>> >>
>> >> 2) Because of "store token" option, the link may need to be updated in
>> >> DB quite often (in theory even during each social login).
>> >>
>> >> I was thinking that storing links directly on CachedUser doesn't work
>> >> very well, because during each update of social link (which may be
>> often
>> >> because of "store token") the user would need to be fully invalidated
>> >> from cache. Having separate cache entry for each social link also has
>> >> some downsides (many items in cache, need to have separate entry for
>> >> store the all links of user anyway). So I ended up with having the
>> cache
>> >> entry, which contains list of all links of particular user. It needs to
>> >> be updated when any social link is added,removed or updated. This
>> seemed
>> >> to me like good compromise. WDYT?
>> >>
>> >> There are also entries for lookup user by federated identity, so you
>> >> don't need to query DB during social login.
>> >>
>> >> So ATM there are not DB queries during social login or during go to
>> >> "federated identities" . I hope I handled all corner cases and
>> >> invalidations correctly, but if someone want to take look it will be
>> >> good. I don't want to add new regressions atm :-)
>> >>
>> >> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160322/2742ba9e/attachment.html 

From mposolda at redhat.com  Tue Mar 22 13:08:49 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Mar 2016 18:08:49 +0100
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
	<CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
	<56F172D9.2050607@redhat.com>
	<CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>
Message-ID: <56F17C21.4000205@redhat.com>

Just updated the PR with the removed flag from invalidateUsers, which 
Bill mentioned earlier - should be slightly cleaner now.

Marek


On 22/03/16 17:50, Stian Thorgersen wrote:
>
> Ok, if Bill reviews and is happy to include in 1.9.x let's do it.
>
> On 22 Mar 2016 16:29, "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Yeah, there might be some risk of regression. On the other hand,
>     there are DB queries during each social login or every time when
>     you click on "federated identities" in account management.
>
>     If you think missing caching is acceptable from performance
>     perspective etc, I can merge just to master and avoid 1.9.x.
>
>     Marek
>
>     On 22/03/16 17:18, Stian Thorgersen wrote:
>>
>>     Is this really critical for 1.9.x? I'm worried about us intruding
>>     more complexity so late and I'd rather postpone to 2.x.
>>
>>     On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 22/03/16 15:18, Bill Burke wrote:
>>         > Some comments on code:
>>         >
>>         > * Why have a special flag in invalidateUser? Just
>>         invalidate the links
>>         > if they exist.  Aggressive eviction isn't a bad thing, is it?
>>         The only reason was performance. The flag "false" is used
>>         when you're
>>         adding new user. But this new user is not yet in cache, so
>>         calling
>>         "getFederatedIdentities" will always need to send DB query to
>>         get all
>>         links of user. But when you're adding new user, you know that
>>         this user
>>         doesn't yet have any social links. So in the end, without the
>>         flag there
>>         will be one more DB query, which will always return empty set.
>>
>>         Currently we don't support store/load of social links from
>>         federation
>>         provider. But maybe in the future, if we support it and we
>>         chain cache
>>         on top of federation storage, it could theoretically happen
>>         that new
>>         user have social links at the moment when he is registered.
>>         So I can do
>>         what you proposed as it seems to be a bit safer for the future.
>>
>>         Marek
>>         >
>>         > On a side note, cache needs more refactoring, we're reusing
>>         the same
>>         > pattern over and over.  Wonder if functions can help.
>>         >
>>         >
>>         > On 3/22/2016 5:42 AM, Marek Posolda wrote:
>>         >> Until now, we don't have support for caching of
>>         identityProvider
>>         >> (social) links. So every social login or every going to
>>         "federated
>>         >> identities" tab in account management needs to send DB
>>         queries. I was
>>         >> looking at fixing it and I've send PR
>>         >> https://github.com/keycloak/keycloak/pull/2404 . It turned
>>         to be a bit
>>         >> tricky because of:
>>         >>
>>         >> 1) Caching needs to be done on both directions. For social
>>         login, you
>>         >> need to lookup user by social link. But on the other hand,
>>         you also need
>>         >> to look all social/identityProvider links of particular
>>         user when you go
>>         >> to account management etc.
>>         >>
>>         >> 2) Because of "store token" option, the link may need to
>>         be updated in
>>         >> DB quite often (in theory even during each social login).
>>         >>
>>         >> I was thinking that storing links directly on CachedUser
>>         doesn't work
>>         >> very well, because during each update of social link
>>         (which may be often
>>         >> because of "store token") the user would need to be fully
>>         invalidated
>>         >> from cache. Having separate cache entry for each social
>>         link also has
>>         >> some downsides (many items in cache, need to have separate
>>         entry for
>>         >> store the all links of user anyway). So I ended up with
>>         having the cache
>>         >> entry, which contains list of all links of particular
>>         user. It needs to
>>         >> be updated when any social link is added,removed or
>>         updated. This seemed
>>         >> to me like good compromise. WDYT?
>>         >>
>>         >> There are also entries for lookup user by federated
>>         identity, so you
>>         >> don't need to query DB during social login.
>>         >>
>>         >> So ATM there are not DB queries during social login or
>>         during go to
>>         >> "federated identities" . I hope I handled all corner cases and
>>         >> invalidations correctly, but if someone want to take look
>>         it will be
>>         >> good. I don't want to add new regressions atm :-)
>>         >>
>>         >> Marek
>>         >>
>>         >>
>>         >>
>>         >>
>>         >>
>>         >>
>>         >> _______________________________________________
>>         >> 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/20160322/f273a90f/attachment-0001.html 

From bburke at redhat.com  Tue Mar 22 13:17:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Mar 2016 13:17:49 -0400
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
	<CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
	<56F172D9.2050607@redhat.com>
	<CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>
Message-ID: <56F17E3D.1050705@redhat.com>

I had already reviewed it.  Adding another thing doesn't make the cache 
more complex as the same pattern/algorithm is pretty much repeated for 
each cached piece of data.  The risk is that we missed an edge case.

On 3/22/2016 12:50 PM, Stian Thorgersen wrote:
>
> Ok, if Bill reviews and is happy to include in 1.9.x let's do it.
>
> On 22 Mar 2016 16:29, "Marek Posolda" <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Yeah, there might be some risk of regression. On the other hand,
>     there are DB queries during each social login or every time when
>     you click on "federated identities" in account management.
>
>     If you think missing caching is acceptable from performance
>     perspective etc, I can merge just to master and avoid 1.9.x.
>
>     Marek
>
>     On 22/03/16 17:18, Stian Thorgersen wrote:
>>
>>     Is this really critical for 1.9.x? I'm worried about us intruding
>>     more complexity so late and I'd rather postpone to 2.x.
>>
>>     On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 22/03/16 15:18, Bill Burke wrote:
>>         > Some comments on code:
>>         >
>>         > * Why have a special flag in invalidateUser? Just
>>         invalidate the links
>>         > if they exist.  Aggressive eviction isn't a bad thing, is it?
>>         The only reason was performance. The flag "false" is used
>>         when you're
>>         adding new user. But this new user is not yet in cache, so
>>         calling
>>         "getFederatedIdentities" will always need to send DB query to
>>         get all
>>         links of user. But when you're adding new user, you know that
>>         this user
>>         doesn't yet have any social links. So in the end, without the
>>         flag there
>>         will be one more DB query, which will always return empty set.
>>
>>         Currently we don't support store/load of social links from
>>         federation
>>         provider. But maybe in the future, if we support it and we
>>         chain cache
>>         on top of federation storage, it could theoretically happen
>>         that new
>>         user have social links at the moment when he is registered.
>>         So I can do
>>         what you proposed as it seems to be a bit safer for the future.
>>
>>         Marek
>>         >
>>         > On a side note, cache needs more refactoring, we're reusing
>>         the same
>>         > pattern over and over.  Wonder if functions can help.
>>         >
>>         >
>>         > On 3/22/2016 5:42 AM, Marek Posolda wrote:
>>         >> Until now, we don't have support for caching of
>>         identityProvider
>>         >> (social) links. So every social login or every going to
>>         "federated
>>         >> identities" tab in account management needs to send DB
>>         queries. I was
>>         >> looking at fixing it and I've send PR
>>         >> https://github.com/keycloak/keycloak/pull/2404 . It turned
>>         to be a bit
>>         >> tricky because of:
>>         >>
>>         >> 1) Caching needs to be done on both directions. For social
>>         login, you
>>         >> need to lookup user by social link. But on the other hand,
>>         you also need
>>         >> to look all social/identityProvider links of particular
>>         user when you go
>>         >> to account management etc.
>>         >>
>>         >> 2) Because of "store token" option, the link may need to
>>         be updated in
>>         >> DB quite often (in theory even during each social login).
>>         >>
>>         >> I was thinking that storing links directly on CachedUser
>>         doesn't work
>>         >> very well, because during each update of social link
>>         (which may be often
>>         >> because of "store token") the user would need to be fully
>>         invalidated
>>         >> from cache. Having separate cache entry for each social
>>         link also has
>>         >> some downsides (many items in cache, need to have separate
>>         entry for
>>         >> store the all links of user anyway). So I ended up with
>>         having the cache
>>         >> entry, which contains list of all links of particular
>>         user. It needs to
>>         >> be updated when any social link is added,removed or
>>         updated. This seemed
>>         >> to me like good compromise. WDYT?
>>         >>
>>         >> There are also entries for lookup user by federated
>>         identity, so you
>>         >> don't need to query DB during social login.
>>         >>
>>         >> So ATM there are not DB queries during social login or
>>         during go to
>>         >> "federated identities" . I hope I handled all corner cases and
>>         >> invalidations correctly, but if someone want to take look
>>         it will be
>>         >> good. I don't want to add new regressions atm :-)
>>         >>
>>         >> Marek
>>         >>
>>         >>
>>         >>
>>         >>
>>         >>
>>         >>
>>         >> _______________________________________________
>>         >> 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
>>
>

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

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

From mposolda at redhat.com  Tue Mar 22 16:43:10 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Mar 2016 21:43:10 +0100
Subject: [keycloak-dev] Caching of identity provider links
In-Reply-To: <56F17E3D.1050705@redhat.com>
References: <56F11384.8030608@redhat.com> <56F1541A.6040706@redhat.com>
	<56F16678.7020306@redhat.com>
	<CAJgngAeRXYZ=ATromoj53ZJnWCdMeQM+ON6QLNskGdQam9Qd+A@mail.gmail.com>
	<56F172D9.2050607@redhat.com>
	<CAJgngAeBbyWapbZAob4BhXFRzokTGoFht8qE_qzc9sbJ87RtZg@mail.gmail.com>
	<56F17E3D.1050705@redhat.com>
Message-ID: <56F1AE5E.1060003@redhat.com>

Thanks, merged to 1.9.x and will be soon backported to master too.

Marek

On 22/03/16 18:17, Bill Burke wrote:
> I had already reviewed it.  Adding another thing doesn't make the 
> cache more complex as the same pattern/algorithm is pretty much 
> repeated for each cached piece of data.  The risk is that we missed an 
> edge case.
>
> On 3/22/2016 12:50 PM, Stian Thorgersen wrote:
>>
>> Ok, if Bill reviews and is happy to include in 1.9.x let's do it.
>>
>> On 22 Mar 2016 16:29, "Marek Posolda" <mposolda at redhat.com 
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     Yeah, there might be some risk of regression. On the other hand,
>>     there are DB queries during each social login or every time when
>>     you click on "federated identities" in account management.
>>
>>     If you think missing caching is acceptable from performance
>>     perspective etc, I can merge just to master and avoid 1.9.x.
>>
>>     Marek
>>
>>     On 22/03/16 17:18, Stian Thorgersen wrote:
>>>
>>>     Is this really critical for 1.9.x? I'm worried about us
>>>     intruding more complexity so late and I'd rather postpone to 2.x.
>>>
>>>     On 22 Mar 2016 15:36, "Marek Posolda" <mposolda at redhat.com
>>>     <mailto:mposolda at redhat.com>> wrote:
>>>
>>>         On 22/03/16 15:18, Bill Burke wrote:
>>>         > Some comments on code:
>>>         >
>>>         > * Why have a special flag in invalidateUser? Just
>>>         invalidate the links
>>>         > if they exist.  Aggressive eviction isn't a bad thing, is it?
>>>         The only reason was performance. The flag "false" is used
>>>         when you're
>>>         adding new user. But this new user is not yet in cache, so
>>>         calling
>>>         "getFederatedIdentities" will always need to send DB query
>>>         to get all
>>>         links of user. But when you're adding new user, you know
>>>         that this user
>>>         doesn't yet have any social links. So in the end, without
>>>         the flag there
>>>         will be one more DB query, which will always return empty set.
>>>
>>>         Currently we don't support store/load of social links from
>>>         federation
>>>         provider. But maybe in the future, if we support it and we
>>>         chain cache
>>>         on top of federation storage, it could theoretically happen
>>>         that new
>>>         user have social links at the moment when he is registered.
>>>         So I can do
>>>         what you proposed as it seems to be a bit safer for the future.
>>>
>>>         Marek
>>>         >
>>>         > On a side note, cache needs more refactoring, we're
>>>         reusing the same
>>>         > pattern over and over.  Wonder if functions can help.
>>>         >
>>>         >
>>>         > On 3/22/2016 5:42 AM, Marek Posolda wrote:
>>>         >> Until now, we don't have support for caching of
>>>         identityProvider
>>>         >> (social) links. So every social login or every going to
>>>         "federated
>>>         >> identities" tab in account management needs to send DB
>>>         queries. I was
>>>         >> looking at fixing it and I've send PR
>>>         >> https://github.com/keycloak/keycloak/pull/2404 . It
>>>         turned to be a bit
>>>         >> tricky because of:
>>>         >>
>>>         >> 1) Caching needs to be done on both directions. For
>>>         social login, you
>>>         >> need to lookup user by social link. But on the other
>>>         hand, you also need
>>>         >> to look all social/identityProvider links of particular
>>>         user when you go
>>>         >> to account management etc.
>>>         >>
>>>         >> 2) Because of "store token" option, the link may need to
>>>         be updated in
>>>         >> DB quite often (in theory even during each social login).
>>>         >>
>>>         >> I was thinking that storing links directly on CachedUser
>>>         doesn't work
>>>         >> very well, because during each update of social link
>>>         (which may be often
>>>         >> because of "store token") the user would need to be fully
>>>         invalidated
>>>         >> from cache. Having separate cache entry for each social
>>>         link also has
>>>         >> some downsides (many items in cache, need to have
>>>         separate entry for
>>>         >> store the all links of user anyway). So I ended up with
>>>         having the cache
>>>         >> entry, which contains list of all links of particular
>>>         user. It needs to
>>>         >> be updated when any social link is added,removed or
>>>         updated. This seemed
>>>         >> to me like good compromise. WDYT?
>>>         >>
>>>         >> There are also entries for lookup user by federated
>>>         identity, so you
>>>         >> don't need to query DB during social login.
>>>         >>
>>>         >> So ATM there are not DB queries during social login or
>>>         during go to
>>>         >> "federated identities" . I hope I handled all corner
>>>         cases and
>>>         >> invalidations correctly, but if someone want to take look
>>>         it will be
>>>         >> good. I don't want to add new regressions atm :-)
>>>         >>
>>>         >> Marek
>>>         >>
>>>         >>
>>>         >>
>>>         >>
>>>         >>
>>>         >>
>>>         >> _______________________________________________
>>>         >> 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
>>>
>>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

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

From mposolda at redhat.com  Thu Mar 24 03:50:03 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Mar 2016 08:50:03 +0100
Subject: [keycloak-dev] Default required actions and admin console
Message-ID: <56F39C2B.4010005@redhat.com>

Right now, when new user is registered through registration form, he is 
added with all default roles, default groups and default required actions.

But when new user is created through admin console (Admin REST API) then 
just default roles and default groups are added, but default required 
actions are not added (More precisely, they are added but then 
immediately removed at UsersResource.updateUserFromRep). This looks like 
a bug to me. IMO default required actions should be added too. WDYT?

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

From sthorger at redhat.com  Thu Mar 24 04:33:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 24 Mar 2016 08:33:42 +0000
Subject: [keycloak-dev] Default required actions and admin console
In-Reply-To: <56F39C2B.4010005@redhat.com>
References: <56F39C2B.4010005@redhat.com>
Message-ID: <CAJgngAeGyuinNcG3PoWj-Yyq-mRVoCaO+1x_0e-aXWjRRXQFxw@mail.gmail.com>

+1
On 24 Mar 2016 07:50, "Marek Posolda" <mposolda at redhat.com> wrote:

> Right now, when new user is registered through registration form, he is
> added with all default roles, default groups and default required actions.
>
> But when new user is created through admin console (Admin REST API) then
> just default roles and default groups are added, but default required
> actions are not added (More precisely, they are added but then immediately
> removed at UsersResource.updateUserFromRep). This looks like a bug to me.
> IMO default required actions should be added too. WDYT?
>
> Marek
>
> _______________________________________________
> 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/20160324/367966f1/attachment.html 

From psilva at redhat.com  Thu Mar 24 13:08:37 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 13:08:37 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <112747559.42706224.1458831450634.JavaMail.zimbra@redhat.com>
Message-ID: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>

Hi All and sorry for the long email.

    As you know, most AJAX frameworks send a X-Requested-With request header. This header is quite useful if you want to handle AJAX requests differently than ordinary HTTP requests.

    For most cases, the keycloak.js is the perfect tool to enable user authentication and token management to a client application using HTML5+AJAX. However, we may find use cases where client configuration is restricted and you can't change it very deeply to integrate with Keycloak.

    Well, yes. These are requirements from WildFly/EAP Console (a.k.a HAL) :)

    If you are not familiar about how the console works from a security PoV, you just need to know that there is no specific configuration to secure the console itself, but to secure the Domain Management API. In other words, the console isn't protected at all and relies on the policies defined to the Domain Management API and on the authentication that is performed by the browser (eg.: DIGEST). 

    (There are some reasons why the console isn't protected by the server. For instance, the server is only concerned about protecting the domain management API and also that the console is just one more client that can talk with that API.)

    The console is basically a GWT application using XMLHttpRequest to send requests to the server, where these requests are only accepted if they have some authentication/identity cookie (DIGEST, BASIC or Keycloak Identity Cookie) which can be handled by the browser and added to every single request to the server.

    Thanks to Elytron, we can now protect the Domain Management API with any HTTP mechanism we want without having to change wildfly-core or any other part of the server. In the past few days I've been working on a Keycloak OIDC Adapter based on Elytron APIs and using it to protected the Domain Management API using bearer tokens, which is working nicely. However, using the same adapter, we must also be able to "protect" the console and enable SSO. Which requires a different type of authentication based on a redirection-based flow (Authorization Code Grant).

    The XMLHttpRequest imposes some restrictions on how redirects can be handled, what makes hard to handle 302 status code and redirect the user to another resource. That said, I would like to propose a change to Keycloak OIDC adapters in order to better support XMLHttpRequest requests:

        - The adapter checks if the request contains a X-Requested-With=XMLHttpRequest. If so, returns a response with a 403 status code and an Authorization header as follows:

          Authorization: as_uri="http://localhost:8081/auth/realms/elytron/protocol/openid-connect/auth?response_type=code&client_id=wildfly-cli&redirect_uri=http%3A%2F%2Flocalhost%3A9990%2Fmanagement&state=2%2F0e177443-e160-49d4-8937-6c7a17a49e62%24%23http%3A%2F%2Flocalhost%3A9990%2Fconsole%2FApp.html&login=true"

          Where "as_uri" can be used by the client to actually redirect the user to the authorization server / keycloak server.

    The reason for a 403 and not a 401 is that some browsers will show a dialog if the server responds with a 401. So we are basically telling the client that the request was forbidden and that it must use "as_uri" to ask for authorization.

    One important thing about this approach is that is up to server to tell to the client where the authorization server is and how it should ask for authorization. The client is pretty much decoupled from the authorization server and just need to know about how to handle the Authorization header with the "as_uri" parameter.

    Any thoughts ?

Regards.
Pedro Igor    

    

From bburke at redhat.com  Thu Mar 24 14:02:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 14:02:52 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
Message-ID: <56F42BCC.8060804@redhat.com>



On 3/24/2016 1:08 PM, Pedro Igor Silva wrote:
> Hi All and sorry for the long email.
>
>      As you know, most AJAX frameworks send a X-Requested-With request header. This header is quite useful if you want to handle AJAX requests differently than ordinary HTTP requests.
>
>      For most cases, the keycloak.js is the perfect tool to enable user authentication and token management to a client application using HTML5+AJAX. However, we may find use cases where client configuration is restricted and you can't change it very deeply to integrate with Keycloak.
>
>      Well, yes. These are requirements from WildFly/EAP Console (a.k.a HAL) :)
>
>      If you are not familiar about how the console works from a security PoV, you just need to know that there is no specific configuration to secure the console itself, but to secure the Domain Management API. In other words, the console isn't protected at all and relies on the policies defined to the Domain Management API and on the authentication that is performed by the browser (eg.: DIGEST).
>
>      (There are some reasons why the console isn't protected by the server. For instance, the server is only concerned about protecting the domain management API and also that the console is just one more client that can talk with that API.)

That is really not different than our admin console.    There's no 
reason the Keycloak admin console couldn't be completely separated from 
the auth server and served up statically from a simple web server like 
Apache HTTPD.

>      The console is basically a GWT application using XMLHttpRequest to send requests to the server, where these requests are only accepted if they have some authentication/identity cookie (DIGEST, BASIC or Keycloak Identity Cookie) which can be handled by the browser and added to every single request to the server.
>
>      Thanks to Elytron, we can now protect the Domain Management API with any HTTP mechanism we want without having to change wildfly-core or any other part of the server. In the past few days I've been working on a Keycloak OIDC Adapter based on Elytron APIs and using it to protected the Domain Management API using bearer tokens, which is working nicely. However, using the same adapter, we must also be able to "protect" the console and enable SSO. Which requires a different type of authentication based on a redirection-based flow (Authorization Code Grant).
>
>      The XMLHttpRequest imposes some restrictions on how redirects can be handled, what makes hard to handle 302 status code and redirect the user to another resource. That said, I would like to propose a change to Keycloak OIDC adapters in order to better support XMLHttpRequest requests:
>
>          - The adapter checks if the request contains a X-Requested-With=XMLHttpRequest. If so, returns a response with a 403 status code and an Authorization header as follows:
>
>            Authorization: as_uri="http://localhost:8081/auth/realms/elytron/protocol/openid-connect/auth?response_type=code&client_id=wildfly-cli&redirect_uri=http%3A%2F%2Flocalhost%3A9990%2Fmanagement&state=2%2F0e177443-e160-49d4-8937-6c7a17a49e62%24%23http%3A%2F%2Flocalhost%3A9990%2Fconsole%2FApp.html&login=true"
>
>            Where "as_uri" can be used by the client to actually redirect the user to the authorization server / keycloak server.
>
>      The reason for a 403 and not a 401 is that some browsers will show a dialog if the server responds with a 401. So we are basically telling the client that the request was forbidden and that it must use "as_uri" to ask for authorization.
>
>      One important thing about this approach is that is up to server to tell to the client where the authorization server is and how it should ask for authorization. The client is pretty much decoupled from the authorization server and just need to know about how to handle the Authorization header with the "as_uri" parameter.
>
>      Any thoughts ?

I don't understand why you would need this.  Why can't the GWT 
application incorporate keycloak.js?  If their console app can't support 
keycloak.js or even a GWT adapter created by us, then they need to 
change.   If you can change the console to support this custom protocol, 
why can't you change it to use keycloak.js?

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


From ssilvert at redhat.com  Thu Mar 24 14:17:35 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 24 Mar 2016 14:17:35 -0400
Subject: [keycloak-dev] 2 Groups with same name?
Message-ID: <56F42F3F.6050205@redhat.com>

We currently allow more than one group to have the same name.  I realize 
that this is probably due to the fact that groups are hierarchical and 
you might want the same group name at different levels.

However, right now there are no restrictions at all.  You can have as 
many "foo" groups as you like even if they have the same parent. This 
causes a problem in the UI because you can't tell them apart.

Plus, apparently, KeycloakModelUtils.findGroupByPath() will return the 
first group it finds.  If there is more than one group with the same 
path then it might not return the group you are looking for.

It would make our code a lot simpler and less error-prone if we enforced 
that all group names be unique throughout.  But I don't know if that is 
to restrictive for users.  At the very least, two groups should probably 
not have the same path.

Thoughts?

Stan

From bburke at redhat.com  Thu Mar 24 14:22:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 14:22:28 -0400
Subject: [keycloak-dev] 2 Groups with same name?
In-Reply-To: <56F42F3F.6050205@redhat.com>
References: <56F42F3F.6050205@redhat.com>
Message-ID: <56F43064.3090705@redhat.com>

Groups should be able to have the same name, but different parents.

i.e.

/Engineering/Managers
/Sales/Managers

If you want to fix the other scenarios to deny same group name in same 
folder(parent), then feel free.  Just know you have to implement it for 
moving groups as well as creating.

On 3/24/2016 2:17 PM, Stan Silvert wrote:
> We currently allow more than one group to have the same name.  I realize
> that this is probably due to the fact that groups are hierarchical and
> you might want the same group name at different levels.
>
> However, right now there are no restrictions at all.  You can have as
> many "foo" groups as you like even if they have the same parent. This
> causes a problem in the UI because you can't tell them apart.
>
> Plus, apparently, KeycloakModelUtils.findGroupByPath() will return the
> first group it finds.  If there is more than one group with the same
> path then it might not return the group you are looking for.
>
> It would make our code a lot simpler and less error-prone if we enforced
> that all group names be unique throughout.  But I don't know if that is
> to restrictive for users.  At the very least, two groups should probably
> not have the same path.
>
> Thoughts?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From psilva at redhat.com  Thu Mar 24 15:01:31 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 15:01:31 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <56F42BCC.8060804@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
Message-ID: <516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 3:02:52 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> That is really not different than our admin console.    There's no
> reason the Keycloak admin console couldn't be completely separated from
> the auth server and served up statically from a simple web server like
> Apache HTTPD.

Yeah, from a client perspective they are the same thing. Just a client trying to access resources protected with a bearer token.

> 
> 
> I don't understand why you would need this.  Why can't the GWT
> application incorporate keycloak.js?  If their console app can't support
> keycloak.js or even a GWT adapter created by us, then they need to
> change.   If you can change the console to support this custom protocol,
> why can't you change it to use keycloak.js?

I did the same question when I started this HAL/Keycloak SSO task. But I did it differently: Why not handle the console just like any other OAuth2 client ?

Some time ago I had some discussions around that where I proposed two approaches to try to solve this problem:

    1) Change HAL to support OAuth2. Which is aligned with your question. In this case, HAL would behave just like any other OAuth2 client using Authorization Code Grant to obtain access tokens and sending them as bearer tokens to the management API.

    2) Minimize changes to HAL and focus on fixing the redirection issue I mentioned before. In this case, we need some very minimal changes to HAL which are basically around dealing with a HTTP header, nothing else. No need to change wildfly-core (where the console is actually installed) or change/add any other configuration specific to the console in order to get it protected or create a specific HAL distribution that can SSO with KC. Beside all that, AFAIK HAL can not have a dependency to Keycloak and may support other authentication mechanisms, such as DIGEST, etc.

Everyone agreed that #1 would be the "right" thing to do, but #2 is more aligned with what WildFly/EAP/HAL teams are willing to do at this regard.

So, back to your question and in addition to what I just mentioned, IMO #2 also provides a nice addition to Keycloak OIDC Adapters. Specially for use cases where the front-end (client) and the back-end (RESTful API) are in the same package (as you said in our F2F meeting, people are still doing that) or even when the client doesn't care if the server is using OAuth2, BASIC, DIGEST, CLIENT_CERT, etc. In other words, it just relies on the server and on the authentication provided by the browser using authentication/identity cookies.

In the latter case, that is exactly how I got SSO working with HAL and Keycloak, where the adapter(from a Elytron/WildFly perspective, the right term would the Keycloak Authentication Mechanism) is configured to use a cookie store (but it can work with a session store as well).

Honestly, for me I'm just fine with #1 and I wouldn't be here, writing this email, if the decision was a "got for it" :)

For last, there are one more thing about this "new protocol" that I want to discuss. But I think we should get some agreement first about what we are discussing right now ...

> 
> --
> 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 psilva at redhat.com  Thu Mar 24 15:09:36 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 15:09:36 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
Message-ID: <257546836.42839105.1458846576603.JavaMail.zimbra@redhat.com>

Btw, the Keycloak Adapter I did based on Elytron is not specific to GWT. It is just a regular OIDC adapter ...

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, March 24, 2016 4:01:31 PM
Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 3:02:52 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> That is really not different than our admin console.    There's no
> reason the Keycloak admin console couldn't be completely separated from
> the auth server and served up statically from a simple web server like
> Apache HTTPD.

Yeah, from a client perspective they are the same thing. Just a client trying to access resources protected with a bearer token.

> 
> 
> I don't understand why you would need this.  Why can't the GWT
> application incorporate keycloak.js?  If their console app can't support
> keycloak.js or even a GWT adapter created by us, then they need to
> change.   If you can change the console to support this custom protocol,
> why can't you change it to use keycloak.js?

I did the same question when I started this HAL/Keycloak SSO task. But I did it differently: Why not handle the console just like any other OAuth2 client ?

Some time ago I had some discussions around that where I proposed two approaches to try to solve this problem:

    1) Change HAL to support OAuth2. Which is aligned with your question. In this case, HAL would behave just like any other OAuth2 client using Authorization Code Grant to obtain access tokens and sending them as bearer tokens to the management API.

    2) Minimize changes to HAL and focus on fixing the redirection issue I mentioned before. In this case, we need some very minimal changes to HAL which are basically around dealing with a HTTP header, nothing else. No need to change wildfly-core (where the console is actually installed) or change/add any other configuration specific to the console in order to get it protected or create a specific HAL distribution that can SSO with KC. Beside all that, AFAIK HAL can not have a dependency to Keycloak and may support other authentication mechanisms, such as DIGEST, etc.

Everyone agreed that #1 would be the "right" thing to do, but #2 is more aligned with what WildFly/EAP/HAL teams are willing to do at this regard.

So, back to your question and in addition to what I just mentioned, IMO #2 also provides a nice addition to Keycloak OIDC Adapters. Specially for use cases where the front-end (client) and the back-end (RESTful API) are in the same package (as you said in our F2F meeting, people are still doing that) or even when the client doesn't care if the server is using OAuth2, BASIC, DIGEST, CLIENT_CERT, etc. In other words, it just relies on the server and on the authentication provided by the browser using authentication/identity cookies.

In the latter case, that is exactly how I got SSO working with HAL and Keycloak, where the adapter(from a Elytron/WildFly perspective, the right term would the Keycloak Authentication Mechanism) is configured to use a cookie store (but it can work with a session store as well).

Honestly, for me I'm just fine with #1 and I wouldn't be here, writing this email, if the decision was a "got for it" :)

For last, there are one more thing about this "new protocol" that I want to discuss. But I think we should get some agreement first about what we are discussing right now ...

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

From bburke at redhat.com  Thu Mar 24 15:25:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 15:25:44 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
Message-ID: <56F43F38.4000208@redhat.com>



On 3/24/2016 3:01 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 3:02:52 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>> That is really not different than our admin console.    There's no
>> reason the Keycloak admin console couldn't be completely separated from
>> the auth server and served up statically from a simple web server like
>> Apache HTTPD.
> Yeah, from a client perspective they are the same thing. Just a client trying to access resources protected with a bearer token.
>
>>
>> I don't understand why you would need this.  Why can't the GWT
>> application incorporate keycloak.js?  If their console app can't support
>> keycloak.js or even a GWT adapter created by us, then they need to
>> change.   If you can change the console to support this custom protocol,
>> why can't you change it to use keycloak.js?
> I did the same question when I started this HAL/Keycloak SSO task. But I did it differently: Why not handle the console just like any other OAuth2 client ?
>
> Some time ago I had some discussions around that where I proposed two approaches to try to solve this problem:
>
>      1) Change HAL to support OAuth2. Which is aligned with your question. In this case, HAL would behave just like any other OAuth2 client using Authorization Code Grant to obtain access tokens and sending them as bearer tokens to the management API.
>
>      2) Minimize changes to HAL and focus on fixing the redirection issue I mentioned before. In this case, we need some very minimal changes to HAL which are basically around dealing with a HTTP header, nothing else. No need to change wildfly-core (where the console is actually installed) or change/add any other configuration specific to the console in order to get it protected or create a specific HAL distribution that can SSO with KC. Beside all that, AFAIK HAL can not have a dependency to Keycloak and may support other authentication mechanisms, such as DIGEST, etc.
>
> Everyone agreed that #1 would be the "right" thing to do, but #2 is more aligned with what WildFly/EAP/HAL teams are willing to do at this regard.
>
> So, back to your question and in addition to what I just mentioned, IMO #2 also provides a nice addition to Keycloak OIDC Adapters. Specially for use cases where the front-end (client) and the back-end (RESTful API) are in the same package (as you said in our F2F meeting, people are still doing that) or even when the client doesn't care if the server is using OAuth2, BASIC, DIGEST, CLIENT_CERT, etc. In other words, it just relies on the server and on the authentication provided by the browser using authentication/identity cookies.
>
> In the latter case, that is exactly how I got SSO working with HAL and Keycloak, where the adapter(from a Elytron/WildFly perspective, the right term would the Keycloak Authentication Mechanism) is configured to use a cookie store (but it can work with a session store as well).
>
> Honestly, for me I'm just fine with #1 and I wouldn't be here, writing this email, if the decision was a "got for it" :)
>
> For last, there are one more thing about this "new protocol" that I want to discuss. But I think we should get some agreement first about what we are discussing right now ...

#1, IMO the wildfly console team needs to make the console securable via 
SAML and/or OIDC. We can't be doing these one-off hack protocols just 
because these teams don't want to take the time to integrate properly.  
I'm sure there are already customers that want to integrate an existing 
non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit 
about DIGEST.  Everybody wants to integrate with an SSO solution.

That being said, I don't understand how this new protocol you are 
suggestion works. Can you walk through it again with which side is doing 
what?  (GWT vs. REST API).  At first glance, it looks like it is really 
vulnerable to CSRF attacks and is even vulnerable to stealing the token 
directly.  But again, maybe I'm not understanding what you want to do.

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


From bburke at redhat.com  Thu Mar 24 15:47:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 15:47:31 -0400
Subject: [keycloak-dev] got detached from git branch? How?
Message-ID: <56F44453.3070207@redhat.com>

Ok,

I've been struggling with GIT today.  For some reason, my 1.9.x branch 
clone and my master clone got detached.  I'm assuming it is because of 
the rebasing I did as this has never happened to me before...

So on that note...screw this rebasing shit.  I'm sick of wasting time 
re-applying commits every time I screw things up.   I'm just too stupid 
and incompetent to use this feature of git.

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


From psilva at redhat.com  Thu Mar 24 16:28:31 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 16:28:31 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <56F43F38.4000208@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
Message-ID: <347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 4:25:44 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> 
> #1, IMO the wildfly console team needs to make the console securable via
> SAML and/or OIDC. We can't be doing these one-off hack protocols just
> because these teams don't want to take the time to integrate properly.
> I'm sure there are already customers that want to integrate an existing
> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
> about DIGEST.  Everybody wants to integrate with an SSO solution.

That is fine as long as everybody is happy. I'm open to get back on step back and get a agreement about #1 or #2.

Integration with third-party OIDC and SAML is something #1 can do using nothing but what the standards define.

Regarding DIGEST, it is just one of the different http authentication mechanism supported by WildFly/EAP. Elytron is adding even more to this list. For instance, SCRAM. There are different use cases out there ...

> 
> That being said, I don't understand how this new protocol you are
> suggestion works. Can you walk through it again with which side is doing
> what?  (GWT vs. REST API).  At first glance, it looks like it is really
> vulnerable to CSRF attacks and is even vulnerable to stealing the token
> directly.  But again, maybe I'm not understanding what you want to do.

Well, it is not really a one-off hack. Actually, I've used something similar to what UMA provides in order to tell clients which AS they should go.

There is no adapter on the client side, but only on the RS side. Beside that, the client was designed to rely on a authentication/identity cookie in order to secure requests and get things from the RS.

The flow is:

1) Client asks a protected resource to the RS
2) The adapter running on the RS side identifies that the request contains a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there is no authentication info associated with the request
3) Instead of responding with a 302 redirect, the adapter sends back a response with a 403 status code and an Authorization header containing the "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing special here
4) Client extract the Authorization header from the response and redirect the user to an URI as specified in "as_uri"
5) User provides his credentials to the AS and if the authentication is successful, he is redirected back to the RS
6) The adapter running on the RS side now creates an identity cookie or a session based on the response from the AS. Again, nothing new here.
7) The adapter redirect the user back to the client application URI based on some information on the original request (eg.: a redirect_uri parameter sent during step #1), where the URI of the client must be valid and provided via adapter configuration (something like a second valid URI check, but at the RS side).

Basically, I'm using 302 instead of 403 and doing a second redirect to get the user back to the client application. Where the client URI must be provided via adapter config and will be always validated.

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

From bburke at redhat.com  Thu Mar 24 16:50:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 16:50:58 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
Message-ID: <56F45332.5030002@redhat.com>



On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 4:25:44 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>>
>> #1, IMO the wildfly console team needs to make the console securable via
>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
>> because these teams don't want to take the time to integrate properly.
>> I'm sure there are already customers that want to integrate an existing
>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
>> about DIGEST.  Everybody wants to integrate with an SSO solution.
> That is fine as long as everybody is happy. I'm open to get back on step back and get a agreement about #1 or #2.
>
> Integration with third-party OIDC and SAML is something #1 can do using nothing but what the standards define.
>
> Regarding DIGEST, it is just one of the different http authentication mechanism supported by WildFly/EAP. Elytron is adding even more to this list. For instance, SCRAM. There are different use cases out there ...

This is a console problem and not an Elytron issue.  How did the console 
authenticate before?

>> That being said, I don't understand how this new protocol you are
>> suggestion works. Can you walk through it again with which side is doing
>> what?  (GWT vs. REST API).  At first glance, it looks like it is really
>> vulnerable to CSRF attacks and is even vulnerable to stealing the token
>> directly.  But again, maybe I'm not understanding what you want to do.
> Well, it is not really a one-off hack. Actually, I've used something similar to what UMA provides in order to tell clients which AS they should go.
>
> There is no adapter on the client side, but only on the RS side. Beside that, the client was designed to rely on a authentication/identity cookie in order to secure requests and get things from the RS.
>
> The flow is:
>
> 1) Client asks a protected resource to the RS
> 2) The adapter running on the RS side identifies that the request contains a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there is no authentication info associated with the request
> 3) Instead of responding with a 302 redirect, the adapter sends back a response with a 403 status code and an Authorization header containing the "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing special here
> 4) Client extract the Authorization header from the response and redirect the user to an URI as specified in "as_uri"

In step #4 you have to modify the client console anyways.  Why not just 
do the right thing here? instead of this custom protocol?

> 5) User provides his credentials to the AS and if the authentication is successful, he is redirected back to the RS
> 6) The adapter running on the RS side now creates an identity cookie or a session based on the response from the AS. Again, nothing new here.

Nothing new here?  We do not recommend, in fact, we discourage Keycloak 
users from using cookie authentication for authenticating REST XHR requests.
> 7) The adapter redirect the user back to the client application URI based on some information on the original request (eg.: a redirect_uri parameter sent during step #1), where the URI of the client must be valid and provided via adapter configuration (something like a second valid URI check, but at the RS side).
>
> Basically, I'm using 302 instead of 403 and doing a second redirect to get the user back to the client application. Where the client URI must be provided via adapter config and will be always validated.

Unless the RS is set up to check the origin via CORS, using cookie 
authentication for REST XHR requests is vulnerable to CSRF attacks.

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


From mposolda at redhat.com  Thu Mar 24 16:51:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Mar 2016 21:51:54 +0100
Subject: [keycloak-dev] got detached from git branch? How?
In-Reply-To: <56F44453.3070207@redhat.com>
References: <56F44453.3070207@redhat.com>
Message-ID: <56F4536A.4070608@redhat.com>

The fact you are detached is not anything bad. You can at any time check 
your commit history with command:

git log --pretty=oneline --graph

If history looks good and commits looks as you expected, you can at any 
time drop your local "master" branch and promote your current branch to 
the new local "master" branch. Just do 2 commands like:
git branch -D master
git checkout -b master
git status

Last command should show that you're again "atached" to master branch. 
Note this needs to be done carefully as you drop your previous local 
"master" branch and all commits in it.

Marek


On 24/03/16 20:47, Bill Burke wrote:
> Ok,
>
> I've been struggling with GIT today.  For some reason, my 1.9.x branch
> clone and my master clone got detached.  I'm assuming it is because of
> the rebasing I did as this has never happened to me before...
>
> So on that note...screw this rebasing shit.  I'm sick of wasting time
> re-applying commits every time I screw things up.   I'm just too stupid
> and incompetent to use this feature of git.
>


From mposolda at redhat.com  Thu Mar 24 16:57:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Mar 2016 21:57:13 +0100
Subject: [keycloak-dev] got detached from git branch? How?
In-Reply-To: <56F4536A.4070608@redhat.com>
References: <56F44453.3070207@redhat.com> <56F4536A.4070608@redhat.com>
Message-ID: <56F454A9.3070808@redhat.com>

Btv. if you have some time, I suggest to look at 
https://git-scm.com/book/en/v2/Git-on-the-Server-Summary and especially 
chapter 3 . This is what Bolek suggested few years ago when we started 
with git on GateIn. Chapter 3 rocks and is likely sufficient to 
understand whole the git history and stuff around rebasing, merging, 
branching etc.

Marek

On 24/03/16 21:51, Marek Posolda wrote:
> The fact you are detached is not anything bad. You can at any time check
> your commit history with command:
>
> git log --pretty=oneline --graph
>
> If history looks good and commits looks as you expected, you can at any
> time drop your local "master" branch and promote your current branch to
> the new local "master" branch. Just do 2 commands like:
> git branch -D master
> git checkout -b master
> git status
>
> Last command should show that you're again "atached" to master branch.
> Note this needs to be done carefully as you drop your previous local
> "master" branch and all commits in it.
>
> Marek
>
>
> On 24/03/16 20:47, Bill Burke wrote:
>> Ok,
>>
>> I've been struggling with GIT today.  For some reason, my 1.9.x branch
>> clone and my master clone got detached.  I'm assuming it is because of
>> the rebasing I did as this has never happened to me before...
>>
>> So on that note...screw this rebasing shit.  I'm sick of wasting time
>> re-applying commits every time I screw things up.   I'm just too stupid
>> and incompetent to use this feature of git.
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Thu Mar 24 17:19:51 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 17:19:51 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <56F45332.5030002@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
Message-ID: <1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 5:50:58 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> 
> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, March 24, 2016 4:25:44 PM
> >> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>
> >>
> >>
> >> #1, IMO the wildfly console team needs to make the console securable via
> >> SAML and/or OIDC. We can't be doing these one-off hack protocols just
> >> because these teams don't want to take the time to integrate properly.
> >> I'm sure there are already customers that want to integrate an existing
> >> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
> >> about DIGEST.  Everybody wants to integrate with an SSO solution.
> > That is fine as long as everybody is happy. I'm open to get back on step
> > back and get a agreement about #1 or #2.
> >
> > Integration with third-party OIDC and SAML is something #1 can do using
> > nothing but what the standards define.
> >
> > Regarding DIGEST, it is just one of the different http authentication
> > mechanism supported by WildFly/EAP. Elytron is adding even more to this
> > list. For instance, SCRAM. There are different use cases out there ...
> 
> This is a console problem and not an Elytron issue.  How did the console
> authenticate before?

Today, the console uses DIGEST by default and relies on the browser to handle that.

When the console sends a request to the mgmt API with no authentication info, the mgmt api responds with a 401 WWW-Authenticate. So the browser will show that dialog and handle both authentication and subsequent requests to the server.

> 
> >> That being said, I don't understand how this new protocol you are
> >> suggestion works. Can you walk through it again with which side is doing
> >> what?  (GWT vs. REST API).  At first glance, it looks like it is really
> >> vulnerable to CSRF attacks and is even vulnerable to stealing the token
> >> directly.  But again, maybe I'm not understanding what you want to do.
> > Well, it is not really a one-off hack. Actually, I've used something
> > similar to what UMA provides in order to tell clients which AS they should
> > go.
> >
> > There is no adapter on the client side, but only on the RS side. Beside
> > that, the client was designed to rely on a authentication/identity cookie
> > in order to secure requests and get things from the RS.
> >
> > The flow is:
> >
> > 1) Client asks a protected resource to the RS
> > 2) The adapter running on the RS side identifies that the request contains
> > a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there
> > is no authentication info associated with the request
> > 3) Instead of responding with a 302 redirect, the adapter sends back a
> > response with a 403 status code and an Authorization header containing the
> > "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
> > special here
> > 4) Client extract the Authorization header from the response and redirect
> > the user to an URI as specified in "as_uri"
> 
> In step #4 you have to modify the client console anyways.  Why not just
> do the right thing here? instead of this custom protocol?

Sure, but those changes are very minimal if compared to what may be necessary to do the "right" thing. Just like I mentioned before.

I'll reopen a thread where I was discussing this topic with the HAL team. Let's start that discussion next week.

> 
> > 5) User provides his credentials to the AS and if the authentication is
> > successful, he is redirected back to the RS
> > 6) The adapter running on the RS side now creates an identity cookie or a
> > session based on the response from the AS. Again, nothing new here.
> 
> Nothing new here?  We do not recommend, in fact, we discourage Keycloak
> users from using cookie authentication for authenticating REST XHR requests.
> > 7) The adapter redirect the user back to the client application URI based
> > on some information on the original request (eg.: a redirect_uri parameter
> > sent during step #1), where the URI of the client must be valid and
> > provided via adapter configuration (something like a second valid URI
> > check, but at the RS side).
> >
> > Basically, I'm using 302 instead of 403 and doing a second redirect to get
> > the user back to the client application. Where the client URI must be
> > provided via adapter config and will be always validated.
> 
> Unless the RS is set up to check the origin via CORS, using cookie
> authentication for REST XHR requests is vulnerable to CSRF attacks.

Yeah, but the idea is to enforce a same-origin policy.

Regardless of what we decide, the good thing about all that is that we have everything from both Elytron and Keycloak side (specially from the former) to secure both console and management API. Specially the management API, which can be 100% covered with bearer tokens. It is up to client to send them :)

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

From psilva at redhat.com  Thu Mar 24 17:20:01 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 17:20:01 -0400 (EDT)
Subject: [keycloak-dev] got detached from git branch? How?
In-Reply-To: <56F44453.3070207@redhat.com>
References: <56F44453.3070207@redhat.com>
Message-ID: <1353652292.42931253.1458854401883.JavaMail.zimbra@redhat.com>

Impossible ! A simple rebase will never defeat Bill Burke :)

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, March 24, 2016 4:47:31 PM
Subject: [keycloak-dev] got detached from git branch? How?

Ok,

I've been struggling with GIT today.  For some reason, my 1.9.x branch 
clone and my master clone got detached.  I'm assuming it is because of 
the rebasing I did as this has never happened to me before...

So on that note...screw this rebasing shit.  I'm sick of wasting time 
re-applying commits every time I screw things up.   I'm just too stupid 
and incompetent to use this feature of git.

-- 
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 Mar 24 17:36:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 17:36:11 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
	<1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
Message-ID: <56F45DCB.3030108@redhat.com>



On 3/24/2016 5:19 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 5:50:58 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>>
>> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, March 24, 2016 4:25:44 PM
>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>
>>>>
>>>>
>>>> #1, IMO the wildfly console team needs to make the console securable via
>>>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
>>>> because these teams don't want to take the time to integrate properly.
>>>> I'm sure there are already customers that want to integrate an existing
>>>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
>>>> about DIGEST.  Everybody wants to integrate with an SSO solution.
>>> That is fine as long as everybody is happy. I'm open to get back on step
>>> back and get a agreement about #1 or #2.
>>>
>>> Integration with third-party OIDC and SAML is something #1 can do using
>>> nothing but what the standards define.
>>>
>>> Regarding DIGEST, it is just one of the different http authentication
>>> mechanism supported by WildFly/EAP. Elytron is adding even more to this
>>> list. For instance, SCRAM. There are different use cases out there ...
>> This is a console problem and not an Elytron issue.  How did the console
>> authenticate before?
> Today, the console uses DIGEST by default and relies on the browser to handle that.

Yeah, that's unacceptable.  Can't expect real authentication to work 
that way.

> When the console sends a request to the mgmt API with no authentication info, the mgmt api responds with a 401 WWW-Authenticate. So the browser will show that dialog and handle both authentication and subsequent requests to the server.

>>>> That being said, I don't understand how this new protocol you are
>>>> suggestion works. Can you walk through it again with which side is doing
>>>> what?  (GWT vs. REST API).  At first glance, it looks like it is really
>>>> vulnerable to CSRF attacks and is even vulnerable to stealing the token
>>>> directly.  But again, maybe I'm not understanding what you want to do.
>>> Well, it is not really a one-off hack. Actually, I've used something
>>> similar to what UMA provides in order to tell clients which AS they should
>>> go.
>>>
>>> There is no adapter on the client side, but only on the RS side. Beside
>>> that, the client was designed to rely on a authentication/identity cookie
>>> in order to secure requests and get things from the RS.
>>>
>>> The flow is:
>>>
>>> 1) Client asks a protected resource to the RS
>>> 2) The adapter running on the RS side identifies that the request contains
>>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there
>>> is no authentication info associated with the request
>>> 3) Instead of responding with a 302 redirect, the adapter sends back a
>>> response with a 403 status code and an Authorization header containing the
>>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
>>> special here
>>> 4) Client extract the Authorization header from the response and redirect
>>> the user to an URI as specified in "as_uri"
>> In step #4 you have to modify the client console anyways.  Why not just
>> do the right thing here? instead of this custom protocol?
> Sure, but those changes are very minimal if compared to what may be necessary to do the "right" thing. Just like I mentioned before.
>
> I'll reopen a thread where I was discussing this topic with the HAL team. Let's start that discussion next week.

You don't need to do much, just integrate keycloak.js.  We already have 
an adapter for javascript.

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


From psilva at redhat.com  Thu Mar 24 17:40:42 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 17:40:42 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <56F45DCB.3030108@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
	<1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
	<56F45DCB.3030108@redhat.com>
Message-ID: <22344635.42935541.1458855642152.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 6:36:11 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> 
> On 3/24/2016 5:19 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, March 24, 2016 5:50:58 PM
> >> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>
> >>
> >>
> >> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, March 24, 2016 4:25:44 PM
> >>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>>>
> >>>>
> >>>>
> >>>> #1, IMO the wildfly console team needs to make the console securable via
> >>>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
> >>>> because these teams don't want to take the time to integrate properly.
> >>>> I'm sure there are already customers that want to integrate an existing
> >>>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
> >>>> about DIGEST.  Everybody wants to integrate with an SSO solution.
> >>> That is fine as long as everybody is happy. I'm open to get back on step
> >>> back and get a agreement about #1 or #2.
> >>>
> >>> Integration with third-party OIDC and SAML is something #1 can do using
> >>> nothing but what the standards define.
> >>>
> >>> Regarding DIGEST, it is just one of the different http authentication
> >>> mechanism supported by WildFly/EAP. Elytron is adding even more to this
> >>> list. For instance, SCRAM. There are different use cases out there ...
> >> This is a console problem and not an Elytron issue.  How did the console
> >> authenticate before?
> > Today, the console uses DIGEST by default and relies on the browser to
> > handle that.
> 
> Yeah, that's unacceptable.  Can't expect real authentication to work
> that way.
> 
> > When the console sends a request to the mgmt API with no authentication
> > info, the mgmt api responds with a 401 WWW-Authenticate. So the browser
> > will show that dialog and handle both authentication and subsequent
> > requests to the server.
> 
> >>>> That being said, I don't understand how this new protocol you are
> >>>> suggestion works. Can you walk through it again with which side is doing
> >>>> what?  (GWT vs. REST API).  At first glance, it looks like it is really
> >>>> vulnerable to CSRF attacks and is even vulnerable to stealing the token
> >>>> directly.  But again, maybe I'm not understanding what you want to do.
> >>> Well, it is not really a one-off hack. Actually, I've used something
> >>> similar to what UMA provides in order to tell clients which AS they
> >>> should
> >>> go.
> >>>
> >>> There is no adapter on the client side, but only on the RS side. Beside
> >>> that, the client was designed to rely on a authentication/identity cookie
> >>> in order to secure requests and get things from the RS.
> >>>
> >>> The flow is:
> >>>
> >>> 1) Client asks a protected resource to the RS
> >>> 2) The adapter running on the RS side identifies that the request
> >>> contains
> >>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there
> >>> is no authentication info associated with the request
> >>> 3) Instead of responding with a 302 redirect, the adapter sends back a
> >>> response with a 403 status code and an Authorization header containing
> >>> the
> >>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
> >>> special here
> >>> 4) Client extract the Authorization header from the response and redirect
> >>> the user to an URI as specified in "as_uri"
> >> In step #4 you have to modify the client console anyways.  Why not just
> >> do the right thing here? instead of this custom protocol?
> > Sure, but those changes are very minimal if compared to what may be
> > necessary to do the "right" thing. Just like I mentioned before.
> >
> > I'll reopen a thread where I was discussing this topic with the HAL team.
> > Let's start that discussion next week.
> 
> You don't need to do much, just integrate keycloak.js.  We already have
> an adapter for javascript.

Let's see. I'm not a GWT expert so I don't have a clue about how to do that. But I'm sure HAL team will support us if we go through this path.

Beside that, we may even come up with a statndard-based solution for the console. SO they can work with any OAuth2/OIDC provider.

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

From bburke at redhat.com  Thu Mar 24 18:18:04 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Mar 2016 18:18:04 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <22344635.42935541.1458855642152.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F42BCC.8060804@redhat.com>
	<516532438.42834585.1458846091097.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
	<1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
	<56F45DCB.3030108@redhat.com>
	<22344635.42935541.1458855642152.JavaMail.zimbra@redhat.com>
Message-ID: <56F4679C.8010609@redhat.com>



On 3/24/2016 5:40 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 6:36:11 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>>
>> On 3/24/2016 5:19 PM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, March 24, 2016 5:50:58 PM
>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>
>>>>
>>>>
>>>> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, March 24, 2016 4:25:44 PM
>>>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>>>
>>>>>>
>>>>>>
>>>>>> #1, IMO the wildfly console team needs to make the console securable via
>>>>>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
>>>>>> because these teams don't want to take the time to integrate properly.
>>>>>> I'm sure there are already customers that want to integrate an existing
>>>>>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a shit
>>>>>> about DIGEST.  Everybody wants to integrate with an SSO solution.
>>>>> That is fine as long as everybody is happy. I'm open to get back on step
>>>>> back and get a agreement about #1 or #2.
>>>>>
>>>>> Integration with third-party OIDC and SAML is something #1 can do using
>>>>> nothing but what the standards define.
>>>>>
>>>>> Regarding DIGEST, it is just one of the different http authentication
>>>>> mechanism supported by WildFly/EAP. Elytron is adding even more to this
>>>>> list. For instance, SCRAM. There are different use cases out there ...
>>>> This is a console problem and not an Elytron issue.  How did the console
>>>> authenticate before?
>>> Today, the console uses DIGEST by default and relies on the browser to
>>> handle that.
>> Yeah, that's unacceptable.  Can't expect real authentication to work
>> that way.
>>
>>> When the console sends a request to the mgmt API with no authentication
>>> info, the mgmt api responds with a 401 WWW-Authenticate. So the browser
>>> will show that dialog and handle both authentication and subsequent
>>> requests to the server.
>>>>>> That being said, I don't understand how this new protocol you are
>>>>>> suggestion works. Can you walk through it again with which side is doing
>>>>>> what?  (GWT vs. REST API).  At first glance, it looks like it is really
>>>>>> vulnerable to CSRF attacks and is even vulnerable to stealing the token
>>>>>> directly.  But again, maybe I'm not understanding what you want to do.
>>>>> Well, it is not really a one-off hack. Actually, I've used something
>>>>> similar to what UMA provides in order to tell clients which AS they
>>>>> should
>>>>> go.
>>>>>
>>>>> There is no adapter on the client side, but only on the RS side. Beside
>>>>> that, the client was designed to rely on a authentication/identity cookie
>>>>> in order to secure requests and get things from the RS.
>>>>>
>>>>> The flow is:
>>>>>
>>>>> 1) Client asks a protected resource to the RS
>>>>> 2) The adapter running on the RS side identifies that the request
>>>>> contains
>>>>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there
>>>>> is no authentication info associated with the request
>>>>> 3) Instead of responding with a 302 redirect, the adapter sends back a
>>>>> response with a 403 status code and an Authorization header containing
>>>>> the
>>>>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
>>>>> special here
>>>>> 4) Client extract the Authorization header from the response and redirect
>>>>> the user to an URI as specified in "as_uri"
>>>> In step #4 you have to modify the client console anyways.  Why not just
>>>> do the right thing here? instead of this custom protocol?
>>> Sure, but those changes are very minimal if compared to what may be
>>> necessary to do the "right" thing. Just like I mentioned before.
>>>
>>> I'll reopen a thread where I was discussing this topic with the HAL team.
>>> Let's start that discussion next week.
>> You don't need to do much, just integrate keycloak.js.  We already have
>> an adapter for javascript.
> Let's see. I'm not a GWT expert so I don't have a clue about how to do that. But I'm sure HAL team will support us if we go through this path.
>
> Beside that, we may even come up with a statndard-based solution for the console. SO they can work with any OAuth2/OIDC provider.

Brother...Argue with me if you don't agree.   Given that I can't even 
manage to master GIT, what makes you think I'm right here?

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


From psilva at redhat.com  Thu Mar 24 19:46:32 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 24 Mar 2016 19:46:32 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <56F4679C.8010609@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
	<1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
	<56F45DCB.3030108@redhat.com>
	<22344635.42935541.1458855642152.JavaMail.zimbra@redhat.com>
	<56F4679C.8010609@redhat.com>
Message-ID: <1254107111.42963068.1458863192317.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, March 24, 2016 7:18:04 PM
> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> 
> 
> 
> On 3/24/2016 5:40 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, March 24, 2016 6:36:11 PM
> >> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>
> >>
> >>
> >> On 3/24/2016 5:19 PM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, March 24, 2016 5:50:58 PM
> >>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>>>
> >>>>
> >>>>
> >>>> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Thursday, March 24, 2016 4:25:44 PM
> >>>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> #1, IMO the wildfly console team needs to make the console securable
> >>>>>> via
> >>>>>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
> >>>>>> because these teams don't want to take the time to integrate properly.
> >>>>>> I'm sure there are already customers that want to integrate an
> >>>>>> existing
> >>>>>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a
> >>>>>> shit
> >>>>>> about DIGEST.  Everybody wants to integrate with an SSO solution.
> >>>>> That is fine as long as everybody is happy. I'm open to get back on
> >>>>> step
> >>>>> back and get a agreement about #1 or #2.
> >>>>>
> >>>>> Integration with third-party OIDC and SAML is something #1 can do using
> >>>>> nothing but what the standards define.
> >>>>>
> >>>>> Regarding DIGEST, it is just one of the different http authentication
> >>>>> mechanism supported by WildFly/EAP. Elytron is adding even more to this
> >>>>> list. For instance, SCRAM. There are different use cases out there ...
> >>>> This is a console problem and not an Elytron issue.  How did the console
> >>>> authenticate before?
> >>> Today, the console uses DIGEST by default and relies on the browser to
> >>> handle that.
> >> Yeah, that's unacceptable.  Can't expect real authentication to work
> >> that way.
> >>
> >>> When the console sends a request to the mgmt API with no authentication
> >>> info, the mgmt api responds with a 401 WWW-Authenticate. So the browser
> >>> will show that dialog and handle both authentication and subsequent
> >>> requests to the server.
> >>>>>> That being said, I don't understand how this new protocol you are
> >>>>>> suggestion works. Can you walk through it again with which side is
> >>>>>> doing
> >>>>>> what?  (GWT vs. REST API).  At first glance, it looks like it is
> >>>>>> really
> >>>>>> vulnerable to CSRF attacks and is even vulnerable to stealing the
> >>>>>> token
> >>>>>> directly.  But again, maybe I'm not understanding what you want to do.
> >>>>> Well, it is not really a one-off hack. Actually, I've used something
> >>>>> similar to what UMA provides in order to tell clients which AS they
> >>>>> should
> >>>>> go.
> >>>>>
> >>>>> There is no adapter on the client side, but only on the RS side. Beside
> >>>>> that, the client was designed to rely on a authentication/identity
> >>>>> cookie
> >>>>> in order to secure requests and get things from the RS.
> >>>>>
> >>>>> The flow is:
> >>>>>
> >>>>> 1) Client asks a protected resource to the RS
> >>>>> 2) The adapter running on the RS side identifies that the request
> >>>>> contains
> >>>>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that
> >>>>> there
> >>>>> is no authentication info associated with the request
> >>>>> 3) Instead of responding with a 302 redirect, the adapter sends back a
> >>>>> response with a 403 status code and an Authorization header containing
> >>>>> the
> >>>>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
> >>>>> special here
> >>>>> 4) Client extract the Authorization header from the response and
> >>>>> redirect
> >>>>> the user to an URI as specified in "as_uri"
> >>>> In step #4 you have to modify the client console anyways.  Why not just
> >>>> do the right thing here? instead of this custom protocol?
> >>> Sure, but those changes are very minimal if compared to what may be
> >>> necessary to do the "right" thing. Just like I mentioned before.
> >>>
> >>> I'll reopen a thread where I was discussing this topic with the HAL team.
> >>> Let's start that discussion next week.
> >> You don't need to do much, just integrate keycloak.js.  We already have
> >> an adapter for javascript.
> > Let's see. I'm not a GWT expert so I don't have a clue about how to do
> > that. But I'm sure HAL team will support us if we go through this path.
> >
> > Beside that, we may even come up with a statndard-based solution for the
> > console. SO they can work with any OAuth2/OIDC provider.
> 
> Brother...Argue with me if you don't agree.   Given that I can't even
> manage to master GIT, what makes you think I'm right here?

Well, I think I did answer your question already. We have the same feeling about which path would be the best to go.

However, I'm looking at both sides and I'm trying to find a balance. I don't think my proposal brings complexity or is useless, but right now it is being driven by a single use case, the console. On the contrary, I think it can help to address use cases with similar requirements. Actually, it was fairly easy to enable SSO and get the console integrated with KC using only the configuration and some very minor changes to the console code.

I think that the next step is get you into the loop and reopen the discussion about #1 and #2. I think is worthy to do that and make sure everybody is aligned.

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

From bburke at redhat.com  Fri Mar 25 09:20:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Mar 2016 09:20:15 -0400
Subject: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
In-Reply-To: <1254107111.42963068.1458863192317.JavaMail.zimbra@redhat.com>
References: <1853963032.42780036.1458839317703.JavaMail.zimbra@redhat.com>
	<56F43F38.4000208@redhat.com>
	<347455356.42896593.1458851311483.JavaMail.zimbra@redhat.com>
	<56F45332.5030002@redhat.com>
	<1922841613.42931195.1458854391439.JavaMail.zimbra@redhat.com>
	<56F45DCB.3030108@redhat.com>
	<22344635.42935541.1458855642152.JavaMail.zimbra@redhat.com>
	<56F4679C.8010609@redhat.com>
	<1254107111.42963068.1458863192317.JavaMail.zimbra@redhat.com>
Message-ID: <56F53B0F.4040101@redhat.com>



On 3/24/2016 7:46 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, March 24, 2016 7:18:04 PM
>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>
>>
>>
>> On 3/24/2016 5:40 PM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, March 24, 2016 6:36:11 PM
>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>
>>>>
>>>>
>>>> On 3/24/2016 5:19 PM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, March 24, 2016 5:50:58 PM
>>>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 3/24/2016 4:28 PM, Pedro Igor Silva wrote:
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Thursday, March 24, 2016 4:25:44 PM
>>>>>>>> Subject: Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> #1, IMO the wildfly console team needs to make the console securable
>>>>>>>> via
>>>>>>>> SAML and/or OIDC. We can't be doing these one-off hack protocols just
>>>>>>>> because these teams don't want to take the time to integrate properly.
>>>>>>>> I'm sure there are already customers that want to integrate an
>>>>>>>> existing
>>>>>>>> non-Keycloak SSO solution with the Wildfly console.  Nobody gives a
>>>>>>>> shit
>>>>>>>> about DIGEST.  Everybody wants to integrate with an SSO solution.
>>>>>>> That is fine as long as everybody is happy. I'm open to get back on
>>>>>>> step
>>>>>>> back and get a agreement about #1 or #2.
>>>>>>>
>>>>>>> Integration with third-party OIDC and SAML is something #1 can do using
>>>>>>> nothing but what the standards define.
>>>>>>>
>>>>>>> Regarding DIGEST, it is just one of the different http authentication
>>>>>>> mechanism supported by WildFly/EAP. Elytron is adding even more to this
>>>>>>> list. For instance, SCRAM. There are different use cases out there ...
>>>>>> This is a console problem and not an Elytron issue.  How did the console
>>>>>> authenticate before?
>>>>> Today, the console uses DIGEST by default and relies on the browser to
>>>>> handle that.
>>>> Yeah, that's unacceptable.  Can't expect real authentication to work
>>>> that way.
>>>>
>>>>> When the console sends a request to the mgmt API with no authentication
>>>>> info, the mgmt api responds with a 401 WWW-Authenticate. So the browser
>>>>> will show that dialog and handle both authentication and subsequent
>>>>> requests to the server.
>>>>>>>> That being said, I don't understand how this new protocol you are
>>>>>>>> suggestion works. Can you walk through it again with which side is
>>>>>>>> doing
>>>>>>>> what?  (GWT vs. REST API).  At first glance, it looks like it is
>>>>>>>> really
>>>>>>>> vulnerable to CSRF attacks and is even vulnerable to stealing the
>>>>>>>> token
>>>>>>>> directly.  But again, maybe I'm not understanding what you want to do.
>>>>>>> Well, it is not really a one-off hack. Actually, I've used something
>>>>>>> similar to what UMA provides in order to tell clients which AS they
>>>>>>> should
>>>>>>> go.
>>>>>>>
>>>>>>> There is no adapter on the client side, but only on the RS side. Beside
>>>>>>> that, the client was designed to rely on a authentication/identity
>>>>>>> cookie
>>>>>>> in order to secure requests and get things from the RS.
>>>>>>>
>>>>>>> The flow is:
>>>>>>>
>>>>>>> 1) Client asks a protected resource to the RS
>>>>>>> 2) The adapter running on the RS side identifies that the request
>>>>>>> contains
>>>>>>> a 'X-Requested-With' header with a value 'XMLHttpRequest' and that
>>>>>>> there
>>>>>>> is no authentication info associated with the request
>>>>>>> 3) Instead of responding with a 302 redirect, the adapter sends back a
>>>>>>> response with a 403 status code and an Authorization header containing
>>>>>>> the
>>>>>>> "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing
>>>>>>> special here
>>>>>>> 4) Client extract the Authorization header from the response and
>>>>>>> redirect
>>>>>>> the user to an URI as specified in "as_uri"
>>>>>> In step #4 you have to modify the client console anyways.  Why not just
>>>>>> do the right thing here? instead of this custom protocol?
>>>>> Sure, but those changes are very minimal if compared to what may be
>>>>> necessary to do the "right" thing. Just like I mentioned before.
>>>>>
>>>>> I'll reopen a thread where I was discussing this topic with the HAL team.
>>>>> Let's start that discussion next week.
>>>> You don't need to do much, just integrate keycloak.js.  We already have
>>>> an adapter for javascript.
>>> Let's see. I'm not a GWT expert so I don't have a clue about how to do
>>> that. But I'm sure HAL team will support us if we go through this path.
>>>
>>> Beside that, we may even come up with a statndard-based solution for the
>>> console. SO they can work with any OAuth2/OIDC provider.
>> Brother...Argue with me if you don't agree.   Given that I can't even
>> manage to master GIT, what makes you think I'm right here?
> Well, I think I did answer your question already. We have the same feeling about which path would be the best to go.
>
> However, I'm looking at both sides and I'm trying to find a balance. I don't think my proposal brings complexity or is useless, but right now it is being driven by a single use case, the console. On the contrary, I think it can help to address use cases with similar requirements. Actually, it was fairly easy to enable SSO and get the console integrated with KC using only the configuration and some very minor changes to the console code.
>
> I think that the next step is get you into the loop and reopen the discussion about #1 and #2. I think is worthy to do that and make sure everybody is aligned.

It would actually help Keycloak project to integrate keycloak.js into 
the console because then we would have a recipe for integrating with GWT 
apps.

That being said, the admin console used to work very similarly before we 
had a javascript adapter.  We need to research CORS and CSRF to make 
sure that this is a viable solution.


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


From nafiux at gmail.com  Fri Mar 25 15:33:57 2016
From: nafiux at gmail.com (Ignacio Ocampo)
Date: Fri, 25 Mar 2016 12:33:57 -0700
Subject: [keycloak-dev] Keycloak 1.9.1.Final- failed verification of token:
	Token is not active
Message-ID: <CAAGqNkm-1D+nuGnwSDeLbyVBZaogiL1vdV67BOL7Kem8Oie58w@mail.gmail.com>

Hello team,

I'm trying to connect a Spring App Keycloak, but I get this error:

After I enter to my app, and I was redirected to Keycloak for
authentication, I receive an error in my browser:

192.168.1.66 redirected you too many times.

Full url

URL: http://192.168.1.66:9092/keycloak-sp-example/sso/login?state=139%2F1ed115fb-4d4f-468c-9a72-845f9cfa9cdb&code=PVGhg5X28G8fjNt36tMGHTJIP7CQdHOhoK4XhPgUh3E.2d885db5-5c4f-43b1-9095-305494718a97

And, in the console, I got:

ERROR org.keycloak.adapters.OAuthRequestAuthenticator - failed
verification of token: Token is not active.

It's a bug? Or is anything that I should configure in the console?

Thanks in advance.
http://stackoverflow.com/questions/36226647/keycloak-1-9-1-final-failed-verification-of-token-token-is-not-active

-- 
Ignacio Ocampo Mill?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160325/a56e6347/attachment.html 

From nafiux at gmail.com  Fri Mar 25 17:19:07 2016
From: nafiux at gmail.com (Ignacio Ocampo)
Date: Fri, 25 Mar 2016 14:19:07 -0700
Subject: [keycloak-dev] Keycloak 1.9.1.Final- failed verification of
	token: Token is not active
In-Reply-To: <CAAGqNkm-1D+nuGnwSDeLbyVBZaogiL1vdV67BOL7Kem8Oie58w@mail.gmail.com>
References: <CAAGqNkm-1D+nuGnwSDeLbyVBZaogiL1vdV67BOL7Kem8Oie58w@mail.gmail.com>
Message-ID: <CAAGqNkniyeXghU0NSLgyq3ZdotjR-Z+yktC6UW+nm6z3dL4gjg@mail.gmail.com>

I found the problem, I was testing the product in a virtual machine without
the correct time zone configured.

Thanks

On Fri, Mar 25, 2016 at 12:33 PM, Ignacio Ocampo <nafiux at gmail.com> wrote:

> Hello team,
>
> I'm trying to connect a Spring App Keycloak, but I get this error:
>
> After I enter to my app, and I was redirected to Keycloak for
> authentication, I receive an error in my browser:
>
> 192.168.1.66 redirected you too many times.
>
> Full url
>
> URL: http://192.168.1.66:9092/keycloak-sp-example/sso/login?state=139%2F1ed115fb-4d4f-468c-9a72-845f9cfa9cdb&code=PVGhg5X28G8fjNt36tMGHTJIP7CQdHOhoK4XhPgUh3E.2d885db5-5c4f-43b1-9095-305494718a97
>
> And, in the console, I got:
>
> ERROR org.keycloak.adapters.OAuthRequestAuthenticator - failed verification of token: Token is not active.
>
> It's a bug? Or is anything that I should configure in the console?
>
> Thanks in advance.
>
> http://stackoverflow.com/questions/36226647/keycloak-1-9-1-final-failed-verification-of-token-token-is-not-active
>
> --
> Ignacio Ocampo Mill?n
>



-- 
Ignacio Ocampo Mill?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160325/b9c02513/attachment-0001.html 

From psilva at redhat.com  Tue Mar 29 21:47:04 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 29 Mar 2016 21:47:04 -0400 (EDT)
Subject: [keycloak-dev] Async HTTP Request Processing
In-Reply-To: <533432794.44917091.1459300075428.JavaMail.zimbra@redhat.com>
Message-ID: <1830946258.44924585.1459302424666.JavaMail.zimbra@redhat.com>

Hi,

    I'm working with the AuthZ Java API in order to make it more event-driven and non-blocking. During our F2F, I've discussed some very interesting requirements with Marc Savy around that.

    I would like to know if makes sense to enable JAX-RS Async support to some AuthZ REST endpoints, which are basically using this API to evaluate policies using different providers (where these providers can be executed in parallel).

Regards.
Pedro Igor

From prabhalar at yahoo.com  Tue Mar 29 21:57:33 2016
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Wed, 30 Mar 2016 01:57:33 +0000 (UTC)
Subject: [keycloak-dev] Async HTTP Request Processing
In-Reply-To: <1830946258.44924585.1459302424666.JavaMail.zimbra@redhat.com>
References: <1830946258.44924585.1459302424666.JavaMail.zimbra@redhat.com>
Message-ID: <597548124.123268.1459303053944.JavaMail.yahoo@mail.yahoo.com>

+1. Makes sense for even KC (as Identity broker waiting for a response from Identity provider or as Identity provider waiting for a response from Authenticators)

      From: Pedro Igor Silva <psilva at redhat.com>
 To: keycloak-dev <keycloak-dev at lists.jboss.org> 
 Sent: Tuesday, March 29, 2016 9:47 PM
 Subject: [keycloak-dev] Async HTTP Request Processing
   
Hi,

? ? I'm working with the AuthZ Java API in order to make it more event-driven and non-blocking. During our F2F, I've discussed some very interesting requirements with Marc Savy around that.

? ? I would like to know if makes sense to enable JAX-RS Async support to some AuthZ REST endpoints, which are basically using this API to evaluate policies using different providers (where these providers can be executed in parallel).

Regards.
Pedro Igor
_______________________________________________
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/20160330/65b4ef24/attachment.html 

From jayapriya.atheesan at gmail.com  Wed Mar 30 02:13:24 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Wed, 30 Mar 2016 11:43:24 +0530
Subject: [keycloak-dev] 403 Forbidden when invoking application secured with
	keycloak
Message-ID: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>

Hi,

 

Greetings of the day !!

 

I need an urgent help from your team.

 

I have an application deployed in wildfly server. The same has been secured
with keycloak server(this runs of a different wildfly box).

The wildfly server has been configured with keycloak adapter. 

 

When I invoke a page from the application deployed in wildfly server, the
application , redirects to keycloak login page. After I click submit
entering user name and password, I get 403 forbidden error.

 

Is there a way to enable logs for keycloak adapter. I'm not getting any logs
related to this error.

 

The issue is similar to the one addressed in
http://lists.jboss.org/pipermail/keycloak-user/2015-February/001601.html

http://lists.jboss.org/pipermail/keycloak-user/2014-November/001280.html

 

Please help me in resolving the same.

 

Below are the details of the server :

Wildfly 9.0.0CR2

Keycloak 1.6.0 Final

 

Thanks,

Jayapriya Atheesan

 

 

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

From mposolda at redhat.com  Wed Mar 30 03:12:28 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Mar 2016 09:12:28 +0200
Subject: [keycloak-dev] 403 Forbidden when invoking application secured
 with keycloak
In-Reply-To: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>
References: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>
Message-ID: <56FB7C5C.60000@redhat.com>

It looks that your user either doesn't have roles or your client doesn't 
have scope. Take a look at examples for more inspiration. For logging, 
you can enable DEBUG logging for category "org.keycloak" in 
standalone/configuration/standalone.xml

Marek

On 30/03/16 08:13, JAYAPRIYA ATHEESAN wrote:
>
> Hi,
>
> Greetings of the day !!
>
> I need an urgent help from your team.
>
> I have an application deployed in wildfly server. The same has been 
> secured with keycloak server(this runs of a different wildfly box).
>
> The wildfly server has been configured with keycloak adapter.
>
> When I invoke a page from the application deployed in wildfly server, 
> the application , redirects to keycloak login page. After I click 
> submit  entering user name and password, I get 403 forbidden error.
>
> Is there a way to enable logs for keycloak adapter. I?m not getting 
> any logs related to this error.
>
> The issue is similar to the one addressed in 
> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001601.html
>
> http://lists.jboss.org/pipermail/keycloak-user/2014-November/001280.html
>
> Please help me in resolving the same.
>
> Below are the details of the server :
>
> Wildfly 9.0.0CR2
>
> Keycloak 1.6.0 Final
>
> Thanks,
>
> Jayapriya Atheesan
>
>
>
> _______________________________________________
> 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/20160330/d30032c9/attachment.html 

From jayapriya.atheesan at gmail.com  Wed Mar 30 03:50:55 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Wed, 30 Mar 2016 13:20:55 +0530
Subject: [keycloak-dev] 403 Forbidden when invoking application secured
	with keycloak
In-Reply-To: <56FB7C5C.60000@redhat.com>
References: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>
	<56FB7C5C.60000@redhat.com>
Message-ID: <56fb8565.8443620a.2b7ed.ffff9530@mx.google.com>

Hi Marek,

 

Thanks for your response.

 

Already I have set a role in keycloak application as giggzouser and I have
set the same in my web.xml file.



After enabling the logs, it shows up this

 

2016-03-30 03:39:26,843 DEBUG [org.keycloak.adapters.PreAuthActionsHandler]
(default task-7) adminRequest
http://hostname:8080/appname/rest/giggzoLogin/userLogin

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.undertow.KeycloakUndertowAccount] (default task-7)
session is active

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.undertow.ServletSessionTokenStore] (default task-7)
Cached account found

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-7)
propagate security context to wildfly

2016-03-30 03:39:26,845 DEBUG [org.keycloak.adapters.RequestAuthenticator]
(default task-7) AUTHENTICATED: was cached

2016-03-30 03:39:26,846 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-7)
AuthenticatedActionsValve.invoke http ://hostname:8080/appname
/rest/giggzoLogin/userLogin

 

After which, I get forbidden on screen.

 

Please find the web.xml file attached to this mail.

 

Thanks,

Jayapriya Atheesan

 

From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Wednesday, March 30, 2016 12:42 PM
To: JAYAPRIYA ATHEESAN; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] 403 Forbidden when invoking application secured
with keycloak

 

It looks that your user either doesn't have roles or your client doesn't
have scope. Take a look at examples for more inspiration. For logging, you
can enable DEBUG logging for category "org.keycloak" in
standalone/configuration/standalone.xml

Marek

On 30/03/16 08:13, JAYAPRIYA ATHEESAN wrote:

Hi,

 

Greetings of the day !!

 

I need an urgent help from your team.

 

I have an application deployed in wildfly server. The same has been secured
with keycloak server(this runs of a different wildfly box).

The wildfly server has been configured with keycloak adapter. 

 

When I invoke a page from the application deployed in wildfly server, the
application , redirects to keycloak login page. After I click submit
entering user name and password, I get 403 forbidden error.

 

Is there a way to enable logs for keycloak adapter. I'm not getting any logs
related to this error.

 

The issue is similar to the one addressed in
http://lists.jboss.org/pipermail/keycloak-user/2015-February/001601.html

http://lists.jboss.org/pipermail/keycloak-user/2014-November/001280.html

 

Please help me in resolving the same.

 

Below are the details of the server :

Wildfly 9.0.0CR2

Keycloak 1.6.0 Final

 

Thanks,

Jayapriya Atheesan

 

 






_______________________________________________
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/20160330/4bac1825/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 28433 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160330/4bac1825/attachment-0001.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: web.xml
Type: text/xml
Size: 12197 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160330/4bac1825/attachment-0001.xml 

From jayapriya.atheesan at gmail.com  Wed Mar 30 03:55:08 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Wed, 30 Mar 2016 13:25:08 +0530
Subject: [keycloak-dev] 403 Forbidden when invoking application secured
	with keycloak
References: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>
	<56FB7C5C.60000@redhat.com> 
Message-ID: <56fb8660.8e43620a.4d9df.ffff95d1@mx.google.com>

Adding to it,

 

2016-03-30 01:20:29,823 WARN
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-1) state
parameter invalid

2016-03-30 01:20:29,823 WARN
[org.keycloak.adapters.OAuthRequestAuthenticator] (default task-1) cookie:
3/d04bf765-63be-4c34-bb42-5f7211bf8051

 

Is it the reason for the issue?

 

Thanks,

Jayapriya Atheesan

 

From: JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] 
Sent: Wednesday, March 30, 2016 1:21 PM
To: 'Marek Posolda'; 'keycloak-dev at lists.jboss.org'
Subject: RE: [keycloak-dev] 403 Forbidden when invoking application secured
with keycloak

 

Hi Marek,

 

Thanks for your response.

 

Already I have set a role in keycloak application as giggzouser and I have
set the same in my web.xml file.



After enabling the logs, it shows up this

 

2016-03-30 03:39:26,843 DEBUG [org.keycloak.adapters.PreAuthActionsHandler]
(default task-7) adminRequest
http://hostname:8080/appname/rest/giggzoLogin/userLogin

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.undertow.KeycloakUndertowAccount] (default task-7)
session is active

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.undertow.ServletSessionTokenStore] (default task-7)
Cached account found

2016-03-30 03:39:26,845 DEBUG
[org.keycloak.adapters.wildfly.WildflyRequestAuthenticator] (default task-7)
propagate security context to wildfly

2016-03-30 03:39:26,845 DEBUG [org.keycloak.adapters.RequestAuthenticator]
(default task-7) AUTHENTICATED: was cached

2016-03-30 03:39:26,846 DEBUG
[org.keycloak.adapters.AuthenticatedActionsHandler] (default task-7)
AuthenticatedActionsValve.invoke http ://hostname:8080/appname
/rest/giggzoLogin/userLogin

 

After which, I get forbidden on screen.

 

Please find the web.xml file attached to this mail.

 

Thanks,

Jayapriya Atheesan

 

From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Wednesday, March 30, 2016 12:42 PM
To: JAYAPRIYA ATHEESAN; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] 403 Forbidden when invoking application secured
with keycloak

 

It looks that your user either doesn't have roles or your client doesn't
have scope. Take a look at examples for more inspiration. For logging, you
can enable DEBUG logging for category "org.keycloak" in
standalone/configuration/standalone.xml

Marek

On 30/03/16 08:13, JAYAPRIYA ATHEESAN wrote:

Hi,

 

Greetings of the day !!

 

I need an urgent help from your team.

 

I have an application deployed in wildfly server. The same has been secured
with keycloak server(this runs of a different wildfly box).

The wildfly server has been configured with keycloak adapter. 

 

When I invoke a page from the application deployed in wildfly server, the
application , redirects to keycloak login page. After I click submit
entering user name and password, I get 403 forbidden error.

 

Is there a way to enable logs for keycloak adapter. I'm not getting any logs
related to this error.

 

The issue is similar to the one addressed in
http://lists.jboss.org/pipermail/keycloak-user/2015-February/001601.html

http://lists.jboss.org/pipermail/keycloak-user/2014-November/001280.html

 

Please help me in resolving the same.

 

Below are the details of the server :

Wildfly 9.0.0CR2

Keycloak 1.6.0 Final

 

Thanks,

Jayapriya Atheesan

 

 





_______________________________________________
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/20160330/3f4de2e6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 28433 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160330/3f4de2e6/attachment-0001.png 

From jayapriya.atheesan at gmail.com  Wed Mar 30 05:20:10 2016
From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN)
Date: Wed, 30 Mar 2016 14:50:10 +0530
Subject: [keycloak-dev] 403 Forbidden when invoking application secured
	with keycloak
In-Reply-To: <56FB7C5C.60000@redhat.com>
References: <56fb6e89.4d40620a.bb016.ffff800d@mx.google.com>
	<56FB7C5C.60000@redhat.com>
Message-ID: <56fb9a56.4744620a.93aed.ffffaa98@mx.google.com>

Thanks a lot Marek.

 

The problem was with the role not scope defined.. I gave full scope for the
client and the issue got resolved

 

Thanks,

Jayapriya Atheesan

 

From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: Wednesday, March 30, 2016 12:42 PM
To: JAYAPRIYA ATHEESAN; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] 403 Forbidden when invoking application secured
with keycloak

 

It looks that your user either doesn't have roles or your client doesn't
have scope. Take a look at examples for more inspiration. For logging, you
can enable DEBUG logging for category "org.keycloak" in
standalone/configuration/standalone.xml

Marek

On 30/03/16 08:13, JAYAPRIYA ATHEESAN wrote:

Hi,

 

Greetings of the day !!

 

I need an urgent help from your team.

 

I have an application deployed in wildfly server. The same has been secured
with keycloak server(this runs of a different wildfly box).

The wildfly server has been configured with keycloak adapter. 

 

When I invoke a page from the application deployed in wildfly server, the
application , redirects to keycloak login page. After I click submit
entering user name and password, I get 403 forbidden error.

 

Is there a way to enable logs for keycloak adapter. I'm not getting any logs
related to this error.

 

The issue is similar to the one addressed in
http://lists.jboss.org/pipermail/keycloak-user/2015-February/001601.html

http://lists.jboss.org/pipermail/keycloak-user/2014-November/001280.html

 

Please help me in resolving the same.

 

Below are the details of the server :

Wildfly 9.0.0CR2

Keycloak 1.6.0 Final

 

Thanks,

Jayapriya Atheesan

 

 






_______________________________________________
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/20160330/b773f1e1/attachment.html 

From fadiabdeen at gmail.com  Wed Mar 30 06:15:57 2016
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Wed, 30 Mar 2016 06:15:57 -0400
Subject: [keycloak-dev] Import/export realm
Message-ID: <CABXXV0TL4XP=FWB-YLrA6W34hAxrEiTOC_yxTjDqwDTTOJLFLQ@mail.gmail.com>

Has anyone imported a realm from an older version keycloak and it worked ?

I imported a realm from a 1.2  to 1.9 and the users not working as they
suppose to .

I'm wondering if there is something i need to do to get that to work !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160330/6bae96b0/attachment.html 

From mposolda at redhat.com  Wed Mar 30 06:37:51 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Mar 2016 12:37:51 +0200
Subject: [keycloak-dev] Import/export realm
In-Reply-To: <CABXXV0TL4XP=FWB-YLrA6W34hAxrEiTOC_yxTjDqwDTTOJLFLQ@mail.gmail.com>
References: <CABXXV0TL4XP=FWB-YLrA6W34hAxrEiTOC_yxTjDqwDTTOJLFLQ@mail.gmail.com>
Message-ID: <56FBAC7F.4070403@redhat.com>

Feel free to create JIRA. Please add the details what exactly doesn't 
work. Also would be appreciated if you can attach the JSON file with 
example of some users, which don't work as expected.

Thanks,
Marek

On 30/03/16 12:15, Fadi Abdin wrote:
> Has anyone imported a realm from an older version keycloak and it 
> worked ?
>
> I imported a realm from a 1.2  to 1.9 and the users not working as 
> they suppose to .
>
> I'm wondering if there is something i need to do to get that to work !
>
>
> _______________________________________________
> 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/20160330/49225f52/attachment.html 

From bburke at redhat.com  Wed Mar 30 09:43:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Mar 2016 09:43:25 -0400
Subject: [keycloak-dev] Async HTTP Request Processing
In-Reply-To: <597548124.123268.1459303053944.JavaMail.yahoo@mail.yahoo.com>
References: <1830946258.44924585.1459302424666.JavaMail.zimbra@redhat.com>
	<597548124.123268.1459303053944.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <56FBD7FD.60203@redhat.com>

JAX-RS async can be enabled per resource, so its really up to you to 
decide if Authz needs it.

Async doesn't make sense for core KC autthentication.  KC Identity 
broker does not wait/block for a response on a login. Authenticators are 
not waiting/blocking for responses either. Waiting/blocking only happens 
on backchannel logouts and background admin operations.  Somebody is 
going to have to show me real tangible benefits before we switch core KC 
to use Async JAX-RS or some async event driven SPI, because right now, 
with our currently functionality and our roadmap, there is no need for 
an async model.



On 3/29/2016 9:57 PM, Raghuram Prabhala wrote:
> +1. Makes sense for even KC (as Identity broker waiting for a response 
> from Identity provider or as Identity provider waiting for a response 
> from Authenticators)
>
>
> ------------------------------------------------------------------------
> *From:* Pedro Igor Silva <psilva at redhat.com>
> *To:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Sent:* Tuesday, March 29, 2016 9:47 PM
> *Subject:* [keycloak-dev] Async HTTP Request Processing
>
> Hi,
>
>     I'm working with the AuthZ Java API in order to make it more 
> event-driven and non-blocking. During our F2F, I've discussed some 
> very interesting requirements with Marc Savy around that.
>
>     I would like to know if makes sense to enable JAX-RS Async support 
> to some AuthZ REST endpoints, which are basically using this API to 
> evaluate policies using different providers (where these providers can 
> be executed in parallel).
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From carreraariel at gmail.com  Wed Mar 30 11:40:10 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Wed, 30 Mar 2016 12:40:10 -0300
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
	validateUserAndPassword process
Message-ID: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>

Hi, I am developing a Federation Provider, and I have a question...

Why the method () checks if the user "is enabled" after validate the
password instead of before of the password validation?

AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
...
        if (invalidUser(context, user)){
            return false;
        }

*        if (!validatePassword(context, user, inputData)){*
*            return false;*
*        }*

*        if(!enabledUser(context, user)){*
*            return false;*
*        }*
...

If the user is disabled... why validate his password and return a password
validation error message?

-- 
Ariel Carrera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160330/8e217f74/attachment-0001.html 

From prabhalar at yahoo.com  Wed Mar 30 21:32:13 2016
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Thu, 31 Mar 2016 01:32:13 +0000 (UTC)
Subject: [keycloak-dev] Async HTTP Request Processing
In-Reply-To: <56FBD7FD.60203@redhat.com>
References: <56FBD7FD.60203@redhat.com>
Message-ID: <2010793447.30046.1459387933182.JavaMail.yahoo@mail.yahoo.com>

I am talking about some external authenticators (MIT Kerberos or SecurID) when KC will wait for the response which can take a few seconds (the thread executing that call sits idle during that time) -and it makes perfect sense in those cases to use async model. The same applies to Identity Broker when KC opens up http connection to an external Identity Provider (say ADFS - there could be delay of few seconds for the response to come back). I had a quick look at the KC code and it appears that normal http blocking calls are being made. Shifting to async will definitely help KC handle many more user requests. See the below text from Apache http components website on when async model makes sense. Whether you consider shifting to async or not is totally your call but shifting to async model (infact using modern web frameworks/servers like Vertx) will future proof KC functionality.
The blocking I/O model may be more appropriate for data intensive, low latency scenarios, whereas the non-blocking model may be more appropriate for high latency scenarios where raw data throughput is less important than the ability to handle thousands of simultaneous HTTP connections in a resource efficient manner.

      From: Bill Burke <bburke at redhat.com>
 To: keycloak-dev at lists.jboss.org 
 Sent: Wednesday, March 30, 2016 9:43 AM
 Subject: Re: [keycloak-dev] Async HTTP Request Processing
   
 JAX-RS async can be enabled per resource, so its really up to you to decide if Authz needs it. 
 
 Async doesn't make sense for core KC autthentication.? KC Identity broker does not wait/block for a response on a login.? Authenticators are not waiting/blocking for responses either.? Waiting/blocking only happens on backchannel logouts and background admin operations.? Somebody is going to have to show me real tangible benefits before we switch core KC to use Async JAX-RS or some async event driven SPI, because right now, with our currently functionality and our roadmap, there is no need for an async model.
 
 
 
 On 3/29/2016 9:57 PM, Raghuram Prabhala wrote:
  
  +1. Makes sense for even KC (as Identity broker waiting for a response from Identity provider or as Identity provider waiting for a response from Authenticators) 
 
        From: Pedro Igor Silva <psilva at redhat.com>
 To: keycloak-dev <keycloak-dev at lists.jboss.org> 
 Sent: Tuesday, March 29, 2016 9:47 PM
 Subject: [keycloak-dev] Async HTTP Request Processing
  
 Hi,
 
 ? ? I'm working with the AuthZ Java API in order to make it more event-driven and non-blocking. During our F2F, I've discussed some very interesting requirements with Marc Savy around that.
 
 ? ? I would like to know if makes sense to enable JAX-RS Async support to some AuthZ REST endpoints, which are basically using this API to evaluate policies using different providers (where these providers can be executed in parallel).
 
 Regards.
 Pedro Igor
 _______________________________________________
 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

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

From mposolda at redhat.com  Thu Mar 31 06:27:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Mar 2016 12:27:18 +0200
Subject: [keycloak-dev] Added DB indexes
Message-ID: <56FCFB86.6020208@redhat.com>

I've did loads of testing for create/load/delete big number of users 
into database and I've send PR for add some additional indexes into 
database to improve performance of operations with big number of users 
in DB - https://github.com/keycloak/keycloak/pull/2456

Note that adding DB indexes is tricky as the performance gain (or loss) 
might be highly dependent on underlying database. Some example:

1) PostgreSQL is adding the indexes by default just for primary keys and 
unique constraints. But it doesn't add indexes for foreign keys. So when 
you have 50K users in DB and 150K role mappings (each user member of 3 
roles), then this query take more than 20 ms:

select * from USER_ROLE_MAPPING where USER_ID='123';


2) MySQL is adding the btree indexes by default even for foreign keys. 
So the same query like above took less than 1 ms by default.


So to improve the time on postgres, the index for USER_ID column in 
USER_ROLE_MAPPING is needed, however for MySQL adding the index doesn't 
have any effect as it's already there. In the end, I've explicitly added 
the indexes into changelog file by default and I can see very good 
performance for both mysql and postgresql and operations are not 
dependent on number of users in DB.

However in theory, adding the indexes may have bad effect for some 
databases and slow down the time for create new user etc. I personally 
don't want to test performance with all supported DBs :) So another 
approach might be to not explicitly add the indexes and let DBA to do 
that. I've added the possibility to enable logging some overall 
statistics from Hibernate, so people can check it by themselves. Let me 
know if you rather want to go this way and not add indexes by default.

Marek

From mposolda at redhat.com  Thu Mar 31 06:44:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Mar 2016 12:44:39 +0200
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
 validateUserAndPassword process
In-Reply-To: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
References: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
Message-ID: <56FCFF97.7030202@redhat.com>

AFAIK one of the reasons is security. If an attacker guesses username 
"foo", which exists, but not password of user "foo", you don't want to 
tell him that he successfully guessed username. So instead of first 
checking that user "foo" is disabled and display the message "The user 
account is disabled", you rather check password first and then display 
the message "Incorrect username or password", so attacker don't have a 
clue if account really exists or password was incorrect etc. Also if 
BruteForce protector is enabled, you want to log the event as failed 
login, so we're checking the password of user.

Marek


On 30/03/16 17:40, Ariel Carrera wrote:
> Hi, I am developing a Federation Provider, and I have a question...
>
> Why the method () checks if the user "is enabled" after validate the 
> password instead of before of the password validation?
>
> AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
> ...
>         if (invalidUser(context, user)){
>             return false;
>         }
>
> *        if (!validatePassword(context, user, inputData)){*
> *            return false;*
> *        }*
>
> *        if(!enabledUser(context, user)){*
> *            return false;*
> *        }*
> ...
>
> If the user is disabled... why validate his password and return a 
> password validation error message?
>
> -- 
> Ariel Carrera
>
>
> _______________________________________________
> 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/20160331/a5742173/attachment.html 

From mposolda at redhat.com  Thu Mar 31 06:56:04 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Mar 2016 12:56:04 +0200
Subject: [keycloak-dev] Async HTTP Request Processing
In-Reply-To: <56FBD7FD.60203@redhat.com>
References: <1830946258.44924585.1459302424666.JavaMail.zimbra@redhat.com>
	<597548124.123268.1459303053944.JavaMail.yahoo@mail.yahoo.com>
	<56FBD7FD.60203@redhat.com>
Message-ID: <56FD0244.7000604@redhat.com>

On 30/03/16 15:43, Bill Burke wrote:
> JAX-RS async can be enabled per resource, so its really up to you to 
> decide if Authz needs it.
>
> Async doesn't make sense for core KC autthentication.  KC Identity 
> broker does not wait/block for a response on a login. Authenticators 
> are not waiting/blocking for responses either. Waiting/blocking only 
> happens on backchannel logouts and background admin operations.
Not directly related to JAX-RS Async, but IMO at least the performance 
of backchannel logout in ResourceAdminMAnager can be slightly improved 
if we send the backchannel logout requests asynchronously. Currently if 
you are logged to 5 apps, you first need to send backchannel logout to 
product-portal, then wait for response, then send another backchannel 
logout to customer-portal, wait again etc. IMO sending 5 requests 
asynchronously can improve performance of logout and it can be done 
quite easily inside ResourceAdminManager.

Marek
> Somebody is going to have to show me real tangible benefits before we 
> switch core KC to use Async JAX-RS or some async event driven SPI, 
> because right now, with our currently functionality and our roadmap, 
> there is no need for an async model.
>
>
>
> On 3/29/2016 9:57 PM, Raghuram Prabhala wrote:
>> +1. Makes sense for even KC (as Identity broker waiting for a 
>> response from Identity provider or as Identity provider waiting for a 
>> response from Authenticators)
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Pedro Igor Silva <psilva at redhat.com>
>> *To:* keycloak-dev <keycloak-dev at lists.jboss.org>
>> *Sent:* Tuesday, March 29, 2016 9:47 PM
>> *Subject:* [keycloak-dev] Async HTTP Request Processing
>>
>> Hi,
>>
>>     I'm working with the AuthZ Java API in order to make it more 
>> event-driven and non-blocking. During our F2F, I've discussed some 
>> very interesting requirements with Marc Savy around that.
>>
>>     I would like to know if makes sense to enable JAX-RS Async 
>> support to some AuthZ REST endpoints, which are basically using this 
>> API to evaluate policies using different providers (where these 
>> providers can be executed in parallel).
>>
>> Regards.
>> Pedro Igor
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> 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/20160331/28d1e702/attachment-0001.html 

From thomas.darimont at googlemail.com  Thu Mar 31 07:59:54 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 31 Mar 2016 13:59:54 +0200
Subject: [keycloak-dev] Added DB indexes
In-Reply-To: <56FCFB86.6020208@redhat.com>
References: <56FCFB86.6020208@redhat.com>
Message-ID: <CAK-7U1hGU3WxneDOxWwO7HFyi-6zOgf=V=gg-v6x_Q9DNiME0A@mail.gmail.com>

Hello Marek,

thanks f?r this interesting hint - our postgres admin recommended the
following script to me to find foreig-key index candidates:
https://github.com/pgexperts/pgx_scripts/blob/master/indexes/fk_no_index.sql

Running that an a fresh keycloak postgres db will return no results... but
if you disable the where condition (that checks for usage)
at the end you'll get an IMHO useful list of index candidates.
I put up a gist with the modified query and results here:
https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e

Cheers,
Thomas

2016-03-31 12:27 GMT+02:00 Marek Posolda <mposolda at redhat.com>:

> I've did loads of testing for create/load/delete big number of users
> into database and I've send PR for add some additional indexes into
> database to improve performance of operations with big number of users
> in DB - https://github.com/keycloak/keycloak/pull/2456
>
> Note that adding DB indexes is tricky as the performance gain (or loss)
> might be highly dependent on underlying database. Some example:
>
> 1) PostgreSQL is adding the indexes by default just for primary keys and
> unique constraints. But it doesn't add indexes for foreign keys. So when
> you have 50K users in DB and 150K role mappings (each user member of 3
> roles), then this query take more than 20 ms:
>
> select * from USER_ROLE_MAPPING where USER_ID='123';
>
>
> 2) MySQL is adding the btree indexes by default even for foreign keys.
> So the same query like above took less than 1 ms by default.
>
>
> So to improve the time on postgres, the index for USER_ID column in
> USER_ROLE_MAPPING is needed, however for MySQL adding the index doesn't
> have any effect as it's already there. In the end, I've explicitly added
> the indexes into changelog file by default and I can see very good
> performance for both mysql and postgresql and operations are not
> dependent on number of users in DB.
>
> However in theory, adding the indexes may have bad effect for some
> databases and slow down the time for create new user etc. I personally
> don't want to test performance with all supported DBs :) So another
> approach might be to not explicitly add the indexes and let DBA to do
> that. I've added the possibility to enable logging some overall
> statistics from Hibernate, so people can check it by themselves. Let me
> know if you rather want to go this way and not add indexes by default.
>
> Marek
> _______________________________________________
> 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/20160331/f191fe69/attachment.html 

From mposolda at redhat.com  Thu Mar 31 08:18:31 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Mar 2016 14:18:31 +0200
Subject: [keycloak-dev] Added DB indexes
In-Reply-To: <CAK-7U1hGU3WxneDOxWwO7HFyi-6zOgf=V=gg-v6x_Q9DNiME0A@mail.gmail.com>
References: <56FCFB86.6020208@redhat.com>
	<CAK-7U1hGU3WxneDOxWwO7HFyi-6zOgf=V=gg-v6x_Q9DNiME0A@mail.gmail.com>
Message-ID: <56FD1597.2@redhat.com>

On 31/03/16 13:59, Thomas Darimont wrote:
> Hello Marek,
>
> thanks f?r this interesting hint - our postgres admin recommended the 
> following script to me to find foreig-key index candidates:
> https://github.com/pgexperts/pgx_scripts/blob/master/indexes/fk_no_index.sql
>
> Running that an a fresh keycloak postgres db will return no results... 
> but if you disable the where condition (that checks for usage)
> at the end you'll get an IMHO useful list of index candidates.
> I put up a gist with the modified query and results here: 
> https://gist.github.com/thomasdarimont/992aaad6af704f40fd4483af3d42290e
Thanks Thomas for the interesting script!

I've actually didn't add indexes to all foreign keys, but just to those, 
which are widely used and are supposed to contain big number of records. 
So especially the tables related to user model. Also I needed to add 
some indexes to columns, which are not foreign keys (those were needed 
for both MySQL and PostgreSQL), for example EMAIL of USER_ENTITY table 
as Keycloak often needs to lookup users by email.

Marek
>
> Cheers,
> Thomas
>
> 2016-03-31 12:27 GMT+02:00 Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>>:
>
>     I've did loads of testing for create/load/delete big number of users
>     into database and I've send PR for add some additional indexes into
>     database to improve performance of operations with big number of users
>     in DB - https://github.com/keycloak/keycloak/pull/2456
>
>     Note that adding DB indexes is tricky as the performance gain (or
>     loss)
>     might be highly dependent on underlying database. Some example:
>
>     1) PostgreSQL is adding the indexes by default just for primary
>     keys and
>     unique constraints. But it doesn't add indexes for foreign keys.
>     So when
>     you have 50K users in DB and 150K role mappings (each user member of 3
>     roles), then this query take more than 20 ms:
>
>     select * from USER_ROLE_MAPPING where USER_ID='123';
>
>
>     2) MySQL is adding the btree indexes by default even for foreign keys.
>     So the same query like above took less than 1 ms by default.
>
>
>     So to improve the time on postgres, the index for USER_ID column in
>     USER_ROLE_MAPPING is needed, however for MySQL adding the index
>     doesn't
>     have any effect as it's already there. In the end, I've explicitly
>     added
>     the indexes into changelog file by default and I can see very good
>     performance for both mysql and postgresql and operations are not
>     dependent on number of users in DB.
>
>     However in theory, adding the indexes may have bad effect for some
>     databases and slow down the time for create new user etc. I personally
>     don't want to test performance with all supported DBs :) So another
>     approach might be to not explicitly add the indexes and let DBA to do
>     that. I've added the possibility to enable logging some overall
>     statistics from Hibernate, so people can check it by themselves.
>     Let me
>     know if you rather want to go this way and not add indexes by default.
>
>     Marek
>     _______________________________________________
>     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/20160331/dc9179b5/attachment.html 

From mposolda at redhat.com  Thu Mar 31 09:00:38 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Mar 2016 15:00:38 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
Message-ID: <56FD1F76.1090908@redhat.com>

Followup on the issue by Libor [1] . I can confirm to see the same 
behaviour in the OOTB Keycloak, like Libor described in the JIRA. In 
other words, when you refresh account page ( 
http://localhost:8080/auth/realms/myrealm/account ) but the UserSession 
referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies 
including KEYCLOAK_REMEMBERME are expired too.

IMO RememberMe cookie shouldn't be expired when session is expired. 
We're using the rememberMe cookie as hint for username on the login 
page. So even if user returns to page after a month, I am not seeing 
anything bad that rememberMe cookie is still valid and user will see 
"hint" with his username on login page and rememberMe checkbox checked 
even if session was expired already for a long time. IMO the only 
situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user 
unchecks the "Remember me" checkbox on login page.

[1] https://issues.jboss.org/browse/ORG-2956

Marek

From thomas.darimont at googlemail.com  Thu Mar 31 09:38:41 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 31 Mar 2016 15:38:41 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
Message-ID: <CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>

Hello Thomas,

would you mind sharing your keycloak configuration with a JMS
resource-adapter?

Did you manage to configure a new resource-adapter via jboss-cli?

Cheers,
Thomas

2016-01-13 14:31 GMT+01:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com
>:

>
> On Wed, Jan 13, 2016 at 3:25 PM, Juraci Paix?o Kr?hling <
> juraci at kroehling.de> wrote:
>
>> I have something like this implemented already. It listens to KC events
>> and publishes those to a REST endpoint (if the target server is remote),
>> or to a JMS topic.
>>
>
> That's great, thanks for the info! I also have the JMS implementation
> ready, but the necessary Wildfly configuration still needs to be thought
> through...
>
> Best regards,
> Thomas
>
> _______________________________________________
> 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/20160331/284ec992/attachment.html 

From thomas.raehalme at aitiofinland.com  Thu Mar 31 09:44:18 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 31 Mar 2016 16:44:18 +0300
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
Message-ID: <CAPyAMoaZpGz6GwFDjmJCCFgmOTsP1cYGCjUMJ1QAM_h+o+Zqrg@mail.gmail.com>

Hi!

Yes, we have it up and running. I'll post the config in a couple of hours.

I have not had a chance to implement the tests Stian wanted for the JMS
event listener, so I haven't send a PR...

Best regards,
Thomas
On Mar 31, 2016 16:39, "Thomas Darimont" <thomas.darimont at googlemail.com>
wrote:

> Hello Thomas,
>
> would you mind sharing your keycloak configuration with a JMS
> resource-adapter?
>
> Did you manage to configure a new resource-adapter via jboss-cli?
>
> Cheers,
> Thomas
>
> 2016-01-13 14:31 GMT+01:00 Thomas Raehalme <
> thomas.raehalme at aitiofinland.com>:
>
>>
>> On Wed, Jan 13, 2016 at 3:25 PM, Juraci Paix?o Kr?hling <
>> juraci at kroehling.de> wrote:
>>
>>> I have something like this implemented already. It listens to KC events
>>> and publishes those to a REST endpoint (if the target server is remote),
>>> or to a JMS topic.
>>>
>>
>> That's great, thanks for the info! I also have the JMS implementation
>> ready, but the necessary Wildfly configuration still needs to be thought
>> through...
>>
>> Best regards,
>> Thomas
>>
>> _______________________________________________
>> 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/20160331/0102bf9d/attachment-0001.html 

From lkrzyzan at redhat.com  Thu Mar 31 10:26:27 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Thu, 31 Mar 2016 16:26:27 +0200
Subject: [keycloak-dev] Expected behaviour for rememberMe?
In-Reply-To: <56FD1F76.1090908@redhat.com>
References: <56FD1F76.1090908@redhat.com>
Message-ID: <5A171A64-64FC-431F-844A-E37E5A92892E@redhat.com>

I read docs today http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630
 <http://keycloak.github.io/docs/userguide/keycloak-server/html/timeouts.html#d4e2630> and my understanding is that user should keep logged in after either browser restart or session expiration.
My tests shows that after session expiration (set to 1 min) I have to log in again.

Thanks,

Libor Krzy?anek
Principal Software Engineer
Red Hat Developers | Engineering

> On Mar 31, 2016, at 3:00 PM, Marek Posolda <mposolda at redhat.com> wrote:
> 
> Followup on the issue by Libor [1] . I can confirm to see the same 
> behaviour in the OOTB Keycloak, like Libor described in the JIRA. In 
> other words, when you refresh account page ( 
> http://localhost:8080/auth/realms/myrealm/account ) but the UserSession 
> referenced from KEYCLOAK_IDENTITY cookie is expired, then all cookies 
> including KEYCLOAK_REMEMBERME are expired too.
> 
> IMO RememberMe cookie shouldn't be expired when session is expired. 
> We're using the rememberMe cookie as hint for username on the login 
> page. So even if user returns to page after a month, I am not seeing 
> anything bad that rememberMe cookie is still valid and user will see 
> "hint" with his username on login page and rememberMe checkbox checked 
> even if session was expired already for a long time. IMO the only 
> situation when we should expire KEYCLOAK_REMEMBERME cookie is, when user 
> unchecks the "Remember me" checkbox on login page.
> 
> [1] https://issues.jboss.org/browse/ORG-2956
> 
> Marek
> _______________________________________________
> 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/20160331/34af3364/attachment.html 

From carreraariel at gmail.com  Thu Mar 31 12:17:02 2016
From: carreraariel at gmail.com (Ariel Carrera)
Date: Thu, 31 Mar 2016 13:17:02 -0300
Subject: [keycloak-dev] AbstractUsernameFormAuthenticator
 validateUserAndPassword process
In-Reply-To: <56FCFF97.7030202@redhat.com>
References: <CAFzO_6fQ9T_g15KKo2AfWiPBahTzFQO7HN8Lv0FW2GuR6qFWYQ@mail.gmail.com>
	<56FCFF97.7030202@redhat.com>
Message-ID: <CAFzO_6dNAaTKPSN3Nw8P+aw-vSPX-TF=zac9P_HddC_w9e2FrQ@mail.gmail.com>

Marek, that's makes sense, but, what happen when the user is known by the
attacker? If the brute force check is in the "isEnabled" method (after
password validation), the attacker guesses the password successfully, the
brute force protection never apply. Please check the code because i am
afraid that it can be a big security risk.
If you wants I can open a new jira issue to discuss about it.

2016-03-31 7:44 GMT-03:00 Marek Posolda <mposolda at redhat.com>:

> AFAIK one of the reasons is security. If an attacker guesses username
> "foo", which exists, but not password of user "foo", you don't want to tell
> him that he successfully guessed username. So instead of first checking
> that user "foo" is disabled and display the message "The user account is
> disabled", you rather check password first and then display the message
> "Incorrect username or password", so attacker don't have a clue if account
> really exists or password was incorrect etc. Also if BruteForce protector
> is enabled, you want to log the event as failed login, so we're checking
> the password of user.
>
> Marek
>
>
>
> On 30/03/16 17:40, Ariel Carrera wrote:
>
> Hi, I am developing a Federation Provider, and I have a question...
>
> Why the method () checks if the user "is enabled" after validate the
> password instead of before of the password validation?
>
> AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
> ...
>         if (invalidUser(context, user)){
>             return false;
>         }
>
> *        if (!validatePassword(context, user, inputData)){*
> *            return false;*
> *        }*
>
> *        if(!enabledUser(context, user)){*
> *            return false;*
> *        }*
> ...
>
> If the user is disabled... why validate his password and return a password
> validation error message?
>
> --
> Ariel Carrera
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>


-- 
Tat?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160331/1d6be7dd/attachment.html 

From thomas.raehalme at aitiofinland.com  Thu Mar 31 14:18:36 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 31 Mar 2016 21:18:36 +0300
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
	<CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>
	<CAK-7U1iZxVMjLtJrOw9kxwUeXPEnOaq+nyqTDQG5y-ObGCgksA@mail.gmail.com>
Message-ID: <CAPyAMoYOLvRGmuffG+s6pdE2jAAC0bKHMPwh=mhCjHqJywpmXA@mail.gmail.com>

Hi,

On Thu, Mar 31, 2016 at 4:38 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> would you mind sharing your keycloak configuration with a JMS
> resource-adapter?
>

Here are the changes I made to standalone/configuration/standalone.xml:

1. Added the following extension under /server/extensions:

<extension module="org.wildfly.extension.messaging-activemq"/>

2. Added the following subsystem under /server/profile:

<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
    <server name="default">
        <security enabled="false" /> <!-- I didn't need to use security as
everything was localhost -->
        <remote-acceptor name="netty" socket-binding="messaging"/>
        <remote-connector name="netty" socket-binding="messaging"/>
        <in-vm-acceptor name="in-vm" server-id="0"/>
        <in-vm-connector name="in-vm" server-id="0"/>
        <pooled-connection-factory name="activemq-ra"
                    transaction="xa" connectors="in-vm"
                    entries="java:/ConnectionFactory java:/JmsXA
java:jboss/DefaultJMSConnectionFactory"/>
        <jms-topic name="KeycloakEvents" entries="jms/KeycloakEvents
java:jboss/exported/jms/KeycloakEvents" />
    </server>
</subsystem>

3. Added the following socket-binding under /server/socket-binding-group:

<socket-binding name="messaging" port="61616"/>

This enabled my external process to listen to the JMS topic.

I attached a full example to this message. The changes have been marked
with <!-- keycloak-events-jms -->.

Did you manage to configure a new resource-adapter via jboss-cli?
>

No, I haven't used jboss-cli but modified the configuration file directly.

My implementation of KEYCLOAK-2302 can be found at Github:
https://github.com/raehalme/keycloak/tree/KEYCLOAK-2302.

I have not sent a PR as I have yet to complete the Arquillian integration
tests requested by Stian. Other work has kept me busy and I haven't had a
chance to even rebase against 1.9.x.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160331/418bff3a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: standalone.xml
Type: text/xml
Size: 21446 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160331/418bff3a/attachment-0001.xml 

From jdennis at redhat.com  Thu Mar 31 17:09:09 2016
From: jdennis at redhat.com (John Dennis)
Date: Thu, 31 Mar 2016 17:09:09 -0400
Subject: [keycloak-dev] Conceptual Questions
In-Reply-To: <CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
References: <56E9DFB2.6070802@redhat.com>
	<CAJgngAex--XycSmcX82YSLAjLpr6p789GvW2i340PZSccW-j7g@mail.gmail.com>
Message-ID: <56FD91F5.4030700@redhat.com>

On 03/22/2016 03:40 AM, Stian Thorgersen wrote:
> That's a very long list of questions. Have you read through our
> documentation? I would hope it at least answers some of these questions.
> If not then breaking this list into smaller emails would make it easier
> to answer. Answering all these questions in one go is a fairly time
> consuming job.

I'm not looking to waste anyone's time. I've read all the documentation, 
watched all the keycloak videos, read the relevant RFC's and browsed the 
Keycloak source code. These are the questions I was left with after 
having done my homework :-)

I recognize the Keycloak team is at a very busy juncture at this point 
in time. Perhaps the best course forward would be a recordable 
conference call the details of which are probably best handled off-list.


-- 
John