From fpo at adorsys.de  Thu Feb  1 02:43:59 2018
From: fpo at adorsys.de (Francis Pouatcha)
Date: Thu, 1 Feb 2018 08:43:59 +0100
Subject: [keycloak-dev] Initial Client Storage SPI
In-Reply-To: <CAJgngAebtRQ21Ks27eNUc7k7EpnCuhcGwsnGuCERKU7-2kwuGA@mail.gmail.com>
References: <CABRXCmzTAXbNkmwMbie3Pa-7EEX46AD=sh4txbY-NrMBNJcuqw@mail.gmail.com>
	<CABRXCmy3_h7eAQLkprm5GceBViHSEeLnKQ+S54RG_5H8gBNtbA@mail.gmail.com>
	<CAJgngAcFQ+ONBNFC+KPBHpg_yhCS_ODtnPCzxvZ-i_KxwuKM8w@mail.gmail.com>
	<CAOW4vyOsKA3FimkOQ7ZRjDVUxFLyrDQrpL52kgzHfWb9fG6G0w@mail.gmail.com>
	<CAJgngAebtRQ21Ks27eNUc7k7EpnCuhcGwsnGuCERKU7-2kwuGA@mail.gmail.com>
Message-ID: <CAOW4vyN7YMDDrrhmxY--3JFBqYzhZiESnz31DyJOjg3BH+YiLQ@mail.gmail.com>

PSD2 does not define any client registration process. But after reading the
last release of the RTS (Regulatory Technical Standard), we have the
following plan for a reference implementation:

1- Certificate based Dynamic Client Registration
The EBA (European Banking Association) requires each TPP (Thirs Party
Provider) to have a digital certificate issued by their country authority.
Based on the RTS (Regulatory Technical Standard) released so far, the flow
we are modelling plans some sort of Certificate Based Dynamic Client
registration.

2- Activity and Fraud Reporting
PSD2 requires ASPSP (Account Servicing Payment Service Provider) to report
irregular activity on a regular basis. Many banks will extend existing
fraud reporting systems to fulfill this requirement. Most of these system
will store more information on the client than required by the identity
provider.

3- Managing the Client Life Cycle
For same reasons (like fraud management), managing the life cycle of TPPs
(Keycloack Clients, including temporary suspensions) shall be delegated to
the PSD2 specific backend.

4- Adding TPP Specific Information to the Access Token
I hope the "Client Attributes Map" will help pass over some client specific
information to the OIDCProtocoMapper so we can add this to the access token.

On Tue, Jan 30, 2018 at 12:49 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Could you elaborate on what PSD2 requires in addition to what Keycloak
> clients provide today? It may make sense to rather extend what the clients
> do today than to require using a custom SPI to store clients externally.
>
> On 29 January 2018 at 22:19, Francis Pouatcha <fpo at adorsys.de> wrote:
>
>> Bill,
>>
>> in Europe we are working on implementing the PSD2 regulation (Second
>> European Payment Service Directive). Implementation involves a lot of
>> interaction between API gateways and IdP and banking systems. Correct
>> implementation of PSD2 requires more than what the keycloak client
>> functionality exposes today. Therefore:
>> - having a Client Storage SPI is a great idea.
>> - making it read-only good for now
>> - making it public SPI might though be very helpful
>>
>>
>> /Francis
>>
>> On Mon, Jan 29, 2018 at 8:57 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> All makes sense to me. Would probably make sense to also add a JIRA to
>>> include what would be needed to make it into a fully supported feature.
>>>
>>> FIY 3Scale was also interested in this as they currently have clients
>>> created through their UI and then have to create/manage clients through
>>> the
>>> admin endpoints in the background when users change client config in
>>> their
>>> UI.
>>>
>>> On 26 January 2018 at 20:02, Bill Burke <bburke at redhat.com> wrote:
>>>
>>> > A few more things:
>>> >
>>> > * Its implemented very similarly to UserStorage SPI.
>>> > * It will not support client roles
>>> > * It will not support node registration.
>>> >
>>> >
>>> > On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke <bburke at redhat.com> wrote:
>>> > > As part of Openshift integration, I needed to implement a Client
>>> > > Storage SPI.  Here are my plans for it:
>>> > >
>>> > > * It is a private SPI
>>> > > * Only read only support.
>>> > > * Only lookup support to facilitate client login and grants and
>>> stuff.
>>> > > Listing all clients will not show up in admin conosle
>>> > > * There will be no admin console support.  This means, no admin
>>> > > console support for provider config.  Providers can only be
>>> configured
>>> > > through REST API or realm import.
>>> > > * Basically it will be bare bones to support Openshift integration
>>> only.
>>> > >
>>> > > My plan is that Openshift support will be distributed as an extension
>>> > > to our base image and/or, it will be a template realm.json import
>>> file
>>> > > that users can edit.  I just don't want to expose an unfinished SPI.
>>> > >
>>> > > I'll probably have a PR for review early next week.
>>> > >
>>> > > --
>>> > > Bill Burke
>>> > > Red Hat
>>> >
>>> >
>>> >
>>> > --
>>> > Bill Burke
>>> > Red Hat
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> >
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>

From sthorger at redhat.com  Thu Feb  1 14:19:18 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 1 Feb 2018 20:19:18 +0100
Subject: [keycloak-dev] Initial Client Storage SPI
In-Reply-To: <CAOW4vyN7YMDDrrhmxY--3JFBqYzhZiESnz31DyJOjg3BH+YiLQ@mail.gmail.com>
References: <CABRXCmzTAXbNkmwMbie3Pa-7EEX46AD=sh4txbY-NrMBNJcuqw@mail.gmail.com>
	<CABRXCmy3_h7eAQLkprm5GceBViHSEeLnKQ+S54RG_5H8gBNtbA@mail.gmail.com>
	<CAJgngAcFQ+ONBNFC+KPBHpg_yhCS_ODtnPCzxvZ-i_KxwuKM8w@mail.gmail.com>
	<CAOW4vyOsKA3FimkOQ7ZRjDVUxFLyrDQrpL52kgzHfWb9fG6G0w@mail.gmail.com>
	<CAJgngAebtRQ21Ks27eNUc7k7EpnCuhcGwsnGuCERKU7-2kwuGA@mail.gmail.com>
	<CAOW4vyN7YMDDrrhmxY--3JFBqYzhZiESnz31DyJOjg3BH+YiLQ@mail.gmail.com>
Message-ID: <CAJgngAe8EoSXRk2iOUjTXxsxshrfcrRGagASb5Qhb2=NhpYc5g@mail.gmail.com>

On 1 February 2018 at 08:43, Francis Pouatcha <fpo at adorsys.de> wrote:

> PSD2 does not define any client registration process. But after reading the
> last release of the RTS (Regulatory Technical Standard), we have the
> following plan for a reference implementation:
>
> 1- Certificate based Dynamic Client Registration
> The EBA (European Banking Association) requires each TPP (Thirs Party
> Provider) to have a digital certificate issued by their country authority.
> Based on the RTS (Regulatory Technical Standard) released so far, the flow
> we are modelling plans some sort of Certificate Based Dynamic Client
> registration.
>

Having certificate based authentication for dynamic client registration
seems like a sensible idea and I'd think we could accept a contribution
around that to allow you to use the dynamic client registration
capabilities already in Keycloak.


>
> 2- Activity and Fraud Reporting
> PSD2 requires ASPSP (Account Servicing Payment Service Provider) to report
> irregular activity on a regular basis. Many banks will extend existing
> fraud reporting systems to fulfill this requirement. Most of these system
> will store more information on the client than required by the identity
> provider.
>

Clients in Keycloak already have attributes that can store any key-value
pair.


>
> 3- Managing the Client Life Cycle
> For same reasons (like fraud management), managing the life cycle of TPPs
> (Keycloack Clients, including temporary suspensions) shall be delegated to
> the PSD2 specific backend.
>

Not sure what specifically this involves, but I could certainly see us
adding more smarts into Keycloak on managing life cycle of clients.


>
> 4- Adding TPP Specific Information to the Access Token
> I hope the "Client Attributes Map" will help pass over some client specific
> information to the OIDCProtocoMapper so we can add this to the access
> token.
>

We just miss a client attribute mapper here right?


>
> On Tue, Jan 30, 2018 at 12:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > Could you elaborate on what PSD2 requires in addition to what Keycloak
> > clients provide today? It may make sense to rather extend what the
> clients
> > do today than to require using a custom SPI to store clients externally.
> >
> > On 29 January 2018 at 22:19, Francis Pouatcha <fpo at adorsys.de> wrote:
> >
> >> Bill,
> >>
> >> in Europe we are working on implementing the PSD2 regulation (Second
> >> European Payment Service Directive). Implementation involves a lot of
> >> interaction between API gateways and IdP and banking systems. Correct
> >> implementation of PSD2 requires more than what the keycloak client
> >> functionality exposes today. Therefore:
> >> - having a Client Storage SPI is a great idea.
> >> - making it read-only good for now
> >> - making it public SPI might though be very helpful
> >>
> >>
> >> /Francis
> >>
> >> On Mon, Jan 29, 2018 at 8:57 PM, Stian Thorgersen <sthorger at redhat.com>
> >> wrote:
> >>
> >>> All makes sense to me. Would probably make sense to also add a JIRA to
> >>> include what would be needed to make it into a fully supported feature.
> >>>
> >>> FIY 3Scale was also interested in this as they currently have clients
> >>> created through their UI and then have to create/manage clients through
> >>> the
> >>> admin endpoints in the background when users change client config in
> >>> their
> >>> UI.
> >>>
> >>> On 26 January 2018 at 20:02, Bill Burke <bburke at redhat.com> wrote:
> >>>
> >>> > A few more things:
> >>> >
> >>> > * Its implemented very similarly to UserStorage SPI.
> >>> > * It will not support client roles
> >>> > * It will not support node registration.
> >>> >
> >>> >
> >>> > On Fri, Jan 26, 2018 at 1:30 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >>> > > As part of Openshift integration, I needed to implement a Client
> >>> > > Storage SPI.  Here are my plans for it:
> >>> > >
> >>> > > * It is a private SPI
> >>> > > * Only read only support.
> >>> > > * Only lookup support to facilitate client login and grants and
> >>> stuff.
> >>> > > Listing all clients will not show up in admin conosle
> >>> > > * There will be no admin console support.  This means, no admin
> >>> > > console support for provider config.  Providers can only be
> >>> configured
> >>> > > through REST API or realm import.
> >>> > > * Basically it will be bare bones to support Openshift integration
> >>> only.
> >>> > >
> >>> > > My plan is that Openshift support will be distributed as an
> extension
> >>> > > to our base image and/or, it will be a template realm.json import
> >>> file
> >>> > > that users can edit.  I just don't want to expose an unfinished
> SPI.
> >>> > >
> >>> > > I'll probably have a PR for review early next week.
> >>> > >
> >>> > > --
> >>> > > Bill Burke
> >>> > > Red Hat
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Bill Burke
> >>> > Red Hat
> >>> > _______________________________________________
> >>> > keycloak-dev mailing list
> >>> > keycloak-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>> >
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From jgallaso at redhat.com  Fri Feb  2 06:30:08 2018
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Fri, 2 Feb 2018 12:30:08 +0100
Subject: [keycloak-dev] Keycloak Events Information
Message-ID: <CAGsbZmHgeQYaRJaspKvoOxHqpJmt-FViFD22OdoksF1M7VA6rg@mail.gmail.com>

Hi,

I'm writing some documentation about Keycloak events and I can't find
anything at all about them with the only exception of this Enum:
https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/events/EventType.java

Am I missing something or this is certainly the only information?

Cheers,

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

From sthorger at redhat.com  Fri Feb  2 06:46:34 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 2 Feb 2018 12:46:34 +0100
Subject: [keycloak-dev] Keycloak Events Information
In-Reply-To: <CAGsbZmHgeQYaRJaspKvoOxHqpJmt-FViFD22OdoksF1M7VA6rg@mail.gmail.com>
References: <CAGsbZmHgeQYaRJaspKvoOxHqpJmt-FViFD22OdoksF1M7VA6rg@mail.gmail.com>
Message-ID: <CAJgngAcjUDwBKjG8hwMrgu8CBv=8qzY04pjetajv2NpyXChtnA@mail.gmail.com>

Are you looking at events through admin console/endpoint or to create a
custom EventListener?

EventListener is not a supported SPI and hence isn't documented. Events in
console/endpoints could/should be documented, but there is very little at
the moment.

On 2 February 2018 at 12:30, Jose Miguel Gallas Olmedo <jgallaso at redhat.com>
wrote:

> Hi,
>
> I'm writing some documentation about Keycloak events and I can't find
> anything at all about them with the only exception of this Enum:
> https://github.com/keycloak/keycloak/blob/master/server-
> spi-private/src/main/java/org/keycloak/events/EventType.java
>
> Am I missing something or this is certainly the only information?
>
> Cheers,
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
> <https://red.ht/sig>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From danielcharczynski at o2.pl  Mon Feb  5 04:14:34 2018
From: danielcharczynski at o2.pl (=?UTF-8?Q?Daniel_Charczy=C5=84ski?=)
Date: Mon, 5 Feb 2018 10:14:34 +0100
Subject: [keycloak-dev] How retrievie access token only with roles for
 specific target service(keycloak client)?
Message-ID: <CALk=OEArDkRD8ZX5YV1Og7wy3uz7w7OC+ubsdpydMij0Lr=hXg@mail.gmail.com>

 Hi everyone

I think that there is an important need to implemment feature that makes
possible getting access token according to target service

background:
we are using bearer access tokens in case of authorization between services
this is JWT  signed by keycloak and contains all roles assigned to this
specific client
we are using "service account" in case of authorization service to service


eg:
if we have following screnario

service A   --->  service B
    |
    |-------------  > service C

service A receives JWT with roles to service B and C

If Service A comunicates with B, B is able to reuse this token and
communicate with C as service A
Token that B receives from A is valid and there is possibility to reuse it
That is CRITICAL security issue in my oppinion.

Out plan is to use Roles that requires scope parameter and it is OK for us
but at the moment there is only possibility to query for specific Role but
there is NO possibility to ask keycloak for JWT with all roles but only in
service B context.

Of course we can use composite roles but this is workaround that requeires
extra maintanence - we do not want to do that in that way

We just need support scope parameter like

*scope = serviceB/**

We created



* https://github.com/keycloak/keycloak/pull/4910
<https://github.com/keycloak/keycloak/pull/4910>   -
rejectedandhttps://issues.jboss.org/browse/KEYCLOAK-6092
<https://issues.jboss.org/browse/KEYCLOAK-6092> - closed as duplicate *
Maybe our PR  is to much flexibe - we build our solution using regex
There is possibillity to use wildcard, anything

Regards
Daniel Charczy?ski

From sthorger at redhat.com  Mon Feb  5 04:54:05 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 5 Feb 2018 10:54:05 +0100
Subject: [keycloak-dev] How retrievie access token only with roles for
 specific target service(keycloak client)?
In-Reply-To: <CALk=OEArDkRD8ZX5YV1Og7wy3uz7w7OC+ubsdpydMij0Lr=hXg@mail.gmail.com>
References: <CALk=OEArDkRD8ZX5YV1Og7wy3uz7w7OC+ubsdpydMij0Lr=hXg@mail.gmail.com>
Message-ID: <CAJgngAct1BeebzoESTnshpaM1RvE85RNHSiaeOq9jSNtY-qH4w@mail.gmail.com>

Did you look at the token exchance service?

On 5 February 2018 at 10:14, Daniel Charczy?ski <danielcharczynski at o2.pl>
wrote:

>  Hi everyone
>
> I think that there is an important need to implemment feature that makes
> possible getting access token according to target service
>
> background:
> we are using bearer access tokens in case of authorization between services
> this is JWT  signed by keycloak and contains all roles assigned to this
> specific client
> we are using "service account" in case of authorization service to service
>
>
> eg:
> if we have following screnario
>
> service A   --->  service B
>     |
>     |-------------  > service C
>
> service A receives JWT with roles to service B and C
>
> If Service A comunicates with B, B is able to reuse this token and
> communicate with C as service A
> Token that B receives from A is valid and there is possibility to reuse it
> That is CRITICAL security issue in my oppinion.
>
> Out plan is to use Roles that requires scope parameter and it is OK for us
> but at the moment there is only possibility to query for specific Role but
> there is NO possibility to ask keycloak for JWT with all roles but only in
> service B context.
>
> Of course we can use composite roles but this is workaround that requeires
> extra maintanence - we do not want to do that in that way
>
> We just need support scope parameter like
>
> *scope = serviceB/**
>
> We created
>
>
>
> * https://github.com/keycloak/keycloak/pull/4910
> <https://github.com/keycloak/keycloak/pull/4910>   -
> rejectedandhttps://issues.jboss.org/browse/KEYCLOAK-6092
> <https://issues.jboss.org/browse/KEYCLOAK-6092> - closed as duplicate *
> Maybe our PR  is to much flexibe - we build our solution using regex
> There is possibillity to use wildcard, anything
>
> Regards
> Daniel Charczy?ski
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From danielcharczynski at o2.pl  Mon Feb  5 06:27:00 2018
From: danielcharczynski at o2.pl (=?UTF-8?Q?Daniel_Charczy=C5=84ski?=)
Date: Mon, 5 Feb 2018 12:27:00 +0100
Subject: [keycloak-dev] How retrievie access token only with roles for
 specific target service(keycloak client)?
In-Reply-To: <CAJgngAct1BeebzoESTnshpaM1RvE85RNHSiaeOq9jSNtY-qH4w@mail.gmail.com>
References: <CALk=OEArDkRD8ZX5YV1Og7wy3uz7w7OC+ubsdpydMij0Lr=hXg@mail.gmail.com>
	<CAJgngAct1BeebzoESTnshpaM1RvE85RNHSiaeOq9jSNtY-qH4w@mail.gmail.com>
Message-ID: <CALk=OEAY8rJRnwgjQSL8CraSiQZv9wS3+PNRWDVFtC8XOA8osw@mail.gmail.com>

Yes

we do not want to exchange service A token to service B token, or any other
client

we want to get service A token but with restricted set of roles to roles
assigned just from service B (without service C roles)



something like

"give me my token for communication with service B"

or

"give me my token for communication with service C"

2018-02-05 10:54 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Did you look at the token exchance service?
>
> On 5 February 2018 at 10:14, Daniel Charczy?ski <danielcharczynski at o2.pl>
> wrote:
>
>>  Hi everyone
>>
>> I think that there is an important need to implemment feature that makes
>> possible getting access token according to target service
>>
>> background:
>> we are using bearer access tokens in case of authorization between
>> services
>> this is JWT  signed by keycloak and contains all roles assigned to this
>> specific client
>> we are using "service account" in case of authorization service to service
>>
>>
>> eg:
>> if we have following screnario
>>
>> service A   --->  service B
>>     |
>>     |-------------  > service C
>>
>> service A receives JWT with roles to service B and C
>>
>> If Service A comunicates with B, B is able to reuse this token and
>> communicate with C as service A
>> Token that B receives from A is valid and there is possibility to reuse it
>> That is CRITICAL security issue in my oppinion.
>>
>> Out plan is to use Roles that requires scope parameter and it is OK for us
>> but at the moment there is only possibility to query for specific Role but
>> there is NO possibility to ask keycloak for JWT with all roles but only in
>> service B context.
>>
>> Of course we can use composite roles but this is workaround that requeires
>> extra maintanence - we do not want to do that in that way
>>
>> We just need support scope parameter like
>>
>> *scope = serviceB/**
>>
>> We created
>>
>>
>>
>> * https://github.com/keycloak/keycloak/pull/4910
>> <https://github.com/keycloak/keycloak/pull/4910>   -
>> rejectedandhttps://issues.jboss.org/browse/KEYCLOAK-6092
>> <https://issues.jboss.org/browse/KEYCLOAK-6092> - closed as duplicate *
>> Maybe our PR  is to much flexibe - we build our solution using regex
>> There is possibillity to use wildcard, anything
>>
>> Regards
>> Daniel Charczy?ski
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From hmlnarik at redhat.com  Mon Feb  5 07:01:04 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 5 Feb 2018 13:01:04 +0100
Subject: [keycloak-dev] Brute force protection behaviour
Message-ID: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>

Hi,

please help me clarify the expected behaviour of brute force protection. I
read the documentation [1] but I am still not 100% sure about it. I'm more
after intention rather than actual implementation.

1) When should the Failure Reset Time apply? After the first or after last
failed attempt?

2) Should failed login attempts counter be cleared after the first
successful login or only after failure reset time regardless of the
successful login?

3) Should login failures be counted while the account is locked?

4) Should unlocking account in admin console reset login failures counter?


In other words, what is expected behaviour of the following scenarios
(questions are in items marked with Q ->)? I intentionally don't suggest
any correct answer below myself.

Setup:
- Permanent lockout: Off
- Max Lock time: 15 mins
- Wait Time Increment: 1 min
- Failure Reset Time: 30 mins

= Scenario 1 =
1.1) User locks its account
1.2) Another 3 immediate failed login attempts while account is blocked
*Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked

= Scenario 2 =
2.1) User locks its account
2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
2.3) Then do another one failed login attempt.
*Q -> *2.4) Should the account be locked now or only after next Max Login
Failures?
*Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
Increment?)
2.6) Then fail another one login attempt
*Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
Increment?)
*Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)
2.9) Validate that the user can again lock themselves out only after Max
Login Failures failed login attempts.

= Scenario 3 =
3.1) User locks its account
3.2) Another 20 failed immediate login attempts while account is blocked
*Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
(Max Lock time is 15 mins)

Thanks

--Hynek

[1]
http://www.keycloak.org/docs/latest/server_admin/index.html#password-guess-brute-force-attacks

From jp at jochenpreusche.de  Mon Feb  5 08:35:01 2018
From: jp at jochenpreusche.de (=?UTF-8?Q?Iilei_=E2=80=A2_Jochen_Preusche?=)
Date: Mon, 05 Feb 2018 14:35:01 +0100
Subject: [keycloak-dev] Locale lookup issue
Message-ID: <u8jo8ikv9aktj1bdrihab5lo.1517837701312@email.android.com>

Hello all,

A little background information:

In Keycloak?3.4.3.Final?the following behaviour seems like a bug to me:

* Use a theme with a country-specific locale, for example fr-FR and a default locale `english`?
* Use Firefox on Ubuntu, drop all language preferences in its settings and just add `french` (no country specified)
* request the login page
* the theme will be rendered in english

Acknowledging the RFC-4647 (1) Section 3.4; "Best Current Practice - Matching of Language Tags - Types of Matching - Lookup" I would expect basic matching to be applied so that the french language is chosen.

The topic is discussed cotroversely in the original Pull Request (2). Therefor I have been asked to move a discussion from the Pull-Request to this mailing list.

For more Info, see also the related issue (3)

Thank you for your consideration.

Kind regards,?
Jochen Preusche


(1)?https://www.ietf.org/rfc/rfc4647.txt

(2)?https://github.com/keycloak/keycloak/pull/4958

(3)?https://issues.jboss.org/browse/KEYCLOAK-6461

From sthorger at redhat.com  Tue Feb  6 01:13:09 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 07:13:09 +0100
Subject: [keycloak-dev] Brute force protection behaviour
In-Reply-To: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>
References: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>
Message-ID: <CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>

Adding my opinions on this

On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Hi,
>
> please help me clarify the expected behaviour of brute force protection. I
> read the documentation [1] but I am still not 100% sure about it. I'm more
> after intention rather than actual implementation.
>
> 1) When should the Failure Reset Time apply? After the first or after last
> failed attempt?
>

Last failed attempt - it's safer this way


>
> 2) Should failed login attempts counter be cleared after the first
> successful login or only after failure reset time regardless of the
> successful login?
>

Only after failure rest time - If there's an ongoing targeted attack on a
specific account this is important, otherwise an attacker would get new
attempts every time the user authenticates (which could be predicted, for
instance 9am every day)


>
> 3) Should login failures be counted while the account is locked?
>

No - I don't think this has any impact on safety and would have negative
effects for the user (most users will type the password again to check)


>
> 4) Should unlocking account in admin console reset login failures counter?
>

Yes - would be good to have a way to show the count in the admin console
though


>
>
> In other words, what is expected behaviour of the following scenarios
> (questions are in items marked with Q ->)? I intentionally don't suggest
> any correct answer below myself.
>
> Setup:
> - Permanent lockout: Off
> - Max Lock time: 15 mins
> - Wait Time Increment: 1 min
> - Failure Reset Time: 30 mins
>
> = Scenario 1 =
> 1.1) User locks its account
> 1.2) Another 3 immediate failed login attempts while account is blocked
> *Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked
>
> = Scenario 2 =
> 2.1) User locks its account
> 2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
> 2.3) Then do another one failed login attempt.
> *Q -> *2.4) Should the account be locked now or only after next Max Login
> Failures?
> *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
> Increment?)
> 2.6) Then fail another one login attempt
> *Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
> Increment?)
> *Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)
> 2.9) Validate that the user can again lock themselves out only after Max
> Login Failures failed login attempts.
>
> = Scenario 3 =
> 3.1) User locks its account
> 3.2) Another 20 failed immediate login attempts while account is blocked
> *Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
> (Max Lock time is 15 mins)
>
> Thanks
>
> --Hynek
>
> [1]
> http://www.keycloak.org/docs/latest/server_admin/index.
> html#password-guess-brute-force-attacks
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Feb  6 01:16:18 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 07:16:18 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
Message-ID: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>

I was experimenting with a custom authenticator and found it annoying that
I had to copy templates manually to the themes directory.

To resolve this I added a Theme Resource Provider SPI.

A theme resource provider can provide additional templates and/or resources
alongside the custom authenticator.

Themes are always searched first for templates and resources. Template
resource providers are only searched if not found in themes. This is
important as it allows a theme to override the templates and/or resources
provided by a theme resource provider.

The code is ready in the PR https://github.com/keycloak/keycloak/pull/4971

For an example on how it's used take a look at
https://github.com/stianst/keycloak-experimental/tree/master/u2f.

From danielcharczynski at o2.pl  Tue Feb  6 04:18:01 2018
From: danielcharczynski at o2.pl (=?UTF-8?Q?Daniel_Charczy=C5=84ski?=)
Date: Tue, 6 Feb 2018 10:18:01 +0100
Subject: [keycloak-dev] How retrievie access token only with roles for
 specific target service(keycloak client)?
In-Reply-To: <CAJgngAct1BeebzoESTnshpaM1RvE85RNHSiaeOq9jSNtY-qH4w@mail.gmail.com>
References: <CALk=OEArDkRD8ZX5YV1Og7wy3uz7w7OC+ubsdpydMij0Lr=hXg@mail.gmail.com>
	<CAJgngAct1BeebzoESTnshpaM1RvE85RNHSiaeOq9jSNtY-qH4w@mail.gmail.com>
Message-ID: <CALk=OEDWaWWWvtO5qj5sVGpNeWH3C_XUZMtmMSz7Qqrg0Yn+_g@mail.gmail.com>

BWT it looks like it doesn't work in Keycloak 3.4.3.Final

{
"error": "invalid_request",
"error_description": "Invalid grant_type"
}

I was using an example from here

https://github.com/keycloak/keycloak-documentation/blob/master/securing_apps/topics/token-exchange/token-exchange.adoc


2018-02-05 10:54 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Did you look at the token exchance service?
>
> On 5 February 2018 at 10:14, Daniel Charczy?ski <danielcharczynski at o2.pl>
> wrote:
>
>>  Hi everyone
>>
>> I think that there is an important need to implemment feature that makes
>> possible getting access token according to target service
>>
>> background:
>> we are using bearer access tokens in case of authorization between
>> services
>> this is JWT  signed by keycloak and contains all roles assigned to this
>> specific client
>> we are using "service account" in case of authorization service to service
>>
>>
>> eg:
>> if we have following screnario
>>
>> service A   --->  service B
>>     |
>>     |-------------  > service C
>>
>> service A receives JWT with roles to service B and C
>>
>> If Service A comunicates with B, B is able to reuse this token and
>> communicate with C as service A
>> Token that B receives from A is valid and there is possibility to reuse it
>> That is CRITICAL security issue in my oppinion.
>>
>> Out plan is to use Roles that requires scope parameter and it is OK for us
>> but at the moment there is only possibility to query for specific Role but
>> there is NO possibility to ask keycloak for JWT with all roles but only in
>> service B context.
>>
>> Of course we can use composite roles but this is workaround that requeires
>> extra maintanence - we do not want to do that in that way
>>
>> We just need support scope parameter like
>>
>> *scope = serviceB/**
>>
>> We created
>>
>>
>>
>> * https://github.com/keycloak/keycloak/pull/4910
>> <https://github.com/keycloak/keycloak/pull/4910>   -
>> rejectedandhttps://issues.jboss.org/browse/KEYCLOAK-6092
>> <https://issues.jboss.org/browse/KEYCLOAK-6092> - closed as duplicate *
>> Maybe our PR  is to much flexibe - we build our solution using regex
>> There is possibillity to use wildcard, anything
>>
>> Regards
>> Daniel Charczy?ski
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From mitya at cargosoft.ru  Tue Feb  6 12:42:33 2018
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Tue, 06 Feb 2018 20:42:33 +0300
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
Message-ID: <1517938953.6946.1.camel@cargosoft.ru>

Hi Stian, nice feature! Is it limited to login themes?

BTW the correct link is?https://github.com/stianst/keycloak-experimenta
l/tree/master/fido-u2f

Also nice to hear that the work has finally started on U2F, it's indeed
a must-have feature today. Is it slated for 4.0.0?

Dmitry 

> I was experimenting with a custom authenticator and found it annoying that
> I had to copy templates manually to the themes directory.
> 
> To resolve this I added a Theme Resource Provider SPI.
> 
> A theme resource provider can provide additional templates and/or resources
> alongside the custom authenticator.
> 
> Themes are always searched first for templates and resources. Template
> resource providers are only searched if not found in themes. This is
> important as it allows a theme to override the templates and/or resources
> provided by a theme resource provider.
> 
> The code is ready in the PR https://github.com/keycloak/keycloak/pull/4971
> 
> For an example on how it's used take a look at
> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bruno at abstractj.org  Tue Feb  6 12:50:33 2018
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 6 Feb 2018 15:50:33 -0200
Subject: [keycloak-dev] Brute force protection behaviour
In-Reply-To: <CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>
References: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>
	<CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>
Message-ID: <20180206175033.GA2754@abstractj.org>

Answers inline, but please keep in mind that some of them are my point
of view.

On 2018-02-06, Stian Thorgersen wrote:
> Adding my opinions on this
> 
> On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> 
> > Hi,
> >
> > please help me clarify the expected behaviour of brute force protection. I
> > read the documentation [1] but I am still not 100% sure about it. I'm more
> > after intention rather than actual implementation.
> >
> > 1) When should the Failure Reset Time apply? After the first or after last
> > failed attempt?
> >
> 
> Last failed attempt - it's safer this way
+1

> 
> 
> >
> > 2) Should failed login attempts counter be cleared after the first
> > successful login or only after failure reset time regardless of the
> > successful login?
> >
> 
> Only after failure reset time - If there's an ongoing targeted attack on a
> specific account this is important, otherwise an attacker would get new
> attempts every time the user authenticates (which could be predicted, for
> instance 9am every day)
+1

> 
> 
> >
> > 3) Should login failures be counted while the account is locked?
> >
> 
> No - I don't think this has any impact on safety and would have negative
> effects for the user (most users will type the password again to check)

I don't think it has a huge impact on safety, but I disagree here. If
you stop counting, as KC admin you can't tell which accounts are 
being targeted. But this is just my personal opinion.

> 
> 
> >
> > 4) Should unlocking account in admin console reset login failures counter?
> >
> 
> Yes - would be good to have a way to show the count in the admin console
> though
+1
> 
> 
> >
> >
> > In other words, what is expected behaviour of the following scenarios
> > (questions are in items marked with Q ->)? I intentionally don't suggest
> > any correct answer below myself.
> >
> > Setup:
> > - Permanent lockout: Off
> > - Max Lock time: 15 mins
> > - Wait Time Increment: 1 min
> > - Failure Reset Time: 30 mins
> >
> > = Scenario 1 =
> > 1.1) User locks its account
> > 1.2) Another 3 immediate failed login attempts while account is blocked
> > *Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked

>From my understanding it should be incremented at every attempt after
the account was locked, in your scenario 3 min.
> >
> > = Scenario 2 =
> > 2.1) User locks its account
> > 2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
> > 2.3) Then do another one failed login attempt.
> > *Q -> *2.4) Should the account be locked now or only after next Max Login
> > Failures?

IMO only after next Max Login Failure.

> > *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
> > Increment?)

2x wait time increment

> > 2.6) Then fail another one login attempt
> > *Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
> > Increment?)

3x wait time increment. IMO we should give the KC admin time to respond
to such attack. 

> > *Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)

Makes more sense to me after the last failed attempt.

> > 2.9) Validate that the user can again lock themselves out only after Max
> > Login Failures failed login attempts.
> >
> > = Scenario 3 =
> > 3.1) User locks its account
> > 3.2) Another 20 failed immediate login attempts while account is blocked
> > *Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
> > (Max Lock time is 15 mins)

I believe you meant "Max Wait". I'd say 15 min after the last failure.

> >
> > Thanks
> >
> > --Hynek
> >
> > [1]
> > http://www.keycloak.org/docs/latest/server_admin/index.
> > html#password-guess-brute-force-attacks
> > _______________________________________________
> > 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

-- 

abstractj

From bburke at redhat.com  Tue Feb  6 12:58:16 2018
From: bburke at redhat.com (Bill Burke)
Date: Tue, 6 Feb 2018 12:58:16 -0500
Subject: [keycloak-dev] Brute force protection behaviour
In-Reply-To: <CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>
References: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>
	<CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>
Message-ID: <CABRXCmxZwVbP=yrVCJaxbyMQVCPtDAPVyW9HC1fUBZi=FWCdCA@mail.gmail.com>

I put this in the PR and corresponding JIRAs, but a user had this
problem in 3.2 (not 3.4, I fixed it)

1) User has 3 failed attempts, account locks, Temporary Disable appears
2) User tries again before wait period is up...Wait increment
increases wait time
3) User tries again before wait period, wait increment is increased
again as Keycloak logged a failure for this
4) User is locked out forever unless admin helps to unlock.

So, I changed the behavior so that a failure isn't logged if a user
attempts a login to an account that is temporarily blocked.  I believe
the failure count is only reset on a successful login.

IMO, the algorithm shoudl be:

1) After N failed attempts lock user for WAIT TIMEOUT
2) Do not increment failure count if login is attempted on locked account
3) After N failed attempts after unlock, lock user again for WAIT TIMEOUT * 2
4) After unlock and another N failed attempts, locak user again for
WAIT TIMEOUT * 3.
5) A successful login resets failure count.

On Tue, Feb 6, 2018 at 1:13 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Adding my opinions on this
>
> On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> Hi,
>>
>> please help me clarify the expected behaviour of brute force protection. I
>> read the documentation [1] but I am still not 100% sure about it. I'm more
>> after intention rather than actual implementation.
>>
>> 1) When should the Failure Reset Time apply? After the first or after last
>> failed attempt?
>
>
> Last failed attempt - it's safer this way
>
>>
>>
>> 2) Should failed login attempts counter be cleared after the first
>> successful login or only after failure reset time regardless of the
>> successful login?
>
>
> Only after failure rest time - If there's an ongoing targeted attack on a
> specific account this is important, otherwise an attacker would get new
> attempts every time the user authenticates (which could be predicted, for
> instance 9am every day)
>
>>
>>
>> 3) Should login failures be counted while the account is locked?
>
>
> No - I don't think this has any impact on safety and would have negative
> effects for the user (most users will type the password again to check)
>
>>
>>
>> 4) Should unlocking account in admin console reset login failures counter?
>
>
> Yes - would be good to have a way to show the count in the admin console
> though
>
>>
>>
>>
>> In other words, what is expected behaviour of the following scenarios
>> (questions are in items marked with Q ->)? I intentionally don't suggest
>> any correct answer below myself.
>>
>> Setup:
>> - Permanent lockout: Off
>> - Max Lock time: 15 mins
>> - Wait Time Increment: 1 min
>> - Failure Reset Time: 30 mins
>>
>> = Scenario 1 =
>> 1.1) User locks its account
>> 1.2) Another 3 immediate failed login attempts while account is blocked
>> *Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked
>>
>> = Scenario 2 =
>> 2.1) User locks its account
>> 2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
>> 2.3) Then do another one failed login attempt.
>> *Q -> *2.4) Should the account be locked now or only after next Max Login
>> Failures?
>> *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
>> Increment?)
>> 2.6) Then fail another one login attempt
>> *Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
>> Increment?)
>> *Q -> *2.8) Wait Failure Reset Time (since first or last failed attempt?)
>> 2.9) Validate that the user can again lock themselves out only after Max
>> Login Failures failed login attempts.
>>
>> = Scenario 3 =
>> 3.1) User locks its account
>> 3.2) Another 20 failed immediate login attempts while account is blocked
>> *Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
>> (Max Lock time is 15 mins)
>>
>> Thanks
>>
>> --Hynek
>>
>> [1]
>>
>> http://www.keycloak.org/docs/latest/server_admin/index.html#password-guess-brute-force-attacks
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Tue Feb  6 13:56:11 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 19:56:11 +0100
Subject: [keycloak-dev] Brute force protection behaviour
In-Reply-To: <CABRXCmxZwVbP=yrVCJaxbyMQVCPtDAPVyW9HC1fUBZi=FWCdCA@mail.gmail.com>
References: <CAMvXD=FJNp7SBVRKz-K5D_9zQYOdGueV9fFSoGG-V05AANxNYg@mail.gmail.com>
	<CAJgngAfpM62mCPEB8puGTRz=WGJP0N4pxB3=n0DHNde6wwP8kA@mail.gmail.com>
	<CABRXCmxZwVbP=yrVCJaxbyMQVCPtDAPVyW9HC1fUBZi=FWCdCA@mail.gmail.com>
Message-ID: <CAJgngAfjGQMRCO=7NVD-weFDHt=+g6QW7-nyvNizMcu1GGq3cQ@mail.gmail.com>

Could you answer Hynek's original questions? Those where the things after
reading the docs and tooltips that where unclear to us.

On 6 February 2018 at 18:58, Bill Burke <bburke at redhat.com> wrote:

> I put this in the PR and corresponding JIRAs, but a user had this
> problem in 3.2 (not 3.4, I fixed it)
>
> 1) User has 3 failed attempts, account locks, Temporary Disable appears
> 2) User tries again before wait period is up...Wait increment
> increases wait time
> 3) User tries again before wait period, wait increment is increased
> again as Keycloak logged a failure for this
> 4) User is locked out forever unless admin helps to unlock.
>
> So, I changed the behavior so that a failure isn't logged if a user
> attempts a login to an account that is temporarily blocked.  I believe
> the failure count is only reset on a successful login.
>
> IMO, the algorithm shoudl be:
>
> 1) After N failed attempts lock user for WAIT TIMEOUT
> 2) Do not increment failure count if login is attempted on locked account
> 3) After N failed attempts after unlock, lock user again for WAIT TIMEOUT
> * 2
> 4) After unlock and another N failed attempts, locak user again for
> WAIT TIMEOUT * 3.
> 5) A successful login resets failure count.
>
> On Tue, Feb 6, 2018 at 1:13 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Adding my opinions on this
> >
> > On 5 February 2018 at 13:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> >>
> >> Hi,
> >>
> >> please help me clarify the expected behaviour of brute force
> protection. I
> >> read the documentation [1] but I am still not 100% sure about it. I'm
> more
> >> after intention rather than actual implementation.
> >>
> >> 1) When should the Failure Reset Time apply? After the first or after
> last
> >> failed attempt?
> >
> >
> > Last failed attempt - it's safer this way
> >
> >>
> >>
> >> 2) Should failed login attempts counter be cleared after the first
> >> successful login or only after failure reset time regardless of the
> >> successful login?
> >
> >
> > Only after failure rest time - If there's an ongoing targeted attack on a
> > specific account this is important, otherwise an attacker would get new
> > attempts every time the user authenticates (which could be predicted, for
> > instance 9am every day)
> >
> >>
> >>
> >> 3) Should login failures be counted while the account is locked?
> >
> >
> > No - I don't think this has any impact on safety and would have negative
> > effects for the user (most users will type the password again to check)
> >
> >>
> >>
> >> 4) Should unlocking account in admin console reset login failures
> counter?
> >
> >
> > Yes - would be good to have a way to show the count in the admin console
> > though
> >
> >>
> >>
> >>
> >> In other words, what is expected behaviour of the following scenarios
> >> (questions are in items marked with Q ->)? I intentionally don't suggest
> >> any correct answer below myself.
> >>
> >> Setup:
> >> - Permanent lockout: Off
> >> - Max Lock time: 15 mins
> >> - Wait Time Increment: 1 min
> >> - Failure Reset Time: 30 mins
> >>
> >> = Scenario 1 =
> >> 1.1) User locks its account
> >> 1.2) Another 3 immediate failed login attempts while account is blocked
> >> *Q -> *1.3) Check that after (1 or 3?) minutes the account is unlocked
> >>
> >> = Scenario 2 =
> >> 2.1) User locks its account
> >> 2.2) Wait until account is unlocked (should be 1x Wait Time Increment)
> >> 2.3) Then do another one failed login attempt.
> >> *Q -> *2.4) Should the account be locked now or only after next Max
> Login
> >> Failures?
> >> *Q -> *2.5) Wait until account is unlocked (should be 1x or 2x Wait Time
> >> Increment?)
> >> 2.6) Then fail another one login attempt
> >> *Q -> *2.7) Wait until account is unlocked (should be 1x or 3x Wait Time
> >> Increment?)
> >> *Q -> *2.8) Wait Failure Reset Time (since first or last failed
> attempt?)
> >> 2.9) Validate that the user can again lock themselves out only after Max
> >> Login Failures failed login attempts.
> >>
> >> = Scenario 3 =
> >> 3.1) User locks its account
> >> 3.2) Another 20 failed immediate login attempts while account is blocked
> >> *Q -> *3.3) Check that after (1 or 15?) minutes the account is unlocked
> >> (Max Lock time is 15 mins)
> >>
> >> Thanks
> >>
> >> --Hynek
> >>
> >> [1]
> >>
> >> http://www.keycloak.org/docs/latest/server_admin/index.
> html#password-guess-brute-force-attacks
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From sthorger at redhat.com  Tue Feb  6 14:03:33 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 20:03:33 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <1517938953.6946.1.camel@cargosoft.ru>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
Message-ID: <CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>

On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Hi Stian, nice feature! Is it limited to login themes?
>

Nah, it's a generic theme feature.

Not sure I can see any use-cases other than custom providers that need
additional templates though. At the moment I can only think of
authenticators and required actions.

Did you have any other use-cases in mind?


>
> BTW the correct link is https://github.com/stianst/
> keycloak-experimental/tree/master/fido-u2f
>
> Also nice to hear that the work has finally started on U2F, it's indeed a
> must-have feature today. Is it slated for 4.0.0?
>
> Dmitry
>
> I was experimenting with a custom authenticator and found it annoying that
> I had to copy templates manually to the themes directory.
>
> To resolve this I added a Theme Resource Provider SPI.
>
> A theme resource provider can provide additional templates and/or resources
> alongside the custom authenticator.
>
> Themes are always searched first for templates and resources. Template
> resource providers are only searched if not found in themes. This is
> important as it allows a theme to override the templates and/or resources
> provided by a theme resource provider.
>
> The code is ready in the PR https://github.com/keycloak/keycloak/pull/4971
>
> For an example on how it's used take a look at
> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sthorger at redhat.com  Tue Feb  6 14:03:59 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 20:03:59 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
Message-ID: <CAJgngAfNO0b_678c2-Ai8GLhjbjnJOrbJjaUorsf4jmbc9zJZA@mail.gmail.com>

Oh and U2F will most likely land in U2F. Feedback on my experimental
implementation would be great as well :)

On 6 February 2018 at 20:03, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
>> Hi Stian, nice feature! Is it limited to login themes?
>>
>
> Nah, it's a generic theme feature.
>
> Not sure I can see any use-cases other than custom providers that need
> additional templates though. At the moment I can only think of
> authenticators and required actions.
>
> Did you have any other use-cases in mind?
>
>
>>
>> BTW the correct link is https://github.com/stianst/
>> keycloak-experimental/tree/master/fido-u2f
>>
>> Also nice to hear that the work has finally started on U2F, it's indeed a
>> must-have feature today. Is it slated for 4.0.0?
>>
>> Dmitry
>>
>> I was experimenting with a custom authenticator and found it annoying that
>> I had to copy templates manually to the themes directory.
>>
>> To resolve this I added a Theme Resource Provider SPI.
>>
>> A theme resource provider can provide additional templates and/or resources
>> alongside the custom authenticator.
>>
>> Themes are always searched first for templates and resources. Template
>> resource providers are only searched if not found in themes. This is
>> important as it allows a theme to override the templates and/or resources
>> provided by a theme resource provider.
>>
>> The code is ready in the PR https://github.com/keycloak/keycloak/pull/4971
>>
>> For an example on how it's used take a look at
>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>

From sthorger at redhat.com  Tue Feb  6 14:22:58 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 6 Feb 2018 20:22:58 +0100
Subject: [keycloak-dev] Updated release cadence
Message-ID: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>

As we've started working in 3 week sprints we are considering a new release
model for Keycloak.

What we are considering is doing a Beta release for every sprint, then for
every 4th sprint (each quarter) we plan to do a Final release.

For a beta release existing features will be considered stable, while new
features may not be ready for prime time. The recommendation will still be
to upgrade to always update to the latest release to receive the latest
security fixes and other fixes.

However, care should be taken before using new features in production until
a Final release is available.

Thoughts?

From hmlnarik at redhat.com  Tue Feb  6 15:01:00 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Tue, 6 Feb 2018 21:01:00 +0100
Subject: [keycloak-dev] Updated release cadence
In-Reply-To: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
References: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
Message-ID: <CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>

Until now we have only supported database migration from Final to Final,
i.e. not from CR1 to .Final. So when a change happened in between CR1 and
Final, we did not care. What will be the supported path now? Will we
support migrating from Beta1 to Beta2 to Beta3 to Final or only from Final
to Final? I'd rather the latter but it seems we'll have to support the
former.

On Tue, Feb 6, 2018 at 8:22 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> As we've started working in 3 week sprints we are considering a new release
> model for Keycloak.
>
> What we are considering is doing a Beta release for every sprint, then for
> every 4th sprint (each quarter) we plan to do a Final release.
>
> For a beta release existing features will be considered stable, while new
> features may not be ready for prime time. The recommendation will still be
> to upgrade to always update to the latest release to receive the latest
> security fixes and other fixes.
>
> However, care should be taken before using new features in production until
> a Final release is available.
>
> Thoughts?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--Hynek

From adr_gonzalez at yahoo.fr  Tue Feb  6 16:09:56 2018
From: adr_gonzalez at yahoo.fr (Adrian Gonzalez)
Date: Tue, 6 Feb 2018 21:09:56 +0000 (UTC)
Subject: [keycloak-dev] Hot reload JBoss modules
References: <1329120254.7079186.1517951396352.ref@mail.yahoo.com>
Message-ID: <1329120254.7079186.1517951396352@mail.yahoo.com>

Hello,
I developed a little Spi (org.keycloak.provider.Spi).
I tried to deploy it the usual way (mvn clean install wildfly:deploy), but it doesn't work.I need to deploy it as a JBoss module.

Is there a way to avoid restarting JBoss when redepoying a JBoss module ?
For the moment, I'm doing:
```mvn clean package$KEYCLOAK_HOME/bin/jboss-cli.sh --command="module remove --name=org.gonzalad.keycloak.idp.idp-service"$KEYCLOAK_HOME/bin/jboss-cli.sh --command="module add --name=org.gonzalad.keycloak.idp.idp-service --resources=target/idp-service-0.0.1-SNAPSHOT.jar --dependencies=javax.ws.rs.api,javax.persistence.api,org.hibernate,org.javassist,org.keycloak.keycloak-core,org.keycloak.keycloak-server-spi,org.keycloak.keycloak-server-spi-private,org.keycloak.keycloak-services,org.keycloak.keycloak-model-jpa,org.jboss.logging"$KEYCLOAK_HOME/bin/standalone.sh --debug```
Thanks,Adrian?

From thomas.darimont at googlemail.com  Tue Feb  6 18:53:06 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 7 Feb 2018 00:53:06 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAfNO0b_678c2-Ai8GLhjbjnJOrbJjaUorsf4jmbc9zJZA@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<CAJgngAfNO0b_678c2-Ai8GLhjbjnJOrbJjaUorsf4jmbc9zJZA@mail.gmail.com>
Message-ID: <CAK-7U1jZTvUDtiuAo=C8oHQUmGGRwGtcu-QJHPm6A4OS=YO-6Q@mail.gmail.com>

How about custom user account pages?

Cheers,
Thomas

2018-02-06 20:03 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Oh and U2F will most likely land in U2F. Feedback on my experimental
> implementation would be great as well :)
>
> On 6 February 2018 at 20:03, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> >
> >
> > On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
> >
> >> Hi Stian, nice feature! Is it limited to login themes?
> >>
> >
> > Nah, it's a generic theme feature.
> >
> > Not sure I can see any use-cases other than custom providers that need
> > additional templates though. At the moment I can only think of
> > authenticators and required actions.
> >
> > Did you have any other use-cases in mind?
> >
> >
> >>
> >> BTW the correct link is https://github.com/stianst/
> >> keycloak-experimental/tree/master/fido-u2f
> >>
> >> Also nice to hear that the work has finally started on U2F, it's indeed
> a
> >> must-have feature today. Is it slated for 4.0.0?
> >>
> >> Dmitry
> >>
> >> I was experimenting with a custom authenticator and found it annoying
> that
> >> I had to copy templates manually to the themes directory.
> >>
> >> To resolve this I added a Theme Resource Provider SPI.
> >>
> >> A theme resource provider can provide additional templates and/or
> resources
> >> alongside the custom authenticator.
> >>
> >> Themes are always searched first for templates and resources. Template
> >> resource providers are only searched if not found in themes. This is
> >> important as it allows a theme to override the templates and/or
> resources
> >> provided by a theme resource provider.
> >>
> >> The code is ready in the PR https://github.com/keycloak/
> keycloak/pull/4971
> >>
> >> For an example on how it's used take a look at
> >> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
> >> _______________________________________________
> >> 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  Wed Feb  7 02:31:48 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Feb 2018 08:31:48 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAK-7U1jZTvUDtiuAo=C8oHQUmGGRwGtcu-QJHPm6A4OS=YO-6Q@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<CAJgngAfNO0b_678c2-Ai8GLhjbjnJOrbJjaUorsf4jmbc9zJZA@mail.gmail.com>
	<CAK-7U1jZTvUDtiuAo=C8oHQUmGGRwGtcu-QJHPm6A4OS=YO-6Q@mail.gmail.com>
Message-ID: <CAJgngAcNSmCXYgPshehHA2P8LDbjBJWgrP0wk_bT3TsmWkTp=Q@mail.gmail.com>

That may make sense, but right now the account management console is not
really extensible. Would actually be pretty nice to have an SPI to be able
to deploy extensions to the account management console. The extensions
would need a number of SPIs

* ThemeResourceProvider - to add resources
* AccountResourceProvider - to add additional rest endpoints to account
services
* AccountPageProvider - to register new pages into the menu (or something
along this line)

On 7 February 2018 at 00:53, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> How about custom user account pages?
>
> Cheers,
> Thomas
>
> 2018-02-06 20:03 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Oh and U2F will most likely land in U2F. Feedback on my experimental
>> implementation would be great as well :)
>>
>> On 6 February 2018 at 20:03, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>> >
>> >
>> > On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>> >
>> >> Hi Stian, nice feature! Is it limited to login themes?
>> >>
>> >
>> > Nah, it's a generic theme feature.
>> >
>> > Not sure I can see any use-cases other than custom providers that need
>> > additional templates though. At the moment I can only think of
>> > authenticators and required actions.
>> >
>> > Did you have any other use-cases in mind?
>> >
>> >
>> >>
>> >> BTW the correct link is https://github.com/stianst/
>> >> keycloak-experimental/tree/master/fido-u2f
>> >>
>> >> Also nice to hear that the work has finally started on U2F, it's
>> indeed a
>> >> must-have feature today. Is it slated for 4.0.0?
>> >>
>> >> Dmitry
>> >>
>> >> I was experimenting with a custom authenticator and found it annoying
>> that
>> >> I had to copy templates manually to the themes directory.
>> >>
>> >> To resolve this I added a Theme Resource Provider SPI.
>> >>
>> >> A theme resource provider can provide additional templates and/or
>> resources
>> >> alongside the custom authenticator.
>> >>
>> >> Themes are always searched first for templates and resources. Template
>> >> resource providers are only searched if not found in themes. This is
>> >> important as it allows a theme to override the templates and/or
>> resources
>> >> provided by a theme resource provider.
>> >>
>> >> The code is ready in the PR https://github.com/keycloak/ke
>> ycloak/pull/4971
>> >>
>> >> For an example on how it's used take a look at
>> >> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>> >> _______________________________________________
>> >> 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  Wed Feb  7 02:44:38 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Feb 2018 08:44:38 +0100
Subject: [keycloak-dev] Updated release cadence
In-Reply-To: <CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>
References: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
	<CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>
Message-ID: <CAJgngAdUttW+Bb-aB0knE5znEW0d=OaNkE5SehWgzahtcLpFTw@mail.gmail.com>

We would need to support migration between beta releases.

On 6 February 2018 at 21:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Until now we have only supported database migration from Final to Final,
> i.e. not from CR1 to .Final. So when a change happened in between CR1 and
> Final, we did not care. What will be the supported path now? Will we
> support migrating from Beta1 to Beta2 to Beta3 to Final or only from Final
> to Final? I'd rather the latter but it seems we'll have to support the
> former.
>
> On Tue, Feb 6, 2018 at 8:22 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> As we've started working in 3 week sprints we are considering a new
>> release
>> model for Keycloak.
>>
>> What we are considering is doing a Beta release for every sprint, then for
>> every 4th sprint (each quarter) we plan to do a Final release.
>>
>> For a beta release existing features will be considered stable, while new
>> features may not be ready for prime time. The recommendation will still be
>> to upgrade to always update to the latest release to receive the latest
>> security fixes and other fixes.
>>
>> However, care should be taken before using new features in production
>> until
>> a Final release is available.
>>
>> Thoughts?
>> _______________________________________________
>> 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 Feb  7 04:53:50 2018
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 7 Feb 2018 10:53:50 +0100
Subject: [keycloak-dev] Updated release cadence
In-Reply-To: <CAJgngAdUttW+Bb-aB0knE5znEW0d=OaNkE5SehWgzahtcLpFTw@mail.gmail.com>
References: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
	<CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>
	<CAJgngAdUttW+Bb-aB0knE5znEW0d=OaNkE5SehWgzahtcLpFTw@mail.gmail.com>
Message-ID: <CAMvXD=HZ7S++Q5nojWvOnTvch1EzrTEQOJa0Z0i81cLVfcqTnw@mail.gmail.com>

Then until we are able to check DBs at PR level, we should run at least
start Keycloak on all supported DBs before promoting Beta release to make
sure the changelogs are sane - to prevent issues like [1, 2]

[1] https://issues.jboss.org/browse/KEYCLOAK-5235
[2] https://issues.jboss.org/browse/KEYCLOAK-5416

On Wed, Feb 7, 2018 at 8:44 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We would need to support migration between beta releases.
>
> On 6 February 2018 at 21:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>
>> Until now we have only supported database migration from Final to Final,
>> i.e. not from CR1 to .Final. So when a change happened in between CR1 and
>> Final, we did not care. What will be the supported path now? Will we
>> support migrating from Beta1 to Beta2 to Beta3 to Final or only from Final
>> to Final? I'd rather the latter but it seems we'll have to support the
>> former.
>>
>> On Tue, Feb 6, 2018 at 8:22 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> As we've started working in 3 week sprints we are considering a new
>>> release
>>> model for Keycloak.
>>>
>>> What we are considering is doing a Beta release for every sprint, then
>>> for
>>> every 4th sprint (each quarter) we plan to do a Final release.
>>>
>>> For a beta release existing features will be considered stable, while new
>>> features may not be ready for prime time. The recommendation will still
>>> be
>>> to upgrade to always update to the latest release to receive the latest
>>> security fixes and other fixes.
>>>
>>> However, care should be taken before using new features in production
>>> until
>>> a Final release is available.
>>>
>>> Thoughts?
>>> _______________________________________________
>>> 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 Feb  7 05:26:10 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Feb 2018 11:26:10 +0100
Subject: [keycloak-dev] Updated release cadence
In-Reply-To: <CAMvXD=HZ7S++Q5nojWvOnTvch1EzrTEQOJa0Z0i81cLVfcqTnw@mail.gmail.com>
References: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
	<CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>
	<CAJgngAdUttW+Bb-aB0knE5znEW0d=OaNkE5SehWgzahtcLpFTw@mail.gmail.com>
	<CAMvXD=HZ7S++Q5nojWvOnTvch1EzrTEQOJa0Z0i81cLVfcqTnw@mail.gmail.com>
Message-ID: <CAJgngAeqV1ENdXjVECVogP5s7mkmFkdS1z6Du7rODh2uqhJE3Q@mail.gmail.com>

Agreed - we need to run the old CI setup before every release (Beta and
Final)

On 7 February 2018 at 10:53, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> Then until we are able to check DBs at PR level, we should run at least
> start Keycloak on all supported DBs before promoting Beta release to make
> sure the changelogs are sane - to prevent issues like [1, 2]
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-5235
> [2] https://issues.jboss.org/browse/KEYCLOAK-5416
>
> On Wed, Feb 7, 2018 at 8:44 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We would need to support migration between beta releases.
>>
>> On 6 February 2018 at 21:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>>> Until now we have only supported database migration from Final to Final,
>>> i.e. not from CR1 to .Final. So when a change happened in between CR1 and
>>> Final, we did not care. What will be the supported path now? Will we
>>> support migrating from Beta1 to Beta2 to Beta3 to Final or only from Final
>>> to Final? I'd rather the latter but it seems we'll have to support the
>>> former.
>>>
>>> On Tue, Feb 6, 2018 at 8:22 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> As we've started working in 3 week sprints we are considering a new
>>>> release
>>>> model for Keycloak.
>>>>
>>>> What we are considering is doing a Beta release for every sprint, then
>>>> for
>>>> every 4th sprint (each quarter) we plan to do a Final release.
>>>>
>>>> For a beta release existing features will be considered stable, while
>>>> new
>>>> features may not be ready for prime time. The recommendation will still
>>>> be
>>>> to upgrade to always update to the latest release to receive the latest
>>>> security fixes and other fixes.
>>>>
>>>> However, care should be taken before using new features in production
>>>> until
>>>> a Final release is available.
>>>>
>>>> Thoughts?
>>>> _______________________________________________
>>>> 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 Feb  7 05:29:15 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 7 Feb 2018 11:29:15 +0100
Subject: [keycloak-dev] Updated release cadence
In-Reply-To: <CAJgngAeqV1ENdXjVECVogP5s7mkmFkdS1z6Du7rODh2uqhJE3Q@mail.gmail.com>
References: <CAJgngAfOfGJWSwxSTrx2tQPnhuBGePc+o+QHiHCq2LbatQAVNg@mail.gmail.com>
	<CAMvXD=EP+Jp1C3dBky+b-rWpHidUccgwaXOj4dHP4Oa8qUubUw@mail.gmail.com>
	<CAJgngAdUttW+Bb-aB0knE5znEW0d=OaNkE5SehWgzahtcLpFTw@mail.gmail.com>
	<CAMvXD=HZ7S++Q5nojWvOnTvch1EzrTEQOJa0Z0i81cLVfcqTnw@mail.gmail.com>
	<CAJgngAeqV1ENdXjVECVogP5s7mkmFkdS1z6Du7rODh2uqhJE3Q@mail.gmail.com>
Message-ID: <CAJgngAd0BfMnRJzUjKHL03Dt_TG+3amNiJsvmFSbnUbBJUkBRQ@mail.gmail.com>

Adding something around fixes.

A final release would not receive any backported bug fixes. For those that
want supported versions there is RH-SSO.

We should however do backporting of critical security issues. We would only
backport security fixes to the current Final release.

So we could have the following releases:

* 4.0.0.Beta1/2/3
* 4.0.0.Final
* 4.1.0.Beta1/2/3
* 4.1.0.Final
* 4.2.0.Beta1
* 4.1.1.Final (to include a single critical security vulnerability, note
there would be no 4.0.1.Final)

On 7 February 2018 at 11:26, Stian Thorgersen <sthorger at redhat.com> wrote:

> Agreed - we need to run the old CI setup before every release (Beta and
> Final)
>
> On 7 February 2018 at 10:53, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>
>> Then until we are able to check DBs at PR level, we should run at least
>> start Keycloak on all supported DBs before promoting Beta release to make
>> sure the changelogs are sane - to prevent issues like [1, 2]
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-5235
>> [2] https://issues.jboss.org/browse/KEYCLOAK-5416
>>
>> On Wed, Feb 7, 2018 at 8:44 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We would need to support migration between beta releases.
>>>
>>> On 6 February 2018 at 21:01, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>>
>>>> Until now we have only supported database migration from Final to
>>>> Final, i.e. not from CR1 to .Final. So when a change happened in between
>>>> CR1 and Final, we did not care. What will be the supported path now? Will
>>>> we support migrating from Beta1 to Beta2 to Beta3 to Final or only from
>>>> Final to Final? I'd rather the latter but it seems we'll have to support
>>>> the former.
>>>>
>>>> On Tue, Feb 6, 2018 at 8:22 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> As we've started working in 3 week sprints we are considering a new
>>>>> release
>>>>> model for Keycloak.
>>>>>
>>>>> What we are considering is doing a Beta release for every sprint, then
>>>>> for
>>>>> every 4th sprint (each quarter) we plan to do a Final release.
>>>>>
>>>>> For a beta release existing features will be considered stable, while
>>>>> new
>>>>> features may not be ready for prime time. The recommendation will
>>>>> still be
>>>>> to upgrade to always update to the latest release to receive the latest
>>>>> security fixes and other fixes.
>>>>>
>>>>> However, care should be taken before using new features in production
>>>>> until
>>>>> a Final release is available.
>>>>>
>>>>> Thoughts?
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --Hynek
>>>>
>>>
>>>
>>
>>
>> --
>>
>> --Hynek
>>
>
>

From mposolda at redhat.com  Thu Feb  8 04:37:53 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Feb 2018 10:37:53 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
Message-ID: <028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>

Good stuff.

I wonder if we can improve usability even more. As people will need to 
implement ThemeResourceProvider. And IMO in 95% of cases, they will use 
templates from the JAR with their provider, so they would need to add 
some boilerplate code like this: 
https://github.com/stianst/keycloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/java/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22 
.

I am thinking if we can add default implementation of 
ThemeResourceProvider, which will scan classpath of the deployed 
provider archives automatically and find the resources from there? 
People won't need to implement their own ThemeResourceProvider, they 
will just need to add their templates into some directory like 
"src/main/resources/themes" or something like that. Maybe we can achieve 
this by adding ProviderEvent, which will be triggered on deploy/undeploy 
of any provider? Default ThemeResourceProvider will be able to listen to 
that and register/unregister classloaders of deployed providers 
automatically.

WDYT?
Marek

On 06/02/18 20:03, Stian Thorgersen wrote:
> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
>> Hi Stian, nice feature! Is it limited to login themes?
>>
> Nah, it's a generic theme feature.
>
> Not sure I can see any use-cases other than custom providers that need
> additional templates though. At the moment I can only think of
> authenticators and required actions.
>
> Did you have any other use-cases in mind?
>
>
>> BTW the correct link is https://github.com/stianst/
>> keycloak-experimental/tree/master/fido-u2f
>>
>> Also nice to hear that the work has finally started on U2F, it's indeed a
>> must-have feature today. Is it slated for 4.0.0?
>>
>> Dmitry
>>
>> I was experimenting with a custom authenticator and found it annoying that
>> I had to copy templates manually to the themes directory.
>>
>> To resolve this I added a Theme Resource Provider SPI.
>>
>> A theme resource provider can provide additional templates and/or resources
>> alongside the custom authenticator.
>>
>> Themes are always searched first for templates and resources. Template
>> resource providers are only searched if not found in themes. This is
>> important as it allows a theme to override the templates and/or resources
>> provided by a theme resource provider.
>>
>> The code is ready in the PR https://github.com/keycloak/keycloak/pull/4971
>>
>> For an example on how it's used take a look at
>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>> _______________________________________________
>> 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  Thu Feb  8 05:12:36 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Feb 2018 11:12:36 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>
Message-ID: <CAJgngAeDoRwWp7ukstmRHLFxowXxZRrQjbhH4+mAN9sne-vOzA@mail.gmail.com>

That may be cool, but think it's a fair amount of work to implement
something like that.

I added a simpler approach with an abstract class
(AbstractClasspathThemeResourceProviderFactory). Now folks only need to add
bits to theme/resource and/or theme/templates,
extend AbstractClasspathThemeResourceProviderFactory and only implement
getId method. That's it.

On 8 February 2018 at 10:37, Marek Posolda <mposolda at redhat.com> wrote:

> Good stuff.
>
> I wonder if we can improve usability even more. As people will need to
> implement ThemeResourceProvider. And IMO in 95% of cases, they will use
> templates from the JAR with their provider, so they would need to add some
> boilerplate code like this: https://github.com/stianst/key
> cloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/
> java/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22 .
>
> I am thinking if we can add default implementation of
> ThemeResourceProvider, which will scan classpath of the deployed provider
> archives automatically and find the resources from there? People won't need
> to implement their own ThemeResourceProvider, they will just need to add
> their templates into some directory like "src/main/resources/themes" or
> something like that. Maybe we can achieve this by adding ProviderEvent,
> which will be triggered on deploy/undeploy of any provider? Default
> ThemeResourceProvider will be able to listen to that and
> register/unregister classloaders of deployed providers automatically.
>
> WDYT?
> Marek
>
>
> On 06/02/18 20:03, Stian Thorgersen wrote:
>
>> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>>
>> Hi Stian, nice feature! Is it limited to login themes?
>>>
>>> Nah, it's a generic theme feature.
>>
>> Not sure I can see any use-cases other than custom providers that need
>> additional templates though. At the moment I can only think of
>> authenticators and required actions.
>>
>> Did you have any other use-cases in mind?
>>
>>
>> BTW the correct link is https://github.com/stianst/
>>> keycloak-experimental/tree/master/fido-u2f
>>>
>>> Also nice to hear that the work has finally started on U2F, it's indeed a
>>> must-have feature today. Is it slated for 4.0.0?
>>>
>>> Dmitry
>>>
>>> I was experimenting with a custom authenticator and found it annoying
>>> that
>>> I had to copy templates manually to the themes directory.
>>>
>>> To resolve this I added a Theme Resource Provider SPI.
>>>
>>> A theme resource provider can provide additional templates and/or
>>> resources
>>> alongside the custom authenticator.
>>>
>>> Themes are always searched first for templates and resources. Template
>>> resource providers are only searched if not found in themes. This is
>>> important as it allows a theme to override the templates and/or resources
>>> provided by a theme resource provider.
>>>
>>> The code is ready in the PR https://github.com/keycloak/ke
>>> ycloak/pull/4971
>>>
>>> For an example on how it's used take a look at
>>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>>> _______________________________________________
>>> 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  Thu Feb  8 06:30:43 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Feb 2018 12:30:43 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAeDoRwWp7ukstmRHLFxowXxZRrQjbhH4+mAN9sne-vOzA@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>
	<CAJgngAeDoRwWp7ukstmRHLFxowXxZRrQjbhH4+mAN9sne-vOzA@mail.gmail.com>
Message-ID: <CAJgngAd+UqgCGyhAtvSNpU3Jde9a6j9vGBDzSsPamyFT6pfemg@mail.gmail.com>

Damn you! I'm now looking at adding some magic touch to automatically
detect theme-resources inside a deployment.

On 8 February 2018 at 11:12, Stian Thorgersen <sthorger at redhat.com> wrote:

> That may be cool, but think it's a fair amount of work to implement
> something like that.
>
> I added a simpler approach with an abstract class (
> AbstractClasspathThemeResourceProviderFactory). Now folks only need to
> add bits to theme/resource and/or theme/templates, extend
> AbstractClasspathThemeResourceProviderFactory and only implement getId
> method. That's it.
>
> On 8 February 2018 at 10:37, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Good stuff.
>>
>> I wonder if we can improve usability even more. As people will need to
>> implement ThemeResourceProvider. And IMO in 95% of cases, they will use
>> templates from the JAR with their provider, so they would need to add some
>> boilerplate code like this: https://github.com/stianst/key
>> cloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/jav
>> a/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22 .
>>
>> I am thinking if we can add default implementation of
>> ThemeResourceProvider, which will scan classpath of the deployed provider
>> archives automatically and find the resources from there? People won't need
>> to implement their own ThemeResourceProvider, they will just need to add
>> their templates into some directory like "src/main/resources/themes" or
>> something like that. Maybe we can achieve this by adding ProviderEvent,
>> which will be triggered on deploy/undeploy of any provider? Default
>> ThemeResourceProvider will be able to listen to that and
>> register/unregister classloaders of deployed providers automatically.
>>
>> WDYT?
>> Marek
>>
>>
>> On 06/02/18 20:03, Stian Thorgersen wrote:
>>
>>> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>>>
>>> Hi Stian, nice feature! Is it limited to login themes?
>>>>
>>>> Nah, it's a generic theme feature.
>>>
>>> Not sure I can see any use-cases other than custom providers that need
>>> additional templates though. At the moment I can only think of
>>> authenticators and required actions.
>>>
>>> Did you have any other use-cases in mind?
>>>
>>>
>>> BTW the correct link is https://github.com/stianst/
>>>> keycloak-experimental/tree/master/fido-u2f
>>>>
>>>> Also nice to hear that the work has finally started on U2F, it's indeed
>>>> a
>>>> must-have feature today. Is it slated for 4.0.0?
>>>>
>>>> Dmitry
>>>>
>>>> I was experimenting with a custom authenticator and found it annoying
>>>> that
>>>> I had to copy templates manually to the themes directory.
>>>>
>>>> To resolve this I added a Theme Resource Provider SPI.
>>>>
>>>> A theme resource provider can provide additional templates and/or
>>>> resources
>>>> alongside the custom authenticator.
>>>>
>>>> Themes are always searched first for templates and resources. Template
>>>> resource providers are only searched if not found in themes. This is
>>>> important as it allows a theme to override the templates and/or
>>>> resources
>>>> provided by a theme resource provider.
>>>>
>>>> The code is ready in the PR https://github.com/keycloak/ke
>>>> ycloak/pull/4971
>>>>
>>>> For an example on how it's used take a look at
>>>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>>>> _______________________________________________
>>>> 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  Thu Feb  8 14:06:26 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Feb 2018 20:06:26 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAd+UqgCGyhAtvSNpU3Jde9a6j9vGBDzSsPamyFT6pfemg@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>
	<CAJgngAeDoRwWp7ukstmRHLFxowXxZRrQjbhH4+mAN9sne-vOzA@mail.gmail.com>
	<CAJgngAd+UqgCGyhAtvSNpU3Jde9a6j9vGBDzSsPamyFT6pfemg@mail.gmail.com>
Message-ID: <CAJgngAdKjpN_gCG4BAQhaOFHyztrtg=GpD3UBBmhmWQ4-V+GLA@mail.gmail.com>

OK, so now I've added support to load theme resources dynamically from a
hot deployment. All you need to do now to add templates and resources to a
hot deployed JAR is:

* Add templates to "theme-resources/templates" and resources inside
"theme-resources/resources"

See https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f
for an example.

Also, added support for hot deployment of themes. For that all you need to
do is:

* Add META-INF/keycloak-themes.json
* Add theme files to "theme"

See https://github.com/stianst/keycloak-experimental/tree/master/themes for
an example.

On 8 February 2018 at 12:30, Stian Thorgersen <sthorger at redhat.com> wrote:

> Damn you! I'm now looking at adding some magic touch to automatically
> detect theme-resources inside a deployment.
>
> On 8 February 2018 at 11:12, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> That may be cool, but think it's a fair amount of work to implement
>> something like that.
>>
>> I added a simpler approach with an abstract class
>> (AbstractClasspathThemeResourceProviderFactory). Now folks only need to
>> add bits to theme/resource and/or theme/templates,
>> extend AbstractClasspathThemeResourceProviderFactory and only implement
>> getId method. That's it.
>>
>> On 8 February 2018 at 10:37, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Good stuff.
>>>
>>> I wonder if we can improve usability even more. As people will need to
>>> implement ThemeResourceProvider. And IMO in 95% of cases, they will use
>>> templates from the JAR with their provider, so they would need to add some
>>> boilerplate code like this: https://github.com/stianst/key
>>> cloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/jav
>>> a/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22 .
>>>
>>> I am thinking if we can add default implementation of
>>> ThemeResourceProvider, which will scan classpath of the deployed provider
>>> archives automatically and find the resources from there? People won't need
>>> to implement their own ThemeResourceProvider, they will just need to add
>>> their templates into some directory like "src/main/resources/themes" or
>>> something like that. Maybe we can achieve this by adding ProviderEvent,
>>> which will be triggered on deploy/undeploy of any provider? Default
>>> ThemeResourceProvider will be able to listen to that and
>>> register/unregister classloaders of deployed providers automatically.
>>>
>>> WDYT?
>>> Marek
>>>
>>>
>>> On 06/02/18 20:03, Stian Thorgersen wrote:
>>>
>>>> On 6 February 2018 at 18:42, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>>>>
>>>> Hi Stian, nice feature! Is it limited to login themes?
>>>>>
>>>>> Nah, it's a generic theme feature.
>>>>
>>>> Not sure I can see any use-cases other than custom providers that need
>>>> additional templates though. At the moment I can only think of
>>>> authenticators and required actions.
>>>>
>>>> Did you have any other use-cases in mind?
>>>>
>>>>
>>>> BTW the correct link is https://github.com/stianst/
>>>>> keycloak-experimental/tree/master/fido-u2f
>>>>>
>>>>> Also nice to hear that the work has finally started on U2F, it's
>>>>> indeed a
>>>>> must-have feature today. Is it slated for 4.0.0?
>>>>>
>>>>> Dmitry
>>>>>
>>>>> I was experimenting with a custom authenticator and found it annoying
>>>>> that
>>>>> I had to copy templates manually to the themes directory.
>>>>>
>>>>> To resolve this I added a Theme Resource Provider SPI.
>>>>>
>>>>> A theme resource provider can provide additional templates and/or
>>>>> resources
>>>>> alongside the custom authenticator.
>>>>>
>>>>> Themes are always searched first for templates and resources. Template
>>>>> resource providers are only searched if not found in themes. This is
>>>>> important as it allows a theme to override the templates and/or
>>>>> resources
>>>>> provided by a theme resource provider.
>>>>>
>>>>> The code is ready in the PR https://github.com/keycloak/ke
>>>>> ycloak/pull/4971
>>>>>
>>>>> For an example on how it's used take a look at
>>>>> https://github.com/stianst/keycloak-experimental/tree/master/u2f.
>>>>> _______________________________________________
>>>>> 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  Thu Feb  8 14:22:59 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 8 Feb 2018 20:22:59 +0100
Subject: [keycloak-dev] FIDO UAF
Message-ID: <CAJgngAe7jOTvmrmQUqbbgJfyigvghO=AsMDycuhYhR7t=LVa4g@mail.gmail.com>

Anyone here interested in FIDO UAF? I'd be interested to have a
conversation about it.

From mposolda at redhat.com  Thu Feb  8 15:54:06 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 8 Feb 2018 21:54:06 +0100
Subject: [keycloak-dev] Theme resource provider - ability for custom
 authenticators to load additional templates
In-Reply-To: <CAJgngAdKjpN_gCG4BAQhaOFHyztrtg=GpD3UBBmhmWQ4-V+GLA@mail.gmail.com>
References: <CAJgngAexupRsN+z6WgVdkJdqojdirMo=h9xiqqTVb6gmUbRc6A@mail.gmail.com>
	<1517938953.6946.1.camel@cargosoft.ru>
	<CAJgngAe8AvBkpR8GfBzDNig97+B03SBDWW7CbavL-=JA6oxCJQ@mail.gmail.com>
	<028fe2f2-c2ea-9dc3-f9b8-f4645e5b5c28@redhat.com>
	<CAJgngAeDoRwWp7ukstmRHLFxowXxZRrQjbhH4+mAN9sne-vOzA@mail.gmail.com>
	<CAJgngAd+UqgCGyhAtvSNpU3Jde9a6j9vGBDzSsPamyFT6pfemg@mail.gmail.com>
	<CAJgngAdKjpN_gCG4BAQhaOFHyztrtg=GpD3UBBmhmWQ4-V+GLA@mail.gmail.com>
Message-ID: <ddfd6961-25a3-6798-b81f-5fdda455bb33@redhat.com>

Nice!

Dne 8.2.2018 v 20:06 Stian Thorgersen napsal(a):
> OK, so now I've added support to load theme resources dynamically from 
> a hot deployment. All you need to do now to add templates and 
> resources to a hot deployed JAR is:
>
> * Add templates to "theme-resources/templates" and resources inside 
> "theme-resources/resources"
>
> See 
> https://github.com/stianst/keycloak-experimental/tree/master/fido-u2f 
> for an example.
>
> Also, added support for hot deployment of themes. For that all you 
> need to do is:
>
> * Add META-INF/keycloak-themes.json
> * Add theme files to "theme"
>
> See 
> https://github.com/stianst/keycloak-experimental/tree/master/themes 
> for an example.
>
> On 8 February 2018 at 12:30, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     Damn you! I'm now looking at adding some magic touch to
>     automatically detect theme-resources inside a deployment.
>
>     On 8 February 2018 at 11:12, Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>
>         That may be cool, but think it's a fair amount of work to
>         implement something like that.
>
>         I added a simpler approach with an abstract class
>         (AbstractClasspathThemeResourceProviderFactory). Now folks
>         only need to add bits to theme/resource and/or
>         theme/templates,
>         extend?AbstractClasspathThemeResourceProviderFactory and only
>         implement getId method. That's it.
>
>         On 8 February 2018 at 10:37, Marek Posolda
>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>
>             Good stuff.
>
>             I wonder if we can improve usability even more. As people
>             will need to implement ThemeResourceProvider. And IMO in
>             95% of cases, they will use templates from the JAR with
>             their provider, so they would need to add some boilerplate
>             code like this:
>             https://github.com/stianst/keycloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/java/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22
>             <https://github.com/stianst/keycloak-experimental/blob/master/fido-u2f/u2f-ejb/src/main/java/org/keycloak/experimental/u2f/U2FThemeResourceProvider.java#L20-L22>
>             .
>
>             I am thinking if we can add default implementation of
>             ThemeResourceProvider, which will scan classpath of the
>             deployed provider archives automatically and find the
>             resources from there? People won't need to implement their
>             own ThemeResourceProvider, they will just need to add
>             their templates into some directory like
>             "src/main/resources/themes" or something like that. Maybe
>             we can achieve this by adding ProviderEvent, which will be
>             triggered on deploy/undeploy of any provider? Default
>             ThemeResourceProvider will be able to listen to that and
>             register/unregister classloaders of deployed providers
>             automatically.
>
>             WDYT?
>             Marek
>
>
>             On 06/02/18 20:03, Stian Thorgersen wrote:
>
>                 On 6 February 2018 at 18:42, Dmitry Telegin
>                 <mitya at cargosoft.ru <mailto:mitya at cargosoft.ru>> wrote:
>
>                     Hi Stian, nice feature! Is it limited to login themes?
>
>                 Nah, it's a generic theme feature.
>
>                 Not sure I can see any use-cases other than custom
>                 providers that need
>                 additional templates though. At the moment I can only
>                 think of
>                 authenticators and required actions.
>
>                 Did you have any other use-cases in mind?
>
>
>                     BTW the correct link is https://github.com/stianst/
>                     keycloak-experimental/tree/master/fido-u2f
>
>                     Also nice to hear that the work has finally
>                     started on U2F, it's indeed a
>                     must-have feature today. Is it slated for 4.0.0?
>
>                     Dmitry
>
>                     I was experimenting with a custom authenticator
>                     and found it annoying that
>                     I had to copy templates manually to the themes
>                     directory.
>
>                     To resolve this I added a Theme Resource Provider SPI.
>
>                     A theme resource provider can provide additional
>                     templates and/or resources
>                     alongside the custom authenticator.
>
>                     Themes are always searched first for templates and
>                     resources. Template
>                     resource providers are only searched if not found
>                     in themes. This is
>                     important as it allows a theme to override the
>                     templates and/or resources
>                     provided by a theme resource provider.
>
>                     The code is ready in the PR
>                     https://github.com/keycloak/keycloak/pull/4971
>                     <https://github.com/keycloak/keycloak/pull/4971>
>
>                     For an example on how it's used take a look at
>                     https://github.com/stianst/keycloak-experimental/tree/master/u2f
>                     <https://github.com/stianst/keycloak-experimental/tree/master/u2f>.
>                     _______________________________________________
>                     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 ssilvert at redhat.com  Fri Feb  9 07:59:24 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 9 Feb 2018 07:59:24 -0500
Subject: [keycloak-dev] Keycloak and Angluar CLI
Message-ID: <4327d864-0613-e8ae-aefe-2438a46e368e@redhat.com>

Just published a new blog post on integration of Keycloak and the 
Angular CLI.
http://blog.keycloak.org/2018/02/keycloak-and-angular-cli.html

If you want to see documentation and a more comprehensive Getting 
Started Guide, go here:
https://github.com/ssilvert/keycloak-schematic/wiki/Getting-Started

Also, if anybody can tell me how to make the links in the blog post show 
up properly, I'd appreciate it.  Right now, you can barely tell that the 
links are links.  Stupid Blogger.com.

Stan

From mposolda at redhat.com  Fri Feb  9 08:30:18 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 9 Feb 2018 14:30:18 +0100
Subject: [keycloak-dev] Scope parameter support
Message-ID: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>

Hi,

started looking at OAuth Scope parameter support. Wanted to clarify some 
things before start implementing:

- Client Scope will allow to group protocolMappers and Role Scope 
Mappings. Pretty similar to current Client Template


- Do we want to get rid of "Client templates" entirely and rename them 
to "Client Scopes" ? Or introduce Client scopes as separate thing in 
addition to client templates? My vote is to rename and get rid of client 
templates. It would mean get rid of new option "Login theme" from client 
template (client scope) then? As otherwise is unclear from which Client 
Scope will client inherit it (assuming client can be inherit from 
multiple Client Scopes, not just from single Client Template like is now).


- Client can inherit from more Client Scopes. I can see 2 groups:
-- Default Client Scopes - Those will be applied even if not requested 
by OIDC scope parameter
-- Optional Client Scopes - Those will be applied just if requested by 
OIDC scope parameter


- Do we still want to keep ProtocolMappers per client and 
Role-Scope-Mappings per client? I can imagine we get rid of them and let 
them to be completely inherited from "Client Scopes" . My vote is yes. 
Just afraid if there are some issues with it like:
-- backwards compatibility and migration -- But hope that's manageable
-- Option "Full Scope Allowed" from role scope mappings -- but that 
should be solvable too (See below)


- Consent screen:
-- Currently we have set of protocolMappers and set of roles on consent 
screen. I assume we want to get rid of this and have just single thing: 
Set of client scopes. Correct?
-- If yes, how to proceed with the protocolMappers and Role Scope 
Mappings, which are defined directly on the client? If we get rid of 
them (as I mentioned above), we don't have this issue. If we don't get 
rid of them, we can have something like "Default consent", which 
encapsulates all the protocolMappers and Role Scope Mappings declared 
directly on client. WDYT?


- Option "Is Consent Required" and "COnsent Text" on protocol mappers - 
Do we want to remove those? I think yes.


- Option "Full Scope Allowed" on clients and option "Scope Param 
Required" on roles.
-- I can imagine we remove both and replace them by having special 
builtin Client Scope, which will automatically have all the roles (all 
realm roles and all client roles of all clients) added to itself.
-- When new client is created, it will automatically have this builtin 
Client Scope added to itself - because currently newly created clients 
also have "Full Scope Allowed" ON by default.
-- When new role is created, it will be automatically added to that 
builtin Client Scope.
-- Admin has ability to remove the roles from this Client Scope. This 
defacto has same meaning like previously "Scope Param Required" flag on 
role, which is curently used for "offline_acces" role.


- I was thinking about creating some UI in admin console for "Scope 
Evaluating" . Admin will see effective roles and effective 
protocolMappers based on "scope" parameter he provides. I guess this 
doesn't have so big priority, but will be good to have IMO.


- UserConsentModel - do we remove roles and protocolMappers and replace 
them instead with Client Scopes? I think yes. Also change the 
"Applications" tab in account management accordingly and have the same 
"Client Scopes" like those, which were displayed on consent screen.


- Tokens - I think we still want to keep "Effective" claims and 
"effective" roles in tokens as is now? At least in first iteration.

WDYT?

Marek


From sthorger at redhat.com  Mon Feb 12 03:35:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Feb 2018 09:35:14 +0100
Subject: [keycloak-dev] [keycloak-user] Trojan in Keycloak Javascript
	Adapter?
In-Reply-To: <CAFzO_6cVzpdLqT4w8cOzMCBCCk3G8apOWYd24px410jqxzmP4w@mail.gmail.com>
References: <CAFzO_6eDDb+uG67_uPFAZTSq6YRfmfhmmJ0VE5AjdvO37UprVA@mail.gmail.com>
	<CAHYJo18jrXAHDRWBiAbbGkNrGVxyCxNkuW9tJL--7RPdM3okeA@mail.gmail.com>
	<CAFzO_6e5DK4b8Mtff85h0AE9KX5mzoj-S7TRxweULgRzQQSejw@mail.gmail.com>
	<CAFzO_6cVzpdLqT4w8cOzMCBCCk3G8apOWYd24px410jqxzmP4w@mail.gmail.com>
Message-ID: <CAJgngAcb0ikcOVCeGTEvSBZGMMGP1Nrc0Ad_Xkpi1Qu9Sy7=0A@mail.gmail.com>

Please try the files on https://www.microsoft.com/en-us/wdsi/filesubmission.
That will allow Microsoft to investigate the issue.

I've just submitted it myself and it comes back clean, so this seems to be
an issue in your environment. Maybe your computer is affected?

On 4 January 2018 at 15:52, Ariel Carrera <carreraariel at gmail.com> wrote:

> Hi, It still happen on my environment.
> The problem persists with the new version of today (3.4.3.Final).
>
> Any comments from the dev team? Could you check it?
>
> Maybe it's a false alarm but it could be a serious security problem.
>
> - Screenshot of Keycloak JS Adapter alert:
>
> [image: Im?genes integradas 1]
>
> - Screenshot of Keycloak distribution alert:
>
> [image: Im?genes integradas 2]
>
> - Screenshot of Virus Definitions Version:
> [image: Im?genes integradas 3]
>
> - Screenshot of Virus Definition Upgrade:
> [image: Im?genes integradas 4]
>
> - Screenshot of Keycloak JS Adapter alert again (with definitions up to
> date):
> [image: Im?genes integradas 5]
>
> Thanks,
>
> 2018-01-03 18:07 GMT-03:00 Ariel Carrera <carreraariel at gmail.com>:
>
> > Thanks Ramunas, I will check My Windows defender?s definition version to
> > compare with you. I have Windows 10 (64 bit) updated on December 2017.
> >
> >
> > El El mi?, 3 ene. 2018 a las 17:45, Rumanas <ramunask at gmail.com>
> escribi?:
> >
> >> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file
> >> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder
> >> with Windows Defender on Windows 10 - no issues found
> >> * checked for Windows updates. New update "Definition Update for Windows
> >> Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and
> >> installed.
> >> * scanned again. No issues found.
> >>
> >> Ram?nas
> >>
> > --
> > Ariel Carrera
> >
>
>
>
> --
> Ariel Carrera
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From sthorger at redhat.com  Mon Feb 12 03:49:36 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Feb 2018 09:49:36 +0100
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
References: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
Message-ID: <CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>

On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:

> Hi,
>
> started looking at OAuth Scope parameter support. Wanted to clarify some
> things before start implementing:
>
> - Client Scope will allow to group protocolMappers and Role Scope
> Mappings. Pretty similar to current Client Template
>
>
> - Do we want to get rid of "Client templates" entirely and rename them
> to "Client Scopes" ? Or introduce Client scopes as separate thing in
> addition to client templates? My vote is to rename and get rid of client
> templates. It would mean get rid of new option "Login theme" from client
> template (client scope) then? As otherwise is unclear from which Client
> Scope will client inherit it (assuming client can be inherit from
> multiple Client Scopes, not just from single Client Template like is now).
>

Removing "Login theme" from client template is fine.

Client templates do have a nice benefit of allowing defining some protocol
mappers and scope that is shared between clients. That can probably be done
by having the option to set a default scope for a client perhaps?


>
>
> - Client can inherit from more Client Scopes. I can see 2 groups:
> -- Default Client Scopes - Those will be applied even if not requested
> by OIDC scope parameter
> -- Optional Client Scopes - Those will be applied just if requested by
> OIDC scope parameter
>

For default client scope, is there global defaults as well as client
defaults?


>
>
> - Do we still want to keep ProtocolMappers per client and
> Role-Scope-Mappings per client? I can imagine we get rid of them and let
> them to be completely inherited from "Client Scopes" . My vote is yes.
> Just afraid if there are some issues with it like:
> -- backwards compatibility and migration -- But hope that's manageable
> -- Option "Full Scope Allowed" from role scope mappings -- but that
> should be solvable too (See below)
>

Not sure about this one. Client scopes can do it all probably, but I think
we'd have to address usability here. Say all I want to do is to add a
protocol mapper to add a single claim to the token for a client then I
don't want to have to:

* Create scope
* Add protocol mapper
* Configure client to set default scope

Then I also have to somehow find the client scopes that are only used by a
single client.


>
>
> - Consent screen:
> -- Currently we have set of protocolMappers and set of roles on consent
> screen. I assume we want to get rid of this and have just single thing:
> Set of client scopes. Correct?
> -- If yes, how to proceed with the protocolMappers and Role Scope
> Mappings, which are defined directly on the client? If we get rid of
> them (as I mentioned above), we don't have this issue. If we don't get
> rid of them, we can have something like "Default consent", which
> encapsulates all the protocolMappers and Role Scope Mappings declared
> directly on client. WDYT?
>

Would make a lot of sense to have a single place to define what is shown on
the consent screen. Client scopes is the place to do it.


>
>
> - Option "Is Consent Required" and "COnsent Text" on protocol mappers -
> Do we want to remove those? I think yes.
>

+1 Not sure how that looks like for backwards compatibility though


>
>
> - Option "Full Scope Allowed" on clients and option "Scope Param
> Required" on roles.
> -- I can imagine we remove both and replace them by having special
> builtin Client Scope, which will automatically have all the roles (all
> realm roles and all client roles of all clients) added to itself.
> -- When new client is created, it will automatically have this builtin
> Client Scope added to itself - because currently newly created clients
> also have "Full Scope Allowed" ON by default.
> -- When new role is created, it will be automatically added to that
> builtin Client Scope.
> -- Admin has ability to remove the roles from this Client Scope. This
> defacto has same meaning like previously "Scope Param Required" flag on
> role, which is curently used for "offline_acces" role.
>
>
> - I was thinking about creating some UI in admin console for "Scope
> Evaluating" . Admin will see effective roles and effective
> protocolMappers based on "scope" parameter he provides. I guess this
> doesn't have so big priority, but will be good to have IMO.
>

The builtin client scope sounds like a good idea, the UI to evaluate also.
Actually I think the UI may be important to be able to easily review how a
token would look like.


>
>
> - UserConsentModel - do we remove roles and protocolMappers and replace
> them instead with Client Scopes? I think yes. Also change the
> "Applications" tab in account management accordingly and have the same
> "Client Scopes" like those, which were displayed on consent screen.
>

+1


>
>
> - Tokens - I think we still want to keep "Effective" claims and
> "effective" roles in tokens as is now? At least in first iteration.
>

Do we perhaps need to introduce revisions for client scopes instead? That
way we can just track the scope + version for a token.


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

From mposolda at redhat.com  Mon Feb 12 08:57:09 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 12 Feb 2018 14:57:09 +0100
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
References: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
	<CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
Message-ID: <cb2e0ae8-766b-9445-a5d4-fc94be0a080f@redhat.com>

On 12/02/18 09:49, Stian Thorgersen wrote:
>
>
> On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi,
>
>     started looking at OAuth Scope parameter support. Wanted to
>     clarify some
>     things before start implementing:
>
>     - Client Scope will allow to group protocolMappers and Role Scope
>     Mappings. Pretty similar to current Client Template
>
>
>     - Do we want to get rid of "Client templates" entirely and rename them
>     to "Client Scopes" ? Or introduce Client scopes as separate thing in
>     addition to client templates? My vote is to rename and get rid of
>     client
>     templates. It would mean get rid of new option "Login theme" from
>     client
>     template (client scope) then? As otherwise is unclear from which
>     Client
>     Scope will client inherit it (assuming client can be inherit from
>     multiple Client Scopes, not just from single Client Template like
>     is now).
>
>
> Removing "Login theme" from client template is fine.
>
> Client templates do have a nice benefit of allowing defining some 
> protocol mappers and scope that is shared between clients. That can 
> probably be done by having the option to set a default scope for a 
> client perhaps?
Yes, should work that way.
>
>
>
>     - Client can inherit from more Client Scopes. I can see 2 groups:
>     -- Default Client Scopes - Those will be applied even if not requested
>     by OIDC scope parameter
>     -- Optional Client Scopes - Those will be applied just if requested by
>     OIDC scope parameter
>
>
> For default client scope, is there global defaults as well as client 
> defaults?
Yes, I think "global defaults" will be good. Those will be added when 
you create new client. You then have possibility to remove some if you want.

I am thinking that "global default" can contain the OIDC predefined 
scopes (email, address, profile, phone) and the scope for all-roles 
described below.

>
>
>     - Do we still want to keep ProtocolMappers per client and
>     Role-Scope-Mappings per client? I can imagine we get rid of them
>     and let
>     them to be completely inherited from "Client Scopes" . My vote is yes.
>     Just afraid if there are some issues with it like:
>     -- backwards compatibility and migration -- But hope that's manageable
>     -- Option "Full Scope Allowed" from role scope mappings -- but that
>     should be solvable too (See below)
>
>
> Not sure about this one. Client scopes can do it all probably, but I 
> think we'd have to address usability here. Say all I want to do is to 
> add a protocol mapper to add a single claim to the token for a client 
> then I don't want to have to:
>
> * Create scope
> * Add protocol mapper
> * Configure client to set default scope
>
> Then I also have to somehow find the client scopes that are only used 
> by a single client.
Yes, I was later thinking too that it is quite problematic. Migration 
from previous versions won't work (without losing some informations).

So then the question remains: How to display on the consent screen the 
protocolMappers and roles, which are defined directly on the client? I 
was thinking about encapsulate them into single scope on the consent 
screen, something like "Client specific" scope or "Client default" 
scope, or something like that?
>
>
>
>     - Consent screen:
>     -- Currently we have set of protocolMappers and set of roles on
>     consent
>     screen. I assume we want to get rid of this and have just single
>     thing:
>     Set of client scopes. Correct?
>     -- If yes, how to proceed with the protocolMappers and Role Scope
>     Mappings, which are defined directly on the client? If we get rid of
>     them (as I mentioned above), we don't have this issue. If we don't get
>     rid of them, we can have something like "Default consent", which
>     encapsulates all the protocolMappers and Role Scope Mappings declared
>     directly on client. WDYT?
>
>
> Would make a lot of sense to have a single place to define what is 
> shown on the consent screen. Client scopes is the place to do it.
>
>
>
>     - Option "Is Consent Required" and "COnsent Text" on protocol
>     mappers -
>     Do we want to remove those? I think yes.
>
>
> +1 Not sure how that looks like for backwards compatibility though
>
>
>
>     - Option "Full Scope Allowed" on clients and option "Scope Param
>     Required" on roles.
>     -- I can imagine we remove both and replace them by having special
>     builtin Client Scope, which will automatically have all the roles (all
>     realm roles and all client roles of all clients) added to itself.
>     -- When new client is created, it will automatically have this builtin
>     Client Scope added to itself - because currently newly created clients
>     also have "Full Scope Allowed" ON by default.
>     -- When new role is created, it will be automatically added to that
>     builtin Client Scope.
>     -- Admin has ability to remove the roles from this Client Scope. This
>     defacto has same meaning like previously "Scope Param Required"
>     flag on
>     role, which is curently used for "offline_acces" role.
>
>
>     - I was thinking about creating some UI in admin console for "Scope
>     Evaluating" . Admin will see effective roles and effective
>     protocolMappers based on "scope" parameter he provides. I guess this
>     doesn't have so big priority, but will be good to have IMO.
>
>
> The builtin client scope sounds like a good idea, the UI to evaluate 
> also. Actually I think the UI may be important to be able to easily 
> review how a token would look like.
>
>
>
>     - UserConsentModel - do we remove roles and protocolMappers and
>     replace
>     them instead with Client Scopes? I think yes. Also change the
>     "Applications" tab in account management accordingly and have the same
>     "Client Scopes" like those, which were displayed on consent screen.
>
>
> +1
>
>
>
>     - Tokens - I think we still want to keep "Effective" claims and
>     "effective" roles in tokens as is now? At least in first iteration.
>
>
> Do we perhaps need to introduce revisions for client scopes instead? 
> That way we can just track the scope + version for a token.
We talked about revisions before in this document 
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit 
in similar context.

If I remember correctly, the idea is, that you increase revision number 
of the Client Scope always when you add/update/remove protocolMapper or 
role scope mapping, is it correct? But what you would do when you detect 
that revision number on the token don't match with current revision of 
scope? Automatically reject the token? That means that always when new 
protocolMapper is added or updated, all refresh tokens (and offline) 
tokens are dropped. Sounds quite problematic IMO.

IMO for now, the things in the token can be unchanged and refactoring it 
can be independent on rest of the work IMO. I can try to figure if 
something can be done based on the remaining time in the sprint...

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


From bburke at redhat.com  Mon Feb 12 09:02:06 2018
From: bburke at redhat.com (Bill Burke)
Date: Mon, 12 Feb 2018 09:02:06 -0500
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
References: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
	<CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
Message-ID: <CABRXCmwfPGHA7EWO_EiObZXWO-BKf5gCNWw8ed_gqcKoGNfCxg@mail.gmail.com>

* Clients should retain protocol mappers and scope for backward
compatibility.  A client is itself a scope, IMO.
* Client Scopes should not have "full scope allowed" flag, but clients
should be able to set this flag.
* Groups should be something that can be added to a scope like roles are.
* Should be a separate "Default Scopes" tab like we have for default
roles/groups.  Defaults scopes are added to new clients, not linked.
This is so that we have backward compatibility and clients can remove
a default if it doesn't want it.




On Mon, Feb 12, 2018 at 3:49 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> started looking at OAuth Scope parameter support. Wanted to clarify some
>> things before start implementing:
>>
>> - Client Scope will allow to group protocolMappers and Role Scope
>> Mappings. Pretty similar to current Client Template
>>
>>
>> - Do we want to get rid of "Client templates" entirely and rename them
>> to "Client Scopes" ? Or introduce Client scopes as separate thing in
>> addition to client templates? My vote is to rename and get rid of client
>> templates. It would mean get rid of new option "Login theme" from client
>> template (client scope) then? As otherwise is unclear from which Client
>> Scope will client inherit it (assuming client can be inherit from
>> multiple Client Scopes, not just from single Client Template like is now).
>>
>
> Removing "Login theme" from client template is fine.
>
> Client templates do have a nice benefit of allowing defining some protocol
> mappers and scope that is shared between clients. That can probably be done
> by having the option to set a default scope for a client perhaps?
>
>
>>
>>
>> - Client can inherit from more Client Scopes. I can see 2 groups:
>> -- Default Client Scopes - Those will be applied even if not requested
>> by OIDC scope parameter
>> -- Optional Client Scopes - Those will be applied just if requested by
>> OIDC scope parameter
>>
>
> For default client scope, is there global defaults as well as client
> defaults?
>
>
>>
>>
>> - Do we still want to keep ProtocolMappers per client and
>> Role-Scope-Mappings per client? I can imagine we get rid of them and let
>> them to be completely inherited from "Client Scopes" . My vote is yes.
>> Just afraid if there are some issues with it like:
>> -- backwards compatibility and migration -- But hope that's manageable
>> -- Option "Full Scope Allowed" from role scope mappings -- but that
>> should be solvable too (See below)
>>
>
> Not sure about this one. Client scopes can do it all probably, but I think
> we'd have to address usability here. Say all I want to do is to add a
> protocol mapper to add a single claim to the token for a client then I
> don't want to have to:
>
> * Create scope
> * Add protocol mapper
> * Configure client to set default scope
>
> Then I also have to somehow find the client scopes that are only used by a
> single client.
>
>
>>
>>
>> - Consent screen:
>> -- Currently we have set of protocolMappers and set of roles on consent
>> screen. I assume we want to get rid of this and have just single thing:
>> Set of client scopes. Correct?
>> -- If yes, how to proceed with the protocolMappers and Role Scope
>> Mappings, which are defined directly on the client? If we get rid of
>> them (as I mentioned above), we don't have this issue. If we don't get
>> rid of them, we can have something like "Default consent", which
>> encapsulates all the protocolMappers and Role Scope Mappings declared
>> directly on client. WDYT?
>>
>
> Would make a lot of sense to have a single place to define what is shown on
> the consent screen. Client scopes is the place to do it.
>
>
>>
>>
>> - Option "Is Consent Required" and "COnsent Text" on protocol mappers -
>> Do we want to remove those? I think yes.
>>
>
> +1 Not sure how that looks like for backwards compatibility though
>
>
>>
>>
>> - Option "Full Scope Allowed" on clients and option "Scope Param
>> Required" on roles.
>> -- I can imagine we remove both and replace them by having special
>> builtin Client Scope, which will automatically have all the roles (all
>> realm roles and all client roles of all clients) added to itself.
>> -- When new client is created, it will automatically have this builtin
>> Client Scope added to itself - because currently newly created clients
>> also have "Full Scope Allowed" ON by default.
>> -- When new role is created, it will be automatically added to that
>> builtin Client Scope.
>> -- Admin has ability to remove the roles from this Client Scope. This
>> defacto has same meaning like previously "Scope Param Required" flag on
>> role, which is curently used for "offline_acces" role.
>>
>>
>> - I was thinking about creating some UI in admin console for "Scope
>> Evaluating" . Admin will see effective roles and effective
>> protocolMappers based on "scope" parameter he provides. I guess this
>> doesn't have so big priority, but will be good to have IMO.
>>
>
> The builtin client scope sounds like a good idea, the UI to evaluate also.
> Actually I think the UI may be important to be able to easily review how a
> token would look like.
>
>
>>
>>
>> - UserConsentModel - do we remove roles and protocolMappers and replace
>> them instead with Client Scopes? I think yes. Also change the
>> "Applications" tab in account management accordingly and have the same
>> "Client Scopes" like those, which were displayed on consent screen.
>>
>
> +1
>
>
>>
>>
>> - Tokens - I think we still want to keep "Effective" claims and
>> "effective" roles in tokens as is now? At least in first iteration.
>>
>
> Do we perhaps need to introduce revisions for client scopes instead? That
> way we can just track the scope + version for a token.
>
>
>>
>> WDYT?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From carreraariel at gmail.com  Mon Feb 12 09:32:42 2018
From: carreraariel at gmail.com (Ariel Carrera)
Date: Mon, 12 Feb 2018 11:32:42 -0300
Subject: [keycloak-dev] [keycloak-user] Trojan in Keycloak Javascript
	Adapter?
In-Reply-To: <CAJgngAcb0ikcOVCeGTEvSBZGMMGP1Nrc0Ad_Xkpi1Qu9Sy7=0A@mail.gmail.com>
References: <CAFzO_6eDDb+uG67_uPFAZTSq6YRfmfhmmJ0VE5AjdvO37UprVA@mail.gmail.com>
	<CAHYJo18jrXAHDRWBiAbbGkNrGVxyCxNkuW9tJL--7RPdM3okeA@mail.gmail.com>
	<CAFzO_6e5DK4b8Mtff85h0AE9KX5mzoj-S7TRxweULgRzQQSejw@mail.gmail.com>
	<CAFzO_6cVzpdLqT4w8cOzMCBCCk3G8apOWYd24px410jqxzmP4w@mail.gmail.com>
	<CAJgngAcb0ikcOVCeGTEvSBZGMMGP1Nrc0Ad_Xkpi1Qu9Sy7=0A@mail.gmail.com>
Message-ID: <CAFzO_6cHUHYgSuM+y3-QF25U1_Cv+EXSi9TUsPZQzL6tTMP_sg@mail.gmail.com>

Hi Stian how you doin ?
Are you talking to me? It's about my virus report?
It was solved with your submit (or my submit). Microsoft Defender tells now
that files are valid.
It was detected as a virus for a while but after submit file and update
virus definitions it was marked as valid.
I remember that we talked about it on January 9th/10th! Thank you!

2018-02-12 5:35 GMT-03:00 Stian Thorgersen <sthorger at redhat.com>:

> Please try the files on https://www.microsoft.com/
> en-us/wdsi/filesubmission. That will allow Microsoft to investigate the
> issue.
>
> I've just submitted it myself and it comes back clean, so this seems to be
> an issue in your environment. Maybe your computer is affected?
>
> On 4 January 2018 at 15:52, Ariel Carrera <carreraariel at gmail.com> wrote:
>
>> Hi, It still happen on my environment.
>> The problem persists with the new version of today (3.4.3.Final).
>>
>> Any comments from the dev team? Could you check it?
>>
>> Maybe it's a false alarm but it could be a serious security problem.
>>
>> - Screenshot of Keycloak JS Adapter alert:
>>
>> [image: Im?genes integradas 1]
>>
>> - Screenshot of Keycloak distribution alert:
>>
>> [image: Im?genes integradas 2]
>>
>> - Screenshot of Virus Definitions Version:
>> [image: Im?genes integradas 3]
>>
>> - Screenshot of Virus Definition Upgrade:
>> [image: Im?genes integradas 4]
>>
>> - Screenshot of Keycloak JS Adapter alert again (with definitions up to
>> date):
>> [image: Im?genes integradas 5]
>>
>> Thanks,
>>
>> 2018-01-03 18:07 GMT-03:00 Ariel Carrera <carreraariel at gmail.com>:
>>
>> > Thanks Ramunas, I will check My Windows defender?s definition version to
>> > compare with you. I have Windows 10 (64 bit) updated on December 2017.
>> >
>> >
>> > El El mi?, 3 ene. 2018 a las 17:45, Rumanas <ramunask at gmail.com>
>> escribi?:
>> >
>> >> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file
>> >> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder
>> >> with Windows Defender on Windows 10 - no issues found
>> >> * checked for Windows updates. New update "Definition Update for
>> Windows
>> >> Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found and
>> >> installed.
>> >> * scanned again. No issues found.
>> >>
>> >> Ram?nas
>> >>
>> > --
>> > Ariel Carrera
>> >
>>
>>
>>
>> --
>> Ariel Carrera
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>


-- 
Ariel Carrera

From sthorger at redhat.com  Mon Feb 12 10:41:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Feb 2018 16:41:14 +0100
Subject: [keycloak-dev] [keycloak-user] Trojan in Keycloak Javascript
	Adapter?
In-Reply-To: <CAFzO_6cHUHYgSuM+y3-QF25U1_Cv+EXSi9TUsPZQzL6tTMP_sg@mail.gmail.com>
References: <CAFzO_6eDDb+uG67_uPFAZTSq6YRfmfhmmJ0VE5AjdvO37UprVA@mail.gmail.com>
	<CAHYJo18jrXAHDRWBiAbbGkNrGVxyCxNkuW9tJL--7RPdM3okeA@mail.gmail.com>
	<CAFzO_6e5DK4b8Mtff85h0AE9KX5mzoj-S7TRxweULgRzQQSejw@mail.gmail.com>
	<CAFzO_6cVzpdLqT4w8cOzMCBCCk3G8apOWYd24px410jqxzmP4w@mail.gmail.com>
	<CAJgngAcb0ikcOVCeGTEvSBZGMMGP1Nrc0Ad_Xkpi1Qu9Sy7=0A@mail.gmail.com>
	<CAFzO_6cHUHYgSuM+y3-QF25U1_Cv+EXSi9TUsPZQzL6tTMP_sg@mail.gmail.com>
Message-ID: <CAJgngAd5EVOpCcGPjBeuD824zA9+0dQOik6wmpNugWZR9MR8JA@mail.gmail.com>

Sorry, I realised what happened. It was an old message that for some reason
was just delivered.

On 12 February 2018 at 15:32, Ariel Carrera <carreraariel at gmail.com> wrote:

> Hi Stian how you doin ?
> Are you talking to me? It's about my virus report?
> It was solved with your submit (or my submit). Microsoft Defender tells
> now that files are valid.
> It was detected as a virus for a while but after submit file and update
> virus definitions it was marked as valid.
> I remember that we talked about it on January 9th/10th! Thank you!
>
> 2018-02-12 5:35 GMT-03:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Please try the files on https://www.microsoft.com/e
>> n-us/wdsi/filesubmission. That will allow Microsoft to investigate the
>> issue.
>>
>> I've just submitted it myself and it comes back clean, so this seems to
>> be an issue in your environment. Maybe your computer is affected?
>>
>> On 4 January 2018 at 15:52, Ariel Carrera <carreraariel at gmail.com> wrote:
>>
>>> Hi, It still happen on my environment.
>>> The problem persists with the new version of today (3.4.3.Final).
>>>
>>> Any comments from the dev team? Could you check it?
>>>
>>> Maybe it's a false alarm but it could be a serious security problem.
>>>
>>> - Screenshot of Keycloak JS Adapter alert:
>>>
>>> [image: Im?genes integradas 1]
>>>
>>> - Screenshot of Keycloak distribution alert:
>>>
>>> [image: Im?genes integradas 2]
>>>
>>> - Screenshot of Virus Definitions Version:
>>> [image: Im?genes integradas 3]
>>>
>>> - Screenshot of Virus Definition Upgrade:
>>> [image: Im?genes integradas 4]
>>>
>>> - Screenshot of Keycloak JS Adapter alert again (with definitions up to
>>> date):
>>> [image: Im?genes integradas 5]
>>>
>>> Thanks,
>>>
>>> 2018-01-03 18:07 GMT-03:00 Ariel Carrera <carreraariel at gmail.com>:
>>>
>>> > Thanks Ramunas, I will check My Windows defender?s definition version
>>> to
>>> > compare with you. I have Windows 10 (64 bit) updated on December 2017.
>>> >
>>> >
>>> > El El mi?, 3 ene. 2018 a las 17:45, Rumanas <ramunask at gmail.com>
>>> escribi?:
>>> >
>>> >> * just downloaded keycloak-js-adapter-dist-3.4.2.Final.zip file
>>> >> * extracted and scanned "keycloak-js-adapter-dist-3.4.2.Final" folder
>>> >> with Windows Defender on Windows 10 - no issues found
>>> >> * checked for Windows updates. New update "Definition Update for
>>> Windows
>>> >> Defender Antivirus - KB2267602 (Definition 1.259.1141.0)" was found
>>> and
>>> >> installed.
>>> >> * scanned again. No issues found.
>>> >>
>>> >> Ram?nas
>>> >>
>>> > --
>>> > Ariel Carrera
>>> >
>>>
>>>
>>>
>>> --
>>> Ariel Carrera
>>>
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>
>
> --
> Ariel Carrera
>

From sthorger at redhat.com  Mon Feb 12 12:17:15 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 12 Feb 2018 18:17:15 +0100
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <cb2e0ae8-766b-9445-a5d4-fc94be0a080f@redhat.com>
References: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
	<CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
	<cb2e0ae8-766b-9445-a5d4-fc94be0a080f@redhat.com>
Message-ID: <CAJgngAc+hsiX0NffVpZGgF14_=58HJP8gqvLvKR+LR05C58pVw@mail.gmail.com>

On 12 February 2018 at 14:57, Marek Posolda <mposolda at redhat.com> wrote:

> On 12/02/18 09:49, Stian Thorgersen wrote:
>
>
>
> On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Hi,
>>
>> started looking at OAuth Scope parameter support. Wanted to clarify some
>> things before start implementing:
>>
>> - Client Scope will allow to group protocolMappers and Role Scope
>> Mappings. Pretty similar to current Client Template
>>
>>
>> - Do we want to get rid of "Client templates" entirely and rename them
>> to "Client Scopes" ? Or introduce Client scopes as separate thing in
>> addition to client templates? My vote is to rename and get rid of client
>> templates. It would mean get rid of new option "Login theme" from client
>> template (client scope) then? As otherwise is unclear from which Client
>> Scope will client inherit it (assuming client can be inherit from
>> multiple Client Scopes, not just from single Client Template like is now).
>>
>
> Removing "Login theme" from client template is fine.
>
> Client templates do have a nice benefit of allowing defining some protocol
> mappers and scope that is shared between clients. That can probably be done
> by having the option to set a default scope for a client perhaps?
>
> Yes, should work that way.
>
>
>
>>
>>
>> - Client can inherit from more Client Scopes. I can see 2 groups:
>> -- Default Client Scopes - Those will be applied even if not requested
>> by OIDC scope parameter
>> -- Optional Client Scopes - Those will be applied just if requested by
>> OIDC scope parameter
>>
>
> For default client scope, is there global defaults as well as client
> defaults?
>
> Yes, I think "global defaults" will be good. Those will be added when you
> create new client. You then have possibility to remove some if you want.
>
> I am thinking that "global default" can contain the OIDC predefined scopes
> (email, address, profile, phone) and the scope for all-roles described
> below.
>
>
>
>>
>> - Do we still want to keep ProtocolMappers per client and
>> Role-Scope-Mappings per client? I can imagine we get rid of them and let
>> them to be completely inherited from "Client Scopes" . My vote is yes.
>> Just afraid if there are some issues with it like:
>> -- backwards compatibility and migration -- But hope that's manageable
>> -- Option "Full Scope Allowed" from role scope mappings -- but that
>> should be solvable too (See below)
>>
>
> Not sure about this one. Client scopes can do it all probably, but I think
> we'd have to address usability here. Say all I want to do is to add a
> protocol mapper to add a single claim to the token for a client then I
> don't want to have to:
>
> * Create scope
> * Add protocol mapper
> * Configure client to set default scope
>
> Then I also have to somehow find the client scopes that are only used by a
> single client.
>
> Yes, I was later thinking too that it is quite problematic. Migration from
> previous versions won't work (without losing some informations).
>
> So then the question remains: How to display on the consent screen the
> protocolMappers and roles, which are defined directly on the client? I was
> thinking about encapsulate them into single scope on the consent screen,
> something like "Client specific" scope or "Client default" scope, or
> something like that?
>

Actually if everything becomes a client scope (aka client template). For
clients that require consents we only store the scopes that was granted.
Then the token is simply update according to the new scope config.


>
>
>>
>>
>> - Consent screen:
>> -- Currently we have set of protocolMappers and set of roles on consent
>> screen. I assume we want to get rid of this and have just single thing:
>> Set of client scopes. Correct?
>> -- If yes, how to proceed with the protocolMappers and Role Scope
>> Mappings, which are defined directly on the client? If we get rid of
>> them (as I mentioned above), we don't have this issue. If we don't get
>> rid of them, we can have something like "Default consent", which
>> encapsulates all the protocolMappers and Role Scope Mappings declared
>> directly on client. WDYT?
>>
>
> Would make a lot of sense to have a single place to define what is shown
> on the consent screen. Client scopes is the place to do it.
>
>
>>
>>
>> - Option "Is Consent Required" and "COnsent Text" on protocol mappers -
>> Do we want to remove those? I think yes.
>>
>
> +1 Not sure how that looks like for backwards compatibility though
>
>
>>
>>
>> - Option "Full Scope Allowed" on clients and option "Scope Param
>> Required" on roles.
>> -- I can imagine we remove both and replace them by having special
>> builtin Client Scope, which will automatically have all the roles (all
>> realm roles and all client roles of all clients) added to itself.
>> -- When new client is created, it will automatically have this builtin
>> Client Scope added to itself - because currently newly created clients
>> also have "Full Scope Allowed" ON by default.
>> -- When new role is created, it will be automatically added to that
>> builtin Client Scope.
>> -- Admin has ability to remove the roles from this Client Scope. This
>> defacto has same meaning like previously "Scope Param Required" flag on
>> role, which is curently used for "offline_acces" role.
>>
>>
>> - I was thinking about creating some UI in admin console for "Scope
>> Evaluating" . Admin will see effective roles and effective
>> protocolMappers based on "scope" parameter he provides. I guess this
>> doesn't have so big priority, but will be good to have IMO.
>>
>
> The builtin client scope sounds like a good idea, the UI to evaluate also.
> Actually I think the UI may be important to be able to easily review how a
> token would look like.
>
>
>>
>>
>> - UserConsentModel - do we remove roles and protocolMappers and replace
>> them instead with Client Scopes? I think yes. Also change the
>> "Applications" tab in account management accordingly and have the same
>> "Client Scopes" like those, which were displayed on consent screen.
>>
>
> +1
>
>
>>
>>
>> - Tokens - I think we still want to keep "Effective" claims and
>> "effective" roles in tokens as is now? At least in first iteration.
>>
>
> Do we perhaps need to introduce revisions for client scopes instead? That
> way we can just track the scope + version for a token.
>
> We talked about revisions before in this document https://docs.google.com/
> document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit in similar
> context.
>
> If I remember correctly, the idea is, that you increase revision number of
> the Client Scope always when you add/update/remove protocolMapper or role
> scope mapping, is it correct? But what you would do when you detect that
> revision number on the token don't match with current revision of scope?
> Automatically reject the token? That means that always when new
> protocolMapper is added or updated, all refresh tokens (and offline) tokens
> are dropped. Sounds quite problematic IMO.
>
> IMO for now, the things in the token can be unchanged and refactoring it
> can be independent on rest of the work IMO. I can try to figure if
> something can be done based on the remaining time in the sprint...
>
> Marek
>
>
>
>>
>> WDYT?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From davmarti at redhat.com  Mon Feb 12 12:23:09 2018
From: davmarti at redhat.com (David Martin)
Date: Mon, 12 Feb 2018 17:23:09 +0000
Subject: [keycloak-dev] NPE in keycloak logs in MetricsEventListener
Message-ID: <CADvBQ47dL=7mQ8JffqH_beKxB1OLdJzyLJ964X7u0N0qXwwtOw@mail.gmail.com>

@Jose, @Peter,
sharing this on the lists in case anyone else comes across it (I came
across it while chatting with Jose on IRC).
I also see successful events being logged in keycloak and getting
through to prometheus & the grafana dashboard.

17:12:49,764 ERROR [org.keycloak.events.EventBuilder] (default
task-75) Failed to send type to
org.jboss.aerogear.keycloak.metrics.MetricsEventListener at 535339d3:
java.lang.NullPointerException

Full logs & stack
https://gist.github.com/david-martin/430709202e4064fe49e6df139380bd2d

Images being used:
aerogearcatalog/keycloak-apb
latest              0a791099254b        4 days ago          669MB
jboss/keycloak-openshift
3.4.3.Final         a032ac87a920        5 weeks ago         844MB
aerogearcatalog/metrics-apb
latest              058e78efe352        4 days ago          669MB


-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)

From pbraun at redhat.com  Mon Feb 12 13:28:56 2018
From: pbraun at redhat.com (Peter Braun)
Date: Mon, 12 Feb 2018 19:28:56 +0100
Subject: [keycloak-dev] NPE in keycloak logs in MetricsEventListener
In-Reply-To: <CADvBQ47dL=7mQ8JffqH_beKxB1OLdJzyLJ964X7u0N0qXwwtOw@mail.gmail.com>
References: <CADvBQ47dL=7mQ8JffqH_beKxB1OLdJzyLJ964X7u0N0qXwwtOw@mail.gmail.com>
Message-ID: <391C462F-10E1-4363-B229-78B833287924@redhat.com>

Hi David, Hi Jose,

we?ve also seen this today when debugging Keycloak with Jose. Looks like we need to add null checks to https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L97 <https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L97> and https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L107 <https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L107>

Jose found another issue: For the metrics to work we need to add the metrics-listener to every Realm we are interested in (metrics wise). That happens automatically for the Project realm. But if the user creates a new Realm in Keycloak or through a custom config file then this listener is not added. To enable metrics the user would have to add the listener manually in the Keycloak Admin Panel.

@David: do you think this is an issue? It means additional config steps for custom Realms that need to be documented.

I think it?s possible to add the metrics-listener to every realm automatically by configuring it in standalone.xml: http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/configure-spi-providers.html <http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/configure-spi-providers.html>

Especially by running a CLI command to add a SPI to the config: http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/cli-recipes.html <http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/cli-recipes.html>

Will look into this with Jose.


Regards,
Peter


> Am 12.02.2018 um 18:23 schrieb David Martin <davmarti at redhat.com>:
> 
> @Jose, @Peter,
> sharing this on the lists in case anyone else comes across it (I came
> across it while chatting with Jose on IRC).
> I also see successful events being logged in keycloak and getting
> through to prometheus & the grafana dashboard.
> 
> 17:12:49,764 ERROR [org.keycloak.events.EventBuilder] (default
> task-75) Failed to send type to
> org.jboss.aerogear.keycloak.metrics.MetricsEventListener at 535339d3:
> java.lang.NullPointerException
> 
> Full logs & stack
> https://gist.github.com/david-martin/430709202e4064fe49e6df139380bd2d
> 
> Images being used:
> aerogearcatalog/keycloak-apb
> latest              0a791099254b        4 days ago          669MB
> jboss/keycloak-openshift
> 3.4.3.Final         a032ac87a920        5 weeks ago         844MB
> aerogearcatalog/metrics-apb
> latest              058e78efe352        4 days ago          669MB
> 
> 
> -- 
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (#aerogear)


From davmarti at redhat.com  Tue Feb 13 05:05:16 2018
From: davmarti at redhat.com (David Martin)
Date: Tue, 13 Feb 2018 10:05:16 +0000
Subject: [keycloak-dev] NPE in keycloak logs in MetricsEventListener
In-Reply-To: <391C462F-10E1-4363-B229-78B833287924@redhat.com>
References: <CADvBQ47dL=7mQ8JffqH_beKxB1OLdJzyLJ964X7u0N0qXwwtOw@mail.gmail.com>
	<391C462F-10E1-4363-B229-78B833287924@redhat.com>
Message-ID: <CADvBQ44X6gRHy4HrbNUp6LzPR2=zFBVxZpDaLr4L0J9NfyeeJw@mail.gmail.com>

On 12 February 2018 at 18:28, Peter Braun <pbraun at redhat.com> wrote:
> Hi David, Hi Jose,
>
> we?ve also seen this today when debugging Keycloak with Jose. Looks like we
> need to add null checks to
> https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L97
> and
> https://github.com/aerogear/keycloak-metrics-spi/blob/mobile-metrics/src/main/java/org/jboss/aerogear/keycloak/metrics/PrometheusExporter.java#L107
>
> Jose found another issue: For the metrics to work we need to add the
> metrics-listener to every Realm we are interested in (metrics wise). That
> happens automatically for the Project realm. But if the user creates a new
> Realm in Keycloak or through a custom config file then this listener is not
> added. To enable metrics the user would have to add the listener manually in
> the Keycloak Admin Panel.
>
> @David: do you think this is an issue? It means additional config steps for
> custom Realms that need to be documented.

It sounds like there should at least be some documentation to cover
this scenario.
e.g.
How to gather metrics for a custom realm.

Having metrics gathered for the all realms automatically may be desirable.
However, I wouldn't say its high priority given that the mobile use
case with Sync & Keycloak leverages the 'namespace' realm

>
> I think it?s possible to add the metrics-listener to every realm
> automatically by configuring it in standalone.xml:
> http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/configure-spi-providers.html
>
> Especially by running a CLI command to add a SPI to the config:
> http://www.keycloak.org/docs/3.3/server_installation/topics/config-subsystem/cli-recipes.html
>
> Will look into this with Jose.
>
>
> Regards,
> Peter
>
>
> Am 12.02.2018 um 18:23 schrieb David Martin <davmarti at redhat.com>:
>
> @Jose, @Peter,
> sharing this on the lists in case anyone else comes across it (I came
> across it while chatting with Jose on IRC).
> I also see successful events being logged in keycloak and getting
> through to prometheus & the grafana dashboard.
>
> 17:12:49,764 ERROR [org.keycloak.events.EventBuilder] (default
> task-75) Failed to send type to
> org.jboss.aerogear.keycloak.metrics.MetricsEventListener at 535339d3:
> java.lang.NullPointerException
>
> Full logs & stack
> https://gist.github.com/david-martin/430709202e4064fe49e6df139380bd2d
>
> Images being used:
> aerogearcatalog/keycloak-apb
> latest              0a791099254b        4 days ago          669MB
> jboss/keycloak-openshift
> 3.4.3.Final         a032ac87a920        5 weeks ago         844MB
> aerogearcatalog/metrics-apb
> latest              058e78efe352        4 days ago          669MB
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (#aerogear)
>
>



-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)


From mposolda at redhat.com  Tue Feb 13 07:10:56 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 13 Feb 2018 13:10:56 +0100
Subject: [keycloak-dev] Scope parameter support
In-Reply-To: <CAJgngAc+hsiX0NffVpZGgF14_=58HJP8gqvLvKR+LR05C58pVw@mail.gmail.com>
References: <016b0a76-8db8-b9b3-f176-fe292da47d1c@redhat.com>
	<CAJgngAe-11p1Be2S=10EQYWnOMJAafLbRi5GPd5dx6YSf69SGg@mail.gmail.com>
	<cb2e0ae8-766b-9445-a5d4-fc94be0a080f@redhat.com>
	<CAJgngAc+hsiX0NffVpZGgF14_=58HJP8gqvLvKR+LR05C58pVw@mail.gmail.com>
Message-ID: <12964dfc-5d77-bdc9-9dea-e4e66981e49c@redhat.com>

Created document 
https://docs.google.com/document/d/1Ht6cRPdFFUOTXtYNCe2UJknh0qo3RBO9F9nsInLBJrc/edit?usp=sharing 
. Anyone should be able to comment.

I've added P1 to the points, which I believe should be done in iteration 
1 and which I think we are in agreement. Others with P2 or P3 can be 
done in later iteration (EG. Groups support) or even postponed to 
future. This contains especially things, where we didn't reach the 100% 
agreement. Those mostly have "maybe" flag on them, so it's not even sure 
if we do them or if the way I described will be used to implement them.

Marek

On 12/02/18 18:17, Stian Thorgersen wrote:
>
>
> On 12 February 2018 at 14:57, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 12/02/18 09:49, Stian Thorgersen wrote:
>>
>>
>>     On 9 February 2018 at 14:30, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Hi,
>>
>>         started looking at OAuth Scope parameter support. Wanted to
>>         clarify some
>>         things before start implementing:
>>
>>         - Client Scope will allow to group protocolMappers and Role Scope
>>         Mappings. Pretty similar to current Client Template
>>
>>
>>         - Do we want to get rid of "Client templates" entirely and
>>         rename them
>>         to "Client Scopes" ? Or introduce Client scopes as separate
>>         thing in
>>         addition to client templates? My vote is to rename and get
>>         rid of client
>>         templates. It would mean get rid of new option "Login theme"
>>         from client
>>         template (client scope) then? As otherwise is unclear from
>>         which Client
>>         Scope will client inherit it (assuming client can be inherit from
>>         multiple Client Scopes, not just from single Client Template
>>         like is now).
>>
>>
>>     Removing "Login theme" from client template is fine.
>>
>>     Client templates do have a nice benefit of allowing defining some
>>     protocol mappers and scope that is shared between clients. That
>>     can probably be done by having the option to set a default scope
>>     for a client perhaps?
>     Yes, should work that way.
>>
>>
>>
>>         - Client can inherit from more Client Scopes. I can see 2 groups:
>>         -- Default Client Scopes - Those will be applied even if not
>>         requested
>>         by OIDC scope parameter
>>         -- Optional Client Scopes - Those will be applied just if
>>         requested by
>>         OIDC scope parameter
>>
>>
>>     For default client scope, is there global defaults as well as
>>     client defaults?
>     Yes, I think "global defaults" will be good. Those will be added
>     when you create new client. You then have possibility to remove
>     some if you want.
>
>     I am thinking that "global default" can contain the OIDC
>     predefined scopes (email, address, profile, phone) and the scope
>     for all-roles described below.
>
>>
>>
>>         - Do we still want to keep ProtocolMappers per client and
>>         Role-Scope-Mappings per client? I can imagine we get rid of
>>         them and let
>>         them to be completely inherited from "Client Scopes" . My
>>         vote is yes.
>>         Just afraid if there are some issues with it like:
>>         -- backwards compatibility and migration -- But hope that's
>>         manageable
>>         -- Option "Full Scope Allowed" from role scope mappings --
>>         but that
>>         should be solvable too (See below)
>>
>>
>>     Not sure about this one. Client scopes can do it all probably,
>>     but I think we'd have to address usability here. Say all I want
>>     to do is to add a protocol mapper to add a single claim to the
>>     token for a client then I don't want to have to:
>>
>>     * Create scope
>>     * Add protocol mapper
>>     * Configure client to set default scope
>>
>>     Then I also have to somehow find the client scopes that are only
>>     used by a single client.
>     Yes, I was later thinking too that it is quite problematic.
>     Migration from previous versions won't work (without losing some
>     informations).
>
>     So then the question remains: How to display on the consent screen
>     the protocolMappers and roles, which are defined directly on the
>     client? I was thinking about encapsulate them into single scope on
>     the consent screen, something like "Client specific" scope or
>     "Client default" scope, or something like that?
>
>
> Actually if everything becomes a client scope (aka client template). 
> For clients that require consents we only store the scopes that was 
> granted. Then the token is simply update according to the new scope 
> config.
>
>>
>>
>>         - Consent screen:
>>         -- Currently we have set of protocolMappers and set of roles
>>         on consent
>>         screen. I assume we want to get rid of this and have just
>>         single thing:
>>         Set of client scopes. Correct?
>>         -- If yes, how to proceed with the protocolMappers and Role Scope
>>         Mappings, which are defined directly on the client? If we get
>>         rid of
>>         them (as I mentioned above), we don't have this issue. If we
>>         don't get
>>         rid of them, we can have something like "Default consent", which
>>         encapsulates all the protocolMappers and Role Scope Mappings
>>         declared
>>         directly on client. WDYT?
>>
>>
>>     Would make a lot of sense to have a single place to define what
>>     is shown on the consent screen. Client scopes is the place to do it.
>>
>>
>>
>>         - Option "Is Consent Required" and "COnsent Text" on protocol
>>         mappers -
>>         Do we want to remove those? I think yes.
>>
>>
>>     +1 Not sure how that looks like for backwards compatibility though
>>
>>
>>
>>         - Option "Full Scope Allowed" on clients and option "Scope Param
>>         Required" on roles.
>>         -- I can imagine we remove both and replace them by having
>>         special
>>         builtin Client Scope, which will automatically have all the
>>         roles (all
>>         realm roles and all client roles of all clients) added to itself.
>>         -- When new client is created, it will automatically have
>>         this builtin
>>         Client Scope added to itself - because currently newly
>>         created clients
>>         also have "Full Scope Allowed" ON by default.
>>         -- When new role is created, it will be automatically added
>>         to that
>>         builtin Client Scope.
>>         -- Admin has ability to remove the roles from this Client
>>         Scope. This
>>         defacto has same meaning like previously "Scope Param
>>         Required" flag on
>>         role, which is curently used for "offline_acces" role.
>>
>>
>>         - I was thinking about creating some UI in admin console for
>>         "Scope
>>         Evaluating" . Admin will see effective roles and effective
>>         protocolMappers based on "scope" parameter he provides. I
>>         guess this
>>         doesn't have so big priority, but will be good to have IMO.
>>
>>
>>     The builtin client scope sounds like a good idea, the UI to
>>     evaluate also. Actually I think the UI may be important to be
>>     able to easily review how a token would look like.
>>
>>
>>
>>         - UserConsentModel - do we remove roles and protocolMappers
>>         and replace
>>         them instead with Client Scopes? I think yes. Also change the
>>         "Applications" tab in account management accordingly and have
>>         the same
>>         "Client Scopes" like those, which were displayed on consent
>>         screen.
>>
>>
>>     +1
>>
>>
>>
>>         - Tokens - I think we still want to keep "Effective" claims and
>>         "effective" roles in tokens as is now? At least in first
>>         iteration.
>>
>>
>>     Do we perhaps need to introduce revisions for client scopes
>>     instead? That way we can just track the scope + version for a token.
>     We talked about revisions before in this document
>     https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit
>     <https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit>
>     in similar context.
>
>     If I remember correctly, the idea is, that you increase revision
>     number of the Client Scope always when you add/update/remove
>     protocolMapper or role scope mapping, is it correct? But what you
>     would do when you detect that revision number on the token don't
>     match with current revision of scope? Automatically reject the
>     token? That means that always when new protocolMapper is added or
>     updated, all refresh tokens (and offline) tokens are dropped.
>     Sounds quite problematic IMO.
>
>     IMO for now, the things in the token can be unchanged and
>     refactoring it can be independent on rest of the work IMO. I can
>     try to figure if something can be done based on the remaining time
>     in the sprint...
>
>     Marek
>>
>>
>>         WDYT?
>>
>>         Marek
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From J.vanZuijlen at flexposure.nl  Tue Feb 13 09:44:19 2018
From: J.vanZuijlen at flexposure.nl (Jasper van Zuijlen)
Date: Tue, 13 Feb 2018 14:44:19 +0000
Subject: [keycloak-dev] Keycloak session expired event
Message-ID: <515B15D1437C5B4EB3CF926B3FF391653CA948@exch01.FLEXDOM.local>

Hi all,

For our application we'd like to make use of the sessions managed by Keycloak. This has proved to work via a plugin up to the point where we want to know when the session ends. Is there any way of getting an event of the expiring of the user session from Keycloak? We'd rather not resort to querying Keycloak for this info from a separate program.

Thanks!


From thomas.darimont at googlemail.com  Tue Feb 13 15:13:33 2018
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 13 Feb 2018 21:13:33 +0100
Subject: [keycloak-dev] Google like Multi-step login
Message-ID: <CAK-7U1iMvi38Y9+Rej+E4auzNm_W1BTqu5WQAk15Ug_OS0Nn-g@mail.gmail.com>

Hello,

are there any plans to support a multi step login flow in Keycloak by
default
like there is for google (*) and yahoo ([1], [2])?

I'm sure that this could be implemented with a custom authenticator +
authentication flow,
but I wonder if it would be useful to have that by default.

[1]
https://ux.stackexchange.com/questions/78805/why-is-google-using-a-new-2-step-gmail-sign-in-process
[2]
https://ux.stackexchange.com/questions/91763/google-and-yahoo-require-you-to-enter-your-username-first-then-password-why-is

(*)
When a user logs in to google he has to enter his username first - the
password is asked
on the next screen potentially followed by another screen for multi factor
authentication.

Cheers,
Thomas

From ssilvert at redhat.com  Tue Feb 13 15:36:41 2018
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 13 Feb 2018 15:36:41 -0500
Subject: [keycloak-dev] Google like Multi-step login
In-Reply-To: <CAK-7U1iMvi38Y9+Rej+E4auzNm_W1BTqu5WQAk15Ug_OS0Nn-g@mail.gmail.com>
References: <CAK-7U1iMvi38Y9+Rej+E4auzNm_W1BTqu5WQAk15Ug_OS0Nn-g@mail.gmail.com>
Message-ID: <4e8d5405-2551-82e5-9576-05bdcae9de43@redhat.com>

If you are asking if this capability will be available "out of the box", 
then yes, we are planning to have that.

Whether multi-step login should be the default setting for all of 
Keycloak is a different question.

Hope that helps.

Stan

On 2/13/2018 3:13 PM, Thomas Darimont wrote:
> Hello,
>
> are there any plans to support a multi step login flow in Keycloak by
> default
> like there is for google (*) and yahoo ([1], [2])?
>
> I'm sure that this could be implemented with a custom authenticator +
> authentication flow,
> but I wonder if it would be useful to have that by default.
>
> [1]
> https://ux.stackexchange.com/questions/78805/why-is-google-using-a-new-2-step-gmail-sign-in-process
> [2]
> https://ux.stackexchange.com/questions/91763/google-and-yahoo-require-you-to-enter-your-username-first-then-password-why-is
>
> (*)
> When a user logs in to google he has to enter his username first - the
> password is asked
> on the next screen potentially followed by another screen for multi factor
> authentication.
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Wed Feb 14 02:52:00 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 14 Feb 2018 08:52:00 +0100
Subject: [keycloak-dev] Google like Multi-step login
In-Reply-To: <4e8d5405-2551-82e5-9576-05bdcae9de43@redhat.com>
References: <CAK-7U1iMvi38Y9+Rej+E4auzNm_W1BTqu5WQAk15Ug_OS0Nn-g@mail.gmail.com>
	<4e8d5405-2551-82e5-9576-05bdcae9de43@redhat.com>
Message-ID: <CAJgngAfxqJBbcgzZtFP24A+bLKNecJep6VeJPbjPMds_yEGfFQ@mail.gmail.com>

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

It should be a configurable option for the realm. Probably through changing
the auth flow.

On 13 February 2018 at 21:36, Stan Silvert <ssilvert at redhat.com> wrote:

> If you are asking if this capability will be available "out of the box",
> then yes, we are planning to have that.
>
> Whether multi-step login should be the default setting for all of
> Keycloak is a different question.
>
> Hope that helps.
>
> Stan
>
> On 2/13/2018 3:13 PM, Thomas Darimont wrote:
> > Hello,
> >
> > are there any plans to support a multi step login flow in Keycloak by
> > default
> > like there is for google (*) and yahoo ([1], [2])?
> >
> > I'm sure that this could be implemented with a custom authenticator +
> > authentication flow,
> > but I wonder if it would be useful to have that by default.
> >
> > [1]
> > https://ux.stackexchange.com/questions/78805/why-is-google-
> using-a-new-2-step-gmail-sign-in-process
> > [2]
> > https://ux.stackexchange.com/questions/91763/google-and-
> yahoo-require-you-to-enter-your-username-first-then-password-why-is
> >
> > (*)
> > When a user logs in to google he has to enter his username first - the
> > password is asked
> > on the next screen potentially followed by another screen for multi
> factor
> > authentication.
> >
> > 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 martin.hardselius at gmail.com  Mon Feb 19 09:40:11 2018
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Mon, 19 Feb 2018 14:40:11 +0000
Subject: [keycloak-dev] Pairwise clients and authorization services
Message-ID: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>

Hi,

It seems like authorization services break when using them with a pairwise
enabled client. I've not investigated the full extent of this but long
story short, the sub from the token is used in token validation and in
org.keyclak.authorization.common.KeycloakIdentity for some comparisons.

Steps to reproduce:
1. Create pairwise a client with authorization enabled
3. Get access token (client_credentials)
3, Try post a new resource_set

I'm not sure what the best way to fix this is.
1. Re-write token validation and KeycloakIdentity to not rely on the sub in
the token,
2. Re-write the pairwise protocol mapper to ignore service accounts (feels
like putting make-up on a pig), or
3. "terminate" pairwise subs, replacing them with the internal sub, before
further processing.

Thoughts?

Regards,
Martin

From psilva at redhat.com  Mon Feb 19 11:19:13 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 19 Feb 2018 13:19:13 -0300
Subject: [keycloak-dev] Pairwise clients and authorization services
In-Reply-To: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
References: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
Message-ID: <CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>

We did not consider subject type pairwise in authorization services, we
need to review this ...

If we can resolve local sub from the a pairwise subject type, I think this
is the best way to go. But pairwise is using SHA26, right ?

I also noticed you are the main contributor of subject pairwise, any
specific reason why we are not using encryption ?

Regards.
Pedro Igor

On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
martin.hardselius at gmail.com> wrote:

> Hi,
>
> It seems like authorization services break when using them with a pairwise
> enabled client. I've not investigated the full extent of this but long
> story short, the sub from the token is used in token validation and in
> org.keyclak.authorization.common.KeycloakIdentity for some comparisons.
>
> Steps to reproduce:
> 1. Create pairwise a client with authorization enabled
> 3. Get access token (client_credentials)
> 3, Try post a new resource_set
>
> I'm not sure what the best way to fix this is.
> 1. Re-write token validation and KeycloakIdentity to not rely on the sub in
> the token,
> 2. Re-write the pairwise protocol mapper to ignore service accounts (feels
> like putting make-up on a pig), or
> 3. "terminate" pairwise subs, replacing them with the internal sub, before
> further processing.
>
> Thoughts?
>
> Regards,
> Martin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From martin.hardselius at gmail.com  Mon Feb 19 12:32:02 2018
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Mon, 19 Feb 2018 17:32:02 +0000
Subject: [keycloak-dev] Pairwise clients and authorization services
In-Reply-To: <CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>
References: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
	<CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>
Message-ID: <CAPJq0L-H6jREji1OEVVjCsPM3xSz308E1cuS2NhB3Ff=puSs_w@mail.gmail.com>

Yes, the default implementation is using SHA-256. That makes things a bit
more complicated. In retrospect, it might have been wiser to go with
AES-128 or some other kind of encryption.

No specific reason. It was one of the suggestions in from the spec and I
suppose we failed to think of scenarios where we would wan't to resolve the
local sub.

Martin

On Mon, 19 Feb 2018 at 17:19 Pedro Igor Silva <psilva at redhat.com> wrote:

> We did not consider subject type pairwise in authorization services, we
> need to review this ...
>
> If we can resolve local sub from the a pairwise subject type, I think this
> is the best way to go. But pairwise is using SHA26, right ?
>
> I also noticed you are the main contributor of subject pairwise, any
> specific reason why we are not using encryption ?
>
> Regards.
> Pedro Igor
>
> On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
> martin.hardselius at gmail.com> wrote:
>
>> Hi,
>>
>> It seems like authorization services break when using them with a pairwise
>> enabled client. I've not investigated the full extent of this but long
>> story short, the sub from the token is used in token validation and in
>> org.keyclak.authorization.common.KeycloakIdentity for some comparisons.
>>
>> Steps to reproduce:
>> 1. Create pairwise a client with authorization enabled
>> 3. Get access token (client_credentials)
>> 3, Try post a new resource_set
>>
>> I'm not sure what the best way to fix this is.
>> 1. Re-write token validation and KeycloakIdentity to not rely on the sub
>> in
>> the token,
>> 2. Re-write the pairwise protocol mapper to ignore service accounts (feels
>> like putting make-up on a pig), or
>> 3. "terminate" pairwise subs, replacing them with the internal sub, before
>> further processing.
>>
>> Thoughts?
>>
>> Regards,
>> Martin
>>
> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From psilva at redhat.com  Mon Feb 19 13:20:01 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 19 Feb 2018 15:20:01 -0300
Subject: [keycloak-dev] Pairwise clients and authorization services
In-Reply-To: <CAPJq0L-H6jREji1OEVVjCsPM3xSz308E1cuS2NhB3Ff=puSs_w@mail.gmail.com>
References: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
	<CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>
	<CAPJq0L-H6jREji1OEVVjCsPM3xSz308E1cuS2NhB3Ff=puSs_w@mail.gmail.com>
Message-ID: <CAJrcDBcRkNUQYCWGEV46VZQGBYermZkvE7hGwUsR5YQrQz_0Vg@mail.gmail.com>

Thanks for the info. It seems the spec was changed to include other
algorithms and examples.

I think we can add support for encryption as an additional pairwise
configuration. That would help us with the original issue and may be useful
for those with a similar requirement.

I've created https://issues.jboss.org/browse/KEYCLOAK-6659.

Thanks.

On Mon, Feb 19, 2018 at 2:32 PM, Martin Hardselius <
martin.hardselius at gmail.com> wrote:

> Yes, the default implementation is using SHA-256. That makes things a bit
> more complicated. In retrospect, it might have been wiser to go with
> AES-128 or some other kind of encryption.
>
> No specific reason. It was one of the suggestions in from the spec and I
> suppose we failed to think of scenarios where we would wan't to resolve the
> local sub.
>
> Martin
>
> On Mon, 19 Feb 2018 at 17:19 Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> We did not consider subject type pairwise in authorization services, we
>> need to review this ...
>>
>> If we can resolve local sub from the a pairwise subject type, I think
>> this is the best way to go. But pairwise is using SHA26, right ?
>>
>> I also noticed you are the main contributor of subject pairwise, any
>> specific reason why we are not using encryption ?
>>
>> Regards.
>> Pedro Igor
>>
>> On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
>> martin.hardselius at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> It seems like authorization services break when using them with a
>>> pairwise
>>> enabled client. I've not investigated the full extent of this but long
>>> story short, the sub from the token is used in token validation and in
>>> org.keyclak.authorization.common.KeycloakIdentity for some comparisons.
>>>
>>> Steps to reproduce:
>>> 1. Create pairwise a client with authorization enabled
>>> 3. Get access token (client_credentials)
>>> 3, Try post a new resource_set
>>>
>>> I'm not sure what the best way to fix this is.
>>> 1. Re-write token validation and KeycloakIdentity to not rely on the sub
>>> in
>>> the token,
>>> 2. Re-write the pairwise protocol mapper to ignore service accounts
>>> (feels
>>> like putting make-up on a pig), or
>>> 3. "terminate" pairwise subs, replacing them with the internal sub,
>>> before
>>> further processing.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> Martin
>>>
>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>

From martin.hardselius at gmail.com  Mon Feb 19 13:41:41 2018
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Mon, 19 Feb 2018 18:41:41 +0000
Subject: [keycloak-dev] Pairwise clients and authorization services
In-Reply-To: <CAJrcDBcRkNUQYCWGEV46VZQGBYermZkvE7hGwUsR5YQrQz_0Vg@mail.gmail.com>
References: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
	<CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>
	<CAPJq0L-H6jREji1OEVVjCsPM3xSz308E1cuS2NhB3Ff=puSs_w@mail.gmail.com>
	<CAJrcDBcRkNUQYCWGEV46VZQGBYermZkvE7hGwUsR5YQrQz_0Vg@mail.gmail.com>
Message-ID: <CAPJq0L8gQ-u5zyoMfkbJbiLqGa+WNpXs8H+s6=CBb81de6ik2g@mail.gmail.com>

It's possible to get the user from the session given a token. That way we
can still resolve the local sub. But for a client configured with a SHA-256
based mapper it might be important to check if the resolved sub hashes to
the same sub in the token, whereas an encryption based sub should decrypt
to match a local sub.

Given the client for which the token was issued, it should be easy to find
out which algorithm was used (check mapper configuration).

I'm prepared to help out with a PR if you need assistance.

Martin

On Mon, 19 Feb 2018 at 19:20 Pedro Igor Silva <psilva at redhat.com> wrote:

> Thanks for the info. It seems the spec was changed to include other
> algorithms and examples.
>
> I think we can add support for encryption as an additional pairwise
> configuration. That would help us with the original issue and may be useful
> for those with a similar requirement.
>
> I've created https://issues.jboss.org/browse/KEYCLOAK-6659.
>
> Thanks.
>
> On Mon, Feb 19, 2018 at 2:32 PM, Martin Hardselius <
> martin.hardselius at gmail.com> wrote:
>
>> Yes, the default implementation is using SHA-256. That makes things a bit
>> more complicated. In retrospect, it might have been wiser to go with
>> AES-128 or some other kind of encryption.
>>
>> No specific reason. It was one of the suggestions in from the spec and I
>> suppose we failed to think of scenarios where we would wan't to resolve the
>> local sub.
>>
>> Martin
>>
>> On Mon, 19 Feb 2018 at 17:19 Pedro Igor Silva <psilva at redhat.com> wrote:
>>
>>> We did not consider subject type pairwise in authorization services, we
>>> need to review this ...
>>>
>>> If we can resolve local sub from the a pairwise subject type, I think
>>> this is the best way to go. But pairwise is using SHA26, right ?
>>>
>>> I also noticed you are the main contributor of subject pairwise, any
>>> specific reason why we are not using encryption ?
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
>>> martin.hardselius at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It seems like authorization services break when using them with a
>>>> pairwise
>>>> enabled client. I've not investigated the full extent of this but long
>>>> story short, the sub from the token is used in token validation and in
>>>> org.keyclak.authorization.common.KeycloakIdentity for some comparisons.
>>>>
>>>> Steps to reproduce:
>>>> 1. Create pairwise a client with authorization enabled
>>>> 3. Get access token (client_credentials)
>>>> 3, Try post a new resource_set
>>>>
>>>> I'm not sure what the best way to fix this is.
>>>> 1. Re-write token validation and KeycloakIdentity to not rely on the
>>>> sub in
>>>> the token,
>>>> 2. Re-write the pairwise protocol mapper to ignore service accounts
>>>> (feels
>>>> like putting make-up on a pig), or
>>>> 3. "terminate" pairwise subs, replacing them with the internal sub,
>>>> before
>>>> further processing.
>>>>
>>>> Thoughts?
>>>>
>>>> Regards,
>>>> Martin
>>>>
>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>

From psilva at redhat.com  Mon Feb 19 14:28:14 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 19 Feb 2018 16:28:14 -0300
Subject: [keycloak-dev] Pairwise clients and authorization services
In-Reply-To: <CAPJq0L8gQ-u5zyoMfkbJbiLqGa+WNpXs8H+s6=CBb81de6ik2g@mail.gmail.com>
References: <CAPJq0L9CnUVyAfg_wa_or-GEfeaC_x-Py=QHRdy+YU+3hei0nw@mail.gmail.com>
	<CAJrcDBcxUhZe=9Jc14AyEajGm_qgyVp+Sr7oyKcx7093aVDzNw@mail.gmail.com>
	<CAPJq0L-H6jREji1OEVVjCsPM3xSz308E1cuS2NhB3Ff=puSs_w@mail.gmail.com>
	<CAJrcDBcRkNUQYCWGEV46VZQGBYermZkvE7hGwUsR5YQrQz_0Vg@mail.gmail.com>
	<CAPJq0L8gQ-u5zyoMfkbJbiLqGa+WNpXs8H+s6=CBb81de6ik2g@mail.gmail.com>
Message-ID: <CAJrcDBc2YUxNEDBJ3hbRCLsOf4rgsucoSC6qSXEO8xzxSa5urw@mail.gmail.com>

On Mon, Feb 19, 2018 at 3:41 PM, Martin Hardselius <
martin.hardselius at gmail.com> wrote:

> It's possible to get the user from the session given a token. That way we
> can still resolve the local sub. But for a client configured with a SHA-256
> based mapper it might be important to check if the resolved sub hashes to
> the same sub in the token, whereas an encryption based sub should decrypt
> to match a local sub.
>

> Given the client for which the token was issued, it should be easy to find
> out which algorithm was used (check mapper configuration).
>
> I'm prepared to help out with a PR if you need assistance.
>

Sure, go ahead. I'm happy to review your changes once you have something.

In fact, it should be better to rely on the session state instead of the
sub claim.


>
> Martin
>
>
> On Mon, 19 Feb 2018 at 19:20 Pedro Igor Silva <psilva at redhat.com> wrote:
>
>> Thanks for the info. It seems the spec was changed to include other
>> algorithms and examples.
>>
>> I think we can add support for encryption as an additional pairwise
>> configuration. That would help us with the original issue and may be useful
>> for those with a similar requirement.
>>
>> I've created https://issues.jboss.org/browse/KEYCLOAK-6659.
>>
>> Thanks.
>>
>> On Mon, Feb 19, 2018 at 2:32 PM, Martin Hardselius <
>> martin.hardselius at gmail.com> wrote:
>>
>>> Yes, the default implementation is using SHA-256. That makes things a
>>> bit more complicated. In retrospect, it might have been wiser to go with
>>> AES-128 or some other kind of encryption.
>>>
>>> No specific reason. It was one of the suggestions in from the spec and I
>>> suppose we failed to think of scenarios where we would wan't to resolve the
>>> local sub.
>>>
>>> Martin
>>>
>>> On Mon, 19 Feb 2018 at 17:19 Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>> We did not consider subject type pairwise in authorization services, we
>>>> need to review this ...
>>>>
>>>> If we can resolve local sub from the a pairwise subject type, I think
>>>> this is the best way to go. But pairwise is using SHA26, right ?
>>>>
>>>> I also noticed you are the main contributor of subject pairwise, any
>>>> specific reason why we are not using encryption ?
>>>>
>>>> Regards.
>>>> Pedro Igor
>>>>
>>>> On Mon, Feb 19, 2018 at 11:40 AM, Martin Hardselius <
>>>> martin.hardselius at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It seems like authorization services break when using them with a
>>>>> pairwise
>>>>> enabled client. I've not investigated the full extent of this but long
>>>>> story short, the sub from the token is used in token validation and in
>>>>> org.keyclak.authorization.common.KeycloakIdentity for some
>>>>> comparisons.
>>>>>
>>>>> Steps to reproduce:
>>>>> 1. Create pairwise a client with authorization enabled
>>>>> 3. Get access token (client_credentials)
>>>>> 3, Try post a new resource_set
>>>>>
>>>>> I'm not sure what the best way to fix this is.
>>>>> 1. Re-write token validation and KeycloakIdentity to not rely on the
>>>>> sub in
>>>>> the token,
>>>>> 2. Re-write the pairwise protocol mapper to ignore service accounts
>>>>> (feels
>>>>> like putting make-up on a pig), or
>>>>> 3. "terminate" pairwise subs, replacing them with the internal sub,
>>>>> before
>>>>> further processing.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Regards,
>>>>> Martin
>>>>>
>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>

From sthorger at redhat.com  Thu Feb 22 02:34:58 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 22 Feb 2018 08:34:58 +0100
Subject: [keycloak-dev] Review updates to German translations
Message-ID: <CAJgngAfRdMqNf8+MCJy2r=wShZi2mwSr-jzCqRrK5YE=GwxaRQ@mail.gmail.com>

Can someone fluent in German review the following PR please:
https://github.com/keycloak/keycloak/pull/5002

From psilva at redhat.com  Thu Feb 22 17:45:42 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 22 Feb 2018 19:45:42 -0300
Subject: [keycloak-dev] [keycloak-user] Authorization Services and UMA
	2.0 changes
In-Reply-To: <CAEyhvmoZ7ejsMv4Ckg9TWLiwyudUCbXk+t_KPbwxdNj8SoB_iQ@mail.gmail.com>
References: <CAJrcDBf8Z7PHY5kzh9MndeEYz=7rdiAgqKpnm9C2joVt_b9-Kg@mail.gmail.com>
	<CAEyhvmrfJd5WtStNPUy2yKFSu2XpVxuz2sZ+aEJThLMr7tfeJA@mail.gmail.com>
	<CAEyhvmoZ7ejsMv4Ckg9TWLiwyudUCbXk+t_KPbwxdNj8SoB_iQ@mail.gmail.com>
Message-ID: <CAJrcDBc_X29==AnUKAX=X2cUbpKzXbVrhQ-P5x8Ycu-y6twroA@mail.gmail.com>

PR is being reviewed. It should be merged very soon.

On Thu, Feb 22, 2018 at 5:14 PM, Corentin Dupont <corentin.dupont at gmail.com>
wrote:

> Hi Pedro and all,
> how is it going with those changes? Any landing date in view?
> It looks very promising.
>
> On Mon, Jan 29, 2018 at 3:09 PM, Corentin Dupont <
> corentin.dupont at gmail.com> wrote:
>
>> That sounds great, thanks a lot!
>>
>> On Mon, Jan 22, 2018 at 2:07 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> We are about to finish the initial round of changes to make Keycloak
>>> Authorization Services compliant with UMA 2.0.
>>>
>>> One of the main changes is related with a new OAuth2 Grant Type
>>> introduced
>>> by UMA 2.0 [1] and how it will be used as a replacement for both
>>> Entitlement and Authorization API. In UMA 2.0, there is no Authorization
>>> API anymore, thus it will be removed on future versions of Keycloak.
>>> Regarding Entitlement API, it will also be removed in favor of the new
>>> grant type, but in this case we are using some extensions to UMA grant
>>> type
>>> to provide the same functionality. One of the objectives of this change
>>> in
>>> particular is to have a single endpoint from where permissions can be
>>> obtained.
>>>
>>> Another important change is also related with UMA where end-users should
>>> be
>>> able now to manage their own resource and permissions via Account
>>> Management Console. Users would be able to access a "Resource" page from
>>> where they can:
>>>
>>> * See the resources they own
>>> * Check for pending permission requests (waiting for the owners
>>> approval).
>>> As well options to grant/deny the request.
>>> * Check for all "shared resources" / granted permissions. As well options
>>> to revoke permissions
>>> * Select an user they want to grant access to a resource and/or scope
>>>
>>> Other changes are related with the Policy Enforcer, Authorization Client
>>> Java API and configuration. For these areas in particular changes are
>>> minimal, specially regarding policy enforcer configuration.
>>>
>>> These changes are targeted to Keycloak v4 and we'll be updating docs
>>> accordingly, specially on how to migrate to the new version.
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.
>>> 0-09.html
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>

From takashi.norimatsu.ws at hitachi.com  Thu Feb 22 20:21:49 2018
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Fri, 23 Feb 2018 01:21:49 +0000
Subject: [keycloak-dev] State hash value (s_hash) to protect state parameter
 (Related to FAPI)
Message-ID: <KAXPR01MB1093D96ECF4436E2DC1F038ECECC0@KAXPR01MB1093.jpnprd01.prod.outlook.com>

Hello.

Last year, I sent some PRs to meet Financial API(FAPI).
FAPI is API's security requirement for API services in financial sector.
It is specified by OpenID Foundation.
http://openid.net/wg/fapi/
FAPI seems to be promising for conforming to PSD2 (Payment Service Directive) in Europe as API Security Profile.

Past PRs (Issue:KEYCLOAK-5661, KEYCLOAK-2604, KEYCLOAK-5811) are related to FAPI Part1. Recently, I've investigated into keycloak to find out whether it conforms to Part 2 (Read and Write API Profile Requirements) for Authorization Server and found that it does not satisfy several points.
Therefore, I've implemented one of them, state hash value (s_hash) to protect state parameter in authorization request.

FAPI Part 2 Read and Write API Security Profile Requirements for Authorization Server is the following.
http://openid.net/specs/openid-financial-api-part-2.html#introduction
http://openid.net/specs/openid-financial-api-part-2.html#authorization-server
* shall include state hash, s_hash, in the ID Token to protect the state value; is met by this PR.
https://github.com/keycloak/keycloak/pull/5022

Hope this PR is reviewed and merged.

And I am also working to meet other points of FAPI Part2, it may take several months (hopefully).

Best Regards
Takashi Norimatsu
Hitachi, Ltd.



From youssef.elhouti at gmail.com  Fri Feb 23 01:27:15 2018
From: youssef.elhouti at gmail.com (Youssef EL HOUTI)
Date: Fri, 23 Feb 2018 07:27:15 +0100
Subject: [keycloak-dev] Testing a custom Provider
Message-ID: <CAMZkV7w7Hu=hVR7UGJJbu0Ap2wS53TtOs_DdJM14whZPpdasCQ@mail.gmail.com>

Hi,

I'm building a custom RealmResourceProvider to be able run a full realm
export and import while the app is running. Since these are sensitive
tasks, I want to secure the endpoint. I think i managed to do that by
"copying" what is done with the adminResource.
Now I want to (integration) test my custom provider
How should proceed to build tests like the ones available in the test suite
(using: AbstractKeycloakTest)

Also is this the right approach?

Things I would like to test:
User is connected to master and has create-realm role  to be able to import
new realm
User is importing from the realm specified in the file to avoid mistakes
User has the role manage-realm to be able to import...
...

Thanks for your help

Youssef

From mkanis at redhat.com  Fri Feb 23 02:35:34 2018
From: mkanis at redhat.com (Martin Kanis)
Date: Fri, 23 Feb 2018 08:35:34 +0100
Subject: [keycloak-dev] Testing a custom Provider
In-Reply-To: <CAMZkV7w7Hu=hVR7UGJJbu0Ap2wS53TtOs_DdJM14whZPpdasCQ@mail.gmail.com>
References: <CAMZkV7w7Hu=hVR7UGJJbu0Ap2wS53TtOs_DdJM14whZPpdasCQ@mail.gmail.com>
Message-ID: <CAAskycRu+ib9SO6a-stpdyZh3CsZmxPAQPcPGmcwVCdGc_X4HQ@mail.gmail.com>

Hi Youssef,

try to have a look to Keycloak quickstarts repository [1][2] where you can
find an examples how to test providers.

Hope this helps you.

Martin

[1]
https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-authenticator/src/test/java/org/keycloak/quickstart/ArquillianActionTokenWithAuthenticatorTest.java
[2]
https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-required-action/src/test/java/org/keycloak/quickstart/ArquillianActionTokenTest.java

On Fri, Feb 23, 2018 at 7:27 AM, Youssef EL HOUTI <youssef.elhouti at gmail.com
> wrote:

> Hi,
>
> I'm building a custom RealmResourceProvider to be able run a full realm
> export and import while the app is running. Since these are sensitive
> tasks, I want to secure the endpoint. I think i managed to do that by
> "copying" what is done with the adminResource.
> Now I want to (integration) test my custom provider
> How should proceed to build tests like the ones available in the test suite
> (using: AbstractKeycloakTest)
>
> Also is this the right approach?
>
> Things I would like to test:
> User is connected to master and has create-realm role  to be able to import
> new realm
> User is importing from the realm specified in the file to avoid mistakes
> User has the role manage-realm to be able to import...
> ...
>
> Thanks for your help
>
> Youssef
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Feb 26 12:35:53 2018
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Feb 2018 12:35:53 -0500
Subject: [keycloak-dev] infinispan as a storage mechanism
Message-ID: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>

If we had a built-in, clusterable storage mechanism for Keycloak using
Infinispan we would:
* Shorten build times drastically.  30 minutes and growing for me for
JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
* Simpler startup.  No need to start a DB.
* Reduce memory footprint?  I think JPA is responsible for a lot of
classes loaded.

I've started some work on this in spare time.  I'd say I'd be done in
like 2 months considering the other work I have in queue.

Looking at FineGrainAtomicMap as an implementation.  Should make DB
migration simple and replication quicker.


-- 
Bill Burke
Red Hat

From psilva at redhat.com  Mon Feb 26 12:54:10 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Feb 2018 14:54:10 -0300
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
Message-ID: <CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>

Isn't this somewhat related with what we used to have with MongoDB ?

On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com> wrote:

> If we had a built-in, clusterable storage mechanism for Keycloak using
> Infinispan we would:
> * Shorten build times drastically.  30 minutes and growing for me for
> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
> * Simpler startup.  No need to start a DB.
> * Reduce memory footprint?  I think JPA is responsible for a lot of
> classes loaded.
>
> I've started some work on this in spare time.  I'd say I'd be done in
> like 2 months considering the other work I have in queue.
>
> Looking at FineGrainAtomicMap as an implementation.  Should make DB
> migration simple and replication quicker.
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Feb 26 14:30:54 2018
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Feb 2018 14:30:54 -0500
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
Message-ID: <CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>

Other than MongoDB not supporting transactions or even sessions?  And
requiring a DB to be run in a separate VM?

No not really :)



On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> Isn't this somewhat related with what we used to have with MongoDB ?
>
> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> If we had a built-in, clusterable storage mechanism for Keycloak using
>> Infinispan we would:
>> * Shorten build times drastically.  30 minutes and growing for me for
>> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>> * Simpler startup.  No need to start a DB.
>> * Reduce memory footprint?  I think JPA is responsible for a lot of
>> classes loaded.
>>
>> I've started some work on this in spare time.  I'd say I'd be done in
>> like 2 months considering the other work I have in queue.
>>
>> Looking at FineGrainAtomicMap as an implementation.  Should make DB
>> migration simple and replication quicker.
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Mon Feb 26 14:56:46 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 26 Feb 2018 16:56:46 -0300
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
Message-ID: <CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>

I think MongoDB will start supporting transactions very soon on v4 ....

I'm not sure about running both app and database in the same VM though. For
dev purposes that is fine, but in real world scenarios you probably want to
avoid sharing resources (mem, cpu) with your DB. In your case, people will
probably need JBoss DataGrid in production.

On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com> wrote:

> Other than MongoDB not supporting transactions or even sessions?  And
> requiring a DB to be run in a separate VM?
>
> No not really :)
>
>
>
> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > Isn't this somewhat related with what we used to have with MongoDB ?
> >
> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> If we had a built-in, clusterable storage mechanism for Keycloak using
> >> Infinispan we would:
> >> * Shorten build times drastically.  30 minutes and growing for me for
> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
> >> * Simpler startup.  No need to start a DB.
> >> * Reduce memory footprint?  I think JPA is responsible for a lot of
> >> classes loaded.
> >>
> >> I've started some work on this in spare time.  I'd say I'd be done in
> >> like 2 months considering the other work I have in queue.
> >>
> >> Looking at FineGrainAtomicMap as an implementation.  Should make DB
> >> migration simple and replication quicker.
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From bburke at redhat.com  Mon Feb 26 15:47:29 2018
From: bburke at redhat.com (Bill Burke)
Date: Mon, 26 Feb 2018 15:47:29 -0500
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
Message-ID: <CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>

I'm thinking of this mostly for running our testsuite.  If you're not
developing on DB, much nicer if your test startup times is
milliseconds rather than 5-10 secs.

For production, I'm thinking more of when people need lightweight
keycloak instances and are doing a lot of identity federation.  This
is really long term thoughts though.

On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> I think MongoDB will start supporting transactions very soon on v4 ....
>
> I'm not sure about running both app and database in the same VM though. For
> dev purposes that is fine, but in real world scenarios you probably want to
> avoid sharing resources (mem, cpu) with your DB. In your case, people will
> probably need JBoss DataGrid in production.
>
> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> Other than MongoDB not supporting transactions or even sessions?  And
>> requiring a DB to be run in a separate VM?
>>
>> No not really :)
>>
>>
>>
>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > Isn't this somewhat related with what we used to have with MongoDB ?
>> >
>> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> If we had a built-in, clusterable storage mechanism for Keycloak using
>> >> Infinispan we would:
>> >> * Shorten build times drastically.  30 minutes and growing for me for
>> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>> >> * Simpler startup.  No need to start a DB.
>> >> * Reduce memory footprint?  I think JPA is responsible for a lot of
>> >> classes loaded.
>> >>
>> >> I've started some work on this in spare time.  I'd say I'd be done in
>> >> like 2 months considering the other work I have in queue.
>> >>
>> >> Looking at FineGrainAtomicMap as an implementation.  Should make DB
>> >> migration simple and replication quicker.
>> >>
>> >>
>> >> --
>> >> Bill Burke
>> >> Red Hat
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Tue Feb 27 01:53:34 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Feb 2018 07:53:34 +0100
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
Message-ID: <CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>

I'm really not convinced about this. Infinispan still needs to persist the
data. It still needs to handle migration whenever we change things. It's
another layer to get working correctly, etc.. I think we have more
important work than to work on another data layer.

On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:

> I'm thinking of this mostly for running our testsuite.  If you're not
> developing on DB, much nicer if your test startup times is
> milliseconds rather than 5-10 secs.
>
> For production, I'm thinking more of when people need lightweight
> keycloak instances and are doing a lot of identity federation.  This
> is really long term thoughts though.
>
> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > I think MongoDB will start supporting transactions very soon on v4 ....
> >
> > I'm not sure about running both app and database in the same VM though.
> For
> > dev purposes that is fine, but in real world scenarios you probably want
> to
> > avoid sharing resources (mem, cpu) with your DB. In your case, people
> will
> > probably need JBoss DataGrid in production.
> >
> > On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> Other than MongoDB not supporting transactions or even sessions?  And
> >> requiring a DB to be run in a separate VM?
> >>
> >> No not really :)
> >>
> >>
> >>
> >> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com>
> >> wrote:
> >> > Isn't this somewhat related with what we used to have with MongoDB ?
> >> >
> >> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> >>
> >> >> If we had a built-in, clusterable storage mechanism for Keycloak
> using
> >> >> Infinispan we would:
> >> >> * Shorten build times drastically.  30 minutes and growing for me for
> >> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
> >> >> * Simpler startup.  No need to start a DB.
> >> >> * Reduce memory footprint?  I think JPA is responsible for a lot of
> >> >> classes loaded.
> >> >>
> >> >> I've started some work on this in spare time.  I'd say I'd be done in
> >> >> like 2 months considering the other work I have in queue.
> >> >>
> >> >> Looking at FineGrainAtomicMap as an implementation.  Should make DB
> >> >> migration simple and replication quicker.
> >> >>
> >> >>
> >> >> --
> >> >> Bill Burke
> >> >> Red Hat
> >> >> _______________________________________________
> >> >> keycloak-dev mailing list
> >> >> keycloak-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Tue Feb 27 09:02:34 2018
From: bburke at redhat.com (Bill Burke)
Date: Tue, 27 Feb 2018 09:02:34 -0500
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
Message-ID: <CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>

This is something I've been doing off and on for awhile.  An hour here
or there.  Its a lot of monotonous work.

Well worth it IMO if our build times drop drastically.  30 min build
is becoming burdensome.  If the console tests get turned on combined
with all the other tests that are added daily, I can see this turning
into 60 min by the end of the year.  Not to mention when I run a
single test from the IDE it takes like 10 seconds to start.  I'm just
sick and tired of it.

For migration, if you base your stored objects on Maps, you only have
to worry about cases where you're modifying objects that are
serialized.  These would need to be versioned as per java
serialization.  New things


On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> I'm really not convinced about this. Infinispan still needs to persist the
> data. It still needs to handle migration whenever we change things. It's
> another layer to get working correctly, etc.. I think we have more important
> work than to work on another data layer.
>
> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>>
>> I'm thinking of this mostly for running our testsuite.  If you're not
>> developing on DB, much nicer if your test startup times is
>> milliseconds rather than 5-10 secs.
>>
>> For production, I'm thinking more of when people need lightweight
>> keycloak instances and are doing a lot of identity federation.  This
>> is really long term thoughts though.
>>
>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
>> wrote:
>> > I think MongoDB will start supporting transactions very soon on v4 ....
>> >
>> > I'm not sure about running both app and database in the same VM though.
>> > For
>> > dev purposes that is fine, but in real world scenarios you probably want
>> > to
>> > avoid sharing resources (mem, cpu) with your DB. In your case, people
>> > will
>> > probably need JBoss DataGrid in production.
>> >
>> > On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> Other than MongoDB not supporting transactions or even sessions?  And
>> >> requiring a DB to be run in a separate VM?
>> >>
>> >> No not really :)
>> >>
>> >>
>> >>
>> >> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >> > Isn't this somewhat related with what we used to have with MongoDB ?
>> >> >
>> >> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> If we had a built-in, clusterable storage mechanism for Keycloak
>> >> >> using
>> >> >> Infinispan we would:
>> >> >> * Shorten build times drastically.  30 minutes and growing for me
>> >> >> for
>> >> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>> >> >> * Simpler startup.  No need to start a DB.
>> >> >> * Reduce memory footprint?  I think JPA is responsible for a lot of
>> >> >> classes loaded.
>> >> >>
>> >> >> I've started some work on this in spare time.  I'd say I'd be done
>> >> >> in
>> >> >> like 2 months considering the other work I have in queue.
>> >> >>
>> >> >> Looking at FineGrainAtomicMap as an implementation.  Should make DB
>> >> >> migration simple and replication quicker.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Bill Burke
>> >> >> Red Hat
>> >> >> _______________________________________________
>> >> >> keycloak-dev mailing list
>> >> >> keycloak-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Bill Burke
>> >> Red Hat
>> >
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Tue Feb 27 13:11:18 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Feb 2018 19:11:18 +0100
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
Message-ID: <CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>

On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:

> This is something I've been doing off and on for awhile.  An hour here
> or there.  Its a lot of monotonous work.
>
> Well worth it IMO if our build times drop drastically.  30 min build
> is becoming burdensome.  If the console tests get turned on combined
> with all the other tests that are added daily, I can see this turning
> into 60 min by the end of the year.  Not to mention when I run a
> single test from the IDE it takes like 10 seconds to start.  I'm just
> sick and tired of it.
>

I can only see how it saves time on starting the Keycloak server, not for
individual tests. That means you're only saving a few seconds each time the
server is started, which is not many times for a full run. You'll probably
end up shaving 1 min of the whole 30 min at best.

Andy also mentioned that the Hibernate guys are working on performance.
There is something weird about the Hibernate startup time in general. So if
there's improvements there that 1 min you could shave would become even
less.

We're also working towards having the full testsuite ran on PRs, which
means as a dev you would be better of picking and running only the tests
you believe may be affected and let the CI run the complete set of jobs.

I'd never bother running the admin console tests locally unless I've done
some changes to the admin console. I also found that running the tests from
the IDE run significantly quicker than through Maven. The difference there
is down to something else than JPA as that's used in both cases. Personally
I very rarely build the full distro or run the tests from Maven at all. I
just let Travis do that, while I run tests through the IDE.


>
> For migration, if you base your stored objects on Maps, you only have
> to worry about cases where you're modifying objects that are
> serialized.  These would need to be versioned as per java
> serialization.  New things
>

I really don't want us to maintain two different persistence layers. It's a
lot of duplicated effort. Becomes even worse when you start thinking about
things like migration, cross-dc, rolling upgrades, etc..

If you are suggesting to completely drop our JPA store altogether and use
Infinispan with a cache store instead that could be an interesting option,
but I have loads and loads of concerns around that.


>
>
> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > I'm really not convinced about this. Infinispan still needs to persist
> the
> > data. It still needs to handle migration whenever we change things. It's
> > another layer to get working correctly, etc.. I think we have more
> important
> > work than to work on another data layer.
> >
> > On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> I'm thinking of this mostly for running our testsuite.  If you're not
> >> developing on DB, much nicer if your test startup times is
> >> milliseconds rather than 5-10 secs.
> >>
> >> For production, I'm thinking more of when people need lightweight
> >> keycloak instances and are doing a lot of identity federation.  This
> >> is really long term thoughts though.
> >>
> >> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
> >> wrote:
> >> > I think MongoDB will start supporting transactions very soon on v4
> ....
> >> >
> >> > I'm not sure about running both app and database in the same VM
> though.
> >> > For
> >> > dev purposes that is fine, but in real world scenarios you probably
> want
> >> > to
> >> > avoid sharing resources (mem, cpu) with your DB. In your case, people
> >> > will
> >> > probably need JBoss DataGrid in production.
> >> >
> >> > On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> >>
> >> >> Other than MongoDB not supporting transactions or even sessions?  And
> >> >> requiring a DB to be run in a separate VM?
> >> >>
> >> >> No not really :)
> >> >>
> >> >>
> >> >>
> >> >> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
> psilva at redhat.com>
> >> >> wrote:
> >> >> > Isn't this somewhat related with what we used to have with MongoDB
> ?
> >> >> >
> >> >> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> If we had a built-in, clusterable storage mechanism for Keycloak
> >> >> >> using
> >> >> >> Infinispan we would:
> >> >> >> * Shorten build times drastically.  30 minutes and growing for me
> >> >> >> for
> >> >> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
> >> >> >> * Simpler startup.  No need to start a DB.
> >> >> >> * Reduce memory footprint?  I think JPA is responsible for a lot
> of
> >> >> >> classes loaded.
> >> >> >>
> >> >> >> I've started some work on this in spare time.  I'd say I'd be done
> >> >> >> in
> >> >> >> like 2 months considering the other work I have in queue.
> >> >> >>
> >> >> >> Looking at FineGrainAtomicMap as an implementation.  Should make
> DB
> >> >> >> migration simple and replication quicker.
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Bill Burke
> >> >> >> Red Hat
> >> >> >> _______________________________________________
> >> >> >> keycloak-dev mailing list
> >> >> >> keycloak-dev at lists.jboss.org
> >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Bill Burke
> >> >> Red Hat
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From sthorger at redhat.com  Tue Feb 27 15:08:21 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 27 Feb 2018 21:08:21 +0100
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
	<CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
Message-ID: <CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>

It's not going to help with startup time, but perhaps one simple way to
make the testsuite run faster would be configuring the h2 dB as
in-mem/non-persisted.

On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com> wrote:

>
>
> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
>
>> This is something I've been doing off and on for awhile.  An hour here
>> or there.  Its a lot of monotonous work.
>>
>> Well worth it IMO if our build times drop drastically.  30 min build
>> is becoming burdensome.  If the console tests get turned on combined
>> with all the other tests that are added daily, I can see this turning
>> into 60 min by the end of the year.  Not to mention when I run a
>> single test from the IDE it takes like 10 seconds to start.  I'm just
>> sick and tired of it.
>>
>
> I can only see how it saves time on starting the Keycloak server, not for
> individual tests. That means you're only saving a few seconds each time the
> server is started, which is not many times for a full run. You'll probably
> end up shaving 1 min of the whole 30 min at best.
>
> Andy also mentioned that the Hibernate guys are working on performance.
> There is something weird about the Hibernate startup time in general. So if
> there's improvements there that 1 min you could shave would become even
> less.
>
> We're also working towards having the full testsuite ran on PRs, which
> means as a dev you would be better of picking and running only the tests
> you believe may be affected and let the CI run the complete set of jobs.
>
> I'd never bother running the admin console tests locally unless I've done
> some changes to the admin console. I also found that running the tests from
> the IDE run significantly quicker than through Maven. The difference there
> is down to something else than JPA as that's used in both cases. Personally
> I very rarely build the full distro or run the tests from Maven at all. I
> just let Travis do that, while I run tests through the IDE.
>
>
>>
>> For migration, if you base your stored objects on Maps, you only have
>> to worry about cases where you're modifying objects that are
>> serialized.  These would need to be versioned as per java
>> serialization.  New things
>>
>
> I really don't want us to maintain two different persistence layers. It's
> a lot of duplicated effort. Becomes even worse when you start thinking
> about things like migration, cross-dc, rolling upgrades, etc..
>
> If you are suggesting to completely drop our JPA store altogether and use
> Infinispan with a cache store instead that could be an interesting option,
> but I have loads and loads of concerns around that.
>
>
>>
>>
>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> > I'm really not convinced about this. Infinispan still needs to persist
>> the
>> > data. It still needs to handle migration whenever we change things. It's
>> > another layer to get working correctly, etc.. I think we have more
>> important
>> > work than to work on another data layer.
>> >
>> > On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>> >>
>> >> I'm thinking of this mostly for running our testsuite.  If you're not
>> >> developing on DB, much nicer if your test startup times is
>> >> milliseconds rather than 5-10 secs.
>> >>
>> >> For production, I'm thinking more of when people need lightweight
>> >> keycloak instances and are doing a lot of identity federation.  This
>> >> is really long term thoughts though.
>> >>
>> >> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
>> >> wrote:
>> >> > I think MongoDB will start supporting transactions very soon on v4
>> ....
>> >> >
>> >> > I'm not sure about running both app and database in the same VM
>> though.
>> >> > For
>> >> > dev purposes that is fine, but in real world scenarios you probably
>> want
>> >> > to
>> >> > avoid sharing resources (mem, cpu) with your DB. In your case, people
>> >> > will
>> >> > probably need JBoss DataGrid in production.
>> >> >
>> >> > On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
>> wrote:
>> >> >>
>> >> >> Other than MongoDB not supporting transactions or even sessions?
>> And
>> >> >> requiring a DB to be run in a separate VM?
>> >> >>
>> >> >> No not really :)
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
>> psilva at redhat.com>
>> >> >> wrote:
>> >> >> > Isn't this somewhat related with what we used to have with
>> MongoDB ?
>> >> >> >
>> >> >> > On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> If we had a built-in, clusterable storage mechanism for Keycloak
>> >> >> >> using
>> >> >> >> Infinispan we would:
>> >> >> >> * Shorten build times drastically.  30 minutes and growing for me
>> >> >> >> for
>> >> >> >> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>> >> >> >> * Simpler startup.  No need to start a DB.
>> >> >> >> * Reduce memory footprint?  I think JPA is responsible for a lot
>> of
>> >> >> >> classes loaded.
>> >> >> >>
>> >> >> >> I've started some work on this in spare time.  I'd say I'd be
>> done
>> >> >> >> in
>> >> >> >> like 2 months considering the other work I have in queue.
>> >> >> >>
>> >> >> >> Looking at FineGrainAtomicMap as an implementation.  Should make
>> DB
>> >> >> >> migration simple and replication quicker.
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Bill Burke
>> >> >> >> Red Hat
>> >> >> >> _______________________________________________
>> >> >> >> keycloak-dev mailing list
>> >> >> >> keycloak-dev at lists.jboss.org
>> >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Bill Burke
>> >> >> Red Hat
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Bill Burke
>> >> Red Hat
>> >> _______________________________________________
>> >> keycloak-dev mailing list
>> >> keycloak-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> >
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>>
>
>

From takashi.norimatsu.ws at hitachi.com  Tue Feb 27 19:22:55 2018
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Wed, 28 Feb 2018 00:22:55 +0000
Subject: [keycloak-dev] Development of FAPI (Financial API) Security Profile
Message-ID: <KAXPR01MB109332484EB2E832A023F383CEC70@KAXPR01MB1093.jpnprd01.prod.outlook.com>

Hello.

We've been trying to use keycloak to protect API services provided by financial institutions.

Under governmental regulation (e.g. Payment Service Directive(PSD2) in Europe), high level security is required for financial sector. One of the most promising security standard for financial API services is Financial API(FAPI) of OpenID Foundation. This is still implementer?s draft, but banking API systems compliant to FAPI are being implemented in some countries.

We've investigated keycloak and found that keycloak does not meet some of FAPI Security Profile requirements. We've been engaging in realizing them in keycloak, but had a lot of works. Is there someone who is interested in it? 

Also, I'm afraid that someone has already planned to support FAPI requirements and/or done some of them. Because it seems that there are some related JIRAs, please tell us the plan of related JIRAs(below 1) tickets).

We?ve created JIRA tickets to realize FAPI. Some tickets have already been resolved while others have been newly created.
Also advice of how to proceed is also welcomed.

1) Aggregated tickets
https://issues.jboss.org/browse/KEYCLOAK-6767

2) Related to existing tickets

* signed and encrypted ID Token
https://issues.jboss.org/browse/KEYCLOAK-6768
It seems that JWE has already been implemented and adopted to authorization code.
Is there any plan to realize signed and encrypted ID Token using this JWE libraries?
https://issues.jboss.org/browse/KEYCLOAK-5288
https://issues.jboss.org/browse/KEYCLOAK-5290
https://issues.jboss.org/browse/KEYCLOAK-5569

* Multi-factor authentication and its corresponding "acr" value in ID Token
https://issues.jboss.org/browse/KEYCLOAK-6769
There has already been some discussion on this issue, but not resolved.
Is there any plan to continue and resolve it?
https://issues.jboss.org/browse/KEYCLOAK-3314

2) Newly created

* JWS signatures using PS256 or ES256 algorithms for signing
https://issues.jboss.org/browse/KEYCLOAK-6770
We?ve investigate why FAPI excludes RS256 and found that RS256 (RSASSA-PKCSv1.5) seems to be considered not secure because several vulnerabilities have been reported.

There are a lot of points using JWS signature not only Access/Refresh/ID Token but Requesting Party Token, Permission Ticket, Request Object, Response from UserInfo Endpoint, JWS Client Assertion, JWT telling events to Clients using client adapter. But I think only it be adequate to target Access/Refresh/ID Token at this time.

However, I?m afraid that some of these points use hard-coded RS256 JWS signature so that it might be difficult to choose other signature algorithm like ES256.

As for signature algorithm, it might be easier to adapt PS256 than ES256 because PS256 is RSA based signature algorithm (RSASSA) like RS256 so that key pair representation is the same. Therefore, I think PS256 could share the same RSA key pair as RS256.

However, it seems that OpenJDK does not support PS256 (?SHA256withRSAandMGF1?).
Considering this point, ES256 (?SHA256withECDSA?) might be only viable option, but additional works like key management be needed comparing with PS256.

* Holder of Key mechanism: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
https://issues.jboss.org/browse/KEYCLOAK-6771
keycloak has already implemented treating X.509 Client Certificate in TLS session.
Also, keycloak has implemented JWS Client Assertion in private so that it has capability of managing X.509 Client Certificate.

It seems that these feature can be used to calculate X.509 Client Certificate thumbprint and embed it onto Access Token that can be used in Sender Constraint.

* State hash value (s_hash) to protect state parameter
https://issues.jboss.org/browse/KEYCLOAK-6700
PR was sent.

3) Resolved
* RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
https://issues.jboss.org/browse/KEYCLOAK-2604

* scope returned in the response from Token Endpoint
https://issues.jboss.org/browse/KEYCLOAK-5661

* OIDC Client Authentication by JWS Client Assertion in client_secret_jwt
https://issues.jboss.org/browse/KEYCLOAK-5811

Best Regards
Takashi Norimatsu
Hitachi, Ltd.



From sthorger at redhat.com  Tue Feb 27 23:06:52 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 28 Feb 2018 05:06:52 +0100
Subject: [keycloak-dev] Review French translation update
Message-ID: <CAJgngAfKUtEcME6bBC_M=w0mR8X5b3WnC9p1HNkit6QMsANTvw@mail.gmail.com>

Can someone fluent in French review the following PR please:
https://github.com/keycloak/keycloak/pull/5036

From sthorger at redhat.com  Tue Feb 27 23:08:14 2018
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 28 Feb 2018 05:08:14 +0100
Subject: [keycloak-dev] Review French translation update
In-Reply-To: <CAJgngAfKUtEcME6bBC_M=w0mR8X5b3WnC9p1HNkit6QMsANTvw@mail.gmail.com>
References: <CAJgngAfKUtEcME6bBC_M=w0mR8X5b3WnC9p1HNkit6QMsANTvw@mail.gmail.com>
Message-ID: <CAJgngAdshr4u=r5vCJ+qYgLu9ptkAb7W8tUwFTjVnCjJ3t+UaA@mail.gmail.com>

and the following PR as well:
https://github.com/keycloak/keycloak/pull/5013

On 28 February 2018 at 05:06, Stian Thorgersen <sthorger at redhat.com> wrote:

> Can someone fluent in French review the following PR please:
> https://github.com/keycloak/keycloak/pull/5036
>

From mposolda at redhat.com  Wed Feb 28 04:23:00 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 Feb 2018 10:23:00 +0100
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
	<CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
	<CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>
Message-ID: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>

I am also personally not concerned about running full testsuite through 
"mvn clean install", however I agree will be good to improve startup 
when you run single test from IDE.

We already use in-memory H2 by default on embedded undertow. But maybe 
it helps if we skip liquibase at all and let Hibernate to create the 
schema when running testsuite with in-mem H2? The problem with Liquibase 
is, that there are more and more changelogs and more and more changes 
and we can't get rid old changelogs. So there are many things like the 
table is created by jpa-changelog-1.0.0, but then immediately dropped by 
jpa-changelog-1.5.0 etc. This is not so big issue for production 
environments when schema is created just once, but sucks during 
development IMO.

Question is, how much time is spent on schema initialization and how 
much on other initialization things (EG. importing master realm and 
"test" realm etc)... Maybe to try some startup profiling will help...

Marek


On 27/02/18 21:08, Stian Thorgersen wrote:
> It's not going to help with startup time, but perhaps one simple way to
> make the testsuite run faster would be configuring the h2 dB as
> in-mem/non-persisted.
>
> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>>
>> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
>>
>>> This is something I've been doing off and on for awhile.  An hour here
>>> or there.  Its a lot of monotonous work.
>>>
>>> Well worth it IMO if our build times drop drastically.  30 min build
>>> is becoming burdensome.  If the console tests get turned on combined
>>> with all the other tests that are added daily, I can see this turning
>>> into 60 min by the end of the year.  Not to mention when I run a
>>> single test from the IDE it takes like 10 seconds to start.  I'm just
>>> sick and tired of it.
>>>
>> I can only see how it saves time on starting the Keycloak server, not for
>> individual tests. That means you're only saving a few seconds each time the
>> server is started, which is not many times for a full run. You'll probably
>> end up shaving 1 min of the whole 30 min at best.
>>
>> Andy also mentioned that the Hibernate guys are working on performance.
>> There is something weird about the Hibernate startup time in general. So if
>> there's improvements there that 1 min you could shave would become even
>> less.
>>
>> We're also working towards having the full testsuite ran on PRs, which
>> means as a dev you would be better of picking and running only the tests
>> you believe may be affected and let the CI run the complete set of jobs.
>>
>> I'd never bother running the admin console tests locally unless I've done
>> some changes to the admin console. I also found that running the tests from
>> the IDE run significantly quicker than through Maven. The difference there
>> is down to something else than JPA as that's used in both cases. Personally
>> I very rarely build the full distro or run the tests from Maven at all. I
>> just let Travis do that, while I run tests through the IDE.
>>
>>
>>> For migration, if you base your stored objects on Maps, you only have
>>> to worry about cases where you're modifying objects that are
>>> serialized.  These would need to be versioned as per java
>>> serialization.  New things
>>>
>> I really don't want us to maintain two different persistence layers. It's
>> a lot of duplicated effort. Becomes even worse when you start thinking
>> about things like migration, cross-dc, rolling upgrades, etc..
>>
>> If you are suggesting to completely drop our JPA store altogether and use
>> Infinispan with a cache store instead that could be an interesting option,
>> but I have loads and loads of concerns around that.
>>
>>
>>>
>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>> I'm really not convinced about this. Infinispan still needs to persist
>>> the
>>>> data. It still needs to handle migration whenever we change things. It's
>>>> another layer to get working correctly, etc.. I think we have more
>>> important
>>>> work than to work on another data layer.
>>>>
>>>> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>>>>> I'm thinking of this mostly for running our testsuite.  If you're not
>>>>> developing on DB, much nicer if your test startup times is
>>>>> milliseconds rather than 5-10 secs.
>>>>>
>>>>> For production, I'm thinking more of when people need lightweight
>>>>> keycloak instances and are doing a lot of identity federation.  This
>>>>> is really long term thoughts though.
>>>>>
>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>> wrote:
>>>>>> I think MongoDB will start supporting transactions very soon on v4
>>> ....
>>>>>> I'm not sure about running both app and database in the same VM
>>> though.
>>>>>> For
>>>>>> dev purposes that is fine, but in real world scenarios you probably
>>> want
>>>>>> to
>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, people
>>>>>> will
>>>>>> probably need JBoss DataGrid in production.
>>>>>>
>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
>>> wrote:
>>>>>>> Other than MongoDB not supporting transactions or even sessions?
>>> And
>>>>>>> requiring a DB to be run in a separate VM?
>>>>>>>
>>>>>>> No not really :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
>>> psilva at redhat.com>
>>>>>>> wrote:
>>>>>>>> Isn't this somewhat related with what we used to have with
>>> MongoDB ?
>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>>>>>>>> wrote:
>>>>>>>>> If we had a built-in, clusterable storage mechanism for Keycloak
>>>>>>>>> using
>>>>>>>>> Infinispan we would:
>>>>>>>>> * Shorten build times drastically.  30 minutes and growing for me
>>>>>>>>> for
>>>>>>>>> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>>>>>>>>> * Simpler startup.  No need to start a DB.
>>>>>>>>> * Reduce memory footprint?  I think JPA is responsible for a lot
>>> of
>>>>>>>>> classes loaded.
>>>>>>>>>
>>>>>>>>> I've started some work on this in spare time.  I'd say I'd be
>>> done
>>>>>>>>> in
>>>>>>>>> like 2 months considering the other work I have in queue.
>>>>>>>>>
>>>>>>>>> Looking at FineGrainAtomicMap as an implementation.  Should make
>>> DB
>>>>>>>>> migration simple and replication quicker.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> Red Hat
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> Red Hat
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Shankar_Bhaskaran at infosys.com  Wed Feb 28 05:15:21 2018
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Wed, 28 Feb 2018 10:15:21 +0000
Subject: [keycloak-dev] Running Keycloak in a clustered mode
Message-ID: <KU1PR02MB243722BAF1DAE8CE29BB0BED9EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>

Hi ,

We are running 2 standalone instances of keycloak with a shared database(later on a clustered database) in active passive mode using haproxy as the loadbalancer  . I  had tested some rest services by running the request again with the same bearer token  with the active keycloak server down and passive server now becomes active one  and it still works.
Can we run  2 instances of keycloak in the standalone mode behind a proxy with a shared database ? Or should we cluster it first using standlone-ha.xml configuration?
What features will be disabled if we use the former way of loadbalancing keycloak

Regards.
Shankar

From psilva at redhat.com  Wed Feb 28 05:56:42 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 28 Feb 2018 07:56:42 -0300
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
	<CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
	<CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>
	<55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>
Message-ID: <CAJrcDBciNo8=J-7yBOLtwWEbDgp_vS5EsLk_HdBCiMNciq7jkw@mail.gmail.com>

Another thing that might provide a better experience is run adapter tests
using Undertow instead of booting a Wildfly app server.

On Wed, Feb 28, 2018 at 6:23 AM, Marek Posolda <mposolda at redhat.com> wrote:

> I am also personally not concerned about running full testsuite through
> "mvn clean install", however I agree will be good to improve startup
> when you run single test from IDE.
>
> We already use in-memory H2 by default on embedded undertow. But maybe
> it helps if we skip liquibase at all and let Hibernate to create the
> schema when running testsuite with in-mem H2? The problem with Liquibase
> is, that there are more and more changelogs and more and more changes
> and we can't get rid old changelogs. So there are many things like the
> table is created by jpa-changelog-1.0.0, but then immediately dropped by
> jpa-changelog-1.5.0 etc. This is not so big issue for production
> environments when schema is created just once, but sucks during
> development IMO.
>
> Question is, how much time is spent on schema initialization and how
> much on other initialization things (EG. importing master realm and
> "test" realm etc)... Maybe to try some startup profiling will help...
>
> Marek
>
>
> On 27/02/18 21:08, Stian Thorgersen wrote:
> > It's not going to help with startup time, but perhaps one simple way to
> > make the testsuite run faster would be configuring the h2 dB as
> > in-mem/non-persisted.
> >
> > On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com> wrote:
> >
> >>
> >> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
> >>
> >>> This is something I've been doing off and on for awhile.  An hour here
> >>> or there.  Its a lot of monotonous work.
> >>>
> >>> Well worth it IMO if our build times drop drastically.  30 min build
> >>> is becoming burdensome.  If the console tests get turned on combined
> >>> with all the other tests that are added daily, I can see this turning
> >>> into 60 min by the end of the year.  Not to mention when I run a
> >>> single test from the IDE it takes like 10 seconds to start.  I'm just
> >>> sick and tired of it.
> >>>
> >> I can only see how it saves time on starting the Keycloak server, not
> for
> >> individual tests. That means you're only saving a few seconds each time
> the
> >> server is started, which is not many times for a full run. You'll
> probably
> >> end up shaving 1 min of the whole 30 min at best.
> >>
> >> Andy also mentioned that the Hibernate guys are working on performance.
> >> There is something weird about the Hibernate startup time in general.
> So if
> >> there's improvements there that 1 min you could shave would become even
> >> less.
> >>
> >> We're also working towards having the full testsuite ran on PRs, which
> >> means as a dev you would be better of picking and running only the tests
> >> you believe may be affected and let the CI run the complete set of jobs.
> >>
> >> I'd never bother running the admin console tests locally unless I've
> done
> >> some changes to the admin console. I also found that running the tests
> from
> >> the IDE run significantly quicker than through Maven. The difference
> there
> >> is down to something else than JPA as that's used in both cases.
> Personally
> >> I very rarely build the full distro or run the tests from Maven at all.
> I
> >> just let Travis do that, while I run tests through the IDE.
> >>
> >>
> >>> For migration, if you base your stored objects on Maps, you only have
> >>> to worry about cases where you're modifying objects that are
> >>> serialized.  These would need to be versioned as per java
> >>> serialization.  New things
> >>>
> >> I really don't want us to maintain two different persistence layers.
> It's
> >> a lot of duplicated effort. Becomes even worse when you start thinking
> >> about things like migration, cross-dc, rolling upgrades, etc..
> >>
> >> If you are suggesting to completely drop our JPA store altogether and
> use
> >> Infinispan with a cache store instead that could be an interesting
> option,
> >> but I have loads and loads of concerns around that.
> >>
> >>
> >>>
> >>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com
> >
> >>> wrote:
> >>>> I'm really not convinced about this. Infinispan still needs to persist
> >>> the
> >>>> data. It still needs to handle migration whenever we change things.
> It's
> >>>> another layer to get working correctly, etc.. I think we have more
> >>> important
> >>>> work than to work on another data layer.
> >>>>
> >>>> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
> >>>>> I'm thinking of this mostly for running our testsuite.  If you're not
> >>>>> developing on DB, much nicer if your test startup times is
> >>>>> milliseconds rather than 5-10 secs.
> >>>>>
> >>>>> For production, I'm thinking more of when people need lightweight
> >>>>> keycloak instances and are doing a lot of identity federation.  This
> >>>>> is really long term thoughts though.
> >>>>>
> >>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com
> >
> >>>>> wrote:
> >>>>>> I think MongoDB will start supporting transactions very soon on v4
> >>> ....
> >>>>>> I'm not sure about running both app and database in the same VM
> >>> though.
> >>>>>> For
> >>>>>> dev purposes that is fine, but in real world scenarios you probably
> >>> want
> >>>>>> to
> >>>>>> avoid sharing resources (mem, cpu) with your DB. In your case,
> people
> >>>>>> will
> >>>>>> probably need JBoss DataGrid in production.
> >>>>>>
> >>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
> >>> wrote:
> >>>>>>> Other than MongoDB not supporting transactions or even sessions?
> >>> And
> >>>>>>> requiring a DB to be run in a separate VM?
> >>>>>>>
> >>>>>>> No not really :)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
> >>> psilva at redhat.com>
> >>>>>>> wrote:
> >>>>>>>> Isn't this somewhat related with what we used to have with
> >>> MongoDB ?
> >>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
> >>>>>>>> wrote:
> >>>>>>>>> If we had a built-in, clusterable storage mechanism for Keycloak
> >>>>>>>>> using
> >>>>>>>>> Infinispan we would:
> >>>>>>>>> * Shorten build times drastically.  30 minutes and growing for me
> >>>>>>>>> for
> >>>>>>>>> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
> >>>>>>>>> * Simpler startup.  No need to start a DB.
> >>>>>>>>> * Reduce memory footprint?  I think JPA is responsible for a lot
> >>> of
> >>>>>>>>> classes loaded.
> >>>>>>>>>
> >>>>>>>>> I've started some work on this in spare time.  I'd say I'd be
> >>> done
> >>>>>>>>> in
> >>>>>>>>> like 2 months considering the other work I have in queue.
> >>>>>>>>>
> >>>>>>>>> Looking at FineGrainAtomicMap as an implementation.  Should make
> >>> DB
> >>>>>>>>> migration simple and replication quicker.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Bill Burke
> >>>>>>>>> Red Hat
> >>>>>>>>> _______________________________________________
> >>>>>>>>> keycloak-dev mailing list
> >>>>>>>>> keycloak-dev at lists.jboss.org
> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Bill Burke
> >>>>>>> Red Hat
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Bill Burke
> >>>>> Red Hat
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> >>>
> >>> --
> >>> Bill Burke
> >>> Red Hat
> >>>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Wed Feb 28 06:53:45 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 Feb 2018 12:53:45 +0100
Subject: [keycloak-dev] Running Keycloak in a clustered mode
In-Reply-To: <KU1PR02MB243722BAF1DAE8CE29BB0BED9EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>
References: <KU1PR02MB243722BAF1DAE8CE29BB0BED9EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>
Message-ID: <d58fa288-bbcf-47f2-11a4-3f1f1023d088@redhat.com>

On 28/02/18 11:15, Shankar_Bhaskaran wrote:
> Hi ,
>
> We are running 2 standalone instances of keycloak with a shared database(later on a clustered database) in active passive mode using haproxy as the loadbalancer  . I  had tested some rest services by running the request again with the same bearer token  with the active keycloak server down and passive server now becomes active one  and it still works.
> Can we run  2 instances of keycloak in the standalone mode behind a proxy with a shared database ? Or should we cluster it first using standlone-ha.xml configuration?
> What features will be disabled if we use the former way of loadbalancing keycloak
I suggest to always rather use clustered keycloak with standalone-ha.xml 
and since you want failover support, increase number of owners to 2 for 
distributed caches.

One of the things, which won't work for the former setup (with 
standalone instances) is the replication of user sessions. In other 
words, userSession created on node1 won't be visible on node2. The 
scenario you mentioned may work (EG. the REST endpoint triggered on 
node2 will be able to successfully verify accessToken created on node1). 
However access tokens are usually short lived and it is assumed that you 
periodically "refresh" them (our adapters do refresh automatically). And 
refreshing the token requires userSession to be present, so with the 
former setup, it will fail as userSession created on node1 won't be 
available on node2.

User session is one example. There are some other things, which won't 
work. We never tried to test such setup and I wouldn't do it.

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



From vramik at redhat.com  Wed Feb 28 07:22:38 2018
From: vramik at redhat.com (Vlasta Ramik)
Date: Wed, 28 Feb 2018 13:22:38 +0100
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <CAJrcDBciNo8=J-7yBOLtwWEbDgp_vS5EsLk_HdBCiMNciq7jkw@mail.gmail.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
	<CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
	<CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>
	<55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>
	<CAJrcDBciNo8=J-7yBOLtwWEbDgp_vS5EsLk_HdBCiMNciq7jkw@mail.gmail.com>
Message-ID: <827f6538-d51c-317f-0e90-638fb142c039@redhat.com>

There are some adapter tests using undertow already [1] but they're 
excluded by default [2]. There is also ongoing work on refactor improve 
the adapter testing [3]


[1] 
https://github.com/keycloak/keycloak/tree/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/adapter/undertow/servlet

[2] 
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/pom.xml#L47

[3] https://issues.jboss.org/browse/KEYCLOAK-6539


On 02/28/2018 11:56 AM, Pedro Igor Silva wrote:
> Another thing that might provide a better experience is run adapter tests
> using Undertow instead of booting a Wildfly app server.
>
> On Wed, Feb 28, 2018 at 6:23 AM, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I am also personally not concerned about running full testsuite through
>> "mvn clean install", however I agree will be good to improve startup
>> when you run single test from IDE.
>>
>> We already use in-memory H2 by default on embedded undertow. But maybe
>> it helps if we skip liquibase at all and let Hibernate to create the
>> schema when running testsuite with in-mem H2? The problem with Liquibase
>> is, that there are more and more changelogs and more and more changes
>> and we can't get rid old changelogs. So there are many things like the
>> table is created by jpa-changelog-1.0.0, but then immediately dropped by
>> jpa-changelog-1.5.0 etc. This is not so big issue for production
>> environments when schema is created just once, but sucks during
>> development IMO.
>>
>> Question is, how much time is spent on schema initialization and how
>> much on other initialization things (EG. importing master realm and
>> "test" realm etc)... Maybe to try some startup profiling will help...
>>
>> Marek
>>
>>
>> On 27/02/18 21:08, Stian Thorgersen wrote:
>>> It's not going to help with startup time, but perhaps one simple way to
>>> make the testsuite run faster would be configuring the h2 dB as
>>> in-mem/non-persisted.
>>>
>>> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>
>>>> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> This is something I've been doing off and on for awhile.  An hour here
>>>>> or there.  Its a lot of monotonous work.
>>>>>
>>>>> Well worth it IMO if our build times drop drastically.  30 min build
>>>>> is becoming burdensome.  If the console tests get turned on combined
>>>>> with all the other tests that are added daily, I can see this turning
>>>>> into 60 min by the end of the year.  Not to mention when I run a
>>>>> single test from the IDE it takes like 10 seconds to start.  I'm just
>>>>> sick and tired of it.
>>>>>
>>>> I can only see how it saves time on starting the Keycloak server, not
>> for
>>>> individual tests. That means you're only saving a few seconds each time
>> the
>>>> server is started, which is not many times for a full run. You'll
>> probably
>>>> end up shaving 1 min of the whole 30 min at best.
>>>>
>>>> Andy also mentioned that the Hibernate guys are working on performance.
>>>> There is something weird about the Hibernate startup time in general.
>> So if
>>>> there's improvements there that 1 min you could shave would become even
>>>> less.
>>>>
>>>> We're also working towards having the full testsuite ran on PRs, which
>>>> means as a dev you would be better of picking and running only the tests
>>>> you believe may be affected and let the CI run the complete set of jobs.
>>>>
>>>> I'd never bother running the admin console tests locally unless I've
>> done
>>>> some changes to the admin console. I also found that running the tests
>> from
>>>> the IDE run significantly quicker than through Maven. The difference
>> there
>>>> is down to something else than JPA as that's used in both cases.
>> Personally
>>>> I very rarely build the full distro or run the tests from Maven at all.
>> I
>>>> just let Travis do that, while I run tests through the IDE.
>>>>
>>>>
>>>>> For migration, if you base your stored objects on Maps, you only have
>>>>> to worry about cases where you're modifying objects that are
>>>>> serialized.  These would need to be versioned as per java
>>>>> serialization.  New things
>>>>>
>>>> I really don't want us to maintain two different persistence layers.
>> It's
>>>> a lot of duplicated effort. Becomes even worse when you start thinking
>>>> about things like migration, cross-dc, rolling upgrades, etc..
>>>>
>>>> If you are suggesting to completely drop our JPA store altogether and
>> use
>>>> Infinispan with a cache store instead that could be an interesting
>> option,
>>>> but I have loads and loads of concerns around that.
>>>>
>>>>
>>>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com
>>>>> wrote:
>>>>>> I'm really not convinced about this. Infinispan still needs to persist
>>>>> the
>>>>>> data. It still needs to handle migration whenever we change things.
>> It's
>>>>>> another layer to get working correctly, etc.. I think we have more
>>>>> important
>>>>>> work than to work on another data layer.
>>>>>>
>>>>>> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>>>>>>> I'm thinking of this mostly for running our testsuite.  If you're not
>>>>>>> developing on DB, much nicer if your test startup times is
>>>>>>> milliseconds rather than 5-10 secs.
>>>>>>>
>>>>>>> For production, I'm thinking more of when people need lightweight
>>>>>>> keycloak instances and are doing a lot of identity federation.  This
>>>>>>> is really long term thoughts though.
>>>>>>>
>>>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com
>>>>>>> wrote:
>>>>>>>> I think MongoDB will start supporting transactions very soon on v4
>>>>> ....
>>>>>>>> I'm not sure about running both app and database in the same VM
>>>>> though.
>>>>>>>> For
>>>>>>>> dev purposes that is fine, but in real world scenarios you probably
>>>>> want
>>>>>>>> to
>>>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case,
>> people
>>>>>>>> will
>>>>>>>> probably need JBoss DataGrid in production.
>>>>>>>>
>>>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
>>>>> wrote:
>>>>>>>>> Other than MongoDB not supporting transactions or even sessions?
>>>>> And
>>>>>>>>> requiring a DB to be run in a separate VM?
>>>>>>>>>
>>>>>>>>> No not really :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
>>>>> psilva at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>> Isn't this somewhat related with what we used to have with
>>>>> MongoDB ?
>>>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> If we had a built-in, clusterable storage mechanism for Keycloak
>>>>>>>>>>> using
>>>>>>>>>>> Infinispan we would:
>>>>>>>>>>> * Shorten build times drastically.  30 minutes and growing for me
>>>>>>>>>>> for
>>>>>>>>>>> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>>>>>>>>>>> * Simpler startup.  No need to start a DB.
>>>>>>>>>>> * Reduce memory footprint?  I think JPA is responsible for a lot
>>>>> of
>>>>>>>>>>> classes loaded.
>>>>>>>>>>>
>>>>>>>>>>> I've started some work on this in spare time.  I'd say I'd be
>>>>> done
>>>>>>>>>>> in
>>>>>>>>>>> like 2 months considering the other work I have in queue.
>>>>>>>>>>>
>>>>>>>>>>> Looking at FineGrainAtomicMap as an implementation.  Should make
>>>>> DB
>>>>>>>>>>> migration simple and replication quicker.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Bill Burke
>>>>>>>>>>> Red Hat
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> Red Hat
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> Red Hat
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> Red Hat
>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From Shankar_Bhaskaran at infosys.com  Wed Feb 28 08:12:11 2018
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Wed, 28 Feb 2018 13:12:11 +0000
Subject: [keycloak-dev] Ldap Issue
Message-ID: <KU1PR02MB24370E329E501AF0C0E6D9259EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>

Hi ,

I see that there is an open issue where we won't be able to create local keycloak users if ldap is down. I am using 3.0.0.Final version of Keycloak and I don't see the issue resolved. Could you please let me if there are plans to fix the issue in the next release

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

Regards,
Shankar

From jayblanc at gmail.com  Wed Feb 28 08:30:19 2018
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Wed, 28 Feb 2018 13:30:19 +0000
Subject: [keycloak-dev] OIDC nonce for FranceConnect [KEYCLOAK-6147]
Message-ID: <CAPNq5vYyoH6y8N71GO3hDneBBTxqFx1-Y+vnj6kCUUn79Ud3ew@mail.gmail.com>

Hi,
According to this task : https://issues.jboss.org/browse/KEYCLOAK-6147 I
have produce a small patch in order to make our keycloak to use
FranceConnect.
It is working now (locally patched instance) btu I'd like to contribute
this modification.
Is there anybody that could help me in this procedure (mostly telling me if
the code is good enough to create a pull request) and especially give me
some guidlines to produce some testing around those modifications ?
The code is available here :
https://github.com/jayblanc/keycloak/tree/idp-oidc-nonce-config
Thanks, best regards,
J?r?me.

From bburke at redhat.com  Wed Feb 28 09:16:28 2018
From: bburke at redhat.com (Bill Burke)
Date: Wed, 28 Feb 2018 09:16:28 -0500
Subject: [keycloak-dev] infinispan as a storage mechanism
In-Reply-To: <55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>
References: <CABRXCmyeM_xtwk1B6Uh7qBDp=vOpuQMFpG_-GOZYex6ch8QvSQ@mail.gmail.com>
	<CAJrcDBeAmB-KeBDAAH3+Ns++JmF_pqOQsfEfiDg-FMb5HaHcrA@mail.gmail.com>
	<CABRXCmwEd9U+K2HT9G+J_DA6kVjwhpDjVrS8KbwYiVWXJ-Ujiw@mail.gmail.com>
	<CAJrcDBfXQjHVBL7D8p6HR8wrNesRXP0q1-YdkDM8XbVhu5J3oA@mail.gmail.com>
	<CABRXCmztZzijyHftPEbLoBFU6_0dYv7MaPcmQU6XtUH6uoVczA@mail.gmail.com>
	<CAJgngAdZgD56Vx2uBMBsiv+EhcjNZ0oGo1TNfgGzmE5c_9BZbQ@mail.gmail.com>
	<CABRXCmwRL=f+ozvEr0xJkuG1afvZ3LwRPZTfm9Yw_+VXn_MHmg@mail.gmail.com>
	<CAJgngAeATAg8Cv-3q6LhqQKfz58isuEtHMGLkEVER5=8x-ydsA@mail.gmail.com>
	<CAJgngAe-6buHyyRnD3bQwEX7ZFVRWWiUotLPTCL7A-THvCjwUQ@mail.gmail.com>
	<55656cbe-6b45-96a2-fb91-d8e791633b46@redhat.com>
Message-ID: <CABRXCmwYu7Bw5QvwWrPNS7v2K5ZyzdMEf4ugbmyg9dSO0B9AoA@mail.gmail.com>

I often have tests that pass within the IDE, or if run singly through
maven, but fail on a maven build.  So, I'm often running a full build.

In my measurements, skipping Liquibase only shaves off 1-2 seconds
(which is still a lot).  JPA initialization takes 5 seconds.
Testsuite slowness is 90% because of Liquibase/JPA.  At least on my
laptop.  Eventually I'll be able to give you numbers when I finish the
Infinispan backend, but I'm weeks away from that as I'm only doing it
off and on.

On Wed, Feb 28, 2018 at 4:23 AM, Marek Posolda <mposolda at redhat.com> wrote:
> I am also personally not concerned about running full testsuite through "mvn
> clean install", however I agree will be good to improve startup when you run
> single test from IDE.
>
> We already use in-memory H2 by default on embedded undertow. But maybe it
> helps if we skip liquibase at all and let Hibernate to create the schema
> when running testsuite with in-mem H2? The problem with Liquibase is, that
> there are more and more changelogs and more and more changes and we can't
> get rid old changelogs. So there are many things like the table is created
> by jpa-changelog-1.0.0, but then immediately dropped by jpa-changelog-1.5.0
> etc. This is not so big issue for production environments when schema is
> created just once, but sucks during development IMO.
>
> Question is, how much time is spent on schema initialization and how much on
> other initialization things (EG. importing master realm and "test" realm
> etc)... Maybe to try some startup profiling will help...
>
> Marek
>
>
>
> On 27/02/18 21:08, Stian Thorgersen wrote:
>>
>> It's not going to help with startup time, but perhaps one simple way to
>> make the testsuite run faster would be configuring the h2 dB as
>> in-mem/non-persisted.
>>
>> On 27 Feb 2018 7:11 pm, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>>>
>>> On 27 February 2018 at 15:02, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> This is something I've been doing off and on for awhile.  An hour here
>>>> or there.  Its a lot of monotonous work.
>>>>
>>>> Well worth it IMO if our build times drop drastically.  30 min build
>>>> is becoming burdensome.  If the console tests get turned on combined
>>>> with all the other tests that are added daily, I can see this turning
>>>> into 60 min by the end of the year.  Not to mention when I run a
>>>> single test from the IDE it takes like 10 seconds to start.  I'm just
>>>> sick and tired of it.
>>>>
>>> I can only see how it saves time on starting the Keycloak server, not for
>>> individual tests. That means you're only saving a few seconds each time
>>> the
>>> server is started, which is not many times for a full run. You'll
>>> probably
>>> end up shaving 1 min of the whole 30 min at best.
>>>
>>> Andy also mentioned that the Hibernate guys are working on performance.
>>> There is something weird about the Hibernate startup time in general. So
>>> if
>>> there's improvements there that 1 min you could shave would become even
>>> less.
>>>
>>> We're also working towards having the full testsuite ran on PRs, which
>>> means as a dev you would be better of picking and running only the tests
>>> you believe may be affected and let the CI run the complete set of jobs.
>>>
>>> I'd never bother running the admin console tests locally unless I've done
>>> some changes to the admin console. I also found that running the tests
>>> from
>>> the IDE run significantly quicker than through Maven. The difference
>>> there
>>> is down to something else than JPA as that's used in both cases.
>>> Personally
>>> I very rarely build the full distro or run the tests from Maven at all. I
>>> just let Travis do that, while I run tests through the IDE.
>>>
>>>
>>>> For migration, if you base your stored objects on Maps, you only have
>>>> to worry about cases where you're modifying objects that are
>>>> serialized.  These would need to be versioned as per java
>>>> serialization.  New things
>>>>
>>> I really don't want us to maintain two different persistence layers. It's
>>> a lot of duplicated effort. Becomes even worse when you start thinking
>>> about things like migration, cross-dc, rolling upgrades, etc..
>>>
>>> If you are suggesting to completely drop our JPA store altogether and use
>>> Infinispan with a cache store instead that could be an interesting
>>> option,
>>> but I have loads and loads of concerns around that.
>>>
>>>
>>>>
>>>> On Tue, Feb 27, 2018 at 1:53 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>>
>>>>> I'm really not convinced about this. Infinispan still needs to persist
>>>>
>>>> the
>>>>>
>>>>> data. It still needs to handle migration whenever we change things.
>>>>> It's
>>>>> another layer to get working correctly, etc.. I think we have more
>>>>
>>>> important
>>>>>
>>>>> work than to work on another data layer.
>>>>>
>>>>> On 26 February 2018 at 21:47, Bill Burke <bburke at redhat.com> wrote:
>>>>>>
>>>>>> I'm thinking of this mostly for running our testsuite.  If you're not
>>>>>> developing on DB, much nicer if your test startup times is
>>>>>> milliseconds rather than 5-10 secs.
>>>>>>
>>>>>> For production, I'm thinking more of when people need lightweight
>>>>>> keycloak instances and are doing a lot of identity federation.  This
>>>>>> is really long term thoughts though.
>>>>>>
>>>>>> On Mon, Feb 26, 2018 at 2:56 PM, Pedro Igor Silva <psilva at redhat.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I think MongoDB will start supporting transactions very soon on v4
>>>>
>>>> ....
>>>>>>>
>>>>>>> I'm not sure about running both app and database in the same VM
>>>>
>>>> though.
>>>>>>>
>>>>>>> For
>>>>>>> dev purposes that is fine, but in real world scenarios you probably
>>>>
>>>> want
>>>>>>>
>>>>>>> to
>>>>>>> avoid sharing resources (mem, cpu) with your DB. In your case, people
>>>>>>> will
>>>>>>> probably need JBoss DataGrid in production.
>>>>>>>
>>>>>>> On Mon, Feb 26, 2018 at 4:30 PM, Bill Burke <bburke at redhat.com>
>>>>
>>>> wrote:
>>>>>>>>
>>>>>>>> Other than MongoDB not supporting transactions or even sessions?
>>>>
>>>> And
>>>>>>>>
>>>>>>>> requiring a DB to be run in a separate VM?
>>>>>>>>
>>>>>>>> No not really :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Feb 26, 2018 at 12:54 PM, Pedro Igor Silva <
>>>>
>>>> psilva at redhat.com>
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Isn't this somewhat related with what we used to have with
>>>>
>>>> MongoDB ?
>>>>>>>>>
>>>>>>>>> On Mon, Feb 26, 2018 at 2:35 PM, Bill Burke <bburke at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> If we had a built-in, clusterable storage mechanism for Keycloak
>>>>>>>>>> using
>>>>>>>>>> Infinispan we would:
>>>>>>>>>> * Shorten build times drastically.  30 minutes and growing for me
>>>>>>>>>> for
>>>>>>>>>> JPA builds.  Liquibase + JPA startup takes 5-7 seconds on my box.
>>>>>>>>>> * Simpler startup.  No need to start a DB.
>>>>>>>>>> * Reduce memory footprint?  I think JPA is responsible for a lot
>>>>
>>>> of
>>>>>>>>>>
>>>>>>>>>> classes loaded.
>>>>>>>>>>
>>>>>>>>>> I've started some work on this in spare time.  I'd say I'd be
>>>>
>>>> done
>>>>>>>>>>
>>>>>>>>>> in
>>>>>>>>>> like 2 months considering the other work I have in queue.
>>>>>>>>>>
>>>>>>>>>> Looking at FineGrainAtomicMap as an implementation.  Should make
>>>>
>>>> DB
>>>>>>>>>>
>>>>>>>>>> migration simple and replication quicker.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Bill Burke
>>>>>>>>>> Red Hat
>>>>>>>>>> _______________________________________________
>>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> Red Hat
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> Red Hat
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Wed Feb 28 14:25:24 2018
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 28 Feb 2018 16:25:24 -0300
Subject: [keycloak-dev] Non-UMA Use Cases
Message-ID: <CAJrcDBddbZ5DZAkegAXviYfMbELtz2DO=g3x1McSfB=QF-+c-A@mail.gmail.com>

Hi,

There are situations where you don't want to use the UMA protocol to obtain
permissions from the server in form of an access token. Reasons can be: you
don't have any privacy requirements or your requirements don't require all
the UMA dance to obtain an access token.

In these situations, you may just want to send a request with the resources
and scopes you want to get access and get back the access token with these
permissions.

This is what we provide today with the Entitlement API, an alternative that
simplifies how clients can obtain permissions from the server.

However, with the introduction of UMA 2.0 support, we have now a specific
grant type [1] for obtaining permissions from the server using the token
endpoint. Just like any other OAuth2 grant type, the UMA grant type expects
a HTTP FORM request with some parameters.

The Entitlement API no longer exists but the same behavior can be achieved
with the new UMA grant type that was introduced. In other words, you can
use this grant type to ask for an access token with permissions without
sending a permission ticket but a list of resources/scopes (as parameters)
you want to get access.

The reason for reusing the grant type is that I would like to avoid having
two endpoints for obtaining permissions from the server. I think it makes
things simple.

Would like to know your opinion if moving the Entitlement API functionality
to this new grant type makes sense and if, maybe, we should have a specific
grant type (based on UMA grant type) that allows authorization requests
without a permission ticket (but a list of resources and scopes you want to
access). As side note, the code for UMA and non-UMA authorization is pretty
much the same, the main difference is on the format of the authorization
request/protocol.

[1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-09.html

Regards.
Pedro Igor

From mposolda at redhat.com  Wed Feb 28 14:59:43 2018
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 28 Feb 2018 20:59:43 +0100
Subject: [keycloak-dev] Ldap Issue
In-Reply-To: <KU1PR02MB24370E329E501AF0C0E6D9259EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>
References: <KU1PR02MB24370E329E501AF0C0E6D9259EC70@KU1PR02MB2437.apcprd02.prod.outlook.com>
Message-ID: <d122f688-acec-b7c2-ebde-018b73992d8f@redhat.com>

In latest Keycloak, there is possibility to disable LDAP (or UserStorage 
provider in general) in admin console.

So if you're fine to create users just in local DB in case that LDAP 
down, you need to disable LDAP provider in admin console and then 
re-enable it once it is back. Does it address your usecase?

Marek

On 28/02/18 14:12, Shankar_Bhaskaran wrote:
> Hi ,
>
> I see that there is an open issue where we won't be able to create local keycloak users if ldap is down. I am using 3.0.0.Final version of Keycloak and I don't see the issue resolved. Could you please let me if there are plans to fix the issue in the next release
>
> https://issues.jboss.org/browse/KEYCLOAK-2984
>
> Regards,
> Shankar
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From jblashka at redhat.com  Wed Feb 28 15:36:46 2018
From: jblashka at redhat.com (Jared Blashka)
Date: Wed, 28 Feb 2018 15:36:46 -0500
Subject: [keycloak-dev] Cross-datacenter configuration issues
Message-ID: <CALO-DfC0AKp-UAnYjDxAmej2xOBy1S2x-y_dU2JTyCid21id-g@mail.gmail.com>

Hey all,

I'm working on testing out the cross-datacenter replication configuration
in our development environment and I'm running into some issues.

I stood up some JDG 7.1 instances and some RH-SSO 7.2 instances all running
on my localhost all with different port offsets, followed the
instructions[1], and everything seemed to work well enough.

Once I got beyond that and tried running RH-SSO and JDG on separate servers
I started running into issues[2] during RH-SSO startup. Looks like RH-SSO
is unable to connect to the remote ___script_cache but that cache isn't
mentioned anywhere in the RH-SSO documentation. The error message (and
online searching) indicates that this cache only allows remote connections
if authorization is enabled. I didn't see any mention of configuration
related to authentication or security for the remote caches in the
documentation either.

At this point we roped in a JDG expert (cc'ed here) and found some
additional Infinispan documentation[3] on how to add authentication to the
*remote* caches within the JDG configuration but nothing much in the way of
adding authentication to the client cache configuration inside RH-SSO that
didn't involve programmatic changes. After some additional searching we
found some info[4] detailing how to add security configurations to a
remote-cache configuration in Infinispan *9.1* but EAP 7.1 is only running
Infinispan *8.2* which doesn't have these changes.

How did you get this working?

Jared Blashka - Identity & Access Management


[1]
https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.2/pdf/server_installation_and_configuration_guide/Red_Hat_Single_Sign-On-7.2-Server_Installation_and_Configuration_Guide-en-US.pdf#__WKANCHOR_1e
[2] http://pastebin.test.redhat.com/559674
[3]
http://infinispan.org/docs/stable/server_guide/server_guide.html#general_concepts
[4]
https://docs.jboss.org/infinispan/9.1/configdocs/infinispan-cachestore-remote-config-9.1.html