From bburke at redhat.com  Mon Feb  1 00:27:33 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 00:27:33 -0500
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
 always validated.
In-Reply-To: <CAFj68vUtyBqyDYf5ot1ncZqiASy9RcY39U+Z-xVk=4_zYsKToA@mail.gmail.com>
References: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
	<56AA269D.1070204@redhat.com>
	<CAFj68vXjKjoYH_2WHFcD0zjXE_4nLyURYFDSOOebchoNFYjJig@mail.gmail.com>
	<56AA360F.9050801@redhat.com>
	<CAFj68vUtyBqyDYf5ot1ncZqiASy9RcY39U+Z-xVk=4_zYsKToA@mail.gmail.com>
Message-ID: <56AEECC5.20206@redhat.com>

I would say that I'd be reluctant to turn it off.  I think this could be 
used with the classic case of:

1. Attacker authenticates with his account at SAML IDP
2. Attacker saves the response from the IDP
3. Attack tricks user to visit their rogue website, then tricks browser 
to repost the SAML response
4. user now thinks they are logged in, but they are logged in as the 
attacker.

On 1/31/2016 11:11 PM, Arulkumar Ponnusamy wrote:
> Hi Bill,
> As per SAML spec, this Destination element is optional. does not this 
> validation is optional.
>
> SAML Spec says,
>
> Destination [Optional]
>
> A URI reference indicating the address to which this request has been 
> sent. This is useful to prevent
>
> malicious forwarding of requests to unintended recipients, a 
> protection that is required by some
>
> protocol bindings. If it is present, the actual recipient MUST check 
> that the URI reference identifies the
>
> location at which the message was received. If it does not, the 
> request MUST be discarded. Some
>
> protocol bindings may require the use of this attribute (see [SAMLBind]).
>
>
>
> On Thu, Jan 28, 2016 at 9:08 PM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     IMO, they should provide it irregardless.
>
>
>     On 1/28/2016 10:21 AM, Arulkumar Ponnusamy wrote:
>>
>>     Yep.. We are trying to integrate with Ping Federate IDP and it
>>     causing the authentication failure. But, Ping federate does not
>>     give Destination element  for signed xml too which we need to
>>     follow up with Ping federate.
>>
>>     On 28-Jan-2016 8:03 PM, "Bill Burke" <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         Yes, we validate it.  Is this a problem with some third party
>>         saml integration?
>>
>>         On 1/28/2016 5:31 AM, Arulkumar Ponnusamy wrote:
>>>         As per OASIS/SAML spec recommendation, If the message is
>>>         signed, the Destination XML attribute in the root SAML
>>>         element of the protocol message MUST contain the URL to
>>>         which the sender has instructed the user agent to deliver
>>>         the message. The recipient MUST then verify that the value
>>>         matches the location at which the message has been received.
>>>
>>>         However, in keycloak, always validate the 'Destination'  on
>>>         saml response. irrespective of response is signed or not.
>>>
>>>         is not a defect?
>>>
>>>         Thanks,
>>>         Arul kumar P.
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>         -- 
>>         Bill Burke
>>         JBoss, a division of Red Hat
>>         http://bill.burkecentral.com
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From sthorger at redhat.com  Mon Feb  1 04:39:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 10:39:39 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <56ACC622.4050505@redhat.com>
References: <56ACC622.4050505@redhat.com>
Message-ID: <CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>

+1 We can import already, but we should add export of individual client

On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com> wrote:

> Can we export/import an individual client to and from the
> ClientRepresentation format?  This will be crucial for debugging
> problems in support cases.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/04399ea0/attachment.html 

From sthorger at redhat.com  Mon Feb  1 04:40:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 10:40:45 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
Message-ID: <CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>

I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should try to get
this included for 1.9. Should be pretty trivial to do.

On 1 February 2016 at 10:39, Stian Thorgersen <sthorger at redhat.com> wrote:

> +1 We can import already, but we should add export of individual client
>
> On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com> wrote:
>
>> Can we export/import an individual client to and from the
>> ClientRepresentation format?  This will be crucial for debugging
>> problems in support cases.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/2e3c514a/attachment.html 

From sthorger at redhat.com  Mon Feb  1 04:44:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 10:44:45 +0100
Subject: [keycloak-dev] new browser back button behavior
In-Reply-To: <56AA29EF.5030402@redhat.com>
References: <56AA29EF.5030402@redhat.com>
Message-ID: <CAJgngAdrcfxPGsiL7fO_5TGNjB1covjPoCHWKc4rt_DtEsd+Ag@mail.gmail.com>

On 28 January 2016 at 15:47, Bill Burke <bburke at redhat.com> wrote:

> PR is building...
>
> Browser back button will now either restart the flow (and create a new
> client session) or not allow you off your current page depending on the
> protocol and where you are in the flow.
>
> * If your protocol is initiated by a GET request and the back button
> brings you to the 1st rendered page (username/password) this starts a
> new flow
> * If your protocol is initiated by a POST request (SAML Post binding)
> things work a bit differently.  This initial post request will redirect
> you to the "authenticate" URL.  Then if your back button brings you to
> the username/password page, you will not see it and just stay on your
> current page.
> * If your back button click brings you to the 2nd page in the flow, you
> will just be stuck on your current page.
>
> Try it out.  Hopefully all these refresh and back button issues are done
> now.
>
> Some changes to make this happen:
> * The "code" in the URL o the flow used to be generated by hashing the
> current action key, the current action (AUTHENTICATE, REQUIRE_ACTION),
> and the realm secret key.  The action key changed whenever you changed
> the current action...NOW the action key does NOT change for the whole
> flow.  The action key is automatically generated once when you create
> the ClientSession and never changed again.
>

Is the action key even needed then?


> * Consent page no longer changes the current action to OAUTH_GRANT.
> Consent page is now considered a REQUIRED_ACTION action and treated as
> such.  This was to support back button here too.
> * Cache-Control: no-store, must-revalidate, max-age=0  is now set in the
> response for every endpoint on LoginActionsService and any protocol
> entry point.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/9b5a522a/attachment.html 

From alexgv99 at gmail.com  Mon Feb  1 07:18:41 2016
From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=)
Date: Mon, 1 Feb 2016 10:18:41 -0200
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <56AA3E0A.4030208@redhat.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
	<CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
	<56AA3E0A.4030208@redhat.com>
Message-ID: <CAGGeCYMn2C03gF4C=Fgt2Tpr=pV-3aFNi85DUWbBzYDew96MBg@mail.gmail.com>

Yup... probably I configured something wrong, but I reviewed each step and
couldn't find anything that seems not ok... Is there a way I can export the
realm so you can see it?
I'm attaching some images from the keycloak admin console that maybe can
help...

[image: Imagem inline 2][image: Imagem inline 1][image: Imagem inline 3]

Thank you.


PS: Mistakenly, I had sent this same message just for Mr. Burke.

Cordialmente.
Alex Gouv?a Vasconcelos
mailto:alexgv99 at gmail.com
MSN: alexgv99 at hotmail.com
http://about.me/alexgv99


2016-01-28 14:12 GMT-02:00 Bill Burke <bburke at redhat.com>:

> Then you probably haven't set u the roles correctly for the user that is
> logging in.
>
>
> On 1/28/2016 11:03 AM, Alex Gouv?a Vasconcelos wrote:
>
> Sorry guys, I'm not sure weather the group receive the answer to Mr. Burke
> question about logs or not...
>
>> ?
>> Do you can an exception stacktrace on app or auth server??
>
> Anyway, there's no log to share, here... the server.log file (in Keycloak
> cluster - 2 instances) doesn't emit any line in the process... and the
> Wildfly (where the app is deployed) just say:
>
>> ?
>> 16:10:23,145 WARN [org.keycloak.adapters.OAuthRequestAuthenticator]
>> ? ?
>> (default task-66) No state cookie?
>
>
> ? So, I hope someone could help me here...
>
> Thanks. ?
>
>
> ---------- Forwarded message ----------
> From: Alex Gouv?a Vasconcelos <alexgv99 at gmail.com>
> Date: 2016-01-26 17:16 GMT-02:00
> Subject: Fwd: Bad Request
> To: keycloak-dev at lists.jboss.org
>
>
> Hi guys. I'm running into some trouble here...
>
> I have a very simple application which should authenticate against
> keycloak and return to the main page. This is triggered through the web.xml
> in my application.
>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation=" <http://java.sun.com/xml/ns/javaee>
> http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
>
> <module-name>teste</module-name>
>
> <filter>
> <filter-name>CORSFilter</filter-name>
> <filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>CORSFilter</filter-name>
> <url-pattern>/rest/*</url-pattern>
> </filter-mapping>
>
> <distributable />
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>teste</web-resource-name>
> <url-pattern>/rest/exemploService/secure/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> <login-config>
> <auth-method>KEYCLOAK</auth-method>
> <realm-name>realmtest</realm-name>
> </login-config>
> <security-role>
> <role-name>user</role-name>
> </security-role>
> <security-role>
> <role-name>admin</role-name>
> </security-role>
>
> </web-app>
>
>
> The server side has a REST API and the client side is an angular
> application. Everything very simple to just try the development
> environment. What happens is that, after filling the login page and return
> to the index.html (actually it's not returning), I receive a 400 BAD
> REQUEST for the uri:
>
>
> <http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1>
> http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1
>
>
> It seems to me, that the malformed URI is because of the ?code=... If I
> reload the page with the same URL, it just return the same 400... if I
> remove the ? portion, it reloads the page and again redirects to and from
> the keycloak server, and recovers the ? portion, repeating the same 400.
>
> I'm running everything in the same application under wildfly 10. Both the
> server and client sides in the same deployed WAR.
>
> I'd appreciate any help.
>
> Best regards.
>
> Alex Gouvea Vasconcelos
>
>
>
>
>
>
>
> [image: Imagem inline 1]
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/8323ea64/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Client.png
Type: image/png
Size: 82757 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/8323ea64/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 248184 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/8323ea64/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Roles.png
Type: image/png
Size: 20781 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/8323ea64/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Json.png
Type: image/png
Size: 91354 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/8323ea64/attachment-0007.png 

From ssilvert at redhat.com  Mon Feb  1 08:45:48 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 01 Feb 2016 08:45:48 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
Message-ID: <56AF618C.3050706@redhat.com>

On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
> I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should try 
> to get this included for 1.9. Should be pretty trivial to do.
I already implemented a version of this for several of the resources but 
we left it out in favor of eventually having a single-screen solution.  
I could dig it out and add it for clients.
>
> On 1 February 2016 at 10:39, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     +1 We can import already, but we should add export of individual
>     client
>
>     On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         Can we export/import an individual client to and from the
>         ClientRepresentation format?  This will be crucial for debugging
>         problems in support cases.
>
>         --
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Feb  1 08:53:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 14:53:42 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <56AF618C.3050706@redhat.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
Message-ID: <CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>

On 1 February 2016 at 14:45, Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>
> I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should try to
> get this included for 1.9. Should be pretty trivial to do.
>
> I already implemented a version of this for several of the resources but
> we left it out in favor of eventually having a single-screen solution.  I
> could dig it out and add it for clients.
>

It's not partial export we want - it's just export of a single client.


>
>
> On 1 February 2016 at 10:39, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> +1 We can import already, but we should add export of individual client
>>
>> On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Can we export/import an individual client to and from the
>>> ClientRepresentation format?  This will be crucial for debugging
>>> problems in support cases.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/0ea6834e/attachment.html 

From ssilvert at redhat.com  Mon Feb  1 09:02:16 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 01 Feb 2016 09:02:16 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
Message-ID: <56AF6568.7080001@redhat.com>

On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>
>
> On 1 February 2016 at 14:45, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>     I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should
>>     try to get this included for 1.9. Should be pretty trivial to do.
>     I already implemented a version of this for several of the
>     resources but we left it out in favor of eventually having a
>     single-screen solution.  I could dig it out and add it for clients.
>
>
> It's not partial export we want - it's just export of a single client.
That's what the old implementation would do.
>
>
>>
>>     On 1 February 2016 at 10:39, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>         +1 We can import already, but we should add export of
>>         individual client
>>
>>         On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>             Can we export/import an individual client to and from the
>>             ClientRepresentation format?  This will be crucial for
>>             debugging
>>             problems in support cases.
>>
>>             --
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Feb  1 09:23:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 15:23:49 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <56AF6568.7080001@redhat.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
Message-ID: <CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>

On 1 February 2016 at 15:02, Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>
>
>
> On 1 February 2016 at 14:45, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>
>> I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should try to
>> get this included for 1.9. Should be pretty trivial to do.
>>
>> I already implemented a version of this for several of the resources but
>> we left it out in favor of eventually having a single-screen solution.  I
>> could dig it out and add it for clients.
>>
>
> It's not partial export we want - it's just export of a single client.
>
> That's what the old implementation would do.
>

Export a single client?


>
>
>
>>
>>
>> On 1 February 2016 at 10:39, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> +1 We can import already, but we should add export of individual client
>>>
>>> On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> Can we export/import an individual client to and from the
>>>> ClientRepresentation format?  This will be crucial for debugging
>>>> problems in support cases.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/ad19f2c6/attachment-0001.html 

From ssilvert at redhat.com  Mon Feb  1 09:26:13 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 01 Feb 2016 09:26:13 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
	<CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
Message-ID: <56AF6B05.8010505@redhat.com>

On 2/1/2016 9:23 AM, Stian Thorgersen wrote:
>
>
> On 1 February 2016 at 15:02, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>>
>>
>>     On 1 February 2016 at 14:45, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>>         I added https://issues.jboss.org/browse/KEYCLOAK-2420. We
>>>         should try to get this included for 1.9. Should be pretty
>>>         trivial to do.
>>         I already implemented a version of this for several of the
>>         resources but we left it out in favor of eventually having a
>>         single-screen solution.  I could dig it out and add it for
>>         clients.
>>
>>
>>     It's not partial export we want - it's just export of a single
>>     client.
>     That's what the old implementation would do.
>
>
> Export a single client?
Yes.  To be more specific, it allowed you to filter the output so you 
could export a single client or a subset of all clients.

I could easily adapt this to export the client you are viewing.  The 
advantage is that I already implemented all the code that does this and 
it allows you to save it on the server or on the admin's machine.

>
>>
>>>
>>>         On 1 February 2016 at 10:39, Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>             +1 We can import already, but we should add export of
>>>             individual client
>>>
>>>             On 30 January 2016 at 15:18, Bill Burke
>>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>
>>>                 Can we export/import an individual client to and
>>>                 from the
>>>                 ClientRepresentation format?  This will be crucial
>>>                 for debugging
>>>                 problems in support cases.
>>>
>>>                 --
>>>                 Bill Burke
>>>                 JBoss, a division of Red Hat
>>>                 http://bill.burkecentral.com
>>>
>>>                 _______________________________________________
>>>                 keycloak-dev mailing list
>>>                 keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

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

From sthorger at redhat.com  Mon Feb  1 09:31:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 15:31:39 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <56AF6B05.8010505@redhat.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
	<CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
	<56AF6B05.8010505@redhat.com>
Message-ID: <CAJgngAd8e3NRO4P=Km2QesYUis69HnQTdPNvFteO-q4eH-j5Og@mail.gmail.com>

On 1 February 2016 at 15:26, Stan Silvert <ssilvert at redhat.com> wrote:

> On 2/1/2016 9:23 AM, Stian Thorgersen wrote:
>
>
>
> On 1 February 2016 at 15:02, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>>
>>
>>
>> On 1 February 2016 at 14:45, Stan Silvert <ssilvert at redhat.com> wrote:
>>
>>> On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>>
>>> I added https://issues.jboss.org/browse/KEYCLOAK-2420. We should try to
>>> get this included for 1.9. Should be pretty trivial to do.
>>>
>>> I already implemented a version of this for several of the resources but
>>> we left it out in favor of eventually having a single-screen solution.  I
>>> could dig it out and add it for clients.
>>>
>>
>> It's not partial export we want - it's just export of a single client.
>>
>> That's what the old implementation would do.
>>
>
> Export a single client?
>
> Yes.  To be more specific, it allowed you to filter the output so you
> could export a single client or a subset of all clients.
>
> I could easily adapt this to export the client you are viewing.  The
> advantage is that I already implemented all the code that does this and it
> allows you to save it on the server or on the admin's machine.
>

That's not what we want. We don't actually need any server side code for
this feature. The client json is already available from the server all we
need is an export button that downloads it as a json file.


>
>
>
>
>>
>>
>>
>>>
>>>
>>> On 1 February 2016 at 10:39, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> +1 We can import already, but we should add export of individual client
>>>>
>>>> On 30 January 2016 at 15:18, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> Can we export/import an individual client to and from the
>>>>> ClientRepresentation format?  This will be crucial for debugging
>>>>> problems in support cases.
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/178fd55b/attachment-0001.html 

From bburke at redhat.com  Mon Feb  1 09:37:27 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 09:37:27 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAd8e3NRO4P=Km2QesYUis69HnQTdPNvFteO-q4eH-j5Og@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
	<CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
	<56AF6B05.8010505@redhat.com>
	<CAJgngAd8e3NRO4P=Km2QesYUis69HnQTdPNvFteO-q4eH-j5Og@mail.gmail.com>
Message-ID: <56AF6DA7.1000301@redhat.com>



On 2/1/2016 9:31 AM, Stian Thorgersen wrote:
>
>
> On 1 February 2016 at 15:26, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 2/1/2016 9:23 AM, Stian Thorgersen wrote:
>>
>>
>>     On 1 February 2016 at 15:02, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>>>
>>>
>>>         On 1 February 2016 at 14:45, Stan Silvert
>>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>             On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>>>             I added https://issues.jboss.org/browse/KEYCLOAK-2420.
>>>>             We should try to get this included for 1.9. Should be
>>>>             pretty trivial to do.
>>>             I already implemented a version of this for several of
>>>             the resources but we left it out in favor of eventually
>>>             having a single-screen solution.  I could dig it out and
>>>             add it for clients.
>>>
>>>
>>>         It's not partial export we want - it's just export of a
>>>         single client.
>>         That's what the old implementation would do.
>>
>>
>>     Export a single client?
>     Yes.  To be more specific, it allowed you to filter the output so
>     you could export a single client or a subset of all clients.
>
>     I could easily adapt this to export the client you are viewing. 
>     The advantage is that I already implemented all the code that does
>     this and it allows you to save it on the server or on the admin's
>     machine.
>
>
> That's not what we want. We don't actually need any server side code 
> for this feature. The client json is already available from the server 
> all we need is an export button that downloads it as a json file.

Just an export button on the client list page. next to each client just 
like we already have edit/delete.

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

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

From sthorger at redhat.com  Mon Feb  1 09:38:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 15:38:50 +0100
Subject: [keycloak-dev] client export import?
In-Reply-To: <56AF6DA7.1000301@redhat.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
	<CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
	<56AF6B05.8010505@redhat.com>
	<CAJgngAd8e3NRO4P=Km2QesYUis69HnQTdPNvFteO-q4eH-j5Og@mail.gmail.com>
	<56AF6DA7.1000301@redhat.com>
Message-ID: <CAJgngAejuxGZYm7hsb1KLUVtU9xgCPGvJAfuN2VSWiYYg8x0Uw@mail.gmail.com>

On 1 February 2016 at 15:37, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 2/1/2016 9:31 AM, Stian Thorgersen wrote:
>
>
>
> On 1 February 2016 at 15:26, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 2/1/2016 9:23 AM, Stian Thorgersen wrote:
>>
>>
>>
>> On 1 February 2016 at 15:02, Stan Silvert < <ssilvert at redhat.com>
>> ssilvert at redhat.com> wrote:
>>
>>> On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 1 February 2016 at 14:45, Stan Silvert < <ssilvert at redhat.com>
>>> ssilvert at redhat.com> wrote:
>>>
>>>> On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>>>
>>>> I added  <https://issues.jboss.org/browse/KEYCLOAK-2420>
>>>> https://issues.jboss.org/browse/KEYCLOAK-2420. We should try to get
>>>> this included for 1.9. Should be pretty trivial to do.
>>>>
>>>> I already implemented a version of this for several of the resources
>>>> but we left it out in favor of eventually having a single-screen solution.
>>>> I could dig it out and add it for clients.
>>>>
>>>
>>> It's not partial export we want - it's just export of a single client.
>>>
>>> That's what the old implementation would do.
>>>
>>
>> Export a single client?
>>
>> Yes.  To be more specific, it allowed you to filter the output so you
>> could export a single client or a subset of all clients.
>>
>> I could easily adapt this to export the client you are viewing.  The
>> advantage is that I already implemented all the code that does this and it
>> allows you to save it on the server or on the admin's machine.
>>
>
> That's not what we want. We don't actually need any server side code for
> this feature. The client json is already available from the server all we
> need is an export button that downloads it as a json file.
>
>
>
> Just an export button on the client list page. next to each client just
> like we already have edit/delete.
>

Is it not better to have the button on the client detail page?


>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/b95e0737/attachment.html 

From bburke at redhat.com  Mon Feb  1 09:41:24 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 09:41:24 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <CAJgngAejuxGZYm7hsb1KLUVtU9xgCPGvJAfuN2VSWiYYg8x0Uw@mail.gmail.com>
References: <56ACC622.4050505@redhat.com>
	<CAJgngAcg=Yit5-VRy_ZNrDwZ9CUY24E3ud64trL+KOe0cAV3Aw@mail.gmail.com>
	<CAJgngAcGHS+sAfHFozEUiDFmxdmpwYgH4JQ8cdTWyiO7knRJcA@mail.gmail.com>
	<56AF618C.3050706@redhat.com>
	<CAJgngAcganrTtn+VQ2je1VNrGHNMXH40DPcH78ohvg4dJGq7ow@mail.gmail.com>
	<56AF6568.7080001@redhat.com>
	<CAJgngAd2J9i+VMhJFZiDMMSueM3p-8XhSuqkG+b1vvSg4bgMsg@mail.gmail.com>
	<56AF6B05.8010505@redhat.com>
	<CAJgngAd8e3NRO4P=Km2QesYUis69HnQTdPNvFteO-q4eH-j5Og@mail.gmail.com>
	<56AF6DA7.1000301@redhat.com>
	<CAJgngAejuxGZYm7hsb1KLUVtU9xgCPGvJAfuN2VSWiYYg8x0Uw@mail.gmail.com>
Message-ID: <56AF6E94.80903@redhat.com>



On 2/1/2016 9:38 AM, Stian Thorgersen wrote:
>
>
> On 1 February 2016 at 15:37, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 2/1/2016 9:31 AM, Stian Thorgersen wrote:
>>
>>
>>     On 1 February 2016 at 15:26, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>         On 2/1/2016 9:23 AM, Stian Thorgersen wrote:
>>>
>>>
>>>         On 1 February 2016 at 15:02, Stan Silvert
>>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>             On 2/1/2016 8:53 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>             On 1 February 2016 at 14:45, Stan Silvert
>>>>             <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>>                 On 2/1/2016 4:40 AM, Stian Thorgersen wrote:
>>>>>                 I added
>>>>>                 https://issues.jboss.org/browse/KEYCLOAK-2420. We
>>>>>                 should try to get this included for 1.9. Should be
>>>>>                 pretty trivial to do.
>>>>                 I already implemented a version of this for several
>>>>                 of the resources but we left it out in favor of
>>>>                 eventually having a single-screen solution.  I
>>>>                 could dig it out and add it for clients.
>>>>
>>>>
>>>>             It's not partial export we want - it's just export of a
>>>>             single client.
>>>             That's what the old implementation would do.
>>>
>>>
>>>         Export a single client?
>>         Yes.  To be more specific, it allowed you to filter the
>>         output so you could export a single client or a subset of all
>>         clients.
>>
>>         I could easily adapt this to export the client you are
>>         viewing.  The advantage is that I already implemented all the
>>         code that does this and it allows you to save it on the
>>         server or on the admin's machine.
>>
>>
>>     That's not what we want. We don't actually need any server side
>>     code for this feature. The client json is already available from
>>     the server all we need is an export button that downloads it as a
>>     json file.
>
>     Just an export button on the client list page. next to each client
>     just like we already have edit/delete.
>
>
> Is it not better to have the button on the client detail page?

*shrug*  Whatever :)

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

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

From bburke at redhat.com  Mon Feb  1 09:45:40 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 09:45:40 -0500
Subject: [keycloak-dev] in-memory users
Message-ID: <56AF6F94.6070700@redhat.com>

This used to be on the priority list, but we dropped it.  Just thought 
of a better way to support this.  Just write an Infinispan model 
provider and turn off user caching.  Sessions would store a URI to the 
user and use that to locate the user if it is not in storage.  Might be 
relatively simple to implement.

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


From sthorger at redhat.com  Mon Feb  1 09:52:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 1 Feb 2016 15:52:42 +0100
Subject: [keycloak-dev] in-memory users
In-Reply-To: <56AF6F94.6070700@redhat.com>
References: <56AF6F94.6070700@redhat.com>
Message-ID: <CAJgngAe3Bjat0hXQPGU6LH5tA4p84RbwH2TBY+GNoEN0jc7--g@mail.gmail.com>

There's no chance we have time for this now. 1.9.0.CR1 is due on 17th Feb
and we still have 48 unresolved issues. After that it's bug fixing only.

We can do this properly in 2.x don't you think?

On 1 February 2016 at 15:45, Bill Burke <bburke at redhat.com> wrote:

> This used to be on the priority list, but we dropped it.  Just thought
> of a better way to support this.  Just write an Infinispan model
> provider and turn off user caching.  Sessions would store a URI to the
> user and use that to locate the user if it is not in storage.  Might be
> relatively simple to implement.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/576d7be6/attachment.html 

From jayblanc at gmail.com  Mon Feb  1 09:56:03 2016
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Mon, 01 Feb 2016 14:56:03 +0000
Subject: [keycloak-dev] Developing Shibboleth Discovery Service in front of
	SAML Provider
Message-ID: <CAPNq5vZDSF-SYbxVoftnKON3XFwJ7Gq_KO1s0mXD0P-jNXkjaQ@mail.gmail.com>

Hi,

I plan to develop the Shibboleth Discovery Functionnality over the current
SAML Provider.
The goal is to provide a simple way to integrate an identity federation
(like shibboleth) with a single provider.
So I plan to add a new Identity Provider that will fork the SAML one but
adding the capability of parsing a federation metadata file periodically in
order to maintain the list of federation available IdPs and a theme to
produce a simple choice list for the federation IdPs...

To perform this I need to parse an online xml file periodically (1 hour).
What is the best way to include this schedulled job in keycloak ? Is there
any service where to put this code ?
I also plan to maintain the parsed IdP list in memory but it should be good
to store it somewhere ?
Finally, I need a small Resource in order to retreive the accurate list of
IdP from the login form but this should be easy to add in the provider
package.

Using this will allow me to avoid aving 250 IdPs in keycloak and 250
endpoints to provide in the ServiceProvider entity descriptor.

Best regards, J?r?me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/d173b68a/attachment.html 

From bburke at redhat.com  Mon Feb  1 09:59:05 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 1 Feb 2016 09:59:05 -0500
Subject: [keycloak-dev] in-memory users
In-Reply-To: <CAJgngAe3Bjat0hXQPGU6LH5tA4p84RbwH2TBY+GNoEN0jc7--g@mail.gmail.com>
References: <56AF6F94.6070700@redhat.com>
	<CAJgngAe3Bjat0hXQPGU6LH5tA4p84RbwH2TBY+GNoEN0jc7--g@mail.gmail.com>
Message-ID: <56AF72B9.9060107@redhat.com>

I agree on delay.  Just wanted to archive the thoughts just in case it 
becomes an issue for deployments like Openstack that are running 
Keycloak in front of openipa or Red Hat IT.

On 2/1/2016 9:52 AM, Stian Thorgersen wrote:
> There's no chance we have time for this now. 1.9.0.CR1 is due on 17th 
> Feb and we still have 48 unresolved issues. After that it's bug fixing 
> only.
>
> We can do this properly in 2.x don't you think?
>
> On 1 February 2016 at 15:45, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     This used to be on the priority list, but we dropped it.  Just thought
>     of a better way to support this.  Just write an Infinispan model
>     provider and turn off user caching.  Sessions would store a URI to the
>     user and use that to locate the user if it is not in storage. 
>     Might be
>     relatively simple to implement.
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

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

From sthorger at redhat.com  Tue Feb  2 08:11:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 2 Feb 2016 14:11:27 +0100
Subject: [keycloak-dev] 1.9.0.Beta release
Message-ID: <CAJgngAeGnzWo_PbnAp0GivmLn0xA2SpZ_E_KY6PH41jGRG7iaQ@mail.gmail.com>

We're planning to release 1.9.0.Beta on Thursday morning (my time). I've
moved some issues to 1.9.0.CR1, but there's still some issues left. I also
need help with testing the release tomorrow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160202/385765c4/attachment.html 

From velias at redhat.com  Tue Feb  2 08:15:08 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 2 Feb 2016 14:15:08 +0100
Subject: [keycloak-dev] Office 365
In-Reply-To: <CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
	<CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
	<56A9FC92.4060801@redhat.com>
	<CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>
Message-ID: <56B0ABDC.4050508@redhat.com>

Hi,

I found this description of differences for the two Microsoft account types

http://www.brucebnews.com/2013/04/the-difference-between-a-microsoft-account-and-an-office-365-account/

really tricky in some cases ;-)

Vlastimil

On 28.1.2016 14:58, Jorge Sol?rzano wrote:
> Is Office 365 using something diferent to Microsoft Live?
>
> Keycloak adds support to Microsoft Live in 1.8 CR2, It should work
> with Office 365.
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> On Thu, Jan 28, 2016 at 5:33 AM, Marek Posolda <mposolda at redhat.com
> <mailto:mposolda at redhat.com>> wrote:
>
>     Seems that office365 supports OpenID Connect. In this case, you
>     can try to configure generic "OpenID Connect v1.0" provider in our
>     admin console.
>
>     Marek
>
>     On 28/01/16 10:03, gambol wrote:
>>
>>     Was wondering if anyone has or knows if Keycloak supports adding
>>     office 365 as a identity provider?
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From hcamp at muerte.net  Tue Feb  2 13:38:17 2016
From: hcamp at muerte.net (Harold Campbell)
Date: Tue, 02 Feb 2016 12:38:17 -0600
Subject: [keycloak-dev] servlet-filter-adapter Principal NPE
Message-ID: <1454438297.14955.2.camel@muerte.net>

The servlet-filter-adapter causes an NPE when a user authed either
through Basic or Bearer attempts to retrieve the Principal from the
HttpServletRequest. This is because?completeBearerAuthentication,
unlike?completeOAuthAuthentication, does not add an OidcKeycloakAccount
to the session. If a user is authed via OAuth, everything works fine.

The attached patch against 1.8.x takes care of the problem. It appears
the same problem exists in master, though with files moved around the
patch will not apply directly. This patch makes completeBearer...
essentially identical to completeOAuth..., so for 1.9.x (or indeed
1.8.x if someone wants to redo this) these might oughta be combined
into a single method.

-- 
Harold Campbell <hcamp at muerte.net>



The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost.
		-- S. Kelly-Bootle, "The Devil's DP Dictionary"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-servlet-filter-adapter-completeBearerAuthentication-.patch
Type: text/x-patch
Size: 2643 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160202/357a59f9/attachment-0001.bin 

From bburke at redhat.com  Tue Feb  2 14:41:45 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 2 Feb 2016 14:41:45 -0500
Subject: [keycloak-dev] servlet-filter-adapter Principal NPE
In-Reply-To: <1454438297.14955.2.camel@muerte.net>
References: <1454438297.14955.2.camel@muerte.net>
Message-ID: <56B10679.2060301@redhat.com>

This is fixed in master already.

On 2/2/2016 1:38 PM, Harold Campbell wrote:
> The servlet-filter-adapter causes an NPE when a user authed either
> through Basic or Bearer attempts to retrieve the Principal from the
> HttpServletRequest. This is because completeBearerAuthentication,
> unlike completeOAuthAuthentication, does not add an OidcKeycloakAccount
> to the session. If a user is authed via OAuth, everything works fine.
>
> The attached patch against 1.8.x takes care of the problem. It appears
> the same problem exists in master, though with files moved around the
> patch will not apply directly. This patch makes completeBearer...
> essentially identical to completeOAuth..., so for 1.9.x (or indeed
> 1.8.x if someone wants to redo this) these might oughta be combined
> into a single method.
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Tue Feb  2 14:43:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 2 Feb 2016 14:43:02 -0500
Subject: [keycloak-dev] servlet-filter-adapter Principal NPE
In-Reply-To: <56B10679.2060301@redhat.com>
References: <1454438297.14955.2.camel@muerte.net> <56B10679.2060301@redhat.com>
Message-ID: <56B106C6.2080403@redhat.com>

And FYI...compleOAth and completeBearer should not be identical. 
CompleteOAuth stores things in the HttpSession.  Bearer tokens should 
not be creating an HttpSession.

On 2/2/2016 2:41 PM, Bill Burke wrote:
> This is fixed in master already.
>
> On 2/2/2016 1:38 PM, Harold Campbell wrote:
>> The servlet-filter-adapter causes an NPE when a user authed either
>> through Basic or Bearer attempts to retrieve the Principal from the
>> HttpServletRequest. This is because completeBearerAuthentication,
>> unlike completeOAuthAuthentication, does not add an OidcKeycloakAccount
>> to the session. If a user is authed via OAuth, everything works fine.
>>
>> The attached patch against 1.8.x takes care of the problem. It appears
>> the same problem exists in master, though with files moved around the
>> patch will not apply directly. This patch makes completeBearer...
>> essentially identical to completeOAuth..., so for 1.9.x (or indeed
>> 1.8.x if someone wants to redo this) these might oughta be combined
>> into a single method.
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Tue Feb  2 19:14:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 2 Feb 2016 19:14:51 -0500
Subject: [keycloak-dev] adapter subsystems no longer import dependencies
Message-ID: <56B1467B.3080602@redhat.com>

My latest PR will have:

Previously, if you had installed our saml or oidc keycloak subsystem 
adapters into Wildfly or JBoss EAP, we would
                     automatically include Keycloak client jars into 
EVERY application irregardless if you were using Keycloak or not.
                     These libraries are now only added to your 
deployment if you have keycloak authentication turned on for that adapter
                     (via the subsystem, or auth-method in web.xml

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


From bruno at abstractj.org  Wed Feb  3 06:12:46 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 3 Feb 2016 09:12:46 -0200
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
	<CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
Message-ID: <CAM5SUC4y6iB=nXT9ewpmcjMFCv+xmgs1-JAO_Uk4n5gpzJY08A@mail.gmail.com>

Do you have a JSON file configured? See:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/keycloak.json
?

What about your realm configuration file, looks like this
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L143
?

Not sure if it helps, but at first glance it looks like some
misconfiguration.

On Thu, Jan 28, 2016 at 2:03 PM, Alex Gouv?a Vasconcelos <alexgv99 at gmail.com
> wrote:

> Sorry guys, I'm not sure weather the group receive the answer to Mr. Burke
> question about logs or not...
>
>> ?
>> Do you can an exception stacktrace on app or auth server??
>
> Anyway, there's no log to share, here... the server.log file (in Keycloak
> cluster - 2 instances) doesn't emit any line in the process... and the
> Wildfly (where the app is deployed) just say:
>
>> ?
>> 16:10:23,145 WARN [org.keycloak.adapters.OAuthRequestAuthenticator]
>> ? ?
>> (default task-66) No state cookie?
>
>
> ?So, I hope someone could help me here...
>
> Thanks.?
>
>
> ---------- Forwarded message ----------
> From: Alex Gouv?a Vasconcelos <alexgv99 at gmail.com>
> Date: 2016-01-26 17:16 GMT-02:00
> Subject: Fwd: Bad Request
> To: keycloak-dev at lists.jboss.org
>
>
> Hi guys. I'm running into some trouble here...
>
> I have a very simple application which should authenticate against
> keycloak and return to the main page. This is triggered through the web.xml
> in my application.
>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
>
> <module-name>teste</module-name>
>
> <filter>
> <filter-name>CORSFilter</filter-name>
> <filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>CORSFilter</filter-name>
> <url-pattern>/rest/*</url-pattern>
> </filter-mapping>
>
> <distributable />
>
> <security-constraint>
> <web-resource-collection>
> <web-resource-name>teste</web-resource-name>
> <url-pattern>/rest/exemploService/secure/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> <user-data-constraint>
> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
> </user-data-constraint>
> </security-constraint>
>
> <login-config>
> <auth-method>KEYCLOAK</auth-method>
> <realm-name>realmtest</realm-name>
> </login-config>
> <security-role>
> <role-name>user</role-name>
> </security-role>
> <security-role>
> <role-name>admin</role-name>
> </security-role>
>
> </web-app>
>
>
> The server side has a REST API and the client side is an angular
> application. Everything very simple to just try the development
> environment. What happens is that, after filling the login page and return
> to the index.html (actually it's not returning), I receive a 400 BAD
> REQUEST for the uri:
>
>
> http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1
>
>
> It seems to me, that the malformed URI is because of the ?code=... If I
> reload the page with the same URL, it just return the same 400... if I
> remove the ? portion, it reloads the page and again redirects to and from
> the keycloak server, and recovers the ? portion, repeating the same 400.
>
> I'm running everything in the same application under wildfly 10. Both the
> server and client sides in the same deployed WAR.
>
> I'd appreciate any help.
>
> Best regards.
>
> Alex Gouvea Vasconcelos
>
>
>
>
>
>
>
> [image: Imagem inline 1]
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
- abstractj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160203/d1a92bac/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak.png
Type: image/png
Size: 248184 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160203/d1a92bac/attachment-0001.png 

From parul.com at gmail.com  Thu Feb  4 06:20:30 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Thu, 4 Feb 2016 16:50:30 +0530
Subject: [keycloak-dev] Does keycloak SAML sp support encryption?
Message-ID: <CAFj68vX_q2ynfUnp-xLEtvRB6gfpMBHHjLdsWTAkMJA5fi1JwQ@mail.gmail.com>

I have enabled encryption on keycloak-saml file.. However i dont see any
encryption happened on SAML request.. Similarly. When idp sends encrypted
response, keycloak sp couldn't handle and throwing null pointer exception..
Is it a defect?.. M using HTTP POST binding..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160204/e7ee73a0/attachment.html 

From gambol99 at gmail.com  Thu Feb  4 06:39:58 2016
From: gambol99 at gmail.com (gambol)
Date: Thu, 4 Feb 2016 11:39:58 +0000
Subject: [keycloak-dev] Keycloak Proxy
Message-ID: <CA+AP+fOK74JFL=r+riLr8iauAPK1MByL6m79_H8yPkwSvurR_g@mail.gmail.com>

Hiya

Was looking for feedback, or criticism :-) .. wrote a go keycloak proxy as
part project, part learning assignment ...

https://github.com/gambol99/keycloak-proxy

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

From bburke at redhat.com  Thu Feb  4 09:33:19 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 4 Feb 2016 09:33:19 -0500
Subject: [keycloak-dev] [keycloak-user] Does keycloak SAML sp support
	encryption?
In-Reply-To: <CAFj68vX_q2ynfUnp-xLEtvRB6gfpMBHHjLdsWTAkMJA5fi1JwQ@mail.gmail.com>
References: <CAFj68vX_q2ynfUnp-xLEtvRB6gfpMBHHjLdsWTAkMJA5fi1JwQ@mail.gmail.com>
Message-ID: <56B3612F.9090203@redhat.com>

See this example.  Has to be configured on both sides:

https://github.com/keycloak/keycloak/tree/master/examples/saml/post-with-encryption

SAML encryption encrypts the assertion part of the login response only.  
You MUST and SHOULD still use HTTPS.  SAML encryption isn't a 
replacement for that.

On 2/4/2016 6:20 AM, Arulkumar Ponnusamy wrote:
>
> I have enabled encryption on keycloak-saml file.. However i dont see 
> any encryption happened on SAML request.. Similarly. When idp sends 
> encrypted response, keycloak sp couldn't handle and throwing null 
> pointer exception.. Is it a defect?.. M using HTTP POST binding..
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Thu Feb  4 09:36:17 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 4 Feb 2016 09:36:17 -0500
Subject: [keycloak-dev] Keycloak Proxy
In-Reply-To: <CA+AP+fOK74JFL=r+riLr8iauAPK1MByL6m79_H8yPkwSvurR_g@mail.gmail.com>
References: <CA+AP+fOK74JFL=r+riLr8iauAPK1MByL6m79_H8yPkwSvurR_g@mail.gmail.com>
Message-ID: <56B361E1.4030609@redhat.com>

Too bad you just didn't expand Keycloak Java Proxy ;)  we actually need 
somebody giving it some love although with mod-auth-mellon and 
mod-auth-oidc, I'm not sure how popular it will ever be.

A GO client adapter would be even more cool.

On 2/4/2016 6:39 AM, gambol wrote:
> Hiya
>
> Was looking for feedback, or criticism :-) .. wrote a go keycloak 
> proxy as part project, part learning assignment ...
>
> https://github.com/gambol99/keycloak-proxy
>
> Rohith
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Thu Feb  4 10:12:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 4 Feb 2016 16:12:27 +0100
Subject: [keycloak-dev] Keycloak 1.8.1.Final and 1.9.0.CR1 released
Message-ID: <CAJgngAf2+_pk70inBAdeasK=qwu05zbbFRa0CWTMZuzfaf8wyg@mail.gmail.com>

Today we have two releases. As 1.8.0.Final was released before WildFly 10
Final was available, we decided to release 1.8.1.Final which is now built
on top of WildFly 10 Final.

The bigger release today is 1.9.0.CR1, this release contains a large number
of bug fixes and improvements, but no major new features.

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

From gambol99 at gmail.com  Thu Feb  4 10:32:41 2016
From: gambol99 at gmail.com (gambol)
Date: Thu, 4 Feb 2016 15:32:41 +0000
Subject: [keycloak-dev] Keycloak Proxy
In-Reply-To: <56B361E1.4030609@redhat.com>
References: <CA+AP+fOK74JFL=r+riLr8iauAPK1MByL6m79_H8yPkwSvurR_g@mail.gmail.com>
	<56B361E1.4030609@redhat.com>
Message-ID: <CA+AP+fPvHstMm3q+_42az=F2Mr1fdWtFvUTaGmOAuhOXScOgcg@mail.gmail.com>

Would have loved to, though my Java is somewhat lacking these days. Looked
at mod-auth-{oidc,mellon} and oauth2-proxy but didn't see how these would
support roles? ...

On Thu, Feb 4, 2016 at 2:36 PM, Bill Burke <bburke at redhat.com> wrote:

> Too bad you just didn't expand Keycloak Java Proxy ;)  we actually need
> somebody giving it some love although with mod-auth-mellon and
> mod-auth-oidc, I'm not sure how popular it will ever be.
>
> A GO client adapter would be even more cool.
>
>
> On 2/4/2016 6:39 AM, gambol wrote:
>
> Hiya
>
> Was looking for feedback, or criticism :-) .. wrote a go keycloak proxy as
> part project, part learning assignment ...
>
> https://github.com/gambol99/keycloak-proxy
>
> Rohith
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160204/e9d18de1/attachment.html 

From gambol99 at gmail.com  Thu Feb  4 12:10:15 2016
From: gambol99 at gmail.com (gambol)
Date: Thu, 4 Feb 2016 17:10:15 +0000
Subject: [keycloak-dev] Keycloak Proxy
In-Reply-To: <CA+AP+fPvHstMm3q+_42az=F2Mr1fdWtFvUTaGmOAuhOXScOgcg@mail.gmail.com>
References: <CA+AP+fOK74JFL=r+riLr8iauAPK1MByL6m79_H8yPkwSvurR_g@mail.gmail.com>
	<56B361E1.4030609@redhat.com>
	<CA+AP+fPvHstMm3q+_42az=F2Mr1fdWtFvUTaGmOAuhOXScOgcg@mail.gmail.com>
Message-ID: <CA+AP+fPURP2HC3N_vVHFhEDwv27pxcAOBj1EQcZLg6prGDqShg@mail.gmail.com>

The solution were working towards though is an lua extension to Kong to
perform the url / role constraints similar to the proxy, integrated with
kubernetes service annotations or third party resources for per service
config.

On Thu, Feb 4, 2016 at 3:32 PM, gambol <gambol99 at gmail.com> wrote:

> Would have loved to, though my Java is somewhat lacking these days. Looked
> at mod-auth-{oidc,mellon} and oauth2-proxy but didn't see how these would
> support roles? ...
>
> On Thu, Feb 4, 2016 at 2:36 PM, Bill Burke <bburke at redhat.com> wrote:
>
>> Too bad you just didn't expand Keycloak Java Proxy ;)  we actually need
>> somebody giving it some love although with mod-auth-mellon and
>> mod-auth-oidc, I'm not sure how popular it will ever be.
>>
>> A GO client adapter would be even more cool.
>>
>>
>> On 2/4/2016 6:39 AM, gambol wrote:
>>
>> Hiya
>>
>> Was looking for feedback, or criticism :-) .. wrote a go keycloak proxy
>> as part project, part learning assignment ...
>>
>> https://github.com/gambol99/keycloak-proxy
>>
>> Rohith
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160204/af4c85aa/attachment-0001.html 

From alexander.schwartz at gmx.net  Fri Feb  5 03:29:27 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Fri, 5 Feb 2016 09:29:27 +0100
Subject: [keycloak-dev] Docker image for Wildfly 10 with Keycloak Client
Message-ID: <trinity-2fc38e35-4f1f-4d6b-a735-38bbe9e712b2-1454660967168@3capp-gmx-bs46>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160205/3b245ccd/attachment.html 

From sthorger at redhat.com  Fri Feb  5 04:30:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 5 Feb 2016 10:30:06 +0100
Subject: [keycloak-dev] Docker image for Wildfly 10 with Keycloak Client
In-Reply-To: <trinity-2fc38e35-4f1f-4d6b-a735-38bbe9e712b2-1454660967168@3capp-gmx-bs46>
References: <trinity-2fc38e35-4f1f-4d6b-a735-38bbe9e712b2-1454660967168@3capp-gmx-bs46>
Message-ID: <CAJgngAfEqBQUpxK5Bc4_F8=qps3v8gNLhZucbCgnZBLci1QJTw@mail.gmail.com>

We'll switch to WildFly 10 and a PR would be welcome.

On 5 February 2016 at 09:29, Alexander Schwartz <alexander.schwartz at gmx.net>
wrote:

> Hello Devs,
>
> I see that docker image for client development is based on Wildfly 9
>
> https://github.com/jboss-dockerfiles/keycloak/tree/master/adapter-wildfly
>
> I wonder if you want this to be switched to Wildfly 10, or if you want to
> have separate folder named adapter-wildfly10.
>
> I am happy to prepare a pull request.
>
> Best regards,
> Alexander
>
> --
> Alexander Schwartz (alexander.schwartz at gmx.net)
> http://www.ahus1.de
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160205/bb6b27e7/attachment.html 

From Vikas.Nagaraj at safenet-inc.com  Mon Feb  8 13:47:28 2016
From: Vikas.Nagaraj at safenet-inc.com (Nagaraj,Vikas)
Date: Mon, 8 Feb 2016 13:47:28 -0500
Subject: [keycloak-dev] Protecting/encrypting realm keys
Message-ID: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>

Hello,

We've been integrating Keycloak into one of our applications, and so far it's been a pretty good experience.  I'm looking now at how realms' signing keys are protected.  Currently Keycloak stores the private key in a database table, but we'd like to explore protecting it with a Hardware Security Module (HSM).

A couple of years ago there was a discussion on this list on this topic (thread starts here: https://lists.jboss.org/pipermail/keycloak-dev/2014-January/001124.html).  One suggestion was to have an EncryptionSpi interface that could be overridden to provide the desired crypto operations; another was to use a master key sourced from somewhere outside the DB to encrypt the private keys stored with the realm.  Has there been any discussion about either of these alternatives since?

I'm happy to help with the implementation, but would appreciate some guidance from more experienced Keycloak devs on the best way to go about it.

Thanks,

--
Vikas Nagaraj
vikas.nagaraj at safenet-inc.com<mailto:vikas.nagaraj at safenet-inc.com>




-- 
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.

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

From sthorger at redhat.com  Mon Feb  8 14:08:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 8 Feb 2016 20:08:42 +0100
Subject: [keycloak-dev] Protecting/encrypting realm keys
In-Reply-To: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
References: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
Message-ID: <CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>

We have briefly discussed HSM some more, but as you are the first to ask
about it we haven't made it a priority. We would certainly be interested in
a contribution towards it. It's a fairly big task and we would also need
decent test coverage for it.

In essence the work would be to create a Encryption SPI and a default
implementation. The default implementation would rely on the keys stored in
the database. I'm not aware of any standard or libraries that can be used
to communicate with HSM devices so I would imagine implementations for
specific HSM vendors would have to be done by users themselves.

As well as encryption/signature methods you would also have to deal with
how to retrieve the public key to display in the admin console and the
providers would also have to be able to tell Keycloak if they can generate
new keys or not. For providers that can generate new keys we would have the
option on the admin console to generate new realm keys, but for others not.

If you are interested let us know. As a heads up this could not be included
until 2.x.


On 8 February 2016 at 19:47, Nagaraj,Vikas <Vikas.Nagaraj at safenet-inc.com>
wrote:

> Hello,
>
> We?ve been integrating Keycloak into one of our applications, and so far
> it?s been a pretty good experience.  I?m looking now at how realms? signing
> keys are protected.  Currently Keycloak stores the private key in a
> database table, but we?d like to explore protecting it with a Hardware
> Security Module (HSM).
>
> A couple of years ago there was a discussion on this list on this topic
> (thread starts here:
> *https://lists.jboss.org/pipermail/keycloak-dev/2014-January/001124.html*
> <https://lists.jboss.org/pipermail/keycloak-dev/2014-January/001124.html>).
> One suggestion was to have an EncryptionSpi interface that could be
> overridden to provide the desired crypto operations; another was to use a
> master key sourced from somewhere outside the DB to encrypt the private
> keys stored with the realm.  Has there been any discussion about either of
> these alternatives since?
>
> I?m happy to help with the implementation, but would appreciate some
> guidance from more experienced Keycloak devs on the best way to go about it.
>
> Thanks,
>
> --
> Vikas Nagaraj
> *vikas.nagaraj at safenet-inc.com* <vikas.nagaraj at safenet-inc.com>
>
>
>
>
> The information contained in this electronic mail transmission
> may be privileged and confidential, and therefore, protected
> from disclosure. If you have received this communication in
> error, please notify us immediately by replying to this
> message and deleting it from your computer without copying
> or disclosing it.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160208/5ccfac39/attachment.html 

From jdennis at redhat.com  Tue Feb  9 09:40:38 2016
From: jdennis at redhat.com (John Dennis)
Date: Tue, 9 Feb 2016 09:40:38 -0500
Subject: [keycloak-dev] Protecting/encrypting realm keys
In-Reply-To: <CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>
References: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
	<CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>
Message-ID: <56B9FA66.9020805@redhat.com>

On 02/08/2016 02:08 PM, Stian Thorgersen wrote:
> In essence the work would be to create a Encryption SPI and a default
> implementation. The default implementation would rely on the keys stored
> in the database. I'm not aware of any standard or libraries that can be
> used to communicate with HSM devices so I would imagine implementations
> for specific HSM vendors would have to be done by users themselves.

There are C libraries to support HSM devices. I think the big question 
would be if they are Linux specific or not or if there are Java 
bindings. I know the Certificate Server (i.e. Dogtag) that Red Hat ships 
is written in Java and has HSM support. I also believe some of this is 
in transition. I would suggest a conversation with Ade Lee 
(alee at redhat.com) who would have more detailed information.

HTH,

-- 
John

From Vikas.Nagaraj at safenet-inc.com  Tue Feb  9 12:56:09 2016
From: Vikas.Nagaraj at safenet-inc.com (Nagaraj,Vikas)
Date: Tue, 9 Feb 2016 12:56:09 -0500
Subject: [keycloak-dev] Protecting/encrypting realm keys
In-Reply-To: <56B9FA66.9020805@redhat.com>
References: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
	<CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>
	<56B9FA66.9020805@redhat.com>
Message-ID: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC09D2@BEL1EXCH02.amer.sfnt.local>

Hi John,

The SafeNet HSM has Java bindings via the JCE interface, as does Thales.  I know less about HSMs from other vendors, but I believe most of them support Java via the Pkcs11Provider.

--vikas

-----Original Message-----
From: John Dennis [mailto:jdennis at redhat.com] 
Sent: February-09-16 9:41 AM
To: stian at redhat.com; Nagaraj,Vikas
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Protecting/encrypting realm keys

There are C libraries to support HSM devices. I think the big question would be if they are Linux specific or not or if there are Java bindings. I know the Certificate Server (i.e. Dogtag) that Red Hat ships is written in Java and has HSM support. I also believe some of this is in transition. I would suggest a conversation with Ade Lee
(alee at redhat.com) who would have more detailed information.

HTH,

-- 
John

-- 
The information contained in this electronic mail transmission 
may be privileged and confidential, and therefore, protected 
from disclosure. If you have received this communication in 
error, please notify us immediately by replying to this 
message and deleting it from your computer without copying 
or disclosing it.



From thomas.darimont at googlemail.com  Tue Feb  9 17:48:26 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 9 Feb 2016 23:48:26 +0100
Subject: [keycloak-dev] Script based Authenticators
Message-ID: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>

Hello group,

I built a little prototype [0] for script based authenticators inspired by
a discussion on the keycloak-users mailing list -
think it was about post broker authentication checks, e.g. if the user has
an email address that belongs to the google apps domain...

I introduced a ScriptBasedAuthenticator that is bootstraped via a
ScriptBasedAuthenticatorFactory can be execute a configured script
via a JSR-223 ScriptEngine against a provided execution context.

I also added a new "script" value type for proper rendering in the UI as
well as an alias property
to the AuthFlowExecutionRepresentation in order to be able to differentiate
multiple instances of an Authenticator
within the same AuthFlow - this comes pretty close to having Auth0  like
scriptable rules in Keycloak.

For convenient editing I added the AngularJS bindings for the popular ACE
editor.

Looking forward to your thoughts :)

Cheers,
Thomas

[0]
https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62
[1] https://auth0.com/docs/rules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160209/9fbd7dba/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak-script-authenticator.png
Type: image/png
Size: 39402 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160209/9fbd7dba/attachment-0001.png 

From bburke at redhat.com  Wed Feb 10 00:12:59 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 00:12:59 -0500
Subject: [keycloak-dev] Script based Authenticators
In-Reply-To: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>
References: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>
Message-ID: <56BAC6DB.1070806@redhat.com>

This is really cool.

On 2/9/2016 5:48 PM, Thomas Darimont wrote:
> Hello group,
>
> I built a little prototype [0] for script based authenticators 
> inspired by a discussion on the keycloak-users mailing list -
> think it was about post broker authentication checks, e.g. if the user 
> has an email address that belongs to the google apps domain...
>
> I introduced a ScriptBasedAuthenticator that is bootstraped via a
> ScriptBasedAuthenticatorFactory can be execute a configured script
> via a JSR-223 ScriptEngine against a provided execution context.
>
> I also added a new "script" value type for proper rendering in the UI 
> as well as an alias property
> to the AuthFlowExecutionRepresentation in order to be able to 
> differentiate multiple instances of an Authenticator
> within the same AuthFlow - this comes pretty close to having Auth0 
>  like scriptable rules in Keycloak.
>
> For convenient editing I added the AngularJS bindings for the popular 
> ACE editor.
>
> Looking forward to your thoughts :)
>
> Cheers,
> Thomas
>
> [0] 
> https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62
> [1] https://auth0.com/docs/rules
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Wed Feb 10 03:45:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 09:45:20 +0100
Subject: [keycloak-dev] Script based Authenticators
In-Reply-To: <56BAC6DB.1070806@redhat.com>
References: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>
	<56BAC6DB.1070806@redhat.com>
Message-ID: <CAJgngAcA8Y1Hg0J5Hn_fZUd3ye5MZafbqRzfdRFrHKkVGmjzjA@mail.gmail.com>

+1 This is very nice

We can't accept this for 1.9.x, but would love to include it in 2.0 if you
can complete the work. We'll create a branch for 1.9.x very soon, once
that's done we can start accepting PRs for 2.0.

Would be great if you carry on work on this feature and do a PR. We'd need
tests as well as documentation, it would also be good with some examples.

BTW could you give us some step-by-step instructions on how to try it out?
I'm to lazy/busy to figure it out on my own.

On 10 February 2016 at 06:12, Bill Burke <bburke at redhat.com> wrote:

> This is really cool.
>
>
> On 2/9/2016 5:48 PM, Thomas Darimont wrote:
>
> Hello group,
>
> I built a little prototype [0] for script based authenticators inspired by
> a discussion on the keycloak-users mailing list -
> think it was about post broker authentication checks, e.g. if the user has
> an email address that belongs to the google apps domain...
>
> I introduced a ScriptBasedAuthenticator that is bootstraped via a
> ScriptBasedAuthenticatorFactory can be execute a configured script
> via a JSR-223 ScriptEngine against a provided execution context.
>
> I also added a new "script" value type for proper rendering in the UI as
> well as an alias property
> to the AuthFlowExecutionRepresentation in order to be able to
> differentiate multiple instances of an Authenticator
> within the same AuthFlow - this comes pretty close to having Auth0  like
> scriptable rules in Keycloak.
>
> For convenient editing I added the AngularJS bindings for the popular ACE
> editor.
>
> Looking forward to your thoughts :)
>
> Cheers,
> Thomas
>
> [0]
> https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62
> [1] https://auth0.com/docs/rules
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160210/5d2ba538/attachment.html 

From dsnoeck at gmail.com  Wed Feb 10 04:35:34 2016
From: dsnoeck at gmail.com (Damien Snoeck)
Date: Wed, 10 Feb 2016 09:35:34 +0000
Subject: [keycloak-dev] Define realm in login
Message-ID: <CA+SRm31ceMcmWpX_fb==YdBc0N9xTp1PEQE2WDCuggb_2v8w0g@mail.gmail.com>

In an angularJS webapp, I have integrated the keycloak adapter. When users
want to access the webapp they are redirected to the keycloak login screen
for a defined realm. But this webapp will be use by several realm.
What would be the best way to let users provide its realm during login
process ?

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

From sthorger at redhat.com  Wed Feb 10 04:57:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 10:57:48 +0100
Subject: [keycloak-dev] Define realm in login
In-Reply-To: <CA+SRm31ceMcmWpX_fb==YdBc0N9xTp1PEQE2WDCuggb_2v8w0g@mail.gmail.com>
References: <CA+SRm31ceMcmWpX_fb==YdBc0N9xTp1PEQE2WDCuggb_2v8w0g@mail.gmail.com>
Message-ID: <CAJgngAfsuCYz+_ZERNKLXsH9Lqt6J2LwhdSc0jnwZemdy8b2bQ@mail.gmail.com>

Selecting realm is something you'd have to implement in your application. I
assume you would want to select realm based on URL rather than having users
select manually.

BTW our JavaEE adapters have support for using different realms and it's up
to the user to implement the mechanism that selects the correct realm. Take
a look at
https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant

On 10 February 2016 at 10:35, Damien Snoeck <dsnoeck at gmail.com> wrote:

> In an angularJS webapp, I have integrated the keycloak adapter. When users
> want to access the webapp they are redirected to the keycloak login screen
> for a defined realm. But this webapp will be use by several realm.
> What would be the best way to let users provide its realm during login
> process ?
>
> - Damien
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160210/5204d095/attachment.html 

From dsnoeck at gmail.com  Wed Feb 10 05:17:29 2016
From: dsnoeck at gmail.com (Damien Snoeck)
Date: Wed, 10 Feb 2016 10:17:29 +0000
Subject: [keycloak-dev] Define realm in login
In-Reply-To: <CAJgngAfsuCYz+_ZERNKLXsH9Lqt6J2LwhdSc0jnwZemdy8b2bQ@mail.gmail.com>
References: <CA+SRm31ceMcmWpX_fb==YdBc0N9xTp1PEQE2WDCuggb_2v8w0g@mail.gmail.com>
	<CAJgngAfsuCYz+_ZERNKLXsH9Lqt6J2LwhdSc0jnwZemdy8b2bQ@mail.gmail.com>
Message-ID: <CA+SRm3194=c5_c9HLCM09MD-j=xY-evJfesgnWVQrn6bvdmGzA@mail.gmail.com>

Would it be possible to customize the keycloak login form by adding a third
field for the realm ?
Otherwise, is there a way to create a custom login form in my webapp with
those 3 fields and call a keycloak service ?
Le mer. 10 f?vr. 2016 ? 10:57, Stian Thorgersen <sthorger at redhat.com> a
?crit :

> Selecting realm is something you'd have to implement in your application.
> I assume you would want to select realm based on URL rather than having
> users select manually.
>
> BTW our JavaEE adapters have support for using different realms and it's
> up to the user to implement the mechanism that selects the correct realm.
> Take a look at
> https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant
>
> On 10 February 2016 at 10:35, Damien Snoeck <dsnoeck at gmail.com> wrote:
>
>> In an angularJS webapp, I have integrated the keycloak adapter. When
>> users want to access the webapp they are redirected to the keycloak login
>> screen for a defined realm. But this webapp will be use by several realm.
>> What would be the best way to let users provide its realm during login
>> process ?
>>
>> - Damien
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160210/77f94e48/attachment-0001.html 

From thomas.darimont at googlemail.com  Wed Feb 10 06:19:39 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 10 Feb 2016 12:19:39 +0100
Subject: [keycloak-dev] Script based Authenticators
In-Reply-To: <CAJgngAcA8Y1Hg0J5Hn_fZUd3ye5MZafbqRzfdRFrHKkVGmjzjA@mail.gmail.com>
References: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>
	<56BAC6DB.1070806@redhat.com>
	<CAJgngAcA8Y1Hg0J5Hn_fZUd3ye5MZafbqRzfdRFrHKkVGmjzjA@mail.gmail.com>
Message-ID: <CAK-7U1i2Uj+HNyZLSRwcAdY-UeBFCRAXi0+ddLw0BshKx7EFRA@mail.gmail.com>

Thanks :)


Sorry for the rather long mail - steps to demo are first, for some
additional thoughts see below.

Is there any chance of having a 1.10.x release line?

if you want to try it out you could apply this patch against a new branch
from current master:

https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62.patch

then just start the org.keycloak.testsuite.KeycloakServer.

In the admin-console you need to do the following:

1) copy the browser authentication flow to "browser script"

2) in the "browser script forms" subflow click on Actions -> Add execution

3) select "Script based authentication" from the list

4) Mark "Script based authentication" as required

5) configure "Script based authentication" via actions -> config

6) as config parameters use

Alias: auth-tracer-script (this is later shown in the auth flow listing)

Script Engine: Nashorn

ScriptName: auth-tracer

Script:

function authenticate(context){



 LOG.info(scriptName + " --> trace auth for: " + user.username);

 context.success();

}

function action(context){

 context.attempted();

}

7) Save the authenticator

8) Goto bindings tab and set the browser flow to "browser script".

9) end.

I usually create a test user to play with this.

I'm keen to get this done since we need to be rather flexible regarding
auth logic.

Btw. the Auth0 rules repository is a great example for what can be done
with this feature:

https://github.com/auth0/rules

Some things to consider:

# Use cases

I think scripting should not only be applied for authenticators but also
for other components like: event listeners, federation-providers, even
custom user action scripts that are performed on login / logout / account /
profile updates also configurable validation scripts would be helpful.

https://issues.jboss.org/browse/KEYCLOAK-1872?jql=project%20%3D%20KEYCLOAK%20AND%20text%20~%20%22forgerock%22

# Implementation

In my naive implementation I just externalized the authenticate(..) and
action(..) method.

I think it might be easier for users to have dedicated scriptable
authenticators (or rather authentication steps? since they only participate
in the authentication but might not decide or authenticate anything...)
e.g. ones that just perform some enrichment of the user model, additional
tracing etc. others could be more complex by conditionally showing forms,
using the providers to send codes (email, sms) etc.

In my POC I exposed a bunch of context variables to the script:

https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62#diff-50db206e6dcd6842014f5be864e6c895R89

One should either be very selective here or just hand in securable wrappers
that would allow to control access from scripts to context objects.

Allowing users to writing / editing scripts in the admin frontend is great
but it would be more helpful if those scripts could be loaded from an
external directory that would allow a proper versioning of the scripts
outside of keycloak.

Having a ScriptingProvider capable of loading / saving scripts and
executing scripts against a provided context would be useful. Within the
scriptable components one would then just refer to a script from a ?Script
Repository?.

A script should have metadata like a script name, comment, script source,
perhaps vcs information.

# Security

Offering scripting support of course opens the door to all kind of bad
things - I don?t think that my initial assumption ?scripts will probably
only be specified by administrators and executed on the server?? will hold
for long ;-)

Soner or later one probably needs some sort of sandbox concept here - the
Auht0 guys do this:

?For security reasons, the Rules code runs in a JavaScript sandbox based on
webtask.io where you can use the full power of the ECMAScript 5 language.

For a list of currently supported sandbox modules, see: Modules Supported
by the Sandbox.?

# UX for Script Support

I think users needs both syntax highlighting and linenumbers for readable
scripts both are provided by the currently used ace editor (
https://ace.c9.io/#nav=about )- another popular option would have been
codemirror (http://codemirror.net/) but personally I found it easier to
integrate ace.

Within the admin console it should be possible to view a script in
read-only mode - perhaps this should be the default when opening a
component like an authenticator. editing should be enabled via a checkbox
or on/off-switch.

The ace editor support could be used to render a highlighted (read-only)
version of JSON (client install) and XML (SAML) configuration.

We need to find a way to parameterize the ace editor for various other
"script" types to get proper highlighting (used in kc-provider-config.html
-> mode: xxxx) - perhaps? code? would be a more generic type than "script".

It would really help to have some server-side validation being performed on
save of an authenticator (or any other object), validation errors should be
propagated to the frontend and shown near the "culprit".

# Documentation

The user guide should include a section about scripting support in general.

Some examples should show the usage of scripting support, e.g. an
authenticator, an event listener.


Cheers,

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

From sthorger at redhat.com  Wed Feb 10 06:47:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 12:47:09 +0100
Subject: [keycloak-dev] Script based Authenticators
In-Reply-To: <CAK-7U1i2Uj+HNyZLSRwcAdY-UeBFCRAXi0+ddLw0BshKx7EFRA@mail.gmail.com>
References: <CAK-7U1gPhv8O-Fzicsu0_6n2-+v2W_Qnw+m+0WL32iAw0Zokkg@mail.gmail.com>
	<56BAC6DB.1070806@redhat.com>
	<CAJgngAcA8Y1Hg0J5Hn_fZUd3ye5MZafbqRzfdRFrHKkVGmjzjA@mail.gmail.com>
	<CAK-7U1i2Uj+HNyZLSRwcAdY-UeBFCRAXi0+ddLw0BshKx7EFRA@mail.gmail.com>
Message-ID: <CAJgngAe3QKORiV+vG=ij6R8WJ_q4pCbG+KjvRe014BJrjvnVSA@mail.gmail.com>

Thanks, I'll take a look at it when I get a chance. Although from your
screenshot it looks very nice indeed.

1.9 is going to be the last release in 1.x and we'll move on to 2.0
afterwards, so afraid this will have to wait for 2.0.

On 10 February 2016 at 12:19, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Thanks :)
>
>
> Sorry for the rather long mail - steps to demo are first, for some
> additional thoughts see below.
>
> Is there any chance of having a 1.10.x release line?
>
> if you want to try it out you could apply this patch against a new branch
> from current master:
>
>
> https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62.patch
>
> then just start the org.keycloak.testsuite.KeycloakServer.
>
> In the admin-console you need to do the following:
>
> 1) copy the browser authentication flow to "browser script"
>
> 2) in the "browser script forms" subflow click on Actions -> Add execution
>
> 3) select "Script based authentication" from the list
>
> 4) Mark "Script based authentication" as required
>
> 5) configure "Script based authentication" via actions -> config
>
> 6) as config parameters use
>
> Alias: auth-tracer-script (this is later shown in the auth flow listing)
>
> Script Engine: Nashorn
>
> ScriptName: auth-tracer
>
> Script:
>
> function authenticate(context){
>
>
>
>  LOG.info(scriptName + " --> trace auth for: " + user.username);
>
>  context.success();
>
> }
>
> function action(context){
>
>  context.attempted();
>
> }
>
> 7) Save the authenticator
>
> 8) Goto bindings tab and set the browser flow to "browser script".
>
> 9) end.
>
> I usually create a test user to play with this.
>
> I'm keen to get this done since we need to be rather flexible regarding
> auth logic.
>
> Btw. the Auth0 rules repository is a great example for what can be done
> with this feature:
>
> https://github.com/auth0/rules
>
> Some things to consider:
>
> # Use cases
>
> I think scripting should not only be applied for authenticators but also
> for other components like: event listeners, federation-providers, even
> custom user action scripts that are performed on login / logout / account /
> profile updates also configurable validation scripts would be helpful.
>
>
> https://issues.jboss.org/browse/KEYCLOAK-1872?jql=project%20%3D%20KEYCLOAK%20AND%20text%20~%20%22forgerock%22
>
> # Implementation
>
> In my naive implementation I just externalized the authenticate(..) and
> action(..) method.
>
> I think it might be easier for users to have dedicated scriptable
> authenticators (or rather authentication steps? since they only participate
> in the authentication but might not decide or authenticate anything...)
> e.g. ones that just perform some enrichment of the user model, additional
> tracing etc. others could be more complex by conditionally showing forms,
> using the providers to send codes (email, sms) etc.
>
> In my POC I exposed a bunch of context variables to the script:
>
>
> https://github.com/thomasdarimont/keycloak/commit/3f39479e7fa0c75941cd524ba99de5c85db43b62#diff-50db206e6dcd6842014f5be864e6c895R89
>
> One should either be very selective here or just hand in securable
> wrappers that would allow to control access from scripts to context objects.
>
> Allowing users to writing / editing scripts in the admin frontend is great
> but it would be more helpful if those scripts could be loaded from an
> external directory that would allow a proper versioning of the scripts
> outside of keycloak.
>
> Having a ScriptingProvider capable of loading / saving scripts and
> executing scripts against a provided context would be useful. Within the
> scriptable components one would then just refer to a script from a ?Script
> Repository?.
>
> A script should have metadata like a script name, comment, script source,
> perhaps vcs information.
>
> # Security
>
> Offering scripting support of course opens the door to all kind of bad
> things - I don?t think that my initial assumption ?scripts will probably
> only be specified by administrators and executed on the server?? will hold
> for long ;-)
>
> Soner or later one probably needs some sort of sandbox concept here - the
> Auht0 guys do this:
>
> ?For security reasons, the Rules code runs in a JavaScript sandbox based
> on webtask.io where you can use the full power of the ECMAScript 5
> language.
>
> For a list of currently supported sandbox modules, see: Modules Supported
> by the Sandbox.?
>
> # UX for Script Support
>
> I think users needs both syntax highlighting and linenumbers for readable
> scripts both are provided by the currently used ace editor (
> https://ace.c9.io/#nav=about )- another popular option would have been
> codemirror (http://codemirror.net/) but personally I found it easier to
> integrate ace.
>
> Within the admin console it should be possible to view a script in
> read-only mode - perhaps this should be the default when opening a
> component like an authenticator. editing should be enabled via a checkbox
> or on/off-switch.
>
> The ace editor support could be used to render a highlighted (read-only)
> version of JSON (client install) and XML (SAML) configuration.
>
> We need to find a way to parameterize the ace editor for various other
> "script" types to get proper highlighting (used in kc-provider-config.html
> -> mode: xxxx) - perhaps? code? would be a more generic type than "script".
>
> It would really help to have some server-side validation being performed
> on save of an authenticator (or any other object), validation errors should
> be propagated to the frontend and shown near the "culprit".
>
> # Documentation
>
> The user guide should include a section about scripting support in
> general.
>
> Some examples should show the usage of scripting support, e.g. an
> authenticator, an event listener.
>
>
> Cheers,
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160210/36b49475/attachment-0001.html 

From sthorger at redhat.com  Wed Feb 10 06:50:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 10 Feb 2016 12:50:01 +0100
Subject: [keycloak-dev] Define realm in login
In-Reply-To: <CA+SRm3194=c5_c9HLCM09MD-j=xY-evJfesgnWVQrn6bvdmGzA@mail.gmail.com>
References: <CA+SRm31ceMcmWpX_fb==YdBc0N9xTp1PEQE2WDCuggb_2v8w0g@mail.gmail.com>
	<CAJgngAfsuCYz+_ZERNKLXsH9Lqt6J2LwhdSc0jnwZemdy8b2bQ@mail.gmail.com>
	<CA+SRm3194=c5_c9HLCM09MD-j=xY-evJfesgnWVQrn6bvdmGzA@mail.gmail.com>
Message-ID: <CAJgngAf5PJmv4q4jkoWY1LE9dich3CHrrcejbKyKJxMdO1_3sA@mail.gmail.com>

No, that would not be possible. A realm contains the configuration for the
client, theme, authentication flows and a number of other things that are
required to process the login.

It would have to be something else and have to be select prior to the login
page could be shown.

An alternative which may work for you is that you have a login realm that
adds a identity broker to the other realms. Then users can login to the
"login" realm from any other realm and your client only has to deal with
one realm.

On 10 February 2016 at 11:17, Damien Snoeck <dsnoeck at gmail.com> wrote:

> Would it be possible to customize the keycloak login form by adding a
> third field for the realm ?
> Otherwise, is there a way to create a custom login form in my webapp with
> those 3 fields and call a keycloak service ?
>
> Le mer. 10 f?vr. 2016 ? 10:57, Stian Thorgersen <sthorger at redhat.com> a
> ?crit :
>
>> Selecting realm is something you'd have to implement in your application.
>> I assume you would want to select realm based on URL rather than having
>> users select manually.
>>
>> BTW our JavaEE adapters have support for using different realms and it's
>> up to the user to implement the mechanism that selects the correct realm.
>> Take a look at
>> https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant
>>
>> On 10 February 2016 at 10:35, Damien Snoeck <dsnoeck at gmail.com> wrote:
>>
>>> In an angularJS webapp, I have integrated the keycloak adapter. When
>>> users want to access the webapp they are redirected to the keycloak login
>>> screen for a defined realm. But this webapp will be use by several realm.
>>> What would be the best way to let users provide its realm during login
>>> process ?
>>>
>>> - Damien
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160210/1e6b3ef2/attachment.html 

From bburke at redhat.com  Wed Feb 10 11:16:21 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 11:16:21 -0500
Subject: [keycloak-dev] avoiding extra sql
Message-ID: <56BB6255.9030805@redhat.com>

FYI:

In some places like getClientById, we check the passed in 
RealmModel.getId() against ClientEntity.getRealm().getId() to make sure 
its the same realm.  This causes an extra SELECT query on the realm.  To 
avoid this, you can set the access to the primary key to property and 
the id will be obtained only without a sql query.

public class RealmEntity {
     @Id
     @Column(name="ID", length = 36)
     @Access(AccessType.PROPERTY)
     protected String id;

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


From jdennis at redhat.com  Wed Feb 10 13:18:57 2016
From: jdennis at redhat.com (John Dennis)
Date: Wed, 10 Feb 2016 13:18:57 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <569CE2D9.4090507@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
	<1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
	<5698FBE9.10406@redhat.com>
	<939885315.18350804.1453114681307.JavaMail.zimbra@redhat.com>
	<569CE2D9.4090507@redhat.com>
Message-ID: <56BB7F11.8000208@redhat.com>

On 01/18/2016 08:04 AM, Bill Burke wrote:
> Make sure that the SP and IDP metadata files both have a post binding in
> there for single logout service.  That's the only thing I can think of.
> Maybe mellon just doesn't support it.  The example file in the mellon
> doc uses redirect for logout.  *shrug*

Bill:

mod_auth_mellon *only* supports the HTTP-Redirect binding for issuing 
logout requests to the IdP. The reason is simple, mellon as an apache 
module does not have a mechanism for POST'ing a request to another 
location while it's processing a request. As such it relies on redirects 
to get the logout request to the IdP.

The problem is the metadata returned by Keycloak only includes a 
SingleLogoutService with the HTTP-POST binding.

Others have tested changing the binding in the IdP metdata to 
HTTP-Redirect and retaining the same URL endpoint (see below and others 
have done the same). It works. Therefore it seems like there is no 
reason for Keycloak not to support SingleLogoutService with the 
HTTP-Redirect binding. Seems like this would be a trivial edit to the 
metadata generator.

Agreed? Should we open a bug?

John


>
> On 1/18/2016 5:58 AM, Michal Hajas wrote:
>> Maybe I configured something wrongly. Do you have any ideas what? Mellon somehow thinks that keycloak doesn't support it so he doesn't even try.
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, January 15, 2016 3:02:17 PM
>> Subject: Re: [keycloak-dev] mod_auth_mellon
>>
>> Looks like its on the auth mellon side as I don't see any request after:
>> /mellon/logout?ReturnTo=/
>>
>>
>>
>> On 1/15/2016 3:57 AM, Michal Hajas wrote:
>>
>>
>>
>> I can't see anything even in console log.
>>
>> I enclosed whole proccess of login and logout in network tab.
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com> To: "Michal Hajas" <mhajas at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Thursday, January 14, 2016 5:01:30 PM
>> Subject: Re: [keycloak-dev] mod_auth_mellon
>>
>> You can probably see a trace in your browser console?
>>
>> On 1/14/2016 10:21 AM, Michal Hajas wrote:
>>
>>
>>
>> Actually, I am not sure but it looks like not. There is nothing in both keycloak server log and events in admin console.
>>
>> Michal.
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com> To: keycloak-dev at lists.jboss.org Sent: Thursday, January 14, 2016 3:28:36 PM
>> Subject: Re: [keycloak-dev] mod_auth_mellon
>>
>> Is mellon actually sending a logout request to Keycloak?
>> Do you see any error message on the keycloak server side? We definitely support POST binding for logout.
>> On 1/14/2016 8:34 AM, Michal Hajas wrote:
>>
>>
>>
>> Hi,
>>
>> I'm trying to run apache + mod_auth_mellon with keycloak as indentity provider.
>>
>> Steps:
>> 1. Install apache and mod_auth_mellon module
>> 2. Generate .key, .cert, .xml files with mellon_create_metadata.sh and copy them to /mellon directory
>> 3. Download idp_metadata.xml from keycloak/auth/realm/{REALM}/protocol/saml/descriptor and copy it to /mellon directory
>> 4. Configure auth_mod_mellon with enclosed file auth_mellon.conf
>> 5. Create client in keycloak from xml file generated in step 2 (There must be enabled Sign Documents, Sign Assertions signing and Force POST Binding)
>>
>> Login works, when I access /auth, mellon redirect me to keycloak and after successful login it redirect me back to protected resource.
>>
>> Problem:
>> I'm not able to logout. When I access localhost/mellon/logout?ReturnTo=/, it doesn't destroy session in keycloak and in apache's error log there is:
>> Current identity provider does not support single logout. Destroying local session only.
>>
>> Only way I was able to log out is change
>>
>> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />
>>
>> to
>>
>> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />
>>
>> POST -> Redirect
>>
>> in idp_metadata.xml and set "Logout Service Redirect Binding URL" to http://localhost/mellon/logout in admin console.
>>
>> Is it correct or it should work with POST binding too?
>>
>> Thank you,
>> Michal.
>>
>>
>> _______________________________________________
>> 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
>>
>


-- 
John

From bburke at redhat.com  Wed Feb 10 13:56:46 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 10 Feb 2016 13:56:46 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <56BB7F11.8000208@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
	<1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
	<5698FBE9.10406@redhat.com>
	<939885315.18350804.1453114681307.JavaMail.zimbra@redhat.com>
	<569CE2D9.4090507@redhat.com> <56BB7F11.8000208@redhat.com>
Message-ID: <56BB87EE.6040404@redhat.com>



On 2/10/2016 1:18 PM, John Dennis wrote:
> On 01/18/2016 08:04 AM, Bill Burke wrote:
>> Make sure that the SP and IDP metadata files both have a post binding in
>> there for single logout service.  That's the only thing I can think of.
>> Maybe mellon just doesn't support it.  The example file in the mellon
>> doc uses redirect for logout.  *shrug*
>
> Bill:
>
> mod_auth_mellon *only* supports the HTTP-Redirect binding for issuing 
> logout requests to the IdP. The reason is simple, mellon as an apache 
> module does not have a mechanism for POST'ing a request to another 
> location while it's processing a request. As such it relies on 
> redirects to get the logout request to the IdP.
>
Huh?  apache doesn't need to make any background HTTP requests.  The 
trick is to encode and pass back an HTML document with javascript in 
it.  That's how the spec recommends it and how we support POST binding.  
Its all done via browser requests.

> The problem is the metadata returned by Keycloak only includes a 
> SingleLogoutService with the HTTP-POST binding.
>
> Others have tested changing the binding in the IdP metdata to 
> HTTP-Redirect and retaining the same URL endpoint (see below and 
> others have done the same). It works. Therefore it seems like there is 
> no reason for Keycloak not to support SingleLogoutService with the 
> HTTP-Redirect binding. Seems like this would be a trivial edit to the 
> metadata generator.
>
> Agreed? Should we open a bug?
Yes please.

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


From mposolda at redhat.com  Thu Feb 11 11:57:05 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 Feb 2016 17:57:05 +0100
Subject: [keycloak-dev] Improving SSO logout performance
Message-ID: <56BCBD61.5080607@redhat.com>

Few things, which we can possibly do:

- Currently when application initiates logout through 
servletRequest.logout , it sends request to Keycloak logout endpoint. 
This endpoint then sends backchannel request to all logged clients with 
registered admin URL. I think we can improve here and not send request 
to the original application, which initiated logout.

For example: When product-portal application initiates logout through 
servletRequest.logout, the adapter itself should be already able to do 
all logout actions on it's side (invalidate httpSession etc) and there 
is no need to send another request from keycloak to product-portal to 
logout same httpSession.

- Backchannel logout requests send by Keycloak (ResourceAdminManager) 
could be send in parallel. Currently they are send sequentially, which 
is not very optimal.

WDYT?

Marek

From srossillo at smartling.com  Thu Feb 11 14:39:01 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 11 Feb 2016 14:39:01 -0500
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCBD61.5080607@redhat.com>
References: <56BCBD61.5080607@redhat.com>
Message-ID: <B88E65E6-5E50-4845-8C21-C416E73458B6@smartling.com>

Why not just kick off the backchannel logout requests sent by Keycloak asynchronously? The logout requesting app can?t do anything if they fail anyway.

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 11, 2016, at 11:57 AM, Marek Posolda <mposolda at redhat.com> wrote:
> 
> Few things, which we can possibly do:
> 
> - Currently when application initiates logout through 
> servletRequest.logout , it sends request to Keycloak logout endpoint. 
> This endpoint then sends backchannel request to all logged clients with 
> registered admin URL. I think we can improve here and not send request 
> to the original application, which initiated logout.
> 
> For example: When product-portal application initiates logout through 
> servletRequest.logout, the adapter itself should be already able to do 
> all logout actions on it's side (invalidate httpSession etc) and there 
> is no need to send another request from keycloak to product-portal to 
> logout same httpSession.
> 
> - Backchannel logout requests send by Keycloak (ResourceAdminManager) 
> could be send in parallel. Currently they are send sequentially, which 
> is not very optimal.
> 
> WDYT?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mstrukel at redhat.com  Thu Feb 11 14:41:12 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 11 Feb 2016 20:41:12 +0100
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCBD61.5080607@redhat.com>
References: <56BCBD61.5080607@redhat.com>
Message-ID: <CA+1OW+i+bs0XUVngYo7hnEXZ9xGngc9OpmQTHji1wfbLC5sNxQ@mail.gmail.com>

There is one neat side-effect of current implementation in that it is
immediately apparent when backchannel events don't work due to
misconfiguration or firewall issues.

If the proposed optimisation is implemented I think we should add some
logging on the server that will make it very obvious when backchannel
events fail.

On Thu, Feb 11, 2016 at 5:57 PM, Marek Posolda <mposolda at redhat.com> wrote:
> Few things, which we can possibly do:
>
> - Currently when application initiates logout through
> servletRequest.logout , it sends request to Keycloak logout endpoint.
> This endpoint then sends backchannel request to all logged clients with
> registered admin URL. I think we can improve here and not send request
> to the original application, which initiated logout.
>
> For example: When product-portal application initiates logout through
> servletRequest.logout, the adapter itself should be already able to do
> all logout actions on it's side (invalidate httpSession etc) and there
> is no need to send another request from keycloak to product-portal to
> logout same httpSession.
>
> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
> could be send in parallel. Currently they are send sequentially, which
> is not very optimal.
>
> WDYT?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Thu Feb 11 14:43:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Feb 2016 14:43:51 -0500
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCBD61.5080607@redhat.com>
References: <56BCBD61.5080607@redhat.com>
Message-ID: <56BCE477.6040601@redhat.com>

There's also the option of doing logout via iframes in the browser. This 
might be very useful for apps that need a browser logout.

On 2/11/2016 11:57 AM, Marek Posolda wrote:
> Few things, which we can possibly do:
>
> - Currently when application initiates logout through
> servletRequest.logout , it sends request to Keycloak logout endpoint.
> This endpoint then sends backchannel request to all logged clients with
> registered admin URL. I think we can improve here and not send request
> to the original application, which initiated logout.
>
> For example: When product-portal application initiates logout through
> servletRequest.logout, the adapter itself should be already able to do
> all logout actions on it's side (invalidate httpSession etc) and there
> is no need to send another request from keycloak to product-portal to
> logout same httpSession.
>
> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
> could be send in parallel. Currently they are send sequentially, which
> is not very optimal.
>
> WDYT?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From bburke at redhat.com  Thu Feb 11 15:08:41 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 11 Feb 2016 15:08:41 -0500
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCE477.6040601@redhat.com>
References: <56BCBD61.5080607@redhat.com> <56BCE477.6040601@redhat.com>
Message-ID: <56BCEA49.9030807@redhat.com>

Also, OIDC adapter needs a ?GLO=true option like saml does.

For SAML it would be easy to implement this optimization.  I don't think 
OIDC has a way to determine who sent the logout reqest.

On 2/11/2016 2:43 PM, Bill Burke wrote:
> There's also the option of doing logout via iframes in the browser. This
> might be very useful for apps that need a browser logout.
>
> On 2/11/2016 11:57 AM, Marek Posolda wrote:
>> Few things, which we can possibly do:
>>
>> - Currently when application initiates logout through
>> servletRequest.logout , it sends request to Keycloak logout endpoint.
>> This endpoint then sends backchannel request to all logged clients with
>> registered admin URL. I think we can improve here and not send request
>> to the original application, which initiated logout.
>>
>> For example: When product-portal application initiates logout through
>> servletRequest.logout, the adapter itself should be already able to do
>> all logout actions on it's side (invalidate httpSession etc) and there
>> is no need to send another request from keycloak to product-portal to
>> logout same httpSession.
>>
>> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
>> could be send in parallel. Currently they are send sequentially, which
>> is not very optimal.
>>
>> WDYT?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From mposolda at redhat.com  Thu Feb 11 15:42:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 Feb 2016 21:42:12 +0100
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <CA+1OW+i+bs0XUVngYo7hnEXZ9xGngc9OpmQTHji1wfbLC5sNxQ@mail.gmail.com>
References: <56BCBD61.5080607@redhat.com>
	<CA+1OW+i+bs0XUVngYo7hnEXZ9xGngc9OpmQTHji1wfbLC5sNxQ@mail.gmail.com>
Message-ID: <56BCF224.6040703@redhat.com>

What I'm currently thinking is, that all backchannel logout requests can 
be sent asynchronously, but the caller will wait for them until all the 
responses are received.

Like if there are 4 clientSessions here: 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/managers/AuthenticationManager.java#L120 
, the "backchannelLogoutClientSession" will be triggered in 4 separate 
threads, but then will wait until all of them are finished (Thread.join 
or Future.get or something like that). In that case, Keycloak will be 
still aware of all the logout requests success and failures. Currently 
Keycloak is aware, but sending logout requests is sequential (request2 
send after response1 is received) and that's far from optimal solution IMO.

Btv. I've just checked that when some logout request fails, we just log 
it 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/managers/ResourceAdminManager.java#L256 
. I guess we should also report it to LOGOUT Event to see which requests 
were successful and which failed. That's another issue though, but is 
quite related.

Marek

On 11/02/16 20:41, Marko Strukelj wrote:
> There is one neat side-effect of current implementation in that it is
> immediately apparent when backchannel events don't work due to
> misconfiguration or firewall issues.
>
> If the proposed optimisation is implemented I think we should add some
> logging on the server that will make it very obvious when backchannel
> events fail.
>
> On Thu, Feb 11, 2016 at 5:57 PM, Marek Posolda <mposolda at redhat.com> wrote:
>> Few things, which we can possibly do:
>>
>> - Currently when application initiates logout through
>> servletRequest.logout , it sends request to Keycloak logout endpoint.
>> This endpoint then sends backchannel request to all logged clients with
>> registered admin URL. I think we can improve here and not send request
>> to the original application, which initiated logout.
>>
>> For example: When product-portal application initiates logout through
>> servletRequest.logout, the adapter itself should be already able to do
>> all logout actions on it's side (invalidate httpSession etc) and there
>> is no need to send another request from keycloak to product-portal to
>> logout same httpSession.
>>
>> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
>> could be send in parallel. Currently they are send sequentially, which
>> is not very optimal.
>>
>> WDYT?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mposolda at redhat.com  Thu Feb 11 15:50:39 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 Feb 2016 21:50:39 +0100
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCEA49.9030807@redhat.com>
References: <56BCBD61.5080607@redhat.com> <56BCE477.6040601@redhat.com>
	<56BCEA49.9030807@redhat.com>
Message-ID: <56BCF41F.6050308@redhat.com>

If application initiates logout via servletRequest.logout, the adapter 
is using backchannel  request to this endpoint - 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/LogoutEndpoint.java#L178 
. It is authenticated by client credentials and hence is aware which 
client initiated the logout. There is also refreshToken and we have the 
clientSession available in this refresh token. This is not OIDC standard 
though, but we have that. So we can easily ommit this clientSession from 
backchannel logout request by ResourceAdminManager.

Marek

On 11/02/16 21:08, Bill Burke wrote:
> Also, OIDC adapter needs a ?GLO=true option like saml does.
>
> For SAML it would be easy to implement this optimization.  I don't think
> OIDC has a way to determine who sent the logout reqest.
>
> On 2/11/2016 2:43 PM, Bill Burke wrote:
>> There's also the option of doing logout via iframes in the browser. This
>> might be very useful for apps that need a browser logout.
>>
>> On 2/11/2016 11:57 AM, Marek Posolda wrote:
>>> Few things, which we can possibly do:
>>>
>>> - Currently when application initiates logout through
>>> servletRequest.logout , it sends request to Keycloak logout endpoint.
>>> This endpoint then sends backchannel request to all logged clients with
>>> registered admin URL. I think we can improve here and not send request
>>> to the original application, which initiated logout.
>>>
>>> For example: When product-portal application initiates logout through
>>> servletRequest.logout, the adapter itself should be already able to do
>>> all logout actions on it's side (invalidate httpSession etc) and there
>>> is no need to send another request from keycloak to product-portal to
>>> logout same httpSession.
>>>
>>> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
>>> could be send in parallel. Currently they are send sequentially, which
>>> is not very optimal.
>>>
>>> WDYT?
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Feb 11 16:02:25 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 11 Feb 2016 22:02:25 +0100
Subject: [keycloak-dev] Improving SSO logout performance
In-Reply-To: <56BCE477.6040601@redhat.com>
References: <56BCBD61.5080607@redhat.com> <56BCE477.6040601@redhat.com>
Message-ID: <56BCF6E1.7030108@redhat.com>

So you mean that we can have option to use logout iframe even in 
server-side applications? Same stuff like we have in keycloak.js?

I guess it should work, but not sure about security implications. For 
example the scenario like:
- User authenticated to customer-portal which is using iframe
- User opened tab with product-portal
- User closed the tab with customer-portal
- User sent logout request to product-portal. Now since the 
customer-portal wasn't opened in browser, it is not immediately 
available about logout and it's httpSession will be still valid. Session 
will be logged-out later once user opens the customer-portal. I guess 
it's not the big issue, the javascript apps also work the same way. But 
not sure...

Marek

On 11/02/16 20:43, Bill Burke wrote:
> There's also the option of doing logout via iframes in the browser. This
> might be very useful for apps that need a browser logout.
>
> On 2/11/2016 11:57 AM, Marek Posolda wrote:
>> Few things, which we can possibly do:
>>
>> - Currently when application initiates logout through
>> servletRequest.logout , it sends request to Keycloak logout endpoint.
>> This endpoint then sends backchannel request to all logged clients with
>> registered admin URL. I think we can improve here and not send request
>> to the original application, which initiated logout.
>>
>> For example: When product-portal application initiates logout through
>> servletRequest.logout, the adapter itself should be already able to do
>> all logout actions on it's side (invalidate httpSession etc) and there
>> is no need to send another request from keycloak to product-portal to
>> logout same httpSession.
>>
>> - Backchannel logout requests send by Keycloak (ResourceAdminManager)
>> could be send in parallel. Currently they are send sequentially, which
>> is not very optimal.
>>
>> WDYT?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From kunal at plivo.com  Fri Feb 12 03:34:34 2016
From: kunal at plivo.com (Kunal K)
Date: Fri, 12 Feb 2016 14:04:34 +0530
Subject: [keycloak-dev] Tests are failing for 1.8.x branch
Message-ID: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>

I'm trying to build the 1.8.x branch with mvn install -Pdistribution but
tests are failing.

Here are the logs - https://gist.github.com/tsudot/6ac955a6b41d8f2df42f


-- 
*KUNAL KERKAR *| PRODUCT ENGINEER
Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
Web: www.plivo.com | Twitter: @plivo <http://twitter.com/plivo>, @tsudot
<http://twitter.com/tsudot>

Free Incoming SMS for All US Short Codes ? Get One Today!?
<https://www.plivo.com/sms-short-code/?utm=emailsig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160212/0d781467/attachment-0001.html 

From mstrukel at redhat.com  Fri Feb 12 03:45:02 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 12 Feb 2016 09:45:02 +0100
Subject: [keycloak-dev] Tests are failing for 1.8.x branch
In-Reply-To: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>
References: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>
Message-ID: <CA+1OW+h1NF_rpDAUbXTCQFGMzgjFgX+4y4Zb6YSm7zGyB=_y9g@mail.gmail.com>

Make sure you have no other server running on ports 8081, and 8181.

On Fri, Feb 12, 2016 at 9:34 AM, Kunal K <kunal at plivo.com> wrote:
> I'm trying to build the 1.8.x branch with mvn install -Pdistribution but
> tests are failing.
>
> Here are the logs - https://gist.github.com/tsudot/6ac955a6b41d8f2df42f
>
>
> --
> KUNAL KERKAR | PRODUCT ENGINEER
> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
> Web: www.plivo.com | Twitter: @plivo, @tsudot
>
> Free Incoming SMS for All US Short Codes ? Get One Today!?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From kunal at plivo.com  Fri Feb 12 03:51:52 2016
From: kunal at plivo.com (Kunal K)
Date: Fri, 12 Feb 2016 14:21:52 +0530
Subject: [keycloak-dev] Tests are failing for 1.8.x branch
In-Reply-To: <CA+1OW+h1NF_rpDAUbXTCQFGMzgjFgX+4y4Zb6YSm7zGyB=_y9g@mail.gmail.com>
References: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>
	<CA+1OW+h1NF_rpDAUbXTCQFGMzgjFgX+4y4Zb6YSm7zGyB=_y9g@mail.gmail.com>
Message-ID: <CAH2rpZsEvA-t7UWjWLFDNogvPKE2gG0-h3XSkJSwJ5AQ4Yk8JQ@mail.gmail.com>

Just checked, nothing seems to be running on those ports.

:~$ sudo netstat -nlp | grep 8081
:~$ sudo netstat -nlp | grep 8181

?


On Fri, Feb 12, 2016 at 2:15 PM, Marko Strukelj <mstrukel at redhat.com> wrote:

> Make sure you have no other server running on ports 8081, and 8181.
>
> On Fri, Feb 12, 2016 at 9:34 AM, Kunal K <kunal at plivo.com> wrote:
> > I'm trying to build the 1.8.x branch with mvn install -Pdistribution but
> > tests are failing.
> >
> > Here are the logs - https://gist.github.com/tsudot/6ac955a6b41d8f2df42f
> >
> >
> > --
> > KUNAL KERKAR | PRODUCT ENGINEER
> > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
> > Web: www.plivo.com | Twitter: @plivo, @tsudot
> >
> > Free Incoming SMS for All US Short Codes ? Get One Today!?
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
*KUNAL KERKAR *| PRODUCT ENGINEER
Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
Web: www.plivo.com | Twitter: @plivo <http://twitter.com/plivo>, @tsudot
<http://twitter.com/tsudot>

Free Incoming SMS for All US Short Codes ? Get One Today!?
<https://www.plivo.com/sms-short-code/?utm=emailsig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160212/ad0fb789/attachment.html 

From kunal at plivo.com  Fri Feb 12 03:56:32 2016
From: kunal at plivo.com (Kunal K)
Date: Fri, 12 Feb 2016 14:26:32 +0530
Subject: [keycloak-dev] Tests are failing for 1.8.x branch
In-Reply-To: <CAH2rpZsEvA-t7UWjWLFDNogvPKE2gG0-h3XSkJSwJ5AQ4Yk8JQ@mail.gmail.com>
References: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>
	<CA+1OW+h1NF_rpDAUbXTCQFGMzgjFgX+4y4Zb6YSm7zGyB=_y9g@mail.gmail.com>
	<CAH2rpZsEvA-t7UWjWLFDNogvPKE2gG0-h3XSkJSwJ5AQ4Yk8JQ@mail.gmail.com>
Message-ID: <CAH2rpZsGO1j4Af88sHPjSUwzZD503v3HY43n0+_OqkJwENea=A@mail.gmail.com>

Tests fail from here -

        -------------------------------------------------------

 T E S T S

-------------------------------------------------------

Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
MaxPermSize=1024m; support was removed in 8.0

Running org.keycloak.testsuite.model.ImportTest

08:53:26,964 INFO
[org.keycloak.services.resources.KeycloakApplication] Load config from
file:/var/log/kunal/keycloak/testsuite/integration/target/test-classes/META-INF/keycloak-server.json

08:53:27,830 INFO  [org.infinispan.factories.GlobalComponentRegistry]
ISPN000128: Infinispan version: Infinispan 'Mahou' 8.1.0.Final

08:53:29,604 ERROR
[org.keycloak.services.resources.KeycloakApplication] Failed to
migrate datamodel

java.lang.RuntimeException: Failed to update database

        at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87)

        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)

        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)

        at org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)

        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)

        at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34)

        at org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16)

        at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)

        at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)

        at org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)

        at org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)

        at org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)

        at org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

        at java.lang.reflect.Constructor.newInstance(Constructor.java:422)

        at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)

        at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)

        at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)

        at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)

        at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)

        at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)

        at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)

        at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)

        at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)

        at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)

        at org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:232)

        at org.keycloak.testsuite.KeycloakServer.start(KeycloakServer.java:321)

        at org.keycloak.testsuite.rule.AbstractKeycloakRule.before(AbstractKeycloakRule.java:58)

        at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)

        at org.junit.rules.RunRules.evaluate(RunRules.java:20)

        at org.junit.runners.ParentRunner.run(ParentRunner.java:363)

        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)

        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)

        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)

        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)

        at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)

        at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)

        at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: liquibase.exception.ChangeLogParseException: Error Reading
Migration File: Found 2 files that match
META-INF/jpa-changelog-master.xml
        at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:112)
        at liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:17)
        at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:225)
        at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1133)
        at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
        at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
        at org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:63)
        ... 39 more
Caused by: java.io.IOException: Found 2 files that match
META-INF/jpa-changelog-master.xml
        at liquibase.util.StreamUtil.singleInputStream(StreamUtil.java:189)
        at liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:93)

        ... 45 more

?


On Fri, Feb 12, 2016 at 2:21 PM, Kunal K <kunal at plivo.com> wrote:

> Just checked, nothing seems to be running on those ports.
>
> :~$ sudo netstat -nlp | grep 8081
> :~$ sudo netstat -nlp | grep 8181
>
> ?
>
>
> On Fri, Feb 12, 2016 at 2:15 PM, Marko Strukelj <mstrukel at redhat.com>
> wrote:
>
>> Make sure you have no other server running on ports 8081, and 8181.
>>
>> On Fri, Feb 12, 2016 at 9:34 AM, Kunal K <kunal at plivo.com> wrote:
>> > I'm trying to build the 1.8.x branch with mvn install -Pdistribution but
>> > tests are failing.
>> >
>> > Here are the logs - https://gist.github.com/tsudot/6ac955a6b41d8f2df42f
>> >
>> >
>> > --
>> > KUNAL KERKAR | PRODUCT ENGINEER
>> > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
>> > Web: www.plivo.com | Twitter: @plivo, @tsudot
>> >
>> > Free Incoming SMS for All US Short Codes ? Get One Today!?
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> *KUNAL KERKAR *| PRODUCT ENGINEER
> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
> Web: www.plivo.com | Twitter: @plivo <http://twitter.com/plivo>, @tsudot
> <http://twitter.com/tsudot>
>
> Free Incoming SMS for All US Short Codes ? Get One Today!?
> <https://www.plivo.com/sms-short-code/?utm=emailsig>
>



-- 
*KUNAL KERKAR *| PRODUCT ENGINEER
Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
Web: www.plivo.com | Twitter: @plivo <http://twitter.com/plivo>, @tsudot
<http://twitter.com/tsudot>

Free Incoming SMS for All US Short Codes ? Get One Today!?
<https://www.plivo.com/sms-short-code/?utm=emailsig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160212/5c615d16/attachment-0001.html 

From mstrukel at redhat.com  Fri Feb 12 04:10:07 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 12 Feb 2016 10:10:07 +0100
Subject: [keycloak-dev] Tests are failing for 1.8.x branch
In-Reply-To: <CAH2rpZsGO1j4Af88sHPjSUwzZD503v3HY43n0+_OqkJwENea=A@mail.gmail.com>
References: <CAH2rpZsWLSRP9PQNXSUuyBkDkHmiX--894xUiJf5JReF8qKF7A@mail.gmail.com>
	<CA+1OW+h1NF_rpDAUbXTCQFGMzgjFgX+4y4Zb6YSm7zGyB=_y9g@mail.gmail.com>
	<CAH2rpZsEvA-t7UWjWLFDNogvPKE2gG0-h3XSkJSwJ5AQ4Yk8JQ@mail.gmail.com>
	<CAH2rpZsGO1j4Af88sHPjSUwzZD503v3HY43n0+_OqkJwENea=A@mail.gmail.com>
Message-ID: <CA+1OW+jkjXK0FagEfGcGm8cVS9fJ2ow=JBvCNAy97_O4YJfS2g@mail.gmail.com>

That looks like a genuine failure :) Someone will have to take a closer look ...

For now try bypass it with -DskipTests.


On Fri, Feb 12, 2016 at 9:56 AM, Kunal K <kunal at plivo.com> wrote:
> Tests fail from here -
>
>         -------------------------------------------------------
>
>  T E S T S
>
> -------------------------------------------------------
>
> Java HotSpot(TM) 64-Bit Server VM warning: ignoring option
> MaxPermSize=1024m; support was removed in 8.0
>
> Running org.keycloak.testsuite.model.ImportTest
>
> 08:53:26,964 INFO  [org.keycloak.services.resources.KeycloakApplication]
> Load config from
> file:/var/log/kunal/keycloak/testsuite/integration/target/test-classes/META-INF/keycloak-server.json
>
> 08:53:27,830 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> ISPN000128: Infinispan version: Infinispan 'Mahou' 8.1.0.Final
>
> 08:53:29,604 ERROR [org.keycloak.services.resources.KeycloakApplication]
> Failed to migrate datamodel
>
> java.lang.RuntimeException: Failed to update database
>
>         at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87)
>
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
>
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
>
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
>
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34)
>
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16)
>
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
>
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
>
>         at
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
>
>         at
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:139)
>
>         at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:82)
>
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>
>         at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
>
>         at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
>
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
>
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
>
>         at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
>
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>
>         at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220)
>
>         at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125)
>
>         at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508)
>
>         at
> org.jboss.resteasy.plugins.server.undertow.UndertowJaxrsServer.deploy(UndertowJaxrsServer.java:232)
>
>         at
> org.keycloak.testsuite.KeycloakServer.start(KeycloakServer.java:321)
>
>         at
> org.keycloak.testsuite.rule.AbstractKeycloakRule.before(AbstractKeycloakRule.java:58)
>
>         at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:46)
>
>         at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>
>         at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>
>         at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>
>         at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>
>         at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>
>         at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>
>         at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>
>         at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>
>         at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: liquibase.exception.ChangeLogParseException: Error Reading
> Migration File: Found 2 files that match META-INF/jpa-changelog-master.xml
>         at
> liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:112)
>         at
> liquibase.parser.core.xml.AbstractChangeLogParser.parse(AbstractChangeLogParser.java:17)
>         at liquibase.Liquibase.getDatabaseChangeLog(Liquibase.java:225)
>         at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1133)
>         at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1126)
>         at liquibase.Liquibase.listUnrunChangeSets(Liquibase.java:1122)
>         at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:63)
>         ... 39 more
> Caused by: java.io.IOException: Found 2 files that match
> META-INF/jpa-changelog-master.xml
>         at liquibase.util.StreamUtil.singleInputStream(StreamUtil.java:189)
>         at
> liquibase.parser.core.xml.XMLChangeLogSAXParser.parseToNode(XMLChangeLogSAXParser.java:93)
>
>         ... 45 more
>
>
> On Fri, Feb 12, 2016 at 2:21 PM, Kunal K <kunal at plivo.com> wrote:
>>
>> Just checked, nothing seems to be running on those ports.
>>
>> :~$ sudo netstat -nlp | grep 8081
>> :~$ sudo netstat -nlp | grep 8181
>>
>>
>> On Fri, Feb 12, 2016 at 2:15 PM, Marko Strukelj <mstrukel at redhat.com>
>> wrote:
>>>
>>> Make sure you have no other server running on ports 8081, and 8181.
>>>
>>> On Fri, Feb 12, 2016 at 9:34 AM, Kunal K <kunal at plivo.com> wrote:
>>> > I'm trying to build the 1.8.x branch with mvn install -Pdistribution
>>> > but
>>> > tests are failing.
>>> >
>>> > Here are the logs - https://gist.github.com/tsudot/6ac955a6b41d8f2df42f
>>> >
>>> >
>>> > --
>>> > KUNAL KERKAR | PRODUCT ENGINEER
>>> > Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
>>> > Web: www.plivo.com | Twitter: @plivo, @tsudot
>>> >
>>> > Free Incoming SMS for All US Short Codes ? Get One Today!?
>>> >
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> --
>> KUNAL KERKAR | PRODUCT ENGINEER
>> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
>> Web: www.plivo.com | Twitter: @plivo, @tsudot
>>
>> Free Incoming SMS for All US Short Codes ? Get One Today!?
>
>
>
>
> --
> KUNAL KERKAR | PRODUCT ENGINEER
> Plivo, Inc. 340 Pine St, San Francisco - 94104, USA
> Web: www.plivo.com | Twitter: @plivo, @tsudot
>
> Free Incoming SMS for All US Short Codes ? Get One Today!?


From sthorger at redhat.com  Fri Feb 12 09:44:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 12 Feb 2016 15:44:04 +0100
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
Message-ID: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>

Currently we include built-in themes in the themes jar as well as extracted
to standalone/configuration/themes. We have to remove the extracted files.

This is due to patching. The patching tools only supports patching modules,
not files. If we need to patch the theme templates (quite likely we will)
we can then only patch the jar. As the extracted themes override the jar it
won't work unless we remove them.

The main problem with removing the extracted files is that they are useful
for someone that needs to modify the templates. I think the best would just
be to give people instructions on how to extract these from the jar. It's
just a zip after all.

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

From ssilvert at redhat.com  Fri Feb 12 10:55:20 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 Feb 2016 10:55:20 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
Message-ID: <56BE0068.1040704@redhat.com>

Putting the themes into a module jar raises two usability issues:
1) They have to be extracted and the re-jarred
2) Modules live many, many level deep in the directory structure and are 
therefore hard to find.

I'm not familiar with the limitations of the patching tool, but is seems 
that we could do this:
* Don't put themes in a jar.  Plain files can also live inside a module.
* Create a second module directory structure.  JBoss Modules lets you 
have multiple paths for modules.  So we just have a <KEYCLOAK 
HOMe>/themes path that is a known module path.

The question is, will the patching tool be able to deal with that?  If 
not, we need to fix the patching tool.

On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>
> Currently we include built-in themes in the themes jar as well as 
> extracted to standalone/configuration/themes. We have to remove the 
> extracted files.
>
> This is due to patching. The patching tools only supports patching 
> modules, not files. If we need to patch the theme templates (quite 
> likely we will) we can then only patch the jar. As the extracted 
> themes override the jar it won't work unless we remove them.
>
> The main problem with removing the extracted files is that they are 
> useful for someone that needs to modify the templates. I think the 
> best would just be to give people instructions on how to extract these 
> from the jar. It's just a zip after all.
>
> Thoughts??
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ssilvert at redhat.com  Fri Feb 12 11:01:55 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 Feb 2016 11:01:55 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
Message-ID: <56BE01F3.7060904@redhat.com>

Another way to deal with this might be to unjar the files ourselves at 
startup.  The files could live in the same place they live today.

We would just have keep track of versioning.  If a newer version of the 
theme is installed we overwrite the old version in 
standlone/configuration/themes.  Of course, if the theme has been 
modified by the user we wouldn't overwrite, but instead just unjar to 
another location.

On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>
> Currently we include built-in themes in the themes jar as well as 
> extracted to standalone/configuration/themes. We have to remove the 
> extracted files.
>
> This is due to patching. The patching tools only supports patching 
> modules, not files. If we need to patch the theme templates (quite 
> likely we will) we can then only patch the jar. As the extracted 
> themes override the jar it won't work unless we remove them.
>
> The main problem with removing the extracted files is that they are 
> useful for someone that needs to modify the templates. I think the 
> best would just be to give people instructions on how to extract these 
> from the jar. It's just a zip after all.
>
> Thoughts??
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Fri Feb 12 12:46:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Feb 2016 12:46:51 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
 standalone/configuration/themes
In-Reply-To: <56BE01F3.7060904@redhat.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com>
Message-ID: <56BE1A8B.2060004@redhat.com>

Keep it the way it is, IMO.  Write directions on how to handle a theme 
patch.

On 2/12/2016 11:01 AM, Stan Silvert wrote:
> Another way to deal with this might be to unjar the files ourselves at 
> startup.  The files could live in the same place they live today.
>
> We would just have keep track of versioning.  If a newer version of 
> the theme is installed we overwrite the old version in 
> standlone/configuration/themes.  Of course, if the theme has been 
> modified by the user we wouldn't overwrite, but instead just unjar to 
> another location.
>
> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>
>> Currently we include built-in themes in the themes jar as well as 
>> extracted to standalone/configuration/themes. We have to remove the 
>> extracted files.
>>
>> This is due to patching. The patching tools only supports patching 
>> modules, not files. If we need to patch the theme templates (quite 
>> likely we will) we can then only patch the jar. As the extracted 
>> themes override the jar it won't work unless we remove them.
>>
>> The main problem with removing the extracted files is that they are 
>> useful for someone that needs to modify the templates. I think the 
>> best would just be to give people instructions on how to extract 
>> these from the jar. It's just a zip after all.
>>
>> 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

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

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

From ssilvert at redhat.com  Fri Feb 12 13:31:32 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 12 Feb 2016 13:31:32 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <56BE1A8B.2060004@redhat.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
Message-ID: <56BE2504.4040203@redhat.com>

BTW, how do you deal with theme changes on OpenShift?  Looks like a year 
ago the answer was, "fork the cartridge".  Is that still the only solution?

http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html

On 2/12/2016 12:46 PM, Bill Burke wrote:
> Keep it the way it is, IMO.  Write directions on how to handle a theme 
> patch.
>
> On 2/12/2016 11:01 AM, Stan Silvert wrote:
>> Another way to deal with this might be to unjar the files ourselves 
>> at startup.  The files could live in the same place they live today.
>>
>> We would just have keep track of versioning.  If a newer version of 
>> the theme is installed we overwrite the old version in 
>> standlone/configuration/themes.  Of course, if the theme has been 
>> modified by the user we wouldn't overwrite, but instead just unjar to 
>> another location.
>>
>> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>>
>>> Currently we include built-in themes in the themes jar as well as 
>>> extracted to standalone/configuration/themes. We have to remove the 
>>> extracted files.
>>>
>>> This is due to patching. The patching tools only supports patching 
>>> modules, not files. If we need to patch the theme templates (quite 
>>> likely we will) we can then only patch the jar. As the extracted 
>>> themes override the jar it won't work unless we remove them.
>>>
>>> The main problem with removing the extracted files is that they are 
>>> useful for someone that needs to modify the templates. I think the 
>>> best would just be to give people instructions on how to extract 
>>> these from the jar. It's just a zip after all.
>>>
>>> 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
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Fri Feb 12 13:47:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Feb 2016 13:47:15 -0500
Subject: [keycloak-dev] caching changes
Message-ID: <56BE28B3.7070707@redhat.com>

I'm still working on stuff, but here is a summary of things so far:
* ConcurrenyTest is passing
* Caching implementation is now a pessimistic locking style based on 
versions.  Locking never happens on reads, only writes.  There are two 
caches.  One cache holds the actual data, and is pretty much a vanilla 
invalidation cache.  The other cache olds versioning information and is 
a local-only cache and just is an id->version map.  Given an id, what is 
the current version of it.  Hopefully, the implementation makes sure 
that you never are able to add or obtain a stale version of an object 
from the cache.  Locking happens for updates.  At the end of a 
transaction, all registered invalidations are iterated on, and a version 
cache lock on that id is obtain.  The db is updated, and after that the 
locks are released.  A lock is also obtained whever something is added 
to the cache.  Again a lock is only obtained on the version cache, so 
any reads will never block.
* KeycloakTransactionManager now has an enlistPrepare method.
* There is a new RealmProvider.getClientByClientId() method. Clients now 
have a clientId "index" in the cache.
* There is a new RealmProvider.removeClient() method.  This was needed 
to support getClientByClientId()

Some other things that were done:
* Unnecessary @JoinTables were removed for certain @OneToMany relationships.
* getId() will no longer cause a DB query if you are invoking on a 
reference to a JPA adapter
* RealmModel.getClients() and getClientNameMap() is no longer used to 
implement getClientByClientId() :)
* CachedRealm now stores PrivateKey, PublicKey, and Certificate in a 
transient variable.  We were actually unmarshalling from the cached pem 
format every time these things were access, which is like few times per 
login.

Next steps:
* Create a client list cache for each realm.  Currently, if you 
add/remove a client, this invalidates the realm cache and its doing a 
big query for each client.
*  Do some profiling to see if there's other things we can do.

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


From bburke at redhat.com  Fri Feb 12 13:48:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 12 Feb 2016 13:48:58 -0500
Subject: [keycloak-dev] stress/soak test/benchmarking framework
Message-ID: <56BE291A.2010101@redhat.com>

I've started implementing a stress test/benchmarking frameork.  The idea 
is that we have a pallet of operations that can be plugged in to run 
randomly over a period of time to see what the effects are. Its all 
under testsuite/stress

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


From mhashim.gm at gmail.com  Sat Feb 13 01:18:05 2016
From: mhashim.gm at gmail.com (mhashim.gm at gmail.com)
Date: Sat, 13 Feb 2016 06:18:05 +0000 (UTC)
Subject: [keycloak-dev] How to use an offline token to get access token
References: <1631726650.3566819.1455344285392.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1631726650.3566819.1455344285392.JavaMail.yahoo@mail.yahoo.com>


Hello,
I have a javascript application with keycloak javascript adapter, I use
direct grant to get the initial offline token and save to database and
it works great, the problem is when I want to get an access token the
adapter fails silently. Here is how I initiate the adapter

?? ?keycloak.init({
??????????? refreshToken: response.refresh_token,
??????????? checkLoginIframe: false
????????? })
????????? .success(authenticated => {
??????????? if(!authenticated)
????????????? dispatch(loginFailure())
??????????? else {
?? ??? ?....
?? ?? }

then I tried to get the token directly from google chrome "postman"
tool:

POST
http://localhost:8080/realms/sisdn-realm/protocol/openid-connect/token

headers:
Content-Type: application/x-www-form-urlencoded
body:
grant_type=refresh_token
refresh_token=eyJhbGciOi...
client_id=sisdn

but the server responds with not-found, what am I doing wrong?


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

From mhashim.gm at gmail.com  Sun Feb 14 09:59:14 2016
From: mhashim.gm at gmail.com (Mohamed Hashim)
Date: Sun, 14 Feb 2016 17:59:14 +0300
Subject: [keycloak-dev] How to use an offline token to get access token
Message-ID: <CAOvPFY0yXrwU3siGt-Rp8WrqFO-oo4iW_r6qdgOStsRmudctpg@mail.gmail.com>

It turns out that i have made a mistake when specifying service url in the
keycloak init configuration. now everything is working properly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160214/9678d6a2/attachment.html 

From fabricio.milone at shinetech.com  Sun Feb 14 23:51:04 2016
From: fabricio.milone at shinetech.com (Fabricio Milone)
Date: Mon, 15 Feb 2016 15:51:04 +1100
Subject: [keycloak-dev] Users with duplicated emails
Message-ID: <CAOjtoUMHmKPULdcFPrfMP6TZvyOZThS43Zd5R-uMno8jCtXLmQ@mail.gmail.com>

Hi,

I've been trying to solve an issue with my Federator for a few days now
when I import users that don't exist in Keycloak (but they do exist in my
Federator DB).

I'm getting a duplicated value constraint violation error on
email_constraint attribute from user_entity table. So I looked into the
source code and found that the emailConstraint attribute is being set to
the email value when I'm calling UserEntity.setEmail(String email).

public void setEmail(String email) {
    this.email = email;
    this.emailConstraint = email != null ? email :
KeycloakModelUtils.generateId();
}


Also I saw this comment in UserEntity.java:64:

// Hack just to workaround the fact that on MS-SQL you can't have
unique constraint with multiple NULL values TODO: Find better solution
(like unique index with 'where' but that's proprietary)
@Column(name = "EMAIL_CONSTRAINT")
protected String emailConstraint = KeycloakModelUtils.generateId();


My system allows duplicated email addresses and that cannot change.

Is there any way to allow duplicated email addresses on Keycloak?
Are you planning on an improvement to add support for a configurable unique
key for users?
What would be the best way to get rid of that constraint?

As a reference, I'm using Keycloak 1.7.0 and Informix as a DB.

Any help would be appreciated.

Thanks in advance.

Regards,
Fab


-- 
*Fabricio Milone*
Developer

*Shine Consulting *

30/600 Bourke Street

Melbourne VIC 3000

T: 03 8488 9939

M: 04 3200 4006


www.shinetech.com  *a* passion for excellence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160215/6e4af81a/attachment-0001.html 

From mposolda at redhat.com  Mon Feb 15 02:54:48 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 Feb 2016 08:54:48 +0100
Subject: [keycloak-dev] Users with duplicated emails
In-Reply-To: <CAOjtoUMHmKPULdcFPrfMP6TZvyOZThS43Zd5R-uMno8jCtXLmQ@mail.gmail.com>
References: <CAOjtoUMHmKPULdcFPrfMP6TZvyOZThS43Zd5R-uMno8jCtXLmQ@mail.gmail.com>
Message-ID: <56C18448.8000405@redhat.com>

On 15/02/16 05:51, Fabricio Milone wrote:
> Hi,
>
> I've been trying to solve an issue with my Federator for a few days 
> now when I import users that don't exist in Keycloak (but they do 
> exist in my Federator DB).
>
> I'm getting a duplicated value constraint violation error on 
> email_constraint attribute from user_entity table. So I looked into 
> the source code and found that the emailConstraint attribute is being 
> set to the email value when I'm calling UserEntity.setEmail(String email).
>
> public void setEmail(String email) {
>      this.email = email; this.emailConstraint = email !=null ? email : KeycloakModelUtils.generateId(); }
>
> Also I saw this comment in UserEntity.java:64:
> // Hack just to workaround the fact that on MS-SQL you can't have 
> unique constraint with multiple NULL values TODO: Find better solution 
> (like unique index with 'where' but that's proprietary) @Column(name ="EMAIL_CONSTRAINT")
> protected StringemailConstraint = KeycloakModelUtils.generateId();
>
> My system allows duplicated email addresses and that cannot change.
>
> Is there any way to allow duplicated email addresses on Keycloak?
> Are you planning on an improvement to add support for a configurable 
> unique key for users?
> What would be the best way to get rid of that constraint?
Depends on if you want to use some Keycloak features, which rely on 
sending emails to users (ie. Forget password).

1) If not, then you have full control in your UserFederationProvider and 
you can skip official "email" attribute and use some completely 
different attribute. Like instead of:

keycloakUser.setEmail(emailFromYourFederatorDB);

you use:

keycloakUser.setSingleAttribute("custom-email", emailFromYourFederatorDB);

You can also create protocolMappers for your clients to ensure that 
emails from attribute "custom-email" are used in access tokens, so your 
applications will properly see the user's emails in attribute "email" 
inside access token.


2) If yes, I suggest to rely on default keycloak user "email" attribute, 
but change your DB to not allow duplicate emails. Having multiple 
accounts with same email is broken architecture IMO. Among other issues, 
there can be security flaws like:
- user1 clicks on "Forget password" link
- user2 (who has same email like user1) will read the email sent by 
Keycloak from user1. He clicks on the link and resets password of user1
- user2 is able to login as user1

Marek
>
> As a reference, I'm using Keycloak 1.7.0 and Informix as a DB.
>
> Any help would be appreciated.
>
> Thanks in advance.
>
> Regards,
> Fab
>
>
> -- 
> *Fabricio Milone*
> Developer
> *
> *
> *
> Shine Consulting *
>
> 30/600 Bourke Street
>
> Melbourne VIC 3000
>
> T: 03 8488 9939
>
> M: 04 3200 4006
>
>
> www.shinetech.com <http://www.shinetech.com/>/*a*/ passion for excellence
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mposolda at redhat.com  Mon Feb 15 03:09:22 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 15 Feb 2016 09:09:22 +0100
Subject: [keycloak-dev] stress/soak test/benchmarking framework
In-Reply-To: <56BE291A.2010101@redhat.com>
References: <56BE291A.2010101@redhat.com>
Message-ID: <56C187B2.4000600@redhat.com>

QA team already has some performance tests. It's based on perfcake ( 
https://www.perfcake.org/ ). That's what I used for performance testing 
last week.

It seems it's not yet commited anywhere inside keycloak repo and it 
doesn't handle the scenario like automatic bootstrap of undertow server 
during startup as it's more focused on the "production" like scenario 
when you test with real Wildfly server or cluster of servers. However 
not sure if there is not any duplicated effort here...

Marek

On 12/02/16 19:48, Bill Burke wrote:
> I've started implementing a stress test/benchmarking frameork.  The idea
> is that we have a pallet of operations that can be plugged in to run
> randomly over a period of time to see what the effects are. Its all
> under testsuite/stress
>


From sthorger at redhat.com  Mon Feb 15 04:08:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 15 Feb 2016 10:08:10 +0100
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <56BE2504.4040203@redhat.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
	<56BE2504.4040203@redhat.com>
Message-ID: <CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>

Keeping it as is isn't an option IMO. There's a pretty big chance that we
will need to patch themes. There's several issues with that as it stands:

* Users need to deal with two separate patching mechanisms and we also need
to create tools, patches, documentation separately
* What if users change the built-in themes, rather than extending. We tell
users not to, but if they can they will. If a built-in theme has been
changed patches probably won't work
* EAP supports roll-back of patches, applies patches atomically. It's a
proper tool that helps users to do it right
* EAP supports domain mode

What Stan is proposing might be worth considering. It doesn't solve the
case that users can modify the files though.

I would actual prefer that built-in themes are always loaded from the
module, but we have the templates available in exames/themes/templates.

Another relevant thing is what do we do when users have modified templates.
How can we help them apply the required changes to the custom template?
On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com> wrote:

> BTW, how do you deal with theme changes on OpenShift?  Looks like a year
> ago the answer was, "fork the cartridge".  Is that still the only solution?
>
> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
>
> On 2/12/2016 12:46 PM, Bill Burke wrote:
>
> Keep it the way it is, IMO.  Write directions on how to handle a theme
> patch.
>
> On 2/12/2016 11:01 AM, Stan Silvert wrote:
>
> Another way to deal with this might be to unjar the files ourselves at
> startup.  The files could live in the same place they live today.
>
> We would just have keep track of versioning.  If a newer version of the
> theme is installed we overwrite the old version in
> standlone/configuration/themes.  Of course, if the theme has been modified
> by the user we wouldn't overwrite, but instead just unjar to another
> location.
>
> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>
> Currently we include built-in themes in the themes jar as well as
> extracted to standalone/configuration/themes. We have to remove the
> extracted files.
>
> This is due to patching. The patching tools only supports patching
> modules, not files. If we need to patch the theme templates (quite likely
> we will) we can then only patch the jar. As the extracted themes override
> the jar it won't work unless we remove them.
>
> The main problem with removing the extracted files is that they are useful
> for someone that needs to modify the templates. I think the best would just
> be to give people instructions on how to extract these from the jar. It's
> just a zip after all.
>
> Thoughts??
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160215/f4c299e8/attachment.html 

From velias at redhat.com  Mon Feb 15 04:25:28 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 15 Feb 2016 10:25:28 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56A7F4D8.2050009@redhat.com>
References: <56A7F4D8.2050009@redhat.com>
Message-ID: <56C19988.8070602@redhat.com>

Hi,

look at https://issues.jboss.org/browse/ORG-2774 to see why correct 
handling of Back button is necessary ;-)
Please note that this concrete issue is against Keycloak 1.6, I'm going 
to retest it against KC 1.8 and 1.9 to see if it is resolved or not, but 
it shows how common users behave and what they expect.

I believe that in common flows Back button should work as expected by 
users, not to break common user experience. Simply send user one screen 
back and allow him to correctly perform other actions provided on this 
page. I understand that there may be some flow when this is not possible 
and a bit different behaviour may be used, but these exceptions must be 
carefully considered, not implemented as common rules for all actions.

The bug report also shows that clear Error pages/messages should be 
provided to the users and reasonable action should be provided them to 
recover from error state if possible.

Vlastimil


On 26.1.2016 23:36, Bill Burke wrote:
> The current thinking for browser back button is to set:
>
> Cache-Control: no-store, must-revalidate, max-age=0
>
> There are possible security issues with this that I don't know if we
> should do this or not.  Don't know if you remember how ClientSessionCode
> works, it uses a hash of the client session id and the action key
> currently stored in the.  When you switch from authentication to
> required actions, the action key changes.  Now, if you hit the back
> button on a required action page, it would take you back to an
> authentication screen.  The code check would fail because the action
> keys don't match.
>
> Do we actually need this action key stuff?  Can we just let the flow
> manager put the browser in the correct state?  So if an "authenticate"
> url is hit and the flow is on required actions, just redirect to the
> required actions URL.   I just worry that this is some sort of security
> hole somehow.  Maybe we're better off just reseting and restarting the
> flow entirely.
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team


From bburke at redhat.com  Mon Feb 15 08:49:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Feb 2016 08:49:10 -0500
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56C19988.8070602@redhat.com>
References: <56A7F4D8.2050009@redhat.com> <56C19988.8070602@redhat.com>
Message-ID: <56C1D756.1040101@redhat.com>

1.9 should solve it.  Basically the back button is "disabled".  Now that 
there are pluggable flows, you should be able to get the behavior you 
want.  If you try out 1.9 ASAP, we can set up the default social login 
flow the way you think it should be.

On 2/15/2016 4:25 AM, Vlastimil Elias wrote:
> Hi,
>
> look at https://issues.jboss.org/browse/ORG-2774 to see why correct
> handling of Back button is necessary ;-)
> Please note that this concrete issue is against Keycloak 1.6, I'm going
> to retest it against KC 1.8 and 1.9 to see if it is resolved or not, but
> it shows how common users behave and what they expect.
>
> I believe that in common flows Back button should work as expected by
> users, not to break common user experience. Simply send user one screen
> back and allow him to correctly perform other actions provided on this
> page. I understand that there may be some flow when this is not possible
> and a bit different behaviour may be used, but these exceptions must be
> carefully considered, not implemented as common rules for all actions.
>
> The bug report also shows that clear Error pages/messages should be
> provided to the users and reasonable action should be provided them to
> recover from error state if possible.
>
> Vlastimil
>
>
> On 26.1.2016 23:36, Bill Burke wrote:
>> The current thinking for browser back button is to set:
>>
>> Cache-Control: no-store, must-revalidate, max-age=0
>>
>> There are possible security issues with this that I don't know if we
>> should do this or not.  Don't know if you remember how ClientSessionCode
>> works, it uses a hash of the client session id and the action key
>> currently stored in the.  When you switch from authentication to
>> required actions, the action key changes.  Now, if you hit the back
>> button on a required action page, it would take you back to an
>> authentication screen.  The code check would fail because the action
>> keys don't match.
>>
>> Do we actually need this action key stuff?  Can we just let the flow
>> manager put the browser in the correct state?  So if an "authenticate"
>> url is hit and the flow is on required actions, just redirect to the
>> required actions URL.   I just worry that this is some sort of security
>> hole somehow.  Maybe we're better off just reseting and restarting the
>> flow entirely.
>>

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


From bburke at redhat.com  Mon Feb 15 09:03:45 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Feb 2016 09:03:45 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
 standalone/configuration/themes
In-Reply-To: <CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
	<56BE2504.4040203@redhat.com>
	<CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>
Message-ID: <56C1DAC1.7050905@redhat.com>

Users will be editing and playing with our existing themes to figure how 
to extend things.  I'll go as far to say that *EVERY* user will do 
this.  It needs to be really easy to do and is just as important as 
playing nicely with the patch mechanism.


On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
>
> Keeping it as is isn't an option IMO. There's a pretty big chance that 
> we will need to patch themes. There's several issues with that as it 
> stands:
>
> * Users need to deal with two separate patching mechanisms and we also 
> need to create tools, patches, documentation separately
> * What if users change the built-in themes, rather than extending. We 
> tell users not to, but if they can they will. If a built-in theme has 
> been changed patches probably won't work
> * EAP supports roll-back of patches, applies patches atomically. It's 
> a proper tool that helps users to do it right
> * EAP supports domain mode
>
> What Stan is proposing might be worth considering. It doesn't solve 
> the case that users can modify the files though.
>
> I would actual prefer that built-in themes are always loaded from the 
> module, but we have the templates available in exames/themes/templates.
>
> Another relevant thing is what do we do when users have modified 
> templates. How can we help them apply the required changes to the 
> custom template?
>
> On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     BTW, how do you deal with theme changes on OpenShift? Looks like a
>     year ago the answer was, "fork the cartridge".  Is that still the
>     only solution?
>
>     http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
>
>     On 2/12/2016 12:46 PM, Bill Burke wrote:
>>     Keep it the way it is, IMO.  Write directions on how to handle a
>>     theme patch.
>>
>>     On 2/12/2016 11:01 AM, Stan Silvert wrote:
>>>     Another way to deal with this might be to unjar the files
>>>     ourselves at startup.  The files could live in the same place
>>>     they live today.
>>>
>>>     We would just have keep track of versioning.  If a newer version
>>>     of the theme is installed we overwrite the old version in
>>>     standlone/configuration/themes.  Of course, if the theme has
>>>     been modified by the user we wouldn't overwrite, but instead
>>>     just unjar to another location.
>>>
>>>     On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>>>
>>>>     Currently we include built-in themes in the themes jar as well
>>>>     as extracted to standalone/configuration/themes. We have to
>>>>     remove the extracted files.
>>>>
>>>>     This is due to patching. The patching tools only supports
>>>>     patching modules, not files. If we need to patch the theme
>>>>     templates (quite likely we will) we can then only patch the
>>>>     jar. As the extracted themes override the jar it won't work
>>>>     unless we remove them.
>>>>
>>>>     The main problem with removing the extracted files is that they
>>>>     are useful for someone that needs to modify the templates. I
>>>>     think the best would just be to give people instructions on how
>>>>     to extract these from the jar. It's just a zip after all.
>>>>
>>>>     Thoughts??
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     keycloak-dev mailing list
>>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>     -- 
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From ssilvert at redhat.com  Mon Feb 15 09:40:14 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 15 Feb 2016 09:40:14 -0500
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <56C1DAC1.7050905@redhat.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
	<56BE2504.4040203@redhat.com>
	<CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>
	<56C1DAC1.7050905@redhat.com>
Message-ID: <56C1E34E.70104@redhat.com>

On 2/15/2016 9:03 AM, Bill Burke wrote:
> Users will be editing and playing with our existing themes to figure 
> how to extend things.  I'll go as far to say that *EVERY* user will do 
> this.  It needs to be really easy to do and is just as important as 
> playing nicely with the patch mechanism.
I agree on making it really easy.

IMO, the real solution is to make themes fully manageable from the admin 
console.  You should be able to upload and download themes. Then, you 
could download the default themes and copy them but not allow overwrite.

This also solves the openshift problem as you would be able to upload 
themes to an openshift-based Keycloak instance.  And, we wouldn't have 
to do anything special to account for the patch tool as the default 
themes would just be read from the module and never modified unless patched.

Obviously, that's more of a long-term solution though.  It would take a 
fair amount of work to implement.

>
> On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
>>
>> Keeping it as is isn't an option IMO. There's a pretty big chance 
>> that we will need to patch themes. There's several issues with that 
>> as it stands:
>>
>> * Users need to deal with two separate patching mechanisms and we 
>> also need to create tools, patches, documentation separately
>> * What if users change the built-in themes, rather than extending. We 
>> tell users not to, but if they can they will. If a built-in theme has 
>> been changed patches probably won't work
>> * EAP supports roll-back of patches, applies patches atomically. It's 
>> a proper tool that helps users to do it right
>> * EAP supports domain mode
>>
>> What Stan is proposing might be worth considering. It doesn't solve 
>> the case that users can modify the files though.
>>
>> I would actual prefer that built-in themes are always loaded from the 
>> module, but we have the templates available in exames/themes/templates.
>>
>> Another relevant thing is what do we do when users have modified 
>> templates. How can we help them apply the required changes to the 
>> custom template?
>>
>> On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com> wrote:
>>
>>     BTW, how do you deal with theme changes on OpenShift?  Looks like
>>     a year ago the answer was, "fork the cartridge".  Is that still
>>     the only solution?
>>
>>     http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
>>
>>     On 2/12/2016 12:46 PM, Bill Burke wrote:
>>>     Keep it the way it is, IMO. Write directions on how to handle a
>>>     theme patch.
>>>
>>>     On 2/12/2016 11:01 AM, Stan Silvert wrote:
>>>>     Another way to deal with this might be to unjar the files
>>>>     ourselves at startup.  The files could live in the same place
>>>>     they live today.
>>>>
>>>>     We would just have keep track of versioning.  If a newer
>>>>     version of the theme is installed we overwrite the old version
>>>>     in standlone/configuration/themes. Of course, if the theme has
>>>>     been modified by the user we wouldn't overwrite, but instead
>>>>     just unjar to another location.
>>>>
>>>>     On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>>>>
>>>>>     Currently we include built-in themes in the themes jar as well
>>>>>     as extracted to standalone/configuration/themes. We have to
>>>>>     remove the extracted files.
>>>>>
>>>>>     This is due to patching. The patching tools only supports
>>>>>     patching modules, not files. If we need to patch the theme
>>>>>     templates (quite likely we will) we can then only patch the
>>>>>     jar. As the extracted themes override the jar it won't work
>>>>>     unless we remove them.
>>>>>
>>>>>     The main problem with removing the extracted files is that
>>>>>     they are useful for someone that needs to modify the
>>>>>     templates. I think the best would just be to give people
>>>>>     instructions on how to extract these from the jar. It's just a
>>>>>     zip after all.
>>>>>
>>>>>     Thoughts??
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     keycloak-dev mailing list
>>>>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     keycloak-dev mailing list
>>>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>     -- 
>>>     Bill Burke
>>>     JBoss, a division of Red Hat
>>>     http://bill.burkecentral.com
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mstrukel at redhat.com  Mon Feb 15 10:15:23 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 15 Feb 2016 16:15:23 +0100
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <56C1E34E.70104@redhat.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
	<56BE2504.4040203@redhat.com>
	<CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>
	<56C1DAC1.7050905@redhat.com> <56C1E34E.70104@redhat.com>
Message-ID: <CA+1OW+iSv8RbDfO-zcRXL1r7aLqZ1ixQB9kqq+Lry5K7=m88iQ@mail.gmail.com>

I'm thinking of a workflow I would find useful, and I think it would
be something like this:

There is a directory with extracted theme files which I don't touch -
$KEYCLOAK_HOME/standalone/configuration/themes/expanded. Keycloak
automatically extracts files into it upon startup. I as a developer do
a 'git init && git add * && git commit -a -m "Keycloak 1.9.0.CR1"' in
it to turn it into a git repo.

My theme development repo is somewhere else on the disk, outside the
KEYCLOAK_HOME, let's say in ~/kc-theme.

In there a have a .git repo with:
git init
git remote add kcinstall
file://$KEYCLOAK_HOME/standalone/configuration/themes/expanded

Now I can do:
git fetch kcinstall
git reset --hard remotes/kcinstall/master

I have my inital custom theme. I make changes and work on it.

When patching is performed on keycloak install it would result in
either complete rewrite of standalone/configuration/themes/expanded or
in only some files changing. If it is the former then I can simply
reinit git repo there as the first time, it it's the latter I just do
'git add * && git commit -a -m "Keycloak 1.9.0.Final"'. Then in my
working dir I say:

git fetch kcinstall
git rebase remotes/kcinstall/master

Now I fix any merge conflicts ...

The effective theme dir for my Keycloak instance can be under
standalone/configuration/themes/public, and in that directory I can
expand my theme copy. Or for development I can configure in
keycloak-server.json to use my working directory ~/ks-theme.



On Mon, Feb 15, 2016 at 3:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> On 2/15/2016 9:03 AM, Bill Burke wrote:
>
> Users will be editing and playing with our existing themes to figure how to
> extend things.  I'll go as far to say that *EVERY* user will do this.  It
> needs to be really easy to do and is just as important as playing nicely
> with the patch mechanism.
>
> I agree on making it really easy.
>
> IMO, the real solution is to make themes fully manageable from the admin
> console.  You should be able to upload and download themes.  Then, you could
> download the default themes and copy them but not allow overwrite.
>
> This also solves the openshift problem as you would be able to upload themes
> to an openshift-based Keycloak instance.  And, we wouldn't have to do
> anything special to account for the patch tool as the default themes would
> just be read from the module and never modified unless patched.
>
> Obviously, that's more of a long-term solution though.  It would take a fair
> amount of work to implement.
>
>
>
> On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
>
> Keeping it as is isn't an option IMO. There's a pretty big chance that we
> will need to patch themes. There's several issues with that as it stands:
>
> * Users need to deal with two separate patching mechanisms and we also need
> to create tools, patches, documentation separately
> * What if users change the built-in themes, rather than extending. We tell
> users not to, but if they can they will. If a built-in theme has been
> changed patches probably won't work
> * EAP supports roll-back of patches, applies patches atomically. It's a
> proper tool that helps users to do it right
> * EAP supports domain mode
>
> What Stan is proposing might be worth considering. It doesn't solve the case
> that users can modify the files though.
>
> I would actual prefer that built-in themes are always loaded from the
> module, but we have the templates available in exames/themes/templates.
>
> Another relevant thing is what do we do when users have modified templates.
> How can we help them apply the required changes to the custom template?
>
> On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com> wrote:
>>
>> BTW, how do you deal with theme changes on OpenShift?  Looks like a year
>> ago the answer was, "fork the cartridge".  Is that still the only solution?
>>
>> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
>>
>> On 2/12/2016 12:46 PM, Bill Burke wrote:
>>
>> Keep it the way it is, IMO.  Write directions on how to handle a theme
>> patch.
>>
>> On 2/12/2016 11:01 AM, Stan Silvert wrote:
>>
>> Another way to deal with this might be to unjar the files ourselves at
>> startup.  The files could live in the same place they live today.
>>
>> We would just have keep track of versioning.  If a newer version of the
>> theme is installed we overwrite the old version in
>> standlone/configuration/themes.  Of course, if the theme has been modified
>> by the user we wouldn't overwrite, but instead just unjar to another
>> location.
>>
>> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
>>
>> Currently we include built-in themes in the themes jar as well as
>> extracted to standalone/configuration/themes. We have to remove the
>> extracted files.
>>
>> This is due to patching. The patching tools only supports patching
>> modules, not files. If we need to patch the theme templates (quite likely we
>> will) we can then only patch the jar. As the extracted themes override the
>> jar it won't work unless we remove them.
>>
>> The main problem with removing the extracted files is that they are useful
>> for someone that needs to modify the templates. I think the best would just
>> be to give people instructions on how to extract these from the jar. It's
>> just a zip after all.
>>
>> 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
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Mon Feb 15 10:35:04 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 15 Feb 2016 10:35:04 -0500
Subject: [keycloak-dev] unmodifiable ok?
Message-ID: <56C1F028.8030305@redhat.com>

I've gone through the cache and model Realm Adapters and reduced copying 
as much as possible and made every collection returned unmodifiable.  Is 
that ok with everybody?

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


From sthorger at redhat.com  Mon Feb 15 11:50:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 15 Feb 2016 17:50:49 +0100
Subject: [keycloak-dev] unmodifiable ok?
In-Reply-To: <56C1F028.8030305@redhat.com>
References: <56C1F028.8030305@redhat.com>
Message-ID: <CAJgngAcCN82asazfk3_wjFfPZMz-yWoFnAgfxxmQQUVzu4cYgw@mail.gmail.com>

+1 They should have been unmodifiable all along
On 15 Feb 2016 15:35, "Bill Burke" <bburke at redhat.com> wrote:

> I've gone through the cache and model Realm Adapters and reduced copying
> as much as possible and made every collection returned unmodifiable.  Is
> that ok with everybody?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160215/2c4d19d0/attachment.html 

From ayoung at redhat.com  Tue Feb 16 00:07:20 2016
From: ayoung at redhat.com (Adam Young)
Date: Tue, 16 Feb 2016 00:07:20 -0500
Subject: [keycloak-dev] Protecting/encrypting realm keys
In-Reply-To: <56B9FA66.9020805@redhat.com>
References: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
	<CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>
	<56B9FA66.9020805@redhat.com>
Message-ID: <56C2AE88.3030408@redhat.com>

On 02/09/2016 09:40 AM, John Dennis wrote:
> On 02/08/2016 02:08 PM, Stian Thorgersen wrote:
>> In essence the work would be to create a Encryption SPI and a default
>> implementation. The default implementation would rely on the keys stored
>> in the database. I'm not aware of any standard or libraries that can be
>> used to communicate with HSM devices so I would imagine implementations
>> for specific HSM vendors would have to be done by users themselves.
> There are C libraries to support HSM devices. I think the big question
> would be if they are Linux specific or not or if there are Java
> bindings. I know the Certificate Server (i.e. Dogtag) that Red Hat ships
> is written in Java and has HSM support. I also believe some of this is
> in transition. I would suggest a conversation with Ade Lee
> (alee at redhat.com) who would have more detailed information.

So, wouldn't the abstraction be NSS, and the Binding be the TomcatNSS 
libraries?





>
> HTH,
>


From bruno at abstractj.org  Tue Feb 16 05:06:00 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 16 Feb 2016 08:06:00 -0200
Subject: [keycloak-dev] Protecting/encrypting realm keys
In-Reply-To: <56C2AE88.3030408@redhat.com>
References: <D1E2C829C5011E4A84DAF8A184DD7CDA0E3EBC0125@BEL1EXCH02.amer.sfnt.local>
	<CAJgngAeMjxGm2+ticNvebCp6wALXh-x_XBWmDJdwfL6n2ud9Lw@mail.gmail.com>
	<56B9FA66.9020805@redhat.com> <56C2AE88.3030408@redhat.com>
Message-ID: <CAM5SUC4n2uE4bxA9nY0Q7bHNTJs-ZQKd3WwFOxKnXJTSwi5VVw@mail.gmail.com>

My 2 cents here, I'd take a look at YubiHSM. Which has SDKs for Python
and Java (https://developers.yubico.com/Software_Projects/YubiHSM/)
and can be easily integrate with solutions like LinOTP
(https://linotp.org/doc/latest/part-management/securitymodule.html)

On Tue, Feb 16, 2016 at 3:07 AM, Adam Young <ayoung at redhat.com> wrote:
> On 02/09/2016 09:40 AM, John Dennis wrote:
>> On 02/08/2016 02:08 PM, Stian Thorgersen wrote:
>>> In essence the work would be to create a Encryption SPI and a default
>>> implementation. The default implementation would rely on the keys stored
>>> in the database. I'm not aware of any standard or libraries that can be
>>> used to communicate with HSM devices so I would imagine implementations
>>> for specific HSM vendors would have to be done by users themselves.
>> There are C libraries to support HSM devices. I think the big question
>> would be if they are Linux specific or not or if there are Java
>> bindings. I know the Certificate Server (i.e. Dogtag) that Red Hat ships
>> is written in Java and has HSM support. I also believe some of this is
>> in transition. I would suggest a conversation with Ade Lee
>> (alee at redhat.com) who would have more detailed information.
>
> So, wouldn't the abstraction be NSS, and the Binding be the TomcatNSS
> libraries?
>
>
>
>
>
>>
>> HTH,
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj

From sthorger at redhat.com  Tue Feb 16 10:40:52 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 16 Feb 2016 16:40:52 +0100
Subject: [keycloak-dev] Need to remove built-in themes from
	standalone/configuration/themes
In-Reply-To: <CA+1OW+iSv8RbDfO-zcRXL1r7aLqZ1ixQB9kqq+Lry5K7=m88iQ@mail.gmail.com>
References: <CAJgngAdaa0OvWtXTD7nUGXsE5S7zF-C=zKUSEe3vPNgM75W=Sg@mail.gmail.com>
	<56BE01F3.7060904@redhat.com> <56BE1A8B.2060004@redhat.com>
	<56BE2504.4040203@redhat.com>
	<CAJgngAcOj-fX-WShy+mRi=Z-03Qidzpa6+SnrgG3ZuoRB73kBA@mail.gmail.com>
	<56C1DAC1.7050905@redhat.com> <56C1E34E.70104@redhat.com>
	<CA+1OW+iSv8RbDfO-zcRXL1r7aLqZ1ixQB9kqq+Lry5K7=m88iQ@mail.gmail.com>
Message-ID: <CAJgngAeSvj9qrEGtmqfS6nVgpLG1Xgv+pCz-6eWH2o-XrSbJyg@mail.gmail.com>

We've had chats with folks that know about the patching tools now and it
turns out that by simply moving the themes from
standalone/configuration/themes they can be patched. If someone has changed
the built-in themes they will get a warning and be asked if they want to
cancel the patching or overwrite the file.

So problem solved by simply moving themes from
standalone/configuration/themes to standalone/themes.

On 15 February 2016 at 16:15, Marko Strukelj <mstrukel at redhat.com> wrote:

> I'm thinking of a workflow I would find useful, and I think it would
> be something like this:
>
> There is a directory with extracted theme files which I don't touch -
> $KEYCLOAK_HOME/standalone/configuration/themes/expanded. Keycloak
> automatically extracts files into it upon startup. I as a developer do
> a 'git init && git add * && git commit -a -m "Keycloak 1.9.0.CR1"' in
> it to turn it into a git repo.
>
> My theme development repo is somewhere else on the disk, outside the
> KEYCLOAK_HOME, let's say in ~/kc-theme.
>
> In there a have a .git repo with:
> git init
> git remote add kcinstall
> file://$KEYCLOAK_HOME/standalone/configuration/themes/expanded
>
> Now I can do:
> git fetch kcinstall
> git reset --hard remotes/kcinstall/master
>
> I have my inital custom theme. I make changes and work on it.
>
> When patching is performed on keycloak install it would result in
> either complete rewrite of standalone/configuration/themes/expanded or
> in only some files changing. If it is the former then I can simply
> reinit git repo there as the first time, it it's the latter I just do
> 'git add * && git commit -a -m "Keycloak 1.9.0.Final"'. Then in my
> working dir I say:
>
> git fetch kcinstall
> git rebase remotes/kcinstall/master
>
> Now I fix any merge conflicts ...
>
> The effective theme dir for my Keycloak instance can be under
> standalone/configuration/themes/public, and in that directory I can
> expand my theme copy. Or for development I can configure in
> keycloak-server.json to use my working directory ~/ks-theme.
>
>
>
> On Mon, Feb 15, 2016 at 3:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> > On 2/15/2016 9:03 AM, Bill Burke wrote:
> >
> > Users will be editing and playing with our existing themes to figure how
> to
> > extend things.  I'll go as far to say that *EVERY* user will do this.  It
> > needs to be really easy to do and is just as important as playing nicely
> > with the patch mechanism.
> >
> > I agree on making it really easy.
> >
> > IMO, the real solution is to make themes fully manageable from the admin
> > console.  You should be able to upload and download themes.  Then, you
> could
> > download the default themes and copy them but not allow overwrite.
> >
> > This also solves the openshift problem as you would be able to upload
> themes
> > to an openshift-based Keycloak instance.  And, we wouldn't have to do
> > anything special to account for the patch tool as the default themes
> would
> > just be read from the module and never modified unless patched.
> >
> > Obviously, that's more of a long-term solution though.  It would take a
> fair
> > amount of work to implement.
> >
> >
> >
> > On 2/15/2016 4:08 AM, Stian Thorgersen wrote:
> >
> > Keeping it as is isn't an option IMO. There's a pretty big chance that we
> > will need to patch themes. There's several issues with that as it stands:
> >
> > * Users need to deal with two separate patching mechanisms and we also
> need
> > to create tools, patches, documentation separately
> > * What if users change the built-in themes, rather than extending. We
> tell
> > users not to, but if they can they will. If a built-in theme has been
> > changed patches probably won't work
> > * EAP supports roll-back of patches, applies patches atomically. It's a
> > proper tool that helps users to do it right
> > * EAP supports domain mode
> >
> > What Stan is proposing might be worth considering. It doesn't solve the
> case
> > that users can modify the files though.
> >
> > I would actual prefer that built-in themes are always loaded from the
> > module, but we have the templates available in exames/themes/templates.
> >
> > Another relevant thing is what do we do when users have modified
> templates.
> > How can we help them apply the required changes to the custom template?
> >
> > On 12 Feb 2016 19:32, "Stan Silvert" <ssilvert at redhat.com> wrote:
> >>
> >> BTW, how do you deal with theme changes on OpenShift?  Looks like a year
> >> ago the answer was, "fork the cartridge".  Is that still the only
> solution?
> >>
> >>
> http://lists.jboss.org/pipermail/keycloak-user/2015-February/001675.html
> >>
> >> On 2/12/2016 12:46 PM, Bill Burke wrote:
> >>
> >> Keep it the way it is, IMO.  Write directions on how to handle a theme
> >> patch.
> >>
> >> On 2/12/2016 11:01 AM, Stan Silvert wrote:
> >>
> >> Another way to deal with this might be to unjar the files ourselves at
> >> startup.  The files could live in the same place they live today.
> >>
> >> We would just have keep track of versioning.  If a newer version of the
> >> theme is installed we overwrite the old version in
> >> standlone/configuration/themes.  Of course, if the theme has been
> modified
> >> by the user we wouldn't overwrite, but instead just unjar to another
> >> location.
> >>
> >> On 2/12/2016 9:44 AM, Stian Thorgersen wrote:
> >>
> >> Currently we include built-in themes in the themes jar as well as
> >> extracted to standalone/configuration/themes. We have to remove the
> >> extracted files.
> >>
> >> This is due to patching. The patching tools only supports patching
> >> modules, not files. If we need to patch the theme templates (quite
> likely we
> >> will) we can then only patch the jar. As the extracted themes override
> the
> >> jar it won't work unless we remove them.
> >>
> >> The main problem with removing the extracted files is that they are
> useful
> >> for someone that needs to modify the templates. I think the best would
> just
> >> be to give people instructions on how to extract these from the jar.
> It's
> >> just a zip after all.
> >>
> >> 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
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160216/369bcfb0/attachment-0001.html 

From sthorger at redhat.com  Tue Feb 16 11:07:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 16 Feb 2016 17:07:06 +0100
Subject: [keycloak-dev] Moving modules to modules/system/layers/keycloak and
	modules/system/add-ons/keycloak
Message-ID: <CAJgngAfRqSjjWo+e2pHFdFN_eJHODzFu5PrBdEX0QKMvgkx9aQ@mail.gmail.com>

Currently all our modules are in module/system/layers/base. This is not
good from a patching perspective.

Modules for the standalone server should be in
modules/system/layers/keycloak.

Modules for adapters and server overlay should be in
modules/system/add-ons/keycloak.

I've asked Marko to sort this out so that it's fixed for 1.9.0.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160216/da62c16c/attachment.html 

From mposolda at redhat.com  Wed Feb 17 07:50:08 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 13:50:08 +0100
Subject: [keycloak-dev] Concurrent sync in cluster
Message-ID: <56C46C80.8070506@redhat.com>

We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there 
are errors when sync of users from federationProvider is triggered 
concurrently in more cluster nodes. This affects periodic sync as well.

To avoid concurrent executions of same task, I've added ClusterProvider. 
This is based on infinispan and it provides some locking functionality 
to ensures that sync from federation can be executed just by one cluster 
node at a time. Even on single node (non-cluster setup), now you can't 
trigger sync multiple times concurrently. So for example if there is 
periodic sync in progress and you click in admin console on "Sync 
users", the sync won't happen.

The same mechanism is now also used for scheduled tasks (Removing 
expired user sessions and expired events). Nobody reported any bug yet, 
however when removing of expired events/sessions is triggered 
concurrently by more cluster nodes, it can be issue too. So this is now 
avoided. Maybe we can improve even more and ensure that just cluster 
coordinator will run scheduled tasks and other nodes will just ignore them?

ClusterProvider also adds possibility to register ClusterListener with 
any task, that should be executed once notification from any cluster 
node comes. This allows that when some federation provider is 
created/updated/removed, then all nodes are aware of the change and will 
immediately change (or remove) scheduled timer.

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

Marek

From psilva at redhat.com  Wed Feb 17 08:14:18 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 08:14:18 -0500 (EST)
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <56C46C80.8070506@redhat.com>
References: <56C46C80.8070506@redhat.com>
Message-ID: <124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>

Instead of locking could you identify the coordinator and only sync from federation from the corresponding node ?

Regards.
Pedro Igor

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 17, 2016 10:50:08 AM
Subject: [keycloak-dev] Concurrent sync in cluster

We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there 
are errors when sync of users from federationProvider is triggered 
concurrently in more cluster nodes. This affects periodic sync as well.

To avoid concurrent executions of same task, I've added ClusterProvider. 
This is based on infinispan and it provides some locking functionality 
to ensures that sync from federation can be executed just by one cluster 
node at a time. Even on single node (non-cluster setup), now you can't 
trigger sync multiple times concurrently. So for example if there is 
periodic sync in progress and you click in admin console on "Sync 
users", the sync won't happen.

The same mechanism is now also used for scheduled tasks (Removing 
expired user sessions and expired events). Nobody reported any bug yet, 
however when removing of expired events/sessions is triggered 
concurrently by more cluster nodes, it can be issue too. So this is now 
avoided. Maybe we can improve even more and ensure that just cluster 
coordinator will run scheduled tasks and other nodes will just ignore them?

ClusterProvider also adds possibility to register ClusterListener with 
any task, that should be executed once notification from any cluster 
node comes. This allows that when some federation provider is 
created/updated/removed, then all nodes are aware of the change and will 
immediately change (or remove) scheduled timer.

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

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 Feb 17 08:48:43 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 14:48:43 +0100
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
Message-ID: <56C47A3B.10706@redhat.com>

Was thinking about it. The thing is that we support both periodic and 
manual sync. And the manual sync can be triggered on any cluster node. 
You can even reproduce issue in non-cluster environment with single host 
if you trigger concurrently 2 sync at the same time (or if periodic is 
in progress and you trigger manual etc).

The possibility to trigger on coordinator should work for scheduled 
periodic cleanup tasks though. We don't support manual triggering for 
them. Wonder if I should change this to trigger it always just on 
coordinator.

Btv. I am not using any real long-live lock, just the kind of 
"pseudo-lock" (based on the presence of some particular item in the 
cache, which is removed once the task is finished).


Marek


On 17/02/16 14:14, Pedro Igor Silva wrote:
> Instead of locking could you identify the coordinator and only sync from federation from the corresponding node ?
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 10:50:08 AM
> Subject: [keycloak-dev] Concurrent sync in cluster
>
> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
> are errors when sync of users from federationProvider is triggered
> concurrently in more cluster nodes. This affects periodic sync as well.
>
> To avoid concurrent executions of same task, I've added ClusterProvider.
> This is based on infinispan and it provides some locking functionality
> to ensures that sync from federation can be executed just by one cluster
> node at a time. Even on single node (non-cluster setup), now you can't
> trigger sync multiple times concurrently. So for example if there is
> periodic sync in progress and you click in admin console on "Sync
> users", the sync won't happen.
>
> The same mechanism is now also used for scheduled tasks (Removing
> expired user sessions and expired events). Nobody reported any bug yet,
> however when removing of expired events/sessions is triggered
> concurrently by more cluster nodes, it can be issue too. So this is now
> avoided. Maybe we can improve even more and ensure that just cluster
> coordinator will run scheduled tasks and other nodes will just ignore them?
>
> ClusterProvider also adds possibility to register ClusterListener with
> any task, that should be executed once notification from any cluster
> node comes. This allows that when some federation provider is
> created/updated/removed, then all nodes are aware of the change and will
> immediately change (or remove) scheduled timer.
>
> PR is here https://github.com/keycloak/keycloak/pull/2234
>
> 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 Feb 17 08:55:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 14:55:24 +0100
Subject: [keycloak-dev] caching changes
In-Reply-To: <56BE28B3.7070707@redhat.com>
References: <56BE28B3.7070707@redhat.com>
Message-ID: <56C47BCC.2080009@redhat.com>

Should this be done for user's cache too? Couldn't it happen that same 
user is concurrently updated by 2 threads?

Also wonder about scenario like:
- 2 admin users are editing realm at the same time
- Admin1 enables user's registration for the realm and click "update"
- Admin2 changed access token timeout and then click "update" . AFAIK at 
this point, he overwrites the change by admin1 because we send whole 
realm representation in the request.

Do we want to address this? Or is this rather a corner case?

Marek


On 12/02/16 19:47, Bill Burke wrote:
> I'm still working on stuff, but here is a summary of things so far:
> * ConcurrenyTest is passing
> * Caching implementation is now a pessimistic locking style based on
> versions.  Locking never happens on reads, only writes.  There are two
> caches.  One cache holds the actual data, and is pretty much a vanilla
> invalidation cache.  The other cache olds versioning information and is
> a local-only cache and just is an id->version map.  Given an id, what is
> the current version of it.  Hopefully, the implementation makes sure
> that you never are able to add or obtain a stale version of an object
> from the cache.  Locking happens for updates.  At the end of a
> transaction, all registered invalidations are iterated on, and a version
> cache lock on that id is obtain.  The db is updated, and after that the
> locks are released.  A lock is also obtained whever something is added
> to the cache.  Again a lock is only obtained on the version cache, so
> any reads will never block.
> * KeycloakTransactionManager now has an enlistPrepare method.
> * There is a new RealmProvider.getClientByClientId() method. Clients now
> have a clientId "index" in the cache.
> * There is a new RealmProvider.removeClient() method.  This was needed
> to support getClientByClientId()
>
> Some other things that were done:
> * Unnecessary @JoinTables were removed for certain @OneToMany relationships.
> * getId() will no longer cause a DB query if you are invoking on a
> reference to a JPA adapter
> * RealmModel.getClients() and getClientNameMap() is no longer used to
> implement getClientByClientId() :)
> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
> transient variable.  We were actually unmarshalling from the cached pem
> format every time these things were access, which is like few times per
> login.
>
> Next steps:
> * Create a client list cache for each realm.  Currently, if you
> add/remove a client, this invalidates the realm cache and its doing a
> big query for each client.
> *  Do some profiling to see if there's other things we can do.
>


From psilva at redhat.com  Wed Feb 17 09:06:36 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 09:06:36 -0500 (EST)
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <56C47A3B.10706@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
	<56C47A3B.10706@redhat.com>
Message-ID: <1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>

I think it makes more sense to not spread administrative operations on different nodes, but just on the coordinator. That would make the design more predictable and make life easier when something wrong happens, given that you know that only a specific node is able to perform the operation.

Not sure how manual works, but in theory you can have a specific cache or just use a known-entry to propagate coordinator related events. So when you trigger a sync you don't really start the work but indicates to the coordinator that a sync was triggered. You still need the lock though, but that will be only a coordinator specific thing.

Regards.
Pedro Igor

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 17, 2016 11:48:43 AM
Subject: Re: [keycloak-dev] Concurrent sync in cluster

Was thinking about it. The thing is that we support both periodic and 
manual sync. And the manual sync can be triggered on any cluster node. 
You can even reproduce issue in non-cluster environment with single host 
if you trigger concurrently 2 sync at the same time (or if periodic is 
in progress and you trigger manual etc).

The possibility to trigger on coordinator should work for scheduled 
periodic cleanup tasks though. We don't support manual triggering for 
them. Wonder if I should change this to trigger it always just on 
coordinator.

Btv. I am not using any real long-live lock, just the kind of 
"pseudo-lock" (based on the presence of some particular item in the 
cache, which is removed once the task is finished).


Marek


On 17/02/16 14:14, Pedro Igor Silva wrote:
> Instead of locking could you identify the coordinator and only sync from federation from the corresponding node ?
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 10:50:08 AM
> Subject: [keycloak-dev] Concurrent sync in cluster
>
> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
> are errors when sync of users from federationProvider is triggered
> concurrently in more cluster nodes. This affects periodic sync as well.
>
> To avoid concurrent executions of same task, I've added ClusterProvider.
> This is based on infinispan and it provides some locking functionality
> to ensures that sync from federation can be executed just by one cluster
> node at a time. Even on single node (non-cluster setup), now you can't
> trigger sync multiple times concurrently. So for example if there is
> periodic sync in progress and you click in admin console on "Sync
> users", the sync won't happen.
>
> The same mechanism is now also used for scheduled tasks (Removing
> expired user sessions and expired events). Nobody reported any bug yet,
> however when removing of expired events/sessions is triggered
> concurrently by more cluster nodes, it can be issue too. So this is now
> avoided. Maybe we can improve even more and ensure that just cluster
> coordinator will run scheduled tasks and other nodes will just ignore them?
>
> ClusterProvider also adds possibility to register ClusterListener with
> any task, that should be executed once notification from any cluster
> node comes. This allows that when some federation provider is
> created/updated/removed, then all nodes are aware of the change and will
> immediately change (or remove) scheduled timer.
>
> PR is here https://github.com/keycloak/keycloak/pull/2234
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Feb 17 09:44:40 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 09:44:40 -0500
Subject: [keycloak-dev] caching changes
In-Reply-To: <56C47BCC.2080009@redhat.com>
References: <56BE28B3.7070707@redhat.com> <56C47BCC.2080009@redhat.com>
Message-ID: <56C48758.1050002@redhat.com>

Even if you have caching off this is a problem.  You have to do this:

* In RepresentationToModel, don't call setters on properties that have 
equal values
* If its not already set, change hibernate to optimized updates, don't 
update fields that haven't changed

On 2/17/2016 8:55 AM, Marek Posolda wrote:
> Should this be done for user's cache too? Couldn't it happen that same 
> user is concurrently updated by 2 threads?
>
> Also wonder about scenario like:
> - 2 admin users are editing realm at the same time
> - Admin1 enables user's registration for the realm and click "update"
> - Admin2 changed access token timeout and then click "update" . AFAIK 
> at this point, he overwrites the change by admin1 because we send 
> whole realm representation in the request.
>
> Do we want to address this? Or is this rather a corner case?
>
> Marek
>
>
> On 12/02/16 19:47, Bill Burke wrote:
>> I'm still working on stuff, but here is a summary of things so far:
>> * ConcurrenyTest is passing
>> * Caching implementation is now a pessimistic locking style based on
>> versions.  Locking never happens on reads, only writes.  There are two
>> caches.  One cache holds the actual data, and is pretty much a vanilla
>> invalidation cache.  The other cache olds versioning information and is
>> a local-only cache and just is an id->version map.  Given an id, what is
>> the current version of it.  Hopefully, the implementation makes sure
>> that you never are able to add or obtain a stale version of an object
>> from the cache.  Locking happens for updates.  At the end of a
>> transaction, all registered invalidations are iterated on, and a version
>> cache lock on that id is obtain.  The db is updated, and after that the
>> locks are released.  A lock is also obtained whever something is added
>> to the cache.  Again a lock is only obtained on the version cache, so
>> any reads will never block.
>> * KeycloakTransactionManager now has an enlistPrepare method.
>> * There is a new RealmProvider.getClientByClientId() method. Clients now
>> have a clientId "index" in the cache.
>> * There is a new RealmProvider.removeClient() method.  This was needed
>> to support getClientByClientId()
>>
>> Some other things that were done:
>> * Unnecessary @JoinTables were removed for certain @OneToMany 
>> relationships.
>> * getId() will no longer cause a DB query if you are invoking on a
>> reference to a JPA adapter
>> * RealmModel.getClients() and getClientNameMap() is no longer used to
>> implement getClientByClientId() :)
>> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
>> transient variable.  We were actually unmarshalling from the cached pem
>> format every time these things were access, which is like few times per
>> login.
>>
>> Next steps:
>> * Create a client list cache for each realm.  Currently, if you
>> add/remove a client, this invalidates the realm cache and its doing a
>> big query for each client.
>> *  Do some profiling to see if there's other things we can do.
>>
>

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


From mposolda at redhat.com  Wed Feb 17 09:50:42 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 15:50:42 +0100
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
	<56C47A3B.10706@redhat.com>
	<1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>
Message-ID: <56C488C2.3060102@redhat.com>

On 17/02/16 15:06, Pedro Igor Silva wrote:
> I think it makes more sense to not spread administrative operations on different nodes, but just on the coordinator. That would make the design more predictable and make life easier when something wrong happens, given that you know that only a specific node is able to perform the operation.
>
> Not sure how manual works, but in theory you can have a specific cache or just use a known-entry to propagate coordinator related events. So when you trigger a sync you don't really start the work but indicates to the coordinator that a sync was triggered. You still need the lock though, but that will be only a coordinator specific thing.
Yeah, some kind of "locking" is always needed as issue can be seen even 
on single node. When the locking mechanism is cluster-aware then even 
better, regarding implementation it's not a big difference.

Regarding every background task running on coordinator, there is the 
disadvantage of this IMO, that coordinator is under bigger workload.

For the future versions, we discussed some improvements planned like:
- Possibility to see the progress in admin console (how many users were 
synced already, possibility to cancel task etc)
- Possibility to run the sync in "distributable" manner. So that the 
sync can be always started on coordinator as you suggested, but 
coordinator will share the workload with other cluster nodes and 
"manage" the work (ie. node1 is supposed to do page1+page2 and node2 
page3+page4 etc). We already use something like this based on infinispan 
Distributable executor service [1], which is very cool stuff IMO. Don't 
you think this is better regarding workload (and time of the task) then 
always execute everything on coordinator?

Unfortunately we are in the "bugfixing" phase and just addressing bugs, 
seems that all the other features will need to wait...

[1] 
http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#DistributedExecutor

Marek
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 11:48:43 AM
> Subject: Re: [keycloak-dev] Concurrent sync in cluster
>
> Was thinking about it. The thing is that we support both periodic and
> manual sync. And the manual sync can be triggered on any cluster node.
> You can even reproduce issue in non-cluster environment with single host
> if you trigger concurrently 2 sync at the same time (or if periodic is
> in progress and you trigger manual etc).
>
> The possibility to trigger on coordinator should work for scheduled
> periodic cleanup tasks though. We don't support manual triggering for
> them. Wonder if I should change this to trigger it always just on
> coordinator.
>
> Btv. I am not using any real long-live lock, just the kind of
> "pseudo-lock" (based on the presence of some particular item in the
> cache, which is removed once the task is finished).
>
>
> Marek
>
>
> On 17/02/16 14:14, Pedro Igor Silva wrote:
>> Instead of locking could you identify the coordinator and only sync from federation from the corresponding node ?
>>
>> Regards.
>> Pedro Igor
>>
>> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 17, 2016 10:50:08 AM
>> Subject: [keycloak-dev] Concurrent sync in cluster
>>
>> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
>> are errors when sync of users from federationProvider is triggered
>> concurrently in more cluster nodes. This affects periodic sync as well.
>>
>> To avoid concurrent executions of same task, I've added ClusterProvider.
>> This is based on infinispan and it provides some locking functionality
>> to ensures that sync from federation can be executed just by one cluster
>> node at a time. Even on single node (non-cluster setup), now you can't
>> trigger sync multiple times concurrently. So for example if there is
>> periodic sync in progress and you click in admin console on "Sync
>> users", the sync won't happen.
>>
>> The same mechanism is now also used for scheduled tasks (Removing
>> expired user sessions and expired events). Nobody reported any bug yet,
>> however when removing of expired events/sessions is triggered
>> concurrently by more cluster nodes, it can be issue too. So this is now
>> avoided. Maybe we can improve even more and ensure that just cluster
>> coordinator will run scheduled tasks and other nodes will just ignore them?
>>
>> ClusterProvider also adds possibility to register ClusterListener with
>> any task, that should be executed once notification from any cluster
>> node comes. This allows that when some federation provider is
>> created/updated/removed, then all nodes are aware of the change and will
>> immediately change (or remove) scheduled timer.
>>
>> PR is here https://github.com/keycloak/keycloak/pull/2234
>>
>> 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 Feb 17 10:03:16 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 16:03:16 +0100
Subject: [keycloak-dev] caching changes
In-Reply-To: <56C48758.1050002@redhat.com>
References: <56BE28B3.7070707@redhat.com> <56C47BCC.2080009@redhat.com>
	<56C48758.1050002@redhat.com>
Message-ID: <56C48BB4.80608@redhat.com>

The thing is, when admin2 press "update realm" , the data on server are 
already updated from admin1. So he will see the value of 
"registrationEnabled" field is true and overrides it with his value false.

It seems the possibilitity to address this might be to add "version" 
column in DB. The version is sent to UI of admin console, but it's 
hidden. When admin2 press "update", he will send the version back and he 
will see that version in DB is bigger than expected, so someone updated 
realm in the meantime.

But I don't know if this is really issue which needs to be solved or 
rather corner case...

Marek

On 17/02/16 15:44, Bill Burke wrote:
> Even if you have caching off this is a problem.  You have to do this:
>
> * In RepresentationToModel, don't call setters on properties that have 
> equal values
> * If its not already set, change hibernate to optimized updates, don't 
> update fields that haven't changed
>
> On 2/17/2016 8:55 AM, Marek Posolda wrote:
>> Should this be done for user's cache too? Couldn't it happen that 
>> same user is concurrently updated by 2 threads?
>>
>> Also wonder about scenario like:
>> - 2 admin users are editing realm at the same time
>> - Admin1 enables user's registration for the realm and click "update"
>> - Admin2 changed access token timeout and then click "update" . AFAIK 
>> at this point, he overwrites the change by admin1 because we send 
>> whole realm representation in the request.
>>
>> Do we want to address this? Or is this rather a corner case?
>>
>> Marek
>>
>>
>> On 12/02/16 19:47, Bill Burke wrote:
>>> I'm still working on stuff, but here is a summary of things so far:
>>> * ConcurrenyTest is passing
>>> * Caching implementation is now a pessimistic locking style based on
>>> versions.  Locking never happens on reads, only writes.  There are two
>>> caches.  One cache holds the actual data, and is pretty much a vanilla
>>> invalidation cache.  The other cache olds versioning information and is
>>> a local-only cache and just is an id->version map.  Given an id, 
>>> what is
>>> the current version of it.  Hopefully, the implementation makes sure
>>> that you never are able to add or obtain a stale version of an object
>>> from the cache.  Locking happens for updates.  At the end of a
>>> transaction, all registered invalidations are iterated on, and a 
>>> version
>>> cache lock on that id is obtain.  The db is updated, and after that the
>>> locks are released.  A lock is also obtained whever something is added
>>> to the cache.  Again a lock is only obtained on the version cache, so
>>> any reads will never block.
>>> * KeycloakTransactionManager now has an enlistPrepare method.
>>> * There is a new RealmProvider.getClientByClientId() method. Clients 
>>> now
>>> have a clientId "index" in the cache.
>>> * There is a new RealmProvider.removeClient() method.  This was needed
>>> to support getClientByClientId()
>>>
>>> Some other things that were done:
>>> * Unnecessary @JoinTables were removed for certain @OneToMany 
>>> relationships.
>>> * getId() will no longer cause a DB query if you are invoking on a
>>> reference to a JPA adapter
>>> * RealmModel.getClients() and getClientNameMap() is no longer used to
>>> implement getClientByClientId() :)
>>> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
>>> transient variable.  We were actually unmarshalling from the cached pem
>>> format every time these things were access, which is like few times per
>>> login.
>>>
>>> Next steps:
>>> * Create a client list cache for each realm.  Currently, if you
>>> add/remove a client, this invalidates the realm cache and its doing a
>>> big query for each client.
>>> *  Do some profiling to see if there's other things we can do.
>>>
>>
>


From psilva at redhat.com  Wed Feb 17 10:13:14 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 10:13:14 -0500 (EST)
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <56C488C2.3060102@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
	<56C47A3B.10706@redhat.com>
	<1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>
	<56C488C2.3060102@redhat.com>
Message-ID: <1239786216.24356666.1455721994900.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 12:50:42 PM
> Subject: Re: [keycloak-dev] Concurrent sync in cluster
> 
> On 17/02/16 15:06, Pedro Igor Silva wrote:
> > I think it makes more sense to not spread administrative operations on
> > different nodes, but just on the coordinator. That would make the design
> > more predictable and make life easier when something wrong happens, given
> > that you know that only a specific node is able to perform the operation.
> >
> > Not sure how manual works, but in theory you can have a specific cache or
> > just use a known-entry to propagate coordinator related events. So when
> > you trigger a sync you don't really start the work but indicates to the
> > coordinator that a sync was triggered. You still need the lock though, but
> > that will be only a coordinator specific thing.
> Yeah, some kind of "locking" is always needed as issue can be seen even
> on single node. When the locking mechanism is cluster-aware then even
> better, regarding implementation it's not a big difference.
> 
> Regarding every background task running on coordinator, there is the
> disadvantage of this IMO, that coordinator is under bigger workload.

True, but I would avoid distribute processing as much as possible. However, I'm sure you want that to address some existing performance issues though.

> 
> For the future versions, we discussed some improvements planned like:
> - Possibility to see the progress in admin console (how many users were
> synced already, possibility to cancel task etc)
> - Possibility to run the sync in "distributable" manner. So that the
> sync can be always started on coordinator as you suggested, but
> coordinator will share the workload with other cluster nodes and
> "manage" the work (ie. node1 is supposed to do page1+page2 and node2
> page3+page4 etc). We already use something like this based on infinispan
> Distributable executor service [1], which is very cool stuff IMO. Don't
> you think this is better regarding workload (and time of the task) then
> always execute everything on coordinator?

Yeah, it is a very cool feature in ISPN, but how better is, depends. At the end you are using multiple producers (each node with their respective pages) writing to the same repository. Before answering your question, I would evaluate how much the end repository can handle concurrent transactions. Depending on how a database is configured, a single writer can perform better.

> 
> Unfortunately we are in the "bugfixing" phase and just addressing bugs,
> seems that all the other features will need to wait...
> 
> [1]
> http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#DistributedExecutor
> 
> Marek
> >
> > Regards.
> > Pedro Igor
> >
> > ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, February 17, 2016 11:48:43 AM
> > Subject: Re: [keycloak-dev] Concurrent sync in cluster
> >
> > Was thinking about it. The thing is that we support both periodic and
> > manual sync. And the manual sync can be triggered on any cluster node.
> > You can even reproduce issue in non-cluster environment with single host
> > if you trigger concurrently 2 sync at the same time (or if periodic is
> > in progress and you trigger manual etc).
> >
> > The possibility to trigger on coordinator should work for scheduled
> > periodic cleanup tasks though. We don't support manual triggering for
> > them. Wonder if I should change this to trigger it always just on
> > coordinator.
> >
> > Btv. I am not using any real long-live lock, just the kind of
> > "pseudo-lock" (based on the presence of some particular item in the
> > cache, which is removed once the task is finished).
> >
> >
> > Marek
> >
> >
> > On 17/02/16 14:14, Pedro Igor Silva wrote:
> >> Instead of locking could you identify the coordinator and only sync from
> >> federation from the corresponding node ?
> >>
> >> Regards.
> >> Pedro Igor
> >>
> >> ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, February 17, 2016 10:50:08 AM
> >> Subject: [keycloak-dev] Concurrent sync in cluster
> >>
> >> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
> >> are errors when sync of users from federationProvider is triggered
> >> concurrently in more cluster nodes. This affects periodic sync as well.
> >>
> >> To avoid concurrent executions of same task, I've added ClusterProvider.
> >> This is based on infinispan and it provides some locking functionality
> >> to ensures that sync from federation can be executed just by one cluster
> >> node at a time. Even on single node (non-cluster setup), now you can't
> >> trigger sync multiple times concurrently. So for example if there is
> >> periodic sync in progress and you click in admin console on "Sync
> >> users", the sync won't happen.
> >>
> >> The same mechanism is now also used for scheduled tasks (Removing
> >> expired user sessions and expired events). Nobody reported any bug yet,
> >> however when removing of expired events/sessions is triggered
> >> concurrently by more cluster nodes, it can be issue too. So this is now
> >> avoided. Maybe we can improve even more and ensure that just cluster
> >> coordinator will run scheduled tasks and other nodes will just ignore
> >> them?
> >>
> >> ClusterProvider also adds possibility to register ClusterListener with
> >> any task, that should be executed once notification from any cluster
> >> node comes. This allows that when some federation provider is
> >> created/updated/removed, then all nodes are aware of the change and will
> >> immediately change (or remove) scheduled timer.
> >>
> >> PR is here https://github.com/keycloak/keycloak/pull/2234
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From psilva at redhat.com  Wed Feb 17 10:24:40 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 10:24:40 -0500 (EST)
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <1239786216.24356666.1455721994900.JavaMail.zimbra@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
	<56C47A3B.10706@redhat.com>
	<1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>
	<56C488C2.3060102@redhat.com>
	<1239786216.24356666.1455721994900.JavaMail.zimbra@redhat.com>
Message-ID: <1525295826.24363224.1455722680747.JavaMail.zimbra@redhat.com>

Btw, I don't know sync works in details, but I assume that you also need to load data from the source repo on each node. Or just send a page to each node from the coordinator.

If you load data from source repo on each node, you have also to consider how much concurrent queries the source repo can handle. If you send a page to each node, the coordinator will spend some time preparing the pages for each node until it is able to send them. Depending on how big is a LDAP server, for instance, that could take some time and you are still "overloading" the coordinator.

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Marek Posolda" <mposolda at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 17, 2016 1:13:14 PM
Subject: Re: [keycloak-dev] Concurrent sync in cluster

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 12:50:42 PM
> Subject: Re: [keycloak-dev] Concurrent sync in cluster
> 
> On 17/02/16 15:06, Pedro Igor Silva wrote:
> > I think it makes more sense to not spread administrative operations on
> > different nodes, but just on the coordinator. That would make the design
> > more predictable and make life easier when something wrong happens, given
> > that you know that only a specific node is able to perform the operation.
> >
> > Not sure how manual works, but in theory you can have a specific cache or
> > just use a known-entry to propagate coordinator related events. So when
> > you trigger a sync you don't really start the work but indicates to the
> > coordinator that a sync was triggered. You still need the lock though, but
> > that will be only a coordinator specific thing.
> Yeah, some kind of "locking" is always needed as issue can be seen even
> on single node. When the locking mechanism is cluster-aware then even
> better, regarding implementation it's not a big difference.
> 
> Regarding every background task running on coordinator, there is the
> disadvantage of this IMO, that coordinator is under bigger workload.

True, but I would avoid distribute processing as much as possible. However, I'm sure you want that to address some existing performance issues though.

> 
> For the future versions, we discussed some improvements planned like:
> - Possibility to see the progress in admin console (how many users were
> synced already, possibility to cancel task etc)
> - Possibility to run the sync in "distributable" manner. So that the
> sync can be always started on coordinator as you suggested, but
> coordinator will share the workload with other cluster nodes and
> "manage" the work (ie. node1 is supposed to do page1+page2 and node2
> page3+page4 etc). We already use something like this based on infinispan
> Distributable executor service [1], which is very cool stuff IMO. Don't
> you think this is better regarding workload (and time of the task) then
> always execute everything on coordinator?

Yeah, it is a very cool feature in ISPN, but how better is, depends. At the end you are using multiple producers (each node with their respective pages) writing to the same repository. Before answering your question, I would evaluate how much the end repository can handle concurrent transactions. Depending on how a database is configured, a single writer can perform better.

> 
> Unfortunately we are in the "bugfixing" phase and just addressing bugs,
> seems that all the other features will need to wait...
> 
> [1]
> http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#DistributedExecutor
> 
> Marek
> >
> > Regards.
> > Pedro Igor
> >
> > ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, February 17, 2016 11:48:43 AM
> > Subject: Re: [keycloak-dev] Concurrent sync in cluster
> >
> > Was thinking about it. The thing is that we support both periodic and
> > manual sync. And the manual sync can be triggered on any cluster node.
> > You can even reproduce issue in non-cluster environment with single host
> > if you trigger concurrently 2 sync at the same time (or if periodic is
> > in progress and you trigger manual etc).
> >
> > The possibility to trigger on coordinator should work for scheduled
> > periodic cleanup tasks though. We don't support manual triggering for
> > them. Wonder if I should change this to trigger it always just on
> > coordinator.
> >
> > Btv. I am not using any real long-live lock, just the kind of
> > "pseudo-lock" (based on the presence of some particular item in the
> > cache, which is removed once the task is finished).
> >
> >
> > Marek
> >
> >
> > On 17/02/16 14:14, Pedro Igor Silva wrote:
> >> Instead of locking could you identify the coordinator and only sync from
> >> federation from the corresponding node ?
> >>
> >> Regards.
> >> Pedro Igor
> >>
> >> ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, February 17, 2016 10:50:08 AM
> >> Subject: [keycloak-dev] Concurrent sync in cluster
> >>
> >> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
> >> are errors when sync of users from federationProvider is triggered
> >> concurrently in more cluster nodes. This affects periodic sync as well.
> >>
> >> To avoid concurrent executions of same task, I've added ClusterProvider.
> >> This is based on infinispan and it provides some locking functionality
> >> to ensures that sync from federation can be executed just by one cluster
> >> node at a time. Even on single node (non-cluster setup), now you can't
> >> trigger sync multiple times concurrently. So for example if there is
> >> periodic sync in progress and you click in admin console on "Sync
> >> users", the sync won't happen.
> >>
> >> The same mechanism is now also used for scheduled tasks (Removing
> >> expired user sessions and expired events). Nobody reported any bug yet,
> >> however when removing of expired events/sessions is triggered
> >> concurrently by more cluster nodes, it can be issue too. So this is now
> >> avoided. Maybe we can improve even more and ensure that just cluster
> >> coordinator will run scheduled tasks and other nodes will just ignore
> >> them?
> >>
> >> ClusterProvider also adds possibility to register ClusterListener with
> >> any task, that should be executed once notification from any cluster
> >> node comes. This allows that when some federation provider is
> >> created/updated/removed, then all nodes are aware of the change and will
> >> immediately change (or remove) scheduled timer.
> >>
> >> PR is here https://github.com/keycloak/keycloak/pull/2234
> >>
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Wed Feb 17 11:06:41 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 11:06:41 -0500
Subject: [keycloak-dev] caching changes
In-Reply-To: <56C48BB4.80608@redhat.com>
References: <56BE28B3.7070707@redhat.com> <56C47BCC.2080009@redhat.com>
	<56C48758.1050002@redhat.com> <56C48BB4.80608@redhat.com>
Message-ID: <56C49A91.2010104@redhat.com>

Hibernate/JPA supports optimistic locking with a version column.

On 2/17/2016 10:03 AM, Marek Posolda wrote:
> The thing is, when admin2 press "update realm" , the data on server 
> are already updated from admin1. So he will see the value of 
> "registrationEnabled" field is true and overrides it with his value 
> false.
>
> It seems the possibilitity to address this might be to add "version" 
> column in DB. The version is sent to UI of admin console, but it's 
> hidden. When admin2 press "update", he will send the version back and 
> he will see that version in DB is bigger than expected, so someone 
> updated realm in the meantime.
>
> But I don't know if this is really issue which needs to be solved or 
> rather corner case...
>
> Marek
>
> On 17/02/16 15:44, Bill Burke wrote:
>> Even if you have caching off this is a problem.  You have to do this:
>>
>> * In RepresentationToModel, don't call setters on properties that 
>> have equal values
>> * If its not already set, change hibernate to optimized updates, 
>> don't update fields that haven't changed
>>
>> On 2/17/2016 8:55 AM, Marek Posolda wrote:
>>> Should this be done for user's cache too? Couldn't it happen that 
>>> same user is concurrently updated by 2 threads?
>>>
>>> Also wonder about scenario like:
>>> - 2 admin users are editing realm at the same time
>>> - Admin1 enables user's registration for the realm and click "update"
>>> - Admin2 changed access token timeout and then click "update" . 
>>> AFAIK at this point, he overwrites the change by admin1 because we 
>>> send whole realm representation in the request.
>>>
>>> Do we want to address this? Or is this rather a corner case?
>>>
>>> Marek
>>>
>>>
>>> On 12/02/16 19:47, Bill Burke wrote:
>>>> I'm still working on stuff, but here is a summary of things so far:
>>>> * ConcurrenyTest is passing
>>>> * Caching implementation is now a pessimistic locking style based on
>>>> versions.  Locking never happens on reads, only writes. There are two
>>>> caches.  One cache holds the actual data, and is pretty much a vanilla
>>>> invalidation cache.  The other cache olds versioning information 
>>>> and is
>>>> a local-only cache and just is an id->version map.  Given an id, 
>>>> what is
>>>> the current version of it.  Hopefully, the implementation makes sure
>>>> that you never are able to add or obtain a stale version of an object
>>>> from the cache.  Locking happens for updates.  At the end of a
>>>> transaction, all registered invalidations are iterated on, and a 
>>>> version
>>>> cache lock on that id is obtain.  The db is updated, and after that 
>>>> the
>>>> locks are released.  A lock is also obtained whever something is added
>>>> to the cache.  Again a lock is only obtained on the version cache, so
>>>> any reads will never block.
>>>> * KeycloakTransactionManager now has an enlistPrepare method.
>>>> * There is a new RealmProvider.getClientByClientId() method. 
>>>> Clients now
>>>> have a clientId "index" in the cache.
>>>> * There is a new RealmProvider.removeClient() method.  This was needed
>>>> to support getClientByClientId()
>>>>
>>>> Some other things that were done:
>>>> * Unnecessary @JoinTables were removed for certain @OneToMany 
>>>> relationships.
>>>> * getId() will no longer cause a DB query if you are invoking on a
>>>> reference to a JPA adapter
>>>> * RealmModel.getClients() and getClientNameMap() is no longer used to
>>>> implement getClientByClientId() :)
>>>> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
>>>> transient variable.  We were actually unmarshalling from the cached 
>>>> pem
>>>> format every time these things were access, which is like few times 
>>>> per
>>>> login.
>>>>
>>>> Next steps:
>>>> * Create a client list cache for each realm.  Currently, if you
>>>> add/remove a client, this invalidates the realm cache and its doing a
>>>> big query for each client.
>>>> *  Do some profiling to see if there's other things we can do.
>>>>
>>>
>>
>

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


From bburke at redhat.com  Wed Feb 17 12:11:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 12:11:08 -0500
Subject: [keycloak-dev] client query caches getting complicated
Message-ID: <56C4A9AC.9050508@redhat.com>

Currently, adding or deleting a client, or updating a realm causes 
invalidation/eviction of the realm and all clients in that realm. To 
make matters worse, the next time the realm is accessed, it queries and 
loads each client and its relationships.  Why do we do this?  When a 
realm invalidation happens, the cache has no idea if the realm is just 
being updated or removed entirely from the DB. With a realm removal, you 
also need to evict the cache of all clients within the realm.  So, a 
cached realm MUST have a list of all clients within it.  As a result, 
the more clients that get added, keycloak gets slower and slower.  
Eventually though the cache stabilizes after inserts/update/deletes 
subside and we get back to normal performance, but you can see a nasty 
blip for a little bit.

I think i have a couple of solutions for this:

* Create a separate client cache. Client keys would be 
"{realm.id}.{client.id}".  Iterate on all client keys, and evict those 
that start with the realm id.
* Or, do a DB query for all clients of the realm.

I'm giving this until end of day to see if I can get a good solution, 
otherwise i'm aborting.

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


From psilva at redhat.com  Wed Feb 17 12:46:51 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 17 Feb 2016 12:46:51 -0500 (EST)
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C4A9AC.9050508@redhat.com>
References: <56C4A9AC.9050508@redhat.com>
Message-ID: <351787088.24425045.1455731211464.JavaMail.zimbra@redhat.com>

ISPN also provides an eviction policies to avoid undesired memory consumption. Not sure if that helps to what you said about "the more clients that get added, keycloak gets slower and slower".

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 17, 2016 3:11:08 PM
Subject: [keycloak-dev] client query caches getting complicated

Currently, adding or deleting a client, or updating a realm causes 
invalidation/eviction of the realm and all clients in that realm. To 
make matters worse, the next time the realm is accessed, it queries and 
loads each client and its relationships.  Why do we do this?  When a 
realm invalidation happens, the cache has no idea if the realm is just 
being updated or removed entirely from the DB. With a realm removal, you 
also need to evict the cache of all clients within the realm.  So, a 
cached realm MUST have a list of all clients within it.  As a result, 
the more clients that get added, keycloak gets slower and slower.  
Eventually though the cache stabilizes after inserts/update/deletes 
subside and we get back to normal performance, but you can see a nasty 
blip for a little bit.

I think i have a couple of solutions for this:

* Create a separate client cache. Client keys would be 
"{realm.id}.{client.id}".  Iterate on all client keys, and evict those 
that start with the realm id.
* Or, do a DB query for all clients of the realm.

I'm giving this until end of day to see if I can get a good solution, 
otherwise i'm aborting.

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

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

From bburke at redhat.com  Wed Feb 17 13:04:52 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 13:04:52 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <351787088.24425045.1455731211464.JavaMail.zimbra@redhat.com>
References: <56C4A9AC.9050508@redhat.com>
	<351787088.24425045.1455731211464.JavaMail.zimbra@redhat.com>
Message-ID: <56C4B644.70104@redhat.com>

Eviction policies don't solve it.  I spelled out why in the original post.

On 2/17/2016 12:46 PM, Pedro Igor Silva wrote:
> ISPN also provides an eviction policies to avoid undesired memory consumption. Not sure if that helps to what you said about "the more clients that get added, keycloak gets slower and slower".
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 3:11:08 PM
> Subject: [keycloak-dev] client query caches getting complicated
>
> Currently, adding or deleting a client, or updating a realm causes
> invalidation/eviction of the realm and all clients in that realm. To
> make matters worse, the next time the realm is accessed, it queries and
> loads each client and its relationships.  Why do we do this?  When a
> realm invalidation happens, the cache has no idea if the realm is just
> being updated or removed entirely from the DB. With a realm removal, you
> also need to evict the cache of all clients within the realm.  So, a
> cached realm MUST have a list of all clients within it.  As a result,
> the more clients that get added, keycloak gets slower and slower.
> Eventually though the cache stabilizes after inserts/update/deletes
> subside and we get back to normal performance, but you can see a nasty
> blip for a little bit.
>
> I think i have a couple of solutions for this:
>
> * Create a separate client cache. Client keys would be
> "{realm.id}.{client.id}".  Iterate on all client keys, and evict those
> that start with the realm id.
> * Or, do a DB query for all clients of the realm.
>
> I'm giving this until end of day to see if I can get a good solution,
> otherwise i'm aborting.
>

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


From mposolda at redhat.com  Wed Feb 17 15:09:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:09:07 +0100
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C4A9AC.9050508@redhat.com>
References: <56C4A9AC.9050508@redhat.com>
Message-ID: <56C4D363.6030906@redhat.com>

On 17/02/16 18:11, Bill Burke wrote:
> Currently, adding or deleting a client, or updating a realm causes
> invalidation/eviction of the realm and all clients in that realm. To
> make matters worse, the next time the realm is accessed, it queries and
> loads each client and its relationships.  Why do we do this?  When a
> realm invalidation happens, the cache has no idea if the realm is just
> being updated or removed entirely from the DB. With a realm removal, you
> also need to evict the cache of all clients within the realm.  So, a
> cached realm MUST have a list of all clients within it.  As a result,
> the more clients that get added, keycloak gets slower and slower.
> Eventually though the cache stabilizes after inserts/update/deletes
> subside and we get back to normal performance, but you can see a nasty
> blip for a little bit.
We don't need to eagerly preload all clients when realm is loaded. 
Infinispan has streaming/predicate API and we are using it in many 
places (see InfinispanUserSessionProvider and all the stuff in package 
org.keycloak.models.sessions.infinispan.stream ). So when entry is 
invalidated, we can have cacheListener, which will query infinispan to 
return all cached clients of the realm and remove them. I can see that 
we already have listener. So possibly we can just change this line to 
use predicate query: 
https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141


Other option is, that we can try to optimize eager preload and see if we 
can reduce number of SQL queries at startup. For example, it seems that 
CachedClient constructor sends SQL query to preload just realm roles. 
And then each client sends another SQL query to preload his client roles 
(method CachedClient.cacheRoles ). Couldn't we instead send one SQL 
query to load all roles of realm (both realm and client roles)? Maybe we 
can even send one big SQL query to load realm with all it's objects :-) 
Possibly some FetchType.EAGER in Hibernate entities could help here.

Marek
>
> I think i have a couple of solutions for this:
>
> * Create a separate client cache. Client keys would be
> "{realm.id}.{client.id}".  Iterate on all client keys, and evict those
> that start with the realm id.
> * Or, do a DB query for all clients of the realm.
>
> I'm giving this until end of day to see if I can get a good solution,
> otherwise i'm aborting.
>

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

From mposolda at redhat.com  Wed Feb 17 15:10:19 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:10:19 +0100
Subject: [keycloak-dev] caching changes
In-Reply-To: <56C49A91.2010104@redhat.com>
References: <56BE28B3.7070707@redhat.com> <56C47BCC.2080009@redhat.com>
	<56C48758.1050002@redhat.com> <56C48BB4.80608@redhat.com>
	<56C49A91.2010104@redhat.com>
Message-ID: <56C4D3AB.6000703@redhat.com>

Yeah, so question is if we need it? It looks to me like corner scenario 
and nobody complained so far AFAIK, so maybe not...

Marel

On 17/02/16 17:06, Bill Burke wrote:
> Hibernate/JPA supports optimistic locking with a version column.
>
> On 2/17/2016 10:03 AM, Marek Posolda wrote:
>> The thing is, when admin2 press "update realm" , the data on server 
>> are already updated from admin1. So he will see the value of 
>> "registrationEnabled" field is true and overrides it with his value 
>> false.
>>
>> It seems the possibilitity to address this might be to add "version" 
>> column in DB. The version is sent to UI of admin console, but it's 
>> hidden. When admin2 press "update", he will send the version back and 
>> he will see that version in DB is bigger than expected, so someone 
>> updated realm in the meantime.
>>
>> But I don't know if this is really issue which needs to be solved or 
>> rather corner case...
>>
>> Marek
>>
>> On 17/02/16 15:44, Bill Burke wrote:
>>> Even if you have caching off this is a problem.  You have to do this:
>>>
>>> * In RepresentationToModel, don't call setters on properties that 
>>> have equal values
>>> * If its not already set, change hibernate to optimized updates, 
>>> don't update fields that haven't changed
>>>
>>> On 2/17/2016 8:55 AM, Marek Posolda wrote:
>>>> Should this be done for user's cache too? Couldn't it happen that 
>>>> same user is concurrently updated by 2 threads?
>>>>
>>>> Also wonder about scenario like:
>>>> - 2 admin users are editing realm at the same time
>>>> - Admin1 enables user's registration for the realm and click "update"
>>>> - Admin2 changed access token timeout and then click "update" . 
>>>> AFAIK at this point, he overwrites the change by admin1 because we 
>>>> send whole realm representation in the request.
>>>>
>>>> Do we want to address this? Or is this rather a corner case?
>>>>
>>>> Marek
>>>>
>>>>
>>>> On 12/02/16 19:47, Bill Burke wrote:
>>>>> I'm still working on stuff, but here is a summary of things so far:
>>>>> * ConcurrenyTest is passing
>>>>> * Caching implementation is now a pessimistic locking style based on
>>>>> versions.  Locking never happens on reads, only writes. There are two
>>>>> caches.  One cache holds the actual data, and is pretty much a 
>>>>> vanilla
>>>>> invalidation cache.  The other cache olds versioning information 
>>>>> and is
>>>>> a local-only cache and just is an id->version map. Given an id, 
>>>>> what is
>>>>> the current version of it.  Hopefully, the implementation makes sure
>>>>> that you never are able to add or obtain a stale version of an object
>>>>> from the cache.  Locking happens for updates.  At the end of a
>>>>> transaction, all registered invalidations are iterated on, and a 
>>>>> version
>>>>> cache lock on that id is obtain.  The db is updated, and after 
>>>>> that the
>>>>> locks are released.  A lock is also obtained whever something is 
>>>>> added
>>>>> to the cache.  Again a lock is only obtained on the version cache, so
>>>>> any reads will never block.
>>>>> * KeycloakTransactionManager now has an enlistPrepare method.
>>>>> * There is a new RealmProvider.getClientByClientId() method. 
>>>>> Clients now
>>>>> have a clientId "index" in the cache.
>>>>> * There is a new RealmProvider.removeClient() method. This was needed
>>>>> to support getClientByClientId()
>>>>>
>>>>> Some other things that were done:
>>>>> * Unnecessary @JoinTables were removed for certain @OneToMany 
>>>>> relationships.
>>>>> * getId() will no longer cause a DB query if you are invoking on a
>>>>> reference to a JPA adapter
>>>>> * RealmModel.getClients() and getClientNameMap() is no longer used to
>>>>> implement getClientByClientId() :)
>>>>> * CachedRealm now stores PrivateKey, PublicKey, and Certificate in a
>>>>> transient variable.  We were actually unmarshalling from the 
>>>>> cached pem
>>>>> format every time these things were access, which is like few 
>>>>> times per
>>>>> login.
>>>>>
>>>>> Next steps:
>>>>> * Create a client list cache for each realm.  Currently, if you
>>>>> add/remove a client, this invalidates the realm cache and its doing a
>>>>> big query for each client.
>>>>> *  Do some profiling to see if there's other things we can do.
>>>>>
>>>>
>>>
>>
>


From mposolda at redhat.com  Wed Feb 17 15:26:35 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 17 Feb 2016 21:26:35 +0100
Subject: [keycloak-dev] Concurrent sync in cluster
In-Reply-To: <1525295826.24363224.1455722680747.JavaMail.zimbra@redhat.com>
References: <56C46C80.8070506@redhat.com>
	<124169875.24265215.1455714858432.JavaMail.zimbra@redhat.com>
	<56C47A3B.10706@redhat.com>
	<1244688436.24314498.1455717996302.JavaMail.zimbra@redhat.com>
	<56C488C2.3060102@redhat.com>
	<1239786216.24356666.1455721994900.JavaMail.zimbra@redhat.com>
	<1525295826.24363224.1455722680747.JavaMail.zimbra@redhat.com>
Message-ID: <56C4D77B.10904@redhat.com>

IMO load data from the source repo on each node is better option. That's 
what we are already using on one place (preloading offline userSessions 
from DB to infinispan cache at server startup). And I can see that 
distributed cache helps with startup when 2 nodes are started 
concurrently (startup time is not 2 times better, but it's better then 
single node startup). I tried with MySQL and Mongo and some improvement 
for concurrent startup can be seen for both.

As you mentioned, sending page from coordinator would mean big overhead 
on coordinator and big messages send over the cluster, so even network 
overhead. Doesn't seem to me like very good option, but maybe I am wrong...

One bad thing is, that some federation storages may not support classic 
pagination, which allows easy divide work into pages and share the work 
(ie. page3 starts from offset 100 to offset 150). For example LDAP 
doesn't have classic pagination, but each page return "cookie", which 
you need to use for query next page. This could make it harder to 
properly share the work. But hopefully this is solvable somehow...

Marek

On 17/02/16 16:24, Pedro Igor Silva wrote:
> Btw, I don't know sync works in details, but I assume that you also need to load data from the source repo on each node. Or just send a page to each node from the coordinator.
>
> If you load data from source repo on each node, you have also to consider how much concurrent queries the source repo can handle. If you send a page to each node, the coordinator will spend some time preparing the pages for each node until it is able to send them. Depending on how big is a LDAP server, for instance, that could take some time and you are still "overloading" the coordinator.
>
> ----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 17, 2016 1:13:14 PM
> Subject: Re: [keycloak-dev] Concurrent sync in cluster
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 17, 2016 12:50:42 PM
>> Subject: Re: [keycloak-dev] Concurrent sync in cluster
>>
>> On 17/02/16 15:06, Pedro Igor Silva wrote:
>>> I think it makes more sense to not spread administrative operations on
>>> different nodes, but just on the coordinator. That would make the design
>>> more predictable and make life easier when something wrong happens, given
>>> that you know that only a specific node is able to perform the operation.
>>>
>>> Not sure how manual works, but in theory you can have a specific cache or
>>> just use a known-entry to propagate coordinator related events. So when
>>> you trigger a sync you don't really start the work but indicates to the
>>> coordinator that a sync was triggered. You still need the lock though, but
>>> that will be only a coordinator specific thing.
>> Yeah, some kind of "locking" is always needed as issue can be seen even
>> on single node. When the locking mechanism is cluster-aware then even
>> better, regarding implementation it's not a big difference.
>>
>> Regarding every background task running on coordinator, there is the
>> disadvantage of this IMO, that coordinator is under bigger workload.
> True, but I would avoid distribute processing as much as possible. However, I'm sure you want that to address some existing performance issues though.
>
>> For the future versions, we discussed some improvements planned like:
>> - Possibility to see the progress in admin console (how many users were
>> synced already, possibility to cancel task etc)
>> - Possibility to run the sync in "distributable" manner. So that the
>> sync can be always started on coordinator as you suggested, but
>> coordinator will share the workload with other cluster nodes and
>> "manage" the work (ie. node1 is supposed to do page1+page2 and node2
>> page3+page4 etc). We already use something like this based on infinispan
>> Distributable executor service [1], which is very cool stuff IMO. Don't
>> you think this is better regarding workload (and time of the task) then
>> always execute everything on coordinator?
> Yeah, it is a very cool feature in ISPN, but how better is, depends. At the end you are using multiple producers (each node with their respective pages) writing to the same repository. Before answering your question, I would evaluate how much the end repository can handle concurrent transactions. Depending on how a database is configured, a single writer can perform better.
>
>> Unfortunately we are in the "bugfixing" phase and just addressing bugs,
>> seems that all the other features will need to wait...
>>
>> [1]
>> http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#DistributedExecutor
>>
>> Marek
>>> Regards.
>>> Pedro Igor
>>>
>>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, February 17, 2016 11:48:43 AM
>>> Subject: Re: [keycloak-dev] Concurrent sync in cluster
>>>
>>> Was thinking about it. The thing is that we support both periodic and
>>> manual sync. And the manual sync can be triggered on any cluster node.
>>> You can even reproduce issue in non-cluster environment with single host
>>> if you trigger concurrently 2 sync at the same time (or if periodic is
>>> in progress and you trigger manual etc).
>>>
>>> The possibility to trigger on coordinator should work for scheduled
>>> periodic cleanup tasks though. We don't support manual triggering for
>>> them. Wonder if I should change this to trigger it always just on
>>> coordinator.
>>>
>>> Btv. I am not using any real long-live lock, just the kind of
>>> "pseudo-lock" (based on the presence of some particular item in the
>>> cache, which is removed once the task is finished).
>>>
>>>
>>> Marek
>>>
>>>
>>> On 17/02/16 14:14, Pedro Igor Silva wrote:
>>>> Instead of locking could you identify the coordinator and only sync from
>>>> federation from the corresponding node ?
>>>>
>>>> Regards.
>>>> Pedro Igor
>>>>
>>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, February 17, 2016 10:50:08 AM
>>>> Subject: [keycloak-dev] Concurrent sync in cluster
>>>>
>>>> We had a bug https://issues.jboss.org/browse/KEYCLOAK-2412 that there
>>>> are errors when sync of users from federationProvider is triggered
>>>> concurrently in more cluster nodes. This affects periodic sync as well.
>>>>
>>>> To avoid concurrent executions of same task, I've added ClusterProvider.
>>>> This is based on infinispan and it provides some locking functionality
>>>> to ensures that sync from federation can be executed just by one cluster
>>>> node at a time. Even on single node (non-cluster setup), now you can't
>>>> trigger sync multiple times concurrently. So for example if there is
>>>> periodic sync in progress and you click in admin console on "Sync
>>>> users", the sync won't happen.
>>>>
>>>> The same mechanism is now also used for scheduled tasks (Removing
>>>> expired user sessions and expired events). Nobody reported any bug yet,
>>>> however when removing of expired events/sessions is triggered
>>>> concurrently by more cluster nodes, it can be issue too. So this is now
>>>> avoided. Maybe we can improve even more and ensure that just cluster
>>>> coordinator will run scheduled tasks and other nodes will just ignore
>>>> them?
>>>>
>>>> ClusterProvider also adds possibility to register ClusterListener with
>>>> any task, that should be executed once notification from any cluster
>>>> node comes. This allows that when some federation provider is
>>>> created/updated/removed, then all nodes are aware of the change and will
>>>> immediately change (or remove) scheduled timer.
>>>>
>>>> PR is here https://github.com/keycloak/keycloak/pull/2234
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Feb 17 15:56:04 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Feb 2016 15:56:04 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C4D363.6030906@redhat.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
Message-ID: <56C4DE64.3060006@redhat.com>



On 2/17/2016 3:09 PM, Marek Posolda wrote:
> On 17/02/16 18:11, Bill Burke wrote:
>> Currently, adding or deleting a client, or updating a realm causes
>> invalidation/eviction of the realm and all clients in that realm. To
>> make matters worse, the next time the realm is accessed, it queries and
>> loads each client and its relationships.  Why do we do this?  When a
>> realm invalidation happens, the cache has no idea if the realm is just
>> being updated or removed entirely from the DB. With a realm removal, you
>> also need to evict the cache of all clients within the realm.  So, a
>> cached realm MUST have a list of all clients within it.  As a result,
>> the more clients that get added, keycloak gets slower and slower.
>> Eventually though the cache stabilizes after inserts/update/deletes
>> subside and we get back to normal performance, but you can see a nasty
>> blip for a little bit.
> We don't need to eagerly preload all clients when realm is loaded. 
> Infinispan has streaming/predicate API and we are using it in many 
> places (see InfinispanUserSessionProvider and all the stuff in package 
> org.keycloak.models.sessions.infinispan.stream ). So when entry is 
> invalidated, we can have cacheListener, which will query infinispan to 
> return all cached clients of the realm and remove them. I can see that 
> we already have listener. So possibly we can just change this line to 
> use predicate query: 
> https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141
>
>

Lol, i was sort of kind of doing that doing cache.values().  This makes 
it much easier with much less refactoring.

> Other option is, that we can try to optimize eager preload and see if 
> we can reduce number of SQL queries at startup. For example, it seems 
> that CachedClient constructor sends SQL query to preload just realm 
> roles. And then each client sends another SQL query to preload his 
> client roles (method CachedClient.cacheRoles ). Couldn't we instead 
> send one SQL query to load all roles of realm (both realm and client 
> roles)? Maybe we can even send one big SQL query to load realm with 
> all it's objects :-) Possibly some FetchType.EAGER in Hibernate 
> entities could help here.
>

yeah, we should start looking into stuff like this.    We can at least 
reduce the number of sql calls for caching a client or realm 
individually.  I'm not sure how feasible it is though or how much better 
it is.  Realms and clients contain more than a few one to many 
relationships which would make the query result HUGE if I remember how 
joins work.

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

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

From sthorger at redhat.com  Thu Feb 18 02:07:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 08:07:10 +0100
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C4DE64.3060006@redhat.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
Message-ID: <CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>

Having two many joins (fetching everything about a realm in one query) is
probably going to be bad for performance, especially if there are loads of
clients and roles. There can also be large difference between different
vendors.

Another thing in the future we should separate clients out into a separate
store. There could be thousands of clients or even more. So they should be
treated in a similar fashion to users. Does that have impact on how we
improve/refactor/fix caching now?

On 17 February 2016 at 21:56, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 2/17/2016 3:09 PM, Marek Posolda wrote:
>
> On 17/02/16 18:11, Bill Burke wrote:
>
> Currently, adding or deleting a client, or updating a realm causes
> invalidation/eviction of the realm and all clients in that realm. To
> make matters worse, the next time the realm is accessed, it queries and
> loads each client and its relationships.  Why do we do this?  When a
> realm invalidation happens, the cache has no idea if the realm is just
> being updated or removed entirely from the DB. With a realm removal, you
> also need to evict the cache of all clients within the realm.  So, a
> cached realm MUST have a list of all clients within it.  As a result,
> the more clients that get added, keycloak gets slower and slower.
> Eventually though the cache stabilizes after inserts/update/deletes
> subside and we get back to normal performance, but you can see a nasty
> blip for a little bit.
>
> We don't need to eagerly preload all clients when realm is loaded.
> Infinispan has streaming/predicate API and we are using it in many places
> (see InfinispanUserSessionProvider and all the stuff in package
> org.keycloak.models.sessions.infinispan.stream ). So when entry is
> invalidated, we can have cacheListener, which will query infinispan to
> return all cached clients of the realm and remove them. I can see that we
> already have listener. So possibly we can just change this line to use
> predicate query:
> https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141
>
>
>
> Lol, i was sort of kind of doing that doing cache.values().  This makes it
> much easier with much less refactoring.
>
> Other option is, that we can try to optimize eager preload and see if we
> can reduce number of SQL queries at startup. For example, it seems that
> CachedClient constructor sends SQL query to preload just realm roles. And
> then each client sends another SQL query to preload his client roles
> (method CachedClient.cacheRoles ). Couldn't we instead send one SQL query
> to load all roles of realm (both realm and client roles)? Maybe we can even
> send one big SQL query to load realm with all it's objects :-)  Possibly
> some FetchType.EAGER in Hibernate entities could help here.
>
>
> yeah, we should start looking into stuff like this.    We can at least
> reduce the number of sql calls for caching a client or realm individually.
> I'm not sure how feasible it is though or how much better it is.  Realms
> and clients contain more than a few one to many relationships which would
> make the query result HUGE if I remember how joins work.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160218/6d093bd7/attachment.html 

From mposolda at redhat.com  Thu Feb 18 02:43:44 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 18 Feb 2016 08:43:44 +0100
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
Message-ID: <56C57630.40201@redhat.com>

On 18/02/16 08:07, Stian Thorgersen wrote:
> Having two many joins (fetching everything about a realm in one query) 
> is probably going to be bad for performance, especially if there are 
> loads of clients and roles. There can also be large difference between 
> different vendors.
Maybe clients and roles (and groups?) shouldn't be loaded eagerly with 
realm, but I guess most of the other stuff can be (ie. federation 
providers, identity providers, SMTP configurations etc). Also for 
clients we can eagerly load most of the stuff (ie. redirectUris, scopes 
). ATM we eagerly preload whole realm in CachedRealm constructor, but we 
have fetchType.LAZY everywhere. IMO this is not optimal and would mean 
lot of SQL at startup during realm preload (I did not doublecheck myself).

Marek

>
> Another thing in the future we should separate clients out into a 
> separate store. There could be thousands of clients or even more. So 
> they should be treated in a similar fashion to users. Does that have 
> impact on how we improve/refactor/fix caching now?
>
> On 17 February 2016 at 21:56, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 2/17/2016 3:09 PM, Marek Posolda wrote:
>>     On 17/02/16 18:11, Bill Burke wrote:
>>>     Currently, adding or deleting a client, or updating a realm causes
>>>     invalidation/eviction of the realm and all clients in that realm. To
>>>     make matters worse, the next time the realm is accessed, it queries and
>>>     loads each client and its relationships.  Why do we do this?  When a
>>>     realm invalidation happens, the cache has no idea if the realm is just
>>>     being updated or removed entirely from the DB. With a realm removal, you
>>>     also need to evict the cache of all clients within the realm.  So, a
>>>     cached realm MUST have a list of all clients within it.  As a result,
>>>     the more clients that get added, keycloak gets slower and slower.
>>>     Eventually though the cache stabilizes after inserts/update/deletes
>>>     subside and we get back to normal performance, but you can see a nasty
>>>     blip for a little bit.
>>     We don't need to eagerly preload all clients when realm is
>>     loaded. Infinispan has streaming/predicate API and we are using
>>     it in many places (see InfinispanUserSessionProvider and all the
>>     stuff in package org.keycloak.models.sessions.infinispan.stream
>>     ). So when entry is invalidated, we can have cacheListener, which
>>     will query infinispan to return all cached clients of the realm
>>     and remove them. I can see that we already have listener. So
>>     possibly we can just change this line to use predicate query:
>>     https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141
>>
>>
>
>     Lol, i was sort of kind of doing that doing cache.values().  This
>     makes it much easier with much less refactoring.
>
>>     Other option is, that we can try to optimize eager preload and
>>     see if we can reduce number of SQL queries at startup. For
>>     example, it seems that CachedClient constructor sends SQL query
>>     to preload just realm roles. And then each client sends another
>>     SQL query to preload his client roles (method
>>     CachedClient.cacheRoles ). Couldn't we instead send one SQL query
>>     to load all roles of realm (both realm and client roles)? Maybe
>>     we can even send one big SQL query to load realm with all it's
>>     objects :-) Possibly some FetchType.EAGER in Hibernate entities
>>     could help here.
>>
>
>     yeah, we should start looking into stuff like this.    We can at
>     least reduce the number of sql calls for caching a client or realm
>     individually.  I'm not sure how feasible it is though or how much
>     better it is. Realms and clients contain more than a few one to
>     many relationships which would make the query result HUGE if I
>     remember how joins work.
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Thu Feb 18 05:05:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 11:05:23 +0100
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C57630.40201@redhat.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
	<56C57630.40201@redhat.com>
Message-ID: <CAJgngAfGZx=C=g32gqYofJmzkhKvzEMXXodv4X-yq9vyoeWdEg@mail.gmail.com>

On 18 February 2016 at 08:43, Marek Posolda <mposolda at redhat.com> wrote:

> On 18/02/16 08:07, Stian Thorgersen wrote:
>
> Having two many joins (fetching everything about a realm in one query) is
> probably going to be bad for performance, especially if there are loads of
> clients and roles. There can also be large difference between different
> vendors.
>
> Maybe clients and roles (and groups?) shouldn't be loaded eagerly with
> realm, but I guess most of the other stuff can be (ie. federation
> providers, identity providers, SMTP configurations etc). Also for clients
> we can eagerly load most of the stuff (ie. redirectUris, scopes ). ATM we
> eagerly preload whole realm in CachedRealm constructor, but we have
> fetchType.LAZY everywhere. IMO this is not optimal and would mean lot of
> SQL at startup during realm preload (I did not doublecheck myself).
>

I don't really think it's a priority and I suspect performance might
actually be worse if we do a lot of eager loading than lazy loading.
Depends on how Hibernate loads it of course, but if it does it through a
crazy join then performance will suffer.


>
>
> Marek
>
>
>
> Another thing in the future we should separate clients out into a separate
> store. There could be thousands of clients or even more. So they should be
> treated in a similar fashion to users. Does that have impact on how we
> improve/refactor/fix caching now?
>
> On 17 February 2016 at 21:56, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 2/17/2016 3:09 PM, Marek Posolda wrote:
>>
>> On 17/02/16 18:11, Bill Burke wrote:
>>
>> Currently, adding or deleting a client, or updating a realm causes
>> invalidation/eviction of the realm and all clients in that realm. To
>> make matters worse, the next time the realm is accessed, it queries and
>> loads each client and its relationships.  Why do we do this?  When a
>> realm invalidation happens, the cache has no idea if the realm is just
>> being updated or removed entirely from the DB. With a realm removal, you
>> also need to evict the cache of all clients within the realm.  So, a
>> cached realm MUST have a list of all clients within it.  As a result,
>> the more clients that get added, keycloak gets slower and slower.
>> Eventually though the cache stabilizes after inserts/update/deletes
>> subside and we get back to normal performance, but you can see a nasty
>> blip for a little bit.
>>
>> We don't need to eagerly preload all clients when realm is loaded.
>> Infinispan has streaming/predicate API and we are using it in many places
>> (see InfinispanUserSessionProvider and all the stuff in package
>> org.keycloak.models.sessions.infinispan.stream ). So when entry is
>> invalidated, we can have cacheListener, which will query infinispan to
>> return all cached clients of the realm and remove them. I can see that we
>> already have listener. So possibly we can just change this line to use
>> predicate query:
>> <https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141>
>> https://github.com/keycloak/keycloak/blob/master/model/infinispan/src/main/java/org/keycloak/models/cache/infinispan/locking/LockingCacheRealmProviderFactory.java#L141
>>
>>
>>
>> Lol, i was sort of kind of doing that doing cache.values().  This makes
>> it much easier with much less refactoring.
>>
>> Other option is, that we can try to optimize eager preload and see if we
>> can reduce number of SQL queries at startup. For example, it seems that
>> CachedClient constructor sends SQL query to preload just realm roles. And
>> then each client sends another SQL query to preload his client roles
>> (method CachedClient.cacheRoles ). Couldn't we instead send one SQL query
>> to load all roles of realm (both realm and client roles)? Maybe we can even
>> send one big SQL query to load realm with all it's objects :-)  Possibly
>> some FetchType.EAGER in Hibernate entities could help here.
>>
>>
>> yeah, we should start looking into stuff like this.    We can at least
>> reduce the number of sql calls for caching a client or realm individually.
>> I'm not sure how feasible it is though or how much better it is.  Realms
>> and clients contain more than a few one to many relationships which would
>> make the query result HUGE if I remember how joins work.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160218/c44f6116/attachment.html 

From bburke at redhat.com  Thu Feb 18 08:53:34 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Feb 2016 08:53:34 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
Message-ID: <56C5CCDE.3090409@redhat.com>



On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
> Having two many joins (fetching everything about a realm in one query) 
> is probably going to be bad for performance, especially if there are 
> loads of clients and roles. There can also be large difference between 
> different vendors.
>
> Another thing in the future we should separate clients out into a 
> separate store. There could be thousands of clients or even more. So 
> they should be treated in a similar fashion to users. Does that have 
> impact on how we improve/refactor/fix caching now?
>

As I said before, OIDC logout queries *ALL* clients to obtain a list of 
valid redirects to compare against the redirect-uri passed to the logout 
endpoint.  That's about the only very frequent, non-adminstrative 
function that requires obtaining a list of all clients.  We also really 
need a way to figure out of a realm invalidation is the result of the 
realm being removed or just updated.  Otherwise, you'll be evicting 
thousands of clients and other realm related items every time a realm is 
updated.  Actually, maybe we're better off not evicting clients on a 
realm removal, and just registering invalidations for every client in 
the realm instead.

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


From bburke at redhat.com  Thu Feb 18 08:54:55 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Feb 2016 08:54:55 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <CAJgngAfGZx=C=g32gqYofJmzkhKvzEMXXodv4X-yq9vyoeWdEg@mail.gmail.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
	<56C57630.40201@redhat.com>
	<CAJgngAfGZx=C=g32gqYofJmzkhKvzEMXXodv4X-yq9vyoeWdEg@mail.gmail.com>
Message-ID: <56C5CD2F.1020000@redhat.com>



On 2/18/2016 5:05 AM, Stian Thorgersen wrote:
>
>
> On 18 February 2016 at 08:43, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 18/02/16 08:07, Stian Thorgersen wrote:
>>     Having two many joins (fetching everything about a realm in one
>>     query) is probably going to be bad for performance, especially if
>>     there are loads of clients and roles. There can also be large
>>     difference between different vendors.
>     Maybe clients and roles (and groups?) shouldn't be loaded eagerly
>     with realm, but I guess most of the other stuff can be (ie.
>     federation providers, identity providers, SMTP configurations
>     etc). Also for clients we can eagerly load most of the stuff (ie.
>     redirectUris, scopes ). ATM we eagerly preload whole realm in
>     CachedRealm constructor, but we have fetchType.LAZY everywhere.
>     IMO this is not optimal and would mean lot of SQL at startup
>     during realm preload (I did not doublecheck myself).
>
>
> I don't really think it's a priority and I suspect performance might 
> actually be worse if we do a lot of eager loading than lazy loading. 
> Depends on how Hibernate loads it of course, but if it does it through 
> a crazy join then performance will suffer.

We don't do EAGER SQL loading of clients.  We just load every 
client/role when a realm is loaded.

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

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

From sthorger at redhat.com  Thu Feb 18 08:56:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 18 Feb 2016 14:56:25 +0100
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C5CCDE.3090409@redhat.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
	<56C5CCDE.3090409@redhat.com>
Message-ID: <CAJgngAezWgNJtE9FA4RY2yr1D-CrcrO3r06HvF20JhRVLy_a5w@mail.gmail.com>

On 18 Feb 2016 13:53, "Bill Burke" <bburke at redhat.com> wrote:
>
>
>
> On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
>>
>> Having two many joins (fetching everything about a realm in one query)
is probably going to be bad for performance, especially if there are loads
of clients and roles. There can also be large difference between different
vendors.
>>
>> Another thing in the future we should separate clients out into a
separate store. There could be thousands of clients or even more. So they
should be treated in a similar fashion to users. Does that have impact on
how we improve/refactor/fix caching now?
>>
>
> As I said before, OIDC logout queries *ALL* clients to obtain a list of
valid redirects to compare against the redirect-uri passed to the logout
endpoint.  That's about the only very frequent, non-adminstrative function
that requires obtaining a list of all clients.  We also really need a way
to figure out of a realm invalidation is the result of the realm being
removed or just updated.  Otherwise, you'll be evicting thousands of
clients and other realm related items every time a realm is updated.
Actually, maybe we're better off not evicting clients on a realm removal,
and just registering invalidations for every client in the realm instead.

Why does OIDC logout need to list all clients? It used to just get the
clients that had client sessions for the specific user session.

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

From bburke at redhat.com  Thu Feb 18 09:03:36 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Feb 2016 09:03:36 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <CAJgngAezWgNJtE9FA4RY2yr1D-CrcrO3r06HvF20JhRVLy_a5w@mail.gmail.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
	<56C5CCDE.3090409@redhat.com>
	<CAJgngAezWgNJtE9FA4RY2yr1D-CrcrO3r06HvF20JhRVLy_a5w@mail.gmail.com>
Message-ID: <56C5CF38.7040900@redhat.com>



On 2/18/2016 8:56 AM, Stian Thorgersen wrote:
>
>
> On 18 Feb 2016 13:53, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
> >
> >
> >
> > On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
> >>
> >> Having two many joins (fetching everything about a realm in one 
> query) is probably going to be bad for performance, especially if 
> there are loads of clients and roles. There can also be large 
> difference between different vendors.
> >>
> >> Another thing in the future we should separate clients out into a 
> separate store. There could be thousands of clients or even more. So 
> they should be treated in a similar fashion to users. Does that have 
> impact on how we improve/refactor/fix caching now?
> >>
> >
> > As I said before, OIDC logout queries *ALL* clients to obtain a list 
> of valid redirects to compare against the redirect-uri passed to the 
> logout endpoint.  That's about the only very frequent, 
> non-adminstrative function that requires obtaining a list of all 
> clients.  We also really need a way to figure out of a realm 
> invalidation is the result of the realm being removed or just 
> updated.  Otherwise, you'll be evicting thousands of clients and other 
> realm related items every time a realm is updated.  Actually, maybe 
> we're better off not evicting clients on a realm removal, and just 
> registering invalidations for every client in the realm instead.
>
> Why does OIDC logout need to list all clients? It used to just get the 
> clients that had client sessions for the specific user session.
>
> >
>
OIDC logout endpoint has a redirect_uri parameter which tells keycloak 
where to redirect *after* logout happens.  This redirect_uri needs to be 
checked.   we may or may not know who initiated the logout request based 
on the "id_token_hint" parameter, nor is it guaranteed that the 
redirect-uri is in the list of clients that are part of the session.

This is one of the reasons why I wanted to create a generic query 
cache.  I could cache this list of redirect uri patterns and not load 
every client.

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

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

From bburke at redhat.com  Thu Feb 18 14:44:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Feb 2016 14:44:07 -0500
Subject: [keycloak-dev] client query caches getting complicated
In-Reply-To: <56C5CF38.7040900@redhat.com>
References: <56C4A9AC.9050508@redhat.com> <56C4D363.6030906@redhat.com>
	<56C4DE64.3060006@redhat.com>
	<CAJgngAeTE3LV2jibPxfF1x3XKO3iGviCGsAU-QBqEUuHd6mxfw@mail.gmail.com>
	<56C5CCDE.3090409@redhat.com>
	<CAJgngAezWgNJtE9FA4RY2yr1D-CrcrO3r06HvF20JhRVLy_a5w@mail.gmail.com>
	<56C5CF38.7040900@redhat.com>
Message-ID: <56C61F07.6010104@redhat.com>

I was thinking about this a bit more.  On a DB removal, you actually 
don't care if "child" elements don't get evicted from the cache. For 
example, if a realm gets removed, you don't care if clients get removed 
from cache or not because they will never be looked up again.  
Eventually eviction policies will trigger and the old irrelevant cache 
items will be gone.

On 2/18/2016 9:03 AM, Bill Burke wrote:
>
>
> On 2/18/2016 8:56 AM, Stian Thorgersen wrote:
>>
>>
>> On 18 Feb 2016 13:53, "Bill Burke" <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>> >
>> >
>> >
>> > On 2/18/2016 2:07 AM, Stian Thorgersen wrote:
>> >>
>> >> Having two many joins (fetching everything about a realm in one 
>> query) is probably going to be bad for performance, especially if 
>> there are loads of clients and roles. There can also be large 
>> difference between different vendors.
>> >>
>> >> Another thing in the future we should separate clients out into a 
>> separate store. There could be thousands of clients or even more. So 
>> they should be treated in a similar fashion to users. Does that have 
>> impact on how we improve/refactor/fix caching now?
>> >>
>> >
>> > As I said before, OIDC logout queries *ALL* clients to obtain a 
>> list of valid redirects to compare against the redirect-uri passed to 
>> the logout endpoint.  That's about the only very frequent, 
>> non-adminstrative function that requires obtaining a list of all 
>> clients.  We also really need a way to figure out of a realm 
>> invalidation is the result of the realm being removed or just 
>> updated.  Otherwise, you'll be evicting thousands of clients and 
>> other realm related items every time a realm is updated.  Actually, 
>> maybe we're better off not evicting clients on a realm removal, and 
>> just registering invalidations for every client in the realm instead.
>>
>> Why does OIDC logout need to list all clients? It used to just get 
>> the clients that had client sessions for the specific user session.
>>
>> >
>>
> OIDC logout endpoint has a redirect_uri parameter which tells keycloak 
> where to redirect *after* logout happens.  This redirect_uri needs to 
> be checked.   we may or may not know who initiated the logout request 
> based on the "id_token_hint" parameter, nor is it guaranteed that the 
> redirect-uri is in the list of clients that are part of the session.
>
> This is one of the reasons why I wanted to create a generic query 
> cache.  I could cache this list of redirect uri patterns and not load 
> every client.
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Fri Feb 19 05:52:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 11:52:00 +0100
Subject: [keycloak-dev] Keycloak 1.9.0.Final release status
Message-ID: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>

I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday
morning. That means all changes should be in by end of today.

With that regards there's a few outstanding items:

* Bill - is the cache stable for release? We can do improvements for next
release if required.
* Marek - what's status on performance degredation? You also have a few
other issues assigned, will these be ready?
* Bruno - will you fix KEYCLOAK-2501 in time?

Is there anything else that's not in JIRA that needs doing?

I'd appreciate as many people as possible help out with testing the
release. I'll send out details once we're ready to start.

Thanks,
Stian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160219/6e34bb13/attachment.html 

From mposolda at redhat.com  Fri Feb 19 06:55:13 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 Feb 2016 12:55:13 +0100
Subject: [keycloak-dev] Keycloak 1.9.0.Final release status
In-Reply-To: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
References: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
Message-ID: <56C702A1.10309@redhat.com>

On 19/02/16 11:52, Stian Thorgersen wrote:
> I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday 
> morning. That means all changes should be in by end of today.
>
> With that regards there's a few outstanding items:
>
> * Bill - is the cache stable for release? We can do improvements for 
> next release if required.
> * Marek - what's status on performance degredation? You also have a 
> few other issues assigned, will these be ready?
Performance degradation is (hopefully) not an issue anymore. I've tried 
long soak test in my environment, but didn't simulate any issue. Pavel 
also didn't simulate anymore in his environment . However he saw some 
NPE during test this night. I've send another PR for that ( 
https://issues.jboss.org/browse/KEYCLOAK-2508 ). ZIPException is also 
resolved. So hopefully Pavel will be able to try soak test again in his 
environment this afternoon/night. I am talking with him. I hope there 
won't be any performance degradation and any exceptions in the log in 
both server and adapter.

Other JIRAs are 2 LDAP related things, which should be easy to fix. 
Going to look at it in the afternoon. Then possibly do a bit more 
profiling during remaining time this afternoon.

Marek

> * Bruno - will you fix KEYCLOAK-2501 in time?
>
> Is there anything else that's not in JIRA that needs doing?
>
> I'd appreciate as many people as possible help out with testing the 
> release. I'll send out details once we're ready to start.
>
> Thanks,
> Stian
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bruno at abstractj.org  Fri Feb 19 07:12:06 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 19 Feb 2016 12:12:06 +0000
Subject: [keycloak-dev] Keycloak 1.9.0.Final release status
In-Reply-To: <56C702A1.10309@redhat.com>
References: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
	<56C702A1.10309@redhat.com>
Message-ID: <CAM5SUC53XKdnk_bTVo160vo2bgzjEGKPyAtfnZaJeK3Q=_ANKQ@mail.gmail.com>

The issue itself was already fixed (maybe not in the best Aesh approach).
Today I contacted St?le to see if there is the better solution. He promised
to mock up something later today and comment on that.

On Fri, Feb 19, 2016 at 9:55 AM Marek Posolda <mposolda at redhat.com> wrote:

> On 19/02/16 11:52, Stian Thorgersen wrote:
>
> I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday
> morning. That means all changes should be in by end of today.
>
> With that regards there's a few outstanding items:
>
> * Bill - is the cache stable for release? We can do improvements for next
> release if required.
> * Marek - what's status on performance degredation? You also have a few
> other issues assigned, will these be ready?
>
> Performance degradation is (hopefully) not an issue anymore. I've tried
> long soak test in my environment, but didn't simulate any issue. Pavel also
> didn't simulate anymore in his environment . However he saw some NPE during
> test this night. I've send another PR for that (
> https://issues.jboss.org/browse/KEYCLOAK-2508 ). ZIPException is also
> resolved. So hopefully Pavel will be able to try soak test again in his
> environment this afternoon/night. I am talking with him. I hope there won't
> be any performance degradation and any exceptions in the log in both server
> and adapter.
>
> Other JIRAs are 2 LDAP related things, which should be easy to fix. Going
> to look at it in the afternoon. Then possibly do a bit more profiling
> during remaining time this afternoon.
>
>
> Marek
>
>
> * Bruno - will you fix KEYCLOAK-2501 in time?
>
> Is there anything else that's not in JIRA that needs doing?
>
> I'd appreciate as many people as possible help out with testing the
> release. I'll send out details once we're ready to start.
>
> Thanks,
> Stian
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160219/d5acb20a/attachment-0001.html 

From bburke at redhat.com  Fri Feb 19 08:49:23 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Feb 2016 08:49:23 -0500
Subject: [keycloak-dev] Keycloak 1.9.0.Final release status
In-Reply-To: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
References: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
Message-ID: <56C71D63.4040108@redhat.com>



On 2/19/2016 5:52 AM, Stian Thorgersen wrote:
> I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday 
> morning. That means all changes should be in by end of today.
>
> With that regards there's a few outstanding items:
>
> * Bill - is the cache stable for release? We can do improvements for 
> next release if required.

I'm all good.  I'm working on more improvements but will hold off until 
1.9.1

> * Marek - what's status on performance degredation? You also have a 
> few other issues assigned, will these be ready?
> * Bruno - will you fix KEYCLOAK-2501 in time?
>
> Is there anything else that's not in JIRA that needs doing?
>
> I'd appreciate as many people as possible help out with testing the 
> release. I'll send out details once we're ready to start.
>
> Thanks,
> Stian
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Fri Feb 19 09:05:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 19 Feb 2016 15:05:08 +0100
Subject: [keycloak-dev] Keycloak 1.9.0.Final release status
In-Reply-To: <56C71D63.4040108@redhat.com>
References: <CAJgngAdJDgQHPhxV-je3N8aLMy5d7pFCLMdWAgKPrr9pzKV_eQ@mail.gmail.com>
	<56C71D63.4040108@redhat.com>
Message-ID: <CAJgngAduyuBq3oLvzwKJyGCwLbRsERzZXjU7ojWF-QZBqJ-7mw@mail.gmail.com>

Awesome - so looks like we're all ready for testing day on Monday. Thanks
everyone.
On 19 Feb 2016 13:49, "Bill Burke" <bburke at redhat.com> wrote:

>
>
> On 2/19/2016 5:52 AM, Stian Thorgersen wrote:
>
> I'm hoping we can start testing Keycloak 1.9.0.Final release on Monday
> morning. That means all changes should be in by end of today.
>
> With that regards there's a few outstanding items:
>
> * Bill - is the cache stable for release? We can do improvements for next
> release if required.
>
>
> I'm all good.  I'm working on more improvements but will hold off until
> 1.9.1
>
> * Marek - what's status on performance degredation? You also have a few
> other issues assigned, will these be ready?
> * Bruno - will you fix KEYCLOAK-2501 in time?
>
> Is there anything else that's not in JIRA that needs doing?
>
> I'd appreciate as many people as possible help out with testing the
> release. I'll send out details once we're ready to start.
>
> Thanks,
> Stian
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160219/28064fed/attachment.html 

From bburke at redhat.com  Fri Feb 19 10:39:12 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 19 Feb 2016 10:39:12 -0500
Subject: [keycloak-dev] table locks
Message-ID: <56C73720.1000907@redhat.com>

FYI, I don't think I can really fix, but I tried a concurrency test that 
creates, fetches, and then deletes a client in multiple concurrent 
threads.  HSQL is giving me deadlock exceptions.  Looks like it is 
trying to obtain table locks.  Sucks as I can't really unit test this 
scenario.

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


From mposolda at redhat.com  Fri Feb 19 12:10:36 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 19 Feb 2016 18:10:36 +0100
Subject: [keycloak-dev] table locks
In-Reply-To: <56C73720.1000907@redhat.com>
References: <56C73720.1000907@redhat.com>
Message-ID: <56C74C8C.40401@redhat.com>

I am often unit-testing from IDEA with MySQL or PostgreSQL. This might 
help with table locks.

You need to set system properties like (see keycloak-server.json):
-Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak 
-Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver 
-Dkeycloak.connectionsJpa.user=keycloak 
-Dkeycloak.connectionsJpa.password=keycloak

Also you need to put MySQL dependency to testsuite/integration/pom.xml :

<dependency>
     <groupId>mysql</groupId>
     <artifactId>mysql-connector-java</artifactId>
</dependency> or: <dependency>
     <groupId>org.postgresql</groupId>
     <artifactId>postgresql</artifactId>
     <version>${postgresql.version}</version>
</dependency> This is not needed if you start test from command line 
with maven, as maven will use the "mysql" or "postgresql" profile and 
will use dependency by default. Marek

On 19/02/16 16:39, Bill Burke wrote:
> FYI, I don't think I can really fix, but I tried a concurrency test that
> creates, fetches, and then deletes a client in multiple concurrent
> threads.  HSQL is giving me deadlock exceptions.  Looks like it is
> trying to obtain table locks.  Sucks as I can't really unit test this
> scenario.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160219/bd74390f/attachment.html 

From alexgv99 at gmail.com  Fri Feb 19 21:10:23 2016
From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=)
Date: Sat, 20 Feb 2016 00:10:23 -0200
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAM5SUC4y6iB=nXT9ewpmcjMFCv+xmgs1-JAO_Uk4n5gpzJY08A@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
	<CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
	<CAM5SUC4y6iB=nXT9ewpmcjMFCv+xmgs1-JAO_Uk4n5gpzJY08A@mail.gmail.com>
Message-ID: <CAGGeCYPU5UvoGhYSSjk_1KqckZw47uHVSfTundHp4OXGY3_Rgg@mail.gmail.com>

Hi Bruno, thank you for the interest in help me...
My problem is exact the same as described here:
https://issues.jboss.org/browse/KEYCLOAK-1701
Except that my keycloak version is 1.6.1, not 1.3.1 as in the issue 1701.

In the comments area, of that issue,
Stian Thorgersen
<https://issues.jboss.org/secure/ViewProfile.jspa?name=stianst> added a
comment - 27/Jul/15 3:01 AM: This is caused by in-proper configuration.
Please use user mailing list for support questions.

________________________________

So, I'm trying my luck here.


I have an app angular using keycloak.js and a java app, rest api, under
protect of the same realm/client. Everything completely straightforward.


I do have a json file, downloaded from keycloak console admin, both in the
java app (WEB-INF Folder) and angular app, for the

new Keycloak("PATH_TO_keycloak.json_FILE");

javascript snippet of code.


Is this what you mean?

Cordialmente.
Alex Gouv?a Vasconcelos
mailto:alexgv99 at gmail.com
MSN: alexgv99 at hotmail.com
http://about.me/alexgv99


2016-02-03 9:12 GMT-02:00 Bruno Oliveira <bruno at abstractj.org>:

> Do you have a JSON file configured? See:
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/keycloak.json
> ?
>
> What about your realm configuration file, looks like this
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json#L143
> ?
>
> Not sure if it helps, but at first glance it looks like some
> misconfiguration.
>
> On Thu, Jan 28, 2016 at 2:03 PM, Alex Gouv?a Vasconcelos <
> alexgv99 at gmail.com> wrote:
>
>> Sorry guys, I'm not sure weather the group receive the answer to Mr.
>> Burke question about logs or not...
>>
>>> ?
>>> Do you can an exception stacktrace on app or auth server??
>>
>> Anyway, there's no log to share, here... the server.log file (in Keycloak
>> cluster - 2 instances) doesn't emit any line in the process... and the
>> Wildfly (where the app is deployed) just say:
>>
>>> ?
>>> 16:10:23,145 WARN [org.keycloak.adapters.OAuthRequestAuthenticator]
>>> ? ?
>>> (default task-66) No state cookie?
>>
>>
>> ?So, I hope someone could help me here...
>>
>> Thanks.?
>>
>>
>> ---------- Forwarded message ----------
>> From: Alex Gouv?a Vasconcelos <alexgv99 at gmail.com>
>> Date: 2016-01-26 17:16 GMT-02:00
>> Subject: Fwd: Bad Request
>> To: keycloak-dev at lists.jboss.org
>>
>>
>> Hi guys. I'm running into some trouble here...
>>
>> I have a very simple application which should authenticate against
>> keycloak and return to the main page. This is triggered through the web.xml
>> in my application.
>>
>> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"
>> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>> http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
>> version="3.0">
>>
>> <module-name>teste</module-name>
>>
>> <filter>
>> <filter-name>CORSFilter</filter-name>
>> <filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
>> </filter>
>> <filter-mapping>
>> <filter-name>CORSFilter</filter-name>
>> <url-pattern>/rest/*</url-pattern>
>> </filter-mapping>
>>
>> <distributable />
>>
>> <security-constraint>
>> <web-resource-collection>
>> <web-resource-name>teste</web-resource-name>
>> <url-pattern>/rest/exemploService/secure/*</url-pattern>
>> </web-resource-collection>
>> <auth-constraint>
>> <role-name>*</role-name>
>> </auth-constraint>
>> <user-data-constraint>
>> <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>> </user-data-constraint>
>> </security-constraint>
>>
>> <login-config>
>> <auth-method>KEYCLOAK</auth-method>
>> <realm-name>realmtest</realm-name>
>> </login-config>
>> <security-role>
>> <role-name>user</role-name>
>> </security-role>
>> <security-role>
>> <role-name>admin</role-name>
>> </security-role>
>>
>> </web-app>
>>
>>
>> The server side has a REST API and the client side is an angular
>> application. Everything very simple to just try the development
>> environment. What happens is that, after filling the login page and return
>> to the index.html (actually it's not returning), I receive a 400 BAD
>> REQUEST for the uri:
>>
>>
>> http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1
>>
>>
>> It seems to me, that the malformed URI is because of the ?code=... If I
>> reload the page with the same URL, it just return the same 400... if I
>> remove the ? portion, it reloads the page and again redirects to and from
>> the keycloak server, and recovers the ? portion, repeating the same 400.
>>
>> I'm running everything in the same application under wildfly 10. Both the
>> server and client sides in the same deployed WAR.
>>
>> I'd appreciate any help.
>>
>> Best regards.
>>
>> Alex Gouvea Vasconcelos
>>
>>
>>
>>
>>
>>
>>
>> [image: Imagem inline 1]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> - abstractj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160220/d287b93a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak.png
Type: image/png
Size: 248184 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160220/d287b93a/attachment-0001.png 

From sthorger at redhat.com  Mon Feb 22 05:40:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 22 Feb 2016 11:40:01 +0100
Subject: [keycloak-dev] Ready to start testing for 1.9.0.Final
Message-ID: <CAJgngAfUa2EhG1f9aV22SM=iGc1StFJoPD2tqLaed_Rpqwn=pg@mail.gmail.com>

I've created 1.9.x branch and we're ready to start testing.

Same procedure as last time. Open
https://docs.google.com/spreadsheets/d/1nHHhuXMZJJpV40gXwQWKyyTnAULMv3S4a5WqljrWr7c
and add your 'Result' column in the name of the test you're going to do.
Once completed change the value to 'PASSED' or 'FAILED'. If failed create
JIRA's and link in comments section.

Remember for fixes send PR to both master and 1.9.x branch.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160222/7efa9155/attachment.html 

From gambol99 at gmail.com  Mon Feb 22 12:33:32 2016
From: gambol99 at gmail.com (gambol)
Date: Mon, 22 Feb 2016 17:33:32 +0000
Subject: [keycloak-dev] Roles Claims
Message-ID: <CA+AP+fN4_oda-umWEpdrD0+bmyhhgkzqakz=GBk0YpHbysG_Bw@mail.gmail.com>

Hiya ...

I was wondering if it's possible as of 1.9.0 to change or map the roles of
a user into new claim .. The reason I ask is
https://github.com/kubernetes/kubernetes/pull/21001/files. I know the
current implementation uses something akin to the below in the access token.

"resource_access": {
    "client_id": {
      "roles": [
        "role-a",
        "role-b",
        "role-c"
      ]
    },
    "account": {
      "roles": [
        "view-profile",
        "manage-account"
      ]
    }
  },

Any chance via a mapper we could use an string array?

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

From gambol99 at gmail.com  Mon Feb 22 12:44:23 2016
From: gambol99 at gmail.com (gambol)
Date: Mon, 22 Feb 2016 17:44:23 +0000
Subject: [keycloak-dev] Roles Claims
In-Reply-To: <CA+AP+fN4_oda-umWEpdrD0+bmyhhgkzqakz=GBk0YpHbysG_Bw@mail.gmail.com>
References: <CA+AP+fN4_oda-umWEpdrD0+bmyhhgkzqakz=GBk0YpHbysG_Bw@mail.gmail.com>
Message-ID: <CA+AP+fNdr=LQPXA6nKGtGnM9Ud1nPbyUO+xPr6jyjhqszSOT-g@mail.gmail.com>

Perhaps a little too quick to email ... I just found the "Group Membership"
option in the client mapper which would work nicely. Is there a role
version of this out of interest?

On Mon, Feb 22, 2016 at 5:33 PM, gambol <gambol99 at gmail.com> wrote:

> Hiya ...
>
> I was wondering if it's possible as of 1.9.0 to change or map the roles of
> a user into new claim .. The reason I ask is
> https://github.com/kubernetes/kubernetes/pull/21001/files. I know the
> current implementation uses something akin to the below in the access token.
>
> "resource_access": {
>     "client_id": {
>       "roles": [
>         "role-a",
>         "role-b",
>         "role-c"
>       ]
>     },
>     "account": {
>       "roles": [
>         "view-profile",
>         "manage-account"
>       ]
>     }
>   },
>
> Any chance via a mapper we could use an string array?
>
> Rohith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160222/34cacd58/attachment.html 

From bburke at redhat.com  Mon Feb 22 14:34:33 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Feb 2016 14:34:33 -0500
Subject: [keycloak-dev] Roles Claims
In-Reply-To: <CA+AP+fN4_oda-umWEpdrD0+bmyhhgkzqakz=GBk0YpHbysG_Bw@mail.gmail.com>
References: <CA+AP+fN4_oda-umWEpdrD0+bmyhhgkzqakz=GBk0YpHbysG_Bw@mail.gmail.com>
Message-ID: <56CB62C9.4070307@redhat.com>

No, not at this time.

On 2/22/2016 12:33 PM, gambol wrote:
> Hiya ...
>
> I was wondering if it's possible as of 1.9.0 to change or map the 
> roles of a user into new claim .. The reason I ask is 
> https://github.com/kubernetes/kubernetes/pull/21001/files. I know the 
> current implementation uses something akin to the below in the access 
> token.
>
> "resource_access": {
>     "client_id": {
>       "roles": [
>         "role-a",
>         "role-b",
>         "role-c"
>       ]
>     },
>     "account": {
>       "roles": [
>         "view-profile",
>         "manage-account"
>       ]
>     }
>   },
>
> Any chance via a mapper we could use an string array?
>
> Rohith
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From thomas.darimont at googlemail.com  Mon Feb 22 17:00:43 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 22 Feb 2016 23:00:43 +0100
Subject: [keycloak-dev] URL Query Parameters not propagated to
	FreeMarkerLoginFormsProvider
Message-ID: <CAK-7U1jqbsHcGWAnu=w0y8uxCMqStEaFA8rN_SNEce30Mu-03w@mail.gmail.com>

It seems that queryParams are not populated in [0]: (there is no assignment)

I think at the two places [1] [2] where the queryParameterMap is build
uriInfo.getQueryParameters() should be used.

[0]
https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L94
[1]
https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L181
[2]
https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L334

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160222/138007ce/attachment.html 

From sthorger at redhat.com  Tue Feb 23 00:58:36 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 06:58:36 +0100
Subject: [keycloak-dev] URL Query Parameters not propagated to
	FreeMarkerLoginFormsProvider
In-Reply-To: <CAK-7U1jqbsHcGWAnu=w0y8uxCMqStEaFA8rN_SNEce30Mu-03w@mail.gmail.com>
References: <CAK-7U1jqbsHcGWAnu=w0y8uxCMqStEaFA8rN_SNEce30Mu-03w@mail.gmail.com>
Message-ID: <CAJgngAccTcX9Kr8cjvYwmR=TXfxB0NXnYJ5wUb6xCx5jgGvrFA@mail.gmail.com>

What's the actual problem you're having?

On 22 February 2016 at 23:00, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> It seems that queryParams are not populated in [0]: (there is no
> assignment)
>
> I think at the two places [1] [2] where the queryParameterMap is build
> uriInfo.getQueryParameters() should be used.
>
> [0]
> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L94
> [1]
> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L181
> [2]
> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L334
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/27207446/attachment-0001.html 

From thomas.darimont at googlemail.com  Tue Feb 23 01:32:13 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 23 Feb 2016 07:32:13 +0100
Subject: [keycloak-dev] URL Query Parameters not propagated to
	FreeMarkerLoginFormsProvider
In-Reply-To: <CAJgngAccTcX9Kr8cjvYwmR=TXfxB0NXnYJ5wUb6xCx5jgGvrFA@mail.gmail.com>
References: <CAK-7U1jqbsHcGWAnu=w0y8uxCMqStEaFA8rN_SNEce30Mu-03w@mail.gmail.com>
	<CAJgngAccTcX9Kr8cjvYwmR=TXfxB0NXnYJ5wUb6xCx5jgGvrFA@mail.gmail.com>
Message-ID: <CAK-7U1j=3gdYhR94UEzVs43iDccB2rFfAg6Xsm3dtP77aveuig@mail.gmail.com>

Sorry was probably to late for me yesterday...

I was trying to add dynamic theme selection via URL parameter - and I
noticed that a "theme"
parameter passed to the login URL was not propagated
to FreeMarkerLoginFormsProvider.

I needed to be able to dynamically select a theme for the login site with a
parameter:
https://gist.github.com/thomasdarimont/c59acdd7d7d41fd5c041#file-freemarkerloginformsprovider-java-L201

Cheers,
Thomas

2016-02-23 6:58 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> What's the actual problem you're having?
>
> On 22 February 2016 at 23:00, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> It seems that queryParams are not populated in [0]: (there is no
>> assignment)
>>
>> I think at the two places [1] [2] where the queryParameterMap is build
>> uriInfo.getQueryParameters() should be used.
>>
>> [0]
>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L94
>> [1]
>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L181
>> [2]
>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L334
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/638756d2/attachment.html 

From sthorger at redhat.com  Tue Feb 23 01:42:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 07:42:03 +0100
Subject: [keycloak-dev] URL Query Parameters not propagated to
	FreeMarkerLoginFormsProvider
In-Reply-To: <CAK-7U1j=3gdYhR94UEzVs43iDccB2rFfAg6Xsm3dtP77aveuig@mail.gmail.com>
References: <CAK-7U1jqbsHcGWAnu=w0y8uxCMqStEaFA8rN_SNEce30Mu-03w@mail.gmail.com>
	<CAJgngAccTcX9Kr8cjvYwmR=TXfxB0NXnYJ5wUb6xCx5jgGvrFA@mail.gmail.com>
	<CAK-7U1j=3gdYhR94UEzVs43iDccB2rFfAg6Xsm3dtP77aveuig@mail.gmail.com>
Message-ID: <CAJgngAeLph3mq6-cXBUfp0xjZAMUg+aZ3MJz4FUq2JyzZ6x-4Q@mail.gmail.com>

It's been a while since I've touched that code, but AFAIR the queryParams
field is used to set additional query params, not to retrieve those
associated with the current request.

On 23 February 2016 at 07:32, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Sorry was probably to late for me yesterday...
>
> I was trying to add dynamic theme selection via URL parameter - and I
> noticed that a "theme"
> parameter passed to the login URL was not propagated
> to FreeMarkerLoginFormsProvider.
>
> I needed to be able to dynamically select a theme for the login site with
> a parameter:
>
> https://gist.github.com/thomasdarimont/c59acdd7d7d41fd5c041#file-freemarkerloginformsprovider-java-L201
>
> Cheers,
> Thomas
>
> 2016-02-23 6:58 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> What's the actual problem you're having?
>>
>> On 22 February 2016 at 23:00, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> It seems that queryParams are not populated in [0]: (there is no
>>> assignment)
>>>
>>> I think at the two places [1] [2] where the queryParameterMap is build
>>> uriInfo.getQueryParameters() should be used.
>>>
>>> [0]
>>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L94
>>> [1]
>>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L181
>>> [2]
>>> https://github.com/keycloak/keycloak/blob/337f39009010705346e28dab8ea326a53acdb5bf/services/src/main/java/org/keycloak/forms/login/freemarker/FreeMarkerLoginFormsProvider.java#L334
>>>
>>> Cheers,
>>> Thomas
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/f08f19f4/attachment.html 

From sthorger at redhat.com  Tue Feb 23 08:20:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 14:20:19 +0100
Subject: [keycloak-dev] We have a new logo!
Message-ID: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/3bea6f60/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/3bea6f60/attachment-0001.png 

From sblanc at redhat.com  Tue Feb 23 08:33:42 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Tue, 23 Feb 2016 14:33:42 +0100
Subject: [keycloak-dev] [keycloak-user] We have a new logo!
In-Reply-To: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
References: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
Message-ID: <CAMZCGg_ciEsddNpp_-+umaSRqJKkicic90qVMUzTVwv+rn_FoA@mail.gmail.com>

Really nice !

On Tue, Feb 23, 2016 at 2:20 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/2a357925/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/2a357925/attachment-0001.png 

From jorsol at gmail.com  Tue Feb 23 09:54:49 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Tue, 23 Feb 2016 08:54:49 -0600
Subject: [keycloak-dev] [keycloak-user] We have a new logo!
In-Reply-To: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
References: <CAJgngAeUcpiTerQ4JSt+sFW1AcjqLHeeqz3BAvLNtjfmm_+_-A@mail.gmail.com>
Message-ID: <CA+cVU8O+ey0-dY5OahpM312mEkrxmAQCTrq3Yucbxk2-=mLynA@mail.gmail.com>

Nice!, just a comment... the contrast of the letters KE and the background
is not good, try just with the same color of the last K in all letters...

cheers,


*Ing. Jorge Sol?rzano*
about.me/jorsol
<https://about.me/jorsol?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

On Tue, Feb 23, 2016 at 7:20 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/f79bf5c8/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak_google_plus_cover_1080x608.png
Type: image/png
Size: 103774 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/f79bf5c8/attachment-0001.png 

From thomas.darimont at googlemail.com  Tue Feb 23 14:13:03 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 23 Feb 2016 20:13:03 +0100
Subject: [keycloak-dev] SCIM Support
Message-ID: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>

Hello,

are there any plans to add support for SCIM (System for Cross-domain
Identity Management)?
http://www.simplecloud.info/

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/d174ac38/attachment.html 

From sthorger at redhat.com  Tue Feb 23 14:24:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 20:24:29 +0100
Subject: [keycloak-dev] SCIM Support
In-Reply-To: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>
References: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>
Message-ID: <CAJgngAdb5KM=_4O=CaXJoE1QDL570mH0mpBzbZ8jo_8EP00yCg@mail.gmail.com>

It's on the radar, but we've not had any demand for it so it's not a high
priority.

On 23 February 2016 at 20:13, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> are there any plans to add support for SCIM (System for Cross-domain
> Identity Management)?
> http://www.simplecloud.info/
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/bde09829/attachment.html 

From thomas.darimont at googlemail.com  Tue Feb 23 14:55:26 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 23 Feb 2016 20:55:26 +0100
Subject: [keycloak-dev] SCIM Support
In-Reply-To: <CAJgngAdb5KM=_4O=CaXJoE1QDL570mH0mpBzbZ8jo_8EP00yCg@mail.gmail.com>
References: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>
	<CAJgngAdb5KM=_4O=CaXJoE1QDL570mH0mpBzbZ8jo_8EP00yCg@mail.gmail.com>
Message-ID: <CAK-7U1gk=FgVA7FpYKNOqd56x6Z2R8yKoQRer3LUFFxca1vbQw@mail.gmail.com>

May I file a JIRA for this?

2016-02-23 20:24 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> It's on the radar, but we've not had any demand for it so it's not a high
> priority.
>
> On 23 February 2016 at 20:13, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello,
>>
>> are there any plans to add support for SCIM (System for Cross-domain
>> Identity Management)?
>> http://www.simplecloud.info/
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/2e1e98ab/attachment.html 

From sthorger at redhat.com  Tue Feb 23 14:57:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 20:57:11 +0100
Subject: [keycloak-dev] SCIM Support
In-Reply-To: <CAK-7U1gk=FgVA7FpYKNOqd56x6Z2R8yKoQRer3LUFFxca1vbQw@mail.gmail.com>
References: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>
	<CAJgngAdb5KM=_4O=CaXJoE1QDL570mH0mpBzbZ8jo_8EP00yCg@mail.gmail.com>
	<CAK-7U1gk=FgVA7FpYKNOqd56x6Z2R8yKoQRer3LUFFxca1vbQw@mail.gmail.com>
Message-ID: <CAJgngAcKSYdkHcxnQiU2snCKxxXLEbZtm5R+T_RXqknasFeJYg@mail.gmail.com>

Sure

On 23 February 2016 at 20:55, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> May I file a JIRA for this?
>
> 2016-02-23 20:24 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> It's on the radar, but we've not had any demand for it so it's not a high
>> priority.
>>
>> On 23 February 2016 at 20:13, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> are there any plans to add support for SCIM (System for Cross-domain
>>> Identity Management)?
>>> http://www.simplecloud.info/
>>>
>>> Cheers,
>>> Thomas
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/e8e64bd7/attachment.html 

From sthorger at redhat.com  Tue Feb 23 15:08:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 23 Feb 2016 21:08:02 +0100
Subject: [keycloak-dev] Keycloak 1.9.0.Final Released
Message-ID: <CAJgngAd6=DgZ_9sq0QGjf0yasqn093xhz5f4ZYGXupWactbPWA@mail.gmail.com>

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

From thomas.darimont at googlemail.com  Tue Feb 23 15:07:46 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 23 Feb 2016 21:07:46 +0100
Subject: [keycloak-dev] SCIM Support
In-Reply-To: <CAJgngAcKSYdkHcxnQiU2snCKxxXLEbZtm5R+T_RXqknasFeJYg@mail.gmail.com>
References: <CAK-7U1j+sD3DakQrTsYdWhm_-dDQBLec3jnR8Et2qCib+QnTGA@mail.gmail.com>
	<CAJgngAdb5KM=_4O=CaXJoE1QDL570mH0mpBzbZ8jo_8EP00yCg@mail.gmail.com>
	<CAK-7U1gk=FgVA7FpYKNOqd56x6Z2R8yKoQRer3LUFFxca1vbQw@mail.gmail.com>
	<CAJgngAcKSYdkHcxnQiU2snCKxxXLEbZtm5R+T_RXqknasFeJYg@mail.gmail.com>
Message-ID: <CAK-7U1jmuW5CnqJ65dQR2CGkRoxPR8X=BY0uX-5xSG_nvQ5Epw@mail.gmail.com>

Okay done: https://issues.jboss.org/browse/KEYCLOAK-2537

2016-02-23 20:57 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Sure
>
> On 23 February 2016 at 20:55, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> May I file a JIRA for this?
>>
>> 2016-02-23 20:24 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> It's on the radar, but we've not had any demand for it so it's not a
>>> high priority.
>>>
>>> On 23 February 2016 at 20:13, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> are there any plans to add support for SCIM (System for Cross-domain
>>>> Identity Management)?
>>>> http://www.simplecloud.info/
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160223/67979929/attachment.html 

From satyajit.das at spire2grow.com  Wed Feb 24 04:58:50 2016
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Wed, 24 Feb 2016 15:28:50 +0530
Subject: [keycloak-dev] Issue with logout.
Message-ID: <CA+oCsRo_zkZMb=A+XxDi6_g3UY-HHO_eKyYi7nwHpbocX6NynQ@mail.gmail.com>

Hi Team we are facing the below issue with logout.

i use login/logout restful service:

after login
i get tokenid say "t1" and refreshtokenid say "rt1"

1) We have registered a webservice as a keycloak client (example demo123)
with access type as bearer.
2) When I call the logout rest service:

if (isPublic()) { // if client is public access type formparams.add(new
BasicNameValuePair(OAuth2Constants.CLIENT_ID, "demo123")); }

URI logoutUri = KeycloakUriBuilder.fromUri(getBaseUrl(request) + "/auth")
.path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH) .build("RealmName");

the logout gives 204 for client's access type as open.

but when i again hit the service with the token id "t1" after logout.
Still i can get the response. *Note this response doesnt hit keycloak*.

Regards,
Satya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160224/4e6cf206/attachment-0001.html 

From thomas.darimont at googlemail.com  Wed Feb 24 05:26:47 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 24 Feb 2016 11:26:47 +0100
Subject: [keycloak-dev] "Full Scope Allowed" seems to emit roles that the
 user actually doesn't have.
Message-ID: <CAK-7U1h6vqF13am0STuQEVgatXEZN_0sjfRP1A-+BKCfDiTE_Q@mail.gmail.com>

Steps to reproduce:

create client A with client id "client-a" with a newly defined role "user"
create client B with client id "client-b" with a newly defined role "user"

create user A with username "user-a" with "user" role granted for "client-a"
create user B with username "user-b" with "user" role granted for "client-b"

Goto applications tab in account page:
http://localhost:8082/auth/realms/eurodata.local/account/applications

login as user-a

Actual: The listing shows both applications client-a AND client-b
        although the user-a only has a user-role to client-a.
Expected: Only client-a (+ account) applications should be shown

logout

login as user-b

Actual: The listing shows both applications client-a and client-b
        although the user-b only has a user-role to client-b.
Expected: Only client-b (+ account) applications should be shown

By default a client has the "Full Scope Allowed" switch set to "on".
Changing this switch to "off" and explicitly assigning the client role
"user" to "client-a"
in the scope settings for client-a and to the user role for client-b in the
scope settings
for client-b solves the issue.

With this setting only the applications for which a user actually has the
"user" role is shown.

Even though the help text for "Full Scope Allowed" says: "Allows you to
disable all restrictions"
one would expect that "Full Scope Allowed" set to "on" would honor the
assigned roles.

Is there something wrong here or should the help text be more descriptive?
I think the piece of code that does this is: org.keycloak.protocol.oidc.
TokenManager.getAccess(String, boolean, ClientModel, UserModel)

Cheers,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160224/5a583ea0/attachment.html 

From mposolda at redhat.com  Wed Feb 24 06:35:20 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 12:35:20 +0100
Subject: [keycloak-dev] "Full Scope Allowed" seems to emit roles that
 the user actually doesn't have.
In-Reply-To: <CAK-7U1h6vqF13am0STuQEVgatXEZN_0sjfRP1A-+BKCfDiTE_Q@mail.gmail.com>
References: <CAK-7U1h6vqF13am0STuQEVgatXEZN_0sjfRP1A-+BKCfDiTE_Q@mail.gmail.com>
Message-ID: <56CD9578.1000102@redhat.com>

On 24/02/16 11:26, Thomas Darimont wrote:
> Steps to reproduce:
>
> create client A with client id "client-a" with a newly defined role "user"
> create client B with client id "client-b" with a newly defined role "user"
>
> create user A with username "user-a" with "user" role granted for 
> "client-a"
> create user B with username "user-b" with "user" role granted for 
> "client-b"
>
> Goto applications tab in account page:
> http://localhost:8082/auth/realms/eurodata.local/account/applications
>
> login as user-a
>
> Actual: The listing shows both applications client-a AND client-b
>         although the user-a only has a user-role to client-a.
> Expected: Only client-a (+ account) applications should be shown
So "client-a" and "client-b" have fullScopeAllowed on? If yes, then the 
current behaviour is correct IMO. The thing is that user-a is able to 
login to application "client-b" and retrieve the accessToken for 
"client-b". And this accessToken will contain "user" role to "client-a" 
because of fullScopeAllowed.


The scope is used to limit the roles, which will user see after retrieve 
accessToken for particular client. So for example if you limit scope to 
client-a, then accessToken for user-a to client-b won't contain "user" 
role of "client-a". But if you retrieve accessToken for client-a, it 
will contain it.

Since the user-a doesn't have role "user" for "client-b" you will never 
see this role in any access token. So current behaviour is correct to me.

Marek


> logout
>
> login as user-b
>
> Actual: The listing shows both applications client-a and client-b
>         although the user-b only has a user-role to client-b.
> Expected: Only client-b (+ account) applications should be shown
>
> By default a client has the "Full Scope Allowed" switch set to "on".
> Changing this switch to "off" and explicitly assigning the client role 
> "user" to "client-a"
> in the scope settings for client-a and to the user role for client-b 
> in the scope settings
> for client-b solves the issue.
>
> With this setting only the applications for which a user actually has 
> the "user" role is shown.
>
> Even though the help text for "Full Scope Allowed" says: "Allows you 
> to disable all restrictions"
> one would expect that "Full Scope Allowed" set to "on" would honor the 
> assigned roles.
>
> Is there something wrong here or should the help text be more descriptive?
> I think the piece of code that does this is: 
> org.keycloak.protocol.oidc.TokenManager.getAccess(String, boolean, 
> ClientModel, UserModel)
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From thomas.darimont at googlemail.com  Wed Feb 24 08:57:40 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 24 Feb 2016 14:57:40 +0100
Subject: [keycloak-dev] "Full Scope Allowed" seems to emit roles that
 the user actually doesn't have.
In-Reply-To: <56CD9578.1000102@redhat.com>
References: <CAK-7U1h6vqF13am0STuQEVgatXEZN_0sjfRP1A-+BKCfDiTE_Q@mail.gmail.com>
	<56CD9578.1000102@redhat.com>
Message-ID: <CAK-7U1gud9TsVwKUfKO-hZYGhMPnSodMzLP2xR1Tgm7ZvmfB5Q@mail.gmail.com>

What I actually want to do is to restrict the application listing on
the account page to just the clients where a user has a role mapping.
Currently this is only possible via "Full Scope Allowed -> off"
and explicit role mappings.
Then an admin has full control over what applications a user can see in the
listing.

What I now ended up with is modifying the application.ftl in a custom theme
that explicitly excludes clients with no role mappings for the current user
(+ the account client itself).

<#list applications.applications as application>
        <#-- filters out "account" app & anything that the user doesn't
have an explicitly defined role in. -->
        <#if application.client.clientId != 'account' &&
application.resourceRolesAvailable[application.client.clientId]?has_content>

     //render account

        </#if>
</#list>


Here are some of my experiments that describe the default behaviour of the
"Full Scope Allowed" Setting in combination with the application listing in
the account page.

Scenario 1)

client      role            Full Scope Allowed
client-a    "user-role-a"   "on"
client-b    "user-role-b"   "on"

user    roles
user-a  client-a: user-role-a
user-b  client-b: user-role-b

On account/applications page

user    applications with access
user-a  account (full access), client-a (full access), client-b (full
access)
user-b  account (full access), client-a (full access), client-b (full
access)

---

Scenario 2)

client      role            Full Scope Allowed
client-a    "user-role-a"   "off"
client-b    "user-role-a"   "on"

user    roles
user-a  client-a: user-role-a
user-b  client-b: user-role-b

On account/applications page

user    applications with access
user-a  account (full access), client-a (full access), client-b (full
access)
user-b  account (full access), client-b (full access)

---

Scenario 3)

client      role            Full Scope Allowed
client-a    "user-role-a"   "on"
client-b    "user-role-b"   "off"

user    roles
user-a  client-a: user-role-a
user-b  client-b: user-role-b

On account/applications page

user    applications with access
user-a  account (full access), client-a (full access)
user-b  account (full access), client-a (full access), client-b (full
access)

-> user-a sees only the application he has acces to
-> user-b sees however also sees client-a although he doesn't have a role
mapping for client-a

---

Scenario 4)

client      role            Full Scope Allowed
client-a    "user-role-a"   "off"
client-b    "user-role-b"   "off"

user    roles
user-a  client-a: user-role-a
user-b  client-b: user-role-b

On account/applications page

user    applications with access
user-a  account (full access), client-a (full access)
user-b  account (full access), client-b (full access)

-> User only sees the applications for which he has roles
---

Scenario 5) introduced a common client...

client      role            Full Scope Allowed
client-a    "user-role-a"   "off"
client-b    "user-role-b"   "off"
client-c    "user-role-c"   "on"

user    roles
user-a  client-a: user-role-a, client-c: user-role-c
user-b  client-b: user-role-b

On account/applications page

user    applications with access
user-a  account (full access), client-a (full access), client-c (full
access)
user-b  account (full access), client-b (full access), client-c (full
access)

-> user-a sees only the applications he has a role for or access to:
client-a, client-c
-> user-a sees client-c for which he doesn't have a role mapping

Cheers,
Thomas

2016-02-24 12:35 GMT+01:00 Marek Posolda <mposolda at redhat.com>:

> On 24/02/16 11:26, Thomas Darimont wrote:
>
> Steps to reproduce:
>
> create client A with client id "client-a" with a newly defined role "user"
> create client B with client id "client-b" with a newly defined role "user"
>
> create user A with username "user-a" with "user" role granted for
> "client-a"
> create user B with username "user-b" with "user" role granted for
> "client-b"
>
> Goto applications tab in account page:
> http://localhost:8082/auth/realms/eurodata.local/account/applications
>
> login as user-a
>
> Actual: The listing shows both applications client-a AND client-b
>         although the user-a only has a user-role to client-a.
> Expected: Only client-a (+ account) applications should be shown
>
> So "client-a" and "client-b" have fullScopeAllowed on? If yes, then the
> current behaviour is correct IMO. The thing is that user-a is able to login
> to application "client-b" and retrieve the accessToken for "client-b". And
> this accessToken will contain "user" role to "client-a" because of
> fullScopeAllowed.
>
>
> The scope is used to limit the roles, which will user see after retrieve
> accessToken for particular client. So for example if you limit scope to
> client-a, then accessToken for user-a to client-b won't contain "user" role
> of "client-a". But if you retrieve accessToken for client-a, it will
> contain it.
>
> Since the user-a doesn't have role "user" for "client-b" you will never
> see this role in any access token. So current behaviour is correct to me.
>
> Marek
>
>
> logout
>
> login as user-b
>
> Actual: The listing shows both applications client-a and client-b
>         although the user-b only has a user-role to client-b.
> Expected: Only client-b (+ account) applications should be shown
>
> By default a client has the "Full Scope Allowed" switch set to "on".
> Changing this switch to "off" and explicitly assigning the client role
> "user" to "client-a"
> in the scope settings for client-a and to the user role for client-b in
> the scope settings
> for client-b solves the issue.
>
> With this setting only the applications for which a user actually has the
> "user" role is shown.
>
> Even though the help text for "Full Scope Allowed" says: "Allows you to
> disable all restrictions"
> one would expect that "Full Scope Allowed" set to "on" would honor the
> assigned roles.
>
> Is there something wrong here or should the help text be more descriptive?
> I think the piece of code that does this is: org.keycloak.protocol.oidc.
> TokenManager.getAccess(String, boolean, ClientModel, UserModel)
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160224/131e7a99/attachment-0001.html 

From mposolda at redhat.com  Wed Feb 24 09:52:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 24 Feb 2016 15:52:54 +0100
Subject: [keycloak-dev] "Full Scope Allowed" seems to emit roles that
 the user actually doesn't have.
In-Reply-To: <CAK-7U1gud9TsVwKUfKO-hZYGhMPnSodMzLP2xR1Tgm7ZvmfB5Q@mail.gmail.com>
References: <CAK-7U1h6vqF13am0STuQEVgatXEZN_0sjfRP1A-+BKCfDiTE_Q@mail.gmail.com>
	<56CD9578.1000102@redhat.com>
	<CAK-7U1gud9TsVwKUfKO-hZYGhMPnSodMzLP2xR1Tgm7ZvmfB5Q@mail.gmail.com>
Message-ID: <56CDC3C6.9070200@redhat.com>

On 24/02/16 14:57, Thomas Darimont wrote:
> What I actually want to do is to restrict the application listing on
> the account page to just the clients where a user has a role mapping.
> Currently this is only possible via "Full Scope Allowed -> off"
> and explicit role mappings.
Yes, exactly.

Some points:
* Each user is able to retrieve accessToken for each client configured 
in the realm
* The roles in the accessToken for particular client are intersection of:
** roles of user
** scopes of the client user is login to. If client has "Full scope 
allowed" then scopes are not taken into equation, so the roles in 
accessToken are consisted just of the user roles. Also note that client 
doesn't need scope for his own client roles (Those are always added into 
accessToken)

So one of your examples:

In case that "user-a" is member of "client-a:user-role-a" and he login 
to "client-b" what happens is:
- Roles of user contains "client-a:user-role-a"
- Scopes of client "client-b" contains "client-a:user-role-a" as well, 
because client-b has "Full scope allowed" on (which in other words means 
that accessToken will contain all roles of user-a including realm roles 
and roles of all clients)

Result is that accessToken of "user-a" to "client-b" will contain role 
"client-a:user-role-a".

By default, the applications page already filters the clients, which 
user don't have any roles. See 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/forms/account/freemarker/model/ApplicationsBean.java#L56 
. But in the case above, the accessToken will contain the role 
client-a:user-role-a , so it's not the case.

You can look at TokenManager.getAccess to see how it works in details.

The "Full Access" in the "Granted Permissions" and "Granted personal 
info" is applicable just for the clients, which requires consent. It 
contains the roles and personal info, which user already confirmed on 
the consent screen. Maybe the UI should be changed to be more "friendly" 
here...  I think we have JIRA already open to improve usability of 
account management in general.

Marek


> Then an admin has full control over what applications a user can see 
> in the listing.
>
> What I now ended up with is modifying the application.ftl in a custom 
> theme
> that explicitly excludes clients with no role mappings for the current 
> user
> (+ the account client itself).
>
> <#list applications.applications as application>
>         <#-- filters out "account" app & anything that the user 
> doesn't have an explicitly defined role in. -->
>         <#if application.client.clientId != 'account' && 
> application.resourceRolesAvailable[application.client.clientId]?has_content>
>      //render account
>
>         </#if>
> </#list>
>
>
> Here are some of my experiments that describe the default behaviour of 
> the
> "Full Scope Allowed" Setting in combination with the application 
> listing in the account page.
>
> Scenario 1)
>
> client      role            Full Scope Allowed
> client-a    "user-role-a"   "on"
> client-b    "user-role-b"   "on"
>
> user    roles
> user-a  client-a: user-role-a
> user-b  client-b: user-role-b
>
> On account/applications page
>
> user    applications with access
> user-a  account (full access), client-a (full access), client-b (full 
> access)
> user-b  account (full access), client-a (full access), client-b (full 
> access)
>
> ---
>
> Scenario 2)
>
> client      role            Full Scope Allowed
> client-a    "user-role-a"   "off"
> client-b    "user-role-a"   "on"
>
> user    roles
> user-a  client-a: user-role-a
> user-b  client-b: user-role-b
>
> On account/applications page
>
> user    applications with access
> user-a  account (full access), client-a (full access), client-b (full 
> access)
> user-b  account (full access), client-b (full access)
>
> ---
>
> Scenario 3)
>
> client      role            Full Scope Allowed
> client-a    "user-role-a"   "on"
> client-b    "user-role-b"   "off"
>
> user    roles
> user-a  client-a: user-role-a
> user-b  client-b: user-role-b
>
> On account/applications page
>
> user    applications with access
> user-a  account (full access), client-a (full access)
> user-b  account (full access), client-a (full access), client-b (full 
> access)
>
> -> user-a sees only the application he has acces to
> -> user-b sees however also sees client-a although he doesn't have a 
> role mapping for client-a
>
> ---
>
> Scenario 4)
>
> client      role            Full Scope Allowed
> client-a    "user-role-a"   "off"
> client-b    "user-role-b"   "off"
>
> user    roles
> user-a  client-a: user-role-a
> user-b  client-b: user-role-b
>
> On account/applications page
>
> user    applications with access
> user-a  account (full access), client-a (full access)
> user-b  account (full access), client-b (full access)
>
> -> User only sees the applications for which he has roles
> ---
>
> Scenario 5) introduced a common client...
>
> client      role            Full Scope Allowed
> client-a    "user-role-a"   "off"
> client-b    "user-role-b"   "off"
> client-c    "user-role-c"   "on"
>
> user    roles
> user-a  client-a: user-role-a, client-c: user-role-c
> user-b  client-b: user-role-b
>
> On account/applications page
>
> user    applications with access
> user-a  account (full access), client-a (full access), client-c (full 
> access)
> user-b  account (full access), client-b (full access), client-c (full 
> access)
>
> -> user-a sees only the applications he has a role for or access to: 
> client-a, client-c
> -> user-a sees client-c for which he doesn't have a role mapping
>
> Cheers,
> Thomas
>
> 2016-02-24 12:35 GMT+01:00 Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>>:
>
>     On 24/02/16 11:26, Thomas Darimont wrote:
>>     Steps to reproduce:
>>
>>     create client A with client id "client-a" with a newly defined
>>     role "user"
>>     create client B with client id "client-b" with a newly defined
>>     role "user"
>>
>>     create user A with username "user-a" with "user" role granted for
>>     "client-a"
>>     create user B with username "user-b" with "user" role granted for
>>     "client-b"
>>
>>     Goto applications tab in account page:
>>     http://localhost:8082/auth/realms/eurodata.local/account/applications
>>
>>     login as user-a
>>
>>     Actual: The listing shows both applications client-a AND client-b
>>             although the user-a only has a user-role to client-a.
>>     Expected: Only client-a (+ account) applications should be shown
>     So "client-a" and "client-b" have fullScopeAllowed on? If yes,
>     then the current behaviour is correct IMO. The thing is that
>     user-a is able to login to application "client-b" and retrieve the
>     accessToken for "client-b". And this accessToken will contain
>     "user" role to "client-a" because of fullScopeAllowed.
>
>
>     The scope is used to limit the roles, which will user see after
>     retrieve accessToken for particular client. So for example if you
>     limit scope to client-a, then accessToken for user-a to client-b
>     won't contain "user" role of "client-a". But if you retrieve
>     accessToken for client-a, it will contain it.
>
>     Since the user-a doesn't have role "user" for "client-b" you will
>     never see this role in any access token. So current behaviour is
>     correct to me.
>
>     Marek
>
>
>>     logout
>>
>>     login as user-b
>>
>>     Actual: The listing shows both applications client-a and client-b
>>             although the user-b only has a user-role to client-b.
>>     Expected: Only client-b (+ account) applications should be shown
>>
>>     By default a client has the "Full Scope Allowed" switch set to "on".
>>     Changing this switch to "off" and explicitly assigning the client
>>     role "user" to "client-a"
>>     in the scope settings for client-a and to the user role for
>>     client-b in the scope settings
>>     for client-b solves the issue.
>>
>>     With this setting only the applications for which a user actually
>>     has the "user" role is shown.
>>
>>     Even though the help text for "Full Scope Allowed" says: "Allows
>>     you to disable all restrictions"
>>     one would expect that "Full Scope Allowed" set to "on" would
>>     honor the assigned roles.
>>
>>     Is there something wrong here or should the help text be more
>>     descriptive?
>>     I think the piece of code that does this is:
>>     org.keycloak.protocol.oidc.TokenManager.getAccess(String,
>>     boolean, ClientModel, UserModel)
>>
>>     Cheers,
>>     Thomas
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From peter.krivansky at traveltainment.de  Thu Feb 25 10:10:11 2016
From: peter.krivansky at traveltainment.de (Peter Krivansky)
Date: Thu, 25 Feb 2016 15:10:11 +0000
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
	/admin/serverinfo
Message-ID: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>

Hello,

I have a Keycloak cluster with two servers, in front of each Keaycloak is Apache running.

LB
/\
  Host A    Host B

Now, Host-A and Host-B are in different subnets, due to this design we are running jGroups via TCP.
Now everything is working fine, except for the Keycloak Admin console, once a user tries to log in, they get for a milisecond in to the Admin console, but then they get redirected to the login page immediately.
When I disable Host-A or Host-B on the Loadbalancer, (new sessions will land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work normally.
During the immediate redirection there is only this one WARNING in the Server.log:

15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-10) Failed executing GET /admin/serverinfo: org.jboss.resteasy.spi.UnauthorizedException: Bearer
         at org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
         at org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
         at java.lang.reflect.Method.invoke(Method.java:498)
         at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
         at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
         at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
         at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
         at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
         at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
         at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
         at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
         at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
         at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
         at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
         at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
         at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
         at java.lang.Thread.run(Thread.java:745)

I attached my domain.xml
Have I missed something, or what did I wrong?

With Kind regards Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160225/a86f4b57/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: domain.xml
Type: application/xml
Size: 95093 bytes
Desc: domain.xml
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160225/a86f4b57/attachment-0001.rdf 

From sthorger at redhat.com  Fri Feb 26 01:46:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 07:46:30 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
	/admin/serverinfo
In-Reply-To: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
Message-ID: <CAJgngAd1R=bAKW+HnupcQThmY+Xh8kD+ffs+eFq_jgnwSUcAzA@mail.gmail.com>

Are you sure clustering is configured properly? Is the time in sync?

On 25 February 2016 at 16:10, Peter Krivansky <
peter.krivansky at traveltainment.de> wrote:

> Hello,
>
>
>
> I have a Keycloak cluster with two servers, in front of each Keaycloak is
> Apache running.
>
>
>
> LB
>
> /\
>
>   Host A    Host B
>
>
>
> Now, Host-A and Host-B are in different subnets, due to this design we are
> running jGroups via TCP.
>
> Now everything is working fine, except for the Keycloak Admin console,
> once a user tries to log in, they get for a milisecond in to the Admin
> console, but then they get redirected to the login page immediately.
>
> When I disable Host-A or Host-B on the Loadbalancer, (new sessions will
> land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work
> normally.
>
> During the immediate redirection there is only this one WARNING in the
> Server.log:
>
>
>
> 15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
> task-10) Failed executing GET /admin/serverinfo:
> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>
>          at
> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>
>          at
> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>          at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
>          at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>          at java.lang.reflect.Method.invoke(Method.java:498)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>
>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
>          at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>
>          at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>
>          at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>
>          at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>
>          at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>
>          at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>
>          at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>
>          at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>
>          at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>
>          at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>
>          at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>
>          at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>
>          at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>
>          at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>
>          at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>          at java.lang.Thread.run(Thread.java:745)
>
>
>
> I attached my domain.xml
>
> Have I missed something, or what did I wrong?
>
>
>
> With Kind regards Peter
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/9f7439e3/attachment.html 

From velias at redhat.com  Fri Feb 26 03:29:38 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 26 Feb 2016 09:29:38 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
 /admin/serverinfo
In-Reply-To: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
Message-ID: <56D00CF2.2010700@redhat.com>

What about configuring Loadbalancer to use sticky sessions?

Vlastimil

On 25.2.2016 16:10, Peter Krivansky wrote:
>
> Hello,
>
> I have a Keycloak cluster with two servers, in front of each Keaycloak 
> is Apache running.
>
> LB
>
> /\
>
>   Host A    Host B
>
> Now, Host-A and Host-B are in different subnets, due to this design we 
> are running jGroups via TCP.
>
> Now everything is working fine, except for the Keycloak Admin console, 
> once a user tries to log in, they get for a milisecond in to the Admin 
> console, but then they get redirected to the login page immediately.
>
> When I disable Host-A or Host-B on the Loadbalancer, (new sessions 
> will land only on Hst-A or Host-B) the Login to Keycloak Admin Console 
> will work normally.
>
> During the immediate redirection there is only this one WARNING in the 
> Server.log:
>
> 15:41:42,886 WARN [org.jboss.resteasy.core.ExceptionHandler] (default 
> task-10) Failed executing GET /admin/serverinfo: 
> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>
>          at 
> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>
>          at 
> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>          at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
>          at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>          at java.lang.reflect.Method.invoke(Method.java:498)
>
>          at 
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>
>          at 
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>
>          at 
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>
>          at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>
>          at 
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>
>          at 
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>
>          at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>
>          at 
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>
>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
>          at 
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>
>          at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>
>          at 
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>
>          at 
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>
>          at 
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>
>          at 
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>
>          at 
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>
>          at 
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>
>          at 
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>
>          at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at 
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>
>          at 
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>
>          at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at 
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>
>          at 
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>
>          at 
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>
>          at 
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>
>          at 
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>
>          at 
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>
>          at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at 
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>
>          at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at 
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at 
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>
>          at 
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>
>          at 
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>
>          at 
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>
>          at 
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>
>          at 
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>
>          at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>          at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>          at java.lang.Thread.run(Thread.java:745)
>
> I attached my domain.xml
>
> Have I missed something, or what did I wrong?
>
> With Kind regards Peter
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Fri Feb 26 03:33:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 09:33:19 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
	/admin/serverinfo
In-Reply-To: <56D00CF2.2010700@redhat.com>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
	<56D00CF2.2010700@redhat.com>
Message-ID: <CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>

This should work just fine without sticky sessions. We also don't support
sticky sessions at the moment as there's no cookie to stick on. We're going
to look into supporting sticky sessions soon.

On 26 February 2016 at 09:29, Vlastimil Elias <velias at redhat.com> wrote:

> What about configuring Loadbalancer to use sticky sessions?
>
> Vlastimil
>
> On 25.2.2016 16:10, Peter Krivansky wrote:
>
> Hello,
>
>
>
> I have a Keycloak cluster with two servers, in front of each Keaycloak is
> Apache running.
>
>
>
> LB
>
> /\
>
>   Host A    Host B
>
>
>
> Now, Host-A and Host-B are in different subnets, due to this design we are
> running jGroups via TCP.
>
> Now everything is working fine, except for the Keycloak Admin console,
> once a user tries to log in, they get for a milisecond in to the Admin
> console, but then they get redirected to the login page immediately.
>
> When I disable Host-A or Host-B on the Loadbalancer, (new sessions will
> land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work
> normally.
>
> During the immediate redirection there is only this one WARNING in the
> Server.log:
>
>
>
> 15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
> task-10) Failed executing GET /admin/serverinfo:
> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>
>          at
> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>
>          at
> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>
>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>          at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>
>          at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
>          at java.lang.reflect.Method.invoke(Method.java:498)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>
>          at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>
>          at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>
>          at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>
>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>
>          at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>
>          at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>
>          at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>
>          at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>
>          at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>
>          at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>
>          at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>
>          at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>
>          at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>
>          at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>
>          at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>
>          at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>
>          at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>
>          at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>
>          at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>
>          at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>
>          at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>
>          at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
>          at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>
>          at java.lang.Thread.run(Thread.java:745)
>
>
>
> I attached my domain.xml
>
> Have I missed something, or what did I wrong?
>
>
>
> With Kind regards Peter
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/57977466/attachment.html 

From velias at redhat.com  Fri Feb 26 04:24:39 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 26 Feb 2016 10:24:39 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
 /admin/serverinfo
In-Reply-To: <CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
	<56D00CF2.2010700@redhat.com>
	<CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>
Message-ID: <56D019D7.6090606@redhat.com>

Hi,

On 26.2.2016 09:33, Stian Thorgersen wrote:
> This should work just fine without sticky sessions.

Sure, but there may be latencies or so between nodes which may bring 
problems, and it is always hard to troubleshoot this kind of problems. 
Sticky session generally lowers probability of this kind of operational 
problems, this is why I like them and use them ;-) But correctly 
configured replication is necessary even in case of sticky sessions to 
have failover.

> We also don't support sticky sessions at the moment as there's no 
> cookie to stick on. We're going to look into supporting sticky 
> sessions soon.

Some loadbalancers are able to make sticky session on his owns, even if 
application itself do not provide any cookie. We use this on RHD 
website, we have F5 loadbalancer which handles sticky sessions for us (I 
think it creates his own cookie), and is able correctly failover when 
keycloak node dies.

So don't tell your users that Keycloak doesn't support sticky sessions 
at all, it works with sticky sessions correctly if provided by 
loadbalancer by some way not relying on cookie provided by Keycloak 
itself. ;-)

Vlastimil

>
> On 26 February 2016 at 09:29, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     What about configuring Loadbalancer to use sticky sessions?
>
>     Vlastimil
>
>     On 25.2.2016 16:10, Peter Krivansky wrote:
>>
>>     Hello,
>>
>>     I have a Keycloak cluster with two servers, in front of each
>>     Keaycloak is Apache running.
>>
>>     LB
>>
>>     /\
>>
>>       Host A  Host B
>>
>>     Now, Host-A and Host-B are in different subnets, due to this
>>     design we are running jGroups via TCP.
>>
>>     Now everything is working fine, except for the Keycloak Admin
>>     console, once a user tries to log in, they get for a milisecond
>>     in to the Admin console, but then they get redirected to the
>>     login page immediately.
>>
>>     When I disable Host-A or Host-B on the Loadbalancer, (new
>>     sessions will land only on Hst-A or Host-B) the Login to Keycloak
>>     Admin Console will work normally.
>>
>>     During the immediate redirection there is only this one WARNING
>>     in the Server.log:
>>
>>     15:41:42,886 WARN [org.jboss.resteasy.core.ExceptionHandler]
>>     (default task-10) Failed executing GET /admin/serverinfo:
>>     org.jboss.resteasy.spi.UnauthorizedException: Bearer
>>
>>     at
>>     org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>>
>>     at
>>     org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>>
>>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>>     at
>>     sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>>     at
>>     sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>>     at java.lang.reflect.Method.invoke(Method.java:498)
>>
>>     at
>>     org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>>
>>     at
>>     org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>>
>>     at
>>     org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>>
>>     at
>>     org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>
>>     at
>>     org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>
>>     at
>>     org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>
>>     at
>>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>
>>     at
>>     org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>
>>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>>
>>     at
>>     io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>
>>     at
>>     org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>
>>     at
>>     io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>
>>     at
>>     io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>
>>     at
>>     io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>
>>     at
>>     io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>
>>     at
>>     org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>
>>     at
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>     at
>>     io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>
>>     at
>>     io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>
>>        at
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>     at
>>     io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>
>>     at
>>     io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>
>>     at
>>     io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>
>>     at
>>     io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>
>>     at
>>     io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>
>>        at
>>     io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>
>>     at
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>     at
>>     org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>
>>     at
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>     at
>>     io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>
>>     at
>>     io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>
>>     at
>>     io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>
>>     at
>>     io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>
>>     at
>>     java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>>     at
>>     java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>>     at java.lang.Thread.run(Thread.java:745)
>>
>>     I attached my domain.xml
>>
>>     Have I missed something, or what did I wrong?
>>
>>     With Kind regards Peter
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From rajat.nair at hpe.com  Fri Feb 26 07:10:53 2016
From: rajat.nair at hpe.com (Nair, Rajat)
Date: Fri, 26 Feb 2016 12:10:53 +0000
Subject: [keycloak-dev] Does Keycloak support OAuth PKCE (Proof Key for Code
	Exchange)
Message-ID: <E8E85ED231DB984CA315C4439410229A1F1A7F13@G9W0758.americas.hpqcorp.net>

Hi,

Does Keycloak support PKCE (Proof Key for Code Exchange) described here - https://tools.ietf.org/html/rfc7636

-- Rajat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/8fa4dd73/attachment.html 

From sthorger at redhat.com  Fri Feb 26 07:27:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 13:27:47 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
	/admin/serverinfo
In-Reply-To: <56D019D7.6090606@redhat.com>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
	<56D00CF2.2010700@redhat.com>
	<CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>
	<56D019D7.6090606@redhat.com>
Message-ID: <CAJgngAf7d9Sw0LCNXOeBLgNAL48JTUDuj=vkoEi5e5_cPDTAYA@mail.gmail.com>

On 26 February 2016 at 10:24, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> On 26.2.2016 09:33, Stian Thorgersen wrote:
>
> This should work just fine without sticky sessions.
>
>
> Sure, but there may be latencies or so between nodes which may bring
> problems, and it is always hard to troubleshoot this kind of problems.
> Sticky session generally lowers probability of this kind of operational
> problems, this is why I like them and use them ;-) But correctly configured
> replication is necessary even in case of sticky sessions to have failover.
>

That's why we use sync, not async.

But, I agree sticky sessions would be nice.


>
>
> We also don't support sticky sessions at the moment as there's no cookie
> to stick on. We're going to look into supporting sticky sessions soon.
>
>
> Some loadbalancers are able to make sticky session on his owns, even if
> application itself do not provide any cookie. We use this on RHD website,
> we have F5 loadbalancer which handles sticky sessions for us (I think it
> creates his own cookie), and is able correctly failover when keycloak node
> dies.
>

What makes it non-trivial is that there are two different things using the
same session and user. The users browser (for login redirects and also
html5 apps) and also server-side applications. These will have different IP
addresses. So simply setting up sticky sessions based on the source won't
work.


>
> So don't tell your users that Keycloak doesn't support sticky sessions at
> all, it works with sticky sessions correctly if provided by loadbalancer by
> some way not relying on cookie provided by Keycloak itself. ;-)
>

>
> Vlastimil
>
>
>
> On 26 February 2016 at 09:29, Vlastimil Elias <velias at redhat.com> wrote:
>
>> What about configuring Loadbalancer to use sticky sessions?
>>
>> Vlastimil
>>
>> On 25.2.2016 16:10, Peter Krivansky wrote:
>>
>> Hello,
>>
>>
>>
>> I have a Keycloak cluster with two servers, in front of each Keaycloak is
>> Apache running.
>>
>>
>>
>> LB
>>
>> /\
>>
>>   Host A    Host B
>>
>>
>>
>> Now, Host-A and Host-B are in different subnets, due to this design we
>> are running jGroups via TCP.
>>
>> Now everything is working fine, except for the Keycloak Admin console,
>> once a user tries to log in, they get for a milisecond in to the Admin
>> console, but then they get redirected to the login page immediately.
>>
>> When I disable Host-A or Host-B on the Loadbalancer, (new sessions will
>> land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work
>> normally.
>>
>> During the immediate redirection there is only this one WARNING in the
>> Server.log:
>>
>>
>>
>> 15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
>> task-10) Failed executing GET /admin/serverinfo:
>> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>>
>>          at
>> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>>
>>          at
>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>>
>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>>          at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>
>>          at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>
>>          at java.lang.reflect.Method.invoke(Method.java:498)
>>
>>          at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>>
>>          at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>>
>>          at
>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>>
>>          at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>
>>          at
>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>
>>          at
>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>
>>          at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>
>>          at
>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>
>>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>
>>          at
>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>>
>>          at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>
>>          at
>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>
>>          at
>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>
>>          at
>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>
>>          at
>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>
>>          at
>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>
>>          at
>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>
>>          at
>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>
>>          at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>          at
>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>
>>          at
>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>
>>          at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>          at
>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>
>>          at
>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>
>>          at
>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>
>>          at
>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>
>>          at
>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>
>>          at
>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>
>>          at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>          at
>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>
>>          at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>          at
>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>
>>          at
>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>
>>          at
>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>
>>          at
>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>
>>          at
>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>
>>          at
>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>
>>          at
>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>
>>          at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>
>>          at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>
>>          at java.lang.Thread.run(Thread.java:745)
>>
>>
>>
>> I attached my domain.xml
>>
>> Have I missed something, or what did I wrong?
>>
>>
>>
>> With Kind regards Peter
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/87fbb1b3/attachment-0001.html 

From sthorger at redhat.com  Fri Feb 26 07:32:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 13:32:48 +0100
Subject: [keycloak-dev] Does Keycloak support OAuth PKCE (Proof Key for
 Code Exchange)
In-Reply-To: <E8E85ED231DB984CA315C4439410229A1F1A7F13@G9W0758.americas.hpqcorp.net>
References: <E8E85ED231DB984CA315C4439410229A1F1A7F13@G9W0758.americas.hpqcorp.net>
Message-ID: <CAJgngAc=wThaTmvSZjptN-SR-7_hUpTsVixjUTUvfa+=KOwgEA@mail.gmail.com>

Not at the moment. It's definitively something we'll look at adding though.

On 26 February 2016 at 13:10, Nair, Rajat <rajat.nair at hpe.com> wrote:

> Hi,
>
>
>
> Does Keycloak support PKCE (Proof Key for Code Exchange) described here -
> https://tools.ietf.org/html/rfc7636
>
>
>
> -- Rajat
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/8fc6ed28/attachment.html 

From velias at redhat.com  Fri Feb 26 08:56:47 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 26 Feb 2016 14:56:47 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
 /admin/serverinfo
In-Reply-To: <CAJgngAf7d9Sw0LCNXOeBLgNAL48JTUDuj=vkoEi5e5_cPDTAYA@mail.gmail.com>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
	<56D00CF2.2010700@redhat.com>
	<CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>
	<56D019D7.6090606@redhat.com>
	<CAJgngAf7d9Sw0LCNXOeBLgNAL48JTUDuj=vkoEi5e5_cPDTAYA@mail.gmail.com>
Message-ID: <56D0599F.6030100@redhat.com>

Sure thing, sticky session can cover requests from browsers only, KC 
state replication is always necessary to cover requests from server-side 
applications.

Vl.

On 26.2.2016 13:27, Stian Thorgersen wrote:
>
>
> On 26 February 2016 at 10:24, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     On 26.2.2016 09:33, Stian Thorgersen wrote:
>>     This should work just fine without sticky sessions.
>
>     Sure, but there may be latencies or so between nodes which may
>     bring problems, and it is always hard to troubleshoot this kind of
>     problems. Sticky session generally lowers probability of this kind
>     of operational problems, this is why I like them and use them ;-)
>     But correctly configured replication is necessary even in case of
>     sticky sessions to have failover.
>
>
> That's why we use sync, not async.
>
> But, I agree sticky sessions would be nice.
>
>
>
>>     We also don't support sticky sessions at the moment as there's no
>>     cookie to stick on. We're going to look into supporting sticky
>>     sessions soon.
>
>     Some loadbalancers are able to make sticky session on his owns,
>     even if application itself do not provide any cookie. We use this
>     on RHD website, we have F5 loadbalancer which handles sticky
>     sessions for us (I think it creates his own cookie), and is able
>     correctly failover when keycloak node dies.
>
>
> What makes it non-trivial is that there are two different things using 
> the same session and user. The users browser (for login redirects and 
> also html5 apps) and also server-side applications. These will have 
> different IP addresses. So simply setting up sticky sessions based on 
> the source won't work.
>
>
>     So don't tell your users that Keycloak doesn't support sticky
>     sessions at all, it works with sticky sessions correctly if
>     provided by loadbalancer by some way not relying on cookie
>     provided by Keycloak itself. ;-)
>
>
>
>     Vlastimil
>
>
>>
>>     On 26 February 2016 at 09:29, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         What about configuring Loadbalancer to use sticky sessions?
>>
>>         Vlastimil
>>
>>         On 25.2.2016 16:10, Peter Krivansky wrote:
>>>
>>>         Hello,
>>>
>>>         I have a Keycloak cluster with two servers, in front of each
>>>         Keaycloak is Apache running.
>>>
>>>         LB
>>>
>>>         /\
>>>
>>>           Host A    Host B
>>>
>>>         Now, Host-A and Host-B are in different subnets, due to this
>>>         design we are running jGroups via TCP.
>>>
>>>         Now everything is working fine, except for the Keycloak
>>>         Admin console, once a user tries to log in, they get for a
>>>         milisecond in to the Admin console, but then they get
>>>         redirected to the login page immediately.
>>>
>>>         When I disable Host-A or Host-B on the Loadbalancer, (new
>>>         sessions will land only on Hst-A or Host-B) the Login to
>>>         Keycloak Admin Console will work normally.
>>>
>>>         During the immediate redirection there is only this one
>>>         WARNING in the Server.log:
>>>
>>>         15:41:42,886 WARN [org.jboss.resteasy.core.ExceptionHandler]
>>>         (default task-10) Failed executing GET /admin/serverinfo:
>>>         org.jboss.resteasy.spi.UnauthorizedException: Bearer
>>>
>>>                  at
>>>         org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>>>
>>>                  at
>>>         org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>>>
>>>                  at
>>>         sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>>                  at
>>>         sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>                  at
>>>         sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>                  at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>>                  at
>>>         org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>>>
>>>                  at
>>>         org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>>>
>>>                  at
>>>         org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>>>
>>>                  at
>>>         org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>>
>>>                  at
>>>         org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>>
>>>                  at
>>>         org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>>
>>>                  at
>>>         org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>
>>>                  at
>>>         org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>
>>>                  at
>>>         javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>>
>>>                  at
>>>         org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>>
>>>                  at
>>>         io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>
>>>                  at
>>>         org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>
>>>                  at
>>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>
>>>                  at
>>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>                  at
>>>         io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>
>>>                  at
>>>         io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>>
>>>                  at
>>>         io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>
>>>                  at
>>>         io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>>
>>>                  at
>>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>                  at
>>>         org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>
>>>                  at
>>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>                  at
>>>         io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>>
>>>                  at
>>>         io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>>
>>>                  at
>>>         io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>>
>>>                  at
>>>         io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>>
>>>                  at
>>>         java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>
>>>                  at
>>>         java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>
>>>                  at java.lang.Thread.run(Thread.java:745)
>>>
>>>         I attached my domain.xml
>>>
>>>         Have I missed something, or what did I wrong?
>>>
>>>         With Kind regards Peter
>>>
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>         -- 
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Fri Feb 26 09:05:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 26 Feb 2016 15:05:48 +0100
Subject: [keycloak-dev] Keycload Admin page Failed Executing GET
	/admin/serverinfo
In-Reply-To: <56D0599F.6030100@redhat.com>
References: <928D7EA37F707B43B6CE2201274CD7534149DDE1@EX-TT-AC-01.traveltainment.int>
	<56D00CF2.2010700@redhat.com>
	<CAJgngAfMygGmHBasg1nHdNHhzxwMooZt+BtY5dH5MWBey4+new@mail.gmail.com>
	<56D019D7.6090606@redhat.com>
	<CAJgngAf7d9Sw0LCNXOeBLgNAL48JTUDuj=vkoEi5e5_cPDTAYA@mail.gmail.com>
	<56D0599F.6030100@redhat.com>
Message-ID: <CAJgngAdHU+PxUjj84XcbWmby4suyX6gxOC_jnC24MCSFNV+EBA@mail.gmail.com>

Unless we can use a header or cookie on the server-side to do sticky
sessions there as well. We could extend adapters to include it.

On 26 February 2016 at 14:56, Vlastimil Elias <velias at redhat.com> wrote:

> Sure thing, sticky session can cover requests from browsers only, KC state
> replication is always necessary to cover requests from server-side
> applications.
>
> Vl.
>
>
> On 26.2.2016 13:27, Stian Thorgersen wrote:
>
>
>
> On 26 February 2016 at 10:24, Vlastimil Elias < <velias at redhat.com>
> velias at redhat.com> wrote:
>
>> Hi,
>>
>> On 26.2.2016 09:33, Stian Thorgersen wrote:
>>
>> This should work just fine without sticky sessions.
>>
>>
>> Sure, but there may be latencies or so between nodes which may bring
>> problems, and it is always hard to troubleshoot this kind of problems.
>> Sticky session generally lowers probability of this kind of operational
>> problems, this is why I like them and use them ;-) But correctly configured
>> replication is necessary even in case of sticky sessions to have failover.
>>
>
> That's why we use sync, not async.
>
> But, I agree sticky sessions would be nice.
>
>
>>
>>
>> We also don't support sticky sessions at the moment as there's no cookie
>> to stick on. We're going to look into supporting sticky sessions soon.
>>
>>
>> Some loadbalancers are able to make sticky session on his owns, even if
>> application itself do not provide any cookie. We use this on RHD website,
>> we have F5 loadbalancer which handles sticky sessions for us (I think it
>> creates his own cookie), and is able correctly failover when keycloak node
>> dies.
>>
>
> What makes it non-trivial is that there are two different things using the
> same session and user. The users browser (for login redirects and also
> html5 apps) and also server-side applications. These will have different IP
> addresses. So simply setting up sticky sessions based on the source won't
> work.
>
>
>>
>> So don't tell your users that Keycloak doesn't support sticky sessions at
>> all, it works with sticky sessions correctly if provided by loadbalancer by
>> some way not relying on cookie provided by Keycloak itself. ;-)
>>
>
>>
>> Vlastimil
>>
>>
>>
>> On 26 February 2016 at 09:29, Vlastimil Elias < <velias at redhat.com>
>> velias at redhat.com> wrote:
>>
>>> What about configuring Loadbalancer to use sticky sessions?
>>>
>>> Vlastimil
>>>
>>> On 25.2.2016 16:10, Peter Krivansky wrote:
>>>
>>> Hello,
>>>
>>>
>>>
>>> I have a Keycloak cluster with two servers, in front of each Keaycloak
>>> is Apache running.
>>>
>>>
>>>
>>> LB
>>>
>>> /\
>>>
>>>   Host A    Host B
>>>
>>>
>>>
>>> Now, Host-A and Host-B are in different subnets, due to this design we
>>> are running jGroups via TCP.
>>>
>>> Now everything is working fine, except for the Keycloak Admin console,
>>> once a user tries to log in, they get for a milisecond in to the Admin
>>> console, but then they get redirected to the login page immediately.
>>>
>>> When I disable Host-A or Host-B on the Loadbalancer, (new sessions will
>>> land only on Hst-A or Host-B) the Login to Keycloak Admin Console will work
>>> normally.
>>>
>>> During the immediate redirection there is only this one WARNING in the
>>> Server.log:
>>>
>>>
>>>
>>> 15:41:42,886 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default
>>> task-10) Failed executing GET /admin/serverinfo:
>>> org.jboss.resteasy.spi.UnauthorizedException: Bearer
>>>
>>>          at
>>> org.keycloak.services.resources.admin.AdminRoot.authenticateRealmAdminRequest(AdminRoot.java:156)
>>>
>>>          at
>>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:209)
>>>
>>>          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>
>>>          at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>
>>>          at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>
>>>          at java.lang.reflect.Method.invoke(Method.java:498)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:81)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:60)
>>>
>>>          at
>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:102)
>>>
>>>          at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>>>
>>>          at
>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>>>
>>>          at
>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>>>
>>>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>>>
>>>          at
>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>>>
>>>          at
>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>>>
>>>          at
>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>>>
>>>          at
>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>>>
>>>          at
>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>>>
>>>          at
>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>>>
>>>          at
>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>>>
>>>          at
>>> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>>>
>>>          at
>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>>>
>>>          at
>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>>>
>>>          at
>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>>>
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>>
>>>          at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>>>
>>>          at java.lang.Thread.run(Thread.java:745)
>>>
>>>
>>>
>>> I attached my domain.xml
>>>
>>> Have I missed something, or what did I wrong?
>>>
>>>
>>>
>>> With Kind regards Peter
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160226/049bfe8b/attachment-0001.html 

From yelata at blulogix.com  Mon Feb 29 03:53:00 2016
From: yelata at blulogix.com (Yasser El-ata)
Date: Mon, 29 Feb 2016 10:53:00 +0200
Subject: [keycloak-dev] CRUD Using KeyCloak
Message-ID: <CAHnbcZi1UV-_1b8XEYHCxuRNzuT2T2d+drrUpX_EWa=3brzauA@mail.gmail.com>

Hello , i wan't to create CRUD using KeyCloak , i have an angularJS
application and it's use KeyCloak

My case is : i have screens in my application that contain sub screens and
every sub screen contain CRUD roles (CREATE , READ , UPDATE , DELETE) ,
it's may contain multi levels

the screenshot may make the case more clear

the normal client roles is not enough for me or maybe i miss understand
some thing

could you please help me how to create these roles in KeyCloak , or if
KeyCloak is support roles like this or if there is any other way to create
them ?

Thanks

-- 
Yasser El-Ata
Java Developer
BluLogix
737 Walker Rd Ste 3, Great Falls, VA 22066
t: 443.333.4100 | f: 443.333.4101
*www.blulogix.com <http://www.blueoss.com/>*

The information transmitted is intended only for the person(s) to whom it
is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any
action in reliance upon, this information by persons or entities other than
the intended recipient is prohibited. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160229/6b052763/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ACCESS LEVELS - New Page.png
Type: image/png
Size: 32777 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160229/6b052763/attachment-0001.png 

From gambol99 at gmail.com  Mon Feb 29 08:46:48 2016
From: gambol99 at gmail.com (gambol)
Date: Mon, 29 Feb 2016 13:46:48 +0000
Subject: [keycloak-dev] Office 365
In-Reply-To: <56B0ABDC.4050508@redhat.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
	<CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
	<56A9FC92.4060801@redhat.com>
	<CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>
	<56B0ABDC.4050508@redhat.com>
Message-ID: <CA+AP+fObBUw8uJOX9Zwa=+bLHXM5rTom2s_q_kYDWewfRCUQGQ@mail.gmail.com>

Hiya

Just a follow up, the delay being we had to wait for our accounts to be
upgraded to Office 365 Premium accounts (for SAML access); integration with
Office 365 works perfectly with the SAML connector.

Rohith

On Tue, Feb 2, 2016 at 1:15 PM, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> I found this description of differences for the two Microsoft account types
>
>
> http://www.brucebnews.com/2013/04/the-difference-between-a-microsoft-account-and-an-office-365-account/
>
> really tricky in some cases ;-)
>
> Vlastimil
>
>
> On 28.1.2016 14:58, Jorge Sol?rzano wrote:
>
> Is Office 365 using something diferent to Microsoft Live?
>
> Keycloak adds support to Microsoft Live in 1.8 CR2, It should work with
> Office 365.
>
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> On Thu, Jan 28, 2016 at 5:33 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>> Seems that office365 supports OpenID Connect. In this case, you can try
>> to configure generic "OpenID Connect v1.0" provider in our admin console.
>>
>> Marek
>>
>> On 28/01/16 10:03, gambol wrote:
>>
>> Was wondering if anyone has or knows if Keycloak supports adding office
>> 365 as a identity provider?
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://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 listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160229/740ae799/attachment.html 

From bburke at redhat.com  Mon Feb 29 09:54:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Feb 2016 09:54:11 -0500
Subject: [keycloak-dev] rebasing
Message-ID: <56D45B93.20706@redhat.com>

How you guys do this?  I did a rebase -i and squashed everything but the 
PR contained diffs of merged files and not just my changes.

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


From srossillo at smartling.com  Mon Feb 29 09:59:24 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 29 Feb 2016 09:59:24 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D45B93.20706@redhat.com>
References: <56D45B93.20706@redhat.com>
Message-ID: <3243ED46-BD0A-4011-9C14-9E8AF65EA389@smartling.com>

git rebase -i is helpful for merging together local commits.

Say you did 5 commits and they?re really a single feature. I usually, do:

git rebase -i HEAD~5 and use ?fixup? to make them one commit.

Lastly, before pushing to create a PR, I rebase on master. This shouldn?t be interactive unless there are conflicts.  That?s just a:

git checkout master
git pull -r
git checkout feature-branch
git rebase master



Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 29, 2016, at 9:54 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> How you guys do this?  I did a rebase -i and squashed everything but the 
> PR contained diffs of merged files and not just my changes.
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Feb 29 10:23:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 29 Feb 2016 16:23:20 +0100
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D45B93.20706@redhat.com>
References: <56D45B93.20706@redhat.com>
Message-ID: <CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>

I just do:

git fetch upstream
git rebase upstream/master

And that's it

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

> How you guys do this?  I did a rebase -i and squashed everything but the
> PR contained diffs of merged files and not just my changes.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160229/a18da9f4/attachment.html 

From bburke at redhat.com  Mon Feb 29 11:22:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 29 Feb 2016 11:22:58 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
Message-ID: <56D47062.1000905@redhat.com>

can you do that after you've committed your local repo without screwing 
anything?

On 2/29/2016 10:23 AM, Stian Thorgersen wrote:
> I just do:
>
> git fetch upstream
> git rebase upstream/master
>
> And that's it
>
> On 29 February 2016 at 15:54, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     How you guys do this?  I did a rebase -i and squashed everything
>     but the
>     PR contained diffs of merged files and not just my changes.
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

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

From mposolda at redhat.com  Mon Feb 29 11:39:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 29 Feb 2016 17:39:24 +0100
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D47062.1000905@redhat.com>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
	<56D47062.1000905@redhat.com>
Message-ID: <56D4743C.3000109@redhat.com>

Yes, you can. In this case your commit will be put as last commit after 
existing commits and your commit will receive new commit ID.

Few other points:
- If there is some conflict during rebase, the command "git rebase 
upstream/master" will fail and it will show you which files are 
conflicting. So in this case you need to manually resolve conflicts like:
git add some/path/ConflictingFile.java
git rebase --continue

- For the case you already pushed to github and then you rebased, the 
commit numbers of your commits won't match, so you need to do:
git push origin master --force

Marek


On 29/02/16 17:22, Bill Burke wrote:
> can you do that after you've committed your local repo without 
> screwing anything?
>
> On 2/29/2016 10:23 AM, Stian Thorgersen wrote:
>> I just do:
>>
>> git fetch upstream
>> git rebase upstream/master
>>
>> And that's it
>>
>> On 29 February 2016 at 15:54, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     How you guys do this?  I did a rebase -i and squashed everything
>>     but the
>>     PR contained diffs of merged files and not just my changes.
>>
>>     --
>>     Bill Burke
>>     JBoss, a division of Red Hat
>>     http://bill.burkecentral.com
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From juraci at kroehling.de  Mon Feb 29 12:12:19 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 29 Feb 2016 18:12:19 +0100
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D4743C.3000109@redhat.com>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
	<56D47062.1000905@redhat.com> <56D4743C.3000109@redhat.com>
Message-ID: <56D47BF3.1040900@kroehling.de>

On 29.02.2016 17:39, Marek Posolda wrote:
> git push origin master --force

Just be extra careful on this command, as it is potentially destructive 
when applied to the "main" repository. As a general rule, I use 
"--force" only on my branches, and never on master (even less on the 
"real" origin/upstream).

By the way: this is a good time to check if the main repository is 
protected against force-pushes: http://snag.gy/2KjLY.jpg

- Juca.


From srossillo at smartling.com  Mon Feb 29 12:14:35 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 29 Feb 2016 12:14:35 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D47BF3.1040900@kroehling.de>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
	<56D47062.1000905@redhat.com> <56D4743C.3000109@redhat.com>
	<56D47BF3.1040900@kroehling.de>
Message-ID: <BD5F4D24-FAA3-4631-B2D7-7A150A0525CB@smartling.com>

+1 do PRs from a branch and never force push master (even your own).

Scott Rossillo
Smartling | Senior Software Engineer
srossillo at smartling.com

> On Feb 29, 2016, at 12:12 PM, Juraci Paix?o Kr?hling <juraci at kroehling.de> wrote:
> 
> On 29.02.2016 17:39, Marek Posolda wrote:
>> git push origin master --force
> 
> Just be extra careful on this command, as it is potentially destructive 
> when applied to the "main" repository. As a general rule, I use 
> "--force" only on my branches, and never on master (even less on the 
> "real" origin/upstream).
> 
> By the way: this is a good time to check if the main repository is 
> protected against force-pushes: http://snag.gy/2KjLY.jpg
> 
> - Juca.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ssilvert at redhat.com  Mon Feb 29 13:05:00 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 29 Feb 2016 13:05:00 -0500
Subject: [keycloak-dev] rebasing
In-Reply-To: <56D45B93.20706@redhat.com>
References: <56D45B93.20706@redhat.com>
Message-ID: <56D4884C.5090806@redhat.com>

On 2/29/2016 9:54 AM, Bill Burke wrote:
> How you guys do this?  I did a rebase -i and squashed everything but the
> PR contained diffs of merged files and not just my changes.
>
I've always followed the WildFly team procedures from here:
https://developer.jboss.org/wiki/HackingOnWildFly


From mposolda at redhat.com  Mon Feb 29 15:24:42 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 29 Feb 2016 21:24:42 +0100
Subject: [keycloak-dev] rebasing
In-Reply-To: <BD5F4D24-FAA3-4631-B2D7-7A150A0525CB@smartling.com>
References: <56D45B93.20706@redhat.com>
	<CAJgngAemh3Cz606OiEzp9r25trezGe-352oQZK6mXmPSn8KUzw@mail.gmail.com>
	<56D47062.1000905@redhat.com> <56D4743C.3000109@redhat.com>
	<56D47BF3.1040900@kroehling.de>
	<BD5F4D24-FAA3-4631-B2D7-7A150A0525CB@smartling.com>
Message-ID: <56D4A90A.6040608@redhat.com>

Yeah, you need to be careful when using this. Similarly like you need to 
be careful when using command "rm -rf" on linux. Both are dangerous 
stuff, on the other hand both can save you time if you are careful and 
you know what you're doing ;-)

Marek

On 29/02/16 18:14, Scott Rossillo wrote:
> +1 do PRs from a branch and never force push master (even your own).
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>> On Feb 29, 2016, at 12:12 PM, Juraci Paix?o Kr?hling 
>> <juraci at kroehling.de <mailto:juraci at kroehling.de>> wrote:
>>
>> On 29.02.2016 17:39, Marek Posolda wrote:
>>> git push origin master --force
>>
>> Just be extra careful on this command, as it is potentially destructive
>> when applied to the "main" repository. As a general rule, I use
>> "--force" only on my branches, and never on master (even less on the
>> "real" origin/upstream).
>>
>> By the way: this is a good time to check if the main repository is
>> protected against force-pushes: http://snag.gy/2KjLY.jpg
>>
>> - Juca.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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