From thomas.darimont at googlemail.com  Sat Nov  4 11:16:30 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 4 Nov 2017 16:16:30 +0100
Subject: [keycloak-dev] FYI Version Keycloak 3.3.0.Final is not yet marked
	as released in JIRA
Message-ID: <CAK-7U1juhiA42H7Wt8p-ba96iWTmBV5fwzVoVNcW7f4yHG+7CQ@mail.gmail.com>

Cheers,
Thomas

From mposolda at redhat.com  Mon Nov  6 03:42:21 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 6 Nov 2017 09:42:21 +0100
Subject: [keycloak-dev] FYI Version Keycloak 3.3.0.Final is not yet
 marked as released in JIRA
In-Reply-To: <CAK-7U1juhiA42H7Wt8p-ba96iWTmBV5fwzVoVNcW7f4yHG+7CQ@mail.gmail.com>
References: <CAK-7U1juhiA42H7Wt8p-ba96iWTmBV5fwzVoVNcW7f4yHG+7CQ@mail.gmail.com>
Message-ID: <3633865d-4381-ad5b-45eb-9dd3393d709a@redhat.com>

Fixed. Thanks!

Marek

On 04/11/17 16:16, Thomas Darimont wrote:
> 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  Tue Nov  7 03:14:28 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 7 Nov 2017 09:14:28 +0100
Subject: [keycloak-dev] Merge of Node.js modules
In-Reply-To: <20171031215109.GA5152@abstractj.org>
References: <20171031215109.GA5152@abstractj.org>
Message-ID: <CAJgngAc8JGpYHo0zXCYXZHCVdZ9pTMmMM5bmX+f140Y6RC0j0A@mail.gmail.com>

Let's move ahead with this then since no one had any objections.

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

On 31 October 2017 at 22:51, Bruno Oliveira <bruno at abstractj.org> wrote:

>
> Aloha,
>
> We're considering the merge keycloak-nodejs-connect and
> keycloak-nodejs-auth-utils into a single codebase for the next release.
> What does that mean? That the whole codebase will live under
> keycloak-nodejs-connect repository and module.
>
> The reason behind is that there are few good reasons to keep both
> separated today. This is going to make our release process better, as well
> the maintenance of the codebase.
>
> I would like to gather some feedback before moving forward. So comments on
> this thread are more than welcome!
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bdawidow at redhat.com  Tue Nov  7 04:53:41 2017
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 07 Nov 2017 09:53:41 +0000
Subject: [keycloak-dev] OpenShift trainings
Message-ID: <CABbwURHz0_qLsDvWHcBGGCLpCMw7pXVp+=OabwfUBFTMWugEaw@mail.gmail.com>

More slots for the online training some of you already had.

https://docs.google.com/spreadsheets/d/18Kq9DLI0h_Vp52quIz5HXdP5A0xYGVKSKhTOMkcRj7Y/edit#gid=1012168231

From rahul.pharande at gi-de.com  Tue Nov  7 08:11:38 2017
From: rahul.pharande at gi-de.com (Pharande Rahul)
Date: Tue, 7 Nov 2017 13:11:38 +0000
Subject: [keycloak-dev] Access Token getting truncated when apache HTTPD is
	in front
Message-ID: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>

Hello Team,

I'm facing issue of "Access Token getting truncated when apache HTTPD is in front".
Though this issue is not directly associated/related to Keycloak but in combination with Apache HTTPD + Keycloak, I would like to take help from experts here :)

Below are more details on same.

Environnent :

o   Server : Keycloak v3.x

o   Proxy server :    Apache HTTPD 2.4.x

o   Client: Angular2 application using OIDC library.

Issue Description / Steps to reproduce:

*         Create realm in Keycloak

*         Create client for realm along with redirect url etc.

*         Create ~70 role/permissions for client with longer names ~25 characters in permission name.

*         Create user and assign all above permissions for newly created client.

*         Access Angular2 application running in browser, and for protected resources Keycloak login page displayed where redirect_uri parameter is given/supplied.

*         After entering valid user credentials, keycloak redirects to Application's redirect URL

*         However error shown on browser console that, "failed at_hash".

o   This is because incomplete/truncated token returned and OIDC client library in Angular application tries to validate token received.
Important point here:

*         Defect mentioned only occurs when Apache is in front and used as proxy/load balancer server.

My analysis:

*         As per my analysis, I see Keycloak returns access_token information in response header during redirect

*         Apache has restriction of handling response header  or cookies of size upto 8k

*         Even after setting, various parameters in Apache HTTPD like - "LimitRequestFieldSize", "LimitRequestLine" we are still getting this error.


Please let me know if anyone already experienced such issue OR has any alternative on using/configuring Keycloak to redirect using part response..

Thanks and Regards.
Rahul Pharande


From mstrukel at redhat.com  Tue Nov  7 10:24:34 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 7 Nov 2017 15:24:34 +0000
Subject: [keycloak-dev] Access Token getting truncated when apache HTTPD
 is in front
In-Reply-To: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>
References: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>
Message-ID: <CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>

If you increased LimitRequestFieldSize to more than the actual size of the
header, then this error should be gone or you should be getting a different
error. Unless you have another proxy / load balancer in front of your
Apache, or between Apache and Keycloak.

I'd do a little test using curl, setting a header of large length, and
tcpdump on Keycloak host to make sure header gets through.

On Tue, Nov 7, 2017 at 1:11 PM, Pharande Rahul <rahul.pharande at gi-de.com>
wrote:

> Hello Team,
>
> I'm facing issue of "Access Token getting truncated when apache HTTPD is
> in front".
> Though this issue is not directly associated/related to Keycloak but in
> combination with Apache HTTPD + Keycloak, I would like to take help from
> experts here :)
>
> Below are more details on same.
>
> Environnent :
>
> o   Server : Keycloak v3.x
>
> o   Proxy server :    Apache HTTPD 2.4.x
>
> o   Client: Angular2 application using OIDC library.
>
> Issue Description / Steps to reproduce:
>
> *         Create realm in Keycloak
>
> *         Create client for realm along with redirect url etc.
>
> *         Create ~70 role/permissions for client with longer names ~25
> characters in permission name.
>
> *         Create user and assign all above permissions for newly created
> client.
>
> *         Access Angular2 application running in browser, and for
> protected resources Keycloak login page displayed where redirect_uri
> parameter is given/supplied.
>
> *         After entering valid user credentials, keycloak redirects to
> Application's redirect URL
>
> *         However error shown on browser console that, "failed at_hash".
>
> o   This is because incomplete/truncated token returned and OIDC client
> library in Angular application tries to validate token received.
> Important point here:
>
> *         Defect mentioned only occurs when Apache is in front and used as
> proxy/load balancer server.
>
> My analysis:
>
> *         As per my analysis, I see Keycloak returns access_token
> information in response header during redirect
>
> *         Apache has restriction of handling response header  or cookies
> of size upto 8k
>
> *         Even after setting, various parameters in Apache HTTPD like -
> "LimitRequestFieldSize", "LimitRequestLine" we are still getting this error.
>
>
> Please let me know if anyone already experienced such issue OR has any
> alternative on using/configuring Keycloak to redirect using part response..
>
> Thanks and Regards.
> Rahul Pharande
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mstrukel at redhat.com  Tue Nov  7 10:40:50 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 7 Nov 2017 15:40:50 +0000
Subject: [keycloak-dev] Access Token getting truncated when apache HTTPD
 is in front
In-Reply-To: <CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>
References: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>
	<CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>
Message-ID: <CA+1OW+jAiimQLkSa7zcNbesWtsy6g9zfX_66RQ4=G7-rnsV_NQ@mail.gmail.com>

And please use keycloak-user mailing list for questions like this.

On Tue, Nov 7, 2017 at 3:24 PM, Marko Strukelj <mstrukel at redhat.com> wrote:

> If you increased LimitRequestFieldSize to more than the actual size of the
> header, then this error should be gone or you should be getting a different
> error. Unless you have another proxy / load balancer in front of your
> Apache, or between Apache and Keycloak.
>
> I'd do a little test using curl, setting a header of large length, and
> tcpdump on Keycloak host to make sure header gets through.
>
> On Tue, Nov 7, 2017 at 1:11 PM, Pharande Rahul <rahul.pharande at gi-de.com>
> wrote:
>
>> Hello Team,
>>
>> I'm facing issue of "Access Token getting truncated when apache HTTPD is
>> in front".
>> Though this issue is not directly associated/related to Keycloak but in
>> combination with Apache HTTPD + Keycloak, I would like to take help from
>> experts here :)
>>
>> Below are more details on same.
>>
>> Environnent :
>>
>> o   Server : Keycloak v3.x
>>
>> o   Proxy server :    Apache HTTPD 2.4.x
>>
>> o   Client: Angular2 application using OIDC library.
>>
>> Issue Description / Steps to reproduce:
>>
>> *         Create realm in Keycloak
>>
>> *         Create client for realm along with redirect url etc.
>>
>> *         Create ~70 role/permissions for client with longer names ~25
>> characters in permission name.
>>
>> *         Create user and assign all above permissions for newly created
>> client.
>>
>> *         Access Angular2 application running in browser, and for
>> protected resources Keycloak login page displayed where redirect_uri
>> parameter is given/supplied.
>>
>> *         After entering valid user credentials, keycloak redirects to
>> Application's redirect URL
>>
>> *         However error shown on browser console that, "failed at_hash".
>>
>> o   This is because incomplete/truncated token returned and OIDC client
>> library in Angular application tries to validate token received.
>> Important point here:
>>
>> *         Defect mentioned only occurs when Apache is in front and used
>> as proxy/load balancer server.
>>
>> My analysis:
>>
>> *         As per my analysis, I see Keycloak returns access_token
>> information in response header during redirect
>>
>> *         Apache has restriction of handling response header  or cookies
>> of size upto 8k
>>
>> *         Even after setting, various parameters in Apache HTTPD like -
>> "LimitRequestFieldSize", "LimitRequestLine" we are still getting this error.
>>
>>
>> Please let me know if anyone already experienced such issue OR has any
>> alternative on using/configuring Keycloak to redirect using part response..
>>
>> Thanks and Regards.
>> Rahul Pharande
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From marochm at gmail.com  Tue Nov  7 11:01:35 2017
From: marochm at gmail.com (Marek Chmiel)
Date: Tue, 7 Nov 2017 17:01:35 +0100
Subject: [keycloak-dev] [New feature idea] Add complex filtering to
 endpoints which are resposible for listing and counting users.
Message-ID: <CAESqMhxu6wtkAFH+q9DiyFjh5MWJZbtxeZif5ymC3K-V=FAgHA@mail.gmail.com>

*Current approach*

Currently the*/admin/realms/{realmName}/users* endpoint filter accepts the
following query string parameters:

*search, lastName, firstName, email, username, first, name*

The limitation is we cannot filter users by their custom attributes and
we cannot use complex filtering logic either.
Additionally, since the */**admin/realms/{realmName}**/users/count *accepts
no parameters,
we're unable to retrieve an actual count of all users matching certain
criteria.

*Improvement idea*

The idea is to support additional query string parameter when querying the
REST APIs
on */users* and */users/count* endpoints to manipulate the returned data
so that it is possible to filter user records by any custom attributes and
use complex filtering logic.

The example can be taken from OData spec's $filter attribute
<http://www.odata.org/documentation/odata-version-2-0/uri-conventions/#FilterSystemQueryOption>
or Forgerock OpenAM's filtering capabilities
<https://backstage.forgerock.com/docs/openam/13/dev-guide/#rest-api-filter-sort-page>
.
Both of this solutions introduce a filter parameter, the value of which is
basically a query DSL.

My suggestion is to implement the *$filter* query string parameter of the
following form to match user attributes:

*attribute operator value*

where *attribute *represents one of user's attributes, *operator *is the
operator code, *value *is the value to match.
The operators codes can be as follows:


   - For matching strings:


*equals *
*startswith *
*endswith *

*contains *
   - For matching other value types:

   *ge *- greater than or equal to
   *gt *- greater than
   *le *- less than or equal to
   *lt *- less than

Filters are read left-to-right.
Filters can be composed of multiple expressions by using boolean operators
*and*, *or*, *not *and by using parentheses, *(expression)* to group
expressions.
The *$filter* parameter must be URL-encoded.

I think it's possible to extend Keycloak with such a filter DSL because
underlying user storage is either SQL or LDAP based
and it's fairly easy to translate DSL query to either an SQL query or an
LDAP filter query.

Examples of filter values:

*firstName **startswith **Mar **and **age **gt **18*
*fullName **equals **"Mark Harmon" **or **myCustomLdapMappedAttribute *
*contains **customValue*

Is this something Keycloak might have implemented?
What you think, guys?

From rahul.pharande at gi-de.com  Tue Nov  7 23:47:27 2017
From: rahul.pharande at gi-de.com (Pharande Rahul)
Date: Wed, 8 Nov 2017 04:47:27 +0000
Subject: [keycloak-dev] Access Token getting truncated when apache HTTPD
 is in front
In-Reply-To: <CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>
References: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>
	<CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>
Message-ID: <e3ff7c05aef7457987818039e08df681@gi-de.com>

Hi Marko,

Thanks for quick reply. I already tried setting LimitRequestFieldSize already with very large value but didn?t help.

Looking forward for your test results.

Thanks and Regards.
Rahul Pharande
From: Marko Strukelj [mailto:mstrukel at redhat.com]
Sent: Tuesday, November 07, 2017 8:55 PM
To: Pharande Rahul
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Access Token getting truncated when apache HTTPD is in front

If you increased LimitRequestFieldSize to more than the actual size of the header, then this error should be gone or you should be getting a different error. Unless you have another proxy / load balancer in front of your Apache, or between Apache and Keycloak.

I'd do a little test using curl, setting a header of large length, and tcpdump on Keycloak host to make sure header gets through.

On Tue, Nov 7, 2017 at 1:11 PM, Pharande Rahul <rahul.pharande at gi-de.com<mailto:rahul.pharande at gi-de.com>> wrote:
Hello Team,

I'm facing issue of "Access Token getting truncated when apache HTTPD is in front".
Though this issue is not directly associated/related to Keycloak but in combination with Apache HTTPD + Keycloak, I would like to take help from experts here :)

Below are more details on same.

Environnent :

o   Server : Keycloak v3.x

o   Proxy server :    Apache HTTPD 2.4.x

o   Client: Angular2 application using OIDC library.

Issue Description / Steps to reproduce:

*         Create realm in Keycloak

*         Create client for realm along with redirect url etc.

*         Create ~70 role/permissions for client with longer names ~25 characters in permission name.

*         Create user and assign all above permissions for newly created client.

*         Access Angular2 application running in browser, and for protected resources Keycloak login page displayed where redirect_uri parameter is given/supplied.

*         After entering valid user credentials, keycloak redirects to Application's redirect URL

*         However error shown on browser console that, "failed at_hash".

o   This is because incomplete/truncated token returned and OIDC client library in Angular application tries to validate token received.
Important point here:

*         Defect mentioned only occurs when Apache is in front and used as proxy/load balancer server.

My analysis:

*         As per my analysis, I see Keycloak returns access_token information in response header during redirect

*         Apache has restriction of handling response header  or cookies of size upto 8k

*         Even after setting, various parameters in Apache HTTPD like - "LimitRequestFieldSize", "LimitRequestLine" we are still getting this error.


Please let me know if anyone already experienced such issue OR has any alternative on using/configuring Keycloak to redirect using part response..

Thanks and Regards.
Rahul Pharande

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


From mstrukel at redhat.com  Wed Nov  8 03:34:22 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 8 Nov 2017 08:34:22 +0000
Subject: [keycloak-dev] Access Token getting truncated when apache HTTPD
 is in front
In-Reply-To: <b7a4fcaea4cc419c8d5f0c67ef6c695f@gi-de.com>
References: <d1a44d1adbc6471b92da05c815e69dbc@gi-de.com>
	<CA+1OW+jry-5mv6Tgu=V0z0_8grWdJD6z4H-JWHUfco=Fm32hfg@mail.gmail.com>
	<CAHYJo1-d+dQPZcrzWO36OuarZ-Lr01LqRziYtwvsiz-dss+COw@mail.gmail.com>
	<b7a4fcaea4cc419c8d5f0c67ef6c695f@gi-de.com>
Message-ID: <CA+1OW+hLjE1c8hOD6c4iEyBOcG55hGBGCKtGVxCY53OcT2Bexg@mail.gmail.com>

Sorry, this is the wrong list for this discussion. Please direct any
further questions to keycloak-user mailing list.

From mposolda at redhat.com  Wed Nov  8 04:42:56 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 8 Nov 2017 10:42:56 +0100
Subject: [keycloak-dev] Use LDAP's PasswordPolicy
In-Reply-To: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>
References: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>
Message-ID: <f56d2bf3-7d2d-075d-3606-9644c0de9b49@redhat.com>

Hi Rafael,

Thanks a lot for sharing this!

Few points:
- The https://issues.jboss.org/browse/KEYCLOAK-4052 adds the optional 
config switch whether Keycloak password policies should be checked for 
LDAP password updates. You mentioned it doesn't make too much sense for 
you, however as you can see, there were few people, who want this. Hence 
the switch is optional and it's up to you whether you rely just on LDAP 
password policies or want to use the Keycloak policies too.

- It's great you found the solution for the issue by yourself! 
Unfortunately it looks that solution is specific for OpenLDAP. Is it 
correct? TBH OpenLDAP is not the priority for the Keycloak team. We are 
doing some basic testing with it and it should work, but don't want to 
add the fix, which is specific for OpenLDAP and which contains a bigger 
amount of changes/refactoring as it adds a risk of breaking the other 
things. However if your change doesn't involve too much refactoring in 
the existing code (ideally just the new mapper impl), feel free to send 
the PR.

Maybe you can create JIRA with the description of your requirement and 
the work done and ideally send PR? Then we can discuss whether the PR 
can be accepted or not.

- Some time ago, I worked on support this for MSAD (that one is big 
priority for us). I was also looking at the delete+add approach, but 
that didn't work well. Mainly because the LDAP connection needed to be 
under the user himself as you mentioned and also because you needed to 
know the old password. Not sure if in OpenLDAP you need to know the old 
password too? So in the end, it was possible to just add some request 
controls to the updatePassword LDAP request and the MSAD policies are 
preserved. More details in class LDAPServerPolicyHintsDecorator and some 
background here [1] . Wonder if something possible can be used for 
OpenLDAP too?

[1] 
https://blogs.technet.microsoft.com/fieldcoding/2013/01/09/resetting-passwords-honoring-password-history-or-whats-happening-under-the-hood-when-changing-resetting-passwords/

Marek

On 30/10/17 01:13, Rafael Ladislau wrote:
> Hello, I'm pretty new here, but I've been using Keycloak with an OpenLDAP
> as the user federation and I've noted some problems that I had to fix by
> myself and I would like to share with the community the fixes I've made.
>
> I'm Software Developer at NYU and I had to change the Keycloak source code
> to make it works in one of our Projects. It's not a big refactoring. It's
> reasonable.
>
>
> Problems and my solutions:
>
> 1 - Keycloak changes the password of the users coming from LDAP sending a
> replace command to LDAP using a connection bound to the LDAP administrator.
> (WRITE mode). It allows the users not respect the
> password policy installed in LDAP if it has it installed. In order to fix
> it, you need to use a connection bound to the user changing the password,
> and Keyucloak should send two commands to LDAP: a command to delete the
> password field with the current password value and a command to add the
> password field with the new value. It makes Keycloak respect the password
> policy installed in LDAP, the operation raises an exception when the
> password is not compliant, after my fixes, I'm handling this exception and
> I'm letting the user knows about the error. (I'm doing this in the
> UPDATE_PASSWORD required action and in the manage account screen)
>
>
> 2 - Because I was making Keycloak respect the password policy in LDAP, I
> had to create a Password Policy User Account Control Mapper. This Mapper is
> based on the MSAD User Account Control Mapper. It has the same idea, but it
> writes the properties "pwdReset" and "pwdAccountLockedTime" to make
> Keycloak knows and let OpenLDAP knows when the user must reset his password
> and when the user is locked.
>
>
> 3 - The step 2 is necessary because when you have a password policy in LDAP
> saying the min age is one day, and you set a temporary password for the
> user. If Keycloak doesn't set the pwdReset flag, the user will not be able
> to change his password. (only after 24 hours)
>
>
> 4 - I've made some changes in the User Federation Configuration in order to
> allow the Keycloak administrator turn on and turn off this feature.
>
>
> The issue https://issues.jboss.org/browse/KEYCLOAK-4052 has made the users
> coming from LDAP go through the Keycloak's Password Policy before they
> change their passwords, but what I'm proposing is making Keycloak be aware
> of the Password Policy installed in LDAP.
>
>
> Do you think it would be a good feature?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From list-keycloak at ad-schmidt.de  Wed Nov  8 10:30:23 2017
From: list-keycloak at ad-schmidt.de (Daniel Schmidt)
Date: Wed, 8 Nov 2017 16:30:23 +0100
Subject: [keycloak-dev] Issue with BrowserHandler using the saml2
 adapter in wildfly 10
In-Reply-To: <CAMvXD=G5dp3tgxjANrcbGBmjj5vOsaPLad_VLvx-8DpKo1=5Bg@mail.gmail.com>
References: <4c0dd839-cc8a-2f07-5f4a-2b90a91afc4c@ad-schmidt.de>
	<CAMvXD=G5dp3tgxjANrcbGBmjj5vOsaPLad_VLvx-8DpKo1=5Bg@mail.gmail.com>
Message-ID: <1da40410-c9bf-7689-dd0e-e4fa24d8e870@ad-schmidt.de>

Hi Hynek,

if the url ends in "/saml" authentication works fine. Thanks!

Could you also provide some insight to my second question, whether it is 
possible to combine Keycloak-SAML-Authentication with other 
<login-module>s for one <security-domain>?


Am 27.10.2017 um 09:34 schrieb Hynek Mlnarik:
> What URL have you set for the client saml endpoint in configuration at 
> the identity provider site? The url needs to end in "/saml" without quotes
>
> On Fri, Oct 27, 2017 at 8:47 AM, Daniel Schmidt 
> <list-keycloak at ad-schmidt.de <mailto:list-keycloak at ad-schmidt.de>> wrote:
>
>     Hi everybody,
>
>     I just started to use the SAML2-authentication-adapter of Keycloak in
>     Wildfly 10. I use it according to this documentation:
>     http://www.keycloak.org/docs/3.0/securing_apps/topics/saml/java/jboss-adapter/securing_wars.html
>     <http://www.keycloak.org/docs/3.0/securing_apps/topics/saml/java/jboss-adapter/securing_wars.html>
>
>     As it did not work, I debugged into the adapter code and narrowed the
>     problem down to
>     org.keycloak.adapters.saml.undertow.UndertowSamlAuthenticator.createBrowserHandler(HttpFacade,
>     SamlDeployment, SamlSessionStore) where a
>     org.keycloak.adapters.saml.profile.webbrowsersso.BrowserHandler is
>     instantiated.
>
>     This BrowserHandler always passes null as samlRequest,
>     samlResponse and
>     relayState. When I create a
>     org.keycloak.adapters.saml.profile.webbrowsersso.WebBrowserSsoAuthenticationHandler
>     instead, the code works as expected.
>
>     Is this a bug in the BrowserHandler or am I missing some important
>     configuration option?
>
>     --
>
>     Another question on this topic:
>     The configuration with <secure-deployment >...</secure-deployment>
>     bypasses any existing <login-module> as far as I can see. Is this
>     the case?
>
>     Is there any possibility to configure a custom login-module that could
>     authenticate a user before using the Keycloak authentication
>     mechanism?
>     I would like to use the Keycloak authentication as a fallback only.
>
>
>     Thanks in advance,
>
>     Daniel Schmidt
>
>     _______________________________________________
>     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>
>
>
>
>
> -- 
>
> --Hynek


From sthorger at redhat.com  Wed Nov  8 13:22:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 8 Nov 2017 19:22:51 +0100
Subject: [keycloak-dev] Keycloak 3.4.0.CR1 released
Message-ID: <CAJgngAf1NaVZ-gnbafpmGrY5BdG14HQUB0YkcRqn7zN0zypSTg@mail.gmail.com>

We've just released Keycloak 3.4.0.CR1.

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

The token exchange service allows clients to exchange tokens for different
tokens. There's quite a few options available so check out the docs
<http://www.keycloak.org/docs/latest/securing_apps/index.html#_token-exchange>
for
more details.
Fine-grained permissions for admin endpoints

By leveraging our authorization services we've made it possible to control
permissions in the admin endpoints almost exactly how you want. For more
details check the docs
<http://www.keycloak.org/docs/latest/server_admin/index.html#_fine_grain_permissions>
.
Cross DC

A lot more work has gone into this release around cross DC support. Docs
are still not ready and there's still some minor polish left. This will
come soon.
Upgraded to WildFly 11 Final

We've upgraded the underlying container to WildFly 11 Final.
Support MySQL and PostgreSQL in main Keycloak Docker image

We used to have separate Docker images for MySQL and PostgreSQL, but now we
have one that supports them all.
AsciiDoctor

Our docs used to be built and hosted on GitBook. We've recently moved to
using pure AsciiDoctor to build the docs. The main reason behind this move
was to closer align with how we build documentation for the productized
version of Keycloak (RH-SSO).
Loads more..

   - Script based protocol mapper for OIDC - thanks to thomasdarimont
   <https://github.com/thomasdarimont>
   - Blacklisted password policy- thanks to thomasdarimont
   <https://github.com/thomasdarimont>
   - Login with PayPal - thanks to petlys <https://github.com/petlys>
   - Almost 200 - we almost resolved 200 issues for this one (197!)

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

Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed. Release candidates are not recommended in
production and we do not support upgrading from release candidates.

From cedric.couralet at gmail.com  Thu Nov  9 01:58:36 2017
From: cedric.couralet at gmail.com (=?UTF-8?Q?C=C3=A9dric_Couralet?=)
Date: Thu, 9 Nov 2017 07:58:36 +0100
Subject: [keycloak-dev] Use LDAP's PasswordPolicy
In-Reply-To: <f56d2bf3-7d2d-075d-3606-9644c0de9b49@redhat.com>
References: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>
	<f56d2bf3-7d2d-075d-3606-9644c0de9b49@redhat.com>
Message-ID: <CAMwoAzeaXR5ukvM6pYqKVQdi+UfZs7h5m5mPvW_hcPJvDH7MXQ@mail.gmail.com>

Hello,

For the password policy, I think Keycloak's password is more easily
extensible than openldap's. I'm not sure that the openldap
implementation is the one adopted by other ldap servers.
So, I think, as Marek says, having both options would be a good choice.

For ldap account for the change of password, it would be a real
benefits to use that of the end user, since this would allow to
configure an anonymous connection at the level of the federation
keycloak, which is rather a good point in security term.

Kind regards,
C?dric

2017-11-08 10:42 GMT+01:00 Marek Posolda <mposolda at redhat.com>:
> Hi Rafael,
>
> Thanks a lot for sharing this!
>
> Few points:
> - The https://issues.jboss.org/browse/KEYCLOAK-4052 adds the optional
> config switch whether Keycloak password policies should be checked for
> LDAP password updates. You mentioned it doesn't make too much sense for
> you, however as you can see, there were few people, who want this. Hence
> the switch is optional and it's up to you whether you rely just on LDAP
> password policies or want to use the Keycloak policies too.
>
> - It's great you found the solution for the issue by yourself!
> Unfortunately it looks that solution is specific for OpenLDAP. Is it
> correct? TBH OpenLDAP is not the priority for the Keycloak team. We are
> doing some basic testing with it and it should work, but don't want to
> add the fix, which is specific for OpenLDAP and which contains a bigger
> amount of changes/refactoring as it adds a risk of breaking the other
> things. However if your change doesn't involve too much refactoring in
> the existing code (ideally just the new mapper impl), feel free to send
> the PR.
>
> Maybe you can create JIRA with the description of your requirement and
> the work done and ideally send PR? Then we can discuss whether the PR
> can be accepted or not.
>
> - Some time ago, I worked on support this for MSAD (that one is big
> priority for us). I was also looking at the delete+add approach, but
> that didn't work well. Mainly because the LDAP connection needed to be
> under the user himself as you mentioned and also because you needed to
> know the old password. Not sure if in OpenLDAP you need to know the old
> password too? So in the end, it was possible to just add some request
> controls to the updatePassword LDAP request and the MSAD policies are
> preserved. More details in class LDAPServerPolicyHintsDecorator and some
> background here [1] . Wonder if something possible can be used for
> OpenLDAP too?
>
> [1]
> https://blogs.technet.microsoft.com/fieldcoding/2013/01/09/resetting-passwords-honoring-password-history-or-whats-happening-under-the-hood-when-changing-resetting-passwords/
>
> Marek
>
> On 30/10/17 01:13, Rafael Ladislau wrote:
>> Hello, I'm pretty new here, but I've been using Keycloak with an OpenLDAP
>> as the user federation and I've noted some problems that I had to fix by
>> myself and I would like to share with the community the fixes I've made.
>>
>> I'm Software Developer at NYU and I had to change the Keycloak source code
>> to make it works in one of our Projects. It's not a big refactoring. It's
>> reasonable.
>>
>>
>> Problems and my solutions:
>>
>> 1 - Keycloak changes the password of the users coming from LDAP sending a
>> replace command to LDAP using a connection bound to the LDAP administrator.
>> (WRITE mode). It allows the users not respect the
>> password policy installed in LDAP if it has it installed. In order to fix
>> it, you need to use a connection bound to the user changing the password,
>> and Keyucloak should send two commands to LDAP: a command to delete the
>> password field with the current password value and a command to add the
>> password field with the new value. It makes Keycloak respect the password
>> policy installed in LDAP, the operation raises an exception when the
>> password is not compliant, after my fixes, I'm handling this exception and
>> I'm letting the user knows about the error. (I'm doing this in the
>> UPDATE_PASSWORD required action and in the manage account screen)
>>
>>
>> 2 - Because I was making Keycloak respect the password policy in LDAP, I
>> had to create a Password Policy User Account Control Mapper. This Mapper is
>> based on the MSAD User Account Control Mapper. It has the same idea, but it
>> writes the properties "pwdReset" and "pwdAccountLockedTime" to make
>> Keycloak knows and let OpenLDAP knows when the user must reset his password
>> and when the user is locked.
>>
>>
>> 3 - The step 2 is necessary because when you have a password policy in LDAP
>> saying the min age is one day, and you set a temporary password for the
>> user. If Keycloak doesn't set the pwdReset flag, the user will not be able
>> to change his password. (only after 24 hours)
>>
>>
>> 4 - I've made some changes in the User Federation Configuration in order to
>> allow the Keycloak administrator turn on and turn off this feature.
>>
>>
>> The issue https://issues.jboss.org/browse/KEYCLOAK-4052 has made the users
>> coming from LDAP go through the Keycloak's Password Policy before they
>> change their passwords, but what I'm proposing is making Keycloak be aware
>> of the Password Policy installed in LDAP.
>>
>>
>> Do you think it would be a good feature?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Nov  9 02:53:25 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 9 Nov 2017 08:53:25 +0100
Subject: [keycloak-dev] Use LDAP's PasswordPolicy
In-Reply-To: <CAMwoAzeaXR5ukvM6pYqKVQdi+UfZs7h5m5mPvW_hcPJvDH7MXQ@mail.gmail.com>
References: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>
	<f56d2bf3-7d2d-075d-3606-9644c0de9b49@redhat.com>
	<CAMwoAzeaXR5ukvM6pYqKVQdi+UfZs7h5m5mPvW_hcPJvDH7MXQ@mail.gmail.com>
Message-ID: <17d1ff10-a982-69d9-c01b-43203032fce4@redhat.com>

On 09/11/17 07:58, C?dric Couralet wrote:
> Hello,
>
> For the password policy, I think Keycloak's password is more easily
> extensible than openldap's. I'm not sure that the openldap
> implementation is the one adopted by other ldap servers.
> So, I think, as Marek says, having both options would be a good choice.
>
> For ldap account for the change of password, it would be a real
> benefits to use that of the end user, since this would allow to
> configure an anonymous connection at the level of the federation
> keycloak, which is rather a good point in security term.
Maybe yes, but I am not sure. I can also see some cons/limitations of 
the "LDAP Connection dedicated to the user" approach like:

- Admin requests will still need to use the global federation 
connection. For example when admin updates user attributes (or user 
password) from the Keycloak admin console. The LDAP connection would 
need to be the "global" federation connection. In case that global 
connection is the anonymous connection, it won't work.

- Performance: With the federation connection used everywhere, there is 
single LDAP connection pool and all the requests can use the cached 
connections from this pool. With connections dedicated to each user, the 
connections can't be reused, hence lots of connection open/close.

Feel free to create JIRA, but I think that it won't be a big priority. 
Also I think that we would still need to support the "global connections 
used for everything" approach at least because of the performance.

Marek
>
> Kind regards,
> C?dric
>
> 2017-11-08 10:42 GMT+01:00 Marek Posolda <mposolda at redhat.com>:
>> Hi Rafael,
>>
>> Thanks a lot for sharing this!
>>
>> Few points:
>> - The https://issues.jboss.org/browse/KEYCLOAK-4052 adds the optional
>> config switch whether Keycloak password policies should be checked for
>> LDAP password updates. You mentioned it doesn't make too much sense for
>> you, however as you can see, there were few people, who want this. Hence
>> the switch is optional and it's up to you whether you rely just on LDAP
>> password policies or want to use the Keycloak policies too.
>>
>> - It's great you found the solution for the issue by yourself!
>> Unfortunately it looks that solution is specific for OpenLDAP. Is it
>> correct? TBH OpenLDAP is not the priority for the Keycloak team. We are
>> doing some basic testing with it and it should work, but don't want to
>> add the fix, which is specific for OpenLDAP and which contains a bigger
>> amount of changes/refactoring as it adds a risk of breaking the other
>> things. However if your change doesn't involve too much refactoring in
>> the existing code (ideally just the new mapper impl), feel free to send
>> the PR.
>>
>> Maybe you can create JIRA with the description of your requirement and
>> the work done and ideally send PR? Then we can discuss whether the PR
>> can be accepted or not.
>>
>> - Some time ago, I worked on support this for MSAD (that one is big
>> priority for us). I was also looking at the delete+add approach, but
>> that didn't work well. Mainly because the LDAP connection needed to be
>> under the user himself as you mentioned and also because you needed to
>> know the old password. Not sure if in OpenLDAP you need to know the old
>> password too? So in the end, it was possible to just add some request
>> controls to the updatePassword LDAP request and the MSAD policies are
>> preserved. More details in class LDAPServerPolicyHintsDecorator and some
>> background here [1] . Wonder if something possible can be used for
>> OpenLDAP too?
>>
>> [1]
>> https://blogs.technet.microsoft.com/fieldcoding/2013/01/09/resetting-passwords-honoring-password-history-or-whats-happening-under-the-hood-when-changing-resetting-passwords/
>>
>> Marek
>>
>> On 30/10/17 01:13, Rafael Ladislau wrote:
>>> Hello, I'm pretty new here, but I've been using Keycloak with an OpenLDAP
>>> as the user federation and I've noted some problems that I had to fix by
>>> myself and I would like to share with the community the fixes I've made.
>>>
>>> I'm Software Developer at NYU and I had to change the Keycloak source code
>>> to make it works in one of our Projects. It's not a big refactoring. It's
>>> reasonable.
>>>
>>>
>>> Problems and my solutions:
>>>
>>> 1 - Keycloak changes the password of the users coming from LDAP sending a
>>> replace command to LDAP using a connection bound to the LDAP administrator.
>>> (WRITE mode). It allows the users not respect the
>>> password policy installed in LDAP if it has it installed. In order to fix
>>> it, you need to use a connection bound to the user changing the password,
>>> and Keyucloak should send two commands to LDAP: a command to delete the
>>> password field with the current password value and a command to add the
>>> password field with the new value. It makes Keycloak respect the password
>>> policy installed in LDAP, the operation raises an exception when the
>>> password is not compliant, after my fixes, I'm handling this exception and
>>> I'm letting the user knows about the error. (I'm doing this in the
>>> UPDATE_PASSWORD required action and in the manage account screen)
>>>
>>>
>>> 2 - Because I was making Keycloak respect the password policy in LDAP, I
>>> had to create a Password Policy User Account Control Mapper. This Mapper is
>>> based on the MSAD User Account Control Mapper. It has the same idea, but it
>>> writes the properties "pwdReset" and "pwdAccountLockedTime" to make
>>> Keycloak knows and let OpenLDAP knows when the user must reset his password
>>> and when the user is locked.
>>>
>>>
>>> 3 - The step 2 is necessary because when you have a password policy in LDAP
>>> saying the min age is one day, and you set a temporary password for the
>>> user. If Keycloak doesn't set the pwdReset flag, the user will not be able
>>> to change his password. (only after 24 hours)
>>>
>>>
>>> 4 - I've made some changes in the User Federation Configuration in order to
>>> allow the Keycloak administrator turn on and turn off this feature.
>>>
>>>
>>> The issue https://issues.jboss.org/browse/KEYCLOAK-4052 has made the users
>>> coming from LDAP go through the Keycloak's Password Policy before they
>>> change their passwords, but what I'm proposing is making Keycloak be aware
>>> of the Password Policy installed in LDAP.
>>>
>>>
>>> Do you think it would be a good feature?
>>> _______________________________________________
>>> 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 cedric.couralet at gmail.com  Thu Nov  9 03:07:43 2017
From: cedric.couralet at gmail.com (=?UTF-8?Q?C=C3=A9dric_Couralet?=)
Date: Thu, 9 Nov 2017 09:07:43 +0100
Subject: [keycloak-dev] Use LDAP's PasswordPolicy
In-Reply-To: <17d1ff10-a982-69d9-c01b-43203032fce4@redhat.com>
References: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>
	<f56d2bf3-7d2d-075d-3606-9644c0de9b49@redhat.com>
	<CAMwoAzeaXR5ukvM6pYqKVQdi+UfZs7h5m5mPvW_hcPJvDH7MXQ@mail.gmail.com>
	<17d1ff10-a982-69d9-c01b-43203032fce4@redhat.com>
Message-ID: <CAMwoAzdzCiuSkgW2W_b+Bu2n8v_GF51UW1NEi7cGPb2xa80Q5w@mail.gmail.com>

2017-11-09 8:53 GMT+01:00 Marek Posolda <mposolda at redhat.com>:

>
> Maybe yes, but I am not sure. I can also see some cons/limitations of the
> "LDAP Connection dedicated to the user" approach like:
>
> - Admin requests will still need to use the global federation connection.
> For example when admin updates user attributes (or user password) from the
> Keycloak admin console. The LDAP connection would need to be the "global"
> federation connection. In case that global connection is the anonymous
> connection, it won't work.
>
> - Performance: With the federation connection used everywhere, there is
> single LDAP connection pool and all the requests can use the cached
> connections from this pool. With connections dedicated to each user, the
> connections can't be reused, hence lots of connection open/close.
>

Right, I was thinking egoistically about my use case, where keycloak
is used only for the authentication/authorization mechanism and not
for account management.
Actually, like Rafel proposed, you could just update the credential
with an user bound connection.

From thomas at recloux.fr  Thu Nov  9 05:57:10 2017
From: thomas at recloux.fr (Thomas Recloux)
Date: Thu, 09 Nov 2017 11:57:10 +0100
Subject: [keycloak-dev] Spring boot integration test
Message-ID: <1510225030.51684.1166814832.4E9FAEED@webmail.messagingengine.com>

Hi All,

I'd like to create integration tests for spring boot and spring security
adapters.

I noticed that the JUnit Rule "AbstractKeycloakRule" is now located in
"keycloak-testsuite-integration-deprecated" module, so it loks like it's
not a great idea to use this ;-)

I also noticed that there is the
"testsuite/integration-arquillian/test-apps/spring-boot-adapter" module
but not used and almost empty. What is the status of this module ?

Is there any work in progress in this area ?
Is there any documentation about testsuite/integration-arquillian
structure ?

Thanks, Thomas

From sthorger at redhat.com  Fri Nov 10 00:15:37 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 06:15:37 +0100
Subject: [keycloak-dev] Spring boot integration test
In-Reply-To: <1510225030.51684.1166814832.4E9FAEED@webmail.messagingengine.com>
References: <1510225030.51684.1166814832.4E9FAEED@webmail.messagingengine.com>
Message-ID: <CAJgngAcQtQQyOqinfXncre67REtD8yPddAJXGEApF5hS5f61ug@mail.gmail.com>

We are currently working on this. See
https://issues.jboss.org/browse/KEYCLOAK-4290. I don't know the details
though. Ilya and Sebastien know more about it.



On 9 November 2017 at 11:57, Thomas Recloux <thomas at recloux.fr> wrote:

> Hi All,
>
> I'd like to create integration tests for spring boot and spring security
> adapters.
>
> I noticed that the JUnit Rule "AbstractKeycloakRule" is now located in
> "keycloak-testsuite-integration-deprecated" module, so it loks like it's
> not a great idea to use this ;-)
>
> I also noticed that there is the
> "testsuite/integration-arquillian/test-apps/spring-boot-adapter" module
> but not used and almost empty. What is the status of this module ?
>
> Is there any work in progress in this area ?
> Is there any documentation about testsuite/integration-arquillian
> structure ?
>
> Thanks, Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Nov 10 01:02:47 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 07:02:47 +0100
Subject: [keycloak-dev] Bug squashing time
Message-ID: <CAJgngAcVxWJ=_zKi_vHJxvfZ0x7tZ3Lg1g1PUKe1SPzcGAycEQ@mail.gmail.com>

We're not accepting any contributions for new features until we start on
Keycloak 4.x. Most likely that'll be mid-December. Any PRs for new features
until then will not be reviewed or merged, but feel free to send if you
want.

We do however have a fair amount of outstanding bugs and would love help
from the community to get as many as possible resolved in the next month!

If you'd like to help take a look at
https://issues.jboss.org/projects/KEYCLOAK/versions/12333692 look for
issues that are not assigned to someone. Remember we want tests as well.

From sthorger at redhat.com  Fri Nov 10 01:13:52 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 07:13:52 +0100
Subject: [keycloak-dev] Can't login with email as username if another user
	has same email
Message-ID: <CAJgngAfQG3Z3_sv+ikU+=t_OmidT+ALNyHkCSwMYfXFB2VmSzQ@mail.gmail.com>

If user#1 has the username 'user at host.com' with no email, and user#2 has
the email 'user at host.com', user#1 would not be able to login.

In this case user#1 would have to contact the admin who would have to
change the username or add an email.

This issue was reported a while back by our QE [1], but AFAIK no actual
users have run into this problem and it seems unlikely that it'll be a real
problem.

I'm leaning towards just closing this issue as won't fix.

Best ideas I have for solving is:

1. Make sure username can't match email of another user. Not sure how we
could do this as I'm pretty sure that couldn't be done with SQL.

2. Add a code check for for the above. It won't be guaranteed, but maybe
good enough?

3. Add option to set if realm should allow login by "Username and email",
"Username only" or "Email only". For the "Username and email" option we
should document the fact that this issue can happen and that email always
wins.

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

From Sebastian.Schuster at bosch-si.com  Fri Nov 10 04:49:16 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 10 Nov 2017 09:49:16 +0000
Subject: [keycloak-dev] Custom attributes for roles
Message-ID: <375aa0ef15414745bc681529fa0325aa@FE-MBX1028.de.bosch.com>

Hi everybody,

For compliance reasons, I have to store for each role, who is responsible for managing this role. Keycloak has the nice feature of supporting custom attributes for users and groups. I think supporting my requirement would be best done by also having custom attributes per role (that could for example also be mapped from an LDAP).

Do you think custom role attributes would be a valuable addition and could make it upstream?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn 




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Freitag, 10. November 2017 07:14
To: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [keycloak-dev] Can't login with email as username if another user has same email

If user#1 has the username 'user at host.com' with no email, and user#2 has the email 'user at host.com', user#1 would not be able to login.

In this case user#1 would have to contact the admin who would have to change the username or add an email.

This issue was reported a while back by our QE [1], but AFAIK no actual users have run into this problem and it seems unlikely that it'll be a real problem.

I'm leaning towards just closing this issue as won't fix.

Best ideas I have for solving is:

1. Make sure username can't match email of another user. Not sure how we could do this as I'm pretty sure that couldn't be done with SQL.

2. Add a code check for for the above. It won't be guaranteed, but maybe good enough?

3. Add option to set if realm should allow login by "Username and email", "Username only" or "Email only". For the "Username and email" option we should document the fact that this issue can happen and that email always wins.

[1] https://issues.jboss.org/browse/KEYCLOAK-4466
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Fri Nov 10 04:56:34 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 10:56:34 +0100
Subject: [keycloak-dev] Custom attributes for roles
In-Reply-To: <375aa0ef15414745bc681529fa0325aa@FE-MBX1028.de.bosch.com>
References: <375aa0ef15414745bc681529fa0325aa@FE-MBX1028.de.bosch.com>
Message-ID: <CAJgngAd03j2AC8qPqBOfBvC5sd4vHeEkNSLy=DnpKvoytfGqaA@mail.gmail.com>

I don't think having attributes for roles will be very common need. It
would also make the query to fetch roles more costly.

On 10 November 2017 at 10:49, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi everybody,
>
> For compliance reasons, I have to store for each role, who is responsible
> for managing this role. Keycloak has the nice feature of supporting custom
> attributes for users and groups. I think supporting my requirement would be
> best done by also having custom attributes per role (that could for example
> also be mapped from an LDAP).
>
> Do you think custom role attributes would be a valuable addition and could
> make it upstream?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing.  Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Freitag, 10. November 2017 07:14
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [keycloak-dev] Can't login with email as username if another user
> has same email
>
> If user#1 has the username 'user at host.com' with no email, and user#2 has
> the email 'user at host.com', user#1 would not be able to login.
>
> In this case user#1 would have to contact the admin who would have to
> change the username or add an email.
>
> This issue was reported a while back by our QE [1], but AFAIK no actual
> users have run into this problem and it seems unlikely that it'll be a real
> problem.
>
> I'm leaning towards just closing this issue as won't fix.
>
> Best ideas I have for solving is:
>
> 1. Make sure username can't match email of another user. Not sure how we
> could do this as I'm pretty sure that couldn't be done with SQL.
>
> 2. Add a code check for for the above. It won't be guaranteed, but maybe
> good enough?
>
> 3. Add option to set if realm should allow login by "Username and email",
> "Username only" or "Email only". For the "Username and email" option we
> should document the fact that this issue can happen and that email always
> wins.
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-4466
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Fri Nov 10 05:29:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 11:29:51 +0100
Subject: [keycloak-dev] Keycloak 3.4.0.Final released
Message-ID: <CAJgngAc5eYoeQaW3JBmMDbF7O-wQR2hpbcECnhGYjB6pVve0qA@mail.gmail.com>

We've just released Keycloak 3.4.0.Final.

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

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

Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed.

From thomas.darimont at googlemail.com  Fri Nov 10 05:47:04 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 10 Nov 2017 11:47:04 +0100
Subject: [keycloak-dev] Keycloak 3.4.0.Final released
In-Reply-To: <CAJgngAc5eYoeQaW3JBmMDbF7O-wQR2hpbcECnhGYjB6pVve0qA@mail.gmail.com>
References: <CAJgngAc5eYoeQaW3JBmMDbF7O-wQR2hpbcECnhGYjB6pVve0qA@mail.gmail.com>
Message-ID: <CAK-7U1gcN-JBuAq9Swwt3fm5BHvR90eouSrM1+kJSNQf1t9d-A@mail.gmail.com>

Hello,

this seems to be a bugfix release - is there any particular reason why this
was not released as 3.3.1.Final?

Cheers,
Thomas

2017-11-10 11:29 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> We've just released Keycloak 3.4.0.Final.
>
> To download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>.
>
> The full list of resolved issues is available in JIRA
> <https://issues.jboss.org/issues/?jql=project%20%3D%
> 20keycloak%20and%20fixVersion%20%3D%203.4.0.Final>
> .
> Upgrading
>
> Before you upgrade remember to backup your database and check the upgrade
> guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
> anything that may have changed.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Nov 10 06:56:47 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 10 Nov 2017 12:56:47 +0100
Subject: [keycloak-dev] Keycloak 3.4.0.Final released
In-Reply-To: <CAK-7U1gcN-JBuAq9Swwt3fm5BHvR90eouSrM1+kJSNQf1t9d-A@mail.gmail.com>
References: <CAJgngAc5eYoeQaW3JBmMDbF7O-wQR2hpbcECnhGYjB6pVve0qA@mail.gmail.com>
	<CAK-7U1gcN-JBuAq9Swwt3fm5BHvR90eouSrM1+kJSNQf1t9d-A@mail.gmail.com>
Message-ID: <CAJgngAeVK3uTAbb5PEo88ihzDGDBPCc+pOhSp5BVPbe=q7EeVA@mail.gmail.com>

Look at all the stuff that went into 3.4.0.CR1

On 10 November 2017 at 11:47, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> this seems to be a bugfix release - is there any particular reason why
> this was not released as 3.3.1.Final?
>
> Cheers,
> Thomas
>
> 2017-11-10 11:29 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We've just released Keycloak 3.4.0.Final.
>>
>> To download the release go to the Keycloak homepage
>> <http://www.keycloak.org/downloads>.
>>
>> The full list of resolved issues is available in JIRA
>> <https://issues.jboss.org/issues/?jql=project%20%3D%20keyclo
>> ak%20and%20fixVersion%20%3D%203.4.0.Final>
>> .
>> Upgrading
>>
>> Before you upgrade remember to backup your database and check the upgrade
>> guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
>> anything that may have changed.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From thomas.darimont at googlemail.com  Fri Nov 10 07:03:09 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 10 Nov 2017 13:03:09 +0100
Subject: [keycloak-dev] Keycloak 3.4.0.Final released
In-Reply-To: <CAJgngAeVK3uTAbb5PEo88ihzDGDBPCc+pOhSp5BVPbe=q7EeVA@mail.gmail.com>
References: <CAJgngAc5eYoeQaW3JBmMDbF7O-wQR2hpbcECnhGYjB6pVve0qA@mail.gmail.com>
	<CAK-7U1gcN-JBuAq9Swwt3fm5BHvR90eouSrM1+kJSNQf1t9d-A@mail.gmail.com>
	<CAJgngAeVK3uTAbb5PEo88ihzDGDBPCc+pOhSp5BVPbe=q7EeVA@mail.gmail.com>
Message-ID: <CAK-7U1h67VvNiiBmvjf9074Z=VVOxfv93icKqavoVspwQ7gd7w@mail.gmail.com>

Ah okay sorry, didn't think of that :-(

This jira-search listsi more issues indeed.
https://issues.jboss.org/browse/KEYCLOAK-5796?jql=project%20%3D%20KEYCLOAK%20AND%20fixVersion%20in%20(3.4.0.Final%2C%203.4.0.CR1)

Thanks for the hint.

Cheers,
Thomas


2017-11-10 12:56 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Look at all the stuff that went into 3.4.0.CR1
>
> On 10 November 2017 at 11:47, Thomas Darimont <thomas.darimont at googlemail.
> com> wrote:
>
>> Hello,
>>
>> this seems to be a bugfix release - is there any particular reason why
>> this was not released as 3.3.1.Final?
>>
>> Cheers,
>> Thomas
>>
>> 2017-11-10 11:29 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> We've just released Keycloak 3.4.0.Final.
>>>
>>> To download the release go to the Keycloak homepage
>>> <http://www.keycloak.org/downloads>.
>>>
>>> The full list of resolved issues is available in JIRA
>>> <https://issues.jboss.org/issues/?jql=project%20%3D%20keyclo
>>> ak%20and%20fixVersion%20%3D%203.4.0.Final>
>>> .
>>> Upgrading
>>>
>>> Before you upgrade remember to backup your database and check the upgrade
>>> guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
>>> anything that may have changed.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From Sebastian.Schuster at bosch-si.com  Fri Nov 10 07:20:35 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 10 Nov 2017 12:20:35 +0000
Subject: [keycloak-dev] Can't login with email as username if another
	user	has same email
In-Reply-To: <CAJgngAfQG3Z3_sv+ikU+=t_OmidT+ALNyHkCSwMYfXFB2VmSzQ@mail.gmail.com>
References: <CAJgngAfQG3Z3_sv+ikU+=t_OmidT+ALNyHkCSwMYfXFB2VmSzQ@mail.gmail.com>
Message-ID: <9404bcf743194f57b317a1f4a8f68ae9@FE-MBX1028.de.bosch.com>

I could also imagine enforcing in the server that whenever a user has an email as the username, it is always identical to the email address.
However, that change might be problematic considering all the existing data...

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn 




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Freitag, 10. November 2017 07:14
To: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [keycloak-dev] Can't login with email as username if another user has same email

If user#1 has the username 'user at host.com' with no email, and user#2 has the email 'user at host.com', user#1 would not be able to login.

In this case user#1 would have to contact the admin who would have to change the username or add an email.

This issue was reported a while back by our QE [1], but AFAIK no actual users have run into this problem and it seems unlikely that it'll be a real problem.

I'm leaning towards just closing this issue as won't fix.

Best ideas I have for solving is:

1. Make sure username can't match email of another user. Not sure how we could do this as I'm pretty sure that couldn't be done with SQL.

2. Add a code check for for the above. It won't be guaranteed, but maybe good enough?

3. Add option to set if realm should allow login by "Username and email", "Username only" or "Email only". For the "Username and email" option we should document the fact that this issue can happen and that email always wins.

[1] https://issues.jboss.org/browse/KEYCLOAK-4466
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Fri Nov 10 10:37:15 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Nov 2017 10:37:15 -0500
Subject: [keycloak-dev] Build broken on Windows
Message-ID: <2436528e-2e46-77b0-eb68-9e38fde85d70@redhat.com>

This commit broke the build on Windows.  It is using symlinks. While 
there are workarounds, I don't think we want to complicate things by 
merging symlinks into our code base.
https://github.com/keycloak/keycloak/commit/f88b3cddb6630aae4e058f7173c7f47529d2482c

Please fix!!!

From thomas.darimont at googlemail.com  Fri Nov 10 12:06:14 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 10 Nov 2017 18:06:14 +0100
Subject: [keycloak-dev] FYI keycloak-3.4.0.Final artifact does not contain
	jpa-changelog-3.4.0.xml
Message-ID: <CAK-7U1jygdDPRgfsHOrz36JPc0qWOPEBRwn7kr6CiFj-+q0rQA@mail.gmail.com>

Hi Keycloak Team,

I just stumbled upon the fact that the latest downloadable Keycloak release
3.4.0.Final
which was announced today does not contain the jpa-changelog-3.4.0.xml
migration.

Was this intended?

FYI The current master branch contains a jpa-changelog-master.xml which
references
jpa-changelog-3.4.0.xml which was added 17days ago.

https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-master.xml

Cheers,
Thomas

From john.d.ament at gmail.com  Fri Nov 10 14:58:53 2017
From: john.d.ament at gmail.com (John D. Ament)
Date: Fri, 10 Nov 2017 19:58:53 +0000
Subject: [keycloak-dev] 5111x SQL Executions
Message-ID: <CAOqetn-RWtUbPQH0UFWJTxoS_6pCyt8td8+xaqur+V91DaNM=g@mail.gmail.com>

Hi,

So we've nailed down most of our performance issues (figured out why
caching was off as well).  We're seeing that the last call that's
struggling is the whoami call.  We see 5k SQL executions for the following
query: 5,111 ? select userrolema0_.ROLE_ID as col_0_0_ from
USER_ROLE_MAPPING userrolema0_ where userrolema0_.USER_ID=?

I've put together a gist of the request/response to better highlight what I
believe the issue is.  Basically, for every realm and every role the user
has, one query is executed.  This data isn't loaded from the cache for some
reason.  I'm wondering if for role mapping does it make sense to simply
load all of them for a given user?

Gist: https://gist.github.com/johnament/e2be3ba7bda695b014caa695ebffdd61

John

From irum at redhat.com  Mon Nov 13 05:18:18 2017
From: irum at redhat.com (Ilya Rum)
Date: Mon, 13 Nov 2017 11:18:18 +0100
Subject: [keycloak-dev] Spring boot integration test
In-Reply-To: <CAJgngAcQtQQyOqinfXncre67REtD8yPddAJXGEApF5hS5f61ug@mail.gmail.com>
References: <1510225030.51684.1166814832.4E9FAEED@webmail.messagingengine.com>
	<CAJgngAcQtQQyOqinfXncre67REtD8yPddAJXGEApF5hS5f61ug@mail.gmail.com>
Message-ID: <CAJHsxukskZSmQV1-6b6QtXF1FEqOxd+eAsT7WNiZOX_0nBryxw@mail.gmail.com>

Hello.

Spring boot integration tests are located in
testsuite/integration-arquillian/tests/others/springboot-tests/
test-apps/spring-boot-adapter is a springboot application which is started
with the tests.
Work is in progress

As for documentation, all of it is located in README files
you can start with testsuite/integration-arquillian/README.md in case you
are interested.

Ilya Rum.

On Fri, Nov 10, 2017 at 6:15 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We are currently working on this. See https://issues.jboss.org/
> browse/KEYCLOAK-4290. I don't know the details though. Ilya and Sebastien
> know more about it.
>
>
>
> On 9 November 2017 at 11:57, Thomas Recloux <thomas at recloux.fr> wrote:
>
>> Hi All,
>>
>> I'd like to create integration tests for spring boot and spring security
>> adapters.
>>
>> I noticed that the JUnit Rule "AbstractKeycloakRule" is now located in
>> "keycloak-testsuite-integration-deprecated" module, so it loks like it's
>> not a great idea to use this ;-)
>>
>> I also noticed that there is the
>> "testsuite/integration-arquillian/test-apps/spring-boot-adapter" module
>> but not used and almost empty. What is the status of this module ?
>>
>> Is there any work in progress in this area ?
>> Is there any documentation about testsuite/integration-arquillian
>> structure ?
>>
>> Thanks, Thomas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Mon Nov 13 07:30:33 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Nov 2017 13:30:33 +0100
Subject: [keycloak-dev] FYI keycloak-3.4.0.Final artifact does not
	contain jpa-changelog-3.4.0.xml
In-Reply-To: <CAK-7U1jygdDPRgfsHOrz36JPc0qWOPEBRwn7kr6CiFj-+q0rQA@mail.gmail.com>
References: <CAK-7U1jygdDPRgfsHOrz36JPc0qWOPEBRwn7kr6CiFj-+q0rQA@mail.gmail.com>
Message-ID: <CAJgngAdu=C5-oEYRkPYyJzaQGbNytNfAdT=vioixUd1H8E9O+g@mail.gmail.com>

Not sure what's happened, but it looks like 3.4.0.Final missed quite a few
changes that was in master.

We'll fix the changelog in 3.4.1 which should be out in 2 weeks. That will
also include other changes that wasn't included.

On 10 November 2017 at 18:06, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hi Keycloak Team,
>
> I just stumbled upon the fact that the latest downloadable Keycloak release
> 3.4.0.Final
> which was announced today does not contain the jpa-changelog-3.4.0.xml
> migration.
>
> Was this intended?
>
> FYI The current master branch contains a jpa-changelog-master.xml which
> references
> jpa-changelog-3.4.0.xml which was added 17days ago.
>
> https://github.com/keycloak/keycloak/blob/master/model/
> jpa/src/main/resources/META-INF/jpa-changelog-master.xml
>
> 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  Mon Nov 13 07:32:46 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Nov 2017 13:32:46 +0100
Subject: [keycloak-dev] Build broken on Windows
In-Reply-To: <2436528e-2e46-77b0-eb68-9e38fde85d70@redhat.com>
References: <2436528e-2e46-77b0-eb68-9e38fde85d70@redhat.com>
Message-ID: <CAJgngAdaiB=YpdL3UuwhA_0tkUFUs1Wr_tnNx-jGsizx=Uq1JA@mail.gmail.com>

We'll either have to get rid of symlinks and just duplicate the license
data or put some workaround in place.

Stan - can you create a JIRA for this for Alex to work on please?

On 10 November 2017 at 16:37, Stan Silvert <ssilvert at redhat.com> wrote:

> This commit broke the build on Windows.  It is using symlinks. While
> there are workarounds, I don't think we want to complicate things by
> merging symlinks into our code base.
> https://github.com/keycloak/keycloak/commit/f88b3cddb6630aae4e058f7173c7f4
> 7529d2482c
>
> Please fix!!!
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Mon Nov 13 07:51:14 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 13 Nov 2017 07:51:14 -0500
Subject: [keycloak-dev] Build broken on Windows
In-Reply-To: <CAJgngAdaiB=YpdL3UuwhA_0tkUFUs1Wr_tnNx-jGsizx=Uq1JA@mail.gmail.com>
References: <2436528e-2e46-77b0-eb68-9e38fde85d70@redhat.com>
	<CAJgngAdaiB=YpdL3UuwhA_0tkUFUs1Wr_tnNx-jGsizx=Uq1JA@mail.gmail.com>
Message-ID: <d484f83f-36a1-46e1-d3e9-6fca3b2888d5@redhat.com>

On 11/13/2017 7:32 AM, Stian Thorgersen wrote:
> We'll either have to get rid of symlinks and just duplicate the 
> license data or put some workaround in place.
>
> Stan - can you create a JIRA for this for Alex to work on please?
https://issues.jboss.org/browse/KEYCLOAK-5843
>
> On 10 November 2017 at 16:37, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     This commit broke the build on Windows.  It is using symlinks. While
>     there are workarounds, I don't think we want to complicate things by
>     merging symlinks into our code base.
>     https://github.com/keycloak/keycloak/commit/f88b3cddb6630aae4e058f7173c7f47529d2482c
>     <https://github.com/keycloak/keycloak/commit/f88b3cddb6630aae4e058f7173c7f47529d2482c>
>
>     Please fix!!!
>     _______________________________________________
>     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  Mon Nov 13 08:57:56 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 13 Nov 2017 08:57:56 -0500
Subject: [keycloak-dev] Console Tests
Message-ID: <ff58933f-03e0-780b-87ea-d0769eeadf50@redhat.com>

Right now, the admin console tests are not being run as part of CI. As a 
result, they have become neglected and broken.  The console bugs I am 
fixing right now are minor and for now we can get away with merging 
fixes that don't include unit tests, but the longer we wait, the worse 
this will get.

Can we come up with a plan to get these tests running again?

FYI, when I try to run a console test, I get:
Caused by: java.lang.IllegalStateException: Password blacklists location 
does not exist: 
c:\GitHub\keycloak\testsuite\integration-arquillian\tests\other\console\target\test-classes\password-blacklists

I can manually create the password-blacklists directory, but then I get:
08:51:31,786 ERROR [io.undertow.request] UT005023: Exception handling 
request to /auth/realms/master/protocol/openid-connect/token
org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: 
Uncompilable source code - Erroneous sym type: 
org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote
...
...
Caused by: java.lang.RuntimeException: Uncompilable source code - 
Erroneous sym type: 
org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote

From psilva at redhat.com  Mon Nov 13 09:52:56 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 13 Nov 2017 12:52:56 -0200
Subject: [keycloak-dev] Client and Service Account Session
Message-ID: <CAJrcDBeyY_ThVOvJQLZFTpdbWKmo5Jeef39Gf+7kAM_M2B+JFg@mail.gmail.com>

Hi,

Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.

To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.

Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.

What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?

Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.

Regards.
Pedro Igor

From sthorger at redhat.com  Mon Nov 13 10:37:18 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 13 Nov 2017 16:37:18 +0100
Subject: [keycloak-dev] Can't login with email as username if another
 user has same email
In-Reply-To: <9404bcf743194f57b317a1f4a8f68ae9@FE-MBX1028.de.bosch.com>
References: <CAJgngAfQG3Z3_sv+ikU+=t_OmidT+ALNyHkCSwMYfXFB2VmSzQ@mail.gmail.com>
	<9404bcf743194f57b317a1f4a8f68ae9@FE-MBX1028.de.bosch.com>
Message-ID: <CAJgngAci6wbmtymvAi2p77tqW4ghnNFOre7Sg-uQKCYtU-xi0w@mail.gmail.com>

That might be a good option. We could potentially do that only for new
users and leave existing users untouched during migration.

On 10 November 2017 at 13:20, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> I could also imagine enforcing in the server that whenever a user has an
> email as the username, it is always identical to the email address.
> However, that change might be problematic considering all the existing
> data...
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing.  Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Freitag, 10. November 2017 07:14
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [keycloak-dev] Can't login with email as username if another user
> has same email
>
> If user#1 has the username 'user at host.com' with no email, and user#2 has
> the email 'user at host.com', user#1 would not be able to login.
>
> In this case user#1 would have to contact the admin who would have to
> change the username or add an email.
>
> This issue was reported a while back by our QE [1], but AFAIK no actual
> users have run into this problem and it seems unlikely that it'll be a real
> problem.
>
> I'm leaning towards just closing this issue as won't fix.
>
> Best ideas I have for solving is:
>
> 1. Make sure username can't match email of another user. Not sure how we
> could do this as I'm pretty sure that couldn't be done with SQL.
>
> 2. Add a code check for for the above. It won't be guaranteed, but maybe
> good enough?
>
> 3. Add option to set if realm should allow login by "Username and email",
> "Username only" or "Email only". For the "Username and email" option we
> should document the fact that this issue can happen and that email always
> wins.
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-4466
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Mon Nov 13 17:45:31 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 13 Nov 2017 22:45:31 +0000
Subject: [keycloak-dev] Console Tests
In-Reply-To: <ff58933f-03e0-780b-87ea-d0769eeadf50@redhat.com>
References: <ff58933f-03e0-780b-87ea-d0769eeadf50@redhat.com>
Message-ID: <CAM5SUC7ov6pL5oZ8wVPvu-nHbTRkqbT8dL=OrUWjvArZNZd=qg@mail.gmail.com>

I believe they are part of central CI, just look for keycloak-ui job.

On Mon, Nov 13, 2017 at 12:53 PM Stan Silvert <ssilvert at redhat.com> wrote:

> Right now, the admin console tests are not being run as part of CI. As a
> result, they have become neglected and broken.  The console bugs I am
> fixing right now are minor and for now we can get away with merging
> fixes that don't include unit tests, but the longer we wait, the worse
> this will get.
>
> Can we come up with a plan to get these tests running again?
>
> FYI, when I try to run a console test, I get:
> Caused by: java.lang.IllegalStateException: Password blacklists location
> does not exist:
>
> c:\GitHub\keycloak\testsuite\integration-arquillian\tests\other\console\target\test-classes\password-blacklists
>
> I can manually create the password-blacklists directory, but then I get:
> 08:51:31,786 ERROR [io.undertow.request] UT005023: Exception handling
> request to /auth/realms/master/protocol/openid-connect/token
> org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException:
> Uncompilable source code - Erroneous sym type:
>
> org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote
> ...
> ...
> Caused by: java.lang.RuntimeException: Uncompilable source code -
> Erroneous sym type:
>
> org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From vmuzikar at redhat.com  Tue Nov 14 01:51:43 2017
From: vmuzikar at redhat.com (Vaclav Muzikar)
Date: Tue, 14 Nov 2017 07:51:43 +0100
Subject: [keycloak-dev] Console Tests
In-Reply-To: <CAM5SUC7ov6pL5oZ8wVPvu-nHbTRkqbT8dL=OrUWjvArZNZd=qg@mail.gmail.com>
References: <ff58933f-03e0-780b-87ea-d0769eeadf50@redhat.com>
	<CAM5SUC7ov6pL5oZ8wVPvu-nHbTRkqbT8dL=OrUWjvArZNZd=qg@mail.gmail.com>
Message-ID: <CAMQSZygtuMNAW-ioP6xgzWm6b9_oCXDKKpHk9QpTtxX5oamkHA@mail.gmail.com>

Yes, Console UI tests are run in a CI job (with FF, Chrome and IE + Safari
will be added in the near future).
I'm currently working on fixing them as they are yet again broken/unstable
(UsersInRoleTest which was merged already broken + AuthZ tests recently
started to be randomly unstable again, mainly in the IE).
This is the main problem of those tests - they're very prone to get
unstable, and this "instability ratio" differs from browser to browser.

But I believe if we managed to get those tests running in Travis with at
least one of the browsers (e.g. Chrome headless which is most stable from
them all), we'd prevented at lest merging broken tests and UI changes as
well as prevented most of the instability issues.
The typical current scenario is:
1) Someone breaks something in the UI, or breaks/makes unstable just the
tests either for one browser or even all of them
2) Those changes are merged since Travis passed
3) The CI job starts to be unstable or broken completely
4) I then need to go, find the problem (if it's just a test issue or a real
bug) and identify the affected browsers, and then fix the test, or file a
JIRA for the bug and ignore the broken test
I believe this is not very efficient and imho I'd be perfect if we managed
to discover at least some of those problems before merging (it'd saved me
some headaches :)).

@Stan Regarding the "Password blacklists location". Should've been fixed
with https://github.com/keycloak/keycloak/pull/4646

V.

On Mon, Nov 13, 2017 at 11:45 PM, Bruno Oliveira <bruno at abstractj.org>
wrote:

> I believe they are part of central CI, just look for keycloak-ui job.
>
> On Mon, Nov 13, 2017 at 12:53 PM Stan Silvert <ssilvert at redhat.com> wrote:
>
> > Right now, the admin console tests are not being run as part of CI. As a
> > result, they have become neglected and broken.  The console bugs I am
> > fixing right now are minor and for now we can get away with merging
> > fixes that don't include unit tests, but the longer we wait, the worse
> > this will get.
> >
> > Can we come up with a plan to get these tests running again?
> >
> > FYI, when I try to run a console test, I get:
> > Caused by: java.lang.IllegalStateException: Password blacklists location
> > does not exist:
> >
> > c:\GitHub\keycloak\testsuite\integration-arquillian\tests\
> other\console\target\test-classes\password-blacklists
> >
> > I can manually create the password-blacklists directory, but then I get:
> > 08:51:31,786 ERROR [io.undertow.request] UT005023: Exception handling
> > request to /auth/realms/master/protocol/openid-connect/token
> > org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException:
> > Uncompilable source code - Erroneous sym type:
> >
> > org.keycloak.authentication.AuthenticationFlowContext.
> getAuthenticationSession.setAuthNote
> > ...
> > ...
> > Caused by: java.lang.RuntimeException: Uncompilable source code -
> > Erroneous sym type:
> >
> > org.keycloak.authentication.AuthenticationFlowContext.
> getAuthenticationSession.setAuthNote
> > _______________________________________________
> > 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
>



-- 
V?clav Muzik??
Quality Engineer
Keycloak / Red Hat Single Sign-On
Red Hat Czech s.r.o.

From 1rahulr at gmail.com  Tue Nov 14 05:13:15 2017
From: 1rahulr at gmail.com (Rahul R)
Date: Tue, 14 Nov 2017 15:43:15 +0530
Subject: [keycloak-dev] access token valid for more than expiry time by
	milli seconds
Message-ID: <CADDv_=G4+zCm=+yHUEytVHqMnZAnmd45sd0An++Tzqa=9begTA@mail.gmail.com>

>
> Hi,
>      We have a keycloak set up where the Access Token Lifespan is set to 5
> minutes. We get the access token using the following command :
> curl  -d "client_id=admin-cli" -d "username=admin_user"   -d
> "password=admin_user"   -d "grant_type=password"   "
> http://192.168.56.101:8080/auth/realms/REALM/protocol/openid-connect/token
> "
>
> Now we use the following command to get the user details
>  curl -H "Authorization: bearer "access token value got earlier"  "
> http://192.168.56.101:8080/auth/realms/REALM/protocol/openi
> d-connect/userinfo"
>
> The expectation is that the second command works till the token expiry
> time which is 5 minutes and after 5 minutes the token not valid error
> should be seen. But while running the tests multiple times,  we are seeing
> that sometimes the token is valid for more than 5 minutes by almost 500
> milliseconds.
>
> From the RFC for JWT  https://tools.ietf.org/html/rfc7519
>
> 4.1.4.  "exp" (Expiration Time) Claim
>
> The "exp" (expiration time) claim identifies the expiration time on or
> after which the JWT MUST NOT be accepted for processing.  The processing of
> the "exp" claim requires that the current date/time MUST be before the
> expiration date/time listed in the "exp" claim. Implementers MAY provide
> for some small leeway, usually no more than a few minutes, to account for
> clock skew.  Its value MUST be a number containing a NumericDate value.
> Use of this claim is OPTIONAL.
>
> So is this delay intentional from the keycloak implementors ?
>
> Thanks
> Rahul
>

From ssilvert at redhat.com  Tue Nov 14 07:21:03 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 14 Nov 2017 07:21:03 -0500
Subject: [keycloak-dev] Console Tests
In-Reply-To: <CAMQSZygtuMNAW-ioP6xgzWm6b9_oCXDKKpHk9QpTtxX5oamkHA@mail.gmail.com>
References: <ff58933f-03e0-780b-87ea-d0769eeadf50@redhat.com>
	<CAM5SUC7ov6pL5oZ8wVPvu-nHbTRkqbT8dL=OrUWjvArZNZd=qg@mail.gmail.com>
	<CAMQSZygtuMNAW-ioP6xgzWm6b9_oCXDKKpHk9QpTtxX5oamkHA@mail.gmail.com>
Message-ID: <c060dcb1-a264-0c4b-d562-a4f1b3861cbf@redhat.com>

Good news.  I'm glad to hear you are actively working on it.  Please 
keep us updated on your progress and let me know if I can help.  It's 
becoming more and more clear that the stability of the admin console is 
suffering because these tests aren't run before merging.

On 11/14/2017 1:51 AM, Vaclav Muzikar wrote:
> Yes, Console UI tests are run in a CI job (with FF, Chrome and IE + 
> Safari will be added in the near future).
> I'm currently working on fixing them as they are yet again 
> broken/unstable (UsersInRoleTest which was merged already broken + 
> AuthZ tests recently started to be randomly unstable again, mainly in 
> the IE).
> This is the main problem of those tests - they're very prone to get 
> unstable, and this "instability ratio" differs from browser to browser.
>
> But I believe if we managed to get those tests running in Travis with 
> at least one of the browsers (e.g. Chrome headless which is most 
> stable from them all), we'd prevented at lest merging broken tests and 
> UI changes as well as prevented most of the instability issues.
> The typical current scenario is:
> 1) Someone breaks something in the UI, or breaks/makes unstable just 
> the tests either for one browser or even all of them
> 2) Those changes are merged since Travis passed
> 3) The CI job starts to be unstable or broken completely
> 4) I then need to go, find the problem (if it's just a test issue or a 
> real bug) and identify the affected browsers, and then fix the test, 
> or file a JIRA for the bug and ignore the broken test
> I believe this is not very efficient and imho I'd be perfect if we 
> managed to discover at least some of those problems before merging 
> (it'd saved me some headaches :)).
>
> @Stan Regarding the "Password blacklists location". Should've been 
> fixed with https://github.com/keycloak/keycloak/pull/4646
>
> V.
>
> On Mon, Nov 13, 2017 at 11:45 PM, Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> wrote:
>
>     I believe they are part of central CI, just look for keycloak-ui job.
>
>     On Mon, Nov 13, 2017 at 12:53 PM Stan Silvert <ssilvert at redhat.com
>     <mailto:ssilvert at redhat.com>> wrote:
>
>     > Right now, the admin console tests are not being run as part of
>     CI. As a
>     > result, they have become neglected and broken.  The console bugs
>     I am
>     > fixing right now are minor and for now we can get away with merging
>     > fixes that don't include unit tests, but the longer we wait, the
>     worse
>     > this will get.
>     >
>     > Can we come up with a plan to get these tests running again?
>     >
>     > FYI, when I try to run a console test, I get:
>     > Caused by: java.lang.IllegalStateException: Password blacklists
>     location
>     > does not exist:
>     >
>     >
>     c:\GitHub\keycloak\testsuite\integration-arquillian\tests\other\console\target\test-classes\password-blacklists
>     >
>     > I can manually create the password-blacklists directory, but
>     then I get:
>     > 08:51:31,786 ERROR [io.undertow.request] UT005023: Exception
>     handling
>     > request to /auth/realms/master/protocol/openid-connect/token
>     > org.jboss.resteasy.spi.UnhandledException:
>     java.lang.RuntimeException:
>     > Uncompilable source code - Erroneous sym type:
>     >
>     >
>     org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote
>     > ...
>     > ...
>     > Caused by: java.lang.RuntimeException: Uncompilable source code -
>     > Erroneous sym type:
>     >
>     >
>     org.keycloak.authentication.AuthenticationFlowContext.getAuthenticationSession.setAuthNote
>     > _______________________________________________
>     > 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>
>
>
>
>
> -- 
> V?clav Muzik??
> Quality Engineer
> Keycloak / Red Hat Single Sign-On
> Red Hat Czech s.r.o.


From ssilvert at redhat.com  Tue Nov 14 15:22:51 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 14 Nov 2017 15:22:51 -0500
Subject: [keycloak-dev] Keycloak email setup "the easy way"
Message-ID: <2a971921-3ff4-daef-83b3-8feffc6235c0@redhat.com>

I just came across what I think is the probably easiest possible way to 
set up Keycloak's SMTP for testing.  So I thought I should share.

If you want/need to test things like password recovery and "verify 
email", here is the tip:

In Admin Console:
1) Go to Realm Settings-->Email
2) Set host to aspmx.l.google.com
3) Set port to 25
4) Use whatever you want for the other fields
5) Note that Enable SSL, Enable StartTLS, and Enable Authentication can 
be left "OFF".
6) Create a new test user with a gmail email address.

This only works for gmail users, so your test user needs a gmail account 
of some kind.  It doesn't need to be "@gmail.com", but it must be a 
gmail account.

For reference:
https://support.google.com/a/answer/176600?hl=en

From bruno at abstractj.org  Tue Nov 14 18:15:04 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 14 Nov 2017 23:15:04 +0000
Subject: [keycloak-dev] Keycloak email setup "the easy way"
In-Reply-To: <2a971921-3ff4-daef-83b3-8feffc6235c0@redhat.com>
References: <2a971921-3ff4-daef-83b3-8feffc6235c0@redhat.com>
Message-ID: <CAM5SUC7da4Q_0SRUzmiVgj7Ot=UsU1=RTcmzgvzbvPHtsYkL6Q@mail.gmail.com>

To me the easiest way is:

docker run -d -p 1025:1025 -p 8025:8025 mailhog/mailhog

In Admin Console:
1) Go to Realm Settings-->Email
2) Set host to localhost
3) Set port to 1025

Mailhog will run on port 8025


On Tue, Nov 14, 2017 at 7:58 PM Stan Silvert <ssilvert at redhat.com> wrote:

> I just came across what I think is the probably easiest possible way to
> set up Keycloak's SMTP for testing.  So I thought I should share.
>
> If you want/need to test things like password recovery and "verify
> email", here is the tip:
>
> In Admin Console:
> 1) Go to Realm Settings-->Email
> 2) Set host to aspmx.l.google.com
> 3) Set port to 25
> 4) Use whatever you want for the other fields
> 5) Note that Enable SSL, Enable StartTLS, and Enable Authentication can
> be left "OFF".
> 6) Create a new test user with a gmail email address.
>
> This only works for gmail users, so your test user needs a gmail account
> of some kind.  It doesn't need to be "@gmail.com", but it must be a
> gmail account.
>
> For reference:
> https://support.google.com/a/answer/176600?hl=en
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Nov 17 03:50:38 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Nov 2017 09:50:38 +0100
Subject: [keycloak-dev] Oracle stores an empty string as null
Message-ID: <CAJgngAf4Cw8By0mD4jDeZVEqUAeQsRZ3zrCWQB_JrufvLf8aZw@mail.gmail.com>

If you try to store an empty string in Oracle it is actually stored as a
null [1].

We actually often store empty strings due to the way AngularJS works. An
empty input on a form ends up being sent as an empty string rather than a
null.

This can lead to all sorts of fun issues. For example
https://issues.jboss.org/browse/KEYCLOAK-5308.

[1]
https://stackoverflow.com/questions/13278773/null-vs-empty-string-in-oracle

From sthorger at redhat.com  Fri Nov 17 06:23:16 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Nov 2017 12:23:16 +0100
Subject: [keycloak-dev] Merging PRs
Message-ID: <CAJgngAf788cXLy9yhZYtE_5Wrx=UawZwCUKsRJdNd1ff2sdrwA@mail.gmail.com>

When merging PRs always use the "Rebase and merge" option.

This option puts the commits on the top of the history without a merge
commit.

From mmo at semmle.com  Fri Nov 17 06:54:15 2017
From: mmo at semmle.com (Man Yue Mo)
Date: Fri, 17 Nov 2017 11:54:15 +0000
Subject: [keycloak-dev] Oracle stores an empty string as null
In-Reply-To: <CAJgngAf4Cw8By0mD4jDeZVEqUAeQsRZ3zrCWQB_JrufvLf8aZw@mail.gmail.com>
References: <CAJgngAf4Cw8By0mD4jDeZVEqUAeQsRZ3zrCWQB_JrufvLf8aZw@mail.gmail.com>
Message-ID: <CAOP_0_6BZ9mTNvg9T-ZvRdpRUSPNC3=7eMkzKay3QpUNGmMtcQ@mail.gmail.com>

Hi,

Would there be issue with these also? https://lgtm.com/query/1505886556363/
Thanks.

Man Yue Mo

On 17 November 2017 at 08:50, Stian Thorgersen <sthorger at redhat.com> wrote:

> If you try to store an empty string in Oracle it is actually stored as a
> null [1].
>
> We actually often store empty strings due to the way AngularJS works. An
> empty input on a form ends up being sent as an empty string rather than a
> null.
>
> This can lead to all sorts of fun issues. For example
> https://issues.jboss.org/browse/KEYCLOAK-5308.
>
> [1]
> https://stackoverflow.com/questions/13278773/null-vs-
> empty-string-in-oracle
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Fri Nov 17 07:36:24 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 17 Nov 2017 12:36:24 +0000
Subject: [keycloak-dev] Merging PRs
In-Reply-To: <CAJgngAf788cXLy9yhZYtE_5Wrx=UawZwCUKsRJdNd1ff2sdrwA@mail.gmail.com>
References: <CAJgngAf788cXLy9yhZYtE_5Wrx=UawZwCUKsRJdNd1ff2sdrwA@mail.gmail.com>
Message-ID: <9f1e2c080d3e447f9f4606b9b1f02355@FE-MBX1028.de.bosch.com>

Isn't it normally the other way round? Every developer should update its local branch with a rebase because you don't want to have merge commits when a developer updates its local repository but you definitely want an explicit merge commit when a major feature comes in, i.e. a pull request is merged?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1) 
Bosch?Software Innovations?GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B 
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn 




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Freitag, 17. November 2017 12:23
To: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: [keycloak-dev] Merging PRs

When merging PRs always use the "Rebase and merge" option.

This option puts the commits on the top of the history without a merge commit.
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Fri Nov 17 08:28:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Nov 2017 14:28:35 +0100
Subject: [keycloak-dev] Merging PRs
In-Reply-To: <9f1e2c080d3e447f9f4606b9b1f02355@FE-MBX1028.de.bosch.com>
References: <CAJgngAf788cXLy9yhZYtE_5Wrx=UawZwCUKsRJdNd1ff2sdrwA@mail.gmail.com>
	<9f1e2c080d3e447f9f4606b9b1f02355@FE-MBX1028.de.bosch.com>
Message-ID: <CAJgngAdE8W18mrkSFpQ3ZoJJMRj+-i-biXHvEmd9FnawNjyTjA@mail.gmail.com>

A major new feature is sent as a single commit and should be added to the
top of the Git history. The "rebase and merge" option allows this and
doesn't add any "messy" merge commits.

On 17 November 2017 at 13:36, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Isn't it normally the other way round? Every developer should update its
> local branch with a rebase because you don't want to have merge commits
> when a developer updates its local repository but you definitely want an
> explicit merge commit when a major feature comes in, i.e. a pull request is
> merged?
>
> Best regards,
> Sebastian
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing.  Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Freitag, 17. November 2017 12:23
> To: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: [keycloak-dev] Merging PRs
>
> When merging PRs always use the "Rebase and merge" option.
>
> This option puts the commits on the top of the history without a merge
> commit.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Nov 17 08:30:07 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 17 Nov 2017 14:30:07 +0100
Subject: [keycloak-dev] Oracle stores an empty string as null
In-Reply-To: <CAOP_0_6BZ9mTNvg9T-ZvRdpRUSPNC3=7eMkzKay3QpUNGmMtcQ@mail.gmail.com>
References: <CAJgngAf4Cw8By0mD4jDeZVEqUAeQsRZ3zrCWQB_JrufvLf8aZw@mail.gmail.com>
	<CAOP_0_6BZ9mTNvg9T-ZvRdpRUSPNC3=7eMkzKay3QpUNGmMtcQ@mail.gmail.com>
Message-ID: <CAJgngAfuShSx1f+XyZc2moZMys1mHXX5tYMrOh6cdtkav-sW5g@mail.gmail.com>

Probably yes

On 17 November 2017 at 12:54, Man Yue Mo <mmo at semmle.com> wrote:

> Hi,
>
> Would there be issue with these also? https://lgtm.com/query/
> 1505886556363/ Thanks.
>
> Man Yue Mo
>
> On 17 November 2017 at 08:50, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> If you try to store an empty string in Oracle it is actually stored as a
>> null [1].
>>
>> We actually often store empty strings due to the way AngularJS works. An
>> empty input on a form ends up being sent as an empty string rather than a
>> null.
>>
>> This can lead to all sorts of fun issues. For example
>> https://issues.jboss.org/browse/KEYCLOAK-5308.
>>
>> [1]
>> https://stackoverflow.com/questions/13278773/null-vs-empty-
>> string-in-oracle
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From Sebastian.Schuster at bosch-si.com  Mon Nov 20 02:51:47 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Mon, 20 Nov 2017 07:51:47 +0000
Subject: [keycloak-dev] Merging PRs
In-Reply-To: <CAJgngAdE8W18mrkSFpQ3ZoJJMRj+-i-biXHvEmd9FnawNjyTjA@mail.gmail.com>
References: <CAJgngAf788cXLy9yhZYtE_5Wrx=UawZwCUKsRJdNd1ff2sdrwA@mail.gmail.com>
	<9f1e2c080d3e447f9f4606b9b1f02355@FE-MBX1028.de.bosch.com>
	<CAJgngAdE8W18mrkSFpQ3ZoJJMRj+-i-biXHvEmd9FnawNjyTjA@mail.gmail.com>
Message-ID: <9b1ee9b895214d8fb0eb17f2a95723a9@bosch-si.com>

I had GitFlow in my mind and forgot about the ?a feature is one commit? feature. I kind of liked GitFlow because it makes the development history more explicit and makes reviewing easier assuming there are nice small consistent commits. The latter is unfortunately rarely the case, that?s probably why you picked the single commit strategy?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing. Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn



From: Stian Thorgersen [mailto:sthorger at redhat.com]
Sent: Freitag, 17. November 2017 14:29
To: Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Merging PRs

A major new feature is sent as a single commit and should be added to the top of the Git history. The "rebase and merge" option allows this and doesn't add any "messy" merge commits.

On 17 November 2017 at 13:36, Schuster Sebastian (INST/ESY1) <Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>> wrote:
Isn't it normally the other way round? Every developer should update its local branch with a rebase because you don't want to have merge commits when a developer updates its local repository but you definitely want an explicit merge commit when a major feature comes in, i.e. a pull request is merged?

Best regards,
Sebastian

Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

Engineering and Support (INST/ESY1)
Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com<http://www.bosch-si.com>
Tel. +49 30 726112-485<tel:%2B49%2030%20726112-485> | Fax +49 30 726112-100<tel:%2B49%2030%20726112-100> | Sebastian.Schuster at bosch-si.com<mailto:Sebastian.Schuster at bosch-si.com>

Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr.-Ing. Rainer Kallenbach, Michael Hahn




-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> [mailto:keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org>] On Behalf Of Stian Thorgersen
Sent: Freitag, 17. November 2017 12:23
To: keycloak-dev <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Subject: [keycloak-dev] Merging PRs

When merging PRs always use the "Rebase and merge" option.

This option puts the commits on the top of the history without a merge commit.
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From orivat at janua.fr  Mon Nov 20 16:21:19 2017
From: orivat at janua.fr (Olivier Rivat)
Date: Mon, 20 Nov 2017 22:21:19 +0100
Subject: [keycloak-dev] cannot run keycloak authz examples working correctly
 - unresolved dependency - Cannot find KieModule:
 org.keycloak:photoz-authz-policy:${project.version}
Message-ID: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>

Hi,

I am using RH-SSO 7.1 with Keycloack examples 2.5.X (2.5.11.Final-SNAPSHOT)

I have been able to ciompiel and upload the both photoz war:
-photoz-html5-client.war
-photoz-restful-api.war

1) on UI uinterface
=============

I have an issue when I am running the example.
When click on "Entitlement" or "Delete" I am getting Error 500.

I have screened it, and the reason is that:


angular.min.js:77 GET http://localhost:8080/photoz-restful-api/album 401 
(Unauthorized)

GET 
http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api 
500 (Internal Server Error)
:8080/photoz-html5-client/#/:1 Failed to load 
http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api: 

No 'Access-Control-Allow-Origin' header is present on the requested 
resource. Origin 'http://localhost:8080' is therefore not allowed access.
The response had HTTP status code 500.


2) in logs -of RH-SSO
=============
Meanwhile, I have had also a look at RH-SSO log, and it is displaying:

21:49:22,210 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default 
task-79) RESTEASY002020: Unhandled asynchronous exception, sending back 
500: org.jboss.resteasy.spi.UnhandledException: 
java.lang.RuntimeException: Cannot find KieModule: 
org.keycloak:photoz-authz-policy:${project.version}
 ??? at 
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:255)

3) ${project.version} in photoz examples
========================
it can be foudn at:

3.1) examples/authz/photoz/photoz-restful-api/pom.xml

 ?<dependency>
 ??????????? <groupId>org.keycloak</groupId>
<artifactId>keycloak-authz-client</artifactId>
 ??????????? <version>${project.version}</version>
 ??????????? <scope>provided</scope>
 ??????? </dependency>

3.2) 
examples/authz/photoz/photoz-restful-api/src/main/resources/photoz-restful-api-authz-service.json

"policies": [
 ??? {
 ????? "name": "Only Owner Policy",
 ????? "description": "Defines that only the resource owner is allowed 
to do something",
 ????? "type": "rules",
 ????? "logic": "POSITIVE",
 ????? "decisionStrategy": "UNANIMOUS",
 ????? "config": {
 ??????? "mavenArtifactVersion": "${project.version}",
 ??????? "mavenArtifactId": "photoz-authz-policy",
 ??????? "sessionName": "MainOwnerSession",
 ??????? "mavenArtifactGroupId": "org.keycloak",
 ??????? "moduleName": "PhotozAuthzOwnerPolicy",
 ??????? "scannerPeriod": "1",
 ??????? "scannerPeriodUnit": "Hours"
 ????? }
 ??? },


and for info:

we also have:

examples/authz/photoz/photoz-authz-policy/pom.xml

 ?<parent>
 ??????? <groupId>org.keycloak</groupId>
<artifactId>keycloak-authz-photoz-parent</artifactId>
 ??????? <version>2.5.11.Final-SNAPSHOT</version>
 ??????? <relativePath>../pom.xml</relativePath>
 ??? </parent>



4) My analysis
=========
The error seen in RH-SSO server (Cannot find KieModule: 
org.keycloak:photoz-authz-policy:${project.version}) comes certainly 
from the fact that
${project.version} is not resolved? at all, although being defined in 
pom.xml of examples/authz/photoz/photoz-authz-policy.

It could be great if someone could help to resolve those unresolved 
dependency which are? preventing to run the example successfully.


Regards,

Olivier









From matzew at apache.org  Tue Nov 21 05:34:31 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 21 Nov 2017 11:34:31 +0100
Subject: [keycloak-dev] Prometheus Metrics
Message-ID: <CAAg5f2TrGLQOekLOdZPwW9MKNwdUhhGccpVZqFJu-R2ED5Kpig@mail.gmail.com>

Hi,

is there any plan for providing Prometheus metric endpoint?

Thanks,
Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

From psilva at redhat.com  Tue Nov 21 07:04:30 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 21 Nov 2017 10:04:30 -0200
Subject: [keycloak-dev] cannot run keycloak authz examples working
 correctly - unresolved dependency - Cannot find KieModule:
 org.keycloak:photoz-authz-policy:${project.version}
In-Reply-To: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>
References: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>
Message-ID: <CAJrcDBfND7p2nE7HazyT3fPhvAb-YLZvxj8L6nBHqBR9nmNwUw@mail.gmail.com>

This is probably because you are importing the wrong file with the
authorization settings. When you build the example, there is a filtered
version of at
photoz-restful-api-authz-service.json
photoz/photoz-restful-api/target/classes/photoz-restful-api-authz-service.json.
This is the file you need to import.

README is not correct and I'll fix this.

Btw, please send such questions to keycloak-user mailing list.

Regards.
Pedro Igor

On Mon, Nov 20, 2017 at 7:21 PM, Olivier Rivat <orivat at janua.fr> wrote:

> Hi,
>
> I am using RH-SSO 7.1 with Keycloack examples 2.5.X (2.5.11.Final-SNAPSHOT)
>
> I have been able to ciompiel and upload the both photoz war:
> -photoz-html5-client.war
> -photoz-restful-api.war
>
> 1) on UI uinterface
> =============
>
> I have an issue when I am running the example.
> When click on "Entitlement" or "Delete" I am getting Error 500.
>
> I have screened it, and the reason is that:
>
>
> angular.min.js:77 GET http://localhost:8080/photoz-restful-api/album 401
> (Unauthorized)
>
> GET
> http://localhost:8180/auth/realms/photoz/authz/
> entitlement/photoz-restful-api
> 500 (Internal Server Error)
> :8080/photoz-html5-client/#/:1 Failed to load
> http://localhost:8180/auth/realms/photoz/authz/
> entitlement/photoz-restful-api:
>
> No 'Access-Control-Allow-Origin' header is present on the requested
> resource. Origin 'http://localhost:8080' is therefore not allowed access.
> The response had HTTP status code 500.
>
>
> 2) in logs -of RH-SSO
> =============
> Meanwhile, I have had also a look at RH-SSO log, and it is displaying:
>
> 21:49:22,210 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
> task-79) RESTEASY002020: Unhandled asynchronous exception, sending back
> 500: org.jboss.resteasy.spi.UnhandledException:
> java.lang.RuntimeException: Cannot find KieModule:
> org.keycloak:photoz-authz-policy:${project.version}
>      at
> org.jboss.resteasy.core.ExceptionHandler.handleException(
> ExceptionHandler.java:255)
>
> 3) ${project.version} in photoz examples
> ========================
> it can be foudn at:
>
> 3.1) examples/authz/photoz/photoz-restful-api/pom.xml
>
>   <dependency>
>              <groupId>org.keycloak</groupId>
> <artifactId>keycloak-authz-client</artifactId>
>              <version>${project.version}</version>
>              <scope>provided</scope>
>          </dependency>
>
> 3.2)
> examples/authz/photoz/photoz-restful-api/src/main/
> resources/photoz-restful-api-authz-service.json
>
> "policies": [
>      {
>        "name": "Only Owner Policy",
>        "description": "Defines that only the resource owner is allowed
> to do something",
>        "type": "rules",
>        "logic": "POSITIVE",
>        "decisionStrategy": "UNANIMOUS",
>        "config": {
>          "mavenArtifactVersion": "${project.version}",
>          "mavenArtifactId": "photoz-authz-policy",
>          "sessionName": "MainOwnerSession",
>          "mavenArtifactGroupId": "org.keycloak",
>          "moduleName": "PhotozAuthzOwnerPolicy",
>          "scannerPeriod": "1",
>          "scannerPeriodUnit": "Hours"
>        }
>      },
>
>
> and for info:
>
> we also have:
>
> examples/authz/photoz/photoz-authz-policy/pom.xml
>
>   <parent>
>          <groupId>org.keycloak</groupId>
> <artifactId>keycloak-authz-photoz-parent</artifactId>
>          <version>2.5.11.Final-SNAPSHOT</version>
>          <relativePath>../pom.xml</relativePath>
>      </parent>
>
>
>
> 4) My analysis
> =========
> The error seen in RH-SSO server (Cannot find KieModule:
> org.keycloak:photoz-authz-policy:${project.version}) comes certainly
> from the fact that
> ${project.version} is not resolved  at all, although being defined in
> pom.xml of examples/authz/photoz/photoz-authz-policy.
>
> It could be great if someone could help to resolve those unresolved
> dependency which are  preventing to run the example successfully.
>
>
> Regards,
>
> Olivier
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From thomas.darimont at googlemail.com  Tue Nov 21 07:36:13 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 21 Nov 2017 13:36:13 +0100
Subject: [keycloak-dev] Prometheus Metrics
In-Reply-To: <CAAg5f2TrGLQOekLOdZPwW9MKNwdUhhGccpVZqFJu-R2ED5Kpig@mail.gmail.com>
References: <CAAg5f2TrGLQOekLOdZPwW9MKNwdUhhGccpVZqFJu-R2ED5Kpig@mail.gmail.com>
Message-ID: <CAK-7U1jASqccYdmKSar4evheUTLdCECXeKGmibmuSgemfaX23A@mail.gmail.com>

Hello,

would be great to have better monitoring and metrics collection support in
Keycloak.

There is also a JIRA Issue to track this:
https://issues.jboss.org/browse/KEYCLOAK-1578

There is a small extension (custom EventListener) which allows to monitor
Keycloak with prometheus:
https://github.com/larscheid-schmitzhermes/keycloak-monitoring-prometheus

Cheers,
Thomas

2017-11-21 11:34 GMT+01:00 Matthias Wessendorf <matzew at apache.org>:

> Hi,
>
> is there any plan for providing Prometheus metric endpoint?
>
> Thanks,
> Matthias
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Tue Nov 21 10:12:23 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 21 Nov 2017 15:12:23 +0000
Subject: [keycloak-dev] X509 authentication - auto submit countdown
Message-ID: <CAM5SUC49DoTZm0E0bn5c2eEKUOuFSSp9FLpCo+r=xjPdxf8L_A@mail.gmail.com>

Good morning,

I would like to remove this from X509 login page
https://github.com/keycloak/keycloak/blob/9083e5fe5cb5ba6b63042f759c74984e1d1a1a76/themes/src/main/resources/theme/base/login/login-x509-info.ftl#L59-L70.
Do we have a strong motivation to keep it?

Today we do not provide anything close to this to other login pages and I
don't see why X509 authentication should behave different. Thoughts?

From orivat at janua.fr  Tue Nov 21 11:06:04 2017
From: orivat at janua.fr (Olivier Rivat)
Date: Tue, 21 Nov 2017 17:06:04 +0100
Subject: [keycloak-dev] cannot run keycloak authz examples working
 correctly - unresolved dependency - Cannot find KieModule:
 org.keycloak:photoz-authz-policy:${project.version}
In-Reply-To: <CAJrcDBfND7p2nE7HazyT3fPhvAb-YLZvxj8L6nBHqBR9nmNwUw@mail.gmail.com>
References: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>
	<CAJrcDBfND7p2nE7HazyT3fPhvAb-YLZvxj8L6nBHqBR9nmNwUw@mail.gmail.com>
Message-ID: <734554cc-f84e-b350-a596-a8cfc520dde5@janua.fr>

Hi Pedro,

Tkx a lot for your help.

With your comment/tip, it is working fine: I can now succesfuly delete 
albums, and access to the link "Request entitlement", without any failure.

Some comments for improvments of this example:

1) when you click on my profile, there is no way to get to the original 
panel (Welcome Screen)
I Have found the way to doing it, by cliking in the browser window to: 
http://localhost:8080/photoz-html5-client/#

2) When Clicking on the link "Request Entitlement", now it works (I.e 
there is no error in debugging window, compared as before)
But there is nothing displayed on the login screen.

It could be nice to add some information, such as the user entittlements.

Regards,
Olivier


Le 21/11/2017 ? 13:04, Pedro Igor Silva a ?crit?:
> This is probably because you are importing the wrong file with the 
> authorization settings. When you build the example, there is a 
> filtered version of at 
> photoz-restful-api-authz-service.json?photoz/photoz-restful-api/target/classes/photoz-restful-api-authz-service.json. 
> This is the file you need to import.
>
> README is not correct and I'll fix this.
>
> Btw, please send such questions to keycloak-user mailing list.
>
> Regards.
> Pedro Igor
>
> On Mon, Nov 20, 2017 at 7:21 PM, Olivier Rivat <orivat at janua.fr 
> <mailto:orivat at janua.fr>> wrote:
>
>     Hi,
>
>     I am using RH-SSO 7.1 with Keycloack examples 2.5.X
>     (2.5.11.Final-SNAPSHOT)
>
>     I have been able to ciompiel and upload the both photoz war:
>     -photoz-html5-client.war
>     -photoz-restful-api.war
>
>     1) on UI uinterface
>     =============
>
>     I have an issue when I am running the example.
>     When click on "Entitlement" or "Delete" I am getting Error 500.
>
>     I have screened it, and the reason is that:
>
>
>     angular.min.js:77 GET
>     http://localhost:8080/photoz-restful-api/album
>     <http://localhost:8080/photoz-restful-api/album> 401
>     (Unauthorized)
>
>     GET
>     http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api
>     <http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api>
>     500 (Internal Server Error)
>     :8080/photoz-html5-client/#/:1 Failed to load
>     http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api
>     <http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api>:
>
>     No 'Access-Control-Allow-Origin' header is present on the requested
>     resource. Origin 'http://localhost:8080' is therefore not allowed
>     access.
>     The response had HTTP status code 500.
>
>
>     2) in logs -of RH-SSO
>     =============
>     Meanwhile, I have had also a look at RH-SSO log, and it is displaying:
>
>     21:49:22,210 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>     task-79) RESTEASY002020: Unhandled asynchronous exception, sending
>     back
>     500: org.jboss.resteasy.spi.UnhandledException:
>     java.lang.RuntimeException: Cannot find KieModule:
>     org.keycloak:photoz-authz-policy:${project.version}
>     ???? at
>     org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:255)
>
>     3) ${project.version} in photoz examples
>     ========================
>     it can be foudn at:
>
>     3.1) examples/authz/photoz/photoz-restful-api/pom.xml
>
>     ??<dependency>
>     ???????????? <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-authz-client</artifactId>
>     ???????????? <version>${project.version}</version>
>     ???????????? <scope>provided</scope>
>     ???????? </dependency>
>
>     3.2)
>     examples/authz/photoz/photoz-restful-api/src/main/resources/photoz-restful-api-authz-service.json
>
>     "policies": [
>     ???? {
>     ?????? "name": "Only Owner Policy",
>     ?????? "description": "Defines that only the resource owner is allowed
>     to do something",
>     ?????? "type": "rules",
>     ?????? "logic": "POSITIVE",
>     ?????? "decisionStrategy": "UNANIMOUS",
>     ?????? "config": {
>     ???????? "mavenArtifactVersion": "${project.version}",
>     ???????? "mavenArtifactId": "photoz-authz-policy",
>     ???????? "sessionName": "MainOwnerSession",
>     ???????? "mavenArtifactGroupId": "org.keycloak",
>     ???????? "moduleName": "PhotozAuthzOwnerPolicy",
>     ???????? "scannerPeriod": "1",
>     ???????? "scannerPeriodUnit": "Hours"
>     ?????? }
>     ???? },
>
>
>     and for info:
>
>     we also have:
>
>     examples/authz/photoz/photoz-authz-policy/pom.xml
>
>     ??<parent>
>     ???????? <groupId>org.keycloak</groupId>
>     <artifactId>keycloak-authz-photoz-parent</artifactId>
>     ???????? <version>2.5.11.Final-SNAPSHOT</version>
>     ???????? <relativePath>../pom.xml</relativePath>
>     ???? </parent>
>
>
>
>     4) My analysis
>     =========
>     The error seen in RH-SSO server (Cannot find KieModule:
>     org.keycloak:photoz-authz-policy:${project.version}) comes certainly
>     from the fact that
>     ${project.version} is not resolved? at all, although being defined in
>     pom.xml of examples/authz/photoz/photoz-authz-policy.
>
>     It could be great if someone could help to resolve those unresolved
>     dependency which are? preventing to run the example successfully.
>
>
>     Regards,
>
>     Olivier
>
>
>
>
>
>
>
>
>     _______________________________________________
>     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 pnalyvayko at agi.com  Tue Nov 21 11:09:49 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Tue, 21 Nov 2017 16:09:49 +0000
Subject: [keycloak-dev] X509 authentication - auto submit countdown
In-Reply-To: <CAM5SUC49DoTZm0E0bn5c2eEKUOuFSSp9FLpCo+r=xjPdxf8L_A@mail.gmail.com>
References: <CAM5SUC49DoTZm0E0bn5c2eEKUOuFSSp9FLpCo+r=xjPdxf8L_A@mail.gmail.com>
Message-ID: <CY1PR0701MB16945659BB4D131B857E1A18DA230@CY1PR0701MB1694.namprd07.prod.outlook.com>

+1
________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Bruno Oliveira [bruno at abstractj.org]
Sent: Tuesday, November 21, 2017 10:12 AM
To: keycloak-dev
Subject: [keycloak-dev] X509 authentication - auto submit countdown

Good morning,

I would like to remove this from X509 login page
https://github.com/keycloak/keycloak/blob/9083e5fe5cb5ba6b63042f759c74984e1d1a1a76/themes/src/main/resources/theme/base/login/login-x509-info.ftl#L59-L70.
Do we have a strong motivation to keep it?

Today we do not provide anything close to this to other login pages and I
don't see why X509 authentication should behave different. Thoughts?
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Nov 21 17:51:40 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Nov 2017 17:51:40 -0500
Subject: [keycloak-dev] thoughts on file migration?
In-Reply-To: <c19be06d-48cd-d046-b149-ab9b46608b7f@redhat.com>
References: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>
	<c19be06d-48cd-d046-b149-ab9b46608b7f@redhat.com>
Message-ID: <CABRXCmw7BJfJ015t4urGck39o1R475EGfE5--xO-cvzz7e87sA@mail.gmail.com>

I added a method to Migration interface.  Migration.migrateImport()
that takes a RealmModel as a parameter.

Also added a static method to MigrationModelManager.migrateImport().
This method is called if a RealmRepresentation has "keycloakVersion"
set.  It loops through all migrators and calls migrateImport passing
in the realm.  New migrations must implement this.

There's new test classes for this under the migration/ directory.  PR incoming.

On Fri, Oct 27, 2017 at 5:48 AM, Marek Posolda <mposolda at redhat.com> wrote:
> We have version already. It's "keycloakVersion" property on
> RealmRepresentation and it's added during export. This was added in
> 1.9.2.Final, so all the realm JSON exported in 1.9.2 or later will have that
> available . See https://issues.jboss.org/browse/KEYCLOAK-2613 .
>
> But it's not used anywhere until now. The problem are hand-written JSON
> files, which don't contain the "keycloakVersion" and they also don't contain
> required built-in objects. So we're usually trying to decide what built-in
> objects should be automatically added/updated during import on some
> best-effort basis, which sometimes doesn't work (especially if new role was
> added to some existing built-in client etc) .
>
> Maybe we can:
> - Decide if JSON was hand-written based on the "keycloakVersion" present or
> not.
> - For hand-written JSON, add the built-in objects automatically
> - For exported JSON, use the proper migrators. We know the version, so we
> know what migrators to run.
>
> Is it what you meant?
>
> Marek
>
>
> On 26/10/17 23:07, Bill Burke wrote:
>>
>> Need input on this JIRA:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-4715
>>
>> The problem is that our json exports do not have a version assigned to
>> them and we may have  org.keycloak.migration.migrators.Migration
>> objects that need to run.
>>
>> Should we force people doing upgrades in this way to add a version tag
>> somewhere in the json?  We should then add a "fromJson" MIgration
>> method to be invoked for each appropriate migrator.
>>
>> That sound like a plan?
>>
>



-- 
Bill Burke
Red Hat

From psilva at redhat.com  Wed Nov 22 06:24:49 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 22 Nov 2017 09:24:49 -0200
Subject: [keycloak-dev] cannot run keycloak authz examples working
 correctly - unresolved dependency - Cannot find KieModule:
 org.keycloak:photoz-authz-policy:${project.version}
In-Reply-To: <734554cc-f84e-b350-a596-a8cfc520dde5@janua.fr>
References: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>
	<CAJrcDBfND7p2nE7HazyT3fPhvAb-YLZvxj8L6nBHqBR9nmNwUw@mail.gmail.com>
	<734554cc-f84e-b350-a596-a8cfc520dde5@janua.fr>
Message-ID: <CAJrcDBfxqLm_ufbL4_U6bMiVeOwDX8ybU7O-J0hE1w1VkfEErA@mail.gmail.com>

Thanks, Olivier. I've created https://issues.jboss.org/browse/KEYCLOAK-5886.
Please, let me know if you have any other improvements we can do to make
life easier :)

On Tue, Nov 21, 2017 at 2:06 PM, Olivier Rivat <orivat at janua.fr> wrote:

> Hi Pedro,
>
> Tkx a lot for your help.
> With your comment/tip, it is working fine: I can now succesfuly delete
> albums, and access to the link "Request entitlement", without any failure.
>
> Some comments for improvments of this example:
>
> 1) when you click on my profile, there is no way to get to the original
> panel (Welcome Screen)
> I Have found the way to doing it, by cliking in the browser window to:
> http://localhost:8080/photoz-html5-client/#
>
> 2) When Clicking on the link "Request Entitlement", now it works (I.e
> there is no error in debugging window, compared as before)
> But there is nothing displayed on the login screen.
>
> It could be nice to add some information, such as the user entittlements.
>
> Regards,
> Olivier
>
>
>
> Le 21/11/2017 ? 13:04, Pedro Igor Silva a ?crit :
>
> This is probably because you are importing the wrong file with the
> authorization settings. When you build the example, there is a filtered
> version of at photoz-restful-api-authz-service.json photoz/photoz-
> restful-api/target/classes/photoz-restful-api-authz-service.json. This is
> the file you need to import.
>
> README is not correct and I'll fix this.
>
> Btw, please send such questions to keycloak-user mailing list.
>
> Regards.
> Pedro Igor
>
> On Mon, Nov 20, 2017 at 7:21 PM, Olivier Rivat <orivat at janua.fr> wrote:
>
>> Hi,
>>
>> I am using RH-SSO 7.1 with Keycloack examples 2.5.X
>> (2.5.11.Final-SNAPSHOT)
>>
>> I have been able to ciompiel and upload the both photoz war:
>> -photoz-html5-client.war
>> -photoz-restful-api.war
>>
>> 1) on UI uinterface
>> =============
>>
>> I have an issue when I am running the example.
>> When click on "Entitlement" or "Delete" I am getting Error 500.
>>
>> I have screened it, and the reason is that:
>>
>>
>> angular.min.js:77 GET http://localhost:8080/photoz-restful-api/album 401
>> (Unauthorized)
>>
>> GET
>> http://localhost:8180/auth/realms/photoz/authz/entitlement/
>> photoz-restful-api
>> 500 (Internal Server Error)
>> :8080/photoz-html5-client/#/:1 Failed to load
>> http://localhost:8180/auth/realms/photoz/authz/entitlement/
>> photoz-restful-api:
>>
>> No 'Access-Control-Allow-Origin' header is present on the requested
>> resource. Origin 'http://localhost:8080' is therefore not allowed access.
>> The response had HTTP status code 500.
>>
>>
>> 2) in logs -of RH-SSO
>> =============
>> Meanwhile, I have had also a look at RH-SSO log, and it is displaying:
>>
>> 21:49:22,210 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default
>> task-79) RESTEASY002020: Unhandled asynchronous exception, sending back
>> 500: org.jboss.resteasy.spi.UnhandledException:
>> java.lang.RuntimeException: Cannot find KieModule:
>> org.keycloak:photoz-authz-policy:${project.version}
>>      at
>> org.jboss.resteasy.core.ExceptionHandler.handleException(Exc
>> eptionHandler.java:255)
>>
>> 3) ${project.version} in photoz examples
>> ========================
>> it can be foudn at:
>>
>> 3.1) examples/authz/photoz/photoz-restful-api/pom.xml
>>
>>   <dependency>
>>              <groupId>org.keycloak</groupId>
>> <artifactId>keycloak-authz-client</artifactId>
>>              <version>${project.version}</version>
>>              <scope>provided</scope>
>>          </dependency>
>>
>> 3.2)
>> examples/authz/photoz/photoz-restful-api/src/main/resources/
>> photoz-restful-api-authz-service.json
>>
>> "policies": [
>>      {
>>        "name": "Only Owner Policy",
>>        "description": "Defines that only the resource owner is allowed
>> to do something",
>>        "type": "rules",
>>        "logic": "POSITIVE",
>>        "decisionStrategy": "UNANIMOUS",
>>        "config": {
>>          "mavenArtifactVersion": "${project.version}",
>>          "mavenArtifactId": "photoz-authz-policy",
>>          "sessionName": "MainOwnerSession",
>>          "mavenArtifactGroupId": "org.keycloak",
>>          "moduleName": "PhotozAuthzOwnerPolicy",
>>          "scannerPeriod": "1",
>>          "scannerPeriodUnit": "Hours"
>>        }
>>      },
>>
>>
>> and for info:
>>
>> we also have:
>>
>> examples/authz/photoz/photoz-authz-policy/pom.xml
>>
>>   <parent>
>>          <groupId>org.keycloak</groupId>
>> <artifactId>keycloak-authz-photoz-parent</artifactId>
>>          <version>2.5.11.Final-SNAPSHOT</version>
>>          <relativePath>../pom.xml</relativePath>
>>      </parent>
>>
>>
>>
>> 4) My analysis
>> =========
>> The error seen in RH-SSO server (Cannot find KieModule:
>> org.keycloak:photoz-authz-policy:${project.version}) comes certainly
>> from the fact that
>> ${project.version} is not resolved  at all, although being defined in
>> pom.xml of examples/authz/photoz/photoz-authz-policy.
>>
>> It could be great if someone could help to resolve those unresolved
>> dependency which are  preventing to run the example successfully.
>>
>>
>> Regards,
>>
>> Olivier
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>

From orivat at janua.fr  Wed Nov 22 07:47:21 2017
From: orivat at janua.fr (Olivier Rivat)
Date: Wed, 22 Nov 2017 13:47:21 +0100
Subject: [keycloak-dev] cannot run keycloak authz examples working
 correctly - unresolved dependency - Cannot find KieModule:
 org.keycloak:photoz-authz-policy:${project.version}
In-Reply-To: <CAJrcDBfxqLm_ufbL4_U6bMiVeOwDX8ybU7O-J0hE1w1VkfEErA@mail.gmail.com>
References: <1f06e431-919e-f3d6-91b2-c44a8877268b@janua.fr>
	<CAJrcDBfND7p2nE7HazyT3fPhvAb-YLZvxj8L6nBHqBR9nmNwUw@mail.gmail.com>
	<734554cc-f84e-b350-a596-a8cfc520dde5@janua.fr>
	<CAJrcDBfxqLm_ufbL4_U6bMiVeOwDX8ybU7O-J0hE1w1VkfEErA@mail.gmail.com>
Message-ID: <522190cb-d88e-8842-4b32-0c546bf0fe5e@janua.fr>

Hi,

Sounds good to me.

Regards,

Olivier



Le 22/11/2017 ? 12:24, Pedro Igor Silva a ?crit?:
> Thanks, Olivier. I've created 
> https://issues.jboss.org/browse/KEYCLOAK-5886. Please, let me know if 
> you have any other improvements we can do to make life easier :)
>
> On Tue, Nov 21, 2017 at 2:06 PM, Olivier Rivat <orivat at janua.fr 
> <mailto:orivat at janua.fr>> wrote:
>
>     Hi Pedro,
>
>     Tkx a lot for your help.
>
>     With your comment/tip, it is working fine: I can now succesfuly
>     delete albums, and access to the link "Request entitlement",
>     without any failure.
>
>     Some comments for improvments of this example:
>
>     1) when you click on my profile, there is no way to get to the
>     original panel (Welcome Screen)
>     I Have found the way to doing it, by cliking in the browser window
>     to: http://localhost:8080/photoz-html5-client/#
>     <http://localhost:8080/photoz-html5-client/#>
>
>     2) When Clicking on the link "Request Entitlement", now it works
>     (I.e there is no error in debugging window, compared as before)
>     But there is nothing displayed on the login screen.
>
>     It could be nice to add some information, such as the user
>     entittlements.
>
>     Regards,
>     Olivier
>
>
>
>     Le 21/11/2017 ? 13:04, Pedro Igor Silva a ?crit?:
>>     This is probably because you are importing the wrong file with
>>     the authorization settings. When you build the example, there is
>>     a filtered version of at
>>     photoz-restful-api-authz-service.json?photoz/photoz-restful-api/target/classes/photoz-restful-api-authz-service.json.
>>     This is the file you need to import.
>>
>>     README is not correct and I'll fix this.
>>
>>     Btw, please send such questions to keycloak-user mailing list.
>>
>>     Regards.
>>     Pedro Igor
>>
>>     On Mon, Nov 20, 2017 at 7:21 PM, Olivier Rivat <orivat at janua.fr
>>     <mailto:orivat at janua.fr>> wrote:
>>
>>         Hi,
>>
>>         I am using RH-SSO 7.1 with Keycloack examples 2.5.X
>>         (2.5.11.Final-SNAPSHOT)
>>
>>         I have been able to ciompiel and upload the both photoz war:
>>         -photoz-html5-client.war
>>         -photoz-restful-api.war
>>
>>         1) on UI uinterface
>>         =============
>>
>>         I have an issue when I am running the example.
>>         When click on "Entitlement" or "Delete" I am getting Error 500.
>>
>>         I have screened it, and the reason is that:
>>
>>
>>         angular.min.js:77 GET
>>         http://localhost:8080/photoz-restful-api/album
>>         <http://localhost:8080/photoz-restful-api/album> 401
>>         (Unauthorized)
>>
>>         GET
>>         http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api
>>         <http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api>
>>         500 (Internal Server Error)
>>         :8080/photoz-html5-client/#/:1 Failed to load
>>         http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api
>>         <http://localhost:8180/auth/realms/photoz/authz/entitlement/photoz-restful-api>:
>>
>>         No 'Access-Control-Allow-Origin' header is present on the
>>         requested
>>         resource. Origin 'http://localhost:8080' is therefore not
>>         allowed access.
>>         The response had HTTP status code 500.
>>
>>
>>         2) in logs -of RH-SSO
>>         =============
>>         Meanwhile, I have had also a look at RH-SSO log, and it is
>>         displaying:
>>
>>         21:49:22,210 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n]
>>         (default
>>         task-79) RESTEASY002020: Unhandled asynchronous exception,
>>         sending back
>>         500: org.jboss.resteasy.spi.UnhandledException:
>>         java.lang.RuntimeException: Cannot find KieModule:
>>         org.keycloak:photoz-authz-policy:${project.version}
>>         ???? at
>>         org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:255)
>>
>>         3) ${project.version} in photoz examples
>>         ========================
>>         it can be foudn at:
>>
>>         3.1) examples/authz/photoz/photoz-restful-api/pom.xml
>>
>>         ??<dependency>
>>         <groupId>org.keycloak</groupId>
>>         <artifactId>keycloak-authz-client</artifactId>
>>         <version>${project.version}</version>
>>         <scope>provided</scope>
>>         ???????? </dependency>
>>
>>         3.2)
>>         examples/authz/photoz/photoz-restful-api/src/main/resources/photoz-restful-api-authz-service.json
>>
>>         "policies": [
>>         ???? {
>>         ?????? "name": "Only Owner Policy",
>>         ?????? "description": "Defines that only the resource owner
>>         is allowed
>>         to do something",
>>         ?????? "type": "rules",
>>         ?????? "logic": "POSITIVE",
>>         ?????? "decisionStrategy": "UNANIMOUS",
>>         ?????? "config": {
>>         ???????? "mavenArtifactVersion": "${project.version}",
>>         ???????? "mavenArtifactId": "photoz-authz-policy",
>>         ???????? "sessionName": "MainOwnerSession",
>>         ???????? "mavenArtifactGroupId": "org.keycloak",
>>         ???????? "moduleName": "PhotozAuthzOwnerPolicy",
>>         ???????? "scannerPeriod": "1",
>>         ???????? "scannerPeriodUnit": "Hours"
>>         ?????? }
>>         ???? },
>>
>>
>>         and for info:
>>
>>         we also have:
>>
>>         examples/authz/photoz/photoz-authz-policy/pom.xml
>>
>>         ??<parent>
>>         <groupId>org.keycloak</groupId>
>>         <artifactId>keycloak-authz-photoz-parent</artifactId>
>>         ???????? <version>2.5.11.Final-SNAPSHOT</version>
>>         <relativePath>../pom.xml</relativePath>
>>         ???? </parent>
>>
>>
>>
>>         4) My analysis
>>         =========
>>         The error seen in RH-SSO server (Cannot find KieModule:
>>         org.keycloak:photoz-authz-policy:${project.version}) comes
>>         certainly
>>         from the fact that
>>         ${project.version} is not resolved? at all, although being
>>         defined in
>>         pom.xml of examples/authz/photoz/photoz-authz-policy.
>>
>>         It could be great if someone could help to resolve those
>>         unresolved
>>         dependency which are? preventing to run the example successfully.
>>
>>
>>         Regards,
>>
>>         Olivier
>>
>>
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         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 mitya at cargosoft.ru  Wed Nov 22 08:43:43 2017
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Wed, 22 Nov 2017 16:43:43 +0300
Subject: [keycloak-dev] ProviderFactory::postDeploy?
In-Reply-To: <d33fbdae-45d8-ff6c-5311-f6d8e25b6138@redhat.com>
References: <1499098603.12833.2.camel@cargosoft.ru>
	<5cfc01b9-cb8c-9fc8-93fe-1d9b545861d9@redhat.com>
	<d33fbdae-45d8-ff6c-5311-f6d8e25b6138@redhat.com>
Message-ID: <1511358223.2109.1.camel@cargosoft.ru>

Hi Marek and all,

It's been a while but I didn't want an important topic to be abandoned.

The proposed "lazyInit" approach might be useful per se, but it is
somewhat orthogonal to the original problem, let me explain that.

Matter is, providers might need to execute some post-init code to
access data model, but this should be done differently depending on the
deployment mode:

- if "cold" deployed (i.e. postInit invoked at server startup), we
should listen for PostMigrationEvent and don't wrap the code in a
transaction (it will be active already);
- if hot (re)deployed, do everything in the current thread, but wrap it
in a transaction.

The problem is how to distinguish the two above cases. At the moment,
there are some hackish methods like testing for presence/absence of
JNDI, analyzing current thread name, classloader implementation etc.,
but what I wanted was some standard, reliable mechanism.

Why wouldn't lazyInit be helpful here? Simply because it would happen
at different moments in time for different provider types. For
EntityProviders, first create() call to the factory occurs *before*
realm migration, that means too early. For RealmResourceProviders, it
happens before first actual REST invocation, and for many use cases
that would be too late.

To sum up, we still need a portable and determinate mechanism for
provider post-init. Could it be some callback that would be guaranteed
to:
- be called upon PostMigrationEvent on cold deploy;
- be called immediately upon hot (re)deploy;
- provide equal transactional semantics for both cases?

What do you think?

Thanks,
Dmitry

? Tue, 04/07/2017 ? 09:26 +0200, Marek Posolda ?????:
> As Dmitri mentioned, the problem is that "postInit" is called before?
> model is fully initialized (eg. before migration), so it's not
> really?
> safe to access DB from there.
> 
> The bit related issue is, if we can add better support for the?
> "lazyInit" pattern into provider framework instead of make the
> providers?
> to care about the synchronization etc? We can possibly add the
> interface?
> like LazyInitializationProvider with single "lazyInit" method? If?
> provider implements it, the framework will ensure that the method is?
> called just once at the time when provider creation is requested for
> the?
> first time.
> 
> Marek
> 
> On 03/07/17 22:19, Bill Burke wrote:
> > Please see my response to your original problem.
> > 
> > 
> > On 7/3/17 12:16 PM, Dmitry wrote:
> > > Hi,
> > > 
> > > At the moment, the ProviderFactory::postInit() method is not
> > > called
> > > during hot (re)deployment of providers, only during server
> > > startup.
> > > This is considered a bug (see discussion in keycloak-user,
> > > KEYCLOAK-
> > > 5131 and PR #4282).
> > > 
> > > Meanwhile, Marek and I have been discussing the problem of
> > > accessing
> > > data model from postInit (see the keycloak-user post). Turns out
> > > that
> > > the semantics should be significantly different depending on
> > > whether
> > > postInit() is called during server startup or hot deploy. In the
> > > first
> > > case, one should listen for PostMigrationEvent. In the second
> > > case, the
> > > event is not available and thus shouldn't be listened for.
> > > However, the
> > > provider should be able to somehow distinguish the cases. There
> > > are
> > > some hacks like analyzing current thread name, querying JNDI or
> > > Resteasy, but maybe we can come up with something more clean and
> > > simple?
> > > 
> > > Marek has suggested that the new method should be introduced on
> > > the
> > > ProviderFactory interface, with empty default implementation (in
> > > order
> > > not to break the code). What do you think?
> > > 
> > > Dmitry
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bruno at abstractj.org  Thu Nov 23 06:15:35 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Nov 2017 09:15:35 -0200
Subject: [keycloak-dev] Alternative flows on Browser refresh
Message-ID: <20171123111535.GA16569@abstractj.org>

Good morning,

For alternative flows like X509 browser, if something goes wrong 
it will fall back to username/password form, as we already know. 
But the flow is not executed again until the browser is closed.

Based on what Stian commented[1], seems like the same applies to
Kerberos. To fix this, we need to change the way how it works today, 
by going through the list of all alternative flows on refresh, 
executing them again.

Does it make sense? Should we have Jira as "enhancement" for this?

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

-- 

abstractj

From bruno at abstractj.org  Thu Nov 23 16:52:16 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 23 Nov 2017 21:52:16 +0000
Subject: [keycloak-dev] Scripts to generate X.509 certificates
Message-ID: <CAM5SUC6=uo7ZLkMqwJctRw2HmwhEbRGS7LU0E1jK6=WQwaN20g@mail.gmail.com>

Ahoy,

I'm adding X509 authentication tests for *Key Usage* and *Extended Key
Usage*. Now I got stuck looking for the scripts that generate these files
https://github.com/keycloak/keycloak/tree/b2f10359c8c33dd0a843c3ee28e0c8ecf275e834/testsuite/integration-arquillian/servers/auth-server/jboss/common/keystore.
Do we have them?

The reason why I'm asking, is because I need to flag *Extended Key Usage*
as critical for testing purposes. Also, I couldn't find the CA key, to sign
another client certificate.

Of course is possible to recreate everything from scratch, but that would
take a considerable time making sure that everything is in the right place.

From mposolda at redhat.com  Fri Nov 24 09:03:39 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Nov 2017 15:03:39 +0100
Subject: [keycloak-dev] Alternative flows on Browser refresh
In-Reply-To: <20171123111535.GA16569@abstractj.org>
References: <20171123111535.GA16569@abstractj.org>
Message-ID: <2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>

I am not sure when exactly we want to retry the alternative 
authenticators like kerberos or X509? The possibilities are:

1) When user opens the secured application URL (which will redirect him 
to Keycloak initial OIDC/SAML Authorization endpoint)
2) When user press browser "refresh" on username/password screen
3) When user press browser "refresh" on TOTP (or any possible additional 
authenticator screen after username/password was already SUCCESS)

I wouldn't do 3. It would be likely complicated to implement when 
thinking various corner cases (browser back/refresh/forward buttons, 
authenticator state etc). And usability also won't help much IMO...

1 will be easier to implement. Is it sufficient or do we want also 2? 
The 2 is possible but maybe harder to do, we will need to track whether 
there was some successful action OR whether some authenticator is 
already in state SUCCESS.

Marek


Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
> Good morning,
>
> For alternative flows like X509 browser, if something goes wrong
> it will fall back to username/password form, as we already know.
> But the flow is not executed again until the browser is closed.
>
> Based on what Stian commented[1], seems like the same applies to
> Kerberos. To fix this, we need to change the way how it works today,
> by going through the list of all alternative flows on refresh,
> executing them again.
>
> Does it make sense? Should we have Jira as "enhancement" for this?
>
> [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
>


From mposolda at redhat.com  Fri Nov 24 09:10:04 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Nov 2017 15:10:04 +0100
Subject: [keycloak-dev] Alternative flows on Browser refresh
In-Reply-To: <2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
References: <20171123111535.GA16569@abstractj.org>
	<2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
Message-ID: <50d22e3b-4bcc-7b33-3a0d-719f6c0a5888@redhat.com>

Bruno, did you already started on 
https://issues.jboss.org/browse/KEYCLOAK-5466 ? I have one related issue 
https://issues.jboss.org/browse/KEYCLOAK-5797, which I plan to look at 
next week. I afraid it clashes a bit with the stuff related to 
https://issues.jboss.org/browse/KEYCLOAK-5466 . Especially since I think 
that some changes may be needed in AuthorizationEndpointBase. Do you 
mind to re-assign KEYCLOAK-5466 to me as well? I am pretty sure that I 
will at least address (1) during the 
https://issues.jboss.org/browse/KEYCLOAK-5797 .

Marek


Dne 24.11.2017 v 15:03 Marek Posolda napsal(a):
> I am not sure when exactly we want to retry the alternative 
> authenticators like kerberos or X509? The possibilities are:
>
> 1) When user opens the secured application URL (which will redirect 
> him to Keycloak initial OIDC/SAML Authorization endpoint)
> 2) When user press browser "refresh" on username/password screen
> 3) When user press browser "refresh" on TOTP (or any possible 
> additional authenticator screen after username/password was already 
> SUCCESS)
>
> I wouldn't do 3. It would be likely complicated to implement when 
> thinking various corner cases (browser back/refresh/forward buttons, 
> authenticator state etc). And usability also won't help much IMO...
>
> 1 will be easier to implement. Is it sufficient or do we want also 2? 
> The 2 is possible but maybe harder to do, we will need to track 
> whether there was some successful action OR whether some authenticator 
> is already in state SUCCESS.
>
> Marek
>
>
> Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
>> Good morning,
>>
>> For alternative flows like X509 browser, if something goes wrong
>> it will fall back to username/password form, as we already know.
>> But the flow is not executed again until the browser is closed.
>>
>> Based on what Stian commented[1], seems like the same applies to
>> Kerberos. To fix this, we need to change the way how it works today,
>> by going through the list of all alternative flows on refresh,
>> executing them again.
>>
>> Does it make sense? Should we have Jira as "enhancement" for this?
>>
>> [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
>>
>


From bruno at abstractj.org  Fri Nov 24 09:59:52 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 24 Nov 2017 14:59:52 +0000
Subject: [keycloak-dev] Alternative flows on Browser refresh
In-Reply-To: <50d22e3b-4bcc-7b33-3a0d-719f6c0a5888@redhat.com>
References: <20171123111535.GA16569@abstractj.org>
	<2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
	<50d22e3b-4bcc-7b33-3a0d-719f6c0a5888@redhat.com>
Message-ID: <CAM5SUC7s5EgFdUeWD3W7z6nzGsTz6Frf-irXL=egQNE8GeGD9g@mail.gmail.com>

Cool, I just assigned it to you, but let me know if you need any help. From
my pov, 1 and 2 are the best alternatives. We can revisit it after your
changes.

On Fri, Nov 24, 2017 at 12:10 PM Marek Posolda <mposolda at redhat.com> wrote:

> Bruno, did you already started on
> https://issues.jboss.org/browse/KEYCLOAK-5466 ? I have one related issue
> https://issues.jboss.org/browse/KEYCLOAK-5797, which I plan to look at
> next week. I afraid it clashes a bit with the stuff related to
> https://issues.jboss.org/browse/KEYCLOAK-5466 . Especially since I think
> that some changes may be needed in AuthorizationEndpointBase. Do you
> mind to re-assign KEYCLOAK-5466 to me as well? I am pretty sure that I
> will at least address (1) during the
> https://issues.jboss.org/browse/KEYCLOAK-5797 .
>
> Marek
>
>
> Dne 24.11.2017 v 15:03 Marek Posolda napsal(a):
> > I am not sure when exactly we want to retry the alternative
> > authenticators like kerberos or X509? The possibilities are:
> >
> > 1) When user opens the secured application URL (which will redirect
> > him to Keycloak initial OIDC/SAML Authorization endpoint)
> > 2) When user press browser "refresh" on username/password screen
> > 3) When user press browser "refresh" on TOTP (or any possible
> > additional authenticator screen after username/password was already
> > SUCCESS)
> >
> > I wouldn't do 3. It would be likely complicated to implement when
> > thinking various corner cases (browser back/refresh/forward buttons,
> > authenticator state etc). And usability also won't help much IMO...
> >
> > 1 will be easier to implement. Is it sufficient or do we want also 2?
> > The 2 is possible but maybe harder to do, we will need to track
> > whether there was some successful action OR whether some authenticator
> > is already in state SUCCESS.
> >
> > Marek
> >
> >
> > Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
> >> Good morning,
> >>
> >> For alternative flows like X509 browser, if something goes wrong
> >> it will fall back to username/password form, as we already know.
> >> But the flow is not executed again until the browser is closed.
> >>
> >> Based on what Stian commented[1], seems like the same applies to
> >> Kerberos. To fix this, we need to change the way how it works today,
> >> by going through the list of all alternative flows on refresh,
> >> executing them again.
> >>
> >> Does it make sense? Should we have Jira as "enhancement" for this?
> >>
> >> [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
> >>
> >
>
>

From mposolda at redhat.com  Fri Nov 24 10:10:28 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Nov 2017 16:10:28 +0100
Subject: [keycloak-dev] Alternative flows on Browser refresh
In-Reply-To: <CAM5SUC7s5EgFdUeWD3W7z6nzGsTz6Frf-irXL=egQNE8GeGD9g@mail.gmail.com>
References: <20171123111535.GA16569@abstractj.org>
	<2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
	<50d22e3b-4bcc-7b33-3a0d-719f6c0a5888@redhat.com>
	<CAM5SUC7s5EgFdUeWD3W7z6nzGsTz6Frf-irXL=egQNE8GeGD9g@mail.gmail.com>
Message-ID: <dd9de15e-17b4-bee0-cb5d-d4840d1e4693@redhat.com>

Cool, Thanks.

Just thinking about the help. Do you have a chance to write an automated 
test for the X509 scenario from 
https://issues.jboss.org/browse/KEYCLOAK-5466 and put it to some your 
branch? Not sure if for scenario 1 or 2 or both? I can then cherry-pick 
and see if the test will be automagically fixed after my changes :) WDYT?


On 24/11/17 15:59, Bruno Oliveira wrote:
> Cool, I just assigned it to you, but let me know if you need any help. 
> From my pov, 1 and 2 are the best alternatives. We can revisit it 
> after your changes.
>
> On Fri, Nov 24, 2017 at 12:10 PM Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Bruno, did you already started on
>     https://issues.jboss.org/browse/KEYCLOAK-5466 ? I have one related
>     issue
>     https://issues.jboss.org/browse/KEYCLOAK-5797, which I plan to look at
>     next week. I afraid it clashes a bit with the stuff related to
>     https://issues.jboss.org/browse/KEYCLOAK-5466 . Especially since I
>     think
>     that some changes may be needed in AuthorizationEndpointBase. Do you
>     mind to re-assign KEYCLOAK-5466 to me as well? I am pretty sure that I
>     will at least address (1) during the
>     https://issues.jboss.org/browse/KEYCLOAK-5797 .
>
>     Marek
>
>
>     Dne 24.11.2017 v 15:03 Marek Posolda napsal(a):
>     > I am not sure when exactly we want to retry the alternative
>     > authenticators like kerberos or X509? The possibilities are:
>     >
>     > 1) When user opens the secured application URL (which will redirect
>     > him to Keycloak initial OIDC/SAML Authorization endpoint)
>     > 2) When user press browser "refresh" on username/password screen
>     > 3) When user press browser "refresh" on TOTP (or any possible
>     > additional authenticator screen after username/password was already
>     > SUCCESS)
>     >
>     > I wouldn't do 3. It would be likely complicated to implement when
>     > thinking various corner cases (browser back/refresh/forward buttons,
>     > authenticator state etc). And usability also won't help much IMO...
>     >
>     > 1 will be easier to implement. Is it sufficient or do we want
>     also 2?
>     > The 2 is possible but maybe harder to do, we will need to track
>     > whether there was some successful action OR whether some
>     authenticator
>     > is already in state SUCCESS.
>     >
>     > Marek
>     >
>     >
>     > Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
>     >> Good morning,
>     >>
>     >> For alternative flows like X509 browser, if something goes wrong
>     >> it will fall back to username/password form, as we already know.
>     >> But the flow is not executed again until the browser is closed.
>     >>
>     >> Based on what Stian commented[1], seems like the same applies to
>     >> Kerberos. To fix this, we need to change the way how it works
>     today,
>     >> by going through the list of all alternative flows on refresh,
>     >> executing them again.
>     >>
>     >> Does it make sense? Should we have Jira as "enhancement" for this?
>     >>
>     >> [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
>     >>
>     >
>


From sthorger at redhat.com  Mon Nov 27 06:39:14 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Nov 2017 12:39:14 +0100
Subject: [keycloak-dev] Alternative flows on Browser refresh
In-Reply-To: <2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
References: <20171123111535.GA16569@abstractj.org>
	<2727cff5-58a7-4f0d-8cc2-0ad99cd7ab76@redhat.com>
Message-ID: <CAJgngAfAWKMR9WQBREBAQtPS10NUmnWaswX-YH2d2ngyELXm5A@mail.gmail.com>

Option 1 should be done for sure.

Option 2 I think we should do. Shouldn't be to hard to have some sort of
flag in the authentication session to mark if something has happened or not?

Option 3 we could consider in the future, but I would do it with a link on
the forms with something like "Login as a different users" or something to
indicate to the user that they want to start from scratch again.

On 24 November 2017 at 15:03, Marek Posolda <mposolda at redhat.com> wrote:

> I am not sure when exactly we want to retry the alternative
> authenticators like kerberos or X509? The possibilities are:
>
> 1) When user opens the secured application URL (which will redirect him
> to Keycloak initial OIDC/SAML Authorization endpoint)
> 2) When user press browser "refresh" on username/password screen
> 3) When user press browser "refresh" on TOTP (or any possible additional
> authenticator screen after username/password was already SUCCESS)
>
> I wouldn't do 3. It would be likely complicated to implement when
> thinking various corner cases (browser back/refresh/forward buttons,
> authenticator state etc). And usability also won't help much IMO...
>
> 1 will be easier to implement. Is it sufficient or do we want also 2?
> The 2 is possible but maybe harder to do, we will need to track whether
> there was some successful action OR whether some authenticator is
> already in state SUCCESS.
>
> Marek
>
>
> Dne 23.11.2017 v 12:15 Bruno Oliveira napsal(a):
> > Good morning,
> >
> > For alternative flows like X509 browser, if something goes wrong
> > it will fall back to username/password form, as we already know.
> > But the flow is not executed again until the browser is closed.
> >
> > Based on what Stian commented[1], seems like the same applies to
> > Kerberos. To fix this, we need to change the way how it works today,
> > by going through the list of all alternative flows on refresh,
> > executing them again.
> >
> > Does it make sense? Should we have Jira as "enhancement" for this?
> >
> > [1] - https://issues.jboss.org/browse/KEYCLOAK-5466
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Nov 27 07:02:54 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 27 Nov 2017 13:02:54 +0100
Subject: [keycloak-dev] X509 authentication - auto submit countdown
In-Reply-To: <CY1PR0701MB16945659BB4D131B857E1A18DA230@CY1PR0701MB1694.namprd07.prod.outlook.com>
References: <CAM5SUC49DoTZm0E0bn5c2eEKUOuFSSp9FLpCo+r=xjPdxf8L_A@mail.gmail.com>
	<CY1PR0701MB16945659BB4D131B857E1A18DA230@CY1PR0701MB1694.namprd07.prod.outlook.com>
Message-ID: <CAJgngAeMJ+vNPH81DZqxokd_V86efFLg2QnQ+H=Z+v5ZOTGW+g@mail.gmail.com>

+1

On 21 November 2017 at 17:09, Nalyvayko, Peter <pnalyvayko at agi.com> wrote:

> +1
> ________________________________________
> From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.
> jboss.org] on behalf of Bruno Oliveira [bruno at abstractj.org]
> Sent: Tuesday, November 21, 2017 10:12 AM
> To: keycloak-dev
> Subject: [keycloak-dev] X509 authentication - auto submit countdown
>
> Good morning,
>
> I would like to remove this from X509 login page
> https://github.com/keycloak/keycloak/blob/9083e5fe5cb5ba6b63042f759c7498
> 4e1d1a1a76/themes/src/main/resources/theme/base/login/
> login-x509-info.ftl#L59-L70.
> Do we have a strong motivation to keep it?
>
> Today we do not provide anything close to this to other login pages and I
> don't see why X509 authentication should behave different. Thoughts?
> _______________________________________________
> 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 matzew at apache.org  Mon Nov 27 09:14:26 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 27 Nov 2017 15:14:26 +0100
Subject: [keycloak-dev] Problem with 3.4.0 (not present in 3.2.1)
Message-ID: <CAAg5f2ScaB94TWu3BKt9uwv=rud2goHS75M8ekWtDxxKXMxH1g@mail.gmail.com>

Hi,

I am on 3,2,1 and all works fine. Updating to 3.4.0 causes a problem:

* After I enter user/passwd on the keycloak login form. I get an endless
redirect loop, with the following log message in Chrome (FF has same
redirect loop):


The value of the 'Access-Control-Allow-Origin' header in the response must
not be the wildcard '*' when the request's credentials mode is 'include'.
Origin 'http://localhost:9191' is therefore not allowed access. The
credentials mode of requests initiated by the XMLHttpRequest is controlled
by the withCredentials attribute.


I've updated my java adapters to 3.4.0 as well the as the angular one:
https://github.com/aerogear/unifiedpush-admin-ui/pull/14/files

I have this in the config of my realm:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/docker-compose/keycloak-realm/ups-realm-sample.json#L62

and as said before w/ the 3.2.1 it all works - with 3.4.0 not

Anyone seen this before ?

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

From jblashka at redhat.com  Mon Nov 27 11:57:52 2017
From: jblashka at redhat.com (Jared Blashka)
Date: Mon, 27 Nov 2017 11:57:52 -0500
Subject: [keycloak-dev] Is there a way to log the details from
	ErrorResponseExceptions?
Message-ID: <CALO-DfDczCJr2i17R=xL9yOB3Mb_rBTDHp2iKnfJ0btvkXL8KQ@mail.gmail.com>

Some of our clients are generating many REFRESH_TOKEN_ERROR events but I
don't see anywhere that the error description from the exception is
logged/stored. The keycloak event itself only says 'invalid token', but I'd
like to see the '{"error":"invalid_grant","error_description":"Session not
active"}' details as well to be able to provide specific guidance around
why their refresh calls are failing.

I tried registering an Exception Mapper provider, but it doesn't looks like
that's supported yet (
http://lists.jboss.org/pipermail/keycloak-dev/2016-June/007361.html).

We're running RH-SSO 7.1.3.

Thanks!
Jared Blashka
Red Hat

From tonnis at autonomic.ai  Mon Nov 27 13:53:08 2017
From: tonnis at autonomic.ai (Tonnis Wildeboer)
Date: Mon, 27 Nov 2017 10:53:08 -0800
Subject: [keycloak-dev] offlineSessions data in cache vs db
Message-ID: <5332a28b-72cb-7bc9-be6e-a449d46fdd9c@autonomic.ai>

Hello Keycloak Devs,

[I posted this to keycloak-user, but got no response.]

Ultimately, what we want to do is migrate three nodes from one namespace 
to another within a Kubernetes cluster as follows:
Start with three nodes in one Kubernetes namespace that define a 
cluster. Then add three more nodes to the cluster in a new namespace 
that shares the same subnet and database, then kill off the original 
three nodes, effectively migrating the cluster to the new namespace and 
we want to do all this without anyone being logged out. The namespace 
distinction is invisible to Keycloak, as far as I can tell.

What we have tried:
* Start with 3 standalone-ha mode instances clustered with 
JGroups/JDBC_PING.
* Set the number of cache owners for sessions to 6.
* Start the three new instances in the new Kubernetes namespace, 
configured exactly the same as the first three - that is, same db, same 
number of cache owners.
* Kill -9 the original three (I know now that it should be a kill -3, 
but don't know if that matters in this case).

But it seems this caused offlineSession tokens to be expired immediately.

I found this in the online documentation 
(http://www.keycloak.org/docs/latest/server_installation/index.html#server-cache-configuration): 


 > The second type of cache handles managing user sessions, offline 
tokens, and keeping track of login failures... The data held in these 
caches is temporary, in memory only, but is possibly replicated across 
the cluster.

 > The sessions, authenticationSessions, offlineSessions and 
loginFailures caches are the only caches that may perform replication. 
Entries are not replicated to every single node, but instead one or more 
nodes is chosen as an owner of that data. If a node is not the owner of 
a specific cache entry it queries the cluster to obtain it. What this 
means for failover is that if all the nodes that own a piece of data go 
down, that data is lost forever. By default, Keycloak only specifies one 
owner for data. So if that one node goes down that data is lost. This 
usually means that users will be logged out and will have to login again.

It appears, based on these documentation comments and our experience, 
that the "source of truth" regarding offlineSessions is the data in the 
"owner" caches, is NOT the database, as I would have expected. It also 
seems to be the case that if a node joins the cluster (as defined by 
JGroups/JDBC_PING), it will NOT be able to populate its offlineSessions 
cache from the database, but must rely on replication from one of the 
owner nodes.

Questions:
1. Is the above understanding regarding the db vs cache correct?
2. If so, please explain the design/reasoning behind this behavior. 
Otherwise, please correct my understanding.
3. Is there a way to perform this simple migration without losing any 
sessions?

Thanks,

--Tonnis

From mikolaj.buda at contractors.roche.com  Wed Nov 29 03:20:36 2017
From: mikolaj.buda at contractors.roche.com (Buda, Mikolaj)
Date: Wed, 29 Nov 2017 09:20:36 +0100
Subject: [keycloak-dev] Importing big realms
Message-ID: <CADdJyKoHw2PcxDhBdzPZcELdHP1VOK7ERz+i-T4ijFf3AJkZag@mail.gmail.com>

Hi,

I've just created a tool that prepares a full backup of realm in json (the
same as during export at standalone startup). Sometime it is 60MB of data
(many users). Import process takes a long time. Do you have any ideas how
to speed up this process?

From sthorger at redhat.com  Wed Nov 29 04:23:12 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 29 Nov 2017 10:23:12 +0100
Subject: [keycloak-dev] Importing big realms
In-Reply-To: <CADdJyKoHw2PcxDhBdzPZcELdHP1VOK7ERz+i-T4ijFf3AJkZag@mail.gmail.com>
References: <CADdJyKoHw2PcxDhBdzPZcELdHP1VOK7ERz+i-T4ijFf3AJkZag@mail.gmail.com>
Message-ID: <CAJgngAdMF5L0MEzwv6dG5u5WazuKFuzU2h3hAh_Eq1MCwpCL8A@mail.gmail.com>

This is a question for the user mailing list.

On 29 November 2017 at 09:20, Buda, Mikolaj <
mikolaj.buda at contractors.roche.com> wrote:

> Hi,
>
> I've just created a tool that prepares a full backup of realm in json (the
> same as during export at standalone startup). Sometime it is 60MB of data
> (many users). Import process takes a long time. Do you have any ideas how
> to speed up this process?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Wed Nov 29 07:00:45 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Nov 2017 13:00:45 +0100
Subject: [keycloak-dev] Better support authenticationSessions in multiple
	browser tabs
Message-ID: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>

I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797 issue now. 
It's about the fact, that when user has opened browser with multiple 
browser tabs, then after successful login in tab1 (clientA), he may be 
redirected to the incorrect client (clientB, which was opened in tab2).

The thing is, that authenticationSession was tracked by the cookie and 
didn't support multiple clients. So both browser tabs "tab1" and "tab2" 
used same authenticationSession, which can reference just one of the 
clients, hence there could be the conflict and one of the tabs 
redirected to incorrect client after authentication.

I am working on a fix, that allow better support for multiple clients. 
What I am doing is, that there is "RootAuthenticationSessionModel", 
which is now referenced by the ID from the cookie. That root session can 
reference more actual authentication sessions through the map like 
"Map<String, AuthenticationSessionModel>" . The key is the client UUID. 
In the Authentication SPI, there are no changes. Those still use the 
AuthenticationSessionModel as before.

This is easily possible as we have "client-id" parameter already 
available during authentication flows in every tab. So every browser tab 
can reference correct client and redirect to it.

However even with the fix, there is another corner case about support 
for multiple browser tabs with *same* client. This will be still an 
issue, especially for the javascript clients. I've created another JIRA 
https://issues.jboss.org/browse/KEYCLOAK-5938 with the example issue, 
which can be simulated with our admin console. To properly support 
multiple tabs of same client, the key will need to be like: "client-id + 
state" instead of just "client-id"  The "state" will need to be either 
the OIDC/SAML state or some randomly generated string (As in both the 
OAuth2 and SAML, the state/relayState parameter is not mandatory AFAIK), 
which will need to be added to the URL during authentication flows as well.

Fixing this will take me another few days of work (maybe 2?) as there 
will need to be change in many files for adding the new parameter + some 
more authenticationSession model changes etc. So I wonder if we want to:
1) Fix this in 3.4.1 . Will likely mean to delay the release?
2) Fix this in 3.4.2. It will affect many files and there is some chance 
of regression (hopefully not big as we have lots of the tests for 
various other corner cases)
3) Fix this later in 4.X .

My vote is 1 or 2. WDYT? Any other possibility?

Marek


From sthorger at redhat.com  Wed Nov 29 08:44:55 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 29 Nov 2017 14:44:55 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
Message-ID: <CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>

I would target this to 3.4.2. I don't want to delay the 3.4.1 release if we
can help it.

I'd also suggest some (short if possible) random key (or a counter?!)
rather than relying on protocol specific values. 'state' is not actually
required in OAuth right? It's just recommended.

On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com> wrote:

> I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797 issue now.
> It's about the fact, that when user has opened browser with multiple
> browser tabs, then after successful login in tab1 (clientA), he may be
> redirected to the incorrect client (clientB, which was opened in tab2).
>
> The thing is, that authenticationSession was tracked by the cookie and
> didn't support multiple clients. So both browser tabs "tab1" and "tab2"
> used same authenticationSession, which can reference just one of the
> clients, hence there could be the conflict and one of the tabs
> redirected to incorrect client after authentication.
>
> I am working on a fix, that allow better support for multiple clients.
> What I am doing is, that there is "RootAuthenticationSessionModel",
> which is now referenced by the ID from the cookie. That root session can
> reference more actual authentication sessions through the map like
> "Map<String, AuthenticationSessionModel>" . The key is the client UUID.
> In the Authentication SPI, there are no changes. Those still use the
> AuthenticationSessionModel as before.
>
> This is easily possible as we have "client-id" parameter already
> available during authentication flows in every tab. So every browser tab
> can reference correct client and redirect to it.
>
> However even with the fix, there is another corner case about support
> for multiple browser tabs with *same* client. This will be still an
> issue, especially for the javascript clients. I've created another JIRA
> https://issues.jboss.org/browse/KEYCLOAK-5938 with the example issue,
> which can be simulated with our admin console. To properly support
> multiple tabs of same client, the key will need to be like: "client-id +
> state" instead of just "client-id"  The "state" will need to be either
> the OIDC/SAML state or some randomly generated string (As in both the
> OAuth2 and SAML, the state/relayState parameter is not mandatory AFAIK),
> which will need to be added to the URL during authentication flows as well.
>
> Fixing this will take me another few days of work (maybe 2?) as there
> will need to be change in many files for adding the new parameter + some
> more authenticationSession model changes etc. So I wonder if we want to:
> 1) Fix this in 3.4.1 . Will likely mean to delay the release?
> 2) Fix this in 3.4.2. It will affect many files and there is some chance
> of regression (hopefully not big as we have lots of the tests for
> various other corner cases)
> 3) Fix this later in 4.X .
>
> My vote is 1 or 2. WDYT? Any other possibility?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Wed Nov 29 09:09:42 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Nov 2017 15:09:42 +0100
Subject: [keycloak-dev] Better support authenticationSessions in
 multiple browser tabs
In-Reply-To: <CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
References: <df2376a1-d9c4-1b41-237b-ffd7ee073e18@redhat.com>
	<CAJgngAd++v1+4wQr+O7AizTDgcfe3nYUJZ5WG+tv+r+d942rnw@mail.gmail.com>
Message-ID: <7e6d1466-9634-c483-5750-a5c7d83c83f3@redhat.com>

On 29/11/17 14:44, Stian Thorgersen wrote:
> I would target this to 3.4.2. I don't want to delay the 3.4.1 release 
> if we can help it.
>
> I'd also suggest some (short if possible) random key (or a counter?!) 
> rather than relying on protocol specific values. 'state' is not 
> actually required in OAuth right? It's just recommended.
Yes, it's not required. And same for SAML. Was wondering about the same. 
Will use the random key or counter. Thinking if counter doesn't have 
some corner case issues (EG. If 2 tabs are opened concurrently after 
logout and will try to use same counter value as authSession update from 
tab2 won't be yet visible in tab1).

Marek
>
> On 29 November 2017 at 13:00, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I am looking at https://issues.jboss.org/browse/KEYCLOAK-5797
>     <https://issues.jboss.org/browse/KEYCLOAK-5797> issue now.
>     It's about the fact, that when user has opened browser with multiple
>     browser tabs, then after successful login in tab1 (clientA), he may be
>     redirected to the incorrect client (clientB, which was opened in
>     tab2).
>
>     The thing is, that authenticationSession was tracked by the cookie and
>     didn't support multiple clients. So both browser tabs "tab1" and
>     "tab2"
>     used same authenticationSession, which can reference just one of the
>     clients, hence there could be the conflict and one of the tabs
>     redirected to incorrect client after authentication.
>
>     I am working on a fix, that allow better support for multiple clients.
>     What I am doing is, that there is "RootAuthenticationSessionModel",
>     which is now referenced by the ID from the cookie. That root
>     session can
>     reference more actual authentication sessions through the map like
>     "Map<String, AuthenticationSessionModel>" . The key is the client
>     UUID.
>     In the Authentication SPI, there are no changes. Those still use the
>     AuthenticationSessionModel as before.
>
>     This is easily possible as we have "client-id" parameter already
>     available during authentication flows in every tab. So every
>     browser tab
>     can reference correct client and redirect to it.
>
>     However even with the fix, there is another corner case about support
>     for multiple browser tabs with *same* client. This will be still an
>     issue, especially for the javascript clients. I've created another
>     JIRA
>     https://issues.jboss.org/browse/KEYCLOAK-5938
>     <https://issues.jboss.org/browse/KEYCLOAK-5938> with the example
>     issue,
>     which can be simulated with our admin console. To properly support
>     multiple tabs of same client, the key will need to be like:
>     "client-id +
>     state" instead of just "client-id"  The "state" will need to be either
>     the OIDC/SAML state or some randomly generated string (As in both the
>     OAuth2 and SAML, the state/relayState parameter is not mandatory
>     AFAIK),
>     which will need to be added to the URL during authentication flows
>     as well.
>
>     Fixing this will take me another few days of work (maybe 2?) as there
>     will need to be change in many files for adding the new parameter
>     + some
>     more authenticationSession model changes etc. So I wonder if we
>     want to:
>     1) Fix this in 3.4.1 . Will likely mean to delay the release?
>     2) Fix this in 3.4.2. It will affect many files and there is some
>     chance
>     of regression (hopefully not big as we have lots of the tests for
>     various other corner cases)
>     3) Fix this later in 4.X .
>
>     My vote is 1 or 2. WDYT? Any other possibility?
>
>     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 matzew at apache.org  Wed Nov 29 15:13:30 2017
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 29 Nov 2017 21:13:30 +0100
Subject: [keycloak-dev] defaullt port ?
Message-ID: <CAAg5f2StxLbnwNdRipMOtR4MH_=o=Pi4Vu8ecUHBLerbKxS+sg@mail.gmail.com>

Hi,

using the 3.4.0 adapter for WF (11), I am seeing this - sometimes:


20:05:18,790 ERROR [org.keycloak.adapters.BearerTokenRequestAuthenticator]
(default task-103) Failed to verify token:
org.keycloak.common.VerificationException: Invalid token issuer. Expected '
http://172.30.103.210:80/auth/realms/aerogear' , but was '
http://172.30.103.210/auth/realms/aerogear'


I wonder why this makes a difference, since it's the default port - no ?

Thanks!
Matthias

-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

From sthorger at redhat.com  Thu Nov 30 13:25:28 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 30 Nov 2017 19:25:28 +0100
Subject: [keycloak-dev] Keycloak 3.4.1.CR1 released
Message-ID: <CAJgngAdGqzj4+PBpsgLHntbjZmqSQJPebs6XKzxo54LjS9gJFg@mail.gmail.com>

We've just released Keycloak 3.4.1.CR1.

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

A lot of work has gone into finishing the Cross DC support and it should
now be ready to use.
Database Replication

We're now testing database replication with MySQL Galera and Oracle RAC.
This is related to Cross DC support which requires a master node in each DC.
Loads more..

   - Loads and loads of fixes

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

Before you upgrade remember to backup your database and check the upgrade
guide <http://www.keycloak.org/docs/latest/upgrading/index.html> for
anything that may have changed. Release candidates are not recommended in
production and we do not support upgrading from release candidates.