From sjoerd.cranen at teampicnic.com  Sun Jul  2 11:44:52 2017
From: sjoerd.cranen at teampicnic.com (Sjoerd Cranen)
Date: Sun, 2 Jul 2017 17:44:52 +0200
Subject: [keycloak-dev] Cookie token storage for Spring Security
In-Reply-To: <CALvb29z895yGf0wk9-PNV78uxxv9oR8Um6XKPVEPeMbpuSJn+A@mail.gmail.com>
References: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>
	<CALvb29z895yGf0wk9-PNV78uxxv9oR8Um6XKPVEPeMbpuSJn+A@mail.gmail.com>
Message-ID: <CAMHuGfq_7xgVd_gFfF7RC9=E68vSPyLCB=r+=G_QSn9zEhYKuw@mail.gmail.com>

I've submitted https://issues.jboss.org/browse/KEYCLOAK-5130 for this. If
the bug report is accepted, I'll be happy to open a PR with a solution.

Answering one of my own questions: the peculiar cookie path I mentioned in
my original post is already described in KEYCLOAK-4342.

On Fri, Jun 23, 2017 at 6:08 PM, Konstantin Gribov <grossws at gmail.com>
wrote:

> On Fri, Jun 23, 2017 at 4:46 PM Sjoerd Cranen <
> sjoerd.cranen at teampicnic.com> wrote:
>
>> One thing I'm wondering is why the cookie path for the adapter state
>> cookie
>> is always set to the context root in CookieTokenStore. In particular, it
>> would seem that if I change the Spring Security adapter in a
>> straightforward way to store the cookies, the cookie would always be set
>> on
>> "/sso", which would not be very useful.
>>
> Same applies for Jetty adapter. But it doesn't work now (see
> KEYCLOAK-2514).
>
> --
>
> Best regards,
> Konstantin Gribov
>

From mitya at cargosoft.ru  Sun Jul  2 21:58:12 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 03 Jul 2017 04:58:12 +0300
Subject: [keycloak-dev] Keycloak 3.2.0.CR2 released
In-Reply-To: <CAJgngAc_1BDsTigOyv4iu3HYmT4t67Gfh0sq9q1Tsu0=tdp5wA@mail.gmail.com>
References: <CAJgngAc_1BDsTigOyv4iu3HYmT4t67Gfh0sq9q1Tsu0=tdp5wA@mail.gmail.com>
Message-ID: <1499047092.11005.5.camel@cargosoft.ru>

Kudos for the team, you've done a good job!
Stian, remember we've been discussing the hypothetical Admin Resource
SPI last time, you've said:
> One issue with introducing admin resource spi now is that it would
> have to be reworked once we rework how permissions are done.

Can we consider this refactoring complete or close to completion? If
yes, should we revisit the Admin Resource SPI topic?
Cheers,Dmitry
> We've just released Keycloak 3.2.0.CR1.
> 
> To download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>.
> HighlightsFine grained admin permissions
> 
> This is something that we've wanted to add for a long time! Through
> our
> authorization services it's now possible to finely tune permissions
> for
> admins. This makes it possible to limit what clients, users, roles,
> etc.
> admins have access to. Documentation is missing for this at the
> moment, but
> will be added in time for 3.2.0.Final.
> Docker Registry support
> 
> It's not possible to secure a Docker Registry with a standard OAuth
> or
> OpenID Connect provider. For some strange reason they have only
> partially
> followed the specifications and the Docker Registry maintainers
> refuse to
> fix this! Fear not, thanks to cainj13 <https://github.com/cainj13>
> who
> contributed this we now have a special Docker Registry protocol that
> can be
> enabled in Keycloak.
> Authentication sessions and access tokens
> 
> In the effort to provide support for running Keycloak in multiple
> data
> centers we've done a large amount of work around user sessions. We've
> introduced authentication sessions that are special sessions used
> primarily
> during the authentication flows. There are two main reasons for this.
> Authentication flows can fairly easily be fixed to a specific node
> within a
> specific data center and there is no need to replicate this to other
> data
> centers. They are also more write heavy than the user sessions. The
> introduction of access tokens makes it possible to detach actions
> (for
> example verify email) from a user session, which has a number of
> benefits.
> More will come in future 3.x releases and by the end of the year we
> aim to
> fully support replicating Keycloak cross multiple data centers.
> Authorization Service improvements
> 
> There's been a lot of work done to the authorization services in this
> release. Way to many to list here so check out JIRA
> <https://issues.jboss.org/browse/KEYCLOAK-5072?jql=project%20%3D%20ke
> ycloak%20and%20fixVersion%20%3D%203.2.0.CR1%20and%20component%20%3D%2
> 0Authorization>
> for
> details.
> QuickStarts
> 
> We've introduced new QuickStarts with the aim to make it even simpler
> for
> you to get started securing your applications and services with
> Keycloak.
> The QuickStarts have proper tests as well, which can serve as a
> reference
> on how to tests your own applications and services secured with
> Keycloak.
> Check out the new QuickStarts in the keycloak-quickstarts GitHub
> repository
> <https://github.com/keycloak/keycloak-quickstarts>.
> Upgraded AngularJS and JQuery
> 
> We've upgraded the versions we use of AngularJS and JQuery as there
> where a
> number of known vulnerabilities. We're fairly certain neither of the
> known
> vulnerabilities affect Keycloak, but to be on the safe side we
> decided to
> upgrade.
> Updated Password Hashing Algorithms
> 
> We're still using PBKDF2, but we've added support for SHA256 and
> SHA512.
> PBKDF2 is SHA256 is now used by default.
> Spring Boot QuickStarter
> 
> We've added a new Spring Boot QuickStarter that makes it super simple
> to
> get started securing your Spring Boot applications. For more details
> check
> out the blog post about it
> <http://blog.keycloak.org/2017/05/easily-secure-your-spring-boot.html
> >.
> Loads more..
> 
> ???- Partial export of realms in the admin console
> ???- Redirect URI rewrite rules for adapters
> ???- Test email settings in the admin console
> ???- Initial access tokens now persisted to the db
> 
> The full list of resolved issues is available in JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%
> 20fixVersion%20%3D%203.2.0.CR1>
> .
> Upgrading
> 
> Before you upgrade remember to backup your database and check the
> migration
> guide
> <https://keycloak.gitbooks.io/documentation/server_admin/topics/Migra
> tionFromOlderVersions.html>.
> Release candidates are not recommended in production and we do not
> support
> upgrading from release candidates.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Sun Jul  2 22:42:40 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Jul 2017 04:42:40 +0200
Subject: [keycloak-dev] Renaming testsuite/integration to
	testsuite/integration-deprecated
In-Reply-To: <CAK-7U1j8cxq8JWNj7PEcwYaC9bg4KOq1ZwMv1LEvk+p=ZdYmkA@mail.gmail.com>
References: <CAJgngAfch9FV1kmR_EV5BsH3duwH5s+n=636mUgf8SF4zMX=dQ@mail.gmail.com>
	<CAJgngAcWqFtgQkMmsofXN6dHzOg=3XXvOELvWnzFznH5XYTVVw@mail.gmail.com>
	<CAK-7U1j8cxq8JWNj7PEcwYaC9bg4KOq1ZwMv1LEvk+p=ZdYmkA@mail.gmail.com>
Message-ID: <CAJgngAeUmfK-H5B1uYNYArC-2LZX3X6eg3rQ6PkWtKrmnbGk9Q@mail.gmail.com>

That'll still be there. Eventually when all the old tests are migrated
it'll be moved to a new tools utils module or something. We're not getting
rid of it though.

On 30 June 2017 at 21:03, Thomas Darimont <thomas.darimont at googlemail.com>
wrote:

> Will it still be possible to use the embedded KeycloakServer for testing?
>
> I use this a lot for quickly trying out new Keycloak extensions /
> customizations.
>
> Cheers,
> Thomas
>
> 2017-06-30 14:51 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Unless someone objects I'm going start by renaming testsuite/integration
>> to
>> testsuite/integration-deprecated. Created JIRA
>> https://issues.jboss.org/browse/KEYCLOAK-5123. Last chance to complain.
>>
>> On 8 June 2017 at 08:27, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> > I would like to rename testsuite/integration to
>> testsuite/integration-deprecated.
>> > This is to make it clear to external contributors that the testsuite is
>> > deprecated and new tests should be added to testsuite/integration-
>> > arquillian.
>> >
>> > I would also like to rename testsuite/integration-arquillian
>> > to testsuite/integration.
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Sun Jul  2 23:21:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Jul 2017 05:21:27 +0200
Subject: [keycloak-dev] Review Chinese translations PR
Message-ID: <CAJgngAd9PriB560mgmgtDEd+dmamAra=UytRY4Qg_GyUGs82Rw@mail.gmail.com>

Can someone please review PR for Chinese translations?

https://github.com/keycloak/keycloak/pull/4251

From sthorger at redhat.com  Sun Jul  2 23:30:03 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Jul 2017 05:30:03 +0200
Subject: [keycloak-dev] Keycloak 3.2.0.CR2 released
In-Reply-To: <1499047092.11005.5.camel@cargosoft.ru>
References: <CAJgngAc_1BDsTigOyv4iu3HYmT4t67Gfh0sq9q1Tsu0=tdp5wA@mail.gmail.com>
	<1499047092.11005.5.camel@cargosoft.ru>
Message-ID: <CAJgngAddHHwGY6of2K+HihGdDhZADwAGwTyVVWq_rQDy+8+yVw@mail.gmail.com>

Yes, it can be re-visited now. I'd suggest creating a new thread about it
on keycloak-dev. It would have to be contributed by the community though as
we don't have time to work in it ourselves at the moment.

On 3 July 2017 at 03:58, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Kudos for the team, you've done a good job!
>
> Stian, remember we've been discussing the hypothetical Admin Resource SPI
> last time, you've said:
>
> One issue with introducing admin resource spi now is that it would have to
> be reworked once we rework how permissions are done.
>
>
> Can we consider this refactoring complete or close to completion? If yes,
> should we revisit the Admin Resource SPI topic?
>
> Cheers,
> Dmitry
>
> We've just released Keycloak 3.2.0.CR1.
>
> To download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>.
> HighlightsFine grained admin permissions
>
> This is something that we've wanted to add for a long time! Through our
> authorization services it's now possible to finely tune permissions for
> admins. This makes it possible to limit what clients, users, roles, etc.
> admins have access to. Documentation is missing for this at the moment, but
> will be added in time for 3.2.0.Final.
> Docker Registry support
>
> It's not possible to secure a Docker Registry with a standard OAuth or
> OpenID Connect provider. For some strange reason they have only partially
> followed the specifications and the Docker Registry maintainers refuse to
> fix this! Fear not, thanks to cainj13 <https://github.com/cainj13> who
> contributed this we now have a special Docker Registry protocol that can be
> enabled in Keycloak.
> Authentication sessions and access tokens
>
> In the effort to provide support for running Keycloak in multiple data
> centers we've done a large amount of work around user sessions. We've
> introduced authentication sessions that are special sessions used primarily
> during the authentication flows. There are two main reasons for this.
> Authentication flows can fairly easily be fixed to a specific node within a
> specific data center and there is no need to replicate this to other data
> centers. They are also more write heavy than the user sessions. The
> introduction of access tokens makes it possible to detach actions (for
> example verify email) from a user session, which has a number of benefits.
> More will come in future 3.x releases and by the end of the year we aim to
> fully support replicating Keycloak cross multiple data centers.
> Authorization Service improvements
>
> There's been a lot of work done to the authorization services in this
> release. Way to many to list here so check out JIRA
> <https://issues.jboss.org/browse/KEYCLOAK-5072?jql=
> project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.
> 2.0.CR1%20and%20component%20%3D%20Authorization>
> for
> details.
> QuickStarts
>
> We've introduced new QuickStarts with the aim to make it even simpler for
> you to get started securing your applications and services with Keycloak.
> The QuickStarts have proper tests as well, which can serve as a reference
> on how to tests your own applications and services secured with Keycloak.
> Check out the new QuickStarts in the keycloak-quickstarts GitHub repository
> <https://github.com/keycloak/keycloak-quickstarts>.
> Upgraded AngularJS and JQuery
>
> We've upgraded the versions we use of AngularJS and JQuery as there where a
> number of known vulnerabilities. We're fairly certain neither of the known
> vulnerabilities affect Keycloak, but to be on the safe side we decided to
> upgrade.
> Updated Password Hashing Algorithms
>
> We're still using PBKDF2, but we've added support for SHA256 and SHA512.
> PBKDF2 is SHA256 is now used by default.
> Spring Boot QuickStarter
>
> We've added a new Spring Boot QuickStarter that makes it super simple to
> get started securing your Spring Boot applications. For more details check
> out the blog post about it
> <http://blog.keycloak.org/2017/05/easily-secure-your-spring-boot.html>.
> Loads more..
>
>    - Partial export of realms in the admin console
>    - Redirect URI rewrite rules for adapters
>    - Test email settings in the admin console
>    - Initial access tokens now persisted to the db
>
> The full list of resolved issues is available in JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%
> 20keycloak%20and%20fixVersion%20%3D%203.2.0.CR1>
> .
> Upgrading
>
> Before you upgrade remember to backup your database and check the migration
> guide
> <https://keycloak.gitbooks.io/documentation/server_admin/topics/
> MigrationFromOlderVersions.html>.
> Release candidates are not recommended in production and we do not support
> upgrading from release candidates.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sblanc at redhat.com  Mon Jul  3 02:29:07 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 3 Jul 2017 08:29:07 +0200
Subject: [keycloak-dev] Cookie token storage for Spring Security
In-Reply-To: <CAMHuGfq_7xgVd_gFfF7RC9=E68vSPyLCB=r+=G_QSn9zEhYKuw@mail.gmail.com>
References: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>
	<CALvb29z895yGf0wk9-PNV78uxxv9oR8Um6XKPVEPeMbpuSJn+A@mail.gmail.com>
	<CAMHuGfq_7xgVd_gFfF7RC9=E68vSPyLCB=r+=G_QSn9zEhYKuw@mail.gmail.com>
Message-ID: <CAMZCGg9tjKaHzKdT3dmFSMyFdb1NJO_-9_wV4JMzoALRayCmqg@mail.gmail.com>

Hi Sjoerd,

You don't to wait for the ticket to be accepted, just send your PR ;)

Is KEYCLOAK-4342 blocking you KEYCLOAK-5130 ? If you know how to fix it you
can also send a PR for this one.

Seb



On Sun, Jul 2, 2017 at 5:44 PM, Sjoerd Cranen <sjoerd.cranen at teampicnic.com>
wrote:

> I've submitted https://issues.jboss.org/browse/KEYCLOAK-5130 for this. If
> the bug report is accepted, I'll be happy to open a PR with a solution.
>
> Answering one of my own questions: the peculiar cookie path I mentioned in
> my original post is already described in KEYCLOAK-4342.
>
> On Fri, Jun 23, 2017 at 6:08 PM, Konstantin Gribov <grossws at gmail.com>
> wrote:
>
> > On Fri, Jun 23, 2017 at 4:46 PM Sjoerd Cranen <
> > sjoerd.cranen at teampicnic.com> wrote:
> >
> >> One thing I'm wondering is why the cookie path for the adapter state
> >> cookie
> >> is always set to the context root in CookieTokenStore. In particular, it
> >> would seem that if I change the Spring Security adapter in a
> >> straightforward way to store the cookies, the cookie would always be set
> >> on
> >> "/sso", which would not be very useful.
> >>
> > Same applies for Jetty adapter. But it doesn't work now (see
> > KEYCLOAK-2514).
> >
> > --
> >
> > Best regards,
> > Konstantin Gribov
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sjoerd.cranen at teampicnic.com  Mon Jul  3 04:43:03 2017
From: sjoerd.cranen at teampicnic.com (Sjoerd Cranen)
Date: Mon, 3 Jul 2017 10:43:03 +0200
Subject: [keycloak-dev] Cookie token storage for Spring Security
In-Reply-To: <CAMZCGg9tjKaHzKdT3dmFSMyFdb1NJO_-9_wV4JMzoALRayCmqg@mail.gmail.com>
References: <CAMHuGfrfsXVpio6v=bN3L5fX_-cmkA4rp7m6QbxPJ22LtYFq9g@mail.gmail.com>
	<CALvb29z895yGf0wk9-PNV78uxxv9oR8Um6XKPVEPeMbpuSJn+A@mail.gmail.com>
	<CAMHuGfq_7xgVd_gFfF7RC9=E68vSPyLCB=r+=G_QSn9zEhYKuw@mail.gmail.com>
	<CAMZCGg9tjKaHzKdT3dmFSMyFdb1NJO_-9_wV4JMzoALRayCmqg@mail.gmail.com>
Message-ID: <CAMHuGfr_AGgPEAiM-w9r4g0gEW8ebk_Nai0_yN7bA+uvOK=6hA@mail.gmail.com>

Confirmation per e-mail is enough, just following the dev guidelines from
the readme ;-) I've opened a PR. It includes a workaround for KEYCLOAK-4342
so the solution can at least be tested. If the workaround is considered
good enough I'll open a separate PR for it.

Cheers,
Sjoerd

On Mon, Jul 3, 2017 at 8:29 AM, Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi Sjoerd,
>
> You don't to wait for the ticket to be accepted, just send your PR ;)
>
> Is KEYCLOAK-4342 blocking you KEYCLOAK-5130 ? If you know how to fix it
> you can also send a PR for this one.
>
> Seb
>
>
>
> On Sun, Jul 2, 2017 at 5:44 PM, Sjoerd Cranen <
> sjoerd.cranen at teampicnic.com> wrote:
>
>> I've submitted https://issues.jboss.org/browse/KEYCLOAK-5130 for this. If
>> the bug report is accepted, I'll be happy to open a PR with a solution.
>>
>> Answering one of my own questions: the peculiar cookie path I mentioned in
>> my original post is already described in KEYCLOAK-4342.
>>
>> On Fri, Jun 23, 2017 at 6:08 PM, Konstantin Gribov <grossws at gmail.com>
>> wrote:
>>
>> > On Fri, Jun 23, 2017 at 4:46 PM Sjoerd Cranen <
>> > sjoerd.cranen at teampicnic.com> wrote:
>> >
>> >> One thing I'm wondering is why the cookie path for the adapter state
>> >> cookie
>> >> is always set to the context root in CookieTokenStore. In particular,
>> it
>> >> would seem that if I change the Spring Security adapter in a
>> >> straightforward way to store the cookies, the cookie would always be
>> set
>> >> on
>> >> "/sso", which would not be very useful.
>> >>
>> > Same applies for Jetty adapter. But it doesn't work now (see
>> > KEYCLOAK-2514).
>> >
>> > --
>> >
>> > Best regards,
>> > Konstantin Gribov
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From psilva at redhat.com  Mon Jul  3 07:26:51 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 3 Jul 2017 08:26:51 -0300
Subject: [keycloak-dev] Possible bug in ResourceSetServlet may cause
 resources being overwritten
In-Reply-To: <CAOP_0_4wRe-x-KXjjcJXihE6vySQJqr4Upfp5pGRDoQab56uHw@mail.gmail.com>
References: <CAOP_0_4wRe-x-KXjjcJXihE6vySQJqr4Upfp5pGRDoQab56uHw@mail.gmail.com>
Message-ID: <CAJrcDBeutz3wVUbMO2qe8ibtmw3fWCU8rZWTRUjakKET9mHpnA@mail.gmail.com>

Thanks, Man Yue Mo. https://issues.jboss.org/browse/KEYCLOAK-5135

On Fri, Jun 30, 2017 at 7:12 AM, Man Yue Mo <mmo at semmle.com> wrote:

> Hi,
>
> In the following:
>
> https://lgtm.com/projects/g/keycloak/keycloak/snapshot/
> 6b3b04f10f5a3ffd0efbec2fcdbe76b518ce8837/files/services/src/
> main/java/org/keycloak/authorization/admin/ResourceSetService.java#V105
>
> because a string is compared to an enum in the last condition, the check
> always returns false. In particular, if the resource already existed, then
> it may overwrite the existing resource. Thanks.
>
> Best Regards,
>
> Man Yue Mo
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mitya at cargosoft.ru  Mon Jul  3 12:16:43 2017
From: mitya at cargosoft.ru (Dmitry)
Date: Mon, 03 Jul 2017 19:16:43 +0300
Subject: [keycloak-dev] ProviderFactory::postDeploy?
Message-ID: <1499098603.12833.2.camel@cargosoft.ru>

Hi,

At the moment, the ProviderFactory::postInit() method is not called
during hot (re)deployment of providers, only during server startup.
This is considered a bug (see discussion in keycloak-user, KEYCLOAK-
5131 and PR #4282).

Meanwhile, Marek and I have been discussing the problem of accessing
data model from postInit (see the keycloak-user post). Turns out that
the semantics should be significantly different depending on whether
postInit() is called during server startup or hot deploy. In the first
case, one should listen for PostMigrationEvent. In the second case, the
event is not available and thus shouldn't be listened for. However, the
provider should be able to somehow distinguish the cases. There are
some hacks like analyzing current thread name, querying JNDI or
Resteasy, but maybe we can come up with something more clean and
simple?

Marek has suggested that the new method should be introduced on the
ProviderFactory interface, with empty default implementation (in order
not to break the code). What do you think?

Dmitry

From psilva at redhat.com  Mon Jul  3 15:51:06 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 3 Jul 2017 16:51:06 -0300
Subject: [keycloak-dev] UMA Implementation
Message-ID: <CAJrcDBeDgGfpBzheNsOnVuTyUmTmmZAEWY26v6PRyxk6gZy+aA@mail.gmail.com>

Now we need to work hard to get UMA 2.0 in :)

http://kantarainitiative.org/confluence/display/uma/UMA+Implementations

Regards.
Pedro Igor

From bburke at redhat.com  Mon Jul  3 16:19:37 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 3 Jul 2017 16:19:37 -0400
Subject: [keycloak-dev] ProviderFactory::postDeploy?
In-Reply-To: <1499098603.12833.2.camel@cargosoft.ru>
References: <1499098603.12833.2.camel@cargosoft.ru>
Message-ID: <5cfc01b9-cb8c-9fc8-93fe-1d9b545861d9@redhat.com>

Please see my response to your original problem.


On 7/3/17 12:16 PM, Dmitry wrote:
> Hi,
>
> At the moment, the ProviderFactory::postInit() method is not called
> during hot (re)deployment of providers, only during server startup.
> This is considered a bug (see discussion in keycloak-user, KEYCLOAK-
> 5131 and PR #4282).
>
> Meanwhile, Marek and I have been discussing the problem of accessing
> data model from postInit (see the keycloak-user post). Turns out that
> the semantics should be significantly different depending on whether
> postInit() is called during server startup or hot deploy. In the first
> case, one should listen for PostMigrationEvent. In the second case, the
> event is not available and thus shouldn't be listened for. However, the
> provider should be able to somehow distinguish the cases. There are
> some hacks like analyzing current thread name, querying JNDI or
> Resteasy, but maybe we can come up with something more clean and
> simple?
>
> Marek has suggested that the new method should be introduced on the
> ProviderFactory interface, with empty default implementation (in order
> not to break the code). What do you think?
>
> Dmitry
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Tue Jul  4 01:56:44 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 4 Jul 2017 07:56:44 +0200
Subject: [keycloak-dev] Resource versions for SNAPSHOTS builds
Message-ID: <CAJgngAd0vHASr+AEqvcU0mb4s1R4Y26sqXwxJmRCNJUfixguYw@mail.gmail.com>

When running SNAPSHOT builds the resource version contains -snapshot, but
doesn't get updated. This is annoying since stale resources are cached. To
work around this I've sent a PR to replace -snapshot with the build time
[1].

Further, When KeycloakServer is ran directly from the IDE the build time
isn't updated so I made it change the build time to the execution time when
not ran from within Maven [2].

[1]
https://github.com/keycloak/keycloak/pull/4287/files#diff-54e8a0187ed2030b92bb214c12019a38R49

[2]
https://github.com/keycloak/keycloak/pull/4287/files#diff-04c94b7f1ce8f7df22b037f39aa258cdR112

From mposolda at redhat.com  Tue Jul  4 03:26:13 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 4 Jul 2017 09:26:13 +0200
Subject: [keycloak-dev] ProviderFactory::postDeploy?
In-Reply-To: <5cfc01b9-cb8c-9fc8-93fe-1d9b545861d9@redhat.com>
References: <1499098603.12833.2.camel@cargosoft.ru>
	<5cfc01b9-cb8c-9fc8-93fe-1d9b545861d9@redhat.com>
Message-ID: <d33fbdae-45d8-ff6c-5311-f6d8e25b6138@redhat.com>

As Dmitri mentioned, the problem is that "postInit" is called before 
model is fully initialized (eg. before migration), so it's not really 
safe to access DB from there.

The bit related issue is, if we can add better support for the 
"lazyInit" pattern into provider framework instead of make the providers 
to care about the synchronization etc? We can possibly add the interface 
like LazyInitializationProvider with single "lazyInit" method? If 
provider implements it, the framework will ensure that the method is 
called just once at the time when provider creation is requested for the 
first time.

Marek

On 03/07/17 22:19, Bill Burke wrote:
> Please see my response to your original problem.
>
>
> On 7/3/17 12:16 PM, Dmitry wrote:
>> Hi,
>>
>> At the moment, the ProviderFactory::postInit() method is not called
>> during hot (re)deployment of providers, only during server startup.
>> This is considered a bug (see discussion in keycloak-user, KEYCLOAK-
>> 5131 and PR #4282).
>>
>> Meanwhile, Marek and I have been discussing the problem of accessing
>> data model from postInit (see the keycloak-user post). Turns out that
>> the semantics should be significantly different depending on whether
>> postInit() is called during server startup or hot deploy. In the first
>> case, one should listen for PostMigrationEvent. In the second case, the
>> event is not available and thus shouldn't be listened for. However, the
>> provider should be able to somehow distinguish the cases. There are
>> some hacks like analyzing current thread name, querying JNDI or
>> Resteasy, but maybe we can come up with something more clean and
>> simple?
>>
>> Marek has suggested that the new method should be introduced on the
>> ProviderFactory interface, with empty default implementation (in order
>> not to break the code). What do you think?
>>
>> Dmitry
>> _______________________________________________
>> 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 rafael.kapp at xovis.com  Tue Jul  4 04:53:21 2017
From: rafael.kapp at xovis.com (Rafael Kapp)
Date: Tue, 4 Jul 2017 08:53:21 +0000
Subject: [keycloak-dev] GroupMembershipMapper with ID
Message-ID: <VI1PR0101MB2398C1B6A0B3BE7B0101663FF7D70@VI1PR0101MB2398.eurprd01.prod.exchangelabs.com>

Hello Keycloak Devs,

We need a mapper for oidc which maps the ID of a group. We are wondering if the GroupMembershipMapper, which maps the name of a group, could be made configurable to map one of Name, Full Path, or ID.

Or would it be better to create a new mapper type? The difference between these mappers would be minimal.

Best regards,
Rafael


From e.kapprafael at gmail.com  Tue Jul  4 05:00:56 2017
From: e.kapprafael at gmail.com (Rafael Kapp)
Date: Tue, 4 Jul 2017 11:00:56 +0200
Subject: [keycloak-dev] GroupMembershipMapper with ID
Message-ID: <CAExsV8uYE7nccU0Mu-M=mSd+zG1cuoc7+a1ShuavH2JQYKaQ1A@mail.gmail.com>

Hello Keycloak Devs,

We need a mapper for oidc which maps the ID of a group. We are wondering if
the GroupMembershipMapper, which maps the name of a group, could be made
configurable to map one of Name, Full Path, or ID.

Or would it be better to create a new mapper type? The difference between
these mappers would be minimal.

Best regards,

Rafael

From sthorger at redhat.com  Tue Jul  4 14:29:11 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 4 Jul 2017 20:29:11 +0200
Subject: [keycloak-dev] keycloak.js and iframe caching issues
Message-ID: <CAJgngAd-fJDBh_tSJmmako4zh6ha_BYxccH=tK2C1FaYBtCnLg@mail.gmail.com>

When keycloak.js and the session iframe are updated that can cause issues
as they are currently cached by the browser. This is now changed and unless
keycloak.js is loaded with ?version=<KC VERSION> they will no longer be
cached. If you load keycloak.js with ?version<KC VERSION> it will
automatically load the iframe with the same query param which makes that
cached as well.

From sthorger at redhat.com  Tue Jul  4 14:29:37 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 4 Jul 2017 20:29:37 +0200
Subject: [keycloak-dev] keycloak.js and iframe caching issues
In-Reply-To: <CAJgngAd-fJDBh_tSJmmako4zh6ha_BYxccH=tK2C1FaYBtCnLg@mail.gmail.com>
References: <CAJgngAd-fJDBh_tSJmmako4zh6ha_BYxccH=tK2C1FaYBtCnLg@mail.gmail.com>
Message-ID: <CAJgngAc=mhig1GO=dORL+bN9LfT+QkQNeDouKMkWdyxo5wrAFw@mail.gmail.com>

Forgot to add relevant JIRAs which link to the PR:

https://issues.jboss.org/browse/KEYCLOAK-4556
https://issues.jboss.org/browse/KEYCLOAK-5022

On 4 July 2017 at 20:29, Stian Thorgersen <sthorger at redhat.com> wrote:

> When keycloak.js and the session iframe are updated that can cause issues
> as they are currently cached by the browser. This is now changed and unless
> keycloak.js is loaded with ?version=<KC VERSION> they will no longer be
> cached. If you load keycloak.js with ?version<KC VERSION> it will
> automatically load the iframe with the same query param which makes that
> cached as well.
>

From mitya at cargosoft.ru  Tue Jul  4 18:33:36 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Wed, 05 Jul 2017 01:33:36 +0300
Subject: [keycloak-dev] Realm Admin Resource SPI
Message-ID: <1499207616.2926.1.camel@cargosoft.ru>

Hi,

This topic has been around for a while, and I'm glad to know that it
has finally been greenlit. Here we'll discuss the requirements for the
upcoming Realm Admin Resource SPI, as well as class/method naming and
any other relevant stuff.

An admin resource is a privileged (protected) resource that exposes
Keycloak data model and business logic via REST. A the moment, it is
possible to create ad-hoc admin resources on top of existing Realm
Resource SPI, but 1) it requires a lot of boilerplate and workarounds,
and 2) there are limitations. For a while, we've been developing a
Keycloak extension that utilizes such ad-hoc admin resources (for those
interested, it brings into Keycloak support for hardware OTP tokens
with full lifecycle) . We've tried to summarize our experience in
BeerCloak [1], where most techniques are demonstrated; I'll refer to
this example in the process.

Now what makes admin resource different from the regular realm
resource? I'll talk about some major features; feel free to share your
thoughts in case I've forgotten something.

Security
========

As admin resource most likely introduces some new functionality, it's
quite natural to limit access to this new functionality by custom
roles. For example, if we introduce feature "foo", most likely we'll
want "view-foo" and "manage-foo" roles. This requirement breaks down to
the following steps:
* create roles for existing realms. That means adding roles to "*-
realm"?clients of master realm and to "realm-management" client of
regular realms;
* ditto for each newly added realm;
* add roles to the "admin" realm role of master realm;
* server-side authorization: provide an instance of
o.k.services.resources.admin.AdminAuth (or subclass) to REST resource
methods so that they could call AdminAuth::hasAppRole;
* client-side authorization: add viewFoo and manageFoo properties to
the "access" AngularJS object.

All of the above is doable on top of Realm Resource SPI (see
BeerCloak), but the code is 99% boilerplate. In fact, the only thing
that the provider (ideally) has to do is to declare the two roles. The
actual implementation could be moved to the SPI. What we need is to
discuss how the roles should be declared (callback, annotation etc.)

Logging
=======

Most likely the admin resource will deal with custom JPA entities
defined using Entity SPI. Moreover, there will likely be a need to log
admin events about this entity and its operations. Currently, we are
limited to 4 generic operation types (see
o.k.events.admin.OperationType) and a list of 27 hardcoded
entity/resource types (see o.k.events.admin.ResourceType). This is a
serious limitation because any provider that defines custom entity
and/or REST operations will be unable to log its activity with Keycloak
API and present it with Keycloak GUI. As an example, the aforementioned
OTP extension would benefit from logging admin events with DEVICE
resource type and ENROLL/REVOKE/LOCK/UNLOCK/RESYNC additional operation
types. We can discuss now which way the provider would define its
custom resource operation and resource types. Under the hood, the
existing enums should be extended with the supplied values (possibly
using the extensible enum pattern [2][3]). The values should also
appear in
o.k.services.resources.admin.info.ServerInfoAdminResource::ENUMS so
that log filtering could be applied in the GUI.

Last time when we discussed this, Stian said:
> Introducing this as part of a admin resource spi would make perfect
> sense.

I agree that extending OperationType is more pertinent to Admin
Resource SPI ("I define an operation and I want to be able to log it").
At the same time, extending ResourceType seems to be more topical for
Entity SPI ("I define an entity and I want to log everything about
it"). We should decide if we should extend the said SPIs, or otherwise
create independent OperationTypeSpi+ResourceTypeSpi that could be mixed
into any provider, be it entity, admin resource or anything else.

At the moment, this couldn't be implemented without modifying Keycloak
sources.

Relation to FeatureProvider
===========================

Bill, once we discussed the potential FeatureProvider:
> ?I was also thinking of having a FeatureProvider that would be an
> "uber" component that could install sub components.? i.e. an
> authenticator, user federation provider, etc.

I think we could revisit this topic too, since both SPIs seem to be
closely related.

Thanks for reading this bulky post! Any feedback welcome,
Dmitry Telegin
CTO, CargoSoft LLC
http://cargosoft.ru/en/rm/about/


[1] https://github.com/dteleguin/beercloak
[2] https://blogs.oracle.com/darcy/mixing-in-an-enum
[3] https://gist.github.com/KamilT/3192681 id="-x-evo-selection-start-
marker">

From sthorger at redhat.com  Wed Jul  5 01:33:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 07:33:04 +0200
Subject: [keycloak-dev] Chinese translations
Message-ID: <CAJgngAcKqKSakC02ZYbuseN0WJ28okwa=0_AzajL=9ba==emZw@mail.gmail.com>

I'm trying once more. Is there someone out there that knows Chinese that
can review PR for translations?

The PR is here:
https://github.com/keycloak/keycloak/pull/4251

From sthorger at redhat.com  Wed Jul  5 03:26:55 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 09:26:55 +0200
Subject: [keycloak-dev] OpenShift v2 cartridge
Message-ID: <CAJgngAdQdBp7V3ZBS3WDprHco2_0WF8tQ+sqJtuzRmF6nBh40w@mail.gmail.com>

Is anyone still using the Keycloak OpenShift v2 cartridge [1] or can we
safely stop maintaining that?

[1] https://github.com/keycloak/openshift-keycloak-cartridge

From sthorger at redhat.com  Wed Jul  5 03:39:40 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 5 Jul 2017 09:39:40 +0200
Subject: [keycloak-dev] Keycloak 3.2.0.Final Released
Message-ID: <CAJgngAfs_VryfU6K52F2BV9=N2dZQ0kKRA3pMryEFQ_F+iFtzA@mail.gmail.com>

Keycloak 3.2.0.Final has just been released.

To download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.

The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.0.Final>
.
Upgrading

Before you upgrade remember to backup your database and check the migration
guide
<https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
.

From kishansagathiya at gmail.com  Fri Jul  7 06:50:15 2017
From: kishansagathiya at gmail.com (Kishan Sagathiya)
Date: Fri, 7 Jul 2017 16:20:15 +0530
Subject: [keycloak-dev] ECDSA support for Keycloak
Message-ID: <CAAYYq6shLeD9YSahqs-aQDmutZZu8X8gAJ1ueNmM1c64VLBfBA@mail.gmail.com>

Hey,
We are trying to develop ECDSA support for Keycloak.
I have already written a ECDSAProvider and I am using nimbus-jose-jwt
library. Though, I am not sure how to proceed forward. How to add an option
in keycloak console to add a ECDSA key, etc.
If anyone can help me with this, that would be great.

-Kishan Sagathiya



<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=kishansagathiya at gmail.com&idSignature=22>

From sthorger at redhat.com  Fri Jul  7 07:35:20 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 7 Jul 2017 13:35:20 +0200
Subject: [keycloak-dev] ECDSA support for Keycloak
In-Reply-To: <CAAYYq6shLeD9YSahqs-aQDmutZZu8X8gAJ1ueNmM1c64VLBfBA@mail.gmail.com>
References: <CAAYYq6shLeD9YSahqs-aQDmutZZu8X8gAJ1ueNmM1c64VLBfBA@mail.gmail.com>
Message-ID: <CAJgngAd4UqN7c7BYTnuHFvHtfGq84-mQ1K=tz6Yx2-tgYjKF4A@mail.gmail.com>

ECDSA would be a great addition as there should be significant performance
improvements over RSA.

First thing is we have our own internal utils for signing that relies on
BouncyCastle and we would not accept a dependency on "nimbus-jose-jwt". Due
to our productization process for RH-SSO we do not easily accept adding new
third party dependencies and in this case it's completely pointless as we
already have the equivalent libraries internally.

To add ECDSA support there is a fair bit of work needed:

1. Add key provider implementations. We'd need providers that correspond to
the ones we have for RSA (upload keys, generated keys, etc.)
2. Add option to realm (to set default realm signing algorithm) and clients
to be able to override the algorithm to use
3. Update internal signing libraries on the server side to use correct
algorithm according to 1
4. Update adapters to support ECDSA signatures - this includes Java and
Node.js adapters
5. Loads of testing
6. Documentation updates

That's at least what I can think of at the top of my head.


On 7 July 2017 at 12:50, Kishan Sagathiya <kishansagathiya at gmail.com> wrote:

> Hey,
> We are trying to develop ECDSA support for Keycloak.
> I have already written a ECDSAProvider and I am using nimbus-jose-jwt
> library. Though, I am not sure how to proceed forward. How to add an option
> in keycloak console to add a ECDSA key, etc.
> If anyone can help me with this, that would be great.
>
> -Kishan Sagathiya
>
>
>
> <https://mailtrack.io/> Sent with Mailtrack
> <https://mailtrack.io/install?source=signature&lang=en&
> referral=kishansagathiya at gmail.com&idSignature=22>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From steindl.bernhard94 at gmail.com  Sun Jul  9 18:06:01 2017
From: steindl.bernhard94 at gmail.com (Bernhard Steindl)
Date: Mon, 10 Jul 2017 00:06:01 +0200
Subject: [keycloak-dev] Access Query Parameter in FreeMarker Login Template
	- Keycloak 2.1.0
References: <710618DE-5D82-4114-9C2F-D3992F48BD57@gmail.com>
Message-ID: <91F016C4-DD90-4339-A1D1-B7E20AF2501B@gmail.com>

Hello,

I must access Query Parameters passed to my keycloak login theme.

Neither was I able to obtain them using 

RequestParameters.paramName nor
request.getParameter(paramName)
	
in the login FreeMarker template.

Everytime I access a query parameter using these methods I get an FreeMarker error

2017-07-06 13:32:07,917 ERROR [freemarker.runtime] (default task-12) Error executing FreeMarker template: 
freemarker.core.InvalidReferenceException: The following has evaluated to null or missing

I am using Keycloak 2.1.0 which includes a FreeMarker jar version 2.3.20.


Can anybody support me in this issue?
I need to use query params to dynamically display information on the login theme.

Kind Regards,
Bernhard

From thiago.addevico at gmail.com  Mon Jul 10 08:21:25 2017
From: thiago.addevico at gmail.com (Thiago Presa)
Date: Mon, 10 Jul 2017 09:21:25 -0300
Subject: [keycloak-dev] Tables without PK constraints in MySQL Cluster
Message-ID: <CAHDpToW_QBZ3D-hq=AcxCPRaUphL4U_-a++subOwsFjYprySag@mail.gmail.com>

Hi,

I've reported KEYCLOAK-4928, and I was wondering if somebody could take a
look at the primary key constraints we've created to make sure we've got it
correctly. Thanks in advance!

Best regards,
Thiago Presa

From sthorger at redhat.com  Tue Jul 11 08:29:18 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 11 Jul 2017 14:29:18 +0200
Subject: [keycloak-dev] Async authentication example
Message-ID: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>

I gave it a go and implemented an "async" authentication example. It's
rather simple what happens is:

* User authenticates with username only
* Then a "waiting" page is displayed, which is waiting for some external
callback. This could be an app or whatever that verifies the user then
sends the callback. In the example a CURL command is printed on sysout for
the server which you can run to "simulate" the callback from the app.
* Once the callback is received the user is authenticated without filling
in password or any other credentials in the main browser

https://github.com/stianst/authenticator-example

Check it out here:
https://youtu.be/C09BpNIf4v8

It's a bit hacky in the way it's implemented:

* Using notes for "callback" is a bit strange maybe?
* Had to use custom realm resource for callback endpoint. Is this strange?
* Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
that
* No way to push change to browser, so have to pull every 2 seconds. Maybe
we could add a simple authentication event feature that uses websockets and
a small auth js lib to do the job of notification?

From sthorger at redhat.com  Tue Jul 11 09:21:02 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 11 Jul 2017 15:21:02 +0200
Subject: [keycloak-dev] Realm Admin Resource SPI
In-Reply-To: <1499207616.2926.1.camel@cargosoft.ru>
References: <1499207616.2926.1.camel@cargosoft.ru>
Message-ID: <CAJgngAdeCvuzevoU4AmhVOfN27BcRYe0-3k0rKmgUSSyeM2f-w@mail.gmail.com>

I wouldn't say it's been greenlit just yet. Firstly, we need to discuss if
it's something we want to add. Personally I'm not convinced it'll get
enough use to justify the amount of time required to implement and test.
Secondly, we need to figure out how it should look like, including trying
to not make it to overly complicated. From your summary below it's sounds
like your after something that'll end up being rather large and complicated.

On 5 July 2017 at 00:33, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Hi,
>
> This topic has been around for a while, and I'm glad to know that it
> has finally been greenlit. Here we'll discuss the requirements for the
> upcoming Realm Admin Resource SPI, as well as class/method naming and
> any other relevant stuff.


> An admin resource is a privileged (protected) resource that exposes
> Keycloak data model and business logic via REST. A the moment, it is
> possible to create ad-hoc admin resources on top of existing Realm
> Resource SPI, but 1) it requires a lot of boilerplate and workarounds,
> and 2) there are limitations. For a while, we've been developing a
> Keycloak extension that utilizes such ad-hoc admin resources (for those
> interested, it brings into Keycloak support for hardware OTP tokens
> with full lifecycle) . We've tried to summarize our experience in
> BeerCloak [1], where most techniques are demonstrated; I'll refer to
> this example in the process.
>
> Now what makes admin resource different from the regular realm
> resource? I'll talk about some major features; feel free to share your
> thoughts in case I've forgotten something.
>
> Security
> ========
>
> As admin resource most likely introduces some new functionality, it's
> quite natural to limit access to this new functionality by custom
> roles. For example, if we introduce feature "foo", most likely we'll
> want "view-foo" and "manage-foo" roles. This requirement breaks down to
> the following steps:
> * create roles for existing realms. That means adding roles to "*-
> realm" clients of master realm and to "realm-management" client of
> regular realms;
> * ditto for each newly added realm;
> * add roles to the "admin" realm role of master realm;
> * server-side authorization: provide an instance of
> o.k.services.resources.admin.AdminAuth (or subclass) to REST resource
> methods so that they could call AdminAuth::hasAppRole;
> * client-side authorization: add viewFoo and manageFoo properties to
> the "access" AngularJS object.
>
> All of the above is doable on top of Realm Resource SPI (see
> BeerCloak), but the code is 99% boilerplate. In fact, the only thing
> that the provider (ideally) has to do is to declare the two roles. The
> actual implementation could be moved to the SPI. What we need is to
> discuss how the roles should be declared (callback, annotation etc.)
>

I'm not sure adding additional roles really is needed. In most cases I
would think view/manage roles would be sufficient. The focus should rather
be on fine-grained permissions which we recently added.


>
> Logging
> =======
>
> Most likely the admin resource will deal with custom JPA entities
> defined using Entity SPI. Moreover, there will likely be a need to log
> admin events about this entity and its operations. Currently, we are
> limited to 4 generic operation types (see
> o.k.events.admin.OperationType) and a list of 27 hardcoded
> entity/resource types (see o.k.events.admin.ResourceType). This is a
> serious limitation because any provider that defines custom entity
> and/or REST operations will be unable to log its activity with Keycloak
> API and present it with Keycloak GUI. As an example, the aforementioned
> OTP extension would benefit from logging admin events with DEVICE
> resource type and ENROLL/REVOKE/LOCK/UNLOCK/RESYNC additional operation
> types. We can discuss now which way the provider would define its
> custom resource operation and resource types. Under the hood, the
> existing enums should be extended with the supplied values (possibly
> using the extensible enum pattern [2][3]). The values should also
> appear in
> o.k.services.resources.admin.info.ServerInfoAdminResource::ENUMS so
> that log filtering could be applied in the GUI.
>

Rather than bring in additional entities, would it not be better to re-use
generic entities? We have a generic component model for config. We have
generic credentials store. We have attributes on everything. Creating
custom entities is just complicated and hard to maintain.


> Last time when we discussed this, Stian said:
> > Introducing this as part of a admin resource spi would make perfect
> > sense.
>
> I agree that extending OperationType is more pertinent to Admin
> Resource SPI ("I define an operation and I want to be able to log it").
> At the same time, extending ResourceType seems to be more topical for
> Entity SPI ("I define an entity and I want to log everything about
> it"). We should decide if we should extend the said SPIs, or otherwise
> create independent OperationTypeSpi+ResourceTypeSpi that could be mixed
> into any provider, be it entity, admin resource or anything else.
>
> At the moment, this couldn't be implemented without modifying Keycloak
> sources.
>


I'm not sure I like the idea of extending either. I'd rather just have
generic plain old strings in event types, operation types, resource types,
etc.. That is much simpler to extend than trying to "extend" enums.



>
> Relation to FeatureProvider
> ===========================
>
> Bill, once we discussed the potential FeatureProvider:
> >  I was also thinking of having a FeatureProvider that would be an
> > "uber" component that could install sub components.  i.e. an
> > authenticator, user federation provider, etc.
>
> I think we could revisit this topic too, since both SPIs seem to be
> closely related.
>
> Thanks for reading this bulky post! Any feedback welcome,
> Dmitry Telegin
> CTO, CargoSoft LLC
> http://cargosoft.ru/en/rm/about/
>
>
> [1] https://github.com/dteleguin/beercloak
> [2] https://blogs.oracle.com/darcy/mixing-in-an-enum
> [3] https://gist.github.com/KamilT/3192681 id="-x-evo-selection-start-
> marker">
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Tue Jul 11 11:05:00 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 11 Jul 2017 11:05:00 -0400
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
Message-ID: <f3f70d21-171e-9234-93f5-a81e27fdd278@redhat.com>

Awesome!   Comments inline


On 7/11/17 8:29 AM, Stian Thorgersen wrote:
> I gave it a go and implemented an "async" authentication example. It's
> rather simple what happens is:
>
> * User authenticates with username only
> * Then a "waiting" page is displayed, which is waiting for some external
> callback. This could be an app or whatever that verifies the user then
> sends the callback. In the example a CURL command is printed on sysout for
> the server which you can run to "simulate" the callback from the app.
> * Once the callback is received the user is authenticated without filling
> in password or any other credentials in the main browser
>
> https://github.com/stianst/authenticator-example
>
> Check it out here:
> https://youtu.be/C09BpNIf4v8
>
> It's a bit hacky in the way it's implemented:
>
> * Using notes for "callback" is a bit strange maybe?
Why?

> * Had to use custom realm resource for callback endpoint. Is this strange?
> * Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
> that
So, in 7.2 it will work for cross-DC?

> * No way to push change to browser, so have to pull every 2 seconds. Maybe
> we could add a simple authentication event feature that uses websockets and
> a small auth js lib to do the job of notification?
You'd have to have a cross-DC notification bus for something like this 
as only one node in the cluster would have the websocket open. If you 
had Javascript that did the polling, the user wouldn't even see it.

Bill


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


From psilva at redhat.com  Tue Jul 11 13:10:49 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 11 Jul 2017 14:10:49 -0300
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
Message-ID: <CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>

Really nice !

On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> I gave it a go and implemented an "async" authentication example. It's
> rather simple what happens is:
>
> * User authenticates with username only
> * Then a "waiting" page is displayed, which is waiting for some external
> callback. This could be an app or whatever that verifies the user then
> sends the callback. In the example a CURL command is printed on sysout for
> the server which you can run to "simulate" the callback from the app.
> * Once the callback is received the user is authenticated without filling
> in password or any other credentials in the main browser
>

Maybe you can use a SET [1], which is basically a JWT, in order to
communicate authentication events between parties. For instance, send
additional data to the external callback about the authentication context
and receive back from the external callback information on how to proceed
with the authentication.

[1] https://tools.ietf.org/html/draft-hunt-idevent-token-03


>
> https://github.com/stianst/authenticator-example
>
> Check it out here:
> https://youtu.be/C09BpNIf4v8
>
> It's a bit hacky in the way it's implemented:
>
> * Using notes for "callback" is a bit strange maybe?
> * Had to use custom realm resource for callback endpoint. Is this strange?
> * Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
> that
> * No way to push change to browser, so have to pull every 2 seconds. Maybe
> we could add a simple authentication event feature that uses websockets and
> a small auth js lib to do the job of notification?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Jul 12 02:58:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Jul 2017 08:58:57 +0200
Subject: [keycloak-dev] NonIDERunListener
Message-ID: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>

What's the point of this? I don't see why we would want to disable Keycloak
server logging when running from Maven?

From sthorger at redhat.com  Wed Jul 12 03:02:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Jul 2017 09:02:53 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <f3f70d21-171e-9234-93f5-a81e27fdd278@redhat.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<f3f70d21-171e-9234-93f5-a81e27fdd278@redhat.com>
Message-ID: <CAJgngAedsfX77t8WiSsL-XHPEQjHCNyAJ=w7f+TTM+geo-5ixg@mail.gmail.com>

On 11 July 2017 at 17:05, Bill Burke <bburke at redhat.com> wrote:

> Awesome!   Comments inline
>
>
> On 7/11/17 8:29 AM, Stian Thorgersen wrote:
> > I gave it a go and implemented an "async" authentication example. It's
> > rather simple what happens is:
> >
> > * User authenticates with username only
> > * Then a "waiting" page is displayed, which is waiting for some external
> > callback. This could be an app or whatever that verifies the user then
> > sends the callback. In the example a CURL command is printed on sysout
> for
> > the server which you can run to "simulate" the callback from the app.
> > * Once the callback is received the user is authenticated without filling
> > in password or any other credentials in the main browser
> >
> > https://github.com/stianst/authenticator-example
> >
> > Check it out here:
> > https://youtu.be/C09BpNIf4v8
> >
> > It's a bit hacky in the way it's implemented:
> >
> > * Using notes for "callback" is a bit strange maybe?
> Why?
>

Dunno, was mainly checking if others thought it was OK.


>
> > * Had to use custom realm resource for callback endpoint. Is this
> strange?
> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
> > that
> So, in 7.2 it will work for cross-DC?
>

The example would need changing for KC 3.2 / 7.2 to support cross-DC. It
would need changing for authentication sessions and the callback should use
the event mechanism that Hynek implemented to update the authentication
session in the correct DC/node. Maybe Marek/Hynek could take a look at that
to make sure it works cross DC?


>
> > * No way to push change to browser, so have to pull every 2 seconds.
> Maybe
> > we could add a simple authentication event feature that uses websockets
> and
> > a small auth js lib to do the job of notification?
> You'd have to have a cross-DC notification bus for something like this
> as only one node in the cluster would have the websocket open. If you
> had Javascript that did the polling, the user wouldn't even see it.
>

I have JS polling at the moment, but I don't like it as it needs a request
every X seconds. Much better to have a way to push when it actually
changes. I don't think it would be to hard to add.


>
> Bill
>
>
> > _______________________________________________
> > 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 hmlnarik at redhat.com  Wed Jul 12 06:24:22 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 12 Jul 2017 12:24:22 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
Message-ID: <CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>

Great!

For 7.2 and on, action tokens approach is the way, and actually a
quickstart with that has been implemented [1]. Instead of an authenticator
and note manipulation that are necessary for 7.1, it employs required
actions (when action token is used, it just removes the custom required
action).

It uses somewhat similar approach to the SET but currently with a two
tokens - one created and signed by Keycloak used to reenter the
authentication flow when the app completes its flow, and the other signed
by the app to have certain chance that the response has indeed been
generated by the correct app. For details see README.md.

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

On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Really nice !
>
> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > I gave it a go and implemented an "async" authentication example. It's
> > rather simple what happens is:
> >
> > * User authenticates with username only
> > * Then a "waiting" page is displayed, which is waiting for some external
> > callback. This could be an app or whatever that verifies the user then
> > sends the callback. In the example a CURL command is printed on sysout
> for
> > the server which you can run to "simulate" the callback from the app.
> > * Once the callback is received the user is authenticated without filling
> > in password or any other credentials in the main browser
> >
>
> Maybe you can use a SET [1], which is basically a JWT, in order to
> communicate authentication events between parties. For instance, send
> additional data to the external callback about the authentication context
> and receive back from the external callback information on how to proceed
> with the authentication.
>
> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>
>
> >
> > https://github.com/stianst/authenticator-example
> >
> > Check it out here:
> > https://youtu.be/C09BpNIf4v8
> >
> > It's a bit hacky in the way it's implemented:
> >
> > * Using notes for "callback" is a bit strange maybe?
> > * Had to use custom realm resource for callback endpoint. Is this
> strange?
> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
> > that
> > * No way to push change to browser, so have to pull every 2 seconds.
> Maybe
> > we could add a simple authentication event feature that uses websockets
> and
> > a small auth js lib to do the job of notification?
> > _______________________________________________
> > 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
>



-- 

--Hynek

From sthorger at redhat.com  Wed Jul 12 06:46:55 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Jul 2017 12:46:55 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
Message-ID: <CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>

On 12 July 2017 at 12:24, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Great!
>
> For 7.2 and on, action tokens approach is the way, and actually a
> quickstart with that has been implemented [1]. Instead of an authenticator
> and note manipulation that are necessary for 7.1, it employs required
> actions (when action token is used, it just removes the custom required
> action).
>
> It uses somewhat similar approach to the SET but currently with a two
> tokens - one created and signed by Keycloak used to reenter the
> authentication flow when the app completes its flow, and the other signed
> by the app to have certain chance that the response has indeed been
> generated by the correct app. For details see README.md.
>

Action tokens may work in some situations, but may not always work. If
there is a specific protocol being used (for example BankID
https://www.bankid.com/) it may demand a certain callback format in which
case we would have to implement a custom realm resource to handle the
callback.

Hynek - could you create a fork of my example that uses action tokens?


>
> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
>
> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Really nice !
>>
>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>> > I gave it a go and implemented an "async" authentication example. It's
>> > rather simple what happens is:
>> >
>> > * User authenticates with username only
>> > * Then a "waiting" page is displayed, which is waiting for some external
>> > callback. This could be an app or whatever that verifies the user then
>> > sends the callback. In the example a CURL command is printed on sysout
>> for
>> > the server which you can run to "simulate" the callback from the app.
>> > * Once the callback is received the user is authenticated without
>> filling
>> > in password or any other credentials in the main browser
>> >
>>
>> Maybe you can use a SET [1], which is basically a JWT, in order to
>> communicate authentication events between parties. For instance, send
>> additional data to the external callback about the authentication context
>> and receive back from the external callback information on how to proceed
>> with the authentication.
>>
>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>>
>>
>> >
>> > https://github.com/stianst/authenticator-example
>> >
>> > Check it out here:
>> > https://youtu.be/C09BpNIf4v8
>> >
>> > It's a bit hacky in the way it's implemented:
>> >
>> > * Using notes for "callback" is a bit strange maybe?
>> > * Had to use custom realm resource for callback endpoint. Is this
>> strange?
>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that does
>> > that
>> > * No way to push change to browser, so have to pull every 2 seconds.
>> Maybe
>> > we could add a simple authentication event feature that uses websockets
>> and
>> > a small auth js lib to do the job of notification?
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
>
> --Hynek
>

From hmlnarik at redhat.com  Wed Jul 12 07:35:10 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 12 Jul 2017 13:35:10 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
Message-ID: <CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>

On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Action tokens may work in some situations, but may not always work. If there
> is a specific protocol being used (for example BankID
> https://www.bankid.com/) it may demand a certain callback format in which
> case we would have to implement a custom realm resource to handle the
> callback.

True - if there is a specific protocol to be used, we need to support
the protocol. This is not aim of the quickstart that illustrates
action token usage though.

The biggest difference I see between the BankID and the action token
quickstart is that for the async auth example, the realm resource code
doesn't care (and possibly does not have to for its purpose) about
authorization and validity of the request. For action token, you get
these validations for free - as action tokens are signed and have
validity timestamps, you can filter unauthorized requests without any
further logic in the handler code.

> Hynek - could you create a fork of my example that uses action tokens?

When the time permits, yes, it is rather straightforward:

* External service (in this case CURL) would be given action token URL
instead of realm resource URL.

* Logic from BankIdCallbackResource would be removed and transformed
into that of action token handler.

The rest would remain the same.

--Hynek

>> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
>>
>> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>>
>>> Really nice !
>>>
>>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>> > I gave it a go and implemented an "async" authentication example. It's
>>> > rather simple what happens is:
>>> >
>>> > * User authenticates with username only
>>> > * Then a "waiting" page is displayed, which is waiting for some
>>> > external
>>> > callback. This could be an app or whatever that verifies the user then
>>> > sends the callback. In the example a CURL command is printed on sysout
>>> > for
>>> > the server which you can run to "simulate" the callback from the app.
>>> > * Once the callback is received the user is authenticated without
>>> > filling
>>> > in password or any other credentials in the main browser
>>> >
>>>
>>> Maybe you can use a SET [1], which is basically a JWT, in order to
>>> communicate authentication events between parties. For instance, send
>>> additional data to the external callback about the authentication context
>>> and receive back from the external callback information on how to proceed
>>> with the authentication.
>>>
>>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>>>
>>>
>>> >
>>> > https://github.com/stianst/authenticator-example
>>> >
>>> > Check it out here:
>>> > https://youtu.be/C09BpNIf4v8
>>> >
>>> > It's a bit hacky in the way it's implemented:
>>> >
>>> > * Using notes for "callback" is a bit strange maybe?
>>> > * Had to use custom realm resource for callback endpoint. Is this
>>> > strange?
>>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that
>>> > does
>>> > that
>>> > * No way to push change to browser, so have to pull every 2 seconds.
>>> > Maybe
>>> > we could add a simple authentication event feature that uses websockets
>>> > and
>>> > a small auth js lib to do the job of notification?
>>> > _______________________________________________
>>> > 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
>>
>>
>>
>>
>> --
>>
>> --Hynek
>
>



-- 

--Hynek

From sthorger at redhat.com  Wed Jul 12 08:30:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Jul 2017 14:30:43 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
	<CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>
Message-ID: <CAJgngAehwn_JVnEbTPzOiB4WqrtFU_vyxvpCYYy-R-M19Kmi3Q@mail.gmail.com>

On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Action tokens may work in some situations, but may not always work. If
> there
> > is a specific protocol being used (for example BankID
> > https://www.bankid.com/) it may demand a certain callback format in
> which
> > case we would have to implement a custom realm resource to handle the
> > callback.
>
> True - if there is a specific protocol to be used, we need to support
> the protocol. This is not aim of the quickstart that illustrates
> action token usage though.
>
> The biggest difference I see between the BankID and the action token
> quickstart is that for the async auth example, the realm resource code
> doesn't care (and possibly does not have to for its purpose) about
> authorization and validity of the request. For action token, you get
> these validations for free - as action tokens are signed and have
> validity timestamps, you can filter unauthorized requests without any
> further logic in the handler code.
>
> > Hynek - could you create a fork of my example that uses action tokens?
>
> When the time permits, yes, it is rather straightforward:
>
> * External service (in this case CURL) would be given action token URL
> instead of realm resource URL.
>
> * Logic from BankIdCallbackResource would be removed and transformed
> into that of action token handler.
>
> The rest would remain the same.
>

Then there's the case that authentication session may not be available on
the node handling the callback. Does action tokens already deal with that?


>
> --Hynek
>
> >> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
> >>
> >> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com>
> >> wrote:
> >>>
> >>> Really nice !
> >>>
> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com
> >
> >>> wrote:
> >>>
> >>> > I gave it a go and implemented an "async" authentication example.
> It's
> >>> > rather simple what happens is:
> >>> >
> >>> > * User authenticates with username only
> >>> > * Then a "waiting" page is displayed, which is waiting for some
> >>> > external
> >>> > callback. This could be an app or whatever that verifies the user
> then
> >>> > sends the callback. In the example a CURL command is printed on
> sysout
> >>> > for
> >>> > the server which you can run to "simulate" the callback from the app.
> >>> > * Once the callback is received the user is authenticated without
> >>> > filling
> >>> > in password or any other credentials in the main browser
> >>> >
> >>>
> >>> Maybe you can use a SET [1], which is basically a JWT, in order to
> >>> communicate authentication events between parties. For instance, send
> >>> additional data to the external callback about the authentication
> context
> >>> and receive back from the external callback information on how to
> proceed
> >>> with the authentication.
> >>>
> >>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
> >>>
> >>>
> >>> >
> >>> > https://github.com/stianst/authenticator-example
> >>> >
> >>> > Check it out here:
> >>> > https://youtu.be/C09BpNIf4v8
> >>> >
> >>> > It's a bit hacky in the way it's implemented:
> >>> >
> >>> > * Using notes for "callback" is a bit strange maybe?
> >>> > * Had to use custom realm resource for callback endpoint. Is this
> >>> > strange?
> >>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that
> >>> > does
> >>> > that
> >>> > * No way to push change to browser, so have to pull every 2 seconds.
> >>> > Maybe
> >>> > we could add a simple authentication event feature that uses
> websockets
> >>> > and
> >>> > a small auth js lib to do the job of notification?
> >>> > _______________________________________________
> >>> > 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
> >>
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
>
>
>
> --
>
> --Hynek
>

From hmlnarik at redhat.com  Wed Jul 12 08:37:15 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 12 Jul 2017 14:37:15 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAehwn_JVnEbTPzOiB4WqrtFU_vyxvpCYYy-R-M19Kmi3Q@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
	<CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>
	<CAJgngAehwn_JVnEbTPzOiB4WqrtFU_vyxvpCYYy-R-M19Kmi3Q@mail.gmail.com>
Message-ID: <CAMvXD=FuWK+_mo05xXJ0EA1djCOXi5H9TJSPZtCz+MgaskhNhg@mail.gmail.com>

That should not change the code in any way as that is matter of
authentication session distribution within the cluster/cross DC rather
than of action tokens. AFAIK Marek is currently working on that.

On Wed, Jul 12, 2017 at 2:30 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > Action tokens may work in some situations, but may not always work. If
>> > there
>> > is a specific protocol being used (for example BankID
>> > https://www.bankid.com/) it may demand a certain callback format in
>> > which
>> > case we would have to implement a custom realm resource to handle the
>> > callback.
>>
>> True - if there is a specific protocol to be used, we need to support
>> the protocol. This is not aim of the quickstart that illustrates
>> action token usage though.
>>
>> The biggest difference I see between the BankID and the action token
>> quickstart is that for the async auth example, the realm resource code
>> doesn't care (and possibly does not have to for its purpose) about
>> authorization and validity of the request. For action token, you get
>> these validations for free - as action tokens are signed and have
>> validity timestamps, you can filter unauthorized requests without any
>> further logic in the handler code.
>>
>> > Hynek - could you create a fork of my example that uses action tokens?
>>
>> When the time permits, yes, it is rather straightforward:
>>
>> * External service (in this case CURL) would be given action token URL
>> instead of realm resource URL.
>>
>> * Logic from BankIdCallbackResource would be removed and transformed
>> into that of action token handler.
>>
>> The rest would remain the same.
>
>
> Then there's the case that authentication session may not be available on
> the node handling the callback. Does action tokens already deal with that?
>
>>
>>
>> --Hynek
>>
>> >> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
>> >>
>> >> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >>>
>> >>> Really nice !
>> >>>
>> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen
>> >>> <sthorger at redhat.com>
>> >>> wrote:
>> >>>
>> >>> > I gave it a go and implemented an "async" authentication example.
>> >>> > It's
>> >>> > rather simple what happens is:
>> >>> >
>> >>> > * User authenticates with username only
>> >>> > * Then a "waiting" page is displayed, which is waiting for some
>> >>> > external
>> >>> > callback. This could be an app or whatever that verifies the user
>> >>> > then
>> >>> > sends the callback. In the example a CURL command is printed on
>> >>> > sysout
>> >>> > for
>> >>> > the server which you can run to "simulate" the callback from the
>> >>> > app.
>> >>> > * Once the callback is received the user is authenticated without
>> >>> > filling
>> >>> > in password or any other credentials in the main browser
>> >>> >
>> >>>
>> >>> Maybe you can use a SET [1], which is basically a JWT, in order to
>> >>> communicate authentication events between parties. For instance, send
>> >>> additional data to the external callback about the authentication
>> >>> context
>> >>> and receive back from the external callback information on how to
>> >>> proceed
>> >>> with the authentication.
>> >>>
>> >>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>> >>>
>> >>>
>> >>> >
>> >>> > https://github.com/stianst/authenticator-example
>> >>> >
>> >>> > Check it out here:
>> >>> > https://youtu.be/C09BpNIf4v8
>> >>> >
>> >>> > It's a bit hacky in the way it's implemented:
>> >>> >
>> >>> > * Using notes for "callback" is a bit strange maybe?
>> >>> > * Had to use custom realm resource for callback endpoint. Is this
>> >>> > strange?
>> >>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that
>> >>> > does
>> >>> > that
>> >>> > * No way to push change to browser, so have to pull every 2 seconds.
>> >>> > Maybe
>> >>> > we could add a simple authentication event feature that uses
>> >>> > websockets
>> >>> > and
>> >>> > a small auth js lib to do the job of notification?
>> >>> > _______________________________________________
>> >>> > 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
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> --Hynek
>> >
>> >
>>
>>
>>
>> --
>>
>> --Hynek
>
>



-- 

--Hynek

From sthorger at redhat.com  Wed Jul 12 09:08:22 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Jul 2017 15:08:22 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAMvXD=FuWK+_mo05xXJ0EA1djCOXi5H9TJSPZtCz+MgaskhNhg@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
	<CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>
	<CAJgngAehwn_JVnEbTPzOiB4WqrtFU_vyxvpCYYy-R-M19Kmi3Q@mail.gmail.com>
	<CAMvXD=FuWK+_mo05xXJ0EA1djCOXi5H9TJSPZtCz+MgaskhNhg@mail.gmail.com>
Message-ID: <CAJgngAdr3=8B2VzmHeCNGZxMtppyG+1kW0fsm7xhtaBV3Ri9-g@mail.gmail.com>

The trick is that it should work even when authentication session is not
distributed. The authentication session cache could be local only and in
that case there needs to be a way to send an event from whatever node/DC
handles the callback to the node/DC that contains the authentication
session.

On 12 July 2017 at 14:37, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> That should not change the code in any way as that is matter of
> authentication session distribution within the cluster/cross DC rather
> than of action tokens. AFAIK Marek is currently working on that.
>
> On Wed, Jul 12, 2017 at 2:30 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >
> > On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> >>
> >> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at redhat.com
> >
> >> wrote:
> >> > Action tokens may work in some situations, but may not always work. If
> >> > there
> >> > is a specific protocol being used (for example BankID
> >> > https://www.bankid.com/) it may demand a certain callback format in
> >> > which
> >> > case we would have to implement a custom realm resource to handle the
> >> > callback.
> >>
> >> True - if there is a specific protocol to be used, we need to support
> >> the protocol. This is not aim of the quickstart that illustrates
> >> action token usage though.
> >>
> >> The biggest difference I see between the BankID and the action token
> >> quickstart is that for the async auth example, the realm resource code
> >> doesn't care (and possibly does not have to for its purpose) about
> >> authorization and validity of the request. For action token, you get
> >> these validations for free - as action tokens are signed and have
> >> validity timestamps, you can filter unauthorized requests without any
> >> further logic in the handler code.
> >>
> >> > Hynek - could you create a fork of my example that uses action tokens?
> >>
> >> When the time permits, yes, it is rather straightforward:
> >>
> >> * External service (in this case CURL) would be given action token URL
> >> instead of realm resource URL.
> >>
> >> * Logic from BankIdCallbackResource would be removed and transformed
> >> into that of action token handler.
> >>
> >> The rest would remain the same.
> >
> >
> > Then there's the case that authentication session may not be available on
> > the node handling the callback. Does action tokens already deal with
> that?
> >
> >>
> >>
> >> --Hynek
> >>
> >> >> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
> >> >>
> >> >> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com
> >
> >> >> wrote:
> >> >>>
> >> >>> Really nice !
> >> >>>
> >> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen
> >> >>> <sthorger at redhat.com>
> >> >>> wrote:
> >> >>>
> >> >>> > I gave it a go and implemented an "async" authentication example.
> >> >>> > It's
> >> >>> > rather simple what happens is:
> >> >>> >
> >> >>> > * User authenticates with username only
> >> >>> > * Then a "waiting" page is displayed, which is waiting for some
> >> >>> > external
> >> >>> > callback. This could be an app or whatever that verifies the user
> >> >>> > then
> >> >>> > sends the callback. In the example a CURL command is printed on
> >> >>> > sysout
> >> >>> > for
> >> >>> > the server which you can run to "simulate" the callback from the
> >> >>> > app.
> >> >>> > * Once the callback is received the user is authenticated without
> >> >>> > filling
> >> >>> > in password or any other credentials in the main browser
> >> >>> >
> >> >>>
> >> >>> Maybe you can use a SET [1], which is basically a JWT, in order to
> >> >>> communicate authentication events between parties. For instance,
> send
> >> >>> additional data to the external callback about the authentication
> >> >>> context
> >> >>> and receive back from the external callback information on how to
> >> >>> proceed
> >> >>> with the authentication.
> >> >>>
> >> >>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
> >> >>>
> >> >>>
> >> >>> >
> >> >>> > https://github.com/stianst/authenticator-example
> >> >>> >
> >> >>> > Check it out here:
> >> >>> > https://youtu.be/C09BpNIf4v8
> >> >>> >
> >> >>> > It's a bit hacky in the way it's implemented:
> >> >>> >
> >> >>> > * Using notes for "callback" is a bit strange maybe?
> >> >>> > * Had to use custom realm resource for callback endpoint. Is this
> >> >>> > strange?
> >> >>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff
> that
> >> >>> > does
> >> >>> > that
> >> >>> > * No way to push change to browser, so have to pull every 2
> seconds.
> >> >>> > Maybe
> >> >>> > we could add a simple authentication event feature that uses
> >> >>> > websockets
> >> >>> > and
> >> >>> > a small auth js lib to do the job of notification?
> >> >>> > _______________________________________________
> >> >>> > 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
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >>
> >> >> --Hynek
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >
> >
>
>
>
> --
>
> --Hynek
>

From hmlnarik at redhat.com  Wed Jul 12 09:18:35 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 12 Jul 2017 15:18:35 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAdr3=8B2VzmHeCNGZxMtppyG+1kW0fsm7xhtaBV3Ri9-g@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
	<CAMvXD=Ep95F5GbPmwZQgNS-KjBbULF4UO4UyTMQt0TLJuQ+a8g@mail.gmail.com>
	<CAJgngAehwn_JVnEbTPzOiB4WqrtFU_vyxvpCYYy-R-M19Kmi3Q@mail.gmail.com>
	<CAMvXD=FuWK+_mo05xXJ0EA1djCOXi5H9TJSPZtCz+MgaskhNhg@mail.gmail.com>
	<CAJgngAdr3=8B2VzmHeCNGZxMtppyG+1kW0fsm7xhtaBV3Ri9-g@mail.gmail.com>
Message-ID: <CAMvXD=E7y=xRdk+vhzkmmMxLuqCE2E=bxzi-k4t8bHL1Uykfkw@mail.gmail.com>

It would work regardless  - whatever mechanism would be used in realm
resource, it can just the same be used in action token handler.

If authentication session would not be distributed, the token would be
prepared to contain identification of the target node/DC but not
contain mapping to any authentication session at all. The action token
handler would use information from the token to send an event that
would reach the right node/DC.

On Wed, Jul 12, 2017 at 3:08 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> The trick is that it should work even when authentication session is not
> distributed. The authentication session cache could be local only and in
> that case there needs to be a way to send an event from whatever node/DC
> handles the callback to the node/DC that contains the authentication
> session.
>
> On 12 July 2017 at 14:37, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> That should not change the code in any way as that is matter of
>> authentication session distribution within the cluster/cross DC rather
>> than of action tokens. AFAIK Marek is currently working on that.
>>
>> On Wed, Jul 12, 2017 at 2:30 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> >
>> > On 12 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>> >>
>> >> On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen
>> >> <sthorger at redhat.com>
>> >> wrote:
>> >> > Action tokens may work in some situations, but may not always work.
>> >> > If
>> >> > there
>> >> > is a specific protocol being used (for example BankID
>> >> > https://www.bankid.com/) it may demand a certain callback format in
>> >> > which
>> >> > case we would have to implement a custom realm resource to handle the
>> >> > callback.
>> >>
>> >> True - if there is a specific protocol to be used, we need to support
>> >> the protocol. This is not aim of the quickstart that illustrates
>> >> action token usage though.
>> >>
>> >> The biggest difference I see between the BankID and the action token
>> >> quickstart is that for the async auth example, the realm resource code
>> >> doesn't care (and possibly does not have to for its purpose) about
>> >> authorization and validity of the request. For action token, you get
>> >> these validations for free - as action tokens are signed and have
>> >> validity timestamps, you can filter unauthorized requests without any
>> >> further logic in the handler code.
>> >>
>> >> > Hynek - could you create a fork of my example that uses action
>> >> > tokens?
>> >>
>> >> When the time permits, yes, it is rather straightforward:
>> >>
>> >> * External service (in this case CURL) would be given action token URL
>> >> instead of realm resource URL.
>> >>
>> >> * Logic from BankIdCallbackResource would be removed and transformed
>> >> into that of action token handler.
>> >>
>> >> The rest would remain the same.
>> >
>> >
>> > Then there's the case that authentication session may not be available
>> > on
>> > the node handling the callback. Does action tokens already deal with
>> > that?
>> >
>> >>
>> >>
>> >> --Hynek
>> >>
>> >> >> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
>> >> >>
>> >> >> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva
>> >> >> <psilva at redhat.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Really nice !
>> >> >>>
>> >> >>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen
>> >> >>> <sthorger at redhat.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>> > I gave it a go and implemented an "async" authentication example.
>> >> >>> > It's
>> >> >>> > rather simple what happens is:
>> >> >>> >
>> >> >>> > * User authenticates with username only
>> >> >>> > * Then a "waiting" page is displayed, which is waiting for some
>> >> >>> > external
>> >> >>> > callback. This could be an app or whatever that verifies the user
>> >> >>> > then
>> >> >>> > sends the callback. In the example a CURL command is printed on
>> >> >>> > sysout
>> >> >>> > for
>> >> >>> > the server which you can run to "simulate" the callback from the
>> >> >>> > app.
>> >> >>> > * Once the callback is received the user is authenticated without
>> >> >>> > filling
>> >> >>> > in password or any other credentials in the main browser
>> >> >>> >
>> >> >>>
>> >> >>> Maybe you can use a SET [1], which is basically a JWT, in order to
>> >> >>> communicate authentication events between parties. For instance,
>> >> >>> send
>> >> >>> additional data to the external callback about the authentication
>> >> >>> context
>> >> >>> and receive back from the external callback information on how to
>> >> >>> proceed
>> >> >>> with the authentication.
>> >> >>>
>> >> >>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>> >> >>>
>> >> >>>
>> >> >>> >
>> >> >>> > https://github.com/stianst/authenticator-example
>> >> >>> >
>> >> >>> > Check it out here:
>> >> >>> > https://youtu.be/C09BpNIf4v8
>> >> >>> >
>> >> >>> > It's a bit hacky in the way it's implemented:
>> >> >>> >
>> >> >>> > * Using notes for "callback" is a bit strange maybe?
>> >> >>> > * Had to use custom realm resource for callback endpoint. Is this
>> >> >>> > strange?
>> >> >>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff
>> >> >>> > that
>> >> >>> > does
>> >> >>> > that
>> >> >>> > * No way to push change to browser, so have to pull every 2
>> >> >>> > seconds.
>> >> >>> > Maybe
>> >> >>> > we could add a simple authentication event feature that uses
>> >> >>> > websockets
>> >> >>> > and
>> >> >>> > a small auth js lib to do the job of notification?
>> >> >>> > _______________________________________________
>> >> >>> > 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
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >>
>> >> >> --Hynek
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >>
>> >> --Hynek
>> >
>> >
>>
>>
>>
>> --
>>
>> --Hynek
>
>



-- 

--Hynek

From mposolda at redhat.com  Wed Jul 12 11:14:33 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 12 Jul 2017 17:14:33 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
Message-ID: <076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>

I guess that logging for keycloak server was disabled because of big 
Travis and Jenkins logs? AFAIK it was always disabled in 
testsuite-arquillian from day 1. Due to this, I was thinking that 
enabling the logging in maven is just not an option, so I've added this 
listener just to ensure that logging is enabled in IDE.

Marek


On 12/07/17 08:58, Stian Thorgersen wrote:
> What's the point of this? I don't see why we would want to disable Keycloak
> server logging when running from Maven?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From adobbels at bottomline.com  Wed Jul 12 12:24:24 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Wed, 12 Jul 2017 16:24:24 +0000
Subject: [keycloak-dev] OTP string based secrets
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA01B7@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi,

We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

2 questions:
1: Is the lower entropy of the secrets generated by Keycloak a concern?
2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.

Thanks,

Andy



From adobbels at bottomline.com  Wed Jul 12 13:39:41 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Wed, 12 Jul 2017 17:39:41 +0000
Subject: [keycloak-dev] OTP string based secrets
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi,

We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

2 questions:
1: Is the lower entropy of the secrets generated by Keycloak a concern?
2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.

Thanks,

Andy



From bburke at redhat.com  Wed Jul 12 18:16:15 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 12 Jul 2017 18:16:15 -0400
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
Message-ID: <0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>



On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> Hi,
>
> We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

> 2 questions:
> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
Should it be a concern?  Its currently a randomly generated 20 character 
alpha-numeric string.  That's not enough entropy?


> 2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
> This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.
We have undocumented SPIs to support other storage options for different 
credential types.  If you want to use the data model that's currently 
there you have to encode your secrets as strings. We're limited in the 
fact that our current OTP storage must be backward compatible.  Also, 
don't want to have to recalculate storage for every single OTP record of 
existing deployments when migrating.

We could though absolutely change how future secrets are generated if 
you feel the entropy is a concern.

Bill

From sthorger at redhat.com  Thu Jul 13 01:07:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Jul 2017 07:07:35 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
	<076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
Message-ID: <CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>

I remember we talked about this, but not the details. I suspect it was
disabled just by mistake. Jenkins primarily uses auth-server-wildfly and
this won't have any effect there as it'll all be controlled through
standalone.xml and use default logging there.

On 12 July 2017 at 17:14, Marek Posolda <mposolda at redhat.com> wrote:

> I guess that logging for keycloak server was disabled because of big
> Travis and Jenkins logs? AFAIK it was always disabled in
> testsuite-arquillian from day 1. Due to this, I was thinking that enabling
> the logging in maven is just not an option, so I've added this listener
> just to ensure that logging is enabled in IDE.
>
> Marek
>
>
> On 12/07/17 08:58, Stian Thorgersen wrote:
>
>> What's the point of this? I don't see why we would want to disable
>> Keycloak
>> server logging when running from Maven?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From mposolda at redhat.com  Thu Jul 13 02:47:41 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 13 Jul 2017 08:47:41 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
	<076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
	<CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>
Message-ID: <d5147be7-b402-afbe-2f2b-c833889320ac@redhat.com>

I guess it wasn't mistake. Lots of our tests produces big exception 
stacktraces and tests have very big logs. But maybe it won't be so bad 
now as travis build is divided into multiple parts and the limit is 
separate for each part? Maybe we can try to enable it and see how big 
logs are and if travis is still ok?

But another thing I was thinking was to increase webDriver timeout to 1 
hour when running from IDE. Currently it's 10 seconds. But I am 
personally usually want to debug server or adapter when I am running 
tests from IDE and I am continuously overriding the system property to 
increase timeout. I suspect that people usually run test from IDE when 
they develop new test or debug existing test, so having bigger timeout 
makes sense?

Marek


On 13/07/17 07:07, Stian Thorgersen wrote:
> I remember we talked about this, but not the details. I suspect it was 
> disabled just by mistake. Jenkins primarily uses auth-server-wildfly 
> and this won't have any effect there as it'll all be controlled 
> through standalone.xml and use default logging there.
>
> On 12 July 2017 at 17:14, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I guess that logging for keycloak server was disabled because of
>     big Travis and Jenkins logs? AFAIK it was always disabled in
>     testsuite-arquillian from day 1. Due to this, I was thinking that
>     enabling the logging in maven is just not an option, so I've added
>     this listener just to ensure that logging is enabled in IDE.
>
>     Marek
>
>
>     On 12/07/17 08:58, Stian Thorgersen wrote:
>
>         What's the point of this? I don't see why we would want to
>         disable Keycloak
>         server logging when running from Maven?
>         _______________________________________________
>         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
>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>


From sthorger at redhat.com  Thu Jul 13 06:54:55 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Jul 2017 12:54:55 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <d5147be7-b402-afbe-2f2b-c833889320ac@redhat.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
	<076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
	<CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>
	<d5147be7-b402-afbe-2f2b-c833889320ac@redhat.com>
Message-ID: <CAJgngAdwRLsyVcFZHpTzPzamwix6nYfZMW7r7-R-cNTm5T9pGg@mail.gmail.com>

I'm working on enabling auth-server-wildfly on Travis. First issue was
amount of logs being generated. I sorted that out by creating a
"LogTrimmer" util. It'll discard output generated during a successful test
run and only print log output generated for a failed test run:

https://github.com/stianst/keycloak/tree/TRAVIS3

Looks like it's working well on Travis:
https://travis-ci.org/stianst/keycloak/branches

TRAVIS3 shows successful runs, TRAVIS-FAULTS shows what happens when there
are failures (I broke a bunch of tests in this branch).

On 13 July 2017 at 08:47, Marek Posolda <mposolda at redhat.com> wrote:

> I guess it wasn't mistake. Lots of our tests produces big exception
> stacktraces and tests have very big logs. But maybe it won't be so bad now
> as travis build is divided into multiple parts and the limit is separate
> for each part? Maybe we can try to enable it and see how big logs are and
> if travis is still ok?
>
> But another thing I was thinking was to increase webDriver timeout to 1
> hour when running from IDE. Currently it's 10 seconds. But I am personally
> usually want to debug server or adapter when I am running tests from IDE
> and I am continuously overriding the system property to increase timeout. I
> suspect that people usually run test from IDE when they develop new test or
> debug existing test, so having bigger timeout makes sense?
>
> Marek
>
>
> On 13/07/17 07:07, Stian Thorgersen wrote:
>
> I remember we talked about this, but not the details. I suspect it was
> disabled just by mistake. Jenkins primarily uses auth-server-wildfly and
> this won't have any effect there as it'll all be controlled through
> standalone.xml and use default logging there.
>
> On 12 July 2017 at 17:14, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I guess that logging for keycloak server was disabled because of big
>> Travis and Jenkins logs? AFAIK it was always disabled in
>> testsuite-arquillian from day 1. Due to this, I was thinking that enabling
>> the logging in maven is just not an option, so I've added this listener
>> just to ensure that logging is enabled in IDE.
>>
>> Marek
>>
>>
>> On 12/07/17 08:58, Stian Thorgersen wrote:
>>
>>> What's the point of this? I don't see why we would want to disable
>>> Keycloak
>>> server logging when running from Maven?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>

From hmlnarik at redhat.com  Thu Jul 13 07:35:23 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 13 Jul 2017 13:35:23 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <CAJgngAdwRLsyVcFZHpTzPzamwix6nYfZMW7r7-R-cNTm5T9pGg@mail.gmail.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
	<076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
	<CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>
	<d5147be7-b402-afbe-2f2b-c833889320ac@redhat.com>
	<CAJgngAdwRLsyVcFZHpTzPzamwix6nYfZMW7r7-R-cNTm5T9pGg@mail.gmail.com>
Message-ID: <CAMvXD=GPE4LNOX2BahVL9w7AJjR=01j6DxoYrPPZjpFvNWzSUQ@mail.gmail.com>

That would be very helpful.

Out of curiosity - why is cache disabled in the new version? [1] Is it
just for development?

--Hynek

[1] https://github.com/keycloak/keycloak/compare/master...stianst:TRAVIS3?expand=1#diff-354f30a63fb0907d4ad57269548329e3R4

On Thu, Jul 13, 2017 at 12:54 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I'm working on enabling auth-server-wildfly on Travis. First issue was
> amount of logs being generated. I sorted that out by creating a
> "LogTrimmer" util. It'll discard output generated during a successful test
> run and only print log output generated for a failed test run:
>
> https://github.com/stianst/keycloak/tree/TRAVIS3
>
> Looks like it's working well on Travis:
> https://travis-ci.org/stianst/keycloak/branches
>
> TRAVIS3 shows successful runs, TRAVIS-FAULTS shows what happens when there
> are failures (I broke a bunch of tests in this branch).
>
> On 13 July 2017 at 08:47, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I guess it wasn't mistake. Lots of our tests produces big exception
>> stacktraces and tests have very big logs. But maybe it won't be so bad now
>> as travis build is divided into multiple parts and the limit is separate
>> for each part? Maybe we can try to enable it and see how big logs are and
>> if travis is still ok?
>>
>> But another thing I was thinking was to increase webDriver timeout to 1
>> hour when running from IDE. Currently it's 10 seconds. But I am personally
>> usually want to debug server or adapter when I am running tests from IDE
>> and I am continuously overriding the system property to increase timeout. I
>> suspect that people usually run test from IDE when they develop new test or
>> debug existing test, so having bigger timeout makes sense?
>>
>> Marek
>>
>>
>> On 13/07/17 07:07, Stian Thorgersen wrote:
>>
>> I remember we talked about this, but not the details. I suspect it was
>> disabled just by mistake. Jenkins primarily uses auth-server-wildfly and
>> this won't have any effect there as it'll all be controlled through
>> standalone.xml and use default logging there.
>>
>> On 12 July 2017 at 17:14, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> I guess that logging for keycloak server was disabled because of big
>>> Travis and Jenkins logs? AFAIK it was always disabled in
>>> testsuite-arquillian from day 1. Due to this, I was thinking that enabling
>>> the logging in maven is just not an option, so I've added this listener
>>> just to ensure that logging is enabled in IDE.
>>>
>>> Marek
>>>
>>>
>>> On 12/07/17 08:58, Stian Thorgersen wrote:
>>>
>>>> What's the point of this? I don't see why we would want to disable
>>>> Keycloak
>>>> server logging when running from Maven?
>>>> _______________________________________________
>>>> 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



-- 

--Hynek

From sthorger at redhat.com  Thu Jul 13 07:48:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Jul 2017 13:48:36 +0200
Subject: [keycloak-dev] NonIDERunListener
In-Reply-To: <CAMvXD=GPE4LNOX2BahVL9w7AJjR=01j6DxoYrPPZjpFvNWzSUQ@mail.gmail.com>
References: <CAJgngAdRt+EQiovLyS-D76g239sxtUdBH8zsLvhN1B=-FJoLKg@mail.gmail.com>
	<076729a7-33a8-fef4-cccb-86db3790d5cc@redhat.com>
	<CAJgngAcuVFEU8A8v7bAPwHjkEDz+x_04QPcuUCTbR5xBPscf_w@mail.gmail.com>
	<d5147be7-b402-afbe-2f2b-c833889320ac@redhat.com>
	<CAJgngAdwRLsyVcFZHpTzPzamwix6nYfZMW7r7-R-cNTm5T9pGg@mail.gmail.com>
	<CAMvXD=GPE4LNOX2BahVL9w7AJjR=01j6DxoYrPPZjpFvNWzSUQ@mail.gmail.com>
Message-ID: <CAJgngAfrDqStQO9wBJKi3JRRTY+FfCTFSsOJMJRg-yTG=CasGg@mail.gmail.com>

Cache is disabled because it didn't work properly. It builds fast without
it (not sure how, but it seems to dl mvn artifacts in record time!).

On 13 July 2017 at 13:35, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> That would be very helpful.
>
> Out of curiosity - why is cache disabled in the new version? [1] Is it
> just for development?
>
> --Hynek
>
> [1] https://github.com/keycloak/keycloak/compare/master...
> stianst:TRAVIS3?expand=1#diff-354f30a63fb0907d4ad57269548329e3R4
>
> On Thu, Jul 13, 2017 at 12:54 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I'm working on enabling auth-server-wildfly on Travis. First issue was
> > amount of logs being generated. I sorted that out by creating a
> > "LogTrimmer" util. It'll discard output generated during a successful
> test
> > run and only print log output generated for a failed test run:
> >
> > https://github.com/stianst/keycloak/tree/TRAVIS3
> >
> > Looks like it's working well on Travis:
> > https://travis-ci.org/stianst/keycloak/branches
> >
> > TRAVIS3 shows successful runs, TRAVIS-FAULTS shows what happens when
> there
> > are failures (I broke a bunch of tests in this branch).
> >
> > On 13 July 2017 at 08:47, Marek Posolda <mposolda at redhat.com> wrote:
> >
> >> I guess it wasn't mistake. Lots of our tests produces big exception
> >> stacktraces and tests have very big logs. But maybe it won't be so bad
> now
> >> as travis build is divided into multiple parts and the limit is separate
> >> for each part? Maybe we can try to enable it and see how big logs are
> and
> >> if travis is still ok?
> >>
> >> But another thing I was thinking was to increase webDriver timeout to 1
> >> hour when running from IDE. Currently it's 10 seconds. But I am
> personally
> >> usually want to debug server or adapter when I am running tests from IDE
> >> and I am continuously overriding the system property to increase
> timeout. I
> >> suspect that people usually run test from IDE when they develop new
> test or
> >> debug existing test, so having bigger timeout makes sense?
> >>
> >> Marek
> >>
> >>
> >> On 13/07/17 07:07, Stian Thorgersen wrote:
> >>
> >> I remember we talked about this, but not the details. I suspect it was
> >> disabled just by mistake. Jenkins primarily uses auth-server-wildfly and
> >> this won't have any effect there as it'll all be controlled through
> >> standalone.xml and use default logging there.
> >>
> >> On 12 July 2017 at 17:14, Marek Posolda <mposolda at redhat.com> wrote:
> >>
> >>> I guess that logging for keycloak server was disabled because of big
> >>> Travis and Jenkins logs? AFAIK it was always disabled in
> >>> testsuite-arquillian from day 1. Due to this, I was thinking that
> enabling
> >>> the logging in maven is just not an option, so I've added this listener
> >>> just to ensure that logging is enabled in IDE.
> >>>
> >>> Marek
> >>>
> >>>
> >>> On 12/07/17 08:58, Stian Thorgersen wrote:
> >>>
> >>>> What's the point of this? I don't see why we would want to disable
> >>>> Keycloak
> >>>> server logging when running from Maven?
> >>>> _______________________________________________
> >>>> 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
>
>
>
> --
>
> --Hynek
>

From wim.vandenhaute at gmail.com  Thu Jul 13 07:54:41 2017
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Thu, 13 Jul 2017 11:54:41 +0000
Subject: [keycloak-dev] Test suite keycloak server port configuration
Message-ID: <CAAmmoOozmyFP3gUk0HsWCR-RRO8Getv6hu5GNuXrY5oabTcLjg@mail.gmail.com>

Hey list,

For a customer of mine, I submitted a few PR's and now have to dig into a
changed behavior on one of the keycloak integration tests.

Sadly enough, on the dev machine I am working on @ my customer's site, the
port 8081 is in use by a McAfee service program which I cannot kill.

Hence my question, would it be acceptable if I made a PR with an effort to
make 8081 ( and I think 8082 also ) configurable via e.g. a maven property
so I can override this when running the tests from that dev machine?
Is an effort planned for this?

Just so I do not waste too much time on this one :)

From sthorger at redhat.com  Thu Jul 13 07:59:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Jul 2017 13:59:35 +0200
Subject: [keycloak-dev] Switching to auth-server-wildfly on Travis
Message-ID: <CAJgngAd=zroe0S=j-u79OSO14oVM8Au7-JNF-WG-hk4Hmd7s0g@mail.gmail.com>

We've tried using auth-server-wildfly on Travis in the past, but the
problem has been there's been to much logs generated (Travis kills the job
after the log file reaches 4mb). Currently it uses the embedded Undertow
which drops all org.keycloak logs which is not good either.

I came up with a simple solution which is a small Java app that the output
is piped into. For each test that is running it buffers the logs. If the
test passes the logs generated during the test are dropped, but if there is
a failure it will output the logs. Log output is also prefixed with the
name of the tests so it's easy to see what output is related to the test.

PR is here:
https://github.com/keycloak/keycloak/pull/4317

Log output when there's no failures can be seen here:
https://travis-ci.org/stianst/keycloak/jobs/252434708

And when there is failures here:
https://travis-ci.org/stianst/keycloak/jobs/252434756

From sthorger at redhat.com  Thu Jul 13 08:43:21 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Jul 2017 14:43:21 +0200
Subject: [keycloak-dev] Test suite keycloak server port configuration
In-Reply-To: <CAAmmoOozmyFP3gUk0HsWCR-RRO8Getv6hu5GNuXrY5oabTcLjg@mail.gmail.com>
References: <CAAmmoOozmyFP3gUk0HsWCR-RRO8Getv6hu5GNuXrY5oabTcLjg@mail.gmail.com>
Message-ID: <CAJgngAdAWOP37JGbcT9_hTrzpdHtOhZJ=YVuXv4Kp5F33Q-4xQ@mail.gmail.com>

Sure. A couple points:

* integration is being deprecated and we wouldn't accept any updates to that
* integration-arquillian is what you want to focus on. There's already a
simple way to set the port through the arquillian.xml and should be easy to
add a sys prop there. One remaining thing is that a lot of tests just
assumes it to run on localhost:8081 instead of pulling the URL properly
from the suitecontext so you'd need to go through quite a lot of tests to
make it work properly

On 13 July 2017 at 13:54, Wim Vandenhaute <wim.vandenhaute at gmail.com> wrote:

> Hey list,
>
> For a customer of mine, I submitted a few PR's and now have to dig into a
> changed behavior on one of the keycloak integration tests.
>
> Sadly enough, on the dev machine I am working on @ my customer's site, the
> port 8081 is in use by a McAfee service program which I cannot kill.
>
> Hence my question, would it be acceptable if I made a PR with an effort to
> make 8081 ( and I think 8082 also ) configurable via e.g. a maven property
> so I can override this when running the tests from that dev machine?
> Is an effort planned for this?
>
> Just so I do not waste too much time on this one :)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From wim.vandenhaute at gmail.com  Thu Jul 13 10:06:08 2017
From: wim.vandenhaute at gmail.com (Wim Vandenhaute)
Date: Thu, 13 Jul 2017 14:06:08 +0000
Subject: [keycloak-dev] Test suite keycloak server port configuration
In-Reply-To: <CAJgngAdAWOP37JGbcT9_hTrzpdHtOhZJ=YVuXv4Kp5F33Q-4xQ@mail.gmail.com>
References: <CAAmmoOozmyFP3gUk0HsWCR-RRO8Getv6hu5GNuXrY5oabTcLjg@mail.gmail.com>
	<CAJgngAdAWOP37JGbcT9_hTrzpdHtOhZJ=YVuXv4Kp5F33Q-4xQ@mail.gmail.com>
Message-ID: <CAAmmoOqbXTknn_rzza9enh3hRFPa7d7karQmVShwxi6WjKdvPg@mail.gmail.com>

Ok thanks, I'll see if I can find/get some time to do this.
Alternatively I'll just do them from my own device.


On Thu, Jul 13, 2017 at 2:43 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Sure. A couple points:
>
> * integration is being deprecated and we wouldn't accept any updates to
> that
> * integration-arquillian is what you want to focus on. There's already a
> simple way to set the port through the arquillian.xml and should be easy to
> add a sys prop there. One remaining thing is that a lot of tests just
> assumes it to run on localhost:8081 instead of pulling the URL properly
> from the suitecontext so you'd need to go through quite a lot of tests to
> make it work properly
>
> On 13 July 2017 at 13:54, Wim Vandenhaute <wim.vandenhaute at gmail.com>
> wrote:
>
>> Hey list,
>>
>> For a customer of mine, I submitted a few PR's and now have to dig into a
>> changed behavior on one of the keycloak integration tests.
>>
>> Sadly enough, on the dev machine I am working on @ my customer's site, the
>> port 8081 is in use by a McAfee service program which I cannot kill.
>>
>> Hence my question, would it be acceptable if I made a PR with an effort to
>> make 8081 ( and I think 8082 also ) configurable via e.g. a maven property
>> so I can override this when running the tests from that dev machine?
>> Is an effort planned for this?
>>
>> Just so I do not waste too much time on this one :)
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From bart.toersche at simacan.com  Thu Jul 13 10:44:57 2017
From: bart.toersche at simacan.com (Bart Toersche)
Date: Thu, 13 Jul 2017 16:44:57 +0200
Subject: [keycloak-dev] Welcome to the "keycloak-dev" mailing list
In-Reply-To: <mailman.0.1499955422.1143.keycloak-dev@lists.jboss.org>
References: <mailman.0.1499955422.1143.keycloak-dev@lists.jboss.org>
Message-ID: <CAHorjSnY_chJVkE8cKGxbZd5NZkO_p8y4QTYNgxyshi+Kr7Wtw@mail.gmail.com>

Hi,

I would like to report some unexpected behavior while requesting access-
and refresh token pairs. It is possible to obtain a new access- and refresh
token pair using only an access token. To describe this more thoroughly; If
someone obtained a valid access token s/he can obtain a new access- and
refresh token pair without ever knowing the refresh token.

The problem is that refresh tokens never leave the client except when
requesting a new one at the authorization server. However, the access token
is sent to resource servers for obtaining resources (obviously). But now a
resource server is actually able to obtain a new access- and refresh token
pair on behalf of the user as well, which was never the user's intention
(since it can keep a valid token indefinitely by refreshing it).
Of course, since the resource server doesn't have client credentials for
private clients it cannot obtain a new access- and refresh token pair for
those. However, it can do so for public clients as only their name is
known. (In fact, it is available in the "azp" claim of the access token.)

Steps to reproduce (I tested this with a clean setup of Keycloak
3.2.0-Final):
1. We will use the admin-cli client and the admin account. You can do this
with any client and account, but since this is already set up for this
particular example, it makes things a bit more easy.
2. Using the admin account, fetch a new access- and refresh token pair
using any grant type. We will be using the password grant:
    curl --data
"client_id=admin-cli&grant_type=password&username=<admin_uname>&password=<admin_pw>"
http://localhost:8080/auth/realms/master/protocol/openid-connect/token
3. Grab the access_token value from the response and perform a refresh
grant using this access token:
    curl --data
"client_id=admin-cli&grant_type=refresh_token&refresh_token=<grabbed_access_token>"
http://localhost:8080/auth/realms/master/protocol/openid-connect/token
4. You will now have a response including a new access- and refresh token
pair.

This unexpected behavior can be solved by either checking the "typ" claim
to be set to "Refresh", or, when time allows, using a different signing
secret for the access- and refresh tokens. I would prefer the latter
solution.

Thanks in advance,
Bart Toersche

From adobbels at bottomline.com  Thu Jul 13 11:17:09 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Thu, 13 Jul 2017 15:17:09 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi Bill,

Thanks for the response and sorry for the double post. 

My main concern is interoperability and not being able to import the secrets from existing OTP solutions even though they are all based on the same RFC. Creating an SPI to allow the secret to be stored as a Base32 string instead of plain text doesn't seem right. The rest of the code is fine and it's all there. If you don't mind I would like to explore a few options that don't require an update of all existing credentials.

1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"  That way we can keep the existing data as is. If the prefix isn't there then it's plain text.
or
2: Add a column that indicates what format the credentials.value property is encoded in. Values could be Plain or Base32. Someone could easily add Base64 or Hex if that helps their adoption/migration of otp. Perhaps later on this could open the door to encrypting the secret by having a value called "encrypted".

Perhaps there are other options?
Is the undocumented SPI purely dealing with how the value is encoded?

Thanks,

Andy


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 12 July 2017 23:16
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets



On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> Hi,
>
> We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

> 2 questions:
> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
Should it be a concern?  Its currently a randomly generated 20 character alpha-numeric string.  That's not enough entropy?


> 2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
> This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.
We have undocumented SPIs to support other storage options for different 
credential types.  If you want to use the data model that's currently 
there you have to encode your secrets as strings. We're limited in the 
fact that our current OTP storage must be backward compatible.  Also, 
don't want to have to recalculate storage for every single OTP record of 
existing deployments when migrating.

We could though absolutely change how future secrets are generated if 
you feel the entropy is a concern.

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


From sthorger at redhat.com  Fri Jul 14 00:14:46 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 14 Jul 2017 06:14:46 +0200
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
Message-ID: <CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>

The OTP strings we have today are already encoded with Base32 as the OTP
specs mandates [1] so I don't really understand what this whole thread is
about.

[1]
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java

On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:

> Hi Bill,
>
> Thanks for the response and sorry for the double post.
>
> My main concern is interoperability and not being able to import the
> secrets from existing OTP solutions even though they are all based on the
> same RFC. Creating an SPI to allow the secret to be stored as a Base32
> string instead of plain text doesn't seem right. The rest of the code is
> fine and it's all there. If you don't mind I would like to explore a few
> options that don't require an update of all existing credentials.
>
> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
> That way we can keep the existing data as is. If the prefix isn't there
> then it's plain text.
> or
> 2: Add a column that indicates what format the credentials.value property
> is encoded in. Values could be Plain or Base32. Someone could easily add
> Base64 or Hex if that helps their adoption/migration of otp. Perhaps later
> on this could open the door to encrypting the secret by having a value
> called "encrypted".
>
> Perhaps there are other options?
> Is the undocumented SPI purely dealing with how the value is encoded?
>
> Thanks,
>
> Andy
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Bill Burke
> Sent: 12 July 2017 23:16
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
>
>
> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> > Hi,
> >
> > We are adopting Keycloak and are trying to move our OTP tokens over to
> Keycloak. However, Keycloak can only use secrets that are alphanumeric
> strings whereas our existing implementation and most hard and software
> tokens we have used use the full range of binary values when generating
> secrets.
>
> > 2 questions:
> > 1: Is the lower entropy of the secrets generated by Keycloak a concern?
> Should it be a concern?  Its currently a randomly generated 20 character
> alpha-numeric string.  That's not enough entropy?
>
>
> > 2: If we provided a PR that migrated the existing data by re-encoding
> all existing secrets as Base32 and updated the code to assume Base32
> instead of string be acceptable?
> > This would be a non breaking change but allow anyone using existing OTP
> tokens to migrate their secrets which I don't think they can at the moment.
> We have undocumented SPIs to support other storage options for different
> credential types.  If you want to use the data model that's currently
> there you have to encode your secrets as strings. We're limited in the
> fact that our current OTP storage must be backward compatible.  Also,
> don't want to have to recalculate storage for every single OTP record of
> existing deployments when migrating.
>
> We could though absolutely change how future secrets are generated if
> you feel the entropy is a concern.
>
> Bill
> _______________________________________________
> 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 adobbels at bottomline.com  Fri Jul 14 06:13:35 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Fri, 14 Jul 2017 10:13:35 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA0A69@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi Stian,

In short: Keycloak uses the system's default character set (typically UTF8) to convert the secret to and from binary/string. This prevents people from moving existing token secrets into Keycloak.
See https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java#L37 getBytes() call.

Longer version:
Keycloak:
Secret generation: New secret = Random alphanumeric String(20)
Secret storage: varchar(4000) (in MS Sql Server) 
Conversion of Value column to binary for use in TOTP algo:  totpSecret.getBytes() which takes a string and gets the binary representation of that string using the default string encoding
Conversion of totpSecret to Base32 for consumption by end user: Base32.encode(binary totpSecret)

Most other TOTP implementations:
Secret generation: New secret = Random array of bytes.
Secret storage: Base32/Base64/HEX varchar or just a binary blob (some might also encrypt the value in the db before storing)
Conversion of Value column to binary totpSecret:  Base32/Base64/Hex decode or nothing if it's already stored as binary.
Conversion of totpSecret to Base32 for consumption by end user: Base32.encode(totpSecret)

The problem is that you cannot migrate any of your typical secrets into Keycloak as your random array of bytes cannot be reliably stored as a string as they cannot be reliably converted  because of low asci/UTF8 values or special UTF8 encodings.

It's about the storage and Keycloak relying on string encoding for conversion to binary and not about the presentation to the user (which I think you're referring to). If keycloak treated the secret as an array of bytes and stored it as BaseXX then there would be no problem at all.

My suggestions below were to allow a migration to a better way of storing secrets while not breaking existing implementations. This relies on detecting how the secret is encoded. The default is whatever the current system's default character set is.

Another way other than the 2 suggestions below to detect that the secret is stored as Base32 would be to check the length of the strings. Current length is 20, the equivalent Base32  would be 33. However, this might be deemed to be too obscure and fail if someone imports a shorter secret that ends up as length 20 as well. Perhaps it should be a configuration option that allows users to specify what encoding is used for the secret. UTF8 (default), Base32/64 or Hex.

I hope that clears up the problem.

Thanks,

Andy

From: Stian Thorgersen [mailto:sthorger at redhat.com] 
Sent: 14 July 2017 05:15
To: Dobbels, Andy
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

The OTP strings we have today are already encoded with Base32 as the OTP specs mandates [1] so I don't really understand what this whole thread is about.

[1]?https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java

On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
Hi Bill,

Thanks for the response and sorry for the double post.

My main concern is interoperability and not being able to import the secrets from existing OTP solutions even though they are all based on the same RFC. Creating an SPI to allow the secret to be stored as a Base32 string instead of plain text doesn't seem right. The rest of the code is fine and it's all there. If you don't mind I would like to explore a few options that don't require an update of all existing credentials.

1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"? That way we can keep the existing data as is. If the prefix isn't there then it's plain text.
or
2: Add a column that indicates what format the credentials.value property is encoded in. Values could be Plain or Base32. Someone could easily add Base64 or Hex if that helps their adoption/migration of otp. Perhaps later on this could open the door to encrypting the secret by having a value called "encrypted".

Perhaps there are other options?
Is the undocumented SPI purely dealing with how the value is encoded?

Thanks,

Andy


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 12 July 2017 23:16
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets



On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> Hi,
>
> We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

> 2 questions:
> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
Should it be a concern?? Its currently a randomly generated 20 character alpha-numeric string.? That's not enough entropy?


> 2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
> This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.
We have undocumented SPIs to support other storage options for different
credential types.? If you want to use the data model that's currently
there you have to encode your secrets as strings. We're limited in the
fact that our current OTP storage must be backward compatible.? Also,
don't want to have to recalculate storage for every single OTP record of
existing deployments when migrating.

We could though absolutely change how future secrets are generated if
you feel the entropy is a concern.

Bill
_______________________________________________
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  Fri Jul 14 07:55:27 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 14 Jul 2017 13:55:27 +0200
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <B36F75FE9807FF41BC172237E5DA720F66AA0A69@US02VWMX0001.us-bottomline.root.bottomline.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA0A69@US02VWMX0001.us-bottomline.root.bottomline.com>
Message-ID: <CAJgngAf_yiU_4ev6YzKU3k1LrbSq6BmCeNfG-VzPUK2Sswk75w@mail.gmail.com>

Thanks for the recap. OK, I can see the problem. This is somewhat related
to the fact that we don't currently store the OTP policy alongside a users
OTP credentials. This is an issue if the OTP policy for a realm changes
which could render all current OTP setups useless.

On 14 July 2017 at 12:13, Dobbels, Andy <adobbels at bottomline.com> wrote:

> Hi Stian,
>
> In short: Keycloak uses the system's default character set (typically
> UTF8) to convert the secret to and from binary/string. This prevents people
> from moving existing token secrets into Keycloak.
> See https://github.com/keycloak/keycloak/blob/master/services/
> src/main/java/org/keycloak/utils/TotpUtils.java#L37 getBytes() call.
>
> Longer version:
> Keycloak:
> Secret generation: New secret = Random alphanumeric String(20)
> Secret storage: varchar(4000) (in MS Sql Server)
> Conversion of Value column to binary for use in TOTP algo:
> totpSecret.getBytes() which takes a string and gets the binary
> representation of that string using the default string encoding
> Conversion of totpSecret to Base32 for consumption by end user:
> Base32.encode(binary totpSecret)
>
> Most other TOTP implementations:
> Secret generation: New secret = Random array of bytes.
> Secret storage: Base32/Base64/HEX varchar or just a binary blob (some
> might also encrypt the value in the db before storing)
> Conversion of Value column to binary totpSecret:  Base32/Base64/Hex decode
> or nothing if it's already stored as binary.
> Conversion of totpSecret to Base32 for consumption by end user:
> Base32.encode(totpSecret)
>
> The problem is that you cannot migrate any of your typical secrets into
> Keycloak as your random array of bytes cannot be reliably stored as a
> string as they cannot be reliably converted  because of low asci/UTF8
> values or special UTF8 encodings.
>
> It's about the storage and Keycloak relying on string encoding for
> conversion to binary and not about the presentation to the user (which I
> think you're referring to). If keycloak treated the secret as an array of
> bytes and stored it as BaseXX then there would be no problem at all.
>
> My suggestions below were to allow a migration to a better way of storing
> secrets while not breaking existing implementations. This relies on
> detecting how the secret is encoded. The default is whatever the current
> system's default character set is.
>
> Another way other than the 2 suggestions below to detect that the secret
> is stored as Base32 would be to check the length of the strings. Current
> length is 20, the equivalent Base32  would be 33. However, this might be
> deemed to be too obscure and fail if someone imports a shorter secret that
> ends up as length 20 as well. Perhaps it should be a configuration option
> that allows users to specify what encoding is used for the secret. UTF8
> (default), Base32/64 or Hex.
>
> I hope that clears up the problem.
>
> Thanks,
>
> Andy
>
> From: Stian Thorgersen [mailto:sthorger at redhat.com]
> Sent: 14 July 2017 05:15
> To: Dobbels, Andy
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
> The OTP strings we have today are already encoded with Base32 as the OTP
> specs mandates [1] so I don't really understand what this whole thread is
> about.
>
> [1] https://github.com/keycloak/keycloak/blob/master/
> services/src/main/java/org/keycloak/utils/TotpUtils.java
>
> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
> Hi Bill,
>
> Thanks for the response and sorry for the double post.
>
> My main concern is interoperability and not being able to import the
> secrets from existing OTP solutions even though they are all based on the
> same RFC. Creating an SPI to allow the secret to be stored as a Base32
> string instead of plain text doesn't seem right. The rest of the code is
> fine and it's all there. If you don't mind I would like to explore a few
> options that don't require an update of all existing credentials.
>
> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
> That way we can keep the existing data as is. If the prefix isn't there
> then it's plain text.
> or
> 2: Add a column that indicates what format the credentials.value property
> is encoded in. Values could be Plain or Base32. Someone could easily add
> Base64 or Hex if that helps their adoption/migration of otp. Perhaps later
> on this could open the door to encrypting the secret by having a value
> called "encrypted".
>
> Perhaps there are other options?
> Is the undocumented SPI purely dealing with how the value is encoded?
>
> Thanks,
>
> Andy
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Bill Burke
> Sent: 12 July 2017 23:16
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
>
>
> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> > Hi,
> >
> > We are adopting Keycloak and are trying to move our OTP tokens over to
> Keycloak. However, Keycloak can only use secrets that are alphanumeric
> strings whereas our existing implementation and most hard and software
> tokens we have used use the full range of binary values when generating
> secrets.
>
> > 2 questions:
> > 1: Is the lower entropy of the secrets generated by Keycloak a concern?
> Should it be a concern?  Its currently a randomly generated 20 character
> alpha-numeric string.  That's not enough entropy?
>
>
> > 2: If we provided a PR that migrated the existing data by re-encoding
> all existing secrets as Base32 and updated the code to assume Base32
> instead of string be acceptable?
> > This would be a non breaking change but allow anyone using existing OTP
> tokens to migrate their secrets which I don't think they can at the moment.
> We have undocumented SPIs to support other storage options for different
> credential types.  If you want to use the data model that's currently
> there you have to encode your secrets as strings. We're limited in the
> fact that our current OTP storage must be backward compatible.  Also,
> don't want to have to recalculate storage for every single OTP record of
> existing deployments when migrating.
>
> We could though absolutely change how future secrets are generated if
> you feel the entropy is a concern.
>
> Bill
> _______________________________________________
> 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 adobbels at bottomline.com  Fri Jul 14 09:36:57 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Fri, 14 Jul 2017 13:36:57 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <CAJgngAf_yiU_4ev6YzKU3k1LrbSq6BmCeNfG-VzPUK2Sswk75w@mail.gmail.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA0A69@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAf_yiU_4ev6YzKU3k1LrbSq6BmCeNfG-VzPUK2Sswk75w@mail.gmail.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA0C6A@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi Stian,

Are you suggesting that a future OTP Policy per credential might be a way to indicate how the secret is stored? If so, that sounds like a good 2 birds with one stone solution and I would like to know what are the steps on the path to implementing this?

Thanks,

Andy


From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: 14 July 2017 12:55
To: Dobbels, Andy
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Thanks for the recap. OK, I can see the problem. This is somewhat related to the fact that we don't currently store the OTP policy alongside a users OTP credentials. This is an issue if the OTP policy for a realm changes which could render all current OTP setups useless.

On 14 July 2017 at 12:13, Dobbels, Andy <adobbels at bottomline.com<mailto:adobbels at bottomline.com>> wrote:
Hi Stian,

In short: Keycloak uses the system's default character set (typically UTF8) to convert the secret to and from binary/string. This prevents people from moving existing token secrets into Keycloak.
See https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java#L37 getBytes() call.

Longer version:
Keycloak:
Secret generation: New secret = Random alphanumeric String(20)
Secret storage: varchar(4000) (in MS Sql Server)
Conversion of Value column to binary for use in TOTP algo:  totpSecret.getBytes() which takes a string and gets the binary representation of that string using the default string encoding
Conversion of totpSecret to Base32 for consumption by end user: Base32.encode(binary totpSecret)

Most other TOTP implementations:
Secret generation: New secret = Random array of bytes.
Secret storage: Base32/Base64/HEX varchar or just a binary blob (some might also encrypt the value in the db before storing)
Conversion of Value column to binary totpSecret:  Base32/Base64/Hex decode or nothing if it's already stored as binary.
Conversion of totpSecret to Base32 for consumption by end user: Base32.encode(totpSecret)

The problem is that you cannot migrate any of your typical secrets into Keycloak as your random array of bytes cannot be reliably stored as a string as they cannot be reliably converted  because of low asci/UTF8 values or special UTF8 encodings.

It's about the storage and Keycloak relying on string encoding for conversion to binary and not about the presentation to the user (which I think you're referring to). If keycloak treated the secret as an array of bytes and stored it as BaseXX then there would be no problem at all.

My suggestions below were to allow a migration to a better way of storing secrets while not breaking existing implementations. This relies on detecting how the secret is encoded. The default is whatever the current system's default character set is.

Another way other than the 2 suggestions below to detect that the secret is stored as Base32 would be to check the length of the strings. Current length is 20, the equivalent Base32  would be 33. However, this might be deemed to be too obscure and fail if someone imports a shorter secret that ends up as length 20 as well. Perhaps it should be a configuration option that allows users to specify what encoding is used for the secret. UTF8 (default), Base32/64 or Hex.

I hope that clears up the problem.

Thanks,

Andy

From: Stian Thorgersen [mailto:sthorger at redhat.com<mailto:sthorger at redhat.com>]
Sent: 14 July 2017 05:15
To: Dobbels, Andy
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] OTP string based secrets

The OTP strings we have today are already encoded with Base32 as the OTP specs mandates [1] so I don't really understand what this whole thread is about.

[1] https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java

On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com<mailto:adobbels at bottomline.com>> wrote:
Hi Bill,

Thanks for the response and sorry for the double post.

My main concern is interoperability and not being able to import the secrets from existing OTP solutions even though they are all based on the same RFC. Creating an SPI to allow the secret to be stored as a Base32 string instead of plain text doesn't seem right. The rest of the code is fine and it's all there. If you don't mind I would like to explore a few options that don't require an update of all existing credentials.

1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"  That way we can keep the existing data as is. If the prefix isn't there then it's plain text.
or
2: Add a column that indicates what format the credentials.value property is encoded in. Values could be Plain or Base32. Someone could easily add Base64 or Hex if that helps their adoption/migration of otp. Perhaps later on this could open the door to encrypting the secret by having a value called "encrypted".

Perhaps there are other options?
Is the undocumented SPI purely dealing with how the value is encoded?

Thanks,

Andy


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> [mailto:keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org>] On Behalf Of Bill Burke
Sent: 12 July 2017 23:16
To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] OTP string based secrets



On 7/12/17 1:39 PM, Dobbels, Andy wrote:
> Hi,
>
> We are adopting Keycloak and are trying to move our OTP tokens over to Keycloak. However, Keycloak can only use secrets that are alphanumeric strings whereas our existing implementation and most hard and software tokens we have used use the full range of binary values when generating secrets.

> 2 questions:
> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
Should it be a concern?  Its currently a randomly generated 20 character alpha-numeric string.  That's not enough entropy?


> 2: If we provided a PR that migrated the existing data by re-encoding all existing secrets as Base32 and updated the code to assume Base32 instead of string be acceptable?
> This would be a non breaking change but allow anyone using existing OTP tokens to migrate their secrets which I don't think they can at the moment.
We have undocumented SPIs to support other storage options for different
credential types.  If you want to use the data model that's currently
there you have to encode your secrets as strings. We're limited in the
fact that our current OTP storage must be backward compatible.  Also,
don't want to have to recalculate storage for every single OTP record of
existing deployments when migrating.

We could though absolutely change how future secrets are generated if
you feel the entropy is a concern.

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


From bburke at redhat.com  Fri Jul 14 11:13:31 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 14 Jul 2017 11:13:31 -0400
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
Message-ID: <f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>

Our secrets are a string and the bytes of the string are converted to 
base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See 
the difference?


On 7/14/17 12:14 AM, Stian Thorgersen wrote:
> The OTP strings we have today are already encoded with Base32 as the OTP
> specs mandates [1] so I don't really understand what this whole thread is
> about.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/utils/TotpUtils.java
>
> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>
>> Hi Bill,
>>
>> Thanks for the response and sorry for the double post.
>>
>> My main concern is interoperability and not being able to import the
>> secrets from existing OTP solutions even though they are all based on the
>> same RFC. Creating an SPI to allow the secret to be stored as a Base32
>> string instead of plain text doesn't seem right. The rest of the code is
>> fine and it's all there. If you don't mind I would like to explore a few
>> options that don't require an update of all existing credentials.
>>
>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>> That way we can keep the existing data as is. If the prefix isn't there
>> then it's plain text.
>> or
>> 2: Add a column that indicates what format the credentials.value property
>> is encoded in. Values could be Plain or Base32. Someone could easily add
>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps later
>> on this could open the door to encrypting the secret by having a value
>> called "encrypted".
>>
>> Perhaps there are other options?
>> Is the undocumented SPI purely dealing with how the value is encoded?
>>
>> Thanks,
>>
>> Andy
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
>> lists.jboss.org] On Behalf Of Bill Burke
>> Sent: 12 July 2017 23:16
>> To: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] OTP string based secrets
>>
>>
>>
>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>> Hi,
>>>
>>> We are adopting Keycloak and are trying to move our OTP tokens over to
>> Keycloak. However, Keycloak can only use secrets that are alphanumeric
>> strings whereas our existing implementation and most hard and software
>> tokens we have used use the full range of binary values when generating
>> secrets.
>>
>>> 2 questions:
>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>> Should it be a concern?  Its currently a randomly generated 20 character
>> alpha-numeric string.  That's not enough entropy?
>>
>>
>>> 2: If we provided a PR that migrated the existing data by re-encoding
>> all existing secrets as Base32 and updated the code to assume Base32
>> instead of string be acceptable?
>>> This would be a non breaking change but allow anyone using existing OTP
>> tokens to migrate their secrets which I don't think they can at the moment.
>> We have undocumented SPIs to support other storage options for different
>> credential types.  If you want to use the data model that's currently
>> there you have to encode your secrets as strings. We're limited in the
>> fact that our current OTP storage must be backward compatible.  Also,
>> don't want to have to recalculate storage for every single OTP record of
>> existing deployments when migrating.
>>
>> We could though absolutely change how future secrets are generated if
>> you feel the entropy is a concern.
>>
>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Sun Jul 16 20:47:40 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Sun, 16 Jul 2017 21:47:40 -0300
Subject: [keycloak-dev] Keycloak Openshift Image
Message-ID: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>

Hi,

I've create a repo [1] with the Docker image that I'm using for testing and
development. Specially when using Minishit.

Regarding running on Openshift, this image is very similar to what
Openshift.io team is using with support for clustering via KUBE_PING
protocol.

Do we have anything like that for Openshift ? Is there any interested to
make it an upstream image ?

[1] https://github.com/pedroigor/dockerfiles/tree/master/keycloak

Regards.
Pedro Igor

From bburke at redhat.com  Sun Jul 16 20:56:08 2017
From: bburke at redhat.com (Bill Burke)
Date: Sun, 16 Jul 2017 20:56:08 -0400
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
Message-ID: <a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>



On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
> Hi,
>
> I've create a repo [1] with the Docker image that I'm using for testing and
> development. Specially when using Minishit.

Minishit?  lol   ;-)



From psilva at redhat.com  Mon Jul 17 08:46:11 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 17 Jul 2017 09:46:11 -0300
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
Message-ID: <CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>

Oops ... Minishift !

On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
> > Hi,
> >
> > I've create a repo [1] with the Docker image that I'm using for testing
> and
> > development. Specially when using Minishit.
>
> Minishit?  lol   ;-)
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From stevenmirabito at gmail.com  Mon Jul 17 14:20:20 2017
From: stevenmirabito at gmail.com (Steven Mirabito)
Date: Mon, 17 Jul 2017 18:20:20 +0000
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
Message-ID: <CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>

Computer Science House runs Keycloak on OpenShift Origin. The official
image (jboss/keycloak) runs out of the box using OpenShift's deploy image
feature, although we run a modified image with a couple of patches to
enable Postgres/Kerberos and install a theme:
https://github.com/ComputerScienceHouse/keycloak-docker

-Steven

On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com> wrote:

> Oops ... Minishift !
>
> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com> wrote:
>
> >
> >
> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
> > > Hi,
> > >
> > > I've create a repo [1] with the Docker image that I'm using for testing
> > and
> > > development. Specially when using Minishit.
> >
> > Minishit?  lol   ;-)
> >
> >
> > _______________________________________________
> > 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 psilva at redhat.com  Mon Jul 17 17:24:08 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 17 Jul 2017 18:24:08 -0300
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
	<CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
Message-ID: <CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>

Interesting, Steven. I think one of the missing bits in our official image
is clustering. It would save some configuration time.

On Mon, Jul 17, 2017 at 3:20 PM, Steven Mirabito <stevenmirabito at gmail.com>
wrote:

> Computer Science House runs Keycloak on OpenShift Origin. The official
> image (jboss/keycloak) runs out of the box using OpenShift's deploy image
> feature, although we run a modified image with a couple of patches to
> enable Postgres/Kerberos and install a theme: https://github.com/
> ComputerScienceHouse/keycloak-docker
>
> -Steven
>
> On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> Oops ... Minishift !
>>
>> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> >
>> >
>> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
>> > > Hi,
>> > >
>> > > I've create a repo [1] with the Docker image that I'm using for
>> testing
>> > and
>> > > development. Specially when using Minishit.
>> >
>> > Minishit?  lol   ;-)
>> >
>> >
>> > _______________________________________________
>> > 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 dklingen at redhat.com  Tue Jul 18 06:16:40 2017
From: dklingen at redhat.com (David Klingenberg)
Date: Tue, 18 Jul 2017 12:16:40 +0200
Subject: [keycloak-dev] WebSocket token validation
Message-ID: <CAMB-fkqaOr-C02-k9C-0FC-tNekrR0YxMM3FZ80GLtF-=H5dBQ@mail.gmail.com>

Hi guys,

we are using keycloak in our project and we need to use websockets. There
is currently no official solution for keycloak - websocket integration, but
there is a great library in hawkular for this purpose:

https://github.com/hawkular/hawkular-accounts/tree/master/websocket-api


I think it would be great if this could become part of keycloak. What do
you think? I'm willing to contribute on it.



Best Regards,
David

From thomas.darimont at googlemail.com  Tue Jul 18 08:06:11 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 18 Jul 2017 14:06:11 +0200
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
	<CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
	<CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>
Message-ID: <CAK-7U1jYTRw3dWXNHiQe=RJRPFVi3XnfaT4vKnWZY9hb96YyzQ@mail.gmail.com>

Great example thanks for sharing!

Any reason why you choose XSLT to modify the keycloak (wildfly)
configuration instead of using jboss-cli?

https://github.com/jugsaar/visit-yajug-20161023-keycloak/blob/master/idm-system/keycloak/docker-entrypoint.sh
https://github.com/jugsaar/visit-yajug-20161023-keycloak/blob/master/idm-system/keycloak/keycloak-setup.cli

Cheers,
Thomas

2017-07-17 23:24 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:

> Interesting, Steven. I think one of the missing bits in our official image
> is clustering. It would save some configuration time.
>
> On Mon, Jul 17, 2017 at 3:20 PM, Steven Mirabito <stevenmirabito at gmail.com
> >
> wrote:
>
> > Computer Science House runs Keycloak on OpenShift Origin. The official
> > image (jboss/keycloak) runs out of the box using OpenShift's deploy image
> > feature, although we run a modified image with a couple of patches to
> > enable Postgres/Kerberos and install a theme: https://github.com/
> > ComputerScienceHouse/keycloak-docker
> >
> > -Steven
> >
> > On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com>
> > wrote:
> >
> >> Oops ... Minishift !
> >>
> >> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> >
> >> >
> >> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
> >> > > Hi,
> >> > >
> >> > > I've create a repo [1] with the Docker image that I'm using for
> >> testing
> >> > and
> >> > > development. Specially when using Minishit.
> >> >
> >> > Minishit?  lol   ;-)
> >> >
> >> >
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Tue Jul 18 09:42:25 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 18 Jul 2017 15:42:25 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with Keycloak
 and the keycloak-installed adapter
Message-ID: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>

Hello folks,

I played a bit with the undocumented? [0] keycloak-installed adapter [1]
for integrating
desktop applications with Keycloak SSO and found some issues with it, which
I'd like to share.
Small explanation for those who are reading the list but don't know the
adapter... [2]

First some general notes / suggestions:
Is the keycloak-installed adapter something that will stay in keycloak or
was this just a PoC?
In the former case I think there are some things that could be improved or
extended a bit:

- Allow users to customize the locale used for the login pages opened by
the adapter
- Provide customizable response templates (perhaps by leveraging a provided
ResourceBundle)
- Allow to customize pages shown after login / logout served by the
keycloak-installed adapter
- Add support for TLS (with custom certificates) for https:// with localhost

I noticed that some browsers (e.g. Chrome) show an error page when trying
to
redirect to the local mini-webserver after a successful login since the
mini-webserver
(...server-socket) embedded in the adapter doesn't respond with a valid
HTTP response.
With that fixed, it worked with all browsers I tested (IE, Firefox, Chrome).

My current modifications of the keycloak-installed adapter
(with HTTP response fixes and response customizations) are here:
https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8

An extended example (using the the modified keycloak-installed adapter) can
be found here:
https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1

WDYT?

Cheers,
Thomas

[0] Not mentioned here:
https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html

[1] https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed

[2] For those that haven't seen the adapter yet, it allows to authenticate
against Keycloak
from a desktop app (e.g. swing, javafx) by opening a desktop browser window
where a user
uses the regular keycloak login pages to login.
The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port which is started by
the adapter.

After logging in the mini web-server receives performs the authenorization
code flow and eventually receives the tokens (access_token, refresh_token,
id_token) which can then be
used to call backend services from the client or retrieve new tokens

A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.

The Keycloak repo contains a small example for this:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java

From stevenmirabito at gmail.com  Tue Jul 18 14:22:15 2017
From: stevenmirabito at gmail.com (Steven Mirabito)
Date: Tue, 18 Jul 2017 18:22:15 +0000
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAK-7U1jYTRw3dWXNHiQe=RJRPFVi3XnfaT4vKnWZY9hb96YyzQ@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
	<CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
	<CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>
	<CAK-7U1jYTRw3dWXNHiQe=RJRPFVi3XnfaT4vKnWZY9hb96YyzQ@mail.gmail.com>
Message-ID: <CAHVh=dZc4z1g9Fkva0Y4EUGFtqU3UWOMVJ5LTLV9xVL3ZqBm7Q@mail.gmail.com>

Hi Thomas,

No, there was another example that I found that used XSLT, so I just went
with that. I'll have to look into configuring with jboss-cli instead -
thanks for sharing!

-Steven

On Tue, Jul 18, 2017 at 5:06 AM Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Great example thanks for sharing!
>
> Any reason why you choose XSLT to modify the keycloak (wildfly)
> configuration instead of using jboss-cli?
>
>
> https://github.com/jugsaar/visit-yajug-20161023-keycloak/blob/master/idm-system/keycloak/docker-entrypoint.sh
>
> https://github.com/jugsaar/visit-yajug-20161023-keycloak/blob/master/idm-system/keycloak/keycloak-setup.cli
>
> Cheers,
> Thomas
>
> 2017-07-17 23:24 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:
>
>> Interesting, Steven. I think one of the missing bits in our official image
>> is clustering. It would save some configuration time.
>>
>> On Mon, Jul 17, 2017 at 3:20 PM, Steven Mirabito <
>> stevenmirabito at gmail.com>
>> wrote:
>>
>> > Computer Science House runs Keycloak on OpenShift Origin. The official
>> > image (jboss/keycloak) runs out of the box using OpenShift's deploy
>> image
>> > feature, although we run a modified image with a couple of patches to
>> > enable Postgres/Kerberos and install a theme: https://github.com/
>> > ComputerScienceHouse/keycloak-docker
>> >
>> > -Steven
>> >
>> > On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com>
>> > wrote:
>> >
>> >> Oops ... Minishift !
>> >>
>> >> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> >
>> >> >
>> >> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
>> >> > > Hi,
>> >> > >
>> >> > > I've create a repo [1] with the Docker image that I'm using for
>> >> testing
>> >> > and
>> >> > > development. Specially when using Minishit.
>> >> >
>> >> > Minishit?  lol   ;-)
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > keycloak-dev mailing list
>> >> > keycloak-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sjoerd.cranen at teampicnic.com  Wed Jul 19 03:50:22 2017
From: sjoerd.cranen at teampicnic.com (Sjoerd Cranen)
Date: Wed, 19 Jul 2017 09:50:22 +0200
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAHVh=dZc4z1g9Fkva0Y4EUGFtqU3UWOMVJ5LTLV9xVL3ZqBm7Q@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
	<CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
	<CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>
	<CAK-7U1jYTRw3dWXNHiQe=RJRPFVi3XnfaT4vKnWZY9hb96YyzQ@mail.gmail.com>
	<CAHVh=dZc4z1g9Fkva0Y4EUGFtqU3UWOMVJ5LTLV9xVL3ZqBm7Q@mail.gmail.com>
Message-ID: <CAMHuGfpqGUd-VMeRop3i8EocJu0OA-EfP+=7LFDrcHZKxwwDBw@mail.gmail.com>

We've been using XSLT too, based on that same example probably. We figured
it might be because some changes could require JBoss/Wildfly restarts,
which would require more overhead in the entrypoint.

Cheers,
Sjoerd

On Tue, Jul 18, 2017 at 8:22 PM, Steven Mirabito <stevenmirabito at gmail.com>
wrote:

> Hi Thomas,
>
> No, there was another example that I found that used XSLT, so I just went
> with that. I'll have to look into configuring with jboss-cli instead -
> thanks for sharing!
>
> -Steven
>
> On Tue, Jul 18, 2017 at 5:06 AM Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
> > Great example thanks for sharing!
> >
> > Any reason why you choose XSLT to modify the keycloak (wildfly)
> > configuration instead of using jboss-cli?
> >
> >
> > https://github.com/jugsaar/visit-yajug-20161023-keycloak/
> blob/master/idm-system/keycloak/docker-entrypoint.sh
> >
> > https://github.com/jugsaar/visit-yajug-20161023-keycloak/
> blob/master/idm-system/keycloak/keycloak-setup.cli
> >
> > Cheers,
> > Thomas
> >
> > 2017-07-17 23:24 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:
> >
> >> Interesting, Steven. I think one of the missing bits in our official
> image
> >> is clustering. It would save some configuration time.
> >>
> >> On Mon, Jul 17, 2017 at 3:20 PM, Steven Mirabito <
> >> stevenmirabito at gmail.com>
> >> wrote:
> >>
> >> > Computer Science House runs Keycloak on OpenShift Origin. The official
> >> > image (jboss/keycloak) runs out of the box using OpenShift's deploy
> >> image
> >> > feature, although we run a modified image with a couple of patches to
> >> > enable Postgres/Kerberos and install a theme: https://github.com/
> >> > ComputerScienceHouse/keycloak-docker
> >> >
> >> > -Steven
> >> >
> >> > On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com>
> >> > wrote:
> >> >
> >> >> Oops ... Minishift !
> >> >>
> >> >> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
> >> >> > > Hi,
> >> >> > >
> >> >> > > I've create a repo [1] with the Docker image that I'm using for
> >> >> testing
> >> >> > and
> >> >> > > development. Specially when using Minishit.
> >> >> >
> >> >> > Minishit?  lol   ;-)
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > keycloak-dev mailing list
> >> >> > keycloak-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> >
> >> >> _______________________________________________
> >> >> keycloak-dev mailing list
> >> >> keycloak-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >>
> >> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From adobbels at bottomline.com  Wed Jul 19 04:37:39 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Wed, 19 Jul 2017 08:37:39 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA22B2@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi Bill, 

Could you give me a link to any of the undocumented SPI's for custom storage of secrets? I'll start with that first if that should fix my issue in the short term.

Stian, is there any work underway to denormalize OTP policy to allow over time migration of OTP secrets and parameters similar to passwords? Is there agreement that that's the way forward?
What's involved in that? We might be able to put a PR together depending on effort and complexity involved.

Thanks,

Andy

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 14 July 2017 16:14
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Our secrets are a string and the bytes of the string are converted to 
base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See 
the difference?


On 7/14/17 12:14 AM, Stian Thorgersen wrote:
> The OTP strings we have today are already encoded with Base32 as the 
> OTP specs mandates [1] so I don't really understand what this whole 
> thread is about.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/jav
> a/org/keycloak/utils/TotpUtils.java
>
> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>
>> Hi Bill,
>>
>> Thanks for the response and sorry for the double post.
>>
>> My main concern is interoperability and not being able to import the 
>> secrets from existing OTP solutions even though they are all based on 
>> the same RFC. Creating an SPI to allow the secret to be stored as a 
>> Base32 string instead of plain text doesn't seem right. The rest of 
>> the code is fine and it's all there. If you don't mind I would like 
>> to explore a few options that don't require an update of all existing credentials.
>>
>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>> That way we can keep the existing data as is. If the prefix isn't 
>> there then it's plain text.
>> or
>> 2: Add a column that indicates what format the credentials.value 
>> property is encoded in. Values could be Plain or Base32. Someone 
>> could easily add
>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps 
>> later on this could open the door to encrypting the secret by having 
>> a value called "encrypted".
>>
>> Perhaps there are other options?
>> Is the undocumented SPI purely dealing with how the value is encoded?
>>
>> Thanks,
>>
>> Andy
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org 
>> [mailto:keycloak-dev-bounces@ lists.jboss.org] On Behalf Of Bill 
>> Burke
>> Sent: 12 July 2017 23:16
>> To: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] OTP string based secrets
>>
>>
>>
>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>> Hi,
>>>
>>> We are adopting Keycloak and are trying to move our OTP tokens over 
>>> to
>> Keycloak. However, Keycloak can only use secrets that are 
>> alphanumeric strings whereas our existing implementation and most 
>> hard and software tokens we have used use the full range of binary 
>> values when generating secrets.
>>
>>> 2 questions:
>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>> Should it be a concern?  Its currently a randomly generated 20 
>> character alpha-numeric string.  That's not enough entropy?
>>
>>
>>> 2: If we provided a PR that migrated the existing data by 
>>> re-encoding
>> all existing secrets as Base32 and updated the code to assume Base32 
>> instead of string be acceptable?
>>> This would be a non breaking change but allow anyone using existing 
>>> OTP
>> tokens to migrate their secrets which I don't think they can at the moment.
>> We have undocumented SPIs to support other storage options for 
>> different credential types.  If you want to use the data model that's 
>> currently there you have to encode your secrets as strings. We're 
>> limited in the fact that our current OTP storage must be backward 
>> compatible.  Also, don't want to have to recalculate storage for 
>> every single OTP record of existing deployments when migrating.
>>
>> We could though absolutely change how future secrets are generated if 
>> you feel the entropy is a concern.
>>
>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From sjoerd.cranen at teampicnic.com  Wed Jul 19 05:19:09 2017
From: sjoerd.cranen at teampicnic.com (Sjoerd Cranen)
Date: Wed, 19 Jul 2017 11:19:09 +0200
Subject: [keycloak-dev] Keycloak Openshift Image
In-Reply-To: <CAMHuGfpqGUd-VMeRop3i8EocJu0OA-EfP+=7LFDrcHZKxwwDBw@mail.gmail.com>
References: <CAJrcDBcGnX6EUL4_R+caGww6K+V4o1OSgOD9b7Rcg=dGj7fnXA@mail.gmail.com>
	<a238f671-b7d7-a647-16f4-db9bf480719c@redhat.com>
	<CAJrcDBc2qLqoZaVJ76uVeQ=ZYmcS-BKn-dFxkB3K9a9PUfAfjw@mail.gmail.com>
	<CAHVh=da+87tMm1f9quUy-VxmenzM3VZ0fD6nBxtGHbaKWFEXFg@mail.gmail.com>
	<CAJrcDBckVBhVvHgV6S4HKpp7wZW5Lq84EVW3kAtypfBBPMDn6A@mail.gmail.com>
	<CAK-7U1jYTRw3dWXNHiQe=RJRPFVi3XnfaT4vKnWZY9hb96YyzQ@mail.gmail.com>
	<CAHVh=dZc4z1g9Fkva0Y4EUGFtqU3UWOMVJ5LTLV9xVL3ZqBm7Q@mail.gmail.com>
	<CAMHuGfpqGUd-VMeRop3i8EocJu0OA-EfP+=7LFDrcHZKxwwDBw@mail.gmail.com>
Message-ID: <CAMHuGfoEUpi+btkY0qcv9vysjVj=mKgq-rSBfk98D+TpXSGO6g@mail.gmail.com>

Ignore my previous comment. Thomas just pointed out to me that running
wildfly embedded in jboss-cli, as he is doing in the script he provided,
solves this problem.

On Wed, Jul 19, 2017 at 9:50 AM, Sjoerd Cranen <sjoerd.cranen at teampicnic.com
> wrote:

> We've been using XSLT too, based on that same example probably. We figured
> it might be because some changes could require JBoss/Wildfly restarts,
> which would require more overhead in the entrypoint.
>
> Cheers,
> Sjoerd
>
> On Tue, Jul 18, 2017 at 8:22 PM, Steven Mirabito <stevenmirabito at gmail.com
> > wrote:
>
>> Hi Thomas,
>>
>> No, there was another example that I found that used XSLT, so I just went
>> with that. I'll have to look into configuring with jboss-cli instead -
>> thanks for sharing!
>>
>> -Steven
>>
>> On Tue, Jul 18, 2017 at 5:06 AM Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>> > Great example thanks for sharing!
>> >
>> > Any reason why you choose XSLT to modify the keycloak (wildfly)
>> > configuration instead of using jboss-cli?
>> >
>> >
>> > https://github.com/jugsaar/visit-yajug-20161023-keycloak/blo
>> b/master/idm-system/keycloak/docker-entrypoint.sh
>> >
>> > https://github.com/jugsaar/visit-yajug-20161023-keycloak/blo
>> b/master/idm-system/keycloak/keycloak-setup.cli
>> >
>> > Cheers,
>> > Thomas
>> >
>> > 2017-07-17 23:24 GMT+02:00 Pedro Igor Silva <psilva at redhat.com>:
>> >
>> >> Interesting, Steven. I think one of the missing bits in our official
>> image
>> >> is clustering. It would save some configuration time.
>> >>
>> >> On Mon, Jul 17, 2017 at 3:20 PM, Steven Mirabito <
>> >> stevenmirabito at gmail.com>
>> >> wrote:
>> >>
>> >> > Computer Science House runs Keycloak on OpenShift Origin. The
>> official
>> >> > image (jboss/keycloak) runs out of the box using OpenShift's deploy
>> >> image
>> >> > feature, although we run a modified image with a couple of patches to
>> >> > enable Postgres/Kerberos and install a theme: https://github.com/
>> >> > ComputerScienceHouse/keycloak-docker
>> >> >
>> >> > -Steven
>> >> >
>> >> > On Mon, Jul 17, 2017 at 7:07 AM Pedro Igor Silva <psilva at redhat.com>
>> >> > wrote:
>> >> >
>> >> >> Oops ... Minishift !
>> >> >>
>> >> >> On Sun, Jul 16, 2017 at 9:56 PM, Bill Burke <bburke at redhat.com>
>> wrote:
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On 7/16/17 8:47 PM, Pedro Igor Silva wrote:
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > > I've create a repo [1] with the Docker image that I'm using for
>> >> >> testing
>> >> >> > and
>> >> >> > > development. Specially when using Minishit.
>> >> >> >
>> >> >> > Minishit?  lol   ;-)
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > keycloak-dev mailing list
>> >> >> > keycloak-dev at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >> >
>> >> >> _______________________________________________
>> >> >> keycloak-dev mailing list
>> >> >> keycloak-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >>
>> >> >
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>
>> >
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From c.majeri at gmail.com  Wed Jul 19 08:59:12 2017
From: c.majeri at gmail.com (Chervine Majeri)
Date: Wed, 19 Jul 2017 14:59:12 +0200
Subject: [keycloak-dev] Generating ascii documentation for rest API
Message-ID: <CAB8J2R4yu=sfBsZ1dVAyE+9kEkM2fdSbM2-7Kfz+2bKYkwHKMQ@mail.gmail.com>

Hi everyone,

To program a client (in go) for the rest API, I want to map all the json
representations to structs in the code.
To this end it would be great if there were json schema files to represent
them. But as I understand it, those aren't available (
https://issues.jboss.org/browse/KEYCLOAK-4661).

The next best thing would be to generate the ascii docs and parse those,
rather than go through parsing html directly. But I get errors when I try
to generate the docs in markup using the maven "gen-asciidoc" goal.

Running :

mvn -X -P jboss-release
io.github.swagger2markup:swagger2markup-maven-plugin:convertSwagger2markup

returns a null pointer exception and a maven mojo failure.

I've checked that the correct versions of swagger2markup are getting
fetched.

Does anyone else have that behaviour? Or is there some other way of
generating ascii documentation?

My environment is as vanilla as it can get, without any modifications to
the default maven settings.xml (it's pretty much empty except comments).


Thanks.


maven --version output :
Apache Maven 3.3.9 (NON-CANONICAL_2016-07-01T11:53:38Z_mockbuild;
2016-07-01T13:53:38+02:00)
Maven home: /usr/share/maven
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.11.6-201.fc25.x86_64", arch: "amd64", family:
"unix"

From hmlnarik at redhat.com  Wed Jul 19 09:44:25 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 19 Jul 2017 15:44:25 +0200
Subject: [keycloak-dev] Async authentication example
In-Reply-To: <CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
References: <CAJgngAeTgHHz3a1jh9K9PrTDnQ1v0TwyzLP_ye2xQnki+07vdg@mail.gmail.com>
	<CAJrcDBeaO33DLs7eD=-Lq2cn_no8YbpzMOhQNShXUsgur4Ukcg@mail.gmail.com>
	<CAMvXD=GDoyaGQdnhc5mPa4Eo8QuRJEV2sSthhysa3n06hK-sGw@mail.gmail.com>
	<CAJgngAfKpBXR6SNZ+G-LZtm17Vg0P5JjnMXNyER2kyckZ-0q=w@mail.gmail.com>
Message-ID: <CAMvXD=H=Gr+5pcOFwmvGF9dgo_Hu8n2k=BejQaPnZiBJ_x_O_A@mail.gmail.com>

Just added the example -
https://github.com/keycloak/keycloak-quickstarts/tree/master/action-token-authenticator

--Hynek

On Wed, Jul 12, 2017 at 12:46 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>
> On 12 July 2017 at 12:24, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> Great!
>>
>> For 7.2 and on, action tokens approach is the way, and actually a
>> quickstart with that has been implemented [1]. Instead of an authenticator
>> and note manipulation that are necessary for 7.1, it employs required
>> actions (when action token is used, it just removes the custom required
>> action).
>>
>> It uses somewhat similar approach to the SET but currently with a two
>> tokens - one created and signed by Keycloak used to reenter the
>> authentication flow when the app completes its flow, and the other signed by
>> the app to have certain chance that the response has indeed been generated
>> by the correct app. For details see README.md.
>
>
> Action tokens may work in some situations, but may not always work. If there
> is a specific protocol being used (for example BankID
> https://www.bankid.com/) it may demand a certain callback format in which
> case we would have to implement a custom realm resource to handle the
> callback.
>
> Hynek - could you create a fork of my example that uses action tokens?
>
>>
>>
>> [1] https://github.com/keycloak/keycloak-quickstarts/pull/37
>>
>> On Tue, Jul 11, 2017 at 7:10 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>>
>>> Really nice !
>>>
>>> On Tue, Jul 11, 2017 at 9:29 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>> > I gave it a go and implemented an "async" authentication example. It's
>>> > rather simple what happens is:
>>> >
>>> > * User authenticates with username only
>>> > * Then a "waiting" page is displayed, which is waiting for some
>>> > external
>>> > callback. This could be an app or whatever that verifies the user then
>>> > sends the callback. In the example a CURL command is printed on sysout
>>> > for
>>> > the server which you can run to "simulate" the callback from the app.
>>> > * Once the callback is received the user is authenticated without
>>> > filling
>>> > in password or any other credentials in the main browser
>>> >
>>>
>>> Maybe you can use a SET [1], which is basically a JWT, in order to
>>> communicate authentication events between parties. For instance, send
>>> additional data to the external callback about the authentication context
>>> and receive back from the external callback information on how to proceed
>>> with the authentication.
>>>
>>> [1] https://tools.ietf.org/html/draft-hunt-idevent-token-03
>>>
>>>
>>> >
>>> > https://github.com/stianst/authenticator-example
>>> >
>>> > Check it out here:
>>> > https://youtu.be/C09BpNIf4v8
>>> >
>>> > It's a bit hacky in the way it's implemented:
>>> >
>>> > * Using notes for "callback" is a bit strange maybe?
>>> > * Had to use custom realm resource for callback endpoint. Is this
>>> > strange?
>>> > * Probably won't work for cross DC, but in 7.2 Hynek has stuff that
>>> > does
>>> > that
>>> > * No way to push change to browser, so have to pull every 2 seconds.
>>> > Maybe
>>> > we could add a simple authentication event feature that uses websockets
>>> > and
>>> > a small auth js lib to do the job of notification?
>>> > _______________________________________________
>>> > 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
>>
>>
>>
>>
>> --
>>
>> --Hynek
>
>



-- 

--Hynek

From bburke at redhat.com  Wed Jul 19 10:31:55 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Jul 2017 10:31:55 -0400
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
Message-ID: <74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>

I'm working on something for command line apps.  A command-line 
text/plain protocol so that login can happen within a console.  I really 
think keycloak-installation or the OAuth device flow is really poor 
solution.


On 7/18/17 9:42 AM, Thomas Darimont wrote:
> Hello folks,
>
> I played a bit with the undocumented? [0] keycloak-installed adapter [1]
> for integrating
> desktop applications with Keycloak SSO and found some issues with it, which
> I'd like to share.
> Small explanation for those who are reading the list but don't know the
> adapter... [2]
>
> First some general notes / suggestions:
> Is the keycloak-installed adapter something that will stay in keycloak or
> was this just a PoC?
> In the former case I think there are some things that could be improved or
> extended a bit:
>
> - Allow users to customize the locale used for the login pages opened by
> the adapter
> - Provide customizable response templates (perhaps by leveraging a provided
> ResourceBundle)
> - Allow to customize pages shown after login / logout served by the
> keycloak-installed adapter
> - Add support for TLS (with custom certificates) for https:// with localhost
>
> I noticed that some browsers (e.g. Chrome) show an error page when trying
> to
> redirect to the local mini-webserver after a successful login since the
> mini-webserver
> (...server-socket) embedded in the adapter doesn't respond with a valid
> HTTP response.
> With that fixed, it worked with all browsers I tested (IE, Firefox, Chrome).
>
> My current modifications of the keycloak-installed adapter
> (with HTTP response fixes and response customizations) are here:
> https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8
>
> An extended example (using the the modified keycloak-installed adapter) can
> be found here:
> https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>
> WDYT?
>
> Cheers,
> Thomas
>
> [0] Not mentioned here:
> https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html
>
> [1] https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
>
> [2] For those that haven't seen the adapter yet, it allows to authenticate
> against Keycloak
> from a desktop app (e.g. swing, javafx) by opening a desktop browser window
> where a user
> uses the regular keycloak login pages to login.
> The trick is now that login page is opened with redirect URL that points to
> a small local
> "web server" (server-socket) on a free ephemeral port which is started by
> the adapter.
>
> After logging in the mini web-server receives performs the authenorization
> code flow and eventually receives the tokens (access_token, refresh_token,
> id_token) which can then be
> used to call backend services from the client or retrieve new tokens
>
> A nice side effect of this is, that the desktop application never sees a
> users
> password and one can leverage existing SSO sessions.
> Btw. the google cloud cli uses the same approach to authenticate with gcp.
>
> The Keycloak repo contains a small example for this:
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Wed Jul 19 14:26:00 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 19 Jul 2017 14:26:00 -0400
Subject: [keycloak-dev] Do we care about reproducible builds?
Message-ID: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>

I'm asking this question about the community version of Keycloak. RH-SSO 
absolutely must be reproducible.

The reason I ask is because we will soon stop checking node_modules into 
github.  javascript libraries will be pulled in at build time.

We will lock down the library versions with yarn, which means everything 
is theoretically reproducible as long as the public npm repo is stable.

But if we want to be extra-sure, we can set up our own npm repo and 
archive it with each community release.

WDYT?  How much do we care about reproducible builds in community?

Stan

From bburke at redhat.com  Wed Jul 19 16:26:10 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 19 Jul 2017 16:26:10 -0400
Subject: [keycloak-dev] Do we care about reproducible builds?
In-Reply-To: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
References: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
Message-ID: <429d9853-9319-56db-9616-e6236b1ab19f@redhat.com>

Don't know what you mean by reproducible builds.


On 7/19/17 2:26 PM, Stan Silvert wrote:
> I'm asking this question about the community version of Keycloak. RH-SSO
> absolutely must be reproducible.
>
> The reason I ask is because we will soon stop checking node_modules into
> github.  javascript libraries will be pulled in at build time.
>
> We will lock down the library versions with yarn, which means everything
> is theoretically reproducible as long as the public npm repo is stable.
>
> But if we want to be extra-sure, we can set up our own npm repo and
> archive it with each community release.
>
> WDYT?  How much do we care about reproducible builds in community?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Wed Jul 19 17:40:18 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 19 Jul 2017 21:40:18 +0000
Subject: [keycloak-dev] Do we care about reproducible builds?
In-Reply-To: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
References: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
Message-ID: <CAM5SUC4tSrgPAdsRK3J72v04gtFaJdXabduTz0rAQsDv5N93xg@mail.gmail.com>

Thinking about this scenario and the fact that you're going to lock down
the library versions.
I'd say go for it.

On Wed, Jul 19, 2017 at 5:03 PM Stan Silvert <ssilvert at redhat.com> wrote:

> I'm asking this question about the community version of Keycloak. RH-SSO
> absolutely must be reproducible.
>
> The reason I ask is because we will soon stop checking node_modules into
> github.  javascript libraries will be pulled in at build time.
>
> We will lock down the library versions with yarn, which means everything
> is theoretically reproducible as long as the public npm repo is stable.
>
> But if we want to be extra-sure, we can set up our own npm repo and
> archive it with each community release.
>
> WDYT?  How much do we care about reproducible builds in community?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Wed Jul 19 18:10:13 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 19 Jul 2017 19:10:13 -0300
Subject: [keycloak-dev] Do we care about reproducible builds?
In-Reply-To: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
References: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
Message-ID: <CAJrcDBd39n5+DtXsyZ5H3ogubof1egTftjQDHHxtCs4zHLRa-w@mail.gmail.com>

Not sure if we need to worry about our own npm repo but just grab the
versions we need from npm during the first install/build. Or are you more
worried about introducing vulnerabilities in case (somehow, by passing
checksum, i don't know) the version we use is modified ?

Regards.
Pedro Igor

On Wed, Jul 19, 2017 at 3:26 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> I'm asking this question about the community version of Keycloak. RH-SSO
> absolutely must be reproducible.
>
> The reason I ask is because we will soon stop checking node_modules into
> github.  javascript libraries will be pulled in at build time.
>
> We will lock down the library versions with yarn, which means everything
> is theoretically reproducible as long as the public npm repo is stable.
>
> But if we want to be extra-sure, we can set up our own npm repo and
> archive it with each community release.
>
> WDYT?  How much do we care about reproducible builds in community?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Thu Jul 20 08:57:58 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 20 Jul 2017 08:57:58 -0400
Subject: [keycloak-dev] Do we care about reproducible builds?
In-Reply-To: <CAJrcDBd39n5+DtXsyZ5H3ogubof1egTftjQDHHxtCs4zHLRa-w@mail.gmail.com>
References: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
	<CAJrcDBd39n5+DtXsyZ5H3ogubof1egTftjQDHHxtCs4zHLRa-w@mail.gmail.com>
Message-ID: <9c9c15cf-3135-c7a7-b471-e7baddfb926e@redhat.com>

So to be more clear, a reproducible build means that once we release a 
version of Keycloak we can rebuild and reproduce the exact bits at any time.

To do this perfectly, we must pull in the exact versions of every js 
library we ship.

So the question is, for community builds, should we maintain our own 
archived version of these libraries or can we pull from the public npm repo?

In the public npm repo, library publishers are allowed to modify their 
bits for 24 hours after publishing.  They may also republish at a later 
time via special request, though this is highly discouraged.

So if we don't archive js libraries with each release it is possible, 
though unlikely, that we could end up with a non-reproducible build.

That's why I ask how much we really care about reproducibility in community.

On 7/19/2017 6:10 PM, Pedro Igor Silva wrote:
> Not sure if we need to worry about our own npm repo but just grab the 
> versions we need from npm during the first install/build. Or are you 
> more worried about introducing vulnerabilities in case (somehow, by 
> passing checksum, i don't know) the version we use is modified ?
>
> Regards.
> Pedro Igor
>
> On Wed, Jul 19, 2017 at 3:26 PM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     I'm asking this question about the community version of Keycloak.
>     RH-SSO
>     absolutely must be reproducible.
>
>     The reason I ask is because we will soon stop checking
>     node_modules into
>     github.  javascript libraries will be pulled in at build time.
>
>     We will lock down the library versions with yarn, which means
>     everything
>     is theoretically reproducible as long as the public npm repo is
>     stable.
>
>     But if we want to be extra-sure, we can set up our own npm repo and
>     archive it with each community release.
>
>     WDYT?  How much do we care about reproducible builds in community?
>
>     Stan
>     _______________________________________________
>     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
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From thomas.darimont at googlemail.com  Thu Jul 20 09:04:27 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 20 Jul 2017 15:04:27 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
Message-ID: <CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>

That's interesting.

Will there also be support for desktop apps in some way?

What in particular do you think is the problem with the approach used by
the keycloak-installed adapter
and OAuth device flow, guessing you mean:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 ?

Cheers,
Thomas



2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com>:

> I'm working on something for command line apps.  A command-line
> text/plain protocol so that login can happen within a console.  I really
> think keycloak-installation or the OAuth device flow is really poor
> solution.
>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > Hello folks,
> >
> > I played a bit with the undocumented? [0] keycloak-installed adapter [1]
> > for integrating
> > desktop applications with Keycloak SSO and found some issues with it,
> which
> > I'd like to share.
> > Small explanation for those who are reading the list but don't know the
> > adapter... [2]
> >
> > First some general notes / suggestions:
> > Is the keycloak-installed adapter something that will stay in keycloak or
> > was this just a PoC?
> > In the former case I think there are some things that could be improved
> or
> > extended a bit:
> >
> > - Allow users to customize the locale used for the login pages opened by
> > the adapter
> > - Provide customizable response templates (perhaps by leveraging a
> provided
> > ResourceBundle)
> > - Allow to customize pages shown after login / logout served by the
> > keycloak-installed adapter
> > - Add support for TLS (with custom certificates) for https:// with
> localhost
> >
> > I noticed that some browsers (e.g. Chrome) show an error page when trying
> > to
> > redirect to the local mini-webserver after a successful login since the
> > mini-webserver
> > (...server-socket) embedded in the adapter doesn't respond with a valid
> > HTTP response.
> > With that fixed, it worked with all browsers I tested (IE, Firefox,
> Chrome).
> >
> > My current modifications of the keycloak-installed adapter
> > (with HTTP response fixes and response customizations) are here:
> > https://github.com/thomasdarimont/keycloak/commit/
> b8ee52a946e73503b1737f5ca7d4520b8484dae8
> >
> > An extended example (using the the modified keycloak-installed adapter)
> can
> > be found here:
> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
> >
> > WDYT?
> >
> > Cheers,
> > Thomas
> >
> > [0] Not mentioned here:
> > https://keycloak.gitbooks.io/documentation/securing_apps/
> topics/oidc/java/java-adapters.html
> >
> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/
> oidc/installed
> >
> > [2] For those that haven't seen the adapter yet, it allows to
> authenticate
> > against Keycloak
> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
> window
> > where a user
> > uses the regular keycloak login pages to login.
> > The trick is now that login page is opened with redirect URL that points
> to
> > a small local
> > "web server" (server-socket) on a free ephemeral port which is started by
> > the adapter.
> >
> > After logging in the mini web-server receives performs the
> authenorization
> > code flow and eventually receives the tokens (access_token,
> refresh_token,
> > id_token) which can then be
> > used to call backend services from the client or retrieve new tokens
> >
> > A nice side effect of this is, that the desktop application never sees a
> > users
> > password and one can leverage existing SSO sessions.
> > Btw. the google cloud cli uses the same approach to authenticate with
> gcp.
> >
> > The Keycloak repo contains a small example for this:
> > https://github.com/keycloak/keycloak/blob/master/examples/
> demo-template/customer-app-cli/src/main/java/org/
> keycloak/example/CustomerCli.java
> > _______________________________________________
> > 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 thomas.darimont at googlemail.com  Thu Jul 20 09:22:55 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 20 Jul 2017 15:22:55 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
	<CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
Message-ID: <CAK-7U1hdndEF-ceneQH+0NAePUkJ49f7818mvhGLuXm3srxa8g@mail.gmail.com>

some more food for thought:

Google seems to recommend using the Loopback IP address to obtain the
authorization
code from a successful Oauth 2.0 interaction in the browser, see [0].

Create authorization credentials -> Option 2: Loopback IP address (macOS,
Linux, Windows desktop)

Other methods like "manual copy/paste" (of the auth code) or "Programmatic
extraction"
are supported but not recommended - the recommended approach is to use
either
Loopback IP address or a Custom URI scheme (on mobile apps or Windows UWP).
Though, one might still be able to programmatically register a custom
protocol handler
in windows and other platforms.

Google also provides some example applications that demonstate the various
approaches.

Further more, OAuth for Apps: Sample Desktop Application for Windows [1]
mentions: OAuth 2.0 for Native Apps (draft-ietf-oauth-native-apps-12) [2]
which descibes the
approaches mentioned above in more detail.

E.g. in 4.1 "Authorization Flow for Native Apps Using the Browser" they
IMHO
describe the interaction model of the keycloak-installed adapter.

[0] https://developers.google.com/identity/protocols/OAuth2InstalledApp
[1]
https://github.com/googlesamples/oauth-apps-for-windows/tree/master/OAuthDesktopApp
[2] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12


2017-07-20 15:04 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> That's interesting.
>
> Will there also be support for desktop apps in some way?
>
> What in particular do you think is the problem with the approach used by
> the keycloak-installed adapter
> and OAuth device flow, guessing you mean: https://tools.ietf.org/html/
> draft-ietf-oauth-device-flow-06 ?
>
> Cheers,
> Thomas
>
>
>
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com>:
>
>> I'm working on something for command line apps.  A command-line
>> text/plain protocol so that login can happen within a console.  I really
>> think keycloak-installation or the OAuth device flow is really poor
>> solution.
>>
>>
>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>> > Hello folks,
>> >
>> > I played a bit with the undocumented? [0] keycloak-installed adapter [1]
>> > for integrating
>> > desktop applications with Keycloak SSO and found some issues with it,
>> which
>> > I'd like to share.
>> > Small explanation for those who are reading the list but don't know the
>> > adapter... [2]
>> >
>> > First some general notes / suggestions:
>> > Is the keycloak-installed adapter something that will stay in keycloak
>> or
>> > was this just a PoC?
>> > In the former case I think there are some things that could be improved
>> or
>> > extended a bit:
>> >
>> > - Allow users to customize the locale used for the login pages opened by
>> > the adapter
>> > - Provide customizable response templates (perhaps by leveraging a
>> provided
>> > ResourceBundle)
>> > - Allow to customize pages shown after login / logout served by the
>> > keycloak-installed adapter
>> > - Add support for TLS (with custom certificates) for https:// with
>> localhost
>> >
>> > I noticed that some browsers (e.g. Chrome) show an error page when
>> trying
>> > to
>> > redirect to the local mini-webserver after a successful login since the
>> > mini-webserver
>> > (...server-socket) embedded in the adapter doesn't respond with a valid
>> > HTTP response.
>> > With that fixed, it worked with all browsers I tested (IE, Firefox,
>> Chrome).
>> >
>> > My current modifications of the keycloak-installed adapter
>> > (with HTTP response fixes and response customizations) are here:
>> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
>> e73503b1737f5ca7d4520b8484dae8
>> >
>> > An extended example (using the the modified keycloak-installed adapter)
>> can
>> > be found here:
>> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>> >
>> > WDYT?
>> >
>> > Cheers,
>> > Thomas
>> >
>> > [0] Not mentioned here:
>> > https://keycloak.gitbooks.io/documentation/securing_apps/top
>> ics/oidc/java/java-adapters.html
>> >
>> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
>> dc/installed
>> >
>> > [2] For those that haven't seen the adapter yet, it allows to
>> authenticate
>> > against Keycloak
>> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
>> window
>> > where a user
>> > uses the regular keycloak login pages to login.
>> > The trick is now that login page is opened with redirect URL that
>> points to
>> > a small local
>> > "web server" (server-socket) on a free ephemeral port which is started
>> by
>> > the adapter.
>> >
>> > After logging in the mini web-server receives performs the
>> authenorization
>> > code flow and eventually receives the tokens (access_token,
>> refresh_token,
>> > id_token) which can then be
>> > used to call backend services from the client or retrieve new tokens
>> >
>> > A nice side effect of this is, that the desktop application never sees a
>> > users
>> > password and one can leverage existing SSO sessions.
>> > Btw. the google cloud cli uses the same approach to authenticate with
>> gcp.
>> >
>> > The Keycloak repo contains a small example for this:
>> > https://github.com/keycloak/keycloak/blob/master/examples/de
>> mo-template/customer-app-cli/src/main/java/org/keycloak/
>> example/CustomerCli.java
>> > _______________________________________________
>> > 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 Jul 20 09:23:28 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Jul 2017 09:23:28 -0400
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
	<CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
Message-ID: <91199b0c-6ce1-b884-db54-30814480612d@redhat.com>

What's wrong?  The fact you have to cut and paste a code from the 
browser to the app.


On 7/20/17 9:04 AM, Thomas Darimont wrote:
> That's interesting.
>
> Will there also be support for desktop apps in some way?
>
> What in particular do you think is the problem with the approach used 
> by the keycloak-installed adapter
> and OAuth device flow, guessing you mean: 
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06 ?
>
> Cheers,
> Thomas
>
>
>
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>>:
>
>     I'm working on something for command line apps.  A command-line
>     text/plain protocol so that login can happen within a console.  I
>     really
>     think keycloak-installation or the OAuth device flow is really poor
>     solution.
>
>
>     On 7/18/17 9:42 AM, Thomas Darimont wrote:
>     > Hello folks,
>     >
>     > I played a bit with the undocumented? [0] keycloak-installed
>     adapter [1]
>     > for integrating
>     > desktop applications with Keycloak SSO and found some issues
>     with it, which
>     > I'd like to share.
>     > Small explanation for those who are reading the list but don't
>     know the
>     > adapter... [2]
>     >
>     > First some general notes / suggestions:
>     > Is the keycloak-installed adapter something that will stay in
>     keycloak or
>     > was this just a PoC?
>     > In the former case I think there are some things that could be
>     improved or
>     > extended a bit:
>     >
>     > - Allow users to customize the locale used for the login pages
>     opened by
>     > the adapter
>     > - Provide customizable response templates (perhaps by leveraging
>     a provided
>     > ResourceBundle)
>     > - Allow to customize pages shown after login / logout served by the
>     > keycloak-installed adapter
>     > - Add support for TLS (with custom certificates) for https://
>     with localhost
>     >
>     > I noticed that some browsers (e.g. Chrome) show an error page
>     when trying
>     > to
>     > redirect to the local mini-webserver after a successful login
>     since the
>     > mini-webserver
>     > (...server-socket) embedded in the adapter doesn't respond with
>     a valid
>     > HTTP response.
>     > With that fixed, it worked with all browsers I tested (IE,
>     Firefox, Chrome).
>     >
>     > My current modifications of the keycloak-installed adapter
>     > (with HTTP response fixes and response customizations) are here:
>     >
>     https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8
>     <https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8>
>     >
>     > An extended example (using the the modified keycloak-installed
>     adapter) can
>     > be found here:
>     >
>     https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>     <https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1>
>     >
>     > WDYT?
>     >
>     > Cheers,
>     > Thomas
>     >
>     > [0] Not mentioned here:
>     >
>     https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html
>     <https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html>
>     >
>     > [1]
>     https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
>     <https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed>
>     >
>     > [2] For those that haven't seen the adapter yet, it allows to
>     authenticate
>     > against Keycloak
>     > from a desktop app (e.g. swing, javafx) by opening a desktop
>     browser window
>     > where a user
>     > uses the regular keycloak login pages to login.
>     > The trick is now that login page is opened with redirect URL
>     that points to
>     > a small local
>     > "web server" (server-socket) on a free ephemeral port which is
>     started by
>     > the adapter.
>     >
>     > After logging in the mini web-server receives performs the
>     authenorization
>     > code flow and eventually receives the tokens (access_token,
>     refresh_token,
>     > id_token) which can then be
>     > used to call backend services from the client or retrieve new tokens
>     >
>     > A nice side effect of this is, that the desktop application
>     never sees a
>     > users
>     > password and one can leverage existing SSO sessions.
>     > Btw. the google cloud cli uses the same approach to authenticate
>     with gcp.
>     >
>     > The Keycloak repo contains a small example for this:
>     >
>     https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java
>     <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java>
>     > _______________________________________________
>     > 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
>     <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
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From thomas.darimont at googlemail.com  Thu Jul 20 09:41:31 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 20 Jul 2017 15:41:31 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <91199b0c-6ce1-b884-db54-30814480612d@redhat.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
	<CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
	<91199b0c-6ce1-b884-db54-30814480612d@redhat.com>
Message-ID: <CAK-7U1jxnNmirNex4rCbNJAonadGjEaBF4hYmqvnTXT+MZGaOw@mail.gmail.com>

Hi Bill,

actually that's not the way it works - there is no manuall copying of the
auth-code needed
in the case of desktop apps.

An example gist can be found at [1]

It works as follows:

When a user wants to login via a desktop app (e.g. swing, javafx) a desktop
browser
is opened window where a user uses the regular keycloak login pages to
login.

The trick is now that login page is opened with redirect URL that points to
a small local
"web server" (server-socket) on a free ephemeral port listening on
localhost
(which should be rather 127.0.0.1 according to [0]) which is started by the
adapter.

After logging in the mini web-server receives the auth code and performs
the via the
redirect uri: localhost:XXXXX and performs the remaioning authorization
code flow.

The keycloak-installed adapter eventually receives the tokens (access_token,
refresh_token, id_token)
which can then be used to call backend services from the client or retrieve
new tokens.

A nice side effect of this is, that the desktop application never sees a
users
password and one can leverage existing SSO sessions.
Btw. the google cloud cli uses the same approach to authenticate with gcp.

[0] https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.3
[1] https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb9508
(in the client in Keycloaks needs to allow http://localhost as valid
redirect uri - should rather be http://127.0.0.1)

Cheers,
Thomas

2017-07-20 15:23 GMT+02:00 Bill Burke <bburke at redhat.com>:

> What's wrong?  The fact you have to cut and paste a code from the browser
> to the app.
>
> On 7/20/17 9:04 AM, Thomas Darimont wrote:
>
> That's interesting.
>
> Will there also be support for desktop apps in some way?
>
> What in particular do you think is the problem with the approach used by
> the keycloak-installed adapter
> and OAuth device flow, guessing you mean: https://tools.ietf.org/html/
> draft-ietf-oauth-device-flow-06 ?
>
> Cheers,
> Thomas
>
>
>
> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com>:
>
>> I'm working on something for command line apps.  A command-line
>> text/plain protocol so that login can happen within a console.  I really
>> think keycloak-installation or the OAuth device flow is really poor
>> solution.
>>
>>
>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>> > Hello folks,
>> >
>> > I played a bit with the undocumented? [0] keycloak-installed adapter [1]
>> > for integrating
>> > desktop applications with Keycloak SSO and found some issues with it,
>> which
>> > I'd like to share.
>> > Small explanation for those who are reading the list but don't know the
>> > adapter... [2]
>> >
>> > First some general notes / suggestions:
>> > Is the keycloak-installed adapter something that will stay in keycloak
>> or
>> > was this just a PoC?
>> > In the former case I think there are some things that could be improved
>> or
>> > extended a bit:
>> >
>> > - Allow users to customize the locale used for the login pages opened by
>> > the adapter
>> > - Provide customizable response templates (perhaps by leveraging a
>> provided
>> > ResourceBundle)
>> > - Allow to customize pages shown after login / logout served by the
>> > keycloak-installed adapter
>> > - Add support for TLS (with custom certificates) for https:// with
>> localhost
>> >
>> > I noticed that some browsers (e.g. Chrome) show an error page when
>> trying
>> > to
>> > redirect to the local mini-webserver after a successful login since the
>> > mini-webserver
>> > (...server-socket) embedded in the adapter doesn't respond with a valid
>> > HTTP response.
>> > With that fixed, it worked with all browsers I tested (IE, Firefox,
>> Chrome).
>> >
>> > My current modifications of the keycloak-installed adapter
>> > (with HTTP response fixes and response customizations) are here:
>> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
>> e73503b1737f5ca7d4520b8484dae8
>> >
>> > An extended example (using the the modified keycloak-installed adapter)
>> can
>> > be found here:
>> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>> >
>> > WDYT?
>> >
>> > Cheers,
>> > Thomas
>> >
>> > [0] Not mentioned here:
>> > https://keycloak.gitbooks.io/documentation/securing_apps/top
>> ics/oidc/java/java-adapters.html
>> >
>> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
>> dc/installed
>> >
>> > [2] For those that haven't seen the adapter yet, it allows to
>> authenticate
>> > against Keycloak
>> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
>> window
>> > where a user
>> > uses the regular keycloak login pages to login.
>> > The trick is now that login page is opened with redirect URL that
>> points to
>> > a small local
>> > "web server" (server-socket) on a free ephemeral port which is started
>> by
>> > the adapter.
>> >
>> > After logging in the mini web-server receives performs the
>> authenorization
>> > code flow and eventually receives the tokens (access_token,
>> refresh_token,
>> > id_token) which can then be
>> > used to call backend services from the client or retrieve new tokens
>> >
>> > A nice side effect of this is, that the desktop application never sees a
>> > users
>> > password and one can leverage existing SSO sessions.
>> > Btw. the google cloud cli uses the same approach to authenticate with
>> gcp.
>> >
>> > The Keycloak repo contains a small example for this:
>> > https://github.com/keycloak/keycloak/blob/master/examples/de
>> mo-template/customer-app-cli/src/main/java/org/keycloak/
>> example/CustomerCli.java
>> > _______________________________________________
>> > 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 Jul 20 09:56:44 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 20 Jul 2017 09:56:44 -0400
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <CAK-7U1jxnNmirNex4rCbNJAonadGjEaBF4hYmqvnTXT+MZGaOw@mail.gmail.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
	<CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
	<91199b0c-6ce1-b884-db54-30814480612d@redhat.com>
	<CAK-7U1jxnNmirNex4rCbNJAonadGjEaBF4hYmqvnTXT+MZGaOw@mail.gmail.com>
Message-ID: <3c573644-c9c8-21b3-aa32-9a31439239c5@redhat.com>

Still crap for command line apps where all you have is a console window.


On 7/20/17 9:41 AM, Thomas Darimont wrote:
> Hi Bill,
>
> actually that's not the way it works - there is no manuall copying of 
> the auth-code needed
> in the case of desktop apps.
>
> An example gist can be found at [1]
>
> It works as follows:
>
> When a user wants to login via a desktop app (e.g. swing, javafx) a 
> desktop browser
> is opened window where a user uses the regular keycloak login pages to 
> login.
>
> The trick is now that login page is opened with redirect URL that 
> points to a small local
> "web server" (server-socket) on a free ephemeral port listening on 
> localhost
> (which should berather 127.0.0.1 according to [0]) which is started by 
> the adapter.
>
> After logging in the mini web-server receives the auth code and 
> performs the via the
> redirect uri: localhost:XXXXX and performs the remaioning 
> authorization code flow.
>
> The keycloak-installed adapter eventually receives the tokens 
> (access_token, refresh_token, id_token)
> which can then be used to call backend services from the client or 
> retrieve new tokens.
>
> A nice side effect of this is, that the desktop application never sees 
> a users
> password and one can leverage existing SSO sessions.
> Btw. the google cloud cli uses the same approach to authenticate with gcp.
>
> [0] 
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12#section-8.3
> [1] 
> https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb9508
> (in the client in Keycloaks needs to allow http://localhost as valid 
> redirect uri - should rather be http://127.0.0.1)
>
> Cheers,
> Thomas
>
> 2017-07-20 15:23 GMT+02:00 Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>>:
>
>     What's wrong?  The fact you have to cut and paste a code from the
>     browser to the app.
>
>
>     On 7/20/17 9:04 AM, Thomas Darimont wrote:
>>     That's interesting.
>>
>>     Will there also be support for desktop apps in some way?
>>
>>     What in particular do you think is the problem with the approach
>>     used by the keycloak-installed adapter
>>     and OAuth device flow, guessing you mean:
>>     https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06
>>     <https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06> ?
>>
>>     Cheers,
>>     Thomas
>>
>>
>>
>>     2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>>:
>>
>>         I'm working on something for command line apps.  A command-line
>>         text/plain protocol so that login can happen within a
>>         console.  I really
>>         think keycloak-installation or the OAuth device flow is
>>         really poor
>>         solution.
>>
>>
>>         On 7/18/17 9:42 AM, Thomas Darimont wrote:
>>         > Hello folks,
>>         >
>>         > I played a bit with the undocumented? [0]
>>         keycloak-installed adapter [1]
>>         > for integrating
>>         > desktop applications with Keycloak SSO and found some
>>         issues with it, which
>>         > I'd like to share.
>>         > Small explanation for those who are reading the list but
>>         don't know the
>>         > adapter... [2]
>>         >
>>         > First some general notes / suggestions:
>>         > Is the keycloak-installed adapter something that will stay
>>         in keycloak or
>>         > was this just a PoC?
>>         > In the former case I think there are some things that could
>>         be improved or
>>         > extended a bit:
>>         >
>>         > - Allow users to customize the locale used for the login
>>         pages opened by
>>         > the adapter
>>         > - Provide customizable response templates (perhaps by
>>         leveraging a provided
>>         > ResourceBundle)
>>         > - Allow to customize pages shown after login / logout
>>         served by the
>>         > keycloak-installed adapter
>>         > - Add support for TLS (with custom certificates) for
>>         https:// with localhost
>>         >
>>         > I noticed that some browsers (e.g. Chrome) show an error
>>         page when trying
>>         > to
>>         > redirect to the local mini-webserver after a successful
>>         login since the
>>         > mini-webserver
>>         > (...server-socket) embedded in the adapter doesn't respond
>>         with a valid
>>         > HTTP response.
>>         > With that fixed, it worked with all browsers I tested (IE,
>>         Firefox, Chrome).
>>         >
>>         > My current modifications of the keycloak-installed adapter
>>         > (with HTTP response fixes and response customizations) are
>>         here:
>>         >
>>         https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8
>>         <https://github.com/thomasdarimont/keycloak/commit/b8ee52a946e73503b1737f5ca7d4520b8484dae8>
>>         >
>>         > An extended example (using the the modified
>>         keycloak-installed adapter) can
>>         > be found here:
>>         >
>>         https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1
>>         <https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6fbe2c013c5f1>
>>         >
>>         > WDYT?
>>         >
>>         > Cheers,
>>         > Thomas
>>         >
>>         > [0] Not mentioned here:
>>         >
>>         https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html
>>         <https://keycloak.gitbooks.io/documentation/securing_apps/topics/oidc/java/java-adapters.html>
>>         >
>>         > [1]
>>         https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed
>>         <https://github.com/keycloak/keycloak/tree/master/adapters/oidc/installed>
>>         >
>>         > [2] For those that haven't seen the adapter yet, it allows
>>         to authenticate
>>         > against Keycloak
>>         > from a desktop app (e.g. swing, javafx) by opening a
>>         desktop browser window
>>         > where a user
>>         > uses the regular keycloak login pages to login.
>>         > The trick is now that login page is opened with redirect
>>         URL that points to
>>         > a small local
>>         > "web server" (server-socket) on a free ephemeral port which
>>         is started by
>>         > the adapter.
>>         >
>>         > After logging in the mini web-server receives performs the
>>         authenorization
>>         > code flow and eventually receives the tokens (access_token,
>>         refresh_token,
>>         > id_token) which can then be
>>         > used to call backend services from the client or retrieve
>>         new tokens
>>         >
>>         > A nice side effect of this is, that the desktop application
>>         never sees a
>>         > users
>>         > password and one can leverage existing SSO sessions.
>>         > Btw. the google cloud cli uses the same approach to
>>         authenticate with gcp.
>>         >
>>         > The Keycloak repo contains a small example for this:
>>         >
>>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java
>>         <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app-cli/src/main/java/org/keycloak/example/CustomerCli.java>
>>         > _______________________________________________
>>         > 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
>>         <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
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From thomas.darimont at googlemail.com  Thu Jul 20 10:01:48 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 20 Jul 2017 16:01:48 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <3c573644-c9c8-21b3-aa32-9a31439239c5@redhat.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<74b958c9-b7e1-1311-3306-3d4f47f98196@redhat.com>
	<CAK-7U1gBv_7eaMqxx-Qv2+rdwfFen2u9_aCH4N4=n-9Q=pN7EA@mail.gmail.com>
	<91199b0c-6ce1-b884-db54-30814480612d@redhat.com>
	<CAK-7U1jxnNmirNex4rCbNJAonadGjEaBF4hYmqvnTXT+MZGaOw@mail.gmail.com>
	<3c573644-c9c8-21b3-aa32-9a31439239c5@redhat.com>
Message-ID: <CAK-7U1gFQ=yW6TXdR2F3X6FkXS8VuuzZ8cTGt8B1+tqV+z9umA@mail.gmail.com>

I can understand that working with cli-apps are a bit awkward to work with
in the context of OAuth 2.0, but I was specifically talking about desktop
apps ;-)

Cheers,
Thomas

2017-07-20 15:56 GMT+02:00 Bill Burke <bburke at redhat.com>:

> Still crap for command line apps where all you have is a console window.
>
> On 7/20/17 9:41 AM, Thomas Darimont wrote:
>
> Hi Bill,
>
> actually that's not the way it works - there is no manuall copying of the
> auth-code needed
> in the case of desktop apps.
>
> An example gist can be found at [1]
>
> It works as follows:
>
> When a user wants to login via a desktop app (e.g. swing, javafx) a
> desktop browser
> is opened window where a user uses the regular keycloak login pages to
> login.
>
> The trick is now that login page is opened with redirect URL that points
> to a small local
> "web server" (server-socket) on a free ephemeral port listening on
> localhost
> (which should be rather 127.0.0.1 according to [0]) which is started by
> the adapter.
>
> After logging in the mini web-server receives the auth code and performs
> the via the
> redirect uri: localhost:XXXXX and performs the remaioning authorization
> code flow.
>
> The keycloak-installed adapter eventually receives the tokens (access_token,
> refresh_token, id_token)
> which can then be used to call backend services from the client or
> retrieve new tokens.
>
> A nice side effect of this is, that the desktop application never sees a
> users
> password and one can leverage existing SSO sessions.
> Btw. the google cloud cli uses the same approach to authenticate with gcp.
>
> [0] https://tools.ietf.org/html/draft-ietf-oauth-native-
> apps-12#section-8.3
> [1] https://gist.github.com/thomasdarimont/ca16080145d226e50628d5696ffb95
> 08
> (in the client in Keycloaks needs to allow http://localhost as valid
> redirect uri - should rather be http://127.0.0.1)
>
> Cheers,
> Thomas
>
> 2017-07-20 15:23 GMT+02:00 Bill Burke <bburke at redhat.com>:
>
>> What's wrong?  The fact you have to cut and paste a code from the browser
>> to the app.
>>
>> On 7/20/17 9:04 AM, Thomas Darimont wrote:
>>
>> That's interesting.
>>
>> Will there also be support for desktop apps in some way?
>>
>> What in particular do you think is the problem with the approach used by
>> the keycloak-installed adapter
>> and OAuth device flow, guessing you mean: https://tools.ietf.org/html/dr
>> aft-ietf-oauth-device-flow-06 ?
>>
>> Cheers,
>> Thomas
>>
>>
>>
>> 2017-07-19 16:31 GMT+02:00 Bill Burke <bburke at redhat.com>:
>>
>>> I'm working on something for command line apps.  A command-line
>>> text/plain protocol so that login can happen within a console.  I really
>>> think keycloak-installation or the OAuth device flow is really poor
>>> solution.
>>>
>>>
>>> On 7/18/17 9:42 AM, Thomas Darimont wrote:
>>> > Hello folks,
>>> >
>>> > I played a bit with the undocumented? [0] keycloak-installed adapter
>>> [1]
>>> > for integrating
>>> > desktop applications with Keycloak SSO and found some issues with it,
>>> which
>>> > I'd like to share.
>>> > Small explanation for those who are reading the list but don't know the
>>> > adapter... [2]
>>> >
>>> > First some general notes / suggestions:
>>> > Is the keycloak-installed adapter something that will stay in keycloak
>>> or
>>> > was this just a PoC?
>>> > In the former case I think there are some things that could be
>>> improved or
>>> > extended a bit:
>>> >
>>> > - Allow users to customize the locale used for the login pages opened
>>> by
>>> > the adapter
>>> > - Provide customizable response templates (perhaps by leveraging a
>>> provided
>>> > ResourceBundle)
>>> > - Allow to customize pages shown after login / logout served by the
>>> > keycloak-installed adapter
>>> > - Add support for TLS (with custom certificates) for https:// with
>>> localhost
>>> >
>>> > I noticed that some browsers (e.g. Chrome) show an error page when
>>> trying
>>> > to
>>> > redirect to the local mini-webserver after a successful login since the
>>> > mini-webserver
>>> > (...server-socket) embedded in the adapter doesn't respond with a valid
>>> > HTTP response.
>>> > With that fixed, it worked with all browsers I tested (IE, Firefox,
>>> Chrome).
>>> >
>>> > My current modifications of the keycloak-installed adapter
>>> > (with HTTP response fixes and response customizations) are here:
>>> > https://github.com/thomasdarimont/keycloak/commit/b8ee52a946
>>> e73503b1737f5ca7d4520b8484dae8
>>> >
>>> > An extended example (using the the modified keycloak-installed
>>> adapter) can
>>> > be found here:
>>> > https://gist.github.com/thomasdarimont/c59c14f45ea2ee00d7b6f
>>> be2c013c5f1
>>> >
>>> > WDYT?
>>> >
>>> > Cheers,
>>> > Thomas
>>> >
>>> > [0] Not mentioned here:
>>> > https://keycloak.gitbooks.io/documentation/securing_apps/top
>>> ics/oidc/java/java-adapters.html
>>> >
>>> > [1] https://github.com/keycloak/keycloak/tree/master/adapters/oi
>>> dc/installed
>>> >
>>> > [2] For those that haven't seen the adapter yet, it allows to
>>> authenticate
>>> > against Keycloak
>>> > from a desktop app (e.g. swing, javafx) by opening a desktop browser
>>> window
>>> > where a user
>>> > uses the regular keycloak login pages to login.
>>> > The trick is now that login page is opened with redirect URL that
>>> points to
>>> > a small local
>>> > "web server" (server-socket) on a free ephemeral port which is started
>>> by
>>> > the adapter.
>>> >
>>> > After logging in the mini web-server receives performs the
>>> authenorization
>>> > code flow and eventually receives the tokens (access_token,
>>> refresh_token,
>>> > id_token) which can then be
>>> > used to call backend services from the client or retrieve new tokens
>>> >
>>> > A nice side effect of this is, that the desktop application never sees
>>> a
>>> > users
>>> > password and one can leverage existing SSO sessions.
>>> > Btw. the google cloud cli uses the same approach to authenticate with
>>> gcp.
>>> >
>>> > The Keycloak repo contains a small example for this:
>>> > https://github.com/keycloak/keycloak/blob/master/examples/de
>>> mo-template/customer-app-cli/src/main/java/org/keycloak/exam
>>> ple/CustomerCli.java
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>

From ssilvert at redhat.com  Thu Jul 20 13:41:14 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 20 Jul 2017 13:41:14 -0400
Subject: [keycloak-dev] Do we care about reproducible builds?
In-Reply-To: <9c9c15cf-3135-c7a7-b471-e7baddfb926e@redhat.com>
References: <f60a57f4-1790-660e-d8f3-21b43997219a@redhat.com>
	<CAJrcDBd39n5+DtXsyZ5H3ogubof1egTftjQDHHxtCs4zHLRa-w@mail.gmail.com>
	<9c9c15cf-3135-c7a7-b471-e7baddfb926e@redhat.com>
Message-ID: <c2799106-6339-2cc6-d364-2edb5e7205af@redhat.com>

I have a PR pending now that will pull js libraries from the public npm 
repo.   The versions are locked. I'll also include a readme file to let 
you know what to do if you need to add or update a js library.

If I don't hear any objection, we won't worry about strict 
reproducibility for community releases.  We can enhance this later if we 
choose.

On 7/20/2017 8:57 AM, Stan Silvert wrote:
> So to be more clear, a reproducible build means that once we release a
> version of Keycloak we can rebuild and reproduce the exact bits at any time.
>
> To do this perfectly, we must pull in the exact versions of every js
> library we ship.
>
> So the question is, for community builds, should we maintain our own
> archived version of these libraries or can we pull from the public npm repo?
>
> In the public npm repo, library publishers are allowed to modify their
> bits for 24 hours after publishing.  They may also republish at a later
> time via special request, though this is highly discouraged.
>
> So if we don't archive js libraries with each release it is possible,
> though unlikely, that we could end up with a non-reproducible build.
>
> That's why I ask how much we really care about reproducibility in community.
>
> On 7/19/2017 6:10 PM, Pedro Igor Silva wrote:
>> Not sure if we need to worry about our own npm repo but just grab the
>> versions we need from npm during the first install/build. Or are you
>> more worried about introducing vulnerabilities in case (somehow, by
>> passing checksum, i don't know) the version we use is modified ?
>>
>> Regards.
>> Pedro Igor
>>
>> On Wed, Jul 19, 2017 at 3:26 PM, Stan Silvert <ssilvert at redhat.com
>> <mailto:ssilvert at redhat.com>> wrote:
>>
>>      I'm asking this question about the community version of Keycloak.
>>      RH-SSO
>>      absolutely must be reproducible.
>>
>>      The reason I ask is because we will soon stop checking
>>      node_modules into
>>      github.  javascript libraries will be pulled in at build time.
>>
>>      We will lock down the library versions with yarn, which means
>>      everything
>>      is theoretically reproducible as long as the public npm repo is
>>      stable.
>>
>>      But if we want to be extra-sure, we can set up our own npm repo and
>>      archive it with each community release.
>>
>>      WDYT?  How much do we care about reproducible builds in community?
>>
>>      Stan
>>      _______________________________________________
>>      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
>>      <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 hmlnarik at redhat.com  Fri Jul 21 10:03:48 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 21 Jul 2017 16:03:48 +0200
Subject: [keycloak-dev] Travis update to trusty and failing testsuite
Message-ID: <CAMvXD=HTiM8JKz3C6tAasv1NeAgkTQ0JvAU8JUrhL3X-p7R+rw@mail.gmail.com>

Hi,

since Travis updated their images to Ubuntu Trusty, the testsuite
started failing for the server-group1. If you already have any PR
submitted that failed for that reason, please rebase to the current
master to get the tests passing (or at least not failing due to
environment issues). This is tracked as [1]

--Hynek

[1] https://issues.jboss.org/browse/KEYCLOAK-5226

From mposolda at redhat.com  Fri Jul 21 10:35:58 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Jul 2017 16:35:58 +0200
Subject: [keycloak-dev] Keycloak 3.2.1.Final released
Message-ID: <25738390-f2a9-6be2-6b50-02bf14a69a3b@redhat.com>

Keycloak 3.2.1.Final has just been released.

This release doesn't contain any new features. However there are few 
fixed bugs related to authorization services and new permissions for 
admin REST API.

To download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>.

The full list of resolved issues is available in JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%203.2.1.Final>
.
Upgrading

Before you upgrade remember to backup your database and check the migration
guide
<https://keycloak.gitbooks.io/documentation/server_admin/topics/MigrationFromOlderVersions.html>
.


From ssilvert at redhat.com  Fri Jul 21 11:43:11 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Jul 2017 11:43:11 -0400
Subject: [keycloak-dev] PermissionsTest failures
Message-ID: <26a511b2-b605-92f8-036c-5085ee638626@redhat.com>

Lots of failures in Travis.  Anybody know off hand what this is about?

Running org.keycloak.testsuite.admin.PermissionsTest
--------- org.keycloak.testsuite.admin.PermissionsTest output start ---------
PermissionsTest ++ 14:38:01,920 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-8) RESTEASY002005: Failed executing GET /admin/realms/permissions-test/clients-initial-access: org.keycloak.services.ForbiddenException
PermissionsTest ++ 	at org.keycloak.services.resources.admin.permissions.ClientPermissions.requireView(ClientPermissions.java:259)
PermissionsTest ++ 	at org.keycloak.services.resources.admin.ClientInitialAccessResource.list(ClientInitialAccessResource.java:102)
PermissionsTest ++ 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
PermissionsTest ++ 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)


From psilva at redhat.com  Fri Jul 21 12:27:37 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 21 Jul 2017 13:27:37 -0300
Subject: [keycloak-dev] Keycloak, Elytron and WildFly 11
Message-ID: <CAJrcDBceNmjwJudH+zFWxKaNujMJgBa8GKEen_Tid0qe6-wF1Q@mail.gmail.com>

Hi,

Just want to let you know that tests using Elytron 1.1.0.CR3 (just
released) and WildFly/Core upstream are passing. Next version of Elytron is
Final and until there we should not have anymore changes that may impact
our side, including Elytron subsystem changes.

We also have some initial changes to the adapter subsystem. These changes
are important in order to allow users to secure WildFly/EAP Console (HAL),
CLI and Management Interface with Keycloak. More work will be done in order
to make even more easier to protect these resources.

For more details, check https://issues.jboss.org/browse/KEYCLOAK-5015.

Regards.
Pedro Igor

From hmlnarik at redhat.com  Fri Jul 21 14:20:02 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 21 Jul 2017 20:20:02 +0200
Subject: [keycloak-dev] PermissionsTest failures
In-Reply-To: <26a511b2-b605-92f8-036c-5085ee638626@redhat.com>
References: <26a511b2-b605-92f8-036c-5085ee638626@redhat.com>
Message-ID: <CAMvXD=FHLXOk2C7vP2+MGJaWd7SrrG+PuRYKSRyw61uBJRw0sA@mail.gmail.com>

Just wrote about it earlier today (search for Travis update to trusty
and failing testsuite)

On Fri, Jul 21, 2017 at 5:43 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> Lots of failures in Travis.  Anybody know off hand what this is about?
>
> Running org.keycloak.testsuite.admin.PermissionsTest
> --------- org.keycloak.testsuite.admin.PermissionsTest output start ---------
> PermissionsTest ++  [31m14:38:01,920 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-8) RESTEASY002005: Failed executing GET /admin/realms/permissions-test/clients-initial-access: org.keycloak.services.ForbiddenException
> PermissionsTest ++      at org.keycloak.services.resources.admin.permissions.ClientPermissions.requireView(ClientPermissions.java:259)
> PermissionsTest ++      at org.keycloak.services.resources.admin.ClientInitialAccessResource.list(ClientInitialAccessResource.java:102)
> PermissionsTest ++      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> PermissionsTest ++      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 

--Hynek

From ssilvert at redhat.com  Fri Jul 21 15:14:08 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Jul 2017 15:14:08 -0400
Subject: [keycloak-dev] PermissionsTest failures
In-Reply-To: <CAMvXD=FHLXOk2C7vP2+MGJaWd7SrrG+PuRYKSRyw61uBJRw0sA@mail.gmail.com>
References: <26a511b2-b605-92f8-036c-5085ee638626@redhat.com>
	<CAMvXD=FHLXOk2C7vP2+MGJaWd7SrrG+PuRYKSRyw61uBJRw0sA@mail.gmail.com>
Message-ID: <7e2b359f-bc27-d4de-a87f-e7c9b7e9618b@redhat.com>

Thanks.  Not sure how I missed that, but it worked.

For anyone else who missed it, you just need to rebase from master and 
re-push.

On 7/21/2017 2:20 PM, Hynek Mlnarik wrote:
> Just wrote about it earlier today (search for Travis update to trusty
> and failing testsuite)
>
> On Fri, Jul 21, 2017 at 5:43 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>> Lots of failures in Travis.  Anybody know off hand what this is about?
>>
>> Running org.keycloak.testsuite.admin.PermissionsTest
>> --------- org.keycloak.testsuite.admin.PermissionsTest output start ---------
>> PermissionsTest ++  [31m14:38:01,920 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-8) RESTEASY002005: Failed executing GET /admin/realms/permissions-test/clients-initial-access: org.keycloak.services.ForbiddenException
>> PermissionsTest ++      at org.keycloak.services.resources.admin.permissions.ClientPermissions.requireView(ClientPermissions.java:259)
>> PermissionsTest ++      at org.keycloak.services.resources.admin.ClientInitialAccessResource.list(ClientInitialAccessResource.java:102)
>> PermissionsTest ++      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> PermissionsTest ++      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From ssilvert at redhat.com  Fri Jul 21 15:19:32 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Jul 2017 15:19:32 -0400
Subject: [keycloak-dev] javascript no longer in GitHub
Message-ID: <976cc22a-d105-edd1-1db2-ab9892144c6d@redhat.com>

FYI.  Most javascript libraries used in the admin console are no longer 
checked into GitHub.  Instead, they are pulled in at build time from the 
public npm repo and cached on your local machine just like with Maven 
artifacts.

If you need to add/update/remove a javascript library for the console, 
see the README.md here:
https://github.com/keycloak/keycloak/tree/master/themes/src/main/resources/theme/keycloak/common/resources


From darran.lofthouse at jboss.com  Mon Jul 24 04:03:41 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 24 Jul 2017 08:03:41 +0000
Subject: [keycloak-dev] Keycloak, Elytron and WildFly 11
In-Reply-To: <CAJrcDBceNmjwJudH+zFWxKaNujMJgBa8GKEen_Tid0qe6-wF1Q@mail.gmail.com>
References: <CAJrcDBceNmjwJudH+zFWxKaNujMJgBa8GKEen_Tid0qe6-wF1Q@mail.gmail.com>
Message-ID: <CAMxVf4ODNHGoung86qiCBUqvQxtFj2Fjdb2BT1TiOEVYKttG2A@mail.gmail.com>

Just to clarify on the Elytron tag, we will be tagging Final in a few weeks
time so late August.

In the meantime if any engineers are working on fixes that need an updated
Elytron tag in either WildFly Core or WildFly I may need to tag another
intermediate CR that they can use.

Regards,
Darran Lofthouse.


On Fri, 21 Jul 2017 at 19:33 Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi,
>
> Just want to let you know that tests using Elytron 1.1.0.CR3 (just
> released) and WildFly/Core upstream are passing. Next version of Elytron is
> Final and until there we should not have anymore changes that may impact
> our side, including Elytron subsystem changes.
>
> We also have some initial changes to the adapter subsystem. These changes
> are important in order to allow users to secure WildFly/EAP Console (HAL),
> CLI and Management Interface with Keycloak. More work will be done in order
> to make even more easier to protect these resources.
>
> For more details, check https://issues.jboss.org/browse/KEYCLOAK-5015.
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Jul 24 18:21:54 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 24 Jul 2017 18:21:54 -0400
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
Message-ID: <de426858-4dc2-34e0-629e-566623699ce6@redhat.com>



On 7/18/17 9:42 AM, Thomas Darimont wrote:
> - Add support for TLS (with custom certificates) for https:// with localhost

Hey, I'm incorporating your changes, but one question I have is why do 
you need this?

Bill

From thomas.darimont at googlemail.com  Tue Jul 25 03:52:45 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 25 Jul 2017 09:52:45 +0200
Subject: [keycloak-dev] Authenticating Desktop Applications with
 Keycloak and the keycloak-installed adapter
In-Reply-To: <de426858-4dc2-34e0-629e-566623699ce6@redhat.com>
References: <CAK-7U1i8MMEM8Dh7DLgh5njN38rSJ5NFc30EdDXCgJFHWkmz9A@mail.gmail.com>
	<de426858-4dc2-34e0-629e-566623699ce6@redhat.com>
Message-ID: <CAK-7U1ju6zuyVD8A-i101U_i0FRKzJFJgGR6a8NVi-9p8D6rYA@mail.gmail.com>

Hi Bill,

that's nice to hear!
Is there already a JIRA issue for that? May I open a pull request and you
take it from there?

I think the TLS feature was a bit over ambitious - so never mind. The idea
was to optionally allow using
https for connections to 127.0.0.1 + allowing users to pass-in a custom
cert / trust store.

Note that using 127.0.0.1 instead of localhost might cause some
compatibility problems and should be mentioned in the migration guide.
E.g. users who already use the keycloak-installed adapter probably need to
adapt the allowed redirect
uri pattern in the client configuration in Keycloak (127.0.0.1 instead of
localhost).

Cheers,
Thomas

2017-07-25 0:21 GMT+02:00 Bill Burke <bburke at redhat.com>:

>
>
> On 7/18/17 9:42 AM, Thomas Darimont wrote:
> > - Add support for TLS (with custom certificates) for https:// with
> localhost
>
> Hey, I'm incorporating your changes, but one question I have is why do
> you need this?
>
> Bill
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From adobbels at bottomline.com  Tue Jul 25 04:21:39 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Tue, 25 Jul 2017 08:21:39 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <B36F75FE9807FF41BC172237E5DA720F66AA22B2@US02VWMX0001.us-bottomline.root.bottomline.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA22B2@US02VWMX0001.us-bottomline.root.bottomline.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA43CD@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi,

Did anyone have any thoughts on how to progress this?

thanks,

Andy

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Dobbels, Andy
Sent: 19 July 2017 09:38
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Hi Bill, 

Could you give me a link to any of the undocumented SPI's for custom storage of secrets? I'll start with that first if that should fix my issue in the short term.

Stian, is there any work underway to denormalize OTP policy to allow over time migration of OTP secrets and parameters similar to passwords? Is there agreement that that's the way forward?
What's involved in that? We might be able to put a PR together depending on effort and complexity involved.

Thanks,

Andy

-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 14 July 2017 16:14
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

Our secrets are a string and the bytes of the string are converted to 
base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See 
the difference?


On 7/14/17 12:14 AM, Stian Thorgersen wrote:
> The OTP strings we have today are already encoded with Base32 as the 
> OTP specs mandates [1] so I don't really understand what this whole 
> thread is about.
>
> [1]
> https://github.com/keycloak/keycloak/blob/master/services/src/main/jav
> a/org/keycloak/utils/TotpUtils.java
>
> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>
>> Hi Bill,
>>
>> Thanks for the response and sorry for the double post.
>>
>> My main concern is interoperability and not being able to import the 
>> secrets from existing OTP solutions even though they are all based on 
>> the same RFC. Creating an SPI to allow the secret to be stored as a
>> Base32 string instead of plain text doesn't seem right. The rest of 
>> the code is fine and it's all there. If you don't mind I would like 
>> to explore a few options that don't require an update of all existing credentials.
>>
>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>> That way we can keep the existing data as is. If the prefix isn't 
>> there then it's plain text.
>> or
>> 2: Add a column that indicates what format the credentials.value 
>> property is encoded in. Values could be Plain or Base32. Someone 
>> could easily add
>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps 
>> later on this could open the door to encrypting the secret by having 
>> a value called "encrypted".
>>
>> Perhaps there are other options?
>> Is the undocumented SPI purely dealing with how the value is encoded?
>>
>> Thanks,
>>
>> Andy
>>
>>
>> -----Original Message-----
>> From: keycloak-dev-bounces at lists.jboss.org
>> [mailto:keycloak-dev-bounces@ lists.jboss.org] On Behalf Of Bill 
>> Burke
>> Sent: 12 July 2017 23:16
>> To: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] OTP string based secrets
>>
>>
>>
>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>> Hi,
>>>
>>> We are adopting Keycloak and are trying to move our OTP tokens over 
>>> to
>> Keycloak. However, Keycloak can only use secrets that are 
>> alphanumeric strings whereas our existing implementation and most 
>> hard and software tokens we have used use the full range of binary 
>> values when generating secrets.
>>
>>> 2 questions:
>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>> Should it be a concern?  Its currently a randomly generated 20 
>> character alpha-numeric string.  That's not enough entropy?
>>
>>
>>> 2: If we provided a PR that migrated the existing data by 
>>> re-encoding
>> all existing secrets as Base32 and updated the code to assume Base32 
>> instead of string be acceptable?
>>> This would be a non breaking change but allow anyone using existing 
>>> OTP
>> tokens to migrate their secrets which I don't think they can at the moment.
>> We have undocumented SPIs to support other storage options for 
>> different credential types.  If you want to use the data model that's 
>> currently there you have to encode your secrets as strings. We're 
>> limited in the fact that our current OTP storage must be backward 
>> compatible.  Also, don't want to have to recalculate storage for 
>> every single OTP record of existing deployments when migrating.
>>
>> We could though absolutely change how future secrets are generated if 
>> you feel the entropy is a concern.
>>
>> Bill
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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


From hmlnarik at redhat.com  Tue Jul 25 09:30:51 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 25 Jul 2017 15:30:51 +0200
Subject: [keycloak-dev] Dutch translation
Message-ID: <CAMvXD=FwQNNF+d4x=uNLCiuMsQ6BJ+qrui7sZs4WOinrAkhpkg@mail.gmail.com>

Can someone please review Dutch translation in PR
https://github.com/keycloak/keycloak/pull/4340?

--Hynek

From bburke at redhat.com  Tue Jul 25 12:49:40 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 25 Jul 2017 12:49:40 -0400
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <B36F75FE9807FF41BC172237E5DA720F66AA43CD@US02VWMX0001.us-bottomline.root.bottomline.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA22B2@US02VWMX0001.us-bottomline.root.bottomline.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA43CD@US02VWMX0001.us-bottomline.root.bottomline.com>
Message-ID: <c1c4517e-dbb2-025f-c299-064bbde3c8f1@redhat.com>

I just don't have the time to fully document this although its on my 
long growing todo list.  My suggestion is to walk through how the 
authenticators work for password validation and otp validation and 
derive things from there.  I'm pretty sure and hopeful that the current 
SPIs that exist are good enough.  Just not sure yet which is why they 
aren't documented, public, or have quickstarts or examples.


On 7/25/17 4:21 AM, Dobbels, Andy wrote:
> Hi,
>
> Did anyone have any thoughts on how to progress this?
>
> thanks,
>
> Andy
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Dobbels, Andy
> Sent: 19 July 2017 09:38
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
> Hi Bill,
>
> Could you give me a link to any of the undocumented SPI's for custom storage of secrets? I'll start with that first if that should fix my issue in the short term.
>
> Stian, is there any work underway to denormalize OTP policy to allow over time migration of OTP secrets and parameters similar to passwords? Is there agreement that that's the way forward?
> What's involved in that? We might be able to put a PR together depending on effort and complexity involved.
>
> Thanks,
>
> Andy
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
> Sent: 14 July 2017 16:14
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
> Our secrets are a string and the bytes of the string are converted to
> base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See
> the difference?
>
>
> On 7/14/17 12:14 AM, Stian Thorgersen wrote:
>> The OTP strings we have today are already encoded with Base32 as the
>> OTP specs mandates [1] so I don't really understand what this whole
>> thread is about.
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/jav
>> a/org/keycloak/utils/TotpUtils.java
>>
>> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>>
>>> Hi Bill,
>>>
>>> Thanks for the response and sorry for the double post.
>>>
>>> My main concern is interoperability and not being able to import the
>>> secrets from existing OTP solutions even though they are all based on
>>> the same RFC. Creating an SPI to allow the secret to be stored as a
>>> Base32 string instead of plain text doesn't seem right. The rest of
>>> the code is fine and it's all there. If you don't mind I would like
>>> to explore a few options that don't require an update of all existing credentials.
>>>
>>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>>> That way we can keep the existing data as is. If the prefix isn't
>>> there then it's plain text.
>>> or
>>> 2: Add a column that indicates what format the credentials.value
>>> property is encoded in. Values could be Plain or Base32. Someone
>>> could easily add
>>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps
>>> later on this could open the door to encrypting the secret by having
>>> a value called "encrypted".
>>>
>>> Perhaps there are other options?
>>> Is the undocumented SPI purely dealing with how the value is encoded?
>>>
>>> Thanks,
>>>
>>> Andy
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces@ lists.jboss.org] On Behalf Of Bill
>>> Burke
>>> Sent: 12 July 2017 23:16
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] OTP string based secrets
>>>
>>>
>>>
>>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>>> Hi,
>>>>
>>>> We are adopting Keycloak and are trying to move our OTP tokens over
>>>> to
>>> Keycloak. However, Keycloak can only use secrets that are
>>> alphanumeric strings whereas our existing implementation and most
>>> hard and software tokens we have used use the full range of binary
>>> values when generating secrets.
>>>
>>>> 2 questions:
>>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>>> Should it be a concern?  Its currently a randomly generated 20
>>> character alpha-numeric string.  That's not enough entropy?
>>>
>>>
>>>> 2: If we provided a PR that migrated the existing data by
>>>> re-encoding
>>> all existing secrets as Base32 and updated the code to assume Base32
>>> instead of string be acceptable?
>>>> This would be a non breaking change but allow anyone using existing
>>>> OTP
>>> tokens to migrate their secrets which I don't think they can at the moment.
>>> We have undocumented SPIs to support other storage options for
>>> different credential types.  If you want to use the data model that's
>>> currently there you have to encode your secrets as strings. We're
>>> limited in the fact that our current OTP storage must be backward
>>> compatible.  Also, don't want to have to recalculate storage for
>>> every single OTP record of existing deployments when migrating.
>>>
>>> We could though absolutely change how future secrets are generated if
>>> you feel the entropy is a concern.
>>>
>>> Bill
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From adobbels at bottomline.com  Tue Jul 25 14:58:43 2017
From: adobbels at bottomline.com (Dobbels, Andy)
Date: Tue, 25 Jul 2017 18:58:43 +0000
Subject: [keycloak-dev] OTP string based secrets
In-Reply-To: <c1c4517e-dbb2-025f-c299-064bbde3c8f1@redhat.com>
References: <B36F75FE9807FF41BC172237E5DA720F66AA0219@US02VWMX0001.us-bottomline.root.bottomline.com>
	<0cfb4e35-f575-06cf-059f-395f82ce23aa@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA072E@US02VWMX0001.us-bottomline.root.bottomline.com>
	<CAJgngAeiASbgTH6PRLg7AKR9q6UsoSUkB7+QOUrwgYOoBMcShA@mail.gmail.com>
	<f6a57f1d-2279-b538-e247-64ad7861682f@redhat.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA22B2@US02VWMX0001.us-bottomline.root.bottomline.com>
	<B36F75FE9807FF41BC172237E5DA720F66AA43CD@US02VWMX0001.us-bottomline.root.bottomline.com>
	<c1c4517e-dbb2-025f-c299-064bbde3c8f1@redhat.com>
Message-ID: <B36F75FE9807FF41BC172237E5DA720F66AA4CE0@US02VWMX0001.us-bottomline.root.bottomline.com>

Hi Bill,

Thanks getting back to me. I appreciate your time constraints.
We'll make our way through the code and see what we can come up with.

Thanks,

Andy


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: 25 July 2017 17:50
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] OTP string based secrets

I just don't have the time to fully document this although its on my long growing todo list.  My suggestion is to walk through how the authenticators work for password validation and otp validation and derive things from there.  I'm pretty sure and hopeful that the current SPIs that exist are good enough.  Just not sure yet which is why they aren't documented, public, or have quickstarts or examples.


On 7/25/17 4:21 AM, Dobbels, Andy wrote:
> Hi,
>
> Did anyone have any thoughts on how to progress this?
>
> thanks,
>
> Andy
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Dobbels, 
> Andy
> Sent: 19 July 2017 09:38
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
> Hi Bill,
>
> Could you give me a link to any of the undocumented SPI's for custom storage of secrets? I'll start with that first if that should fix my issue in the short term.
>
> Stian, is there any work underway to denormalize OTP policy to allow over time migration of OTP secrets and parameters similar to passwords? Is there agreement that that's the way forward?
> What's involved in that? We might be able to put a PR together depending on effort and complexity involved.
>
> Thanks,
>
> Andy
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
> Sent: 14 July 2017 16:14
> To: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] OTP string based secrets
>
> Our secrets are a string and the bytes of the string are converted to
> base32.   Andy Dobbels uses keys that are raw bytes, not strings.  See
> the difference?
>
>
> On 7/14/17 12:14 AM, Stian Thorgersen wrote:
>> The OTP strings we have today are already encoded with Base32 as the 
>> OTP specs mandates [1] so I don't really understand what this whole 
>> thread is about.
>>
>> [1]
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/ja
>> v
>> a/org/keycloak/utils/TotpUtils.java
>>
>> On 13 July 2017 at 17:17, Dobbels, Andy <adobbels at bottomline.com> wrote:
>>
>>> Hi Bill,
>>>
>>> Thanks for the response and sorry for the double post.
>>>
>>> My main concern is interoperability and not being able to import the 
>>> secrets from existing OTP solutions even though they are all based 
>>> on the same RFC. Creating an SPI to allow the secret to be stored as 
>>> a
>>> Base32 string instead of plain text doesn't seem right. The rest of 
>>> the code is fine and it's all there. If you don't mind I would like 
>>> to explore a few options that don't require an update of all existing credentials.
>>>
>>> 1: Prefix the Base32 strings with an identifier. E.g. "Base32:{secret}"
>>> That way we can keep the existing data as is. If the prefix isn't 
>>> there then it's plain text.
>>> or
>>> 2: Add a column that indicates what format the credentials.value 
>>> property is encoded in. Values could be Plain or Base32. Someone 
>>> could easily add
>>> Base64 or Hex if that helps their adoption/migration of otp. Perhaps 
>>> later on this could open the door to encrypting the secret by having 
>>> a value called "encrypted".
>>>
>>> Perhaps there are other options?
>>> Is the undocumented SPI purely dealing with how the value is encoded?
>>>
>>> Thanks,
>>>
>>> Andy
>>>
>>>
>>> -----Original Message-----
>>> From: keycloak-dev-bounces at lists.jboss.org
>>> [mailto:keycloak-dev-bounces@ lists.jboss.org] On Behalf Of Bill 
>>> Burke
>>> Sent: 12 July 2017 23:16
>>> To: keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] OTP string based secrets
>>>
>>>
>>>
>>> On 7/12/17 1:39 PM, Dobbels, Andy wrote:
>>>> Hi,
>>>>
>>>> We are adopting Keycloak and are trying to move our OTP tokens over 
>>>> to
>>> Keycloak. However, Keycloak can only use secrets that are 
>>> alphanumeric strings whereas our existing implementation and most 
>>> hard and software tokens we have used use the full range of binary 
>>> values when generating secrets.
>>>
>>>> 2 questions:
>>>> 1: Is the lower entropy of the secrets generated by Keycloak a concern?
>>> Should it be a concern?  Its currently a randomly generated 20 
>>> character alpha-numeric string.  That's not enough entropy?
>>>
>>>
>>>> 2: If we provided a PR that migrated the existing data by 
>>>> re-encoding
>>> all existing secrets as Base32 and updated the code to assume Base32 
>>> instead of string be acceptable?
>>>> This would be a non breaking change but allow anyone using existing 
>>>> OTP
>>> tokens to migrate their secrets which I don't think they can at the moment.
>>> We have undocumented SPIs to support other storage options for 
>>> different credential types.  If you want to use the data model 
>>> that's currently there you have to encode your secrets as strings. 
>>> We're limited in the fact that our current OTP storage must be 
>>> backward compatible.  Also, don't want to have to recalculate 
>>> storage for every single OTP record of existing deployments when migrating.
>>>
>>> We could though absolutely change how future secrets are generated 
>>> if you feel the entropy is a concern.
>>>
>>> Bill
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From mposolda at redhat.com  Thu Jul 27 08:25:21 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 27 Jul 2017 14:25:21 +0200
Subject: [keycloak-dev] UserSessions support for cross-dc
Message-ID: <5be07d37-7bd9-5302-581c-114b731a131b@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/4357 for subject. 
It adds cross-dc support for userSessions, so that if you write 
userSession "abc" in DC1, you will be able to read it in DC2 and viceversa.

Among cross-dc, it also provides the solution for lost updates (write 
skew) issues where 2 threads on different cluster nodes (or in different 
data-centers) updates same userSession. They both read the userSession 
in same state and then both update it, but 2nd update will overwrite the 
1st one, which was committed first. I've used the pattern based on 
tracking changes (events) and infinispan atomic-replace operation 
described in the earlier mail: 
http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009347.html

So there was some refactoring of InfinispanUserSessionProvider to 
support the event-based approach. One difference from the previous 
proposal was, that events are not sent between data-centers but instead 
userSession entities are directly written to remoteCache itself - 
however the writes are still protected to avoid write skew issues. The 
reason is, that with multiple datacenters, it can happen that 
datacenters lost the network connection between each other (split 
brain). Infinispan has some ways to restore from this state and sync the 
entities after network connection is fixed. With the entities directly 
in the cache, this should be easier to achieve then the case when the 
remoteCache is used just as an event bus to send "changes" among 
datacenters.

There is still lots of work for the cross-dc support, but hopefully it's 
another step forward :)

Marek


From bburke at redhat.com  Thu Jul 27 13:10:58 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 27 Jul 2017 13:10:58 -0400
Subject: [keycloak-dev] UserSessions support for cross-dc
In-Reply-To: <5be07d37-7bd9-5302-581c-114b731a131b@redhat.com>
References: <5be07d37-7bd9-5302-581c-114b731a131b@redhat.com>
Message-ID: <880b96ef-59b3-47a1-e4df-ee664e281324@redhat.com>

Don't want to create more work for us, but, wouldn't this UserSession 
cross-DC approach be applicable to any http session data?  Maybe its an 
approach that should be ported to generically work in Wildfly for all 
servlet-based apps.


On 7/27/17 8:25 AM, Marek Posolda wrote:
> I've sent PR https://github.com/keycloak/keycloak/pull/4357 for subject.
> It adds cross-dc support for userSessions, so that if you write
> userSession "abc" in DC1, you will be able to read it in DC2 and viceversa.
>
> Among cross-dc, it also provides the solution for lost updates (write
> skew) issues where 2 threads on different cluster nodes (or in different
> data-centers) updates same userSession. They both read the userSession
> in same state and then both update it, but 2nd update will overwrite the
> 1st one, which was committed first. I've used the pattern based on
> tracking changes (events) and infinispan atomic-replace operation
> described in the earlier mail:
> http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009347.html
>
> So there was some refactoring of InfinispanUserSessionProvider to
> support the event-based approach. One difference from the previous
> proposal was, that events are not sent between data-centers but instead
> userSession entities are directly written to remoteCache itself -
> however the writes are still protected to avoid write skew issues. The
> reason is, that with multiple datacenters, it can happen that
> datacenters lost the network connection between each other (split
> brain). Infinispan has some ways to restore from this state and sync the
> entities after network connection is fixed. With the entities directly
> in the cache, this should be easier to achieve then the case when the
> remoteCache is used just as an event bus to send "changes" among
> datacenters.
>
> There is still lots of work for the cross-dc support, but hopefully it's
> another step forward :)
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Fri Jul 28 09:40:00 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 28 Jul 2017 15:40:00 +0200
Subject: [keycloak-dev] UserSessions support for cross-dc
In-Reply-To: <880b96ef-59b3-47a1-e4df-ee664e281324@redhat.com>
References: <5be07d37-7bd9-5302-581c-114b731a131b@redhat.com>
	<880b96ef-59b3-47a1-e4df-ee664e281324@redhat.com>
Message-ID: <882181aa-57d5-4b90-0cd2-5da429c48e8f@redhat.com>

Hmm, maybe yes. I don't know.

The question is, if they have same requirements like us? We have lots of 
backchannel requests, so we want to support the usecase, when same 
userSession is read and concurrently updated from multiple datacenters 
without the risk of write skews (lost updates).

Wildfly can probably rely much more on sticky sessions. I've checked 
that they have the documented option to add remoteStore to the 
infinispan cache. This is useful if they have sticky sessions and 2nd 
datacenter is used just as a backup in case that 1st datacenter becomes 
unavailable. It doesn't provide same level of consistency like us 
(prevention of write skews when concurrent update from both DCs happen), 
but likely sufficient with sticky sessions.

Hopefully we can also have an option to relax on consistency in favor of 
performance, once we will have sticky session support for backchannel 
requests...

Marek

On 27/07/17 19:10, Bill Burke wrote:
> Don't want to create more work for us, but, wouldn't this UserSession
> cross-DC approach be applicable to any http session data?  Maybe its an
> approach that should be ported to generically work in Wildfly for all
> servlet-based apps.
>
>
> On 7/27/17 8:25 AM, Marek Posolda wrote:
>> I've sent PR https://github.com/keycloak/keycloak/pull/4357 for subject.
>> It adds cross-dc support for userSessions, so that if you write
>> userSession "abc" in DC1, you will be able to read it in DC2 and viceversa.
>>
>> Among cross-dc, it also provides the solution for lost updates (write
>> skew) issues where 2 threads on different cluster nodes (or in different
>> data-centers) updates same userSession. They both read the userSession
>> in same state and then both update it, but 2nd update will overwrite the
>> 1st one, which was committed first. I've used the pattern based on
>> tracking changes (events) and infinispan atomic-replace operation
>> described in the earlier mail:
>> http://lists.jboss.org/pipermail/keycloak-dev/2017-May/009347.html
>>
>> So there was some refactoring of InfinispanUserSessionProvider to
>> support the event-based approach. One difference from the previous
>> proposal was, that events are not sent between data-centers but instead
>> userSession entities are directly written to remoteCache itself -
>> however the writes are still protected to avoid write skew issues. The
>> reason is, that with multiple datacenters, it can happen that
>> datacenters lost the network connection between each other (split
>> brain). Infinispan has some ways to restore from this state and sync the
>> entities after network connection is fixed. With the entities directly
>> in the cache, this should be easier to achieve then the case when the
>> remoteCache is used just as an event bus to send "changes" among
>> datacenters.
>>
>> There is still lots of work for the cross-dc support, but hopefully it's
>> another step forward :)
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From thomas.darimont at googlemail.com  Fri Jul 28 11:48:05 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 28 Jul 2017 17:48:05 +0200
Subject: [keycloak-dev] Blacklist Password Policy
Message-ID: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>

Hello,

I build a configurable Password Policy that allows to match a given
password against
a blacklist with easy to guess passwords that should be not allowed as user
passwords.

The 'BlacklistPasswordPolicyProvider' can be configured via the admin UI
with a ";" delimited list of easy to guess passwords.

If the user / or admin want's to change the password it is checked against
the blacklist.
A password list can be found here:
https://github.com/danielmiessler/SecLists/tree/master/Passwords

A blacklist is of course not a perfect solution but could still be useful
for some users.

Password blacklist would be compiled to a trie at startup (and on changes
of the blacklist)
for efficient lookups.

WDYT?

Cheers,
Thomas

From thomas.darimont at googlemail.com  Fri Jul 28 14:52:33 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 28 Jul 2017 20:52:33 +0200
Subject: [keycloak-dev] Blacklist Password Policy
In-Reply-To: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>
References: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>
Message-ID: <CAK-7U1jfSLcYbYgWPvWhmTGcC6Sv+ny3s2UettLsYcUONA0bDw@mail.gmail.com>

Hello,

just realized that I cannot store large strings as the value for the
password policy since
all password policy configurations are stored as a concatenated string in
the
password_policy column of the realm table which has a maximum capacity of
2550 characters :-/

Values look like:
"hashIterations and passwordHistory and passwordBlacklist(bubu;foo;bar;baz)"

One could change the column type to "text" which is "not limited" but I
think it would be
better to use something else for storing such values - the component_config
table perhaps?

Thoughts?

Thomas

2017-07-28 17:48 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello,
>
> I build a configurable Password Policy that allows to match a given
> password against
> a blacklist with easy to guess passwords that should be not allowed as
> user passwords.
>
> The 'BlacklistPasswordPolicyProvider' can be configured via the admin UI
> with a ";" delimited list of easy to guess passwords.
>
> If the user / or admin want's to change the password it is checked against
> the blacklist.
> A password list can be found here:
> https://github.com/danielmiessler/SecLists/tree/master/Passwords
>
> A blacklist is of course not a perfect solution but could still be useful
> for some users.
>
> Password blacklist would be compiled to a trie at startup (and on changes
> of the blacklist)
> for efficient lookups.
>
> WDYT?
>
> Cheers,
> Thomas
>

From bburke at redhat.com  Fri Jul 28 16:03:12 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Jul 2017 16:03:12 -0400
Subject: [keycloak-dev] Blacklist Password Policy
In-Reply-To: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>
References: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>
Message-ID: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com>

Yah, that sounds cool.


On 7/28/17 11:48 AM, Thomas Darimont wrote:
> Hello,
>
> I build a configurable Password Policy that allows to match a given
> password against
> a blacklist with easy to guess passwords that should be not allowed as user
> passwords.
>
> The 'BlacklistPasswordPolicyProvider' can be configured via the admin UI
> with a ";" delimited list of easy to guess passwords.
>
> If the user / or admin want's to change the password it is checked against
> the blacklist.
> A password list can be found here:
> https://github.com/danielmiessler/SecLists/tree/master/Passwords
>
> A blacklist is of course not a perfect solution but could still be useful
> for some users.
>
> Password blacklist would be compiled to a trie at startup (and on changes
> of the blacklist)
> for efficient lookups.
>
> WDYT?
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Jul 28 16:24:45 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Jul 2017 16:24:45 -0400
Subject: [keycloak-dev] token exchange
Message-ID: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com>

I've implemented a simple token exchange API [1] that allows you to 
exchange an access token created for one client to another client.  The 
REST API follows the oauth token exchange api [2] very loosely.

subject_token: a keycloak access token

audience: takes a client id

It then converts the access token created for one client and converts it 
to another.  It lives under the token endpoint.

The security model is as follows:

* Authenticate calling client the same way as password grant.

* The calling client must have service account enabled

* Service account must have a realm role "token-exchanger" grant edto it 
or, it must have a client role "token-exchanger" granted to it.  This 
exchanger client role is a role defined by the target client you are 
exchanging the token to.


Is this a good security model?  I'm thinking of not creating these roles 
right now and to enable support for exchange would require defining the 
roles specified above.


Future work would be to have an additional subject_issuer and 
requested_issuer parameters.  "subject_issuer" would match to a broker 
alias, so you could exchange a facebook token for a keycloak realm 
token.  Same thing goes for "requested_issuer". This would allow you to 
exchange a Keycloak token for a facebook token or some other registered 
broker.


[1] https://github.com/keycloak/keycloak/pull/4362

[2] http://www.ietf.org/id/draft-ietf-oauth-token-exchange-09.txt




From bburke at redhat.com  Fri Jul 28 16:36:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Jul 2017 16:36:49 -0400
Subject: [keycloak-dev] generic cli sso utility
Message-ID: <c44c5df8-8408-b26e-9553-70da7e366c4b@redhat.com>

I've developed a small command line utility around Keycloak Installed.  
The idea is that this utility performs a login with keycloak to obtain 
an access token.  This utility saves the access and refresh token in a 
file (similar to how ssh does in .ssh). Then bash scripts can be used to 
export the access token as an environment variable so it can be used by 
other command line utilities.


https://github.com/patriot1burke/keycloak/blob/master/adapters/oidc/installed/src/main/java/org/keycloak/adapters/installed/KeycloakCliSso.java

https://github.com/patriot1burke/keycloak/tree/master/adapters/oidc/cli-sso


Eventually I'm thinking of creating a text/plain protocol with Keycloak 
server so that launching a browser or cutting/pasting between the 
command line window and browser isn't a requirement. It woudl be a plain 
text challenge response protocol.  This would require a bit more work as 
it would require reworking all of our built in authenticators and 
required action plugins.


From thomas.darimont at googlemail.com  Sat Jul 29 04:06:42 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 29 Jul 2017 10:06:42 +0200
Subject: [keycloak-dev] Blacklist Password Policy
In-Reply-To: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com>
References: <CAK-7U1h2SuVFd-PcUXNPCVg1byW2mX6yEUggqpJqJd9HJLAYLQ@mail.gmail.com>
	<337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com>
Message-ID: <CAK-7U1hoPNOqpz4yMiFfaVdg-nSxYGnydTQMYJvS7MbkRyGBtQ@mail.gmail.com>

Okay cool.

Instead of storing the password blacklist in the database I could instead
just refer to a password
blacklist that lives on the file system.

So Keycloak could ship with some of the lists from [0] and refer to those
with a name like "default-blacklist1000", "default-blacklist-100000"
in the BlacklistPasswordPolicy
config
within the admin-console.

The "default-blacklist-100000" blacklist would then be mapped and resolve
to
something like
"META-INF/password-blacklist/10_million_password_list_top_100000.txt".

Users could provide their own blacklists with the provider config stored in
standalone.xml
than could then be adjusted via jboss-cli.

I think this filesystem based approach is better than having to load and
store big text-blobs in the database.

Cheers,
Thomas

[0] https://github.com/danielmiessler/SecLists/tree/master/Passwords
Using those password lists seems to be allowed according to their license:
https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project
which is Creative Commons Attribution ShareAlike 3.0 License
-> IANAL but it seems to be useable in commercial products as well
https://creativecommons.org/licenses/by-sa/3.0/
as long as the authors are mentioned.


2017-07-28 22:03 GMT+02:00 Bill Burke <bburke at redhat.com>:

> Yah, that sounds cool.
>
>
> On 7/28/17 11:48 AM, Thomas Darimont wrote:
> > Hello,
> >
> > I build a configurable Password Policy that allows to match a given
> > password against
> > a blacklist with easy to guess passwords that should be not allowed as
> user
> > passwords.
> >
> > The 'BlacklistPasswordPolicyProvider' can be configured via the admin UI
> > with a ";" delimited list of easy to guess passwords.
> >
> > If the user / or admin want's to change the password it is checked
> against
> > the blacklist.
> > A password list can be found here:
> > https://github.com/danielmiessler/SecLists/tree/master/Passwords
> >
> > A blacklist is of course not a perfect solution but could still be useful
> > for some users.
> >
> > Password blacklist would be compiled to a trie at startup (and on changes
> > of the blacklist)
> > for efficient lookups.
> >
> > WDYT?
> >
> > Cheers,
> > Thomas
> > _______________________________________________
> > 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 takashi.norimatsu.ws at hitachi.com  Mon Jul 31 00:09:17 2017
From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=)
Date: Mon, 31 Jul 2017 04:09:17 +0000
Subject: [keycloak-dev] Proposal of using existing authentication and
 authorization server on behalf of keycloak browser-based authentication
Message-ID: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net>

Hello.

Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature.

I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent
https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent
It can delegate not only authentication but authorization(consent).

Kindly review it and provide us some comment and advices. 
We would like to contribute this feature onto keycloak.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

---
From: Stian Thorgersen [mailto:sthorger at redhat.com] 
Sent: Thursday, June 29, 2017 6:23 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication

There's an SPI to implement your own custom identity brokering provider [1].

[1]?https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java

On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP,
in order to integrate existing authentication system.
(some commercial products supports such the case)

I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2.
https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html

Therefore, I realized it by using redirect based authentication flows.

Can identity Brokering can support such the case?

Aside from this, I'd like to contribute it to Community extensions and examples.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

---
From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Tuesday, June 27, 2017 5:52 PM
To: ???? / NORIMATSU?TAKASHI
Cc: keycloak-dev at lists.jboss.org
Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication

I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository.

On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI <takashi.norimatsu.ws at hitachi.com> wrote:
Hello.

Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism.

I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260).
Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak.

Detailed description of this feature is mentioned below.
https://github.com/Hitachi/PoV-keycloak-authentication-delegation

I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem?

[Problem]
- I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases.

After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.

_______________________________________________
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 thomas.darimont at googlemail.com  Mon Jul 31 11:24:58 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 31 Jul 2017 17:24:58 +0200
Subject: [keycloak-dev] (no subject)
Message-ID: <CAK-7U1gt2Vgcf4vzhdnSSM5n8dN7TjCwLh85z9BtJ7NmzL2y-g@mail.gmail.com>

Hello,

how can I add a new dependency to the keycloak modules/system/layers/base
when building
a server-distribution?

I need to add org.apache.commons:commons-collections4 for the PatriciaTrie
which I need for
my BlacklistPasswordPolicyProvider: [0]

I tried adding a dependency to keycloak/dependencies/server-all/pom.xml but
I still get
CNFEs if I try to run the server from the dist-build.

Caused by: java.lang.ClassNotFoundException:
org.apache.commons.collections4.trie.PatriciaTrie from [Module
"org.keycloak.keycloak-server-spi-private" from local module loader
@282ba1e (finder: local module finder @13b6d03 (roots:
/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules,/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules/system/layers/keycloak,/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules/system/layers/base))]

Cheers,
Thomas

[0]
https://github.com/thomasdarimont/keycloak/commit/59a84df2f70623f11bd4d78771a4b91422fa0286

From thomas.darimont at googlemail.com  Mon Jul 31 11:28:02 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 31 Jul 2017 17:28:02 +0200
Subject: [keycloak-dev] How to add a dependency to keycloak server
	distribution build?
Message-ID: <CAK-7U1j-2izOe7V7VB8gPOXPfSF7JSp9j2bvcY+Hyh=fXGbQww@mail.gmail.com>

Hello,

(sorry hit send to fast...)

how can I add a new dependency to the keycloak modules/system/layers/base
when building
a server-distribution?

I need to add org.apache.commons:commons-collections4 for the PatriciaTrie
which I need for
my BlacklistPasswordPolicyProvider: [0]

I tried adding a dependency to keycloak/dependencies/server-all/pom.xml but
I still get
CNFEs if I try to run the server from the dist-build.

Caused by: java.lang.ClassNotFoundException:
org.apache.commons.collections4.trie.PatriciaTrie
from [Module "org.keycloak.keycloak-server-spi-private" from local module
loader @282ba1e (finder: local module finder @13b6d03 (roots:
/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-
SNAPSHOT/modules,/home/tom/dev/playground/keycloak/
keycloak-3.3.0.CR1-SNAPSHOT/modules/system/layers/keycloak,/home/tom/dev/
playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules/
system/layers/base))]

Cheers,
Thomas

[0] https://github.com/thomasdarimont/keycloak/commit/
59a84df2f70623f11bd4d78771a4b91422fa0286

From psilva at redhat.com  Mon Jul 31 11:35:07 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 31 Jul 2017 12:35:07 -0300
Subject: [keycloak-dev] token exchange
In-Reply-To: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com>
References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com>
Message-ID: <CAJrcDBcedStc8h6taDKZenmJRh_Jaqw05H1Yig2MUfqiM-CbzA@mail.gmail.com>

On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke <bburke at redhat.com> wrote:

> I've implemented a simple token exchange API [1] that allows you to
> exchange an access token created for one client to another client.  The
> REST API follows the oauth token exchange api [2] very loosely.
>
> subject_token: a keycloak access token
>
> audience: takes a client id
>
> It then converts the access token created for one client and converts it
> to another.  It lives under the token endpoint.
>
> The security model is as follows:
>
> * Authenticate calling client the same way as password grant.
>
> * The calling client must have service account enabled
>
> * Service account must have a realm role "token-exchanger" grant edto it
> or, it must have a client role "token-exchanger" granted to it.  This
> exchanger client role is a role defined by the target client you are
> exchanging the token to.
>
>
> Is this a good security model?  I'm thinking of not creating these roles
> right now and to enable support for exchange would require defining the
> roles specified above.
>

I think roles are too coarse-grained to represent this kind of policy. A
better option would be to explicitly define the clients that are allowed to
exchange tokens for a particular resource server. Eg.:

RS A allows Client B, C and D to exchange their tokens where the target
audience is RS A (or if using "resource", a specific resource in RS A).


>
>
> Future work would be to have an additional subject_issuer and
> requested_issuer parameters.  "subject_issuer" would match to a broker
> alias, so you could exchange a facebook token for a keycloak realm
> token.  Same thing goes for "requested_issuer". This would allow you to
> exchange a Keycloak token for a facebook token or some other registered
> broker.
>

I'm following your discussion in OAuth2 WG. Do we really need these
additional paramerters ?

My understanding from the specs is that:

* Facebook -> Keycloak Realm
  If you pass a "subject_token_type" like
"urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where {ALIAS} is the
alias of the broker configured to your realm. Assuming {ALIAS} maps to a
Facebook broker in your realm, you probably know how to exchange the FB
opaque access token to a Keycloak realm token.

* Keycloak -> Facebook
  If you pass a "requested_token_type" like
"urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where {ALIAS} is the
alias of the broker configured to your realm. Assuming {ALIAS} maps to a
Facebook broker in your realm, you probably know how to exchange the
Keycloak token to a FB token.

Or are you thinking about something else ?


>
>
> [1] https://github.com/keycloak/keycloak/pull/4362
>
> [2] http://www.ietf.org/id/draft-ietf-oauth-token-exchange-09.txt
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Jul 31 12:18:35 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Jul 2017 12:18:35 -0400
Subject: [keycloak-dev] token exchange
In-Reply-To: <CAJrcDBcedStc8h6taDKZenmJRh_Jaqw05H1Yig2MUfqiM-CbzA@mail.gmail.com>
References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com>
	<CAJrcDBcedStc8h6taDKZenmJRh_Jaqw05H1Yig2MUfqiM-CbzA@mail.gmail.com>
Message-ID: <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com>



On 7/31/17 11:35 AM, Pedro Igor Silva wrote:
> On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I've implemented a simple token exchange API [1] that allows you to
>     exchange an access token created for one client to another
>     client.  The
>     REST API follows the oauth token exchange api [2] very loosely.
>
>     subject_token: a keycloak access token
>
>     audience: takes a client id
>
>     It then converts the access token created for one client and
>     converts it
>     to another.  It lives under the token endpoint.
>
>     The security model is as follows:
>
>     * Authenticate calling client the same way as password grant.
>
>     * The calling client must have service account enabled
>
>     * Service account must have a realm role "token-exchanger" grant
>     edto it
>     or, it must have a client role "token-exchanger" granted to it.  This
>     exchanger client role is a role defined by the target client you are
>     exchanging the token to.
>
>
>     Is this a good security model?  I'm thinking of not creating these
>     roles
>     right now and to enable support for exchange would require
>     defining the
>     roles specified above.
>
>
> I think roles are too coarse-grained to represent this kind of policy. 
> A better option would be to explicitly define the clients that are 
> allowed to exchange tokens for a particular resource server. Eg.:
>
> RS A allows Client B, C and D to exchange their tokens where the 
> target audience is RS A (or if using "resource", a specific resource 
> in RS A).

I changed it a little.  actors are:

* Authenticated client asking for change
* Clients that are the audience of the token being exchanged
* Client you want the token to be exchanged to

So, the authenticated client must be in the audience of the token being 
exchanged, or, have permission to exchange from that particular 
audience.  The authenticated client also must have permission to 
exchange to the audience it wants to exchange to.


>
>
>     Future work would be to have an additional subject_issuer and
>     requested_issuer parameters.  "subject_issuer" would match to a broker
>     alias, so you could exchange a facebook token for a keycloak realm
>     token.  Same thing goes for "requested_issuer". This would allow
>     you to
>     exchange a Keycloak token for a facebook token or some other
>     registered
>     broker.
>
>
> I'm following your discussion in OAuth2 WG. Do we really need these 
> additional paramerters ?
>
> My understanding from the specs is that:
>
> * Facebook -> Keycloak Realm
>   If you pass a "subject_token_type" like 
> "urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where {ALIAS} 
> is the alias of the broker configured to your realm. Assuming {ALIAS} 
> maps to a Facebook broker in your realm, you probably know how to 
> exchange the FB opaque access token to a Keycloak realm token.
>
> * Keycloak -> Facebook
>   If you pass a "requested_token_type" like 
> "urn:keycloak:params:oauth:token-type:broker-{ALIAS}", where 
> {ALIAS} is the alias of the broker configured to your realm. Assuming 
> {ALIAS} maps to a Facebook broker in your realm, you probably know how 
> to exchange the Keycloak token to a FB token.
>
> Or are you thinking about something else ?

I'm conversing with WG to get this new parameter included in the 
specification.  types and issuers shouldn't be mixed IMO. Especially 
when you could standardize oauth to oauth cross-domain exchange pretty 
easily if you had these new parameters where otherwise you'd be 
dependent on the STS's proprietary type definitions.  The spec is way 
too vague for cross-domain exchange.

Bill

From bburke at redhat.com  Mon Jul 31 12:54:23 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Jul 2017 12:54:23 -0400
Subject: [keycloak-dev] token exchange
In-Reply-To: <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com>
References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com>
	<CAJrcDBcedStc8h6taDKZenmJRh_Jaqw05H1Yig2MUfqiM-CbzA@mail.gmail.com>
	<49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com>
Message-ID: <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com>



On 7/31/17 12:18 PM, Bill Burke wrote:
>
>
>
> On 7/31/17 11:35 AM, Pedro Igor Silva wrote:
>> On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     I've implemented a simple token exchange API [1] that allows you to
>>     exchange an access token created for one client to another
>>     client.  The
>>     REST API follows the oauth token exchange api [2] very loosely.
>>
>>     subject_token: a keycloak access token
>>
>>     audience: takes a client id
>>
>>     It then converts the access token created for one client and
>>     converts it
>>     to another.  It lives under the token endpoint.
>>
>>     The security model is as follows:
>>
>>     * Authenticate calling client the same way as password grant.
>>
>>     * The calling client must have service account enabled
>>
>>     * Service account must have a realm role "token-exchanger" grant
>>     edto it
>>     or, it must have a client role "token-exchanger" granted to it.  This
>>     exchanger client role is a role defined by the target client you are
>>     exchanging the token to.
>>
>>
>>     Is this a good security model?  I'm thinking of not creating
>>     these roles
>>     right now and to enable support for exchange would require
>>     defining the
>>     roles specified above.
>>
>>
>> I think roles are too coarse-grained to represent this kind of 
>> policy. A better option would be to explicitly define the clients 
>> that are allowed to exchange tokens for a particular resource server. 
>> Eg.:
>>
>> RS A allows Client B, C and D to exchange their tokens where the 
>> target audience is RS A (or if using "resource", a specific resource 
>> in RS A).
>
> I changed it a little.  actors are:
>
> * Authenticated client asking for change
> * Clients that are the audience of the token being exchanged
> * Client you want the token to be exchanged to
>
> So, the authenticated client must be in the audience of the token 
> being exchanged, or, have permission to exchange from that particular 
> audience.  The authenticated client also must have permission to 
> exchange to the audience it wants to exchange to.
>
Good idea to change it to use the fine grain admin permissions. There's 
a couple of issues/problems with doing this that I think are easily done:

* public clients can't have service accounts.
* Client Policy looks at kc_client_id attribute which is pulled from the 
issuedFor claim in the token.  This isn't correct as we permission 
checks based on the authenticated client, not the token.

So I'll have to create a new Identity type that either wraps the service 
account or ClientModel and sets the "kc_client_id" property.

Bill