From postmaster at lists.jboss.org  Sat Oct  1 03:00:23 2016
From: postmaster at lists.jboss.org (Mail Delivery Subsystem)
Date: Sat, 1 Oct 2016 12:30:23 +0530
Subject: [keycloak-dev] Returned mail: see transcript for details
Message-ID: <201610010659.u916xg7A012537@lists01.dmz-a.mwc.hst.phx2.redhat.com>

??UG???????Pj
(???tq??????*?j???$lY?\????^~??????xPi40?
??Xm???????
;?~m?? ?????r?\??????? a???0?U???TV?l??3?CL?&/??
hA?C?'{????????U????:??;%XPO??K??[zY????E?U????W???Z~B1\'?Z?f4Y8??m??"? ??j???FK?U???{?,dY??H?V`????2v??e??!*?x?/i?2?"??#???CNL>s???C??!?w?bk??6????S?????PV?!???|???1????U??,??;?
??l"J?Z????at?????Z??
?}?&>r?JHd??,{????q??'T39?????R??Bj????o???kGsg4?????Rd?q.Q
??3d?V??hB0?
q??&?cO38?i)_??????a??J?MI:??lx)????N>?????????\?????????????O'_X??????sJj<S?H??t
?P???????p~??-?S.X???y????o?x??H]?VD?u" j????v?H?t??dN?N??C?E"M??1?T9{KW???JM?BbU???FvN??K?t.????*?$ylfG)?H?I8dl?r?(??Y?q*?K??
??????/J?c??A8???h????D?6????Wg
dp???B?0?lS?a?Up?2??]???2?_g??tis???\?J?<qk?g???x]?:??????????5?????7???iC??{?????O??20?????*bl??g7??G
rE
?????M?V???????;??_????%V'a???.??(u???l???.?w??????n?[???d????j?\c?7????q??????o
??~0?3???%3?D???7.O?\<d&'x9?j?N??Z?Dg??b?I???
??BsA?????)????P5g??x*
??????c?[?????B:/^?}??h$n????(??-??b???w?K,l???????N???N?|c???r?B?ne~???A??-???????\??????vu??*,??h??Y?:?
`UYRR??f??fP???oc?I&??
,P?{ld???i?????(?hf9kS8RLb?3??h2
J??]u?NW?Y1g???H??x????;?.?*U??iSy?)m{???O?
?LI????q?`?c?/8d9????o#?G8?^?~P
<?s?mY????y??T????p??#(?W'b9.?4M'J?????t^?cwN?]?j???5z?????tP?yQ:?#?(????
#???H????,b/h?,y???&26????>?>???od????wP9?C5???H?(?xb????????h?????~?KOz?Jyy?G?MY ??NW?????:??
????f????O
d??$?_????A?b??Jn/?'~*????g0
fo?.??wIu???S?^Q??M??<?8??????,v?????nP??Y?h???)?~?y?T??b?_?l???[?v??????????;?]??,??Y??l*Q??K??Wf#bqeb?????W?)|Y1???vjB??<?r}%???U?B???????g???6??N2J0r?Q??8??????????k????T?\}?1??E?^?N?mz??&?*mvY?#Qh???Hp
?\??d&<>iZP???Vo???3`H????-???????LN?0??[Yz"???????$]]??w?????p?F????4/??N??Q???Yg??/P5
??`{h?r?1??]o`AuWp$2S?l{?%cFZ:M.v?S}?????`??>{?Q?!???????????O??[??V?Wp??D'??#??yb??r~????UE


From sthorger at redhat.com  Mon Oct  3 02:54:52 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Oct 2016 08:54:52 +0200
Subject: [keycloak-dev] Browser Javascript Support
In-Reply-To: <57EE6CA5.8090407@redhat.com>
References: <57EE6CA5.8090407@redhat.com>
Message-ID: <CAJgngAcrEEvqOKv-6kjCx0sBME2-Deit5O5ADORqhjYRTJ0+4Q@mail.gmail.com>

For admin console we'll not support that wide list of browsers. It'll be
last two Firefox, last two Chrome, IE11, Edge and Safari. As we're based on
Bootstrap and Angular it should more or less work on others as well.

For login it should support anything that makes sense and there's no
requirement for javascript there.

On 30 September 2016 at 15:46, Stan Silvert <ssilvert at redhat.com> wrote:

> What is our statement about browser support?  For admin console, are we
> stating that we support any browser that supports ES5?
> http://kangax.github.io/compat-table/es5/
>
> Do we have separate standards for things like the login screen and
> Account Management?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct  3 07:29:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Oct 2016 13:29:00 +0200
Subject: [keycloak-dev] Configurable cookie names
In-Reply-To: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
References: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
Message-ID: <CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>

Not sure I see the need for this. What "product branding" are you referring
to? Not sure about #2 either. Are you talking from a security perspective?

On 30 September 2016 at 14:07, Martin Hardselius <
martin.hardselius at gmail.com> wrote:

> What are your thoughts on configurable cookie names (or other visible
> references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with
> "MYCOMPANY_SESSION". The use case being
>
> 1. Product branding
> 2. Making it harder to figure out exactly which technology that's used
> behind the scenes
>
> Regards,
> Martin
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct  3 07:30:38 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 3 Oct 2016 13:30:38 +0200
Subject: [keycloak-dev] Allow adapter subsystem to just inject
	dependencies
In-Reply-To: <6eb9e340-6a7c-4d2b-12e8-f9ffe59838d2@redhat.com>
References: <8b0a0f73-823e-1d17-5e39-b4316eab30ef@redhat.com>
	<CAJgngAfoi3EfQVchn+341dbOcSrqb24B6xF9vA1j2DMvdzUMUg@mail.gmail.com>
	<e5fa0486-19f2-fe1d-6114-bd4a3c9556ce@redhat.com>
	<CAJgngAdQ0+N8dU77cbKMkSXtGPSUi09C6RiRQ6=_Yz6HqpeC7A@mail.gmail.com>
	<1f111b70-1092-03ed-6ec7-d2856663f690@redhat.com>
	<CAJgngAeGdZEv-Ob2Sy=jfPHhsrbXxD9+EW40z2qS9A=xAKJhiA@mail.gmail.com>
	<81cc6490-0faf-8a66-fbe9-10406bbe057d@redhat.com>
	<CAJgngAfeQXXyieR5sHhHwJQKOeWimHBus2Chuce3oarzLRM0zA@mail.gmail.com>
	<6eb9e340-6a7c-4d2b-12e8-f9ffe59838d2@redhat.com>
Message-ID: <CAJgngAemGmb64Co_GTRCgCKdMkWNxG3pQsKdphmzs_bPW4v+3Q@mail.gmail.com>

Ok, makes sense to have the "empty" security context tag then. Seems like a
simple and non-intrusive change.

On 30 September 2016 at 16:24, Marek Posolda <mposolda at redhat.com> wrote:

> On 30/09/16 12:58, Stian Thorgersen wrote:
>
> What's the use-case for hawtio on EAP if not for Fuse?
>
> By Hawtio on Fuse, I meant Hawtio deployed on JBoss Fuse ( karaf + jetty).
> Where Hawtio on EAP is just hawtio war deployed on EAP.
>
> AFAIK both usecases (Hawtio on JBoss Fuse and Hawtio on EAP) is what we
> want to support for "Fuse adapter" ?
>
> With Hawtio on EAP you need to change some settings in the war to add our
> login module right? So not sure why it would be an issue to add
> jboss-deployment-structure.xml at the same time?
>
> Nope, I don't change anything inside the WAR. And I want to keep it like
> that. I suppose that require people to change stuff directly inside the
> hawtio.war is not something we want to do? Otherwise I would just add
> jboss-deployment-structure.xml and I wouldn't start this thread :-)
>
> The JAAS configuration is in standalone.xml and hawtio is able to read it.
> It's just not able to find the keycloak classes. So really the only thing I
> need is a way for hawtio to find the classes. So a way for our subsystem to
> just add dependencies, but not add the deployment configuration (as I don't
> need it).
>
>
> Marek
>
> On 30 September 2016 at 10:35, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 30/09/16 08:55, Stian Thorgersen wrote:
>>
>> Wouldn't it actually be better to have the auth-server-url in
>> standalone.xml than in the JAAS login module configuration?
>>
>> Hawtio relies on JAAS and I can't see any nice way how to pass the stuff
>> from our subsystem to the JAAS login module. Also I suppose we don't want
>> to introduce any keycloak dependencies in hawtio as that would mean other
>> complications...
>>
>> Our adapter subsystem puts the stuff into the JSON string, which is saved
>> as servletContext attribute. So what can work is, that hawtio can read it
>> from the servletContext and save it to some threadLocal. Then on hawtio
>> side, there will be login module, which will read the JSON from threadLocal
>> and put it to JAAS sharedState. The Keycloak login module, which will be
>> next in the JAAS chain, can then try to see if there is stuff in
>> sharedState and if yes, then use it instead of the KeycloakDeployment
>> provided by it's JAAS config. Or another possibility that class holding
>> threadLocal will be in Keycloak codebase and hawtio will use reflection to
>> put the JSON into it (as we don't want keycloak dependencies in hawtio
>> directly).
>>
>> Both approaches looks to me complicated and introducing dependencies on
>> keycloak subsystem implementation details into hawtio codebase (reading the
>> servletContext attribute etc). Also it will be useful just with hawtio on
>> EAP, but not for Hawtio on Fuse. And Fuse seems to be much more important.
>>
>> Marek
>>
>>
>> On 30 September 2016 at 08:34, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 29/09/16 10:09, Stian Thorgersen wrote:
>>>
>>> Oki, so sounds like what you proposed is the way to go. I'm not to keen
>>> on option 2 or 3 as they seem a bit artificial. Why do they not need
>>> auth-server-url though?
>>>
>>> Ok, I've created https://issues.jboss.org/browse/KEYCLOAK-3634 . The
>>> auth-server-url is needed, but this is provided by the JAAS login module
>>> configuration. Hawtio itself just relies on the JAAS. It doesn't have
>>> servlet security or any security-constraints in web.xml, so doesn't rely on
>>> classic servlet adapter.
>>>
>>> Marek
>>>
>>>
>>> On 29 September 2016 at 08:18, Marek Posolda <mposolda at redhat.com>
>>> wrote:
>>>
>>>> On 28/09/16 10:58, Stian Thorgersen wrote:
>>>>
>>>> Not sure even using "<secure-deployment...>" makes sense at all in
>>>> this case.  If there's keycloak.json the subsystem still injects the
>>>> dependencies, but doesn't do any configuration. Why can't it just rely on
>>>> that?
>>>>
>>>> Without "secure-deployment", you also need the KEYCLOAK in login-config
>>>> in web.xml  in addition to keycloak.json.
>>>>
>>>> Anyway, regarding usability, I suspect it's not an option to require
>>>> people to crack inside hawtio.war and change the things in the WAR
>>>> directly? Otherwise they can just add jboss-deployment-structure.xml into
>>>> the hawtio.war and I don't need to care about subsystem at all.
>>>>
>>>> Marek
>>>>
>>>>
>>>>
>>>>
>>>> On 26 September 2016 at 16:39, Marek Posolda <mposolda at redhat.com>
>>>> wrote:
>>>>
>>>>> I've did some testing with hawtio on EAP 7. It works fine, however
>>>>> there
>>>>> is one thing in our subsystem, which may improve integration a bit.
>>>>>
>>>>> Hawtio doesn't use servlet security ( security-constraints in web.xml )
>>>>> but they rely on JAAS, which is needed for JMX calls to be performed on
>>>>> behalf of JAAS Subject. Hawtio WAR needs to have access to
>>>>> keycloak-adapter classes (as it needs login modules for JAAS), however
>>>>> it doesn't need subsystem to configure adapter. This is all handled by
>>>>> JAAS login module.
>>>>>
>>>>> In other words, it will be nice if subsystem can just inject
>>>>> dependencies ( KeycloakDependencyProcessor ), but ignore adding
>>>>> subsystem configuration ( KeycloakAdapterConfigDeploymentProcessor ).
>>>>>
>>>>> The workaround I used was to add secure-deployment section to
>>>>> standalone.xml with some dummy values, which are mandatory for
>>>>> subsystem. It works, but it's really not too pretty IMO. Something
>>>>> like:
>>>>>
>>>>>              <secure-deployment name="hawtio.war">
>>>>>                  <resource>does-not-matter</resource>
>>>>> <auth-server-url>does-not-matter</auth-server-url>
>>>>>              </secure-deployment>
>>>>>
>>>>> What will be nice is to have some of those possibilities:
>>>>>
>>>>> 1) Have subsystem to use some default values like "undefined" instead
>>>>> of
>>>>> null . This is more a workaround as subsystem will still process the
>>>>> KeycloakAdapterConfigDeploymentProcessor. However it's less work and
>>>>> it
>>>>> will improve usability, so this will work just fine:
>>>>>
>>>>> <secure-deployment name="hawtio.war" />
>>>>>
>>>>>
>>>>> 2) Tell the subsystem to ignore
>>>>> KeycloakAdapterConfigDeploymentProcessor. Looks like more work, but
>>>>> seems to be more proper solution than (1). I can think of:
>>>>>
>>>>> 2.a) some flag like:
>>>>>
>>>>> <secure-deployment name="hawtio.war" ignore-deployment-config="true"
>>>>> />
>>>>>
>>>>> 2.b) Use different element like "deployment" instead of
>>>>> "secure-deployment" . The "deployment" will inject dependencies, but
>>>>> won't handle adapter configuration. So something like this will work:
>>>>>
>>>>> <deployment name="hawtio.war" />
>>>>>
>>>>>
>>>>> WDYT?
>>>>> Marek
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

From martin.hardselius at gmail.com  Mon Oct  3 09:05:22 2016
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Mon, 03 Oct 2016 13:05:22 +0000
Subject: [keycloak-dev] Configurable cookie names
In-Reply-To: <CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>
References: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
	<CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>
Message-ID: <CAPJq0L9rCvQJZPZB0E-BB96omLOGfmCQai7xj7NZeHpyOBaXvg@mail.gmail.com>

It's certainly not needed, more of a nice-to-have that came up during
discussions about our deployment. As for #2, it might be more of a
security-by-obscurity thing. Wanting to make it a bit harder to figure out
what kind of stack you are running seems like a legitimate wish.

On Mon, 3 Oct 2016 at 13:29 Stian Thorgersen <sthorger at redhat.com> wrote:

> Not sure I see the need for this. What "product branding" are you
> referring to? Not sure about #2 either. Are you talking from a security
> perspective?
>
> On 30 September 2016 at 14:07, Martin Hardselius <
> martin.hardselius at gmail.com> wrote:
>
> What are your thoughts on configurable cookie names (or other visible
> references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with
> "MYCOMPANY_SESSION". The use case being
>
> 1. Product branding
> 2. Making it harder to figure out exactly which technology that's used
> behind the scenes
>
> Regards,
> Martin
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From bburke at redhat.com  Mon Oct  3 11:51:27 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 3 Oct 2016 11:51:27 -0400
Subject: [keycloak-dev] Configurable cookie names
In-Reply-To: <CAPJq0L9rCvQJZPZB0E-BB96omLOGfmCQai7xj7NZeHpyOBaXvg@mail.gmail.com>
References: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
	<CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>
	<CAPJq0L9rCvQJZPZB0E-BB96omLOGfmCQai7xj7NZeHpyOBaXvg@mail.gmail.com>
Message-ID: <ed447aa0-9dc1-a733-7b15-f2461fe82c86@redhat.com>

I really don't see the benefit to this.  Somebody could easily figure 
out that its Keycloak just by the URL scheme.


On 10/3/16 9:05 AM, Martin Hardselius wrote:
> It's certainly not needed, more of a nice-to-have that came up during
> discussions about our deployment. As for #2, it might be more of a
> security-by-obscurity thing. Wanting to make it a bit harder to figure out
> what kind of stack you are running seems like a legitimate wish.
>
> On Mon, 3 Oct 2016 at 13:29 Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Not sure I see the need for this. What "product branding" are you
>> referring to? Not sure about #2 either. Are you talking from a security
>> perspective?
>>
>> On 30 September 2016 at 14:07, Martin Hardselius <
>> martin.hardselius at gmail.com> wrote:
>>
>> What are your thoughts on configurable cookie names (or other visible
>> references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION" with
>> "MYCOMPANY_SESSION". The use case being
>>
>> 1. Product branding
>> 2. Making it harder to figure out exactly which technology that's used
>> behind the scenes
>>
>> Regards,
>> Martin
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Mon Oct  3 13:03:38 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 3 Oct 2016 14:03:38 -0300
Subject: [keycloak-dev] Custom Authenticator
In-Reply-To: <CACYMz7LPwY+BK9eO3qPdFmLm5gn3Dk+w+1DE9JrZ4bJ_Tvpe0Q@mail.gmail.com>
References: <CACYMz7LPwY+BK9eO3qPdFmLm5gn3Dk+w+1DE9JrZ4bJ_Tvpe0Q@mail.gmail.com>
Message-ID: <20161003170338.GA4808@abstractj.org>

Take a look at the docs here: https://keycloak.gitbooks.io/server-developer-guide/content/v/2.2/topics/auth-spi.html.

Although, I would not recommend hashing to store passwords. Hashes were
made to be fast and can be broken. That's why Keycloak has PBKDF2, or if
you don't like it, try to implement your own with BCrypt or Scrypt, but
never MD5[1].

[1] - https://cwe.mitre.org/data/definitions/327.html

On 2016-09-29, Yunus ?NCEL wrote:
> Hello;
>
> i have described for MD5 passwort. now i write to database password of
> users with MD5ed password.
>
> it is possible,  Can ? wr?te or change custom Authenticator with hilfe SPI?
>
> Because i need another conditon  to the correct user to the login.
>
> thank you and sorry for my English

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


--

abstractj
PGP: 0x84DC9914

From mposolda at redhat.com  Mon Oct  3 16:24:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 3 Oct 2016 22:24:18 +0200
Subject: [keycloak-dev] Added rotation of public keys of external clients
 and identity providers
Message-ID: <dfa2c0ce-f99c-46ee-2ffa-ff2d3f457da2@redhat.com>

OIDC dynamic profile needs to support ability to rotate public keys of 
external clients.

In order to this, I've added PublicKeyStorageProvider, which is used to 
store external public keys of the OIDC clients (those clients, which 
require authentication by signed JWT) and OIDC identity providers (those 
which require signature verification). There is just one implementation 
of the SPI based on local infinispan cache to cache computed public keys.

The advantages are:
- Improved performance : Previously during client authentication with 
signed JWT (or during verification of token signed by OIDC 
identityProvider), the public keys were always computed from PEM. This 
didn't  have very great performance. Now we have local infinispan cache, 
so the public keys are cached locally. The cache is set with eviction 
and expiration, so the locally cached keys are expired from cache in 
case of inactive / deleted clients.

- Ability to dynamically download the keys if token signed by unknown 
"kid" (Key ID) is found : Previously we supported that public key (or 
certificate) PEM of particular client was always hardcoded in Keycloak 
database. This is still supported, so everything is backwards 
compatible. However we additionally support that client or identity 
provider can have "jwks_url" defined. In that case, public keys are 
always downloaded dynamically from the given jwks_url when token signed 
by unknown "kid" is found. In other words, always when external client 
(or idp) rotate it's keys, Keycloak will dynamically download them and 
update the storage.

There is configurable limit (10 seconds by default), so that client 
won't try to download keys from "jwks_url" more than once in 10 seconds. 
This is to avoid DOS, so when evil sends many requests with unknown 
"kid", the keycloak won't try to download keys from "jwks_url" for every 
request.

Marek


From sthorger at redhat.com  Mon Oct  3 23:25:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 4 Oct 2016 05:25:39 +0200
Subject: [keycloak-dev] Configurable cookie names
In-Reply-To: <ed447aa0-9dc1-a733-7b15-f2461fe82c86@redhat.com>
References: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
	<CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>
	<CAPJq0L9rCvQJZPZB0E-BB96omLOGfmCQai7xj7NZeHpyOBaXvg@mail.gmail.com>
	<ed447aa0-9dc1-a733-7b15-f2461fe82c86@redhat.com>
Message-ID: <CAJgngAcZTAbCxzY7S_BXE2Mnji+bp=cDHMqONTRT0ssufEUfDw@mail.gmail.com>

Me neither. KC URL scheme is so distinct that there's no problem figuring
out that it's Keycloak under the hood. This is just adding another thing to
test and document, which isn't required and probably only very few would
use.

On 3 October 2016 at 17:51, Bill Burke <bburke at redhat.com> wrote:

> I really don't see the benefit to this.  Somebody could easily figure
> out that its Keycloak just by the URL scheme.
>
>
> On 10/3/16 9:05 AM, Martin Hardselius wrote:
> > It's certainly not needed, more of a nice-to-have that came up during
> > discussions about our deployment. As for #2, it might be more of a
> > security-by-obscurity thing. Wanting to make it a bit harder to figure
> out
> > what kind of stack you are running seems like a legitimate wish.
> >
> > On Mon, 3 Oct 2016 at 13:29 Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >> Not sure I see the need for this. What "product branding" are you
> >> referring to? Not sure about #2 either. Are you talking from a security
> >> perspective?
> >>
> >> On 30 September 2016 at 14:07, Martin Hardselius <
> >> martin.hardselius at gmail.com> wrote:
> >>
> >> What are your thoughts on configurable cookie names (or other visible
> >> references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION"
> with
> >> "MYCOMPANY_SESSION". The use case being
> >>
> >> 1. Product branding
> >> 2. Making it harder to figure out exactly which technology that's used
> >> behind the scenes
> >>
> >> Regards,
> >> Martin
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From martin.hardselius at gmail.com  Tue Oct  4 05:58:57 2016
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Tue, 04 Oct 2016 09:58:57 +0000
Subject: [keycloak-dev] Configurable cookie names
In-Reply-To: <CAJgngAcZTAbCxzY7S_BXE2Mnji+bp=cDHMqONTRT0ssufEUfDw@mail.gmail.com>
References: <CAPJq0L-3iDGDtceoRHnb_62Jog3-FadpQAiwN8D1LTNkkH=_dg@mail.gmail.com>
	<CAJgngAedqAY73WrrR5uCE3mHM65vDpv_1YVCd3fARisoEy5w1w@mail.gmail.com>
	<CAPJq0L9rCvQJZPZB0E-BB96omLOGfmCQai7xj7NZeHpyOBaXvg@mail.gmail.com>
	<ed447aa0-9dc1-a733-7b15-f2461fe82c86@redhat.com>
	<CAJgngAcZTAbCxzY7S_BXE2Mnji+bp=cDHMqONTRT0ssufEUfDw@mail.gmail.com>
Message-ID: <CAPJq0L_7BG5jW3RaJUHLzhyT2nK3+QzjN+JGHZFgjdKT41TU7Q@mail.gmail.com>

That's some valid points. If, for some reason, the renaming and disguising
becomes an absolute requirement I guess we can accomplish it with some
reverse proxy magic instead. :) Thank you for your answers!

Martin

On Tue, 4 Oct 2016 at 05:26 Stian Thorgersen <sthorger at redhat.com> wrote:

Me neither. KC URL scheme is so distinct that there's no problem figuring
out that it's Keycloak under the hood. This is just adding another thing to
test and document, which isn't required and probably only very few would
use.

On 3 October 2016 at 17:51, Bill Burke <bburke at redhat.com> wrote:

> I really don't see the benefit to this.  Somebody could easily figure
> out that its Keycloak just by the URL scheme.
>
>
> On 10/3/16 9:05 AM, Martin Hardselius wrote:
> > It's certainly not needed, more of a nice-to-have that came up during
> > discussions about our deployment. As for #2, it might be more of a
> > security-by-obscurity thing. Wanting to make it a bit harder to figure
> out
> > what kind of stack you are running seems like a legitimate wish.
> >
> > On Mon, 3 Oct 2016 at 13:29 Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> >> Not sure I see the need for this. What "product branding" are you
> >> referring to? Not sure about #2 either. Are you talking from a security
> >> perspective?
> >>
> >> On 30 September 2016 at 14:07, Martin Hardselius <
> >> martin.hardselius at gmail.com> wrote:
> >>
> >> What are your thoughts on configurable cookie names (or other visible
> >> references to Keycloak)? I.e a way to override e.g "KEYCLOAK_SESSION"
> with
> >> "MYCOMPANY_SESSION". The use case being
> >>
> >> 1. Product branding
> >> 2. Making it harder to figure out exactly which technology that's used
> >> behind the scenes
> >>
> >> Regards,
> >> Martin
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From ronyjoy at gmail.com  Tue Oct  4 09:56:47 2016
From: ronyjoy at gmail.com (rony joy)
Date: Tue, 04 Oct 2016 13:56:47 +0000
Subject: [keycloak-dev] Sending Username/emailid in the saml req as NameID
Message-ID: <CACCBH8MATP=HWKsBf7M3MdoqGZPB4LoJ5adfS27cZoDm8=pc2A@mail.gmail.com>

Hi All,

We have a requirement to send Username/EmailId in the Subject/NameID field
to the keycloak. Keycloak then receive that value in a custom authenticator
and send it to the tokenvalidator for further flow. The idea here is to
omit the step to ask user name from user again.

1. In Keycloak I am not able to see NameID value since keycloak is not
putting this in the client session. why?
2. I can see that keycloak is parsing the Subject/Name ID field.  How can I
get this value in my custom Autheticator ?
3. Please see our SAML request

Please let me know your suggestions and ideas
Rony Joy

<?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="
http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
Version="2.0"><saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
http://localhost:8080/employee-sig-idfirst/</saml2:Issuer><ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference
URI="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><ds:Transforms><ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
"/><ds:DigestValue>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeVwc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdXo3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3XpvqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhkiG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMxM1oXDTI2MDgwMjE3
MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxveWVlLXNpZy1pZGZp
cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZxnZdlT8UwWZmT4537
zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+ng15sO5QfE
EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/9Rx53kIJpEOt9Y1RHql+vW2
hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9MtAVE8hlgSAZSzwN6S
FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw9fcJfjXVlY0
lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+0KuoEht+VgiFlceWFNUN5ur
tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgCMYhpPPfN39yV24yWpv4VTrOG1q3pj
yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2rx2kOgHIuxZ4e2kVla
x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+K2oP5dPMemdsZMWqzzvrSNQrebPgsB
KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>*<saml2:Subject
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></saml2p:AuthnRequest>

From hcamp at muerte.net  Tue Oct  4 14:00:41 2016
From: hcamp at muerte.net (Harold Campbell)
Date: Tue, 04 Oct 2016 13:00:41 -0500
Subject: [keycloak-dev] new provider deployer working on branch!
In-Reply-To: <d712c2c6-1540-834d-88c5-778e18487a67@redhat.com>
References: <d712c2c6-1540-834d-88c5-778e18487a67@redhat.com>
Message-ID: <1475604041.2566.9.camel@muerte.net>

On Sat, 2016-08-06 at 11:43 -0400, Bill Burke wrote:
> I've implemented a Keycloak provider deployer and it works great.??I?
> re-implemented the JPA User Storage SPI example.??The provider is now
> a?
> @Stateful EJB and EntityManager access is all managed by?
> @PersistenceContext.??The example now looks really simple and
> elegant?
> rather than the crap I mentioned before.??Would not have worked
> without?
> the JTA integration I did (see previous email).??Things left to do:
>?

Do I need to do something special to get the CDI container bootstrapped
in a deployment? I'm deploying a jar which contains CDI annotated
classes and a beans.xml (though the beans.xml should not be necessary)
and yet I get:

Caused by: java.lang.ClassNotFoundException: javax.enterprise.inject.spi.CDI from [Module "deployment.envestnet-auth-full.jar:main" from Se
rvice Module Loader]
????????at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
????????at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
????????at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
????????at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)

If I add a dependency on javaee.api to my MANIFEST.MF the class not
found goes away, but instead I get:

Caused by: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => []
????????at org.jboss.weld.bootstrap.api.helpers.RegistrySingletonProvider$RegistrySingleton.get(RegistrySingletonProvider.java:28)
????????at org.jboss.weld.Container.instance(Container.java:55)
????????at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:61)
????????at javax.enterprise.inject.spi.CDI.current(CDI.java:60)
...


Both can be triggered at the users page by clicking 'View all users'.
This is a UserFederationProvider I'm trying to convert to a deployment
so I can use JPA & CDI. I'm reusing code from another project which is
CDI based, so rewriting logic to be EJB based as in your user-storage-
jpa example would not be ideal.

-- 
Harold Campbell <hcamp at muerte.net>

"Stupidity, like virtue, is its own reward"
-- William E. Davidsen

From ronyjoy at gmail.com  Wed Oct  5 08:45:22 2016
From: ronyjoy at gmail.com (rony joy)
Date: Wed, 05 Oct 2016 12:45:22 +0000
Subject: [keycloak-dev] Keycloak: NameID/BaseID/EncryptedID from SAML
 REQUEST is not adding to client session
In-Reply-To: <CACCBH8O7+33S50XFMNQdLrAY4H_s9q5pA4MxP1TxAVM5DCvwEA@mail.gmail.com>
References: <CACCBH8O7+33S50XFMNQdLrAY4H_s9q5pA4MxP1TxAVM5DCvwEA@mail.gmail.com>
Message-ID: <CACCBH8PKh7rgtOyaZ6p7MtrRh_+Wxf-s9d2erys8TpMCnSFCfg@mail.gmail.com>

We have a requirement to receive Username/EmailId in the Subject/NameID
field of SAML Request. Keycloak then receive that value in a custom
authenticator

and send it to the tokenvalidator for further flow. The idea here is
to omit the step to ask user name from user again if that is present
in the SAMLRequest.

1. In Keycloak I don't see NameID/BaseID/EncryptedId value from the
SAML request is putting in the client session. why?
2. I can see that keycloak is parsing the Subject/Name ID field, but
not adding to the client session? Is the any reason for this?

3. I am willing to fork the repo and do the changes.
4. Please see our SAML request

Please let me know your suggestions and ideas
Rony Joy

<?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
Destination="http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
Version="2.0"><saml2:Issuer
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:8080/employee-sig-idfirst/</saml2:Issuer><ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference
URI="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><ds:Transforms><ds:Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
"/><ds:DigestValue>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeVwc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdXo3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3XpvqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhkiG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMxM1oXDTI2MDgwMjE3
MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxveWVlLXNpZy1pZGZp
cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZxnZdlT8UwWZmT4537
zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+ng15sO5QfE
EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/9Rx53kIJpEOt9Y1RHql+vW2
hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9MtAVE8hlgSAZSzwN6S
FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw9fcJfjXVlY0
lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+0KuoEht+VgiFlceWFNUN5ur
tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgCMYhpPPfN39yV24yWpv4VTrOG1q3pj
yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2rx2kOgHIuxZ4e2kVla
x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+K2oP5dPMemdsZMWqzzvrSNQrebPgsB
KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>*<saml2:Subject
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></saml2p:AuthnRequest>

From e.berdoncesbonelo at campus.tu-berlin.de  Wed Oct  5 10:00:17 2016
From: e.berdoncesbonelo at campus.tu-berlin.de (Erik Berdonces Bonelo)
Date: Wed, 5 Oct 2016 16:00:17 +0200
Subject: [keycloak-dev] Using Client's Attributes in Custom Policy
Message-ID: <etPan.57f50771.5f7a0c02.21b4@campus.tu-berlin.de>

Hello,

I?m trying to implement a custom policy but I?m having a hard time with the Evaluation API.?

As I see, there is just some few available settings to get, but, I?m trying to fetch specifically a custom attribute of the client, let?s say FOO, which can be set through adding them in the representation when registering a new Client, which we will call BAR, ?through the Registration API. Is it even possible?

Otherwise, I?m not sure in which case would the client attributes be used.
In the settings of the client BAR, in policies, in the test tab, there is in the ?Contextual Attributes' part, a ?Custom Attribute? option. Is there any possible to set them, or to use them??

I?ve been trying to link them somehow to FOO attribute using a custom scripted policy in Javascript for the client BAR such as:


contextAttributes.containsValue(?kc.client.attributes.FOO', ?myFooAttributeValue')
But I?m not successful, plus it?s really difficult to debug so :(

Any advice on how to implement something like this? I?m just trying to create a policy, where one of the parameters is loaded from the client, and I want to save that property somewhere accessible such as a custom attribute, and not so hardcoded such as a javascript or Drool script.

Thanks a lot!

??
Best regards,?

Erik Berdonces Bonelo

From bburke at redhat.com  Wed Oct  5 10:38:13 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 5 Oct 2016 10:38:13 -0400
Subject: [keycloak-dev] new synchronization SPI
Message-ID: <36eb8bbb-51b6-c75a-2564-728332d4b9a3@redhat.com>

Marek in particular...

Why do we have 2 sync methods currently?

syncAllUsers syncChangedUsers

Could we just have one method?

sync(KeycloakSessionFactory sessionFactory, String realmId, ComponentModel model, DatelastSync);


From mposolda at redhat.com  Thu Oct  6 04:11:48 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 6 Oct 2016 10:11:48 +0200
Subject: [keycloak-dev] new synchronization SPI
In-Reply-To: <36eb8bbb-51b6-c75a-2564-728332d4b9a3@redhat.com>
References: <36eb8bbb-51b6-c75a-2564-728332d4b9a3@redhat.com>
Message-ID: <d3966705-9079-f1dc-b3e6-a7fc25c92e5f@redhat.com>

The "syncChangedUsers" was meant to query the external storage just for 
the users updated since lastSync. The "syncAllUsers" was meant to always 
query whole external storage and import/update all users from it into 
Keycloak.

I agree that probably most of deployments can live just with the 
"syncChangedUsers" . The "syncAllUsers" is probably useful just for the 
case if you really want to enforce syncing all users for some rare 
reason (eg. changelog in external storage was somehow broken and doesn't 
provide accurate info). I don't know if it's something to consider... 
Maybe simplify SPI and go with single method is sufficient.

Marek

On 05/10/16 16:38, Bill Burke wrote:
> Marek in particular...
>
> Why do we have 2 sync methods currently?
>
> syncAllUsers syncChangedUsers
>
> Could we just have one method?
>
> sync(KeycloakSessionFactory sessionFactory, String realmId, ComponentModel model, DatelastSync);
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Thu Oct  6 04:58:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 6 Oct 2016 10:58:19 +0200
Subject: [keycloak-dev] new synchronization SPI
In-Reply-To: <d3966705-9079-f1dc-b3e6-a7fc25c92e5f@redhat.com>
References: <36eb8bbb-51b6-c75a-2564-728332d4b9a3@redhat.com>
	<d3966705-9079-f1dc-b3e6-a7fc25c92e5f@redhat.com>
Message-ID: <CAJgngAfXyptyXn89frURb5FRuOAV7dcnsJSkO3W6cSdon1X1ug@mail.gmail.com>

Wouldn't it be cleaner to have a single method that passes in some context
object that contains details around last sync? Something like:

   syncUsers(long lastSync)

Alternatively it can be up to the provider itself to store details around
lastSync and just have a syncUsers method.

On 6 October 2016 at 10:11, Marek Posolda <mposolda at redhat.com> wrote:

> The "syncChangedUsers" was meant to query the external storage just for
> the users updated since lastSync. The "syncAllUsers" was meant to always
> query whole external storage and import/update all users from it into
> Keycloak.
>
> I agree that probably most of deployments can live just with the
> "syncChangedUsers" . The "syncAllUsers" is probably useful just for the
> case if you really want to enforce syncing all users for some rare
> reason (eg. changelog in external storage was somehow broken and doesn't
> provide accurate info). I don't know if it's something to consider...
> Maybe simplify SPI and go with single method is sufficient.
>
> Marek
>
> On 05/10/16 16:38, Bill Burke wrote:
> > Marek in particular...
> >
> > Why do we have 2 sync methods currently?
> >
> > syncAllUsers syncChangedUsers
> >
> > Could we just have one method?
> >
> > sync(KeycloakSessionFactory sessionFactory, String realmId,
> ComponentModel model, DatelastSync);
> >
> > _______________________________________________
> > 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 sblanc at redhat.com  Thu Oct  6 12:46:04 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 6 Oct 2016 18:46:04 +0200
Subject: [keycloak-dev] Tomcat 8 Adapter breaks with Tomcat 8.5.5
Message-ID: <CAMZCGg_DfOwXWEeNR5vhJhFtwh=+yX9BhgU1w0bWeDtc43AvdA@mail.gmail.com>

Tomcat 8.5.5 that was released last month doesn't work with the KC Tomcat
Adapter.

This is because of this bug that has been fixed on their side :
https://bz.apache.org/bugzilla/show_bug.cgi?id=59823 and their pretty
"breaking-change" fix :
https://github.com/apache/tomcat85/commit/c74595783a821cf43de45def094254c673298e73?diff=split

I created a ticket , https://issues.jboss.org/browse/KEYCLOAK-3669 , that
describes the problem and the possible fix.

But the question is : this fix will only be valid (and possible to compile)
for version of Tomcat > 8.5.5 (including 9). Does that mean we need to
create a new Adapter just for this version ?

 I'm not sure there is another solution.

Sebi

ps : This also affects people using the latest version of Springboot, as it
uses tomcat 8.5.5

From ronyjoy at gmail.com  Thu Oct  6 14:08:51 2016
From: ronyjoy at gmail.com (rony joy)
Date: Thu, 06 Oct 2016 18:08:51 +0000
Subject: [keycloak-dev] Keycloak: NameID/BaseID/EncryptedID from SAML
 REQUEST is not adding to client session
In-Reply-To: <CACCBH8PKh7rgtOyaZ6p7MtrRh_+Wxf-s9d2erys8TpMCnSFCfg@mail.gmail.com>
References: <CACCBH8O7+33S50XFMNQdLrAY4H_s9q5pA4MxP1TxAVM5DCvwEA@mail.gmail.com>
	<CACCBH8PKh7rgtOyaZ6p7MtrRh_+Wxf-s9d2erys8TpMCnSFCfg@mail.gmail.com>
Message-ID: <CACCBH8OnRqY9xoHKNHnL_qpoe5vfNCbjsv0QQ1+ST-mV_yHiSg@mail.gmail.com>

We are proposing the following changes to
"org.keycloak.protocol.saml.SamlService" Method : "loginRequest" Method.
 + Read the Subject / NameID value from the saml Request if it is not NULL.
 + Add it to the Client Session note under SamlProtocol.SAML_NAME_ID.

The code will look something like this
 //Reading subject in the saml request
    SubjectType subject = requestAbstractType.getSubject();
    if(subject !=null) {
      SubjectType.STSubType subType = subject.getSubType();
      if(subType !=null) {
        BaseIDAbstractType baseID = subject.getSubType().getBaseID();
        if(baseID!=null && baseID instanceof NameIDType) {
            NameIDType nameID = (NameIDType) baseID;
            clientSession.setNote(SamlProtocol.SAML_NAME_ID,
nameID.getValue());
          }
      }
     }





On Wed, Oct 5, 2016 at 7:45 AM rony joy <ronyjoy at gmail.com> wrote:

> We have a requirement to receive Username/EmailId in the Subject/NameID
> field of SAML Request. Keycloak then receive that value in a custom
> authenticator
>
> and send it to the tokenvalidator for further flow. The idea here is to omit the step to ask user name from user again if that is present in the SAMLRequest.
>
> 1. In Keycloak I don't see NameID/BaseID/EncryptedId value from the SAML request is putting in the client session. why?
> 2. I can see that keycloak is parsing the Subject/Name ID field, but not adding to the client session? Is the any reason for this?
>
> 3. I am willing to fork the repo and do the changes.
> 4. Please see our SAML request
>
> Please let me know your suggestions and ideas
> Rony Joy
>
> <?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
> xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
> ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
> IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
> Version="2.0"><saml2:Issuer
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://localhost:8080/employee-sig-idfirst/</saml2:Issuer><ds:Signature
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference
> URI="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><ds:Transforms><ds:Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
> "/><ds:DigestValue>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeVwc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdXo3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3XpvqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhkiG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
> b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMxM1oXDTI2MDgwMjE3
> MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxveWVlLXNpZy1pZGZp
> cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZxnZdlT8UwWZmT4537
> zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+ng15sO5QfE
> EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/9Rx53kIJpEOt9Y1RHql+vW2
> hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
> 4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9MtAVE8hlgSAZSzwN6S
> FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw9fcJfjXVlY0
> lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+0KuoEht+VgiFlceWFNUN5ur
> tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgCMYhpPPfN39yV24yWpv4VTrOG1q3pj
> yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2rx2kOgHIuxZ4e2kVla
> x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+K2oP5dPMemdsZMWqzzvrSNQrebPgsB
> KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature>*<saml2:Subject
> xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
> AllowCreate="true"
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/></saml2p:AuthnRequest>
>
>

From shmuein+keycloak-dev at gmail.com  Thu Oct  6 23:28:31 2016
From: shmuein+keycloak-dev at gmail.com (Muein Muzamil)
Date: Thu, 6 Oct 2016 22:28:31 -0500
Subject: [keycloak-dev] Keycloak: NameID/BaseID/EncryptedID from SAML
 REQUEST is not adding to client session
In-Reply-To: <CACCBH8OnRqY9xoHKNHnL_qpoe5vfNCbjsv0QQ1+ST-mV_yHiSg@mail.gmail.com>
References: <CACCBH8O7+33S50XFMNQdLrAY4H_s9q5pA4MxP1TxAVM5DCvwEA@mail.gmail.com>
	<CACCBH8PKh7rgtOyaZ6p7MtrRh_+Wxf-s9d2erys8TpMCnSFCfg@mail.gmail.com>
	<CACCBH8OnRqY9xoHKNHnL_qpoe5vfNCbjsv0QQ1+ST-mV_yHiSg@mail.gmail.com>
Message-ID: <CACEM6k9_vwVEaXfE4LRDEip3hNoiM7+O5Cv1RTQNzmvkNaorhQ@mail.gmail.com>

we also have a similar requirement for one of our customer. your changes
make sense to me and I am hoping your they  get merged back so that we can
reuse them :)

Regards,
Muein

On Oct 6, 2016 1:11 PM, "rony joy" <ronyjoy at gmail.com> wrote:

> We are proposing the following changes to
> "org.keycloak.protocol.saml.SamlService" Method : "loginRequest" Method.
>  + Read the Subject / NameID value from the saml Request if it is not NULL.
>  + Add it to the Client Session note under SamlProtocol.SAML_NAME_ID.
>
> The code will look something like this
>  //Reading subject in the saml request
>     SubjectType subject = requestAbstractType.getSubject();
>     if(subject !=null) {
>       SubjectType.STSubType subType = subject.getSubType();
>       if(subType !=null) {
>         BaseIDAbstractType baseID = subject.getSubType().getBaseID();
>         if(baseID!=null && baseID instanceof NameIDType) {
>             NameIDType nameID = (NameIDType) baseID;
>             clientSession.setNote(SamlProtocol.SAML_NAME_ID,
> nameID.getValue());
>           }
>       }
>      }
>
>
>
>
>
> On Wed, Oct 5, 2016 at 7:45 AM rony joy <ronyjoy at gmail.com> wrote:
>
> > We have a requirement to receive Username/EmailId in the Subject/NameID
> > field of SAML Request. Keycloak then receive that value in a custom
> > authenticator
> >
> > and send it to the tokenvalidator for further flow. The idea here is to
> omit the step to ask user name from user again if that is present in the
> SAMLRequest.
> >
> > 1. In Keycloak I don't see NameID/BaseID/EncryptedId value from the SAML
> request is putting in the client session. why?
> > 2. I can see that keycloak is parsing the Subject/Name ID field, but not
> adding to the client session? Is the any reason for this?
> >
> > 3. I am willing to fork the repo and do the changes.
> > 4. Please see our SAML request
> >
> > Please let me know your suggestions and ideas
> > Rony Joy
> >
> > <?xml version="1.0" encoding="UTF-8"?><saml2p:AuthnRequest
> > xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="
> http://192.168.99.100:9980/auth/realms/saml-demo/protocol/saml"
> > ForceAuthn="false" ID="daakemmdhjmfajnhpljnckldjmcejllkffegibdj"
> > IsPassive="false" IssueInstant="2016-10-04T04:42:32.860Z"
> > Version="2.0"><saml2:Issuer
> > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">http://
> localhost:8080/employee-sig-idfirst/</saml2:Issuer><ds:Signature
> > xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:
> CanonicalizationMethod
> > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference
> > URI="#daakemmdhjmfajnhpljnckldjmcejllkffegibdj"><ds:Transforms><
> ds:Transform
> > Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature
> "/><ds:Transform
> > Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:
> Transforms><ds:DigestMethod
> > Algorithm="http://www.w3.org/2000/09/xmldsig#sha1
> > "/><ds:DigestValue>R4HTkFdDm5tYqRLGb1Wh8QUwa0o=</
> ds:DigestValue></ds:Reference></ds:SignedInfo><ds:
> SignatureValue>IokRvOo8z3EES+85HvckmYYXQ/Q8DadiGHJdZmmYGpQ3VZW1MYnlBgeV
> wc5Dx4wsNGvRPpAsNM7ij9qGhgLUORuqZshb4YFMMqqDTzg4SoHuq2Ol7jdX
> o3x39hyZGKjoiC7qBxXbSml7j9UixL/7CescKvuh1xTSOBulsM4EefaY+
> J7Ud8ZSEMaqfCk36OaWZwq+8Ss/aZ6p31oMKu9T2dGTW7DZY3mn4Fz0aVr3lYzkaJAOQ+
> mMHOK8TDYlmZcc1e9l37KuKR3Z9dBawXdplHHD25vW/C0NnNfxbo90UTgN2kpDlhGSjrxW3Xp
> vqEpEaF3DwR9Q40iD3M0+su6ZXg==</ds:SignatureValue><ds:
> KeyInfo><ds:X509Data><ds:X509Certificate>MIIC5TCCAc0CBgFWTDcTwDANBgkqhk
> iG9w0BAQsFADA2MTQwMgYDVQQDDCtodHRwOi8vbG9jYWxo
> > b3N0OjgwODAvZW1wbG95ZWUtc2lnLWlkZmlyc3QvMB4XDTE2MDgwMjE3MDMx
> M1oXDTI2MDgwMjE3
> > MDQ1M1owNjE0MDIGA1UEAwwraHR0cDovL2xvY2FsaG9zdDo4MDgwL2VtcGxv
> eWVlLXNpZy1pZGZp
> > cnN0LzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI9BGbuxabZx
> nZdlT8UwWZmT4537
> > zduU08apai2E3m3/xJNEKU5gcufLlYXzAoHNGvoX1j+GowKjv+Z0uypJLpFoyE9tj+
> ng15sO5QfE
> > EK5L7K0yl3W3s4AeNue6YTQjeuL0DoFVj2hUcMEZpd7gjLp/aVzk/
> 9Rx53kIJpEOt9Y1RHql+vW2
> > hIeq9Qap2qkOzjPN85257hqCylfhfk7z7xgMDA6EUalU+
> QCMecsqEr2FDfUtE1qHPAJTMHmjK8DC
> > 4PjtnkLroPSaUoJ1YxJtCcw1vzOrDbSsMW2J6GBtkzNMkRIJIZCqCus4C9Mt
> AVE8hlgSAZSzwN6S
> > FVIj/pgYAscCAwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKtrEjO1MWXxQGx6dD4Ogw
> 9fcJfjXVlY0
> > lsis1s7hxeaqYHZSAtNWTkFp7JltaPp6VFmBs7hPSJUvPo7z13rP+
> 0KuoEht+VgiFlceWFNUN5ur
> > tYskQoN+sQ1V8Z6u/vku6fwVOQm9YpS7Nn582A2nBL4IdgC
> MYhpPPfN39yV24yWpv4VTrOG1q3pj
> > yc1IHCU+ooP8pa64gXt0T/HRRCnm+CWgwYSrhdYYG0rYxAdKQ5GhkfRhR2r
> x2kOgHIuxZ4e2kVla
> > x9zQ9fuBtDn6u4VdzoikJUiEYxt4Sb4YfvgchU1Sk4G0Y+
> K2oP5dPMemdsZMWqzzvrSNQrebPgsB
> > KYpXxA==</ds:X509Certificate></ds:X509Data></ds:KeyInfo></
> ds:Signature>*<saml2:Subject
> > xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"><saml2:NameID
> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:
> unspecified">username</saml2:NameID></saml2:Subject>*<saml2p:NameIDPolicy
> > AllowCreate="true"
> > Format="urn:oasis:names:tc:SAML:1.1:nameid-format:
> unspecified"/></saml2p:AuthnRequest>
> >
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sblanc at redhat.com  Fri Oct  7 02:45:49 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 7 Oct 2016 08:45:49 +0200
Subject: [keycloak-dev] Tomcat 6 will soon be EOL,
 what should we do with the Adapter tomcat 6.x ?
Message-ID: <CAMZCGg8j1r6V80Uy9s=OcMnAYmeSieUrzxsQaQu5=y0iNU_6=A@mail.gmail.com>

Hi,

31/12/2016 Tomcat 6 will be EOL (
https://tomcat.apache.org/tomcat-60-eol.html).
What should happen for the adapter ? Maybe we could consider dropping it
for KC 2.3 ?

From sthorger at redhat.com  Fri Oct  7 03:53:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 7 Oct 2016 09:53:24 +0200
Subject: [keycloak-dev] Tomcat 6 will soon be EOL,
 what should we do with the Adapter tomcat 6.x ?
In-Reply-To: <CAMZCGg8j1r6V80Uy9s=OcMnAYmeSieUrzxsQaQu5=y0iNU_6=A@mail.gmail.com>
References: <CAMZCGg8j1r6V80Uy9s=OcMnAYmeSieUrzxsQaQu5=y0iNU_6=A@mail.gmail.com>
Message-ID: <CAJgngAc+NwCu+xmuEiWNYcPMRzo+y3=mMuzZfHsFBkPUiugsAw@mail.gmail.com>

+1 To removing, but not in 2.3. Can you create a JIRA and set fix version
to 'Next' please.

On 7 October 2016 at 08:45, Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi,
>
> 31/12/2016 Tomcat 6 will be EOL (
> https://tomcat.apache.org/tomcat-60-eol.html).
> What should happen for the adapter ? Maybe we could consider dropping it
> for KC 2.3 ?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Oct  7 03:54:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 7 Oct 2016 09:54:25 +0200
Subject: [keycloak-dev] Tomcat 8 Adapter breaks with Tomcat 8.5.5
In-Reply-To: <CAMZCGg_DfOwXWEeNR5vhJhFtwh=+yX9BhgU1w0bWeDtc43AvdA@mail.gmail.com>
References: <CAMZCGg_DfOwXWEeNR5vhJhFtwh=+yX9BhgU1w0bWeDtc43AvdA@mail.gmail.com>
Message-ID: <CAJgngAeaVK4=jHn4q1Cz-pV5WMcti7jfM3Xb9ha5uc__tZBt0g@mail.gmail.com>

Unless we get a community contribution support for Tomcat 8.5.5 will have
to wait. I've set fix version on KEYCLOAK-3669 to Next for now.

On 6 October 2016 at 18:46, Sebastien Blanc <sblanc at redhat.com> wrote:

> Tomcat 8.5.5 that was released last month doesn't work with the KC Tomcat
> Adapter.
>
> This is because of this bug that has been fixed on their side :
> https://bz.apache.org/bugzilla/show_bug.cgi?id=59823 and their pretty
> "breaking-change" fix :
> https://github.com/apache/tomcat85/commit/c74595783a821cf43de45def094254
> c673298e73?diff=split
>
> I created a ticket , https://issues.jboss.org/browse/KEYCLOAK-3669 , that
> describes the problem and the possible fix.
>
> But the question is : this fix will only be valid (and possible to compile)
> for version of Tomcat > 8.5.5 (including 9). Does that mean we need to
> create a new Adapter just for this version ?
>
>  I'm not sure there is another solution.
>
> Sebi
>
> ps : This also affects people using the latest version of Springboot, as it
> uses tomcat 8.5.5
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Fri Oct  7 11:17:29 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 7 Oct 2016 11:17:29 -0400
Subject: [keycloak-dev] Tomcat 6 will soon be EOL,
 what should we do with the Adapter tomcat 6.x ?
In-Reply-To: <CAJgngAc+NwCu+xmuEiWNYcPMRzo+y3=mMuzZfHsFBkPUiugsAw@mail.gmail.com>
References: <CAMZCGg8j1r6V80Uy9s=OcMnAYmeSieUrzxsQaQu5=y0iNU_6=A@mail.gmail.com>
	<CAJgngAc+NwCu+xmuEiWNYcPMRzo+y3=mMuzZfHsFBkPUiugsAw@mail.gmail.com>
Message-ID: <a6e5f397-ce60-687b-7af7-1e0a19c1956b@redhat.com>

I want download numbers on Tomcat 6.  If they are solid, then IMO, we 
keep it.  Doesn't matter if Tomcat 6 is EOL.  People will probably still 
be using it.  If you look at the adapters there is not much difference 
between Tomcat 6 and Tomcat 8.


On 10/7/16 3:53 AM, Stian Thorgersen wrote:
> +1 To removing, but not in 2.3. Can you create a JIRA and set fix version
> to 'Next' please.
>
> On 7 October 2016 at 08:45, Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> Hi,
>>
>> 31/12/2016 Tomcat 6 will be EOL (
>> https://tomcat.apache.org/tomcat-60-eol.html).
>> What should happen for the adapter ? Maybe we could consider dropping it
>> for KC 2.3 ?
>> _______________________________________________
>> 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 singhrasster at gmail.com  Mon Oct 10 01:17:05 2016
From: singhrasster at gmail.com (Rashmi Singh)
Date: Mon, 10 Oct 2016 00:17:05 -0500
Subject: [keycloak-dev] How to store value in RequiredAction so it becomes
	available in an Authenticator?
Message-ID: <CAJ0vL++vBcnZ0XC_f7gcuCpaeQWTCUHruYcF8=4Lz-bNJS6GaQ@mail.gmail.com>

Hi,

When I set a value in UserSessionNote in authenticator as:

context.getClientSession().setUserSessionNote("testname", "testvalue");

the value set is available in other authenticators. However, I have a
changePasswordAction where I need to store a value to be made available to
an authenticator. I tried setting in a similar way but the value is not
available in the auhenticator. Is that the expected behavior?

In that case, how can I store a value in my ChangePasswordAction so I can
retrieve it in an Authenticator? Any help will be appreciated.

From sthorger at redhat.com  Mon Oct 10 01:47:38 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 10 Oct 2016 07:47:38 +0200
Subject: [keycloak-dev] Tomcat 6 will soon be EOL,
 what should we do with the Adapter tomcat 6.x ?
In-Reply-To: <a6e5f397-ce60-687b-7af7-1e0a19c1956b@redhat.com>
References: <CAMZCGg8j1r6V80Uy9s=OcMnAYmeSieUrzxsQaQu5=y0iNU_6=A@mail.gmail.com>
	<CAJgngAc+NwCu+xmuEiWNYcPMRzo+y3=mMuzZfHsFBkPUiugsAw@mail.gmail.com>
	<a6e5f397-ce60-687b-7af7-1e0a19c1956b@redhat.com>
Message-ID: <CAJgngAdiBPpVm0c6qVk4ODrYAm-yfuxvs=obAGQMjG3_6XJp4A@mail.gmail.com>

4 people downloaded 2.2.1 from the website. We don't yet have maven stats.
So there's someone using it.

Let's just keep it around for now until there's no downloads or there's
some overhead of maintaining it.

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

> I want download numbers on Tomcat 6.  If they are solid, then IMO, we
> keep it.  Doesn't matter if Tomcat 6 is EOL.  People will probably still
> be using it.  If you look at the adapters there is not much difference
> between Tomcat 6 and Tomcat 8.
>
>
> On 10/7/16 3:53 AM, Stian Thorgersen wrote:
> > +1 To removing, but not in 2.3. Can you create a JIRA and set fix version
> > to 'Next' please.
> >
> > On 7 October 2016 at 08:45, Sebastien Blanc <sblanc at redhat.com> wrote:
> >
> >> Hi,
> >>
> >> 31/12/2016 Tomcat 6 will be EOL (
> >> https://tomcat.apache.org/tomcat-60-eol.html).
> >> What should happen for the adapter ? Maybe we could consider dropping it
> >> for KC 2.3 ?
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From gambol99 at gmail.com  Tue Oct 11 08:50:05 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 11 Oct 2016 13:50:05 +0100
Subject: [keycloak-dev] Keycloak Clustering
Message-ID: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>

Hiya

I'm running Keycloak inside Kubernetes and attempting to get clustering
working. Multicasting is isn't available so i'm attempting to get the
gossip protocol working.

Version: 2.2.1-Final

I've changed the standalone-ha.xml

 <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
            <channels default="ee">
                <channel name="ee" stack="tcp"/>
            </channels>
            <stacks>
                <stack name="udp">
                    <transport type="UDP" socket-binding="jgroups-udp"/>
                    <protocol type="PING"/>
                    <protocol type="MERGE3"/>
                    <protocol type="FD_SOCK" socket-binding="jgroups-udp-
fd"/>
                    <protocol type="FD_ALL"/>
                    <protocol type="VERIFY_SUSPECT"/>
                    <protocol type="pbcast.NAKACK2"/>
                    <protocol type="UNICAST3"/>
                    <protocol type="pbcast.STABLE"/>
                    <protocol type="pbcast.GMS"/>
                    <protocol type="UFC"/>
                    <protocol type="MFC"/>
                    <protocol type="FRAG2"/>
                </stack>
                <stack name="tcp">
                    <transport type="TCP" socket-binding="jgroups-tcp"/>
                    <protocol type="TCPGOSSIP">
                      <property name="initial_hosts">${env.
GOSSIP_ROUTER_HOST:127.0.0.1}[12001]</property>
                    </protocol>
                    <protocol type="MPING" socket-binding="jgroups-mping"/>
                    <protocol type="MERGE3"/>
                    <protocol type="FD_SOCK" socket-binding="jgroups-tcp-
fd"/>
                    <protocol type="FD"/>
                    <protocol type="VERIFY_SUSPECT"/>
                    <protocol type="pbcast.NAKACK2"/>
                    <protocol type="UNICAST3"/>
                    <protocol type="pbcast.STABLE"/>
                    <protocol type="pbcast.GMS"/>
                    <protocol type="MFC"/>
                    <protocol type="FRAG2"/>
                </stack>
            </stacks>

The gossip router service were using is jboss/jgroups-gossip

12:40:53,114 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000078: Starting JGroups channel ejb
12:40:53,114 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000078: Starting JGroups channel server
12:40:53,114 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000078: Starting JGroups channel hibernate
12:40:53,114 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000078: Starting JGroups channel keycloak
12:40:53,114 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000078: Starting JGroups channel web
12:40:53,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000094: Received new cluster view for channel
ejb: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000094: Received new cluster view for channel
hibernate: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000094: Received new cluster view for channel
server: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,217 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000094: Received new cluster view for channel
keycloak: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,216 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000094: Received new cluster view for channel
web: [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
12:40:53,221 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-4) ISPN000079: Channel keycloak local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-6) ISPN000079: Channel server local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-1) ISPN000079: Channel hibernate local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-7) ISPN000079: Channel web local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,221 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
(MSC service thread 1-8) ISPN000079: Channel ejb local address is
keycloak-4062290770-sn7jb, physical addresses are [10.10.69.4:7600]
12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry] (MSC
service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
8.1.0.Final
12:40:55,110 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
container
12:40:55,111 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
container
12:40:55,114 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
container
12:40:55,113 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
keycloak container
12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
container
12:40:55,115 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
container
12:40:58,330 INFO  [org.keycloak.services] (ServerService Thread Pool --
58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
12:41:00,911 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
container
12:41:00,921 INFO  [org.jboss.as.clustering.infinispan] (ServerService
Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
keycloak container

But no matter what i seem to change ... I can't multiple pods to see the
membership ... Note, i don't even see a reference to the gossip route
itself, so i'm not entirely sure it's being used.

Are there any working examples or perhaps something obvious i'm missing?

Rohith

From gambol99 at gmail.com  Tue Oct 11 09:42:08 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 11 Oct 2016 14:42:08 +0100
Subject: [keycloak-dev] Keycloak Clustering
In-Reply-To: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
References: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
Message-ID: <CA+AP+fPkXApDbiXe+Gh7pVWoyOr3pGKs_DfSo56PkuNF7Hsayg@mail.gmail.com>

So tcpdumping the in the gossip router I can see traffic from the keycloak
instances when it boots

13:23:09.679254 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [F.], seq
3916063057, ack 3487985413, win 13442, options [nop,nop,TS val 597445725
ecr 597241454], length 0
13:23:09.679956 IP 10.10.69.2.12001 > 10.10.13.2.57533: Flags [F.], seq 1,
ack 1, win 210, options [nop,nop,TS val 597636171 ecr 597445725], length 0
13:23:09.680198 IP 10.10.69.2.12001 > 10.10.69.4.37303: Flags [P.], seq
3146214056:3146214091, ack 2740076567, win 210, options [nop,nop,TS val
597636171 ecr 597194069], length 35
13:23:09.680269 IP 10.10.69.4.37303 > 10.10.69.2.12001: Flags [.], ack 35,
win 13442, options [nop,nop,TS val 597636171 ecr 597636171], length 0
13:23:09.680550 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [.], ack 2,
win 13442, options [nop,nop,TS val 597445726 ecr 597636171], length 0

Oddly enough I see UDP from KC instance to multicast

13:37:54.224690 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
E..x.. at ...Hj

....ee...8..DT.:......)%lp......keycloak-648398853-kfidy..

None the less, the instances don't seem to be aware of one another ...
logging into one and refreshing will eventually hit the other and error
with unknown bearer; also when I had this working before in v1.9.0 bringing
up or killing a instance would show membership logs events on the console

Rohith


On Tue, Oct 11, 2016 at 1:50 PM, gambol <gambol99 at gmail.com> wrote:

> Hiya
>
> I'm running Keycloak inside Kubernetes and attempting to get clustering
> working. Multicasting is isn't available so i'm attempting to get the
> gossip protocol working.
>
> Version: 2.2.1-Final
>
> I've changed the standalone-ha.xml
>
>  <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>             <channels default="ee">
>                 <channel name="ee" stack="tcp"/>
>             </channels>
>             <stacks>
>                 <stack name="udp">
>                     <transport type="UDP" socket-binding="jgroups-udp"/>
>                     <protocol type="PING"/>
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd
> "/>
>                     <protocol type="FD_ALL"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK2"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="UFC"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                 </stack>
>                 <stack name="tcp">
>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>                     <protocol type="TCPGOSSIP">
>                       <property name="initial_hosts">${env.GOS
> SIP_ROUTER_HOST:127.0.0.1}[12001]</property>
>                     </protocol>
>                     <protocol type="MPING" socket-binding="jgroups-mping"
> />
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd
> "/>
>                     <protocol type="FD"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK2"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                 </stack>
>             </stacks>
>
> The gossip router service were using is jboss/jgroups-gossip
>
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078:
> Starting JGroups channel ejb
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078:
> Starting JGroups channel server
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078:
> Starting JGroups channel hibernate
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078:
> Starting JGroups channel keycloak
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078:
> Starting JGroups channel web
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094:
> Received new cluster view for channel ejb: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094:
> Received new cluster view for channel hibernate:
> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094:
> Received new cluster view for channel server: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,217 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094:
> Received new cluster view for channel keycloak:
> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094:
> Received new cluster view for channel web: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079:
> Channel keycloak local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079:
> Channel server local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079:
> Channel hibernate local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079:
> Channel web local address is keycloak-4062290770-sn7jb, physical addresses
> are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079:
> Channel ejb local address is keycloak-4062290770-sn7jb, physical addresses
> are [10.10.69.4:7600]
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:55,110 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
> container
> 12:40:55,111 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
> container
> 12:40:55,114 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
> container
> 12:40:55,113 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
> keycloak container
> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
> container
> 12:40:55,115 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
> container
> 12:40:58,330 INFO  [org.keycloak.services] (ServerService Thread Pool --
> 58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
> 12:41:00,911 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
> container
> 12:41:00,921 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
> keycloak container
>
> But no matter what i seem to change ... I can't multiple pods to see the
> membership ... Note, i don't even see a reference to the gossip route
> itself, so i'm not entirely sure it's being used.
>
> Are there any working examples or perhaps something obvious i'm missing?
>
> Rohith
>
>

From gambol99 at gmail.com  Tue Oct 11 10:20:01 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 11 Oct 2016 15:20:01 +0100
Subject: [keycloak-dev] Keycloak Clustering
In-Reply-To: <CA+AP+fPkXApDbiXe+Gh7pVWoyOr3pGKs_DfSo56PkuNF7Hsayg@mail.gmail.com>
References: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
	<CA+AP+fPkXApDbiXe+Gh7pVWoyOr3pGKs_DfSo56PkuNF7Hsayg@mail.gmail.com>
Message-ID: <CA+AP+fOVKy=v3_euc2guLRjs9DzFgTWUj+yJYK+TBMNcewfAsg@mail.gmail.com>

Ok ... so the error appears to be related to it's use of multi-casting
(which would not propagate nodes over flannel overlay network); as when I
pin the keycloaks instances to the same kubernetes node, suddenly
everything works when a new pod is added ...

] (1) [keycloak-2268126783-gjr2g]
14:00:57,413 INFO
 [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-1) ISPN000094: Received new cluster view for channel server:
[keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
14:00:57,414 INFO
 [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-2) ISPN000094: Received new cluster view for channel ejb:
[keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
14:00:57,415 INFO
 [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-7) ISPN000094: Received new cluster view for channel hibernate:
[keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
14:00:57,415 INFO
 [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-5) ISPN000094: Received new cluster view for channel keycloak:
[keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
14:00:57,419 INFO
 [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service
thread 1-2) ISPN000079: Channel ejb local address is
keycloak-2268126783-gjr2g, physical addresConnection to 10.70.2.71 closed.


Placing on different nodes will result in and unanswered multicasting

14:14:52.676714 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack 1,
win 553, options [nop,nop,TS val 600739168 ecr 600901632], length 0
14:14:52.676877 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack 1,
win 235, options [nop,nop,TS val 600911648 ecr 600568905], length 0
> 14:14:59.557124 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
> 14:14:59.557157 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
14:15:02.628054 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack 1,
win 235, options [nop,nop,TS val 600921600 ecr 600568905], length 0
14:15:02.628073 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack 1,
win 553, options [nop,nop,TS val 600749119 ecr 600911648], length 0
14:15:02.692712 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack 1,
win 553, options [nop,nop,TS val 600749184 ecr 600911648], length 0
14:15:02.692894 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack 1,
win 235, options [nop,nop,TS val 600921664 ecr 600749119], length 0
14:15:07.636711 ARP, Request who-has 10.10.69.4 tell 10.10.69.1, length 28
14:15:07.636738 ARP, Reply 10.10.69.4 is-at 02:42:0a:0a:45:04, length 28

Perhaps i've misunderstood tcpgossip? ... Anyone know how to stop using MC
and where in the config this is set? ...

Rohith


On Tue, Oct 11, 2016 at 2:42 PM, gambol <gambol99 at gmail.com> wrote:

>
> So tcpdumping the in the gossip router I can see traffic from the keycloak
> instances when it boots
>
> 13:23:09.679254 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [F.], seq
> 3916063057, ack 3487985413, win 13442, options [nop,nop,TS val 597445725
> ecr 597241454], length 0
> 13:23:09.679956 IP 10.10.69.2.12001 > 10.10.13.2.57533: Flags [F.], seq 1,
> ack 1, win 210, options [nop,nop,TS val 597636171 ecr 597445725], length 0
> 13:23:09.680198 IP 10.10.69.2.12001 > 10.10.69.4.37303: Flags [P.], seq
> 3146214056:3146214091, ack 2740076567, win 210, options [nop,nop,TS val
> 597636171 ecr 597194069], length 35
> 13:23:09.680269 IP 10.10.69.4.37303 > 10.10.69.2.12001: Flags [.], ack 35,
> win 13442, options [nop,nop,TS val 597636171 ecr 597636171], length 0
> 13:23:09.680550 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [.], ack 2,
> win 13442, options [nop,nop,TS val 597445726 ecr 597636171], length 0
>
> Oddly enough I see UDP from KC instance to multicast
>
> 13:37:54.224690 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
> E..x.. at ...Hj
>
> ....ee...8..DT.:......)%lp......keycloak-648398853-kfidy..
>
> None the less, the instances don't seem to be aware of one another ...
> logging into one and refreshing will eventually hit the other and error
> with unknown bearer; also when I had this working before in v1.9.0 bringing
> up or killing a instance would show membership logs events on the console
>
> Rohith
>
>
> On Tue, Oct 11, 2016 at 1:50 PM, gambol <gambol99 at gmail.com> wrote:
>
>> Hiya
>>
>> I'm running Keycloak inside Kubernetes and attempting to get clustering
>> working. Multicasting is isn't available so i'm attempting to get the
>> gossip protocol working.
>>
>> Version: 2.2.1-Final
>>
>> I've changed the standalone-ha.xml
>>
>>  <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>>             <channels default="ee">
>>                 <channel name="ee" stack="tcp"/>
>>             </channels>
>>             <stacks>
>>                 <stack name="udp">
>>                     <transport type="UDP" socket-binding="jgroups-udp"/>
>>                     <protocol type="PING"/>
>>                     <protocol type="MERGE3"/>
>>                     <protocol type="FD_SOCK"
>> socket-binding="jgroups-udp-fd"/>
>>                     <protocol type="FD_ALL"/>
>>                     <protocol type="VERIFY_SUSPECT"/>
>>                     <protocol type="pbcast.NAKACK2"/>
>>                     <protocol type="UNICAST3"/>
>>                     <protocol type="pbcast.STABLE"/>
>>                     <protocol type="pbcast.GMS"/>
>>                     <protocol type="UFC"/>
>>                     <protocol type="MFC"/>
>>                     <protocol type="FRAG2"/>
>>                 </stack>
>>                 <stack name="tcp">
>>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>>                     <protocol type="TCPGOSSIP">
>>                       <property name="initial_hosts">${env.GOS
>> SIP_ROUTER_HOST:127.0.0.1}[12001]</property>
>>                     </protocol>
>>                     <protocol type="MPING" socket-binding="jgroups-mping"
>> />
>>                     <protocol type="MERGE3"/>
>>                     <protocol type="FD_SOCK"
>> socket-binding="jgroups-tcp-fd"/>
>>                     <protocol type="FD"/>
>>                     <protocol type="VERIFY_SUSPECT"/>
>>                     <protocol type="pbcast.NAKACK2"/>
>>                     <protocol type="UNICAST3"/>
>>                     <protocol type="pbcast.STABLE"/>
>>                     <protocol type="pbcast.GMS"/>
>>                     <protocol type="MFC"/>
>>                     <protocol type="FRAG2"/>
>>                 </stack>
>>             </stacks>
>>
>> The gossip router service were using is jboss/jgroups-gossip
>>
>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078:
>> Starting JGroups channel ejb
>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078:
>> Starting JGroups channel server
>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078:
>> Starting JGroups channel hibernate
>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078:
>> Starting JGroups channel keycloak
>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078:
>> Starting JGroups channel web
>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094:
>> Received new cluster view for channel ejb: [keycloak-4062290770-sn7jb|0]
>> (1) [keycloak-4062290770-sn7jb]
>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094:
>> Received new cluster view for channel hibernate:
>> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094:
>> Received new cluster view for channel server: [keycloak-4062290770-sn7jb|0]
>> (1) [keycloak-4062290770-sn7jb]
>> 12:40:53,217 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094:
>> Received new cluster view for channel keycloak:
>> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094:
>> Received new cluster view for channel web: [keycloak-4062290770-sn7jb|0]
>> (1) [keycloak-4062290770-sn7jb]
>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079:
>> Channel keycloak local address is keycloak-4062290770-sn7jb, physical
>> addresses are [10.10.69.4:7600]
>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079:
>> Channel server local address is keycloak-4062290770-sn7jb, physical
>> addresses are [10.10.69.4:7600]
>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079:
>> Channel hibernate local address is keycloak-4062290770-sn7jb, physical
>> addresses are [10.10.69.4:7600]
>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079:
>> Channel web local address is keycloak-4062290770-sn7jb, physical addresses
>> are [10.10.69.4:7600]
>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079:
>> Channel ejb local address is keycloak-4062290770-sn7jb, physical addresses
>> are [10.10.69.4:7600]
>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>> (MSC service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
>> 8.1.0.Final
>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>> (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
>> 8.1.0.Final
>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>> (MSC service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
>> 8.1.0.Final
>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>> (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
>> 8.1.0.Final
>> 12:40:55,110 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
>> container
>> 12:40:55,111 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
>> container
>> 12:40:55,114 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
>> container
>> 12:40:55,113 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
>> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
>> keycloak container
>> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
>> container
>> 12:40:55,115 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
>> container
>> 12:40:58,330 INFO  [org.keycloak.services] (ServerService Thread Pool --
>> 58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
>> 12:41:00,911 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
>> container
>> 12:41:00,921 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>> Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
>> keycloak container
>>
>> But no matter what i seem to change ... I can't multiple pods to see the
>> membership ... Note, i don't even see a reference to the gossip route
>> itself, so i'm not entirely sure it's being used.
>>
>> Are there any working examples or perhaps something obvious i'm missing?
>>
>> Rohith
>>
>>
>

From bachoreczm at gmail.com  Tue Oct 11 11:07:18 2016
From: bachoreczm at gmail.com (=?UTF-8?B?TcOhdHnDoXMgQmFjaG9yZWN6?=)
Date: Tue, 11 Oct 2016 17:07:18 +0200
Subject: [keycloak-dev] feature request
Message-ID: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>

Hi,

we have a multi-component project, and all components running in one
machine, also Keycloak.
We would like to obtain token via curl, and our components would like to
validate it, but they can't, because we've got:
"Token audience doesn't match domain. Token issuer is " + token.getIssuer()
+ ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)

I would like to implement a new feature: a new checkbox or something else
to realm settings page, which can switch off the above mentioned feature.
I've read that I should write an email here if I would like to implement
something. Is it ok, or how it works?

Br,
Matyi

From gambol99 at gmail.com  Tue Oct 11 11:12:37 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 11 Oct 2016 16:12:37 +0100
Subject: [keycloak-dev] Keycloak Clustering
In-Reply-To: <CA+AP+fOVKy=v3_euc2guLRjs9DzFgTWUj+yJYK+TBMNcewfAsg@mail.gmail.com>
References: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
	<CA+AP+fPkXApDbiXe+Gh7pVWoyOr3pGKs_DfSo56PkuNF7Hsayg@mail.gmail.com>
	<CA+AP+fOVKy=v3_euc2guLRjs9DzFgTWUj+yJYK+TBMNcewfAsg@mail.gmail.com>
Message-ID: <CA+AP+fOTV6FP4KWX_KFs4ux2KCznG38U1d3=3s=cNwJeVcPnQQ@mail.gmail.com>

As a short term fix ... removing any references to mping from
standalone-ha.xml fixed the issue, though i'm not sure how to select this
are runtime? ...

Rohith

On Tue, Oct 11, 2016 at 3:20 PM, gambol <gambol99 at gmail.com> wrote:

> Ok ... so the error appears to be related to it's use of multi-casting
> (which would not propagate nodes over flannel overlay network); as when I
> pin the keycloaks instances to the same kubernetes node, suddenly
> everything works when a new pod is added ...
>
> ] (1) [keycloak-2268126783-gjr2g]
> 14:00:57,413 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (MSC service thread 1-1) ISPN000094: Received new cluster view for channel
> server: [keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
> 14:00:57,414 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (MSC service thread 1-2) ISPN000094: Received new cluster view for channel
> ejb: [keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
> 14:00:57,415 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (MSC service thread 1-7) ISPN000094: Received new cluster view for channel
> hibernate: [keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
> 14:00:57,415 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (MSC service thread 1-5) ISPN000094: Received new cluster view for channel
> keycloak: [keycloak-2268126783-gjr2g|0] (1) [keycloak-2268126783-gjr2g]
> 14:00:57,419 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport]
> (MSC service thread 1-2) ISPN000079: Channel ejb local address is
> keycloak-2268126783-gjr2g, physical addresConnection to 10.70.2.71 closed.
>
>
> Placing on different nodes will result in and unanswered multicasting
>
> 14:14:52.676714 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack
> 1, win 553, options [nop,nop,TS val 600739168 ecr 600901632], length 0
> 14:14:52.676877 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack
> 1, win 235, options [nop,nop,TS val 600911648 ecr 600568905], length 0
> > 14:14:59.557124 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
> > 14:14:59.557157 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
> 14:15:02.628054 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack
> 1, win 235, options [nop,nop,TS val 600921600 ecr 600568905], length 0
> 14:15:02.628073 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack
> 1, win 553, options [nop,nop,TS val 600749119 ecr 600911648], length 0
> 14:15:02.692712 IP 10.10.69.4.32790 > 10.200.227.31.8200: Flags [.], ack
> 1, win 553, options [nop,nop,TS val 600749184 ecr 600911648], length 0
> 14:15:02.692894 IP 10.200.227.31.8200 > 10.10.69.4.32790: Flags [.], ack
> 1, win 235, options [nop,nop,TS val 600921664 ecr 600749119], length 0
> 14:15:07.636711 ARP, Request who-has 10.10.69.4 tell 10.10.69.1, length 28
> 14:15:07.636738 ARP, Reply 10.10.69.4 is-at 02:42:0a:0a:45:04, length 28
>
> Perhaps i've misunderstood tcpgossip? ... Anyone know how to stop using MC
> and where in the config this is set? ...
>
> Rohith
>
>
> On Tue, Oct 11, 2016 at 2:42 PM, gambol <gambol99 at gmail.com> wrote:
>
>>
>> So tcpdumping the in the gossip router I can see traffic from the
>> keycloak instances when it boots
>>
>> 13:23:09.679254 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [F.], seq
>> 3916063057, ack 3487985413, win 13442, options [nop,nop,TS val 597445725
>> ecr 597241454], length 0
>> 13:23:09.679956 IP 10.10.69.2.12001 > 10.10.13.2.57533: Flags [F.], seq
>> 1, ack 1, win 210, options [nop,nop,TS val 597636171 ecr 597445725], length
>> 0
>> 13:23:09.680198 IP 10.10.69.2.12001 > 10.10.69.4.37303: Flags [P.], seq
>> 3146214056:3146214091, ack 2740076567, win 210, options [nop,nop,TS val
>> 597636171 ecr 597194069], length 35
>> 13:23:09.680269 IP 10.10.69.4.37303 > 10.10.69.2.12001: Flags [.], ack
>> 35, win 13442, options [nop,nop,TS val 597636171 ecr 597636171], length 0
>> 13:23:09.680550 IP 10.10.13.2.57533 > 10.10.69.2.12001: Flags [.], ack 2,
>> win 13442, options [nop,nop,TS val 597445726 ecr 597636171], length 0
>>
>> Oddly enough I see UDP from KC instance to multicast
>>
>> 13:37:54.224690 IP 10.10.69.4.45700 > 230.0.0.4.45700: UDP, length 92
>> E..x.. at ...Hj
>>
>> ....ee...8..DT.:......)%lp......keycloak-648398853-kfidy..
>>
>> None the less, the instances don't seem to be aware of one another ...
>> logging into one and refreshing will eventually hit the other and error
>> with unknown bearer; also when I had this working before in v1.9.0 bringing
>> up or killing a instance would show membership logs events on the console
>>
>> Rohith
>>
>>
>> On Tue, Oct 11, 2016 at 1:50 PM, gambol <gambol99 at gmail.com> wrote:
>>
>>> Hiya
>>>
>>> I'm running Keycloak inside Kubernetes and attempting to get clustering
>>> working. Multicasting is isn't available so i'm attempting to get the
>>> gossip protocol working.
>>>
>>> Version: 2.2.1-Final
>>>
>>> I've changed the standalone-ha.xml
>>>
>>>  <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>>>             <channels default="ee">
>>>                 <channel name="ee" stack="tcp"/>
>>>             </channels>
>>>             <stacks>
>>>                 <stack name="udp">
>>>                     <transport type="UDP" socket-binding="jgroups-udp"/>
>>>                     <protocol type="PING"/>
>>>                     <protocol type="MERGE3"/>
>>>                     <protocol type="FD_SOCK"
>>> socket-binding="jgroups-udp-fd"/>
>>>                     <protocol type="FD_ALL"/>
>>>                     <protocol type="VERIFY_SUSPECT"/>
>>>                     <protocol type="pbcast.NAKACK2"/>
>>>                     <protocol type="UNICAST3"/>
>>>                     <protocol type="pbcast.STABLE"/>
>>>                     <protocol type="pbcast.GMS"/>
>>>                     <protocol type="UFC"/>
>>>                     <protocol type="MFC"/>
>>>                     <protocol type="FRAG2"/>
>>>                 </stack>
>>>                 <stack name="tcp">
>>>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>>>                     <protocol type="TCPGOSSIP">
>>>                       <property name="initial_hosts">${env.GOS
>>> SIP_ROUTER_HOST:127.0.0.1}[12001]</property>
>>>                     </protocol>
>>>                     <protocol type="MPING" socket-binding="jgroups-mping"
>>> />
>>>                     <protocol type="MERGE3"/>
>>>                     <protocol type="FD_SOCK"
>>> socket-binding="jgroups-tcp-fd"/>
>>>                     <protocol type="FD"/>
>>>                     <protocol type="VERIFY_SUSPECT"/>
>>>                     <protocol type="pbcast.NAKACK2"/>
>>>                     <protocol type="UNICAST3"/>
>>>                     <protocol type="pbcast.STABLE"/>
>>>                     <protocol type="pbcast.GMS"/>
>>>                     <protocol type="MFC"/>
>>>                     <protocol type="FRAG2"/>
>>>                 </stack>
>>>             </stacks>
>>>
>>> The gossip router service were using is jboss/jgroups-gossip
>>>
>>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078:
>>> Starting JGroups channel ejb
>>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078:
>>> Starting JGroups channel server
>>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078:
>>> Starting JGroups channel hibernate
>>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078:
>>> Starting JGroups channel keycloak
>>> 12:40:53,114 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078:
>>> Starting JGroups channel web
>>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094:
>>> Received new cluster view for channel ejb: [keycloak-4062290770-sn7jb|0]
>>> (1) [keycloak-4062290770-sn7jb]
>>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094:
>>> Received new cluster view for channel hibernate:
>>> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
>>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094:
>>> Received new cluster view for channel server: [keycloak-4062290770-sn7jb|0]
>>> (1) [keycloak-4062290770-sn7jb]
>>> 12:40:53,217 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094:
>>> Received new cluster view for channel keycloak:
>>> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
>>> 12:40:53,216 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094:
>>> Received new cluster view for channel web: [keycloak-4062290770-sn7jb|0]
>>> (1) [keycloak-4062290770-sn7jb]
>>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079:
>>> Channel keycloak local address is keycloak-4062290770-sn7jb, physical
>>> addresses are [10.10.69.4:7600]
>>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079:
>>> Channel server local address is keycloak-4062290770-sn7jb, physical
>>> addresses are [10.10.69.4:7600]
>>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079:
>>> Channel hibernate local address is keycloak-4062290770-sn7jb, physical
>>> addresses are [10.10.69.4:7600]
>>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079:
>>> Channel web local address is keycloak-4062290770-sn7jb, physical addresses
>>> are [10.10.69.4:7600]
>>> 12:40:53,221 INFO  [org.infinispan.remoting.tran
>>> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079:
>>> Channel ejb local address is keycloak-4062290770-sn7jb, physical addresses
>>> are [10.10.69.4:7600]
>>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>>> (MSC service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
>>> 8.1.0.Final
>>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>>> (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
>>> 8.1.0.Final
>>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>>> (MSC service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
>>> 8.1.0.Final
>>> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
>>> (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
>>> 8.1.0.Final
>>> 12:40:55,110 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
>>> container
>>> 12:40:55,111 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
>>> container
>>> 12:40:55,114 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
>>> container
>>> 12:40:55,113 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
>>> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
>>> keycloak container
>>> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
>>> container
>>> 12:40:55,115 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
>>> container
>>> 12:40:58,330 INFO  [org.keycloak.services] (ServerService Thread Pool --
>>> 58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
>>> 12:41:00,911 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
>>> container
>>> 12:41:00,921 INFO  [org.jboss.as.clustering.infinispan] (ServerService
>>> Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
>>> keycloak container
>>>
>>> But no matter what i seem to change ... I can't multiple pods to see the
>>> membership ... Note, i don't even see a reference to the gossip route
>>> itself, so i'm not entirely sure it's being used.
>>>
>>> Are there any working examples or perhaps something obvious i'm missing?
>>>
>>> Rohith
>>>
>>>
>>
>

From sthorger at redhat.com  Tue Oct 11 12:45:44 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 11 Oct 2016 18:45:44 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
Message-ID: <CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>

Rather than hacking Keycloak you should figure out why your token audience
doesn't match. For a token to be valid it has to been issued by the same
server URL and realm. It's an important check and we wouldn't accept a
feature that prevents it.

On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com> wrote:

> Hi,
>
> we have a multi-component project, and all components running in one
> machine, also Keycloak.
> We would like to obtain token via curl, and our components would like to
> validate it, but they can't, because we've got:
> "Token audience doesn't match domain. Token issuer is " + token.getIssuer()
> + ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
>
> I would like to implement a new feature: a new checkbox or something else
> to realm settings page, which can switch off the above mentioned feature.
> I've read that I should write an email here if I would like to implement
> something. Is it ok, or how it works?
>
> Br,
> Matyi
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From gambol99 at gmail.com  Tue Oct 11 15:10:00 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 11 Oct 2016 20:10:00 +0100
Subject: [keycloak-dev] Keycloak Clustering
In-Reply-To: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
References: <CA+AP+fNJmkxF21FP25Vxz_Bp0T1Zijy8eF9M-1Nc+3b-EhZ4Ug@mail.gmail.com>
Message-ID: <CA+AP+fP3YgiytZf66Vs+_T0TotyfBQQKjeOMZtKaiQEuKvdvDQ@mail.gmail.com>

Just to round up and close off, albeit a one person thread, the moral of
the story - "read the documentation" (
http://www.jgroups.org/manual/html/user-advanced.html) ... I've got
clustering working fine :-)

On Tue, Oct 11, 2016 at 1:50 PM, gambol <gambol99 at gmail.com> wrote:

> Hiya
>
> I'm running Keycloak inside Kubernetes and attempting to get clustering
> working. Multicasting is isn't available so i'm attempting to get the
> gossip protocol working.
>
> Version: 2.2.1-Final
>
> I've changed the standalone-ha.xml
>
>  <subsystem xmlns="urn:jboss:domain:jgroups:4.0">
>             <channels default="ee">
>                 <channel name="ee" stack="tcp"/>
>             </channels>
>             <stacks>
>                 <stack name="udp">
>                     <transport type="UDP" socket-binding="jgroups-udp"/>
>                     <protocol type="PING"/>
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK" socket-binding="jgroups-udp-fd
> "/>
>                     <protocol type="FD_ALL"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK2"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="UFC"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                 </stack>
>                 <stack name="tcp">
>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>                     <protocol type="TCPGOSSIP">
>                       <property name="initial_hosts">${env.GOS
> SIP_ROUTER_HOST:127.0.0.1}[12001]</property>
>                     </protocol>
>                     <protocol type="MPING" socket-binding="jgroups-mping"
> />
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd
> "/>
>                     <protocol type="FD"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK2"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                 </stack>
>             </stacks>
>
> The gossip router service were using is jboss/jgroups-gossip
>
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000078:
> Starting JGroups channel ejb
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000078:
> Starting JGroups channel server
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000078:
> Starting JGroups channel hibernate
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000078:
> Starting JGroups channel keycloak
> 12:40:53,114 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000078:
> Starting JGroups channel web
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000094:
> Received new cluster view for channel ejb: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000094:
> Received new cluster view for channel hibernate:
> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000094:
> Received new cluster view for channel server: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,217 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000094:
> Received new cluster view for channel keycloak:
> [keycloak-4062290770-sn7jb|0] (1) [keycloak-4062290770-sn7jb]
> 12:40:53,216 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000094:
> Received new cluster view for channel web: [keycloak-4062290770-sn7jb|0]
> (1) [keycloak-4062290770-sn7jb]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-4) ISPN000079:
> Channel keycloak local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-6) ISPN000079:
> Channel server local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-1) ISPN000079:
> Channel hibernate local address is keycloak-4062290770-sn7jb, physical
> addresses are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-7) ISPN000079:
> Channel web local address is keycloak-4062290770-sn7jb, physical addresses
> are [10.10.69.4:7600]
> 12:40:53,221 INFO  [org.infinispan.remoting.tran
> sport.jgroups.JGroupsTransport] (MSC service thread 1-8) ISPN000079:
> Channel ejb local address is keycloak-4062290770-sn7jb, physical addresses
> are [10.10.69.4:7600]
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-6) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-8) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:53,314 INFO  [org.infinispan.factories.GlobalComponentRegistry]
> (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Mahou'
> 8.1.0.Final
> 12:40:55,110 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 60) WFLYCLINF0002: Started users cache from keycloak
> container
> 12:40:55,111 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 52) WFLYCLINF0002: Started realms cache from keycloak
> container
> 12:40:55,114 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 56) WFLYCLINF0002: Started sessions cache from keycloak
> container
> 12:40:55,113 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 54) WFLYCLINF0002: Started work cache from keycloak container
> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 59) WFLYCLINF0002: Started offlineSessions cache from
> keycloak container
> 12:40:55,117 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started authorization cache from keycloak
> container
> 12:40:55,115 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 55) WFLYCLINF0002: Started loginFailures cache from keycloak
> container
> 12:40:58,330 INFO  [org.keycloak.services] (ServerService Thread Pool --
> 58) KC-SERVICES0001: Loading config from standalone.xml or domain.xml
> 12:41:00,911 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started userRevisions cache from keycloak
> container
> 12:41:00,921 INFO  [org.jboss.as.clustering.infinispan] (ServerService
> Thread Pool -- 58) WFLYCLINF0002: Started realmRevisions cache from
> keycloak container
>
> But no matter what i seem to change ... I can't multiple pods to see the
> membership ... Note, i don't even see a reference to the gossip route
> itself, so i'm not entirely sure it's being used.
>
> Are there any working examples or perhaps something obvious i'm missing?
>
> Rohith
>
>

From mauriciogiacomini at hotmail.com  Tue Oct 11 17:50:16 2016
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Tue, 11 Oct 2016 21:50:16 +0000
Subject: [keycloak-dev] KeycloakSecurityContext is always null
Message-ID: <CY1PR0501MB180415798BBDD9A0A2B17B5AA8DA0@CY1PR0501MB1804.namprd05.prod.outlook.com>

Hello everyone,

I do not understanding how can I correctly use KeycloakSecurityContext on a Rest service to obtain access to keycloak tokens.

I tryed via httpServletRequest:
KeycloakSecurityContext session = (KeycloakSecurityContext) httpServletRequest.getAttribute(KeycloakSecurityContext.class.getName());

But, my KeycloakSecurityContext is always null.
I put the anotation @SecurityDomain("keycloak") on my class without success.

The authentication works perfectly but, the authorization is a problem. I am trying access to KeycloakSecurityContext to work with authorization.

If someone has a tip that can help me, please let me know.

Regards,
Mauricio.


From sthorger at redhat.com  Wed Oct 12 00:59:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 06:59:04 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
Message-ID: <CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>

[Adding list again]

Token based security relies on HTTPS for security. You need to use the
HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
match the issuer of the domain.

On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com> wrote:

> My token audience does not match, because we request for a token via
> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
> private ip (like 192.168.xx.xx). So my question is how to solve this
> problem?
>
> There are two machines, one belongs to user, and on the other we running
> keycloak, and a client, which can validate token. But client only nows the
> private ip, and user can't access keycloak on private ip, cause he/she is
> not in that network.
>
> Br,
> Matyi
>
> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Rather than hacking Keycloak you should figure out why your token
>> audience doesn't match. For a token to be valid it has to been issued by
>> the same server URL and realm. It's an important check and we wouldn't
>> accept a feature that prevents it.
>>
>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> we have a multi-component project, and all components running in one
>>> machine, also Keycloak.
>>> We would like to obtain token via curl, and our components would like to
>>> validate it, but they can't, because we've got:
>>> "Token audience doesn't match domain. Token issuer is " +
>>> token.getIssuer()
>>> + ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
>>>
>>> I would like to implement a new feature: a new checkbox or something else
>>> to realm settings page, which can switch off the above mentioned feature.
>>> I've read that I should write an email here if I would like to implement
>>> something. Is it ok, or how it works?
>>>
>>> Br,
>>> Matyi
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From sthorger at redhat.com  Wed Oct 12 01:00:36 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 07:00:36 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
Message-ID: <CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>

You can obviously use DNS settings and the machines hosts file to change
what IP address the name resolves to.

https://machine.local could resolve to 10.0.0.12 or 192.168.1.12 depending
on where it's called from.

On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com> wrote:

> [Adding list again]
>
> Token based security relies on HTTPS for security. You need to use the
> HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
> match the issuer of the domain.
>
> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
> wrote:
>
>> My token audience does not match, because we request for a token via
>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>> private ip (like 192.168.xx.xx). So my question is how to solve this
>> problem?
>>
>> There are two machines, one belongs to user, and on the other we running
>> keycloak, and a client, which can validate token. But client only nows the
>> private ip, and user can't access keycloak on private ip, cause he/she is
>> not in that network.
>>
>> Br,
>> Matyi
>>
>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Rather than hacking Keycloak you should figure out why your token
>>> audience doesn't match. For a token to be valid it has to been issued by
>>> the same server URL and realm. It's an important check and we wouldn't
>>> accept a feature that prevents it.
>>>
>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> we have a multi-component project, and all components running in one
>>>> machine, also Keycloak.
>>>> We would like to obtain token via curl, and our components would like to
>>>> validate it, but they can't, because we've got:
>>>> "Token audience doesn't match domain. Token issuer is " +
>>>> token.getIssuer()
>>>> + ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
>>>>
>>>> I would like to implement a new feature: a new checkbox or something
>>>> else
>>>> to realm settings page, which can switch off the above mentioned
>>>> feature.
>>>> I've read that I should write an email here if I would like to implement
>>>> something. Is it ok, or how it works?
>>>>
>>>> Br,
>>>> Matyi
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>

From bachoreczm at gmail.com  Wed Oct 12 01:48:11 2016
From: bachoreczm at gmail.com (=?UTF-8?B?TcOhdHnDoXMgQmFjaG9yZWN6?=)
Date: Wed, 12 Oct 2016 07:48:11 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
	<CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
Message-ID: <CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>

I understand, thank you for your answer.

On 12 October 2016 at 07:00, Stian Thorgersen <sthorger at redhat.com> wrote:

> You can obviously use DNS settings and the machines hosts file to change
> what IP address the name resolves to.
>
> https://machine.local could resolve to 10.0.0.12 or 192.168.1.12
> depending on where it's called from.
>
> On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> [Adding list again]
>>
>> Token based security relies on HTTPS for security. You need to use the
>> HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
>> match the issuer of the domain.
>>
>> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
>> wrote:
>>
>>> My token audience does not match, because we request for a token via
>>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>>> private ip (like 192.168.xx.xx). So my question is how to solve this
>>> problem?
>>>
>>> There are two machines, one belongs to user, and on the other we running
>>> keycloak, and a client, which can validate token. But client only nows the
>>> private ip, and user can't access keycloak on private ip, cause he/she is
>>> not in that network.
>>>
>>> Br,
>>> Matyi
>>>
>>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Rather than hacking Keycloak you should figure out why your token
>>>> audience doesn't match. For a token to be valid it has to been issued by
>>>> the same server URL and realm. It's an important check and we wouldn't
>>>> accept a feature that prevents it.
>>>>
>>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> we have a multi-component project, and all components running in one
>>>>> machine, also Keycloak.
>>>>> We would like to obtain token via curl, and our components would like
>>>>> to
>>>>> validate it, but they can't, because we've got:
>>>>> "Token audience doesn't match domain. Token issuer is " +
>>>>> token.getIssuer()
>>>>> + ", but URL from configuration is " + realmUrl (RSATokenVerifier.java)
>>>>>
>>>>> I would like to implement a new feature: a new checkbox or something
>>>>> else
>>>>> to realm settings page, which can switch off the above mentioned
>>>>> feature.
>>>>> I've read that I should write an email here if I would like to
>>>>> implement
>>>>> something. Is it ok, or how it works?
>>>>>
>>>>> Br,
>>>>> Matyi
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From bachoreczm at gmail.com  Wed Oct 12 01:56:11 2016
From: bachoreczm at gmail.com (=?UTF-8?B?TcOhdHnDoXMgQmFjaG9yZWN6?=)
Date: Wed, 12 Oct 2016 07:56:11 +0200
Subject: [keycloak-dev] obtain auth-code (standard flow)
Message-ID: <CAGTR_EQOj0bGsyZ1ryPYYhaRQ2ZmhvRYFY8PcHJLnG8Gt+AXFw@mail.gmail.com>

Hi,

how can i get authoriziation code via curl?

Br,
Matyi

From bachoreczm at gmail.com  Wed Oct 12 02:28:05 2016
From: bachoreczm at gmail.com (=?UTF-8?B?TcOhdHnDoXMgQmFjaG9yZWN6?=)
Date: Wed, 12 Oct 2016 08:28:05 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
	<CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
	<CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>
Message-ID: <CAGTR_ERKJhg-_+rE9VbmC5Mbfd638gmC8Z_so8Nmg72UmRuzxQ@mail.gmail.com>

Actually I got your solution, but don't really understand what is the
purpose of this feature? Why should I use DNS? I know that HTTPS is so
important, but I can configure my realm to require HTTPS, so in the above
mentioned situation I wouldn't like to use DNS names.
So my main question is: what is the purpose of this feature?

Br,
Matyi

On 12 October 2016 at 07:48, M?ty?s Bachorecz <bachoreczm at gmail.com> wrote:

> I understand, thank you for your answer.
>
> On 12 October 2016 at 07:00, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> You can obviously use DNS settings and the machines hosts file to change
>> what IP address the name resolves to.
>>
>> https://machine.local could resolve to 10.0.0.12 or 192.168.1.12
>> depending on where it's called from.
>>
>> On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> [Adding list again]
>>>
>>> Token based security relies on HTTPS for security. You need to use the
>>> HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
>>> match the issuer of the domain.
>>>
>>> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>> wrote:
>>>
>>>> My token audience does not match, because we request for a token via
>>>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>>>> private ip (like 192.168.xx.xx). So my question is how to solve this
>>>> problem?
>>>>
>>>> There are two machines, one belongs to user, and on the other we
>>>> running keycloak, and a client, which can validate token. But client only
>>>> nows the private ip, and user can't access keycloak on private ip, cause
>>>> he/she is not in that network.
>>>>
>>>> Br,
>>>> Matyi
>>>>
>>>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Rather than hacking Keycloak you should figure out why your token
>>>>> audience doesn't match. For a token to be valid it has to been issued by
>>>>> the same server URL and realm. It's an important check and we wouldn't
>>>>> accept a feature that prevents it.
>>>>>
>>>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> we have a multi-component project, and all components running in one
>>>>>> machine, also Keycloak.
>>>>>> We would like to obtain token via curl, and our components would like
>>>>>> to
>>>>>> validate it, but they can't, because we've got:
>>>>>> "Token audience doesn't match domain. Token issuer is " +
>>>>>> token.getIssuer()
>>>>>> + ", but URL from configuration is " + realmUrl
>>>>>> (RSATokenVerifier.java)
>>>>>>
>>>>>> I would like to implement a new feature: a new checkbox or something
>>>>>> else
>>>>>> to realm settings page, which can switch off the above mentioned
>>>>>> feature.
>>>>>> I've read that I should write an email here if I would like to
>>>>>> implement
>>>>>> something. Is it ok, or how it works?
>>>>>>
>>>>>> Br,
>>>>>> Matyi
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

From wadahiro at gmail.com  Wed Oct 12 03:30:56 2016
From: wadahiro at gmail.com (Hiroyuki Wada)
Date: Wed, 12 Oct 2016 16:30:56 +0900
Subject: [keycloak-dev] How to report security problem
Message-ID: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>

Hello,

I have security concern in Keycloak server. It might be a vulnerability.
Where should I report this problem?


Regards,

--
Hiroyuki Wada,
Developer,
Nomura Research Institute, Ltd.

From thomas.darimont at googlemail.com  Wed Oct 12 03:36:07 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 12 Oct 2016 09:36:07 +0200
Subject: [keycloak-dev] How to report security problem
In-Reply-To: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
References: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
Message-ID: <CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>

Hello Hiroyuki,

Just create a new issue here https://issues.jboss.org/projects/KEYCLOAK
Mark it as Security Sensitive Issue (x) This issue is security relevant.

Cheers,
Thomas

2016-10-12 9:30 GMT+02:00 Hiroyuki Wada <wadahiro at gmail.com>:

> Hello,
>
> I have security concern in Keycloak server. It might be a vulnerability.
> Where should I report this problem?
>
>
> Regards,
>
> --
> Hiroyuki Wada,
> Developer,
> Nomura Research Institute, Ltd.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From to.petrovski at gmail.com  Wed Oct 12 03:51:56 2016
From: to.petrovski at gmail.com (Nikolay Petrovski)
Date: Wed, 12 Oct 2016 10:51:56 +0300
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
Message-ID: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>

Hello, I would like to start working on
https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
X-headers for the outbound emails that Keycloak is sending.

From thomas.darimont at googlemail.com  Wed Oct 12 03:54:50 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 12 Oct 2016 09:54:50 +0200
Subject: [keycloak-dev] How to report security problem
In-Reply-To: <CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
References: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
	<CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
Message-ID: <CAK-7U1g09S6ANHZGHmhr3grzmdmp7JZj5oh6Db=W-d4-=8hBKg@mail.gmail.com>

Hello,

just a quick follow-up IIRC there was also a link with something like
"Found a Security issue? report it here" on the keycloak.org
website a while ago - might also have been the website of the Red Hat SSO
product. Anyways keycloak.org should have a
more visible link / section with details about reporting security issues.

Cheers,
Thomas

2016-10-12 9:36 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello Hiroyuki,
>
> Just create a new issue here https://issues.jboss.org/projects/KEYCLOAK
> Mark it as Security Sensitive Issue (x) This issue is security relevant.
>
> Cheers,
> Thomas
>
> 2016-10-12 9:30 GMT+02:00 Hiroyuki Wada <wadahiro at gmail.com>:
>
>> Hello,
>>
>> I have security concern in Keycloak server. It might be a vulnerability.
>> Where should I report this problem?
>>
>>
>> Regards,
>>
>> --
>> Hiroyuki Wada,
>> Developer,
>> Nomura Research Institute, Ltd.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From wadahiro at gmail.com  Wed Oct 12 04:01:13 2016
From: wadahiro at gmail.com (Hiroyuki Wada)
Date: Wed, 12 Oct 2016 17:01:13 +0900
Subject: [keycloak-dev] How to report security problem
In-Reply-To: <CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
References: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
	<CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
Message-ID: <CAPq3NeETXKn4u1ZtG8_JxVedEQbbfHOb4WpODTCmBpB-85uZ8w@mail.gmail.com>

Hello Thomas,

Thanks for your quick reply.
I'll create a jira ticket soon.



On Wed, Oct 12, 2016 at 4:36 PM, Thomas Darimont
<thomas.darimont at googlemail.com> wrote:
> Hello Hiroyuki,
>
> Just create a new issue here https://issues.jboss.org/projects/KEYCLOAK
> Mark it as Security Sensitive Issue (x) This issue is security relevant.
>
> Cheers,
> Thomas
>
> 2016-10-12 9:30 GMT+02:00 Hiroyuki Wada <wadahiro at gmail.com>:
>>
>> Hello,
>>
>> I have security concern in Keycloak server. It might be a vulnerability.
>> Where should I report this problem?
>>
>>
>> Regards,
>>
>> --
>> Hiroyuki Wada,
>> Developer,
>> Nomura Research Institute, Ltd.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

From sthorger at redhat.com  Wed Oct 12 07:45:44 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 13:45:44 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAGTR_ERKJhg-_+rE9VbmC5Mbfd638gmC8Z_so8Nmg72UmRuzxQ@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
	<CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
	<CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>
	<CAGTR_ERKJhg-_+rE9VbmC5Mbfd638gmC8Z_so8Nmg72UmRuzxQ@mail.gmail.com>
Message-ID: <CAJgngAevyGrBP8xXt4KxU5+6Oc=gSRvEHDOkGqx496kHngP6xw@mail.gmail.com>

I'm not sure what you are asking.

On 12 October 2016 at 08:28, M?ty?s Bachorecz <bachoreczm at gmail.com> wrote:

> Actually I got your solution, but don't really understand what is the
> purpose of this feature? Why should I use DNS? I know that HTTPS is so
> important, but I can configure my realm to require HTTPS, so in the above
> mentioned situation I wouldn't like to use DNS names.
> So my main question is: what is the purpose of this feature?
>
> Br,
> Matyi
>
> On 12 October 2016 at 07:48, M?ty?s Bachorecz <bachoreczm at gmail.com>
> wrote:
>
>> I understand, thank you for your answer.
>>
>> On 12 October 2016 at 07:00, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> You can obviously use DNS settings and the machines hosts file to change
>>> what IP address the name resolves to.
>>>
>>> https://machine.local could resolve to 10.0.0.12 or 192.168.1.12
>>> depending on where it's called from.
>>>
>>> On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> [Adding list again]
>>>>
>>>> Token based security relies on HTTPS for security. You need to use the
>>>> HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
>>>> match the issuer of the domain.
>>>>
>>>> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>> wrote:
>>>>
>>>>> My token audience does not match, because we request for a token via
>>>>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>>>>> private ip (like 192.168.xx.xx). So my question is how to solve this
>>>>> problem?
>>>>>
>>>>> There are two machines, one belongs to user, and on the other we
>>>>> running keycloak, and a client, which can validate token. But client only
>>>>> nows the private ip, and user can't access keycloak on private ip, cause
>>>>> he/she is not in that network.
>>>>>
>>>>> Br,
>>>>> Matyi
>>>>>
>>>>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Rather than hacking Keycloak you should figure out why your token
>>>>>> audience doesn't match. For a token to be valid it has to been issued by
>>>>>> the same server URL and realm. It's an important check and we wouldn't
>>>>>> accept a feature that prevents it.
>>>>>>
>>>>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> we have a multi-component project, and all components running in one
>>>>>>> machine, also Keycloak.
>>>>>>> We would like to obtain token via curl, and our components would
>>>>>>> like to
>>>>>>> validate it, but they can't, because we've got:
>>>>>>> "Token audience doesn't match domain. Token issuer is " +
>>>>>>> token.getIssuer()
>>>>>>> + ", but URL from configuration is " + realmUrl
>>>>>>> (RSATokenVerifier.java)
>>>>>>>
>>>>>>> I would like to implement a new feature: a new checkbox or something
>>>>>>> else
>>>>>>> to realm settings page, which can switch off the above mentioned
>>>>>>> feature.
>>>>>>> I've read that I should write an email here if I would like to
>>>>>>> implement
>>>>>>> something. Is it ok, or how it works?
>>>>>>>
>>>>>>> Br,
>>>>>>> Matyi
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sthorger at redhat.com  Wed Oct 12 07:46:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 13:46:45 +0200
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
Message-ID: <CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>

I'm not convinced this is needed. What's the actual use-case?

You could also just extend the built-in email sender and add the headers
there.

On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski at gmail.com>
wrote:

> Hello, I would like to start working on
> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
> X-headers for the outbound emails that Keycloak is sending.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bachoreczm at gmail.com  Wed Oct 12 08:00:26 2016
From: bachoreczm at gmail.com (=?UTF-8?B?TcOhdHnDoXMgQmFjaG9yZWN6?=)
Date: Wed, 12 Oct 2016 14:00:26 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAJgngAevyGrBP8xXt4KxU5+6Oc=gSRvEHDOkGqx496kHngP6xw@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
	<CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
	<CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>
	<CAGTR_ERKJhg-_+rE9VbmC5Mbfd638gmC8Z_so8Nmg72UmRuzxQ@mail.gmail.com>
	<CAJgngAevyGrBP8xXt4KxU5+6Oc=gSRvEHDOkGqx496kHngP6xw@mail.gmail.com>
Message-ID: <CAGTR_ER4prsyPv0LShc50mW8Dnz+abCESOWQvyJ_f-+iTqTPnw@mail.gmail.com>

You wrote, that:
"You need to use the HTTPs domain name when you are contacting Keycloak." -
I'm just asking why? Why can't I use e.g.
https://10.xx.xx.xx:<keycloak_port>/auth/....?
Why do I have to use DNS name?

Br,
M

On 12 October 2016 at 13:45, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'm not sure what you are asking.
>
> On 12 October 2016 at 08:28, M?ty?s Bachorecz <bachoreczm at gmail.com>
> wrote:
>
>> Actually I got your solution, but don't really understand what is the
>> purpose of this feature? Why should I use DNS? I know that HTTPS is so
>> important, but I can configure my realm to require HTTPS, so in the above
>> mentioned situation I wouldn't like to use DNS names.
>> So my main question is: what is the purpose of this feature?
>>
>> Br,
>> Matyi
>>
>> On 12 October 2016 at 07:48, M?ty?s Bachorecz <bachoreczm at gmail.com>
>> wrote:
>>
>>> I understand, thank you for your answer.
>>>
>>> On 12 October 2016 at 07:00, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> You can obviously use DNS settings and the machines hosts file to
>>>> change what IP address the name resolves to.
>>>>
>>>> https://machine.local could resolve to 10.0.0.12 or 192.168.1.12
>>>> depending on where it's called from.
>>>>
>>>> On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> [Adding list again]
>>>>>
>>>>> Token based security relies on HTTPS for security. You need to use the
>>>>> HTTPs domain name when you are contacting Keycloak. The HTTPs domain should
>>>>> match the issuer of the domain.
>>>>>
>>>>> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> My token audience does not match, because we request for a token via
>>>>>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>>>>>> private ip (like 192.168.xx.xx). So my question is how to solve this
>>>>>> problem?
>>>>>>
>>>>>> There are two machines, one belongs to user, and on the other we
>>>>>> running keycloak, and a client, which can validate token. But client only
>>>>>> nows the private ip, and user can't access keycloak on private ip, cause
>>>>>> he/she is not in that network.
>>>>>>
>>>>>> Br,
>>>>>> Matyi
>>>>>>
>>>>>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Rather than hacking Keycloak you should figure out why your token
>>>>>>> audience doesn't match. For a token to be valid it has to been issued by
>>>>>>> the same server URL and realm. It's an important check and we wouldn't
>>>>>>> accept a feature that prevents it.
>>>>>>>
>>>>>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> we have a multi-component project, and all components running in one
>>>>>>>> machine, also Keycloak.
>>>>>>>> We would like to obtain token via curl, and our components would
>>>>>>>> like to
>>>>>>>> validate it, but they can't, because we've got:
>>>>>>>> "Token audience doesn't match domain. Token issuer is " +
>>>>>>>> token.getIssuer()
>>>>>>>> + ", but URL from configuration is " + realmUrl
>>>>>>>> (RSATokenVerifier.java)
>>>>>>>>
>>>>>>>> I would like to implement a new feature: a new checkbox or
>>>>>>>> something else
>>>>>>>> to realm settings page, which can switch off the above mentioned
>>>>>>>> feature.
>>>>>>>> I've read that I should write an email here if I would like to
>>>>>>>> implement
>>>>>>>> something. Is it ok, or how it works?
>>>>>>>>
>>>>>>>> Br,
>>>>>>>> Matyi
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From to.petrovski at gmail.com  Wed Oct 12 08:17:29 2016
From: to.petrovski at gmail.com (Nikolay Petrovski)
Date: Wed, 12 Oct 2016 15:17:29 +0300
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
Message-ID: <CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>

Adding keycloak-dev

On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <to.petrovski at gmail.com>
wrote:

> Well, the use-case I reached is based on the fact that I rule 2 different
> Keycloak environments (lets call them "prod" and "test") from the same
> subnet + 1 Mail server on top.
>
> All emails are received from one and the same IP address, and in the Mail
> Server I have to figure out which Keycloak has sent the email so a specific
> rule will be applied (quarantine the emails from the "test" server for
> instance).
>
> Any idea how to distinguish emails sent from different Keycloak instances
> without using a custom email headers?
>
>
>
> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> I'm not convinced this is needed. What's the actual use-case?
>>
>> You could also just extend the built-in email sender and add the headers
>> there.
>>
>> On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski at gmail.com>
>> wrote:
>>
>>> Hello, I would like to start working on
>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>> X-headers for the outbound emails that Keycloak is sending.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From sthorger at redhat.com  Wed Oct 12 08:34:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 14:34:55 +0200
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
Message-ID: <CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>

Could you not just set the from email differently and filter based on that?

On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com>
wrote:

> Adding keycloak-dev
>
>
> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <to.petrovski at gmail.com
> > wrote:
>
>> Well, the use-case I reached is based on the fact that I rule 2 different
>> Keycloak environments (lets call them "prod" and "test") from the same
>> subnet + 1 Mail server on top.
>>
>> All emails are received from one and the same IP address, and in the Mail
>> Server I have to figure out which Keycloak has sent the email so a specific
>> rule will be applied (quarantine the emails from the "test" server for
>> instance).
>>
>> Any idea how to distinguish emails sent from different Keycloak instances
>> without using a custom email headers?
>>
>>
>>
>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> I'm not convinced this is needed. What's the actual use-case?
>>>
>>> You could also just extend the built-in email sender and add the headers
>>> there.
>>>
>>> On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski at gmail.com>
>>> wrote:
>>>
>>>> Hello, I would like to start working on
>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>>> X-headers for the outbound emails that Keycloak is sending.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>

From sthorger at redhat.com  Wed Oct 12 08:36:44 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 14:36:44 +0200
Subject: [keycloak-dev] feature request
In-Reply-To: <CAGTR_ER4prsyPv0LShc50mW8Dnz+abCESOWQvyJ_f-+iTqTPnw@mail.gmail.com>
References: <CAGTR_EQnM3toFF_gEVzc5Ep0E0ykB7_eEzH-0ZOYm=0jk_6JEQ@mail.gmail.com>
	<CAJgngAdbD5LHHY+to9+pT4L1bCk0=wLV_KXWrw2EWmM9yvofTg@mail.gmail.com>
	<CAGTR_ESRnDa-T+FY3WEqD3LkWRz39Kg8hf0CeOsoPV176ZTx_Q@mail.gmail.com>
	<CAJgngAefMibe7WF5JtAenr7oDKLvEdy76NyrNs9Kv3N=Xi-k4w@mail.gmail.com>
	<CAJgngAcNEH2wC7_mbz9ia09p4vkm5Gue7rQw8bCCc8Y+bTj1Qg@mail.gmail.com>
	<CAGTR_ERtfZkZwRQO965__f2MiosshJN-LediO_jRdFTjPdtvew@mail.gmail.com>
	<CAGTR_ERKJhg-_+rE9VbmC5Mbfd638gmC8Z_so8Nmg72UmRuzxQ@mail.gmail.com>
	<CAJgngAevyGrBP8xXt4KxU5+6Oc=gSRvEHDOkGqx496kHngP6xw@mail.gmail.com>
	<CAGTR_ER4prsyPv0LShc50mW8Dnz+abCESOWQvyJ_f-+iTqTPnw@mail.gmail.com>
Message-ID: <CAJgngAfya+o6ppeeRWg00MbAWsy7Lob+AwQbYydnCmPaxfXcGg@mail.gmail.com>

Sure, you could use a certificated issued to an IP address. However, in
that case all nodes would have to use the same IP address. If you use a
hostname you can have different machines use different IP addresses based
on different dns servers or settings in hosts file.

On 12 October 2016 at 14:00, M?ty?s Bachorecz <bachoreczm at gmail.com> wrote:

> You wrote, that:
> "You need to use the HTTPs domain name when you are contacting Keycloak."
> - I'm just asking why? Why can't I use e.g. https://10.xx.xx.xx:<keycloak_port>/auth/....?
> Why do I have to use DNS name?
>
> Br,
> M
>
> On 12 October 2016 at 13:45, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> I'm not sure what you are asking.
>>
>> On 12 October 2016 at 08:28, M?ty?s Bachorecz <bachoreczm at gmail.com>
>> wrote:
>>
>>> Actually I got your solution, but don't really understand what is the
>>> purpose of this feature? Why should I use DNS? I know that HTTPS is so
>>> important, but I can configure my realm to require HTTPS, so in the above
>>> mentioned situation I wouldn't like to use DNS names.
>>> So my main question is: what is the purpose of this feature?
>>>
>>> Br,
>>> Matyi
>>>
>>> On 12 October 2016 at 07:48, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>> wrote:
>>>
>>>> I understand, thank you for your answer.
>>>>
>>>> On 12 October 2016 at 07:00, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> You can obviously use DNS settings and the machines hosts file to
>>>>> change what IP address the name resolves to.
>>>>>
>>>>> https://machine.local could resolve to 10.0.0.12 or 192.168.1.12
>>>>> depending on where it's called from.
>>>>>
>>>>> On 12 October 2016 at 06:59, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> [Adding list again]
>>>>>>
>>>>>> Token based security relies on HTTPS for security. You need to use
>>>>>> the HTTPs domain name when you are contacting Keycloak. The HTTPs domain
>>>>>> should match the issuer of the domain.
>>>>>>
>>>>>> On 11 October 2016 at 18:56, M?ty?s Bachorecz <bachoreczm at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> My token audience does not match, because we request for a token via
>>>>>>> floating ip (openstack, like 10.xx.xx.xx), and would like to validate via
>>>>>>> private ip (like 192.168.xx.xx). So my question is how to solve this
>>>>>>> problem?
>>>>>>>
>>>>>>> There are two machines, one belongs to user, and on the other we
>>>>>>> running keycloak, and a client, which can validate token. But client only
>>>>>>> nows the private ip, and user can't access keycloak on private ip, cause
>>>>>>> he/she is not in that network.
>>>>>>>
>>>>>>> Br,
>>>>>>> Matyi
>>>>>>>
>>>>>>> On 11 October 2016 at 18:45, Stian Thorgersen <sthorger at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Rather than hacking Keycloak you should figure out why your token
>>>>>>>> audience doesn't match. For a token to be valid it has to been issued by
>>>>>>>> the same server URL and realm. It's an important check and we wouldn't
>>>>>>>> accept a feature that prevents it.
>>>>>>>>
>>>>>>>> On 11 October 2016 at 17:07, M?ty?s Bachorecz <bachoreczm at gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> we have a multi-component project, and all components running in
>>>>>>>>> one
>>>>>>>>> machine, also Keycloak.
>>>>>>>>> We would like to obtain token via curl, and our components would
>>>>>>>>> like to
>>>>>>>>> validate it, but they can't, because we've got:
>>>>>>>>> "Token audience doesn't match domain. Token issuer is " +
>>>>>>>>> token.getIssuer()
>>>>>>>>> + ", but URL from configuration is " + realmUrl
>>>>>>>>> (RSATokenVerifier.java)
>>>>>>>>>
>>>>>>>>> I would like to implement a new feature: a new checkbox or
>>>>>>>>> something else
>>>>>>>>> to realm settings page, which can switch off the above mentioned
>>>>>>>>> feature.
>>>>>>>>> I've read that I should write an email here if I would like to
>>>>>>>>> implement
>>>>>>>>> something. Is it ok, or how it works?
>>>>>>>>>
>>>>>>>>> Br,
>>>>>>>>> Matyi
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From to.petrovski at gmail.com  Wed Oct 12 08:42:26 2016
From: to.petrovski at gmail.com (Nikolay Petrovski)
Date: Wed, 12 Oct 2016 15:42:26 +0300
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
	<CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
Message-ID: <CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>

Unfortunately the automated delivery process here does not allow me to
set-up a different "From" address. I can try to extend the default email
sender provider and add the custom headers there, although I believe having
and option to set-up X headers could be really handy for the product.

On Wed, Oct 12, 2016 at 3:34 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Could you not just set the from email differently and filter based on that?
>
> On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com>
> wrote:
>
>> Adding keycloak-dev
>>
>>
>> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <
>> to.petrovski at gmail.com> wrote:
>>
>>> Well, the use-case I reached is based on the fact that I rule 2
>>> different Keycloak environments (lets call them "prod" and "test") from the
>>> same subnet + 1 Mail server on top.
>>>
>>> All emails are received from one and the same IP address, and in the
>>> Mail Server I have to figure out which Keycloak has sent the email so a
>>> specific rule will be applied (quarantine the emails from the "test" server
>>> for instance).
>>>
>>> Any idea how to distinguish emails sent from different Keycloak
>>> instances without using a custom email headers?
>>>
>>>
>>>
>>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> I'm not convinced this is needed. What's the actual use-case?
>>>>
>>>> You could also just extend the built-in email sender and add the
>>>> headers there.
>>>>
>>>> On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello, I would like to start working on
>>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>>>> X-headers for the outbound emails that Keycloak is sending.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From sthorger at redhat.com  Wed Oct 12 08:45:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 14:45:28 +0200
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
	<CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
	<CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>
Message-ID: <CAJgngAdNbeN-M6fEoKFLrygH5xTKM0xPfmsjfFUkX-sBvvg7eQ@mail.gmail.com>

Would you not need different realm settings in either case? To set the
different values for the email headers?

On 12 October 2016 at 14:42, Nikolay Petrovski <to.petrovski at gmail.com>
wrote:

> Unfortunately the automated delivery process here does not allow me to
> set-up a different "From" address. I can try to extend the default email
> sender provider and add the custom headers there, although I believe having
> and option to set-up X headers could be really handy for the product.
>
> On Wed, Oct 12, 2016 at 3:34 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Could you not just set the from email differently and filter based on
>> that?
>>
>> On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com>
>> wrote:
>>
>>> Adding keycloak-dev
>>>
>>>
>>> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <
>>> to.petrovski at gmail.com> wrote:
>>>
>>>> Well, the use-case I reached is based on the fact that I rule 2
>>>> different Keycloak environments (lets call them "prod" and "test") from the
>>>> same subnet + 1 Mail server on top.
>>>>
>>>> All emails are received from one and the same IP address, and in the
>>>> Mail Server I have to figure out which Keycloak has sent the email so a
>>>> specific rule will be applied (quarantine the emails from the "test" server
>>>> for instance).
>>>>
>>>> Any idea how to distinguish emails sent from different Keycloak
>>>> instances without using a custom email headers?
>>>>
>>>>
>>>>
>>>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> I'm not convinced this is needed. What's the actual use-case?
>>>>>
>>>>> You could also just extend the built-in email sender and add the
>>>>> headers there.
>>>>>
>>>>> On 12 October 2016 at 09:51, Nikolay Petrovski <to.petrovski at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Hello, I would like to start working on
>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>>>>> X-headers for the outbound emails that Keycloak is sending.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

From to.petrovski at gmail.com  Wed Oct 12 09:01:35 2016
From: to.petrovski at gmail.com (Nikolay Petrovski)
Date: Wed, 12 Oct 2016 16:01:35 +0300
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAJgngAdNbeN-M6fEoKFLrygH5xTKM0xPfmsjfFUkX-sBvvg7eQ@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
	<CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
	<CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>
	<CAJgngAdNbeN-M6fEoKFLrygH5xTKM0xPfmsjfFUkX-sBvvg7eQ@mail.gmail.com>
Message-ID: <CAKRr-7ZgBK7sgxy-kJqG_j8S++tgHreyxkjg_zX+f1kZpf+fiA@mail.gmail.com>

This is correct - I use slightly different realm settings with both
environments and I can pass different "from" addresses the same way I would
pass the custom headers. The constraint here is the Mail Server in front,
where I must use a specific From address, but I guess this case concerns
only me. If you believe having this feature (adding custom email headers)
is unnecessary for the product I will not spend time in developing it and
will close the ticket.


On Wed, Oct 12, 2016 at 3:45 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Would you not need different realm settings in either case? To set the
> different values for the email headers?
>
> On 12 October 2016 at 14:42, Nikolay Petrovski <to.petrovski at gmail.com>
> wrote:
>
>> Unfortunately the automated delivery process here does not allow me to
>> set-up a different "From" address. I can try to extend the default email
>> sender provider and add the custom headers there, although I believe having
>> and option to set-up X headers could be really handy for the product.
>>
>> On Wed, Oct 12, 2016 at 3:34 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Could you not just set the from email differently and filter based on
>>> that?
>>>
>>> On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com>
>>> wrote:
>>>
>>>> Adding keycloak-dev
>>>>
>>>>
>>>> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <
>>>> to.petrovski at gmail.com> wrote:
>>>>
>>>>> Well, the use-case I reached is based on the fact that I rule 2
>>>>> different Keycloak environments (lets call them "prod" and "test") from the
>>>>> same subnet + 1 Mail server on top.
>>>>>
>>>>> All emails are received from one and the same IP address, and in the
>>>>> Mail Server I have to figure out which Keycloak has sent the email so a
>>>>> specific rule will be applied (quarantine the emails from the "test" server
>>>>> for instance).
>>>>>
>>>>> Any idea how to distinguish emails sent from different Keycloak
>>>>> instances without using a custom email headers?
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <sthorger at redhat.com
>>>>> > wrote:
>>>>>
>>>>>> I'm not convinced this is needed. What's the actual use-case?
>>>>>>
>>>>>> You could also just extend the built-in email sender and add the
>>>>>> headers there.
>>>>>>
>>>>>> On 12 October 2016 at 09:51, Nikolay Petrovski <
>>>>>> to.petrovski at gmail.com> wrote:
>>>>>>
>>>>>>> Hello, I would like to start working on
>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>>>>>> X-headers for the outbound emails that Keycloak is sending.
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From sthorger at redhat.com  Wed Oct 12 09:45:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 12 Oct 2016 15:45:11 +0200
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAKRr-7ZgBK7sgxy-kJqG_j8S++tgHreyxkjg_zX+f1kZpf+fiA@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
	<CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
	<CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>
	<CAJgngAdNbeN-M6fEoKFLrygH5xTKM0xPfmsjfFUkX-sBvvg7eQ@mail.gmail.com>
	<CAKRr-7ZgBK7sgxy-kJqG_j8S++tgHreyxkjg_zX+f1kZpf+fiA@mail.gmail.com>
Message-ID: <CAJgngAd_uGOO92X6ukXAjxeLLckTkr1LXaD2ZwWQ3fZzFmsdvA@mail.gmail.com>

We've not had anyone else request it and it does seem like a special case.
So if you're happy with closing the issue and doing it with a custom
provider that's probably best.

On 12 October 2016 at 15:01, Nikolay Petrovski <to.petrovski at gmail.com>
wrote:

> This is correct - I use slightly different realm settings with both
> environments and I can pass different "from" addresses the same way I would
> pass the custom headers. The constraint here is the Mail Server in front,
> where I must use a specific From address, but I guess this case concerns
> only me. If you believe having this feature (adding custom email headers)
> is unnecessary for the product I will not spend time in developing it and
> will close the ticket.
>
>
> On Wed, Oct 12, 2016 at 3:45 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Would you not need different realm settings in either case? To set the
>> different values for the email headers?
>>
>> On 12 October 2016 at 14:42, Nikolay Petrovski <to.petrovski at gmail.com>
>> wrote:
>>
>>> Unfortunately the automated delivery process here does not allow me to
>>> set-up a different "From" address. I can try to extend the default email
>>> sender provider and add the custom headers there, although I believe having
>>> and option to set-up X headers could be really handy for the product.
>>>
>>> On Wed, Oct 12, 2016 at 3:34 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> Could you not just set the from email differently and filter based on
>>>> that?
>>>>
>>>> On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com>
>>>> wrote:
>>>>
>>>>> Adding keycloak-dev
>>>>>
>>>>>
>>>>> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <
>>>>> to.petrovski at gmail.com> wrote:
>>>>>
>>>>>> Well, the use-case I reached is based on the fact that I rule 2
>>>>>> different Keycloak environments (lets call them "prod" and "test") from the
>>>>>> same subnet + 1 Mail server on top.
>>>>>>
>>>>>> All emails are received from one and the same IP address, and in the
>>>>>> Mail Server I have to figure out which Keycloak has sent the email so a
>>>>>> specific rule will be applied (quarantine the emails from the "test" server
>>>>>> for instance).
>>>>>>
>>>>>> Any idea how to distinguish emails sent from different Keycloak
>>>>>> instances without using a custom email headers?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> I'm not convinced this is needed. What's the actual use-case?
>>>>>>>
>>>>>>> You could also just extend the built-in email sender and add the
>>>>>>> headers there.
>>>>>>>
>>>>>>> On 12 October 2016 at 09:51, Nikolay Petrovski <
>>>>>>> to.petrovski at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello, I would like to start working on
>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing custom
>>>>>>>> X-headers for the outbound emails that Keycloak is sending.
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From to.petrovski at gmail.com  Wed Oct 12 09:51:25 2016
From: to.petrovski at gmail.com (Nikolay Petrovski)
Date: Wed, 12 Oct 2016 16:51:25 +0300
Subject: [keycloak-dev] Email custom header: KEYCLOAK-3605
In-Reply-To: <CAJgngAd_uGOO92X6ukXAjxeLLckTkr1LXaD2ZwWQ3fZzFmsdvA@mail.gmail.com>
References: <CAKRr-7YpLE8fYT7qCSBP7L5JscmNsGW=BHf0PGqFvwjs2H6-kA@mail.gmail.com>
	<CAJgngAevB3=GA8=yPduH_J9_UQbxGw6VyH2QNXq22xvko8Wbyg@mail.gmail.com>
	<CAKRr-7ZPFvTpdyMJ8pZdqUHPswfzAMDdHazFym49WabR7hzfSw@mail.gmail.com>
	<CAKRr-7ZH8zHJ6LsjPixOBRJ9JOW_djBtiTWsR4z89u9NX9qg5w@mail.gmail.com>
	<CAJgngAdfbv8DQZxaBXVYKdK=nU8HeVrzAmT-WZOoDGOQCoUz7A@mail.gmail.com>
	<CAKRr-7YHWSbs7H-je8EYFoxv4h2k3t0-s8MERpbSLi8Bpbn4mw@mail.gmail.com>
	<CAJgngAdNbeN-M6fEoKFLrygH5xTKM0xPfmsjfFUkX-sBvvg7eQ@mail.gmail.com>
	<CAKRr-7ZgBK7sgxy-kJqG_j8S++tgHreyxkjg_zX+f1kZpf+fiA@mail.gmail.com>
	<CAJgngAd_uGOO92X6ukXAjxeLLckTkr1LXaD2ZwWQ3fZzFmsdvA@mail.gmail.com>
Message-ID: <CAKRr-7YfpRnjdVi7zcM3FS+SxtzkVubM03KvORsuhT+Tk+pGpg@mail.gmail.com>

Thanks.

On Wed, Oct 12, 2016 at 4:45 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We've not had anyone else request it and it does seem like a special case.
> So if you're happy with closing the issue and doing it with a custom
> provider that's probably best.
>
> On 12 October 2016 at 15:01, Nikolay Petrovski <to.petrovski at gmail.com>
> wrote:
>
>> This is correct - I use slightly different realm settings with both
>> environments and I can pass different "from" addresses the same way I would
>> pass the custom headers. The constraint here is the Mail Server in front,
>> where I must use a specific From address, but I guess this case concerns
>> only me. If you believe having this feature (adding custom email headers)
>> is unnecessary for the product I will not spend time in developing it and
>> will close the ticket.
>>
>>
>> On Wed, Oct 12, 2016 at 3:45 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> Would you not need different realm settings in either case? To set the
>>> different values for the email headers?
>>>
>>> On 12 October 2016 at 14:42, Nikolay Petrovski <to.petrovski at gmail.com>
>>> wrote:
>>>
>>>> Unfortunately the automated delivery process here does not allow me to
>>>> set-up a different "From" address. I can try to extend the default email
>>>> sender provider and add the custom headers there, although I believe having
>>>> and option to set-up X headers could be really handy for the product.
>>>>
>>>> On Wed, Oct 12, 2016 at 3:34 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> Could you not just set the from email differently and filter based on
>>>>> that?
>>>>>
>>>>> On 12 October 2016 at 14:17, Nikolay Petrovski <to.petrovski at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Adding keycloak-dev
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 12, 2016 at 3:13 PM, Nikolay Petrovski <
>>>>>> to.petrovski at gmail.com> wrote:
>>>>>>
>>>>>>> Well, the use-case I reached is based on the fact that I rule 2
>>>>>>> different Keycloak environments (lets call them "prod" and "test") from the
>>>>>>> same subnet + 1 Mail server on top.
>>>>>>>
>>>>>>> All emails are received from one and the same IP address, and in the
>>>>>>> Mail Server I have to figure out which Keycloak has sent the email so a
>>>>>>> specific rule will be applied (quarantine the emails from the "test" server
>>>>>>> for instance).
>>>>>>>
>>>>>>> Any idea how to distinguish emails sent from different Keycloak
>>>>>>> instances without using a custom email headers?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Oct 12, 2016 at 2:46 PM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> I'm not convinced this is needed. What's the actual use-case?
>>>>>>>>
>>>>>>>> You could also just extend the built-in email sender and add the
>>>>>>>> headers there.
>>>>>>>>
>>>>>>>> On 12 October 2016 at 09:51, Nikolay Petrovski <
>>>>>>>> to.petrovski at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hello, I would like to start working on
>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-3605 - implementing
>>>>>>>>> custom
>>>>>>>>> X-headers for the outbound emails that Keycloak is sending.
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

From tom.cerny at gmail.com  Wed Oct 12 15:39:06 2016
From: tom.cerny at gmail.com (Tomas Cerny)
Date: Wed, 12 Oct 2016 21:39:06 +0200
Subject: [keycloak-dev] Scope Param with Keycloak
In-Reply-To: <CAJgngAcL5A=E=0f3yKZqt7CRhFTRT1LL=xLUJZhMv++409KgjA@mail.gmail.com>
References: <CAFjvcK4zzc-ubWeBiugRmeGwSRxqgt-vE7UankP6M7=aPCWoug@mail.gmail.com>
	<CAJgngAcL5A=E=0f3yKZqt7CRhFTRT1LL=xLUJZhMv++409KgjA@mail.gmail.com>
Message-ID: <CAFjvcK6BPLRCJjb=+n1VQpcpmsgqquWKSyYo68Av4OXZEA28Dg@mail.gmail.com>

Hello,

is there any update on the scope param (below)? Regarding to the protocol
mappers (a param to pass) is there any good sample to start with, or a
reference to look over?

Thank you, Tomas

On Tue, Oct 6, 2015 at 10:11 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> We do not currently support scope param and this is something we plan to
> add in the future. We do have protocol mappers that you can use to add any
> additional claims to the token for a client.
>
> On 5 October 2015 at 21:49, Tomas Cerny <tom.cerny at gmail.com> wrote:
>
>> Hi all,
>>
>>
>>
>> I am trying to use the scope param with keycloak, which is part of the
>> open id
>>
>> http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>
>> Here is an sample URL (from https://openid.net/
>> specs/openid-connect-basic-1_0.html#AuthenticationRequest )
>>
>>
>>
>> Which is
>>
>> https://server.example.com/authorize?
>>
>>   response_type=code
>>
>>   &client_id=s6BhdRkqt3
>>
>>   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
>>
>>   &scope=openid%20profile
>>
>>   &state=af0ifjsldkj
>>
>>
>>
>> note the state param there
>>
>> with keycloak this is my auth URL: http://127.0.0.1:8080/
>> auth/realms/example/protocol/openid-connect/auth?client_id=
>> js-console&redirect_uri=http://127.0.0.1:8080/js-console/&
>> state=4bb976a4-ad5f-4af5-955d-1b2bdfb738df&response_type=code
>>
>>
>>
>> When I pass scope param, then it is ignored.
>>
>>
>>
>> Does keycloak support scope param? Can I intercept it to make a custom
>> handler? (e.g. lookup DB data)
>>
>>
>>
>> Sample Use Case: Keycloak has my custom UserFederation provides where I
>> issue user lookup to my SQL DB, and determine access, next basing on the
>> scope I like to post back to the app roles relevant to the scope param.
>>
>>
>>
>> I know keycloak has static roles, but I need it contextual, such as -
>> user is master in scope = A, but reader in scope = B. Since the range of
>> scopes is dynamic and large, the use of client-ids is not sufficient.
>>
>>
>>
>> I assume the scope can help me solving situation such as am I owned of an
>> object?
>>
>>
>>
>> I did days of debugging keycloak code and cannot find much even thought
>> there is OAuth2Constants.Scope but may be that is something different?
>>
>>
>>
>> and I seem some dead sample here: FishEye: changeset
>> d309fab8251d95f50f94c77e4d08e6e8c2977994
>> <https://source.jboss.org/changelog/Keycloak?cs=d309fab8251d95f50f94c77e4d08e6e8c2977994>
>>
>>
>>
>>
>>
>> The alternative OpenAM supports scope param it - OpenAM Project - About
>> OpenAM <http://openam.forgerock.org/>
>>
>>
>>
>> Thanks, Tom
>>
>> Here a forum public users.
>> https://developer.jboss.org/message/934762#934762
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From postmaster at lists.jboss.org  Thu Oct 13 03:04:48 2016
From: postmaster at lists.jboss.org (Bounced mail)
Date: Thu, 13 Oct 2016 12:34:48 +0530
Subject: [keycloak-dev] Returned mail: see transcript for details
Message-ID: <201610130704.u9D74HiS015076@lists01.dmz-a.mwc.hst.phx2.redhat.com>




From sthorger at redhat.com  Thu Oct 13 09:44:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Oct 2016 15:44:43 +0200
Subject: [keycloak-dev] Use non-XA datasource
Message-ID: <CAJgngAehjzqMycBL0KXWdM4h8m9mmswJLj9QApMPKPgWD9RiFQ@mail.gmail.com>

IMO we should not make KeycloakDS XA by default. Rather, the docs for the
user federation provider should state that if you add another datasource
you need to make that one XA.

From wadahiro at gmail.com  Thu Oct 13 10:09:06 2016
From: wadahiro at gmail.com (Hiroyuki Wada)
Date: Thu, 13 Oct 2016 23:09:06 +0900
Subject: [keycloak-dev] How to report security problem
In-Reply-To: <CAPq3NeETXKn4u1ZtG8_JxVedEQbbfHOb4WpODTCmBpB-85uZ8w@mail.gmail.com>
References: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
	<CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
	<CAPq3NeETXKn4u1ZtG8_JxVedEQbbfHOb4WpODTCmBpB-85uZ8w@mail.gmail.com>
Message-ID: <CAPq3NeHx9sT49+mBMuiKr1BMBxh=rWsqUswXC_aek05gBV8OTg@mail.gmail.com>

Hello,

I created the security issue yesterday.

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

Can only core members see the ticket?
I wrote reproduce steps too. Please check the issue.

Regards,

--
Hiroyuki Wada

On Wed, Oct 12, 2016 at 5:01 PM, Hiroyuki Wada <wadahiro at gmail.com> wrote:
> Hello Thomas,
>
> Thanks for your quick reply.
> I'll create a jira ticket soon.
>
>
>
> On Wed, Oct 12, 2016 at 4:36 PM, Thomas Darimont
> <thomas.darimont at googlemail.com> wrote:
>> Hello Hiroyuki,
>>
>> Just create a new issue here https://issues.jboss.org/projects/KEYCLOAK
>> Mark it as Security Sensitive Issue (x) This issue is security relevant.
>>
>> Cheers,
>> Thomas
>>
>> 2016-10-12 9:30 GMT+02:00 Hiroyuki Wada <wadahiro at gmail.com>:
>>>
>>> Hello,
>>>
>>> I have security concern in Keycloak server. It might be a vulnerability.
>>> Where should I report this problem?
>>>
>>>
>>> Regards,
>>>
>>> --
>>> Hiroyuki Wada,
>>> Developer,
>>> Nomura Research Institute, Ltd.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>

From mauriciogiacomini at hotmail.com  Thu Oct 13 10:59:10 2016
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Thu, 13 Oct 2016 14:59:10 +0000
Subject: [keycloak-dev] KeycloakSecurityContext is always null
In-Reply-To: <CY1PR0501MB180415798BBDD9A0A2B17B5AA8DA0@CY1PR0501MB1804.namprd05.prod.outlook.com>
References: <CY1PR0501MB180415798BBDD9A0A2B17B5AA8DA0@CY1PR0501MB1804.namprd05.prod.outlook.com>
Message-ID: <CY1PR0501MB18043B562E1AB99891BF8C14A8DC0@CY1PR0501MB1804.namprd05.prod.outlook.com>

On Keycloak Secure Application Service Guide is described like an obligation the definition of security-constration in web.xml.

I am programming an application that follows concepts of "WYSIWYG". My app need have the feature of anonymous browsing and identified browsing on same app URIs. The definition of url-paths protected by security-constration are breaking the concepts of "WYSIWYG".

Is there a way to get access to keycloak SecurityDomain without restrict paths by security-constration?

Regards,
Mauricio.

________________________________
De: Maur?cio Giacomini Penteado <mauriciogiacomini at hotmail.com>
Enviado: ter?a-feira, 11 de outubro de 2016 21:50
Para: keycloak-dev at lists.jboss.org
Assunto: KeycloakSecurityContext is always null


Hello everyone,

I do not understanding how can I correctly use KeycloakSecurityContext on a Rest service to obtain access to keycloak tokens.

I tryed via httpServletRequest:
KeycloakSecurityContext session = (KeycloakSecurityContext) httpServletRequest.getAttribute(KeycloakSecurityContext.class.getName());

But, my KeycloakSecurityContext is always null.
I put the anotation @SecurityDomain("keycloak") on my class without success.

The authentication works perfectly but, the authorization is a problem. I am trying access to KeycloakSecurityContext to work with authorization.

If someone has a tip that can help me, please let me know.

Regards,
Mauricio.


From sthorger at redhat.com  Thu Oct 13 13:32:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 13 Oct 2016 19:32:07 +0200
Subject: [keycloak-dev] How to report security problem
In-Reply-To: <CAPq3NeHx9sT49+mBMuiKr1BMBxh=rWsqUswXC_aek05gBV8OTg@mail.gmail.com>
References: <CAPq3NeFfNyrxWE2KVAEMvjJdARNG4wj1wZnpoOD=8J+KVxgs=A@mail.gmail.com>
	<CAK-7U1gs_6Ag+xVBF1SgJdehQ3OdSPSY8ttOD3X1W9ftRcj4+Q@mail.gmail.com>
	<CAPq3NeETXKn4u1ZtG8_JxVedEQbbfHOb4WpODTCmBpB-85uZ8w@mail.gmail.com>
	<CAPq3NeHx9sT49+mBMuiKr1BMBxh=rWsqUswXC_aek05gBV8OTg@mail.gmail.com>
Message-ID: <CAJgngAcP4on6kUB1W+J52cZ41RYr8MUBW6Bm3DSapYH9ZC64-g@mail.gmail.com>

Thanks. Only core members and the reporter can see the ticket.

On 13 October 2016 at 16:09, Hiroyuki Wada <wadahiro at gmail.com> wrote:

> Hello,
>
> I created the security issue yesterday.
>
> https://issues.jboss.org/browse/KEYCLOAK-3692
>
> Can only core members see the ticket?
> I wrote reproduce steps too. Please check the issue.
>
> Regards,
>
> --
> Hiroyuki Wada
>
> On Wed, Oct 12, 2016 at 5:01 PM, Hiroyuki Wada <wadahiro at gmail.com> wrote:
> > Hello Thomas,
> >
> > Thanks for your quick reply.
> > I'll create a jira ticket soon.
> >
> >
> >
> > On Wed, Oct 12, 2016 at 4:36 PM, Thomas Darimont
> > <thomas.darimont at googlemail.com> wrote:
> >> Hello Hiroyuki,
> >>
> >> Just create a new issue here https://issues.jboss.org/projects/KEYCLOAK
> >> Mark it as Security Sensitive Issue (x) This issue is security relevant.
> >>
> >> Cheers,
> >> Thomas
> >>
> >> 2016-10-12 9:30 GMT+02:00 Hiroyuki Wada <wadahiro at gmail.com>:
> >>>
> >>> Hello,
> >>>
> >>> I have security concern in Keycloak server. It might be a
> vulnerability.
> >>> Where should I report this problem?
> >>>
> >>>
> >>> Regards,
> >>>
> >>> --
> >>> Hiroyuki Wada,
> >>> Developer,
> >>> Nomura Research Institute, Ltd.
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mauriciogiacomini at hotmail.com  Thu Oct 13 14:37:57 2016
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Thu, 13 Oct 2016 18:37:57 +0000
Subject: [keycloak-dev] KeycloakSecurityContext is always null
In-Reply-To: <CY1PR0501MB18043B562E1AB99891BF8C14A8DC0@CY1PR0501MB1804.namprd05.prod.outlook.com>
References: <CY1PR0501MB180415798BBDD9A0A2B17B5AA8DA0@CY1PR0501MB1804.namprd05.prod.outlook.com>,
	<CY1PR0501MB18043B562E1AB99891BF8C14A8DC0@CY1PR0501MB1804.namprd05.prod.outlook.com>
Message-ID: <CY1PR0501MB1804AA5E2D2FEF52BB058C33A8DC0@CY1PR0501MB1804.namprd05.prod.outlook.com>

Strangely, if I add "Keycloak OIDC JBoss Subsystem XML" on my standalone.xml  the authentication stops to work and when I try do login I receive:

WARN  [org.keycloak.adapters.OAuthRequestAuthenticator] No state cookie

Please, is "state cookie" a enable/disable feature?

Regards,
Mauricio.


________________________________
De: keycloak-dev-bounces at lists.jboss.org <keycloak-dev-bounces at lists.jboss.org> em nome de Maur?cio Giacomini Penteado <mauriciogiacomini at hotmail.com>
Enviado: quinta-feira, 13 de outubro de 2016 14:59
Para: keycloak-dev at lists.jboss.org
Assunto: Re: [keycloak-dev] KeycloakSecurityContext is always null

On Keycloak Secure Application Service Guide is described like an obligation the definition of security-constration in web.xml.

I am programming an application that follows concepts of "WYSIWYG". My app need have the feature of anonymous browsing and identified browsing on same app URIs. The definition of url-paths protected by security-constration are breaking the concepts of "WYSIWYG".

Is there a way to get access to keycloak SecurityDomain without restrict paths by security-constration?

Regards,
Mauricio.

________________________________
De: Maur?cio Giacomini Penteado <mauriciogiacomini at hotmail.com>
Enviado: ter?a-feira, 11 de outubro de 2016 21:50
Para: keycloak-dev at lists.jboss.org
Assunto: KeycloakSecurityContext is always null


Hello everyone,

I do not understanding how can I correctly use KeycloakSecurityContext on a Rest service to obtain access to keycloak tokens.

I tryed via httpServletRequest:
KeycloakSecurityContext session = (KeycloakSecurityContext) httpServletRequest.getAttribute(KeycloakSecurityContext.class.getName());

But, my KeycloakSecurityContext is always null.
I put the anotation @SecurityDomain("keycloak") on my class without success.

The authentication works perfectly but, the authorization is a problem. I am trying access to KeycloakSecurityContext to work with authorization.

If someone has a tip that can help me, please let me know.

Regards,
Mauricio.

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
keycloak-dev Info Page - lists.jboss.org<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
lists.jboss.org
To see the collection of prior postings to the list, visit the keycloak-dev Archives. Using keycloak-dev: To post a message to all the list members ...




From mitya at cargosoft.ru  Fri Oct 14 01:00:21 2016
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Fri, 14 Oct 2016 08:00:21 +0300
Subject: [keycloak-dev] Custom AdminEvents
In-Reply-To: <1474906838.7390.44.camel@cargosoft.ru>
References: <1474900897.7390.25.camel@cargosoft.ru>
	<cf4b4ba7-7259-d223-3241-b442570e602a@redhat.com>
	<1474905095.7390.43.camel@cargosoft.ru>
	<1474906838.7390.44.camel@cargosoft.ru>
Message-ID: <1476421221.23974.1.camel@cargosoft.ru>

PR created https://github.com/keycloak/keycloak/pull/3316

From mitya at cargosoft.ru  Fri Oct 14 01:09:58 2016
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Fri, 14 Oct 2016 08:09:58 +0300
Subject: [keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable
Message-ID: <1476421798.23974.2.camel@cargosoft.ru>

Hi,

After KEYCLOAK-3618 is (hopefully) resolved, providers will have an
ability to log admin events with custom ResourceType. However, custom
values won't show in the Events - Admin Events - Filter - Resource
Types dropdown (fortunately, the values can still be typed in
directly).
The values in the dropdown reflect
org.keycloak.services.resources.admin.info.ServerInfoAdminResource::ENU
MS content. How about making it mutable, so that providers could
register provider-specific values? These could be some two methods: one
taking (String, String[]) to add values to existing enum maps, another
one taking (Class... enums) to register completely different enums for
provider's private needs.

What do you think?
Dmitry

From sblanc at redhat.com  Fri Oct 14 08:19:07 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Fri, 14 Oct 2016 14:19:07 +0200
Subject: [keycloak-dev] Need help with KEYCLOAK-3625 (OpenID connect session
	management - JS impl)
Message-ID: <CAMZCGg8skq2fK5Bk4QxKazNgW8zVrBHcrUAWfOdRUYtTNXr8JQ@mail.gmail.com>

Hi,

I started to look at https://issues.jboss.org/browse/KEYCLOAK-3625 .  The
fix is to send back a String containing just "changed" or "unchanged" from
the iframe to the main window, instead of a whole JSON like we do now.

Most of the refactoring is doable but there is one point on which I'm
really stuck :

The JS library maintain a callBack map that contains promises, the key is a
ID that we generate and that we pass to the iframe. When the iframe sends
back a message to the main Window it passes also the ID, so that we can
retrieve the correct promise to resolve it (or not).

But now since we return just a String, I don't know how we can retrieve the
correct promise from the callBack map.
Does anyone have an idea ?

Sebi

From sthorger at redhat.com  Mon Oct 17 01:19:05 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 07:19:05 +0200
Subject: [keycloak-dev] Need help with KEYCLOAK-3625 (OpenID connect
 session management - JS impl)
In-Reply-To: <CAMZCGg8skq2fK5Bk4QxKazNgW8zVrBHcrUAWfOdRUYtTNXr8JQ@mail.gmail.com>
References: <CAMZCGg8skq2fK5Bk4QxKazNgW8zVrBHcrUAWfOdRUYtTNXr8JQ@mail.gmail.com>
Message-ID: <CAJgngAck-mjtRvjXVc_PzV9C86p0_kUmMC3S0woQgpxisDniUw@mail.gmail.com>

checkLoginIframe should just add promise to a list and send the message if
there's not a request already in progress. messageCallback should then
invoke all promises in the list.

On 14 October 2016 at 14:19, Sebastien Blanc <sblanc at redhat.com> wrote:

> Hi,
>
> I started to look at https://issues.jboss.org/browse/KEYCLOAK-3625 .  The
> fix is to send back a String containing just "changed" or "unchanged" from
> the iframe to the main window, instead of a whole JSON like we do now.
>
> Most of the refactoring is doable but there is one point on which I'm
> really stuck :
>
> The JS library maintain a callBack map that contains promises, the key is a
> ID that we generate and that we pass to the iframe. When the iframe sends
> back a message to the main Window it passes also the ID, so that we can
> retrieve the correct promise to resolve it (or not).
>
> But now since we return just a String, I don't know how we can retrieve the
> correct promise from the callBack map.
> Does anyone have an idea ?
>
> Sebi
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct 17 01:20:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 07:20:30 +0200
Subject: [keycloak-dev] Use non-XA datasource
In-Reply-To: <CAJgngAehjzqMycBL0KXWdM4h8m9mmswJLj9QApMPKPgWD9RiFQ@mail.gmail.com>
References: <CAJgngAehjzqMycBL0KXWdM4h8m9mmswJLj9QApMPKPgWD9RiFQ@mail.gmail.com>
Message-ID: <CAJgngAd9P5+uk+z1diOpt0Vdeu7QzcdQxuO-wNgHn7cGRnr4Ug@mail.gmail.com>

Bill - can you comment on this please?

On 13 October 2016 at 15:44, Stian Thorgersen <sthorger at redhat.com> wrote:

> IMO we should not make KeycloakDS XA by default. Rather, the docs for the
> user federation provider should state that if you add another datasource
> you need to make that one XA.
>

From sblanc at redhat.com  Mon Oct 17 01:33:57 2016
From: sblanc at redhat.com (Sebastien Blanc)
Date: Mon, 17 Oct 2016 07:33:57 +0200
Subject: [keycloak-dev] Need help with KEYCLOAK-3625 (OpenID connect
 session management - JS impl)
In-Reply-To: <CAJgngAck-mjtRvjXVc_PzV9C86p0_kUmMC3S0woQgpxisDniUw@mail.gmail.com>
References: <CAMZCGg8skq2fK5Bk4QxKazNgW8zVrBHcrUAWfOdRUYtTNXr8JQ@mail.gmail.com>
	<CAJgngAck-mjtRvjXVc_PzV9C86p0_kUmMC3S0woQgpxisDniUw@mail.gmail.com>
Message-ID: <CAMZCGg9pT0-RRNHSBrm2eX3OSu=qZodGXqG1hdNhVcbP_1z5fQ@mail.gmail.com>

Ok, iterating through simple list and invoke each promises is what I did
indeed but I was not sure it was correct (was more using it like a
temporary fix ;) ).
About "send the message if there's not a request already in progress" , how
can I check that from the checkLoginIframe session ?

On Mon, Oct 17, 2016 at 7:19 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> checkLoginIframe should just add promise to a list and send the message if
> there's not a request already in progress. messageCallback should then
> invoke all promises in the list.
>
> On 14 October 2016 at 14:19, Sebastien Blanc <sblanc at redhat.com> wrote:
>
>> Hi,
>>
>> I started to look at https://issues.jboss.org/browse/KEYCLOAK-3625 .  The
>> fix is to send back a String containing just "changed" or "unchanged" from
>> the iframe to the main window, instead of a whole JSON like we do now.
>>
>> Most of the refactoring is doable but there is one point on which I'm
>> really stuck :
>>
>> The JS library maintain a callBack map that contains promises, the key is
>> a
>> ID that we generate and that we pass to the iframe. When the iframe sends
>> back a message to the main Window it passes also the ID, so that we can
>> retrieve the correct promise to resolve it (or not).
>>
>> But now since we return just a String, I don't know how we can retrieve
>> the
>> correct promise from the callBack map.
>> Does anyone have an idea ?
>>
>> Sebi
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Mon Oct 17 02:11:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 08:11:57 +0200
Subject: [keycloak-dev] Need help with KEYCLOAK-3625 (OpenID connect
 session management - JS impl)
In-Reply-To: <CAMZCGg9pT0-RRNHSBrm2eX3OSu=qZodGXqG1hdNhVcbP_1z5fQ@mail.gmail.com>
References: <CAMZCGg8skq2fK5Bk4QxKazNgW8zVrBHcrUAWfOdRUYtTNXr8JQ@mail.gmail.com>
	<CAJgngAck-mjtRvjXVc_PzV9C86p0_kUmMC3S0woQgpxisDniUw@mail.gmail.com>
	<CAMZCGg9pT0-RRNHSBrm2eX3OSu=qZodGXqG1hdNhVcbP_1z5fQ@mail.gmail.com>
Message-ID: <CAJgngAdCCp=8JZur+aD=V=mUzK9N91Wp0vqz1DNwgLYAYrdm+A@mail.gmail.com>

List size != 0 ;)

On 17 October 2016 at 07:33, Sebastien Blanc <sblanc at redhat.com> wrote:

> Ok, iterating through simple list and invoke each promises is what I did
> indeed but I was not sure it was correct (was more using it like a
> temporary fix ;) ).
> About "send the message if there's not a request already in progress" ,
> how can I check that from the checkLoginIframe session ?
>
> On Mon, Oct 17, 2016 at 7:19 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> checkLoginIframe should just add promise to a list and send the message
>> if there's not a request already in progress. messageCallback should then
>> invoke all promises in the list.
>>
>> On 14 October 2016 at 14:19, Sebastien Blanc <sblanc at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I started to look at https://issues.jboss.org/browse/KEYCLOAK-3625 .
>>> The
>>> fix is to send back a String containing just "changed" or "unchanged"
>>> from
>>> the iframe to the main window, instead of a whole JSON like we do now.
>>>
>>> Most of the refactoring is doable but there is one point on which I'm
>>> really stuck :
>>>
>>> The JS library maintain a callBack map that contains promises, the key
>>> is a
>>> ID that we generate and that we pass to the iframe. When the iframe sends
>>> back a message to the main Window it passes also the ID, so that we can
>>> retrieve the correct promise to resolve it (or not).
>>>
>>> But now since we return just a String, I don't know how we can retrieve
>>> the
>>> correct promise from the callBack map.
>>> Does anyone have an idea ?
>>>
>>> Sebi
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From mposolda at redhat.com  Mon Oct 17 03:41:36 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 17 Oct 2016 09:41:36 +0200
Subject: [keycloak-dev] Added Dynamic client registration policies
Message-ID: <702f1049-53ae-26ad-51db-be9ac2dbf09a@redhat.com>

I've added support for Dynamic client registration policies to the master.


Summary of changes:

* Admin console tab "Initial Access Tokens" was renamed to "Client 
Registrations" . It has 2 subtabs now "Initial Access Tokens" and 
"Client Registration Policies" .

* Previous "Trusted hosts" stuff was renamed from UI (still need to do 
some model cleanup...)

* Client Registration Policies tab exposes the configured client 
registration policies for the realm. I've added new 
ClientRegistrationPolicy SPI based on generic component model.

* There are 2 kinds of client registration policies.

** Authenticated - Those are used when clientRegistration request with 
initial-access-token or with bearer-token comes.

** Anonymous - Those are used when clientRegistration request without 
initial-access-token or without bearer-token comes. Also it's used for 
update requests with registrationToken for clients, which were 
registered through anonymous registration.

* Implementations of clientRegistrationPolicies:

** TrustedHostClientRegistrationPolicy - Allows to configure trusted 
hosts (by IP Address or by hostname) and domains. ClientRegistration 
request needs to come from some trusted host or domain, otherwise it's 
rejected. Also all the client uris (redirect_uris etc) needs to match 
some trusted host or domain. By default there is not any trusted host 
configured. Hence anonymous clientRegistrations, which uses this policy 
by default, are always rejected by default unless you specify some 
trusted host.

** ConsentRequiredClientRegistrationPolicy - newly registered clients 
will automatically have consentRequired enabled. Also it's not possible 
to update them to switch consentRequired to off.

** ScopeClientRegistrationPolicy - newly registered clients will 
automatically have fullScopeAllowed disabled. Also it's not possible to 
update them to switch fullScopeAllowed to on.

** ProtocolMapperClientRegistrationPolicy - newly registered clients 
can't use any protocolMapper implementations besides those, which are 
whitelisted. By default, the whitelisted includes few types, mostly 
those which we already as builtin mappers (User Property Mapper, USer 
Attribute Mapper, Full name mapper etc)

** ClientTemplateClientRegistrationPolicy - newly registered or updated 
clients can't have any clientTemplate, which is not whitelisted. By 
default, there is not any whitelisted clientTemplate

* Authenticated policies - There are 2 policies by default. One for 
protocol mappers and one for clientTemplate.

* Anonymous policies - Contains all 5 policies configured. In other 
words, newly registered clients need to come from trusted hosts, have 
fullScopeAllowed disabled and consentRequired enabled and can't have 
non-whitelisted protocolMappers and clientTemplates.

* Some generic changes:

** Added 2 types of ProviderConfigProperty

*** MultivaluedString - allows to specify more string values of some 
attribute. Something like redirectUris or webOrigins for client.

*** MultivaluedList - allows to specify more string values, which needs 
to be selected from the list of pre-defined allowed values. Something 
like "requiredActions" for user.

** Added field "subType" to ComponentModel. This is because for 
clientRegistrationPolicies, I have 2 kinds of policies with same type 
and same parentId (same realm), but I still need to differentiate 
between them.


Remaining TODOs (maybe some more based on feedback) :

* It seems I broke Wildfly distribution. I will fix ASAP today.

* I've just created KEYCLOAK-3712 Client Registration limitations - In 
shortcut, our default implementations of ClientRegistrationProvider 
doesn't allow to CRUD client roles, scope mappings, service account 
roles or authorization settings of client. It also doesn't allow to 
update of protocolMappers. Not sure if we need to address this for this 
release? If yes, then Scope policy should be enhanced to also support 
whitelisting of scoped roles.

* Some cleanup (logging messages, cleanup of infinispan model for 
previous "trusted hosts" thing)

* Docs


Marek


From mposolda at redhat.com  Mon Oct 17 03:48:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 17 Oct 2016 09:48:07 +0200
Subject: [keycloak-dev] ProviderConfigProperty.defaultValue for LIST_TYPE
Message-ID: <2fd7b95c-bb78-04a0-15ab-329db3781f78@redhat.com>

There is one strange thing for ProviderConfigProperties, which uses type 
LIST. For those, the "defaultValue" field doesn't really use 
defaultValue of particular field, but instead it contains list of 
available values to be selected in combobox for particular config property.

IMO this is not good because of:

* Field "defaultValue" is used for something, which is not really 
defaultValue. It's a bit confusing IMO. Note once we're adding supported 
UserStorage SPIs, then customers may need to add their own properties of 
type "List" . So this is not just Keycloak implementation detail, but 
it's exposed externally.

* It's not easily possible to set the actual defaultValue for list 
because field "defaultValue" is occupied by the list of available values.


How about adding new field like "availableValues" to 
ProviderConfigProperty and refactor existing impls to use this one instead?

Marek


From sthorger at redhat.com  Mon Oct 17 07:03:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 13:03:34 +0200
Subject: [keycloak-dev] ProviderConfigProperty.defaultValue for LIST_TYPE
In-Reply-To: <2fd7b95c-bb78-04a0-15ab-329db3781f78@redhat.com>
References: <2fd7b95c-bb78-04a0-15ab-329db3781f78@redhat.com>
Message-ID: <CAJgngAfK1kgBRCXKyK+UkS6gr_tAKBy1fs=mTTjWpoumSO+x+g@mail.gmail.com>

+1 Maybe call it options? instead of availableValues.

On 17 October 2016 at 09:48, Marek Posolda <mposolda at redhat.com> wrote:

> There is one strange thing for ProviderConfigProperties, which uses type
> LIST. For those, the "defaultValue" field doesn't really use
> defaultValue of particular field, but instead it contains list of
> available values to be selected in combobox for particular config property.
>
> IMO this is not good because of:
>
> * Field "defaultValue" is used for something, which is not really
> defaultValue. It's a bit confusing IMO. Note once we're adding supported
> UserStorage SPIs, then customers may need to add their own properties of
> type "List" . So this is not just Keycloak implementation detail, but
> it's exposed externally.
>
> * It's not easily possible to set the actual defaultValue for list
> because field "defaultValue" is occupied by the list of available values.
>
>
> How about adding new field like "availableValues" to
> ProviderConfigProperty and refactor existing impls to use this one instead?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mposolda at redhat.com  Mon Oct 17 07:20:48 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 17 Oct 2016 13:20:48 +0200
Subject: [keycloak-dev] ProviderConfigProperty.defaultValue for LIST_TYPE
In-Reply-To: <CAJgngAfK1kgBRCXKyK+UkS6gr_tAKBy1fs=mTTjWpoumSO+x+g@mail.gmail.com>
References: <2fd7b95c-bb78-04a0-15ab-329db3781f78@redhat.com>
	<CAJgngAfK1kgBRCXKyK+UkS6gr_tAKBy1fs=mTTjWpoumSO+x+g@mail.gmail.com>
Message-ID: <75021c11-30ba-b2db-b64c-f3c6d4794905@redhat.com>

+1 for "options"

Marek

On 17/10/16 13:03, Stian Thorgersen wrote:
> +1 Maybe call it options? instead of availableValues.
>
> On 17 October 2016 at 09:48, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     There is one strange thing for ProviderConfigProperties, which
>     uses type
>     LIST. For those, the "defaultValue" field doesn't really use
>     defaultValue of particular field, but instead it contains list of
>     available values to be selected in combobox for particular config
>     property.
>
>     IMO this is not good because of:
>
>     * Field "defaultValue" is used for something, which is not really
>     defaultValue. It's a bit confusing IMO. Note once we're adding
>     supported
>     UserStorage SPIs, then customers may need to add their own
>     properties of
>     type "List" . So this is not just Keycloak implementation detail, but
>     it's exposed externally.
>
>     * It's not easily possible to set the actual defaultValue for list
>     because field "defaultValue" is occupied by the list of available
>     values.
>
>
>     How about adding new field like "availableValues" to
>     ProviderConfigProperty and refactor existing impls to use this one
>     instead?
>
>     Marek
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mposolda at redhat.com  Mon Oct 17 07:32:23 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 17 Oct 2016 13:32:23 +0200
Subject: [keycloak-dev] ProviderConfigProperty.defaultValue for LIST_TYPE
In-Reply-To: <75021c11-30ba-b2db-b64c-f3c6d4794905@redhat.com>
References: <2fd7b95c-bb78-04a0-15ab-329db3781f78@redhat.com>
	<CAJgngAfK1kgBRCXKyK+UkS6gr_tAKBy1fs=mTTjWpoumSO+x+g@mail.gmail.com>
	<75021c11-30ba-b2db-b64c-f3c6d4794905@redhat.com>
Message-ID: <6aeeca67-138d-9c73-4973-c3cd0d421c8c@redhat.com>

I've created https://issues.jboss.org/browse/KEYCLOAK-3719 . Will try to 
sort it before the release.

Marek

On 17/10/16 13:20, Marek Posolda wrote:
> +1 for "options"
>
> Marek
>
> On 17/10/16 13:03, Stian Thorgersen wrote:
>> +1 Maybe call it options? instead of availableValues.
>>
>> On 17 October 2016 at 09:48, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>      There is one strange thing for ProviderConfigProperties, which
>>      uses type
>>      LIST. For those, the "defaultValue" field doesn't really use
>>      defaultValue of particular field, but instead it contains list of
>>      available values to be selected in combobox for particular config
>>      property.
>>
>>      IMO this is not good because of:
>>
>>      * Field "defaultValue" is used for something, which is not really
>>      defaultValue. It's a bit confusing IMO. Note once we're adding
>>      supported
>>      UserStorage SPIs, then customers may need to add their own
>>      properties of
>>      type "List" . So this is not just Keycloak implementation detail, but
>>      it's exposed externally.
>>
>>      * It's not easily possible to set the actual defaultValue for list
>>      because field "defaultValue" is occupied by the list of available
>>      values.
>>
>>
>>      How about adding new field like "availableValues" to
>>      ProviderConfigProperty and refactor existing impls to use this one
>>      instead?
>>
>>      Marek
>>
>>      _______________________________________________
>>      keycloak-dev mailing list
>>      keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>      https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>      <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Mon Oct 17 09:30:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 15:30:50 +0200
Subject: [keycloak-dev] Scope Param with Keycloak
In-Reply-To: <CAFjvcK6BPLRCJjb=+n1VQpcpmsgqquWKSyYo68Av4OXZEA28Dg@mail.gmail.com>
References: <CAFjvcK4zzc-ubWeBiugRmeGwSRxqgt-vE7UankP6M7=aPCWoug@mail.gmail.com>
	<CAJgngAcL5A=E=0f3yKZqt7CRhFTRT1LL=xLUJZhMv++409KgjA@mail.gmail.com>
	<CAFjvcK6BPLRCJjb=+n1VQpcpmsgqquWKSyYo68Av4OXZEA28Dg@mail.gmail.com>
Message-ID: <CAJgngAdp+uy9038d=s9Q7h6WgMdb7CXrBN_2sD+UoQkh=KZ6Pg@mail.gmail.com>

Support for scope parameter has been postponed. We may pick this up for
3.x, but it's not guaranteed we'll have cycles to do it then either. You
can add a "me to" to the issue or even better if you'd like to contribute
the feature we'd love that ;)

On 12 October 2016 at 21:39, Tomas Cerny <tom.cerny at gmail.com> wrote:

> Hello,
>
> is there any update on the scope param (below)? Regarding to the protocol
> mappers (a param to pass) is there any good sample to start with, or a
> reference to look over?
>
> Thank you, Tomas
>
> On Tue, Oct 6, 2015 at 10:11 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We do not currently support scope param and this is something we plan to
>> add in the future. We do have protocol mappers that you can use to add any
>> additional claims to the token for a client.
>>
>> On 5 October 2015 at 21:49, Tomas Cerny <tom.cerny at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>
>>>
>>> I am trying to use the scope param with keycloak, which is part of the
>>> open id
>>>
>>> http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims
>>>
>>> Here is an sample URL (from https://openid.net/specs
>>> /openid-connect-basic-1_0.html#AuthenticationRequest )
>>>
>>>
>>>
>>> Which is
>>>
>>> https://server.example.com/authorize?
>>>
>>>   response_type=code
>>>
>>>   &client_id=s6BhdRkqt3
>>>
>>>   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
>>>
>>>   &scope=openid%20profile
>>>
>>>   &state=af0ifjsldkj
>>>
>>>
>>>
>>> note the state param there
>>>
>>> with keycloak this is my auth URL: http://127.0.0.1:8080/aut
>>> h/realms/example/protocol/openid-connect/auth?client_id=js-
>>> console&redirect_uri=http://127.0.0.1:8080/js-console/&sta
>>> te=4bb976a4-ad5f-4af5-955d-1b2bdfb738df&response_type=code
>>>
>>>
>>>
>>> When I pass scope param, then it is ignored.
>>>
>>>
>>>
>>> Does keycloak support scope param? Can I intercept it to make a custom
>>> handler? (e.g. lookup DB data)
>>>
>>>
>>>
>>> Sample Use Case: Keycloak has my custom UserFederation provides where I
>>> issue user lookup to my SQL DB, and determine access, next basing on the
>>> scope I like to post back to the app roles relevant to the scope param.
>>>
>>>
>>>
>>> I know keycloak has static roles, but I need it contextual, such as -
>>> user is master in scope = A, but reader in scope = B. Since the range of
>>> scopes is dynamic and large, the use of client-ids is not sufficient.
>>>
>>>
>>>
>>> I assume the scope can help me solving situation such as am I owned of
>>> an object?
>>>
>>>
>>>
>>> I did days of debugging keycloak code and cannot find much even thought
>>> there is OAuth2Constants.Scope but may be that is something different?
>>>
>>>
>>>
>>> and I seem some dead sample here: FishEye: changeset
>>> d309fab8251d95f50f94c77e4d08e6e8c2977994
>>> <https://source.jboss.org/changelog/Keycloak?cs=d309fab8251d95f50f94c77e4d08e6e8c2977994>
>>>
>>>
>>>
>>>
>>>
>>> The alternative OpenAM supports scope param it - OpenAM Project - About
>>> OpenAM <http://openam.forgerock.org/>
>>>
>>>
>>>
>>> Thanks, Tom
>>>
>>> Here a forum public users.
>>> https://developer.jboss.org/message/934762#934762
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From bburke at redhat.com  Mon Oct 17 11:31:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 17 Oct 2016 11:31:11 -0400
Subject: [keycloak-dev] Use non-XA datasource
In-Reply-To: <CAJgngAd9P5+uk+z1diOpt0Vdeu7QzcdQxuO-wNgHn7cGRnr4Ug@mail.gmail.com>
References: <CAJgngAehjzqMycBL0KXWdM4h8m9mmswJLj9QApMPKPgWD9RiFQ@mail.gmail.com>
	<CAJgngAd9P5+uk+z1diOpt0Vdeu7QzcdQxuO-wNgHn7cGRnr4Ug@mail.gmail.com>
Message-ID: <ca4dda44-68cc-65c2-06c5-4c2aa27b56a1@redhat.com>

I thought we already agreed we'd make KeycloakDS non-xa?


On 10/17/16 1:20 AM, Stian Thorgersen wrote:
> Bill - can you comment on this please?
>
> On 13 October 2016 at 15:44, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     IMO we should not make KeycloakDS XA by default. Rather, the docs
>     for the user federation provider should state that if you add
>     another datasource you need to make that one XA.
>
>


From sthorger at redhat.com  Mon Oct 17 11:37:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 17:37:04 +0200
Subject: [keycloak-dev] Use non-XA datasource
In-Reply-To: <ca4dda44-68cc-65c2-06c5-4c2aa27b56a1@redhat.com>
References: <CAJgngAehjzqMycBL0KXWdM4h8m9mmswJLj9QApMPKPgWD9RiFQ@mail.gmail.com>
	<CAJgngAd9P5+uk+z1diOpt0Vdeu7QzcdQxuO-wNgHn7cGRnr4Ug@mail.gmail.com>
	<ca4dda44-68cc-65c2-06c5-4c2aa27b56a1@redhat.com>
Message-ID: <CAJgngAfhWJcm7yAtaaZGxkQ3J-2yoTTO37nraBxpSAc584Yj_w@mail.gmail.com>

Wasn't sure we had, but let's go with that. Thanks

On 17 October 2016 at 17:31, Bill Burke <bburke at redhat.com> wrote:

> I thought we already agreed we'd make KeycloakDS non-xa?
>
> On 10/17/16 1:20 AM, Stian Thorgersen wrote:
>
> Bill - can you comment on this please?
>
> On 13 October 2016 at 15:44, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> IMO we should not make KeycloakDS XA by default. Rather, the docs for the
>> user federation provider should state that if you add another datasource
>> you need to make that one XA.
>>
>
>
>

From sthorger at redhat.com  Mon Oct 17 12:49:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 18:49:51 +0200
Subject: [keycloak-dev] Removed themes jar from server distribution
Message-ID: <CAJgngAfCLAJvJWuT3Lne0CBJs0RRtCFft+=1nfi8bhrfM230iQ@mail.gmail.com>

I've removed the themes jar from the server distribution and at the same
time made all built-in theme resources read-only so users don't edit them
by mistake.

I've also removed from unused files from the common resources for themes
(files for third party libraries).

From thomas.darimont at googlemail.com  Mon Oct 17 14:35:55 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 17 Oct 2016 20:35:55 +0200
Subject: [keycloak-dev] Selectively control the returned data of a
	(User)Representation
Message-ID: <CAK-7U1hkBPGVjDBAPd-mURsCmaqWg401+CcaiGfjbUjwJZZK1g@mail.gmail.com>

Hello group,

for KEYCLOAK-3410 "Ease creating user with initial roles via REST I" filed
the following
PR https://github.com/keycloak/keycloak/pull/3120 in which the need arose
to selectively include details within a Representation returned by a REST
resource.

In this concrete case I made it easier to create users with an initial set
of Realm-/ClientRoles
via the Keycloak admin client which I learned in some projects is a common
requirement.

Previously roles passed to the UserRepresentation were ignored when
creating a user via the Keycloak admin client and a user had to create the
roles in a second step after the creation of the user which required
multiple HTTP requests.

With the changes within the mentioned PR clients can create a user with a
set of predefined roles
with a single HTTP request like the following:

   UserRepresentation user = new UserRepresentation();
   user.setUsername("user1");
   user.setRealmRoles(singletonList(REALM_ROLE_NAME));
   user.setClientRoles(singletonMap(APP_CLIENT_ID,
singletonList(CLIENT_ROLE_NAME)));

   Response response = keycloak.realm(realmName).users().create(user);

For symmetry reasons I also changed the
org.keycloak.services.resources.admin.UsersResource#getUser(String)
method to return the configured Realm/ClientRoles with just one HTTP
request.
See:
https://github.com/keycloak/keycloak/pull/3120/commits/2afec29a2cf97a4aac97e169a564ab88bdce5d19

One downside of this is that this could potentially lead to unexpected
performance problems since a user could have many roles assigned, also
currently the admin console issues some UsersResource#getUser(String)
requests which would (currently) ignore the returned rows.

Stian and I had some discussions on how this could be solved - among the
discussed options were:
1) just return the Realm/ClientRoles and document the potential performance
impact
2) introduce some sort of ?include=[String ... categories] parameter in the
Keycloak client API
   which would allow a client to control what would be returned in the
(User)Representation
3) Introduce a new dedicated endpoint UsersResource#getUserDetails(String
userId) to return the full UserRepresentation with the roles.
4) Use Media-Types like application/vnd.keycloak-user+json and
application/vnd.keycloak-user-details+json to control the data of the
returned representation.

Since all of those mentioned options come with some pros and cons we'd like
to reach out to you folks to help us to find the best solution possible.

Since this problem also arises for other representations like clients /
groups, realms etc.
it would be beneficial for the sake of a consistent API to find a general
solution how to proceed here.

Looking forward to your feedback.

Cheers,
Thomas

From sthorger at redhat.com  Mon Oct 17 14:54:22 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 17 Oct 2016 20:54:22 +0200
Subject: [keycloak-dev] Selectively control the returned data of a
	(User)Representation
In-Reply-To: <CAK-7U1hkBPGVjDBAPd-mURsCmaqWg401+CcaiGfjbUjwJZZK1g@mail.gmail.com>
References: <CAK-7U1hkBPGVjDBAPd-mURsCmaqWg401+CcaiGfjbUjwJZZK1g@mail.gmail.com>
Message-ID: <CAJgngAcEMSeQOs8+0CLjb_CZpEJhrm+kSCKfJCN-n_brX-350A@mail.gmail.com>

@Thomas no one is going to read that - you wrote to much ;)

Summary:

Fetching a user from the admin endpoints doesn't include roles mappings.
Thomas wants it to and proposes to use "?include=roles", well actually I
proposed it, so it gets a +1 from me.

On 17 October 2016 at 20:35, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hello group,
>
> for KEYCLOAK-3410 "Ease creating user with initial roles via REST I" filed
> the following
> PR https://github.com/keycloak/keycloak/pull/3120 in which the need arose
> to selectively include details within a Representation returned by a REST
> resource.
>
> In this concrete case I made it easier to create users with an initial set
> of Realm-/ClientRoles
> via the Keycloak admin client which I learned in some projects is a common
> requirement.
>
> Previously roles passed to the UserRepresentation were ignored when
> creating a user via the Keycloak admin client and a user had to create the
> roles in a second step after the creation of the user which required
> multiple HTTP requests.
>
> With the changes within the mentioned PR clients can create a user with a
> set of predefined roles
> with a single HTTP request like the following:
>
>    UserRepresentation user = new UserRepresentation();
>    user.setUsername("user1");
>    user.setRealmRoles(singletonList(REALM_ROLE_NAME));
>    user.setClientRoles(singletonMap(APP_CLIENT_ID,
> singletonList(CLIENT_ROLE_NAME)));
>
>    Response response = keycloak.realm(realmName).users().create(user);
>
> For symmetry reasons I also changed the
> org.keycloak.services.resources.admin.UsersResource#getUser(String)
> method to return the configured Realm/ClientRoles with just one HTTP
> request.
> See:
> https://github.com/keycloak/keycloak/pull/3120/commits/
> 2afec29a2cf97a4aac97e169a564ab88bdce5d19
>
> One downside of this is that this could potentially lead to unexpected
> performance problems since a user could have many roles assigned, also
> currently the admin console issues some UsersResource#getUser(String)
> requests which would (currently) ignore the returned rows.
>
> Stian and I had some discussions on how this could be solved - among the
> discussed options were:
> 1) just return the Realm/ClientRoles and document the potential performance
> impact
> 2) introduce some sort of ?include=[String ... categories] parameter in the
> Keycloak client API
>    which would allow a client to control what would be returned in the
> (User)Representation
> 3) Introduce a new dedicated endpoint UsersResource#getUserDetails(String
> userId) to return the full UserRepresentation with the roles.
> 4) Use Media-Types like application/vnd.keycloak-user+json and
> application/vnd.keycloak-user-details+json to control the data of the
> returned representation.
>
> Since all of those mentioned options come with some pros and cons we'd like
> to reach out to you folks to help us to find the best solution possible.
>
> Since this problem also arises for other representations like clients /
> groups, realms etc.
> it would be beneficial for the sake of a consistent API to find a general
> solution how to proceed here.
>
> Looking forward to your feedback.
>
> Cheers,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mitya at cargosoft.ru  Mon Oct 17 15:15:18 2016
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 17 Oct 2016 22:15:18 +0300
Subject: [keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable
In-Reply-To: <1476421798.23974.2.camel@cargosoft.ru>
References: <1476421798.23974.2.camel@cargosoft.ru>
Message-ID: <1476731718.4820.0.camel@cargosoft.ru>

JIRA https://issues.jboss.org/browse/KEYCLOAK-3711
PR https://github.com/keycloak/keycloak/pull/3337

From sthorger at redhat.com  Tue Oct 18 01:18:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 18 Oct 2016 07:18:35 +0200
Subject: [keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable
In-Reply-To: <1476731718.4820.0.camel@cargosoft.ru>
References: <1476421798.23974.2.camel@cargosoft.ru>
	<1476731718.4820.0.camel@cargosoft.ru>
Message-ID: <CAJgngAd+sfbtdDVBappdmxAYY9EjJd7fL9g+iJX9024fy=ioaQ@mail.gmail.com>

I don't like the PRs you've sent at all. It's all very hacky, calling
static methods on other classes is far from elegant. I've rejected both
PRs. It also ends up being completely undocumented so no-one except you
would know about this.

On 17 October 2016 at 21:15, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> JIRA https://issues.jboss.org/browse/KEYCLOAK-3711
> PR https://github.com/keycloak/keycloak/pull/3337
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From gambol99 at gmail.com  Tue Oct 18 06:25:32 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 18 Oct 2016 11:25:32 +0100
Subject: [keycloak-dev] Enrollment Workflows
Message-ID: <CA+AP+fOtjAY47e0zZjoG19q3voC1rtCBcr9U=E3NKype4eMZZA@mail.gmail.com>

Hiya

I was wondering if aspects should has user enrollment and workflows is on
the cards for Keycloak. Or would you regard this as another product? ... an
example being Forgerocks OpenIDM

Rohitih

From sthorger at redhat.com  Tue Oct 18 06:44:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 18 Oct 2016 12:44:49 +0200
Subject: [keycloak-dev] Enrollment Workflows
In-Reply-To: <CA+AP+fOtjAY47e0zZjoG19q3voC1rtCBcr9U=E3NKype4eMZZA@mail.gmail.com>
References: <CA+AP+fOtjAY47e0zZjoG19q3voC1rtCBcr9U=E3NKype4eMZZA@mail.gmail.com>
Message-ID: <CAJgngAcQc4Jd2=JZ37v12OKr=YccafYyLF7t3FZFR_ToVyF=xg@mail.gmail.com>

It's on the horizon, but nothing that is planned for the immediate future.

On 18 October 2016 at 12:25, gambol <gambol99 at gmail.com> wrote:

> Hiya
>
> I was wondering if aspects should has user enrollment and workflows is on
> the cards for Keycloak. Or would you regard this as another product? ... an
> example being Forgerocks OpenIDM
>
> Rohitih
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From gambol99 at gmail.com  Tue Oct 18 08:39:04 2016
From: gambol99 at gmail.com (gambol)
Date: Tue, 18 Oct 2016 13:39:04 +0100
Subject: [keycloak-dev] Enrollment Workflows
In-Reply-To: <CAJgngAcQc4Jd2=JZ37v12OKr=YccafYyLF7t3FZFR_ToVyF=xg@mail.gmail.com>
References: <CA+AP+fOtjAY47e0zZjoG19q3voC1rtCBcr9U=E3NKype4eMZZA@mail.gmail.com>
	<CAJgngAcQc4Jd2=JZ37v12OKr=YccafYyLF7t3FZFR_ToVyF=xg@mail.gmail.com>
Message-ID: <CA+AP+fPP+yZXEZGOhqq6B1=CGiHtBmUPifw=1x4zixVWivwL9w@mail.gmail.com>

Along the lines of feature sets. One of the biggest gripes that pops up is
User management and ability to delegate responsibility of a 'group or
groups' to another member without have to give them admin to the realm. I
was wondering if managerial control over a set of groups is on the cards.
i.e. allow members, x y and z to manage the admin group (add members etc).
I guessing at present given the way members are being authorized, via roles
in the issued jwt tokens, fine grains controls isn't yet available without
big changes?? ...

On Tue, Oct 18, 2016 at 11:44 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> It's on the horizon, but nothing that is planned for the immediate future.
>
> On 18 October 2016 at 12:25, gambol <gambol99 at gmail.com> wrote:
>
>> Hiya
>>
>> I was wondering if aspects should has user enrollment and workflows is on
>> the cards for Keycloak. Or would you regard this as another product? ...
>> an
>> example being Forgerocks OpenIDM
>>
>> Rohitih
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From sthorger at redhat.com  Tue Oct 18 09:50:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 18 Oct 2016 15:50:27 +0200
Subject: [keycloak-dev] Enrollment Workflows
In-Reply-To: <CA+AP+fPP+yZXEZGOhqq6B1=CGiHtBmUPifw=1x4zixVWivwL9w@mail.gmail.com>
References: <CA+AP+fOtjAY47e0zZjoG19q3voC1rtCBcr9U=E3NKype4eMZZA@mail.gmail.com>
	<CAJgngAcQc4Jd2=JZ37v12OKr=YccafYyLF7t3FZFR_ToVyF=xg@mail.gmail.com>
	<CA+AP+fPP+yZXEZGOhqq6B1=CGiHtBmUPifw=1x4zixVWivwL9w@mail.gmail.com>
Message-ID: <CAJgngAcBE7e2CSVRgwJwcFipp66S90NKg0E3RsLdZ-q=+9FRqA@mail.gmail.com>

I assume that's a different requirement to user enrollment and workflows.

We have an open issue to allow granting admins access to limited groups of
users, clients, etc.. See https://issues.jboss.org/browse/KEYCLOAK-3444 for
more details. You can add a comment to that issue to describe what you need.

On 18 October 2016 at 14:39, gambol <gambol99 at gmail.com> wrote:

> Along the lines of feature sets. One of the biggest gripes that pops up is
> User management and ability to delegate responsibility of a 'group or
> groups' to another member without have to give them admin to the realm. I
> was wondering if managerial control over a set of groups is on the cards.
> i.e. allow members, x y and z to manage the admin group (add members etc).
> I guessing at present given the way members are being authorized, via roles
> in the issued jwt tokens, fine grains controls isn't yet available without
> big changes?? ...
>
> On Tue, Oct 18, 2016 at 11:44 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
> > It's on the horizon, but nothing that is planned for the immediate
> future.
> >
> > On 18 October 2016 at 12:25, gambol <gambol99 at gmail.com> wrote:
> >
> >> Hiya
> >>
> >> I was wondering if aspects should has user enrollment and workflows is
> on
> >> the cards for Keycloak. Or would you regard this as another product? ...
> >> an
> >> example being Forgerocks OpenIDM
> >>
> >> Rohitih
> >> _______________________________________________
> >> 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 mitya at cargosoft.ru  Tue Oct 18 15:57:02 2016
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Tue, 18 Oct 2016 22:57:02 +0300
Subject: [keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable
In-Reply-To: <CAJgngAd+sfbtdDVBappdmxAYY9EjJd7fL9g+iJX9024fy=ioaQ@mail.gmail.com>
References: <1476421798.23974.2.camel@cargosoft.ru>
	<1476731718.4820.0.camel@cargosoft.ru>
	<CAJgngAd+sfbtdDVBappdmxAYY9EjJd7fL9g+iJX9024fy=ioaQ@mail.gmail.com>
Message-ID: <1476820622.8706.1.camel@cargosoft.ru>

Hi Stian,
I completely agree on the first point, this deserves a better solution.
But knowing that it would require digging deep into the guts of
KeyCloak, I just didn't dare :)
I would see providers somehow registering their custom enum keys,
either via API call or via callback, and KeyCloak would maintain the
list of custom values per provider. ServerInfoAdminResource then could
return a combined list of enum keys, both built-in and defined by
providers. But I'm afraid that would require changes to API and/or
interfaces. What do you think? How would you approach this problem
yourself?
And BTW, what's wrong with the second PR? The github comment seems a
bit unclear, so could you please elaborate? It has completely different
scope, though deals with the same feature. It's not about exposing
anything via static methods, it's about making ResourceType extensible,
following a well-defined pattern. I was sure that Marek supported it,
and I've implemented it in accordance with his recommendations.
Please forgive my persistence, but I consider this an important
feature. What we love about KeyCloak is its total extensibility. Having
custom entities and realm resources is great, but not being able to log
their events leaves a sensation of incompleteness.
Cheers,Dmitry
> I don't like the PRs you've sent at all. It's all very hacky, calling
> static methods on other classes is far from elegant. I've rejected
> both PRs. It also ends up being completely undocumented so no-one
> except you would know about this.
> On 17 October 2016 at 21:15, Dmitry Telegin <mitya at cargosoft.ru>
> wrote:
> > JIRA https://issues.jboss.org/browse/KEYCLOAK-3711
> > 
> > PR https://github.com/keycloak/keycloak/pull/3337
> > 
> > _______________________________________________
> > 
> > keycloak-dev mailing list
> > 
> > keycloak-dev at lists.jboss.org
> > 
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > 

From sthorger at redhat.com  Wed Oct 19 00:17:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 19 Oct 2016 06:17:43 +0200
Subject: [keycloak-dev] Making ServerInfoAdminResource::ENUMS mutable
In-Reply-To: <1476820622.8706.1.camel@cargosoft.ru>
References: <1476421798.23974.2.camel@cargosoft.ru>
	<1476731718.4820.0.camel@cargosoft.ru>
	<CAJgngAd+sfbtdDVBappdmxAYY9EjJd7fL9g+iJX9024fy=ioaQ@mail.gmail.com>
	<1476820622.8706.1.camel@cargosoft.ru>
Message-ID: <CAJgngAcYnnNsXEaCj5JHgPpcG6kK_TqW8jTXA_xKCbuSisxQzA@mail.gmail.com>

On 18 October 2016 at 21:57, Dmitry Telegin <mitya at cargosoft.ru> wrote:

> Hi Stian,
>
> I completely agree on the first point, this deserves a better solution.
> But knowing that it would require digging deep into the guts of KeyCloak, I
> just didn't dare :)
>
> I would see providers somehow registering their custom enum keys, either
> via API call or via callback, and KeyCloak would maintain the list of
> custom values per provider. ServerInfoAdminResource then could return a
> combined list of enum keys, both built-in and defined by providers. But I'm
> afraid that would require changes to API and/or interfaces. What do you
> think? How would you approach this problem yourself?
>

We have SPIs to make features pluggable so that's the way to go. We'd
probably want a AdminResourceTypeSpi and at the same time refactor the
current enum to use this.


>
> And BTW, what's wrong with the second PR? The github comment seems a bit
> unclear, so could you please elaborate? It has completely different scope,
> though deals with the same feature. It's not about exposing anything via
> static methods, it's about making ResourceType extensible, following a
> well-defined pattern. I was sure that Marek supported it, and I've
> implemented it in accordance with his recommendations.
>

Seemed rather hacky to me, but maybe I'm mistaking something. Can you show
an example on how it would actually be used? I don't see how you'd add
additional types and how you'd actually use the resource type not knowing
what type it is. Seems all operations valid on an enum becomes invalid in
this case.


>
> Please forgive my persistence, but I consider this an important feature.
> What we love about KeyCloak is its total extensibility. Having custom
> entities and realm resources is great, but not being able to log their
> events leaves a sensation of incompleteness.
>

NP, I appreciate and welcome it. However, bear in mind that we can't
accommodate every wish. Adding loads of little things used by only one user
would bloat the code base. At the very least it has to be well designed,
generically usable and documented.


>
> Cheers,
> Dmitry
>
> I don't like the PRs you've sent at all. It's all very hacky, calling
> static methods on other classes is far from elegant. I've rejected both
> PRs. It also ends up being completely undocumented so no-one except you
> would know about this.
>
> On 17 October 2016 at 21:15, Dmitry Telegin <mitya at cargosoft.ru> wrote:
>
> JIRA https://issues.jboss.org/browse/KEYCLOAK-3711
> PR https://github.com/keycloak/keycloak/pull/3337
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From sthorger at redhat.com  Wed Oct 19 01:08:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 19 Oct 2016 07:08:56 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
Message-ID: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>

Marko,

I've just been playing with the client registration cli and it's just plain
awesome.

This:
# kcreg.sh create myclient.json

Is so much better than:
# Open admin console
# Login
# Click clients
# Click create
# Click import file
# Click save

Nice work :)

From thomas.darimont at googlemail.com  Wed Oct 19 01:11:28 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 19 Oct 2016 07:11:28 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
In-Reply-To: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
References: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
Message-ID: <CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>

Cool stuff!

Is there a template for client.json?

Cheers,
Thomas

Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen" <sthorger at redhat.com>:

> Marko,
>
> I've just been playing with the client registration cli and it's just plain
> awesome.
>
> This:
> # kcreg.sh create myclient.json
>
> Is so much better than:
> # Open admin console
> # Login
> # Click clients
> # Click create
> # Click import file
> # Click save
>
> Nice work :)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Wed Oct 19 01:14:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 19 Oct 2016 07:14:16 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
In-Reply-To: <CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>
References: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
	<CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>
Message-ID: <CAJgngAfgsqkXpGG+csGNmmUAO7oKhZ4Ok0UK86NmHbshBdcbzw@mail.gmail.com>

It actually supports Keycloak client rep (same as used by admin console),
OIDC client representations (
https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata)
as well as SAML entity descriptors.

For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
options.

You can even do:

kcreg.sh create -s clientId=test -s redirectUris='["http://localhost","
http://localhost:8080"]'

On 19 October 2016 at 07:11, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Cool stuff!
>
> Is there a template for client.json?
>
> Cheers,
> Thomas
>
> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen" <sthorger at redhat.com>:
>
>> Marko,
>>
>> I've just been playing with the client registration cli and it's just
>> plain
>> awesome.
>>
>> This:
>> # kcreg.sh create myclient.json
>>
>> Is so much better than:
>> # Open admin console
>> # Login
>> # Click clients
>> # Click create
>> # Click import file
>> # Click save
>>
>> Nice work :)
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From thomas.darimont at googlemail.com  Wed Oct 19 03:16:34 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 19 Oct 2016 09:16:34 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
In-Reply-To: <CAJgngAfgsqkXpGG+csGNmmUAO7oKhZ4Ok0UK86NmHbshBdcbzw@mail.gmail.com>
References: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
	<CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>
	<CAJgngAfgsqkXpGG+csGNmmUAO7oKhZ4Ok0UK86NmHbshBdcbzw@mail.gmail.com>
Message-ID: <CAK-7U1ivaM4EjeqG+jNsV02riygU89oa4HJ2a024HT3T91MBEA@mail.gmail.com>

Hello,

ah great - I guess one could take the json from a fully configured client
as an example.

I used the following curl sequence get the client representation of an
existing client:


KC_REALM=dev
KC_USERNAME=realm-admin
KC_PASSWORD=test
KC_CLIENT=admin-client
KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
KC_SERVER=https://test-sso
KC_CONTEXT=auth
CURL_OPTS="-k -v --noproxy 192.168.99.1"

# Request Tokens for credentials
KC_RESPONSE=$( \
   curl $CURL_OPTS -X POST \
        -H "Content-Type: application/x-www-form-urlencoded" \
        -d "username=$KC_USERNAME" \
        -d "password=$KC_PASSWORD" \
        -d 'grant_type=password' \
        -d "client_id=$KC_CLIENT" \
        -d "client_secret=$KC_CLIENT_SECRET" \

"$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token" \
    | jq .
)

KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)

CLIENT_CLIENTID=myapp

curl -v \
       -k \
       -H "Authorization: Bearer $KC_ACCESS_TOKEN" \

$KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-registrations/default/$CLIENT_CLIENTID
\
      | jq .

Cheers,
Thomas

2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> It actually supports Keycloak client rep (same as used by admin console),
> OIDC client representations (https://openid.net/specs/
> openid-connect-registration-1_0.html#ClientMetadata) as well as SAML
> entity descriptors.
>
> For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
> options.
>
> You can even do:
>
> kcreg.sh create -s clientId=test -s redirectUris='["http://localhost","
> http://localhost:8080"]'
>
> On 19 October 2016 at 07:11, Thomas Darimont <thomas.darimont at googlemail.
> com> wrote:
>
>> Cool stuff!
>>
>> Is there a template for client.json?
>>
>> Cheers,
>> Thomas
>>
>> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen" <sthorger at redhat.com
>> >:
>>
>>> Marko,
>>>
>>> I've just been playing with the client registration cli and it's just
>>> plain
>>> awesome.
>>>
>>> This:
>>> # kcreg.sh create myclient.json
>>>
>>> Is so much better than:
>>> # Open admin console
>>> # Login
>>> # Click clients
>>> # Click create
>>> # Click import file
>>> # Click save
>>>
>>> Nice work :)
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

From mstrukel at redhat.com  Wed Oct 19 05:40:35 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 19 Oct 2016 11:40:35 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
In-Reply-To: <CAK-7U1ivaM4EjeqG+jNsV02riygU89oa4HJ2a024HT3T91MBEA@mail.gmail.com>
References: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
	<CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>
	<CAJgngAfgsqkXpGG+csGNmmUAO7oKhZ4Ok0UK86NmHbshBdcbzw@mail.gmail.com>
	<CAK-7U1ivaM4EjeqG+jNsV02riygU89oa4HJ2a024HT3T91MBEA@mail.gmail.com>
Message-ID: <CA+1OW+gVgK0ohUUCBgV3Mu3aeR1FTDi-5TEty61wh-hU_Edkaw@mail.gmail.com>

Thanks Stian!

It took a while to get it to this point, but hopefully it will suit well
different needs and scripting styles, and get used a lot.

There are still bugs in there I'm sure :)

Next on the list - Admin CLI ...

On Wed, Oct 19, 2016 at 9:16 AM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> ah great - I guess one could take the json from a fully configured client
> as an example.
>
> I used the following curl sequence get the client representation of an
> existing client:
>
>
> KC_REALM=dev
> KC_USERNAME=realm-admin
> KC_PASSWORD=test
> KC_CLIENT=admin-client
> KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
> KC_SERVER=https://test-sso
> KC_CONTEXT=auth
> CURL_OPTS="-k -v --noproxy 192.168.99.1"
>
> # Request Tokens for credentials
> KC_RESPONSE=$( \
>    curl $CURL_OPTS -X POST \
>         -H "Content-Type: application/x-www-form-urlencoded" \
>         -d "username=$KC_USERNAME" \
>         -d "password=$KC_PASSWORD" \
>         -d 'grant_type=password' \
>         -d "client_id=$KC_CLIENT" \
>         -d "client_secret=$KC_CLIENT_SECRET" \
>         "$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token"
> \
>     | jq .
> )
>
> KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
>
> CLIENT_CLIENTID=myapp
>
> curl -v \
>        -k \
>        -H "Authorization: Bearer $KC_ACCESS_TOKEN" \
>       $KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-
> registrations/default/$CLIENT_CLIENTID \
>       | jq .
>
> Cheers,
> Thomas
>
> 2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> It actually supports Keycloak client rep (same as used by admin console),
>> OIDC client representations (https://openid.net/specs/open
>> id-connect-registration-1_0.html#ClientMetadata) as well as SAML entity
>> descriptors.
>>
>> For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
>> options.
>>
>> You can even do:
>>
>> kcreg.sh create -s clientId=test -s redirectUris='["http://localhost","
>> http://localhost:8080"]'
>>
>> On 19 October 2016 at 07:11, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Cool stuff!
>>>
>>> Is there a template for client.json?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen" <sthorger at redhat.com
>>> >:
>>>
>>>> Marko,
>>>>
>>>> I've just been playing with the client registration cli and it's just
>>>> plain
>>>> awesome.
>>>>
>>>> This:
>>>> # kcreg.sh create myclient.json
>>>>
>>>> Is so much better than:
>>>> # Open admin console
>>>> # Login
>>>> # Click clients
>>>> # Click create
>>>> # Click import file
>>>> # Click save
>>>>
>>>> Nice work :)
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>

From mstrukel at redhat.com  Wed Oct 19 05:58:04 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 19 Oct 2016 11:58:04 +0200
Subject: [keycloak-dev] Client Registration CLI is awesome!!
In-Reply-To: <CAK-7U1ivaM4EjeqG+jNsV02riygU89oa4HJ2a024HT3T91MBEA@mail.gmail.com>
References: <CAJgngAda-urUtAhDt42bC3EmXWALdSbsCm_u_H7e=QMe_bv2kQ@mail.gmail.com>
	<CAK-7U1jBfxQYf1xj-K4cssCbj4ND0j7KNTbqf9codcsfd8iAgg@mail.gmail.com>
	<CAJgngAfgsqkXpGG+csGNmmUAO7oKhZ4Ok0UK86NmHbshBdcbzw@mail.gmail.com>
	<CAK-7U1ivaM4EjeqG+jNsV02riygU89oa4HJ2a024HT3T91MBEA@mail.gmail.com>
Message-ID: <CA+1OW+if8mp4xAQWZoZ1_ruC+cO-4A2Xm0=1f7Z8=D8izSVSpw@mail.gmail.com>

Thomas, you would now do the same using something like:

Set up truststore ($KC_TRUSTSTORE is path to .jks file with certificates
you trust):

$ kcreg.sh config truststore $KC_TRUSTSTORE --trustpass $KC_TRUSTPASS


Login:

$ kcreg.sh config credentials --server $KC_SERVER/$KC_CONTEXT --realm
$KC_REALM --user $KC_USERNAME --password $KC_PASSWORD --client $KC_CLIENT
--secret $KC_CLIENT_SECRET


And then you can do as many CRUD operations as you like:

$ kcreg.sh get $CLIENT_CLIENTID


Or if you just want a simple one liner you can actually put all the
parameters on a single command line, and make sure nothing (meaning tokens,
and secrets) is saved in private config file:

$ kcreg.sh get --no-config --server $KC_SERVER/$KC_CONTEXT --realm
$KC_REALM --user $KC_USERNAME --password $KC_PASSWORD --client $KC_CLIENT
--secret $KC_CLIENT_SECRET --truststore $KC_TRUSTSTORE --trustpass
$KC_TRUSTPASS $CLIENT_CLIENTID



On Wed, Oct 19, 2016 at 9:16 AM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hello,
>
> ah great - I guess one could take the json from a fully configured client
> as an example.
>
> I used the following curl sequence get the client representation of an
> existing client:
>
>
> KC_REALM=dev
> KC_USERNAME=realm-admin
> KC_PASSWORD=test
> KC_CLIENT=admin-client
> KC_CLIENT_SECRET=1f3d9b89-de75-4356-abe8-fab815cf9ce4
> KC_SERVER=https://test-sso
> KC_CONTEXT=auth
> CURL_OPTS="-k -v --noproxy 192.168.99.1"
>
> # Request Tokens for credentials
> KC_RESPONSE=$( \
>    curl $CURL_OPTS -X POST \
>         -H "Content-Type: application/x-www-form-urlencoded" \
>         -d "username=$KC_USERNAME" \
>         -d "password=$KC_PASSWORD" \
>         -d 'grant_type=password' \
>         -d "client_id=$KC_CLIENT" \
>         -d "client_secret=$KC_CLIENT_SECRET" \
>         "$KC_SERVER/$KC_CONTEXT/realms/$KC_REALM/protocol/openid-connect/token"
> \
>     | jq .
> )
>
> KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
>
> CLIENT_CLIENTID=myapp
>
> curl -v \
>        -k \
>        -H "Authorization: Bearer $KC_ACCESS_TOKEN" \
>       $KC_SERVER/$KC_CONTEXT/realms/eurodata-dev/clients-
> registrations/default/$CLIENT_CLIENTID \
>       | jq .
>
> Cheers,
> Thomas
>
> 2016-10-19 7:14 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> It actually supports Keycloak client rep (same as used by admin console),
>> OIDC client representations (https://openid.net/specs/open
>> id-connect-registration-1_0.html#ClientMetadata) as well as SAML entity
>> descriptors.
>>
>> For Keycloak client rep you can use "kcreg.sh attrs" to see the supported
>> options.
>>
>> You can even do:
>>
>> kcreg.sh create -s clientId=test -s redirectUris='["http://localhost","
>> http://localhost:8080"]'
>>
>> On 19 October 2016 at 07:11, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Cool stuff!
>>>
>>> Is there a template for client.json?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> Am 19.10.2016 7:09 vorm. schrieb "Stian Thorgersen" <sthorger at redhat.com
>>> >:
>>>
>>>> Marko,
>>>>
>>>> I've just been playing with the client registration cli and it's just
>>>> plain
>>>> awesome.
>>>>
>>>> This:
>>>> # kcreg.sh create myclient.json
>>>>
>>>> Is so much better than:
>>>> # Open admin console
>>>> # Login
>>>> # Click clients
>>>> # Click create
>>>> # Click import file
>>>> # Click save
>>>>
>>>> Nice work :)
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
>

From mbsoftkeycloak at hotmail.com  Wed Oct 19 10:42:04 2016
From: mbsoftkeycloak at hotmail.com (mbsoft keycloak)
Date: Wed, 19 Oct 2016 14:42:04 +0000
Subject: [keycloak-dev] Keycloak and Spring 4 MVC
Message-ID: <CO2PR0701MB776AFA622EDAB876091AFFCD3D20@CO2PR0701MB776.namprd07.prod.outlook.com>


Hi guys,
     I'm trying to include keycloak in my application based on Spring 4 MVC but I see that all the examples are on Spring Boot. No way to include keycloak in Sping MVC?

I hope you can help me !!!

>From already thank you very much


From sthorger at redhat.com  Wed Oct 19 11:31:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 19 Oct 2016 17:31:51 +0200
Subject: [keycloak-dev] Bug squashing time!!
Message-ID: <CAJgngAfAmLkgvBSrA8EYge25wdPhvs1CS5VXzoya2mBGv4NuXw@mail.gmail.com>

Let the race begin! Who can squash the most about of bugs for 2.4!

Anyone from the community that'd like to help us out? There's plenty to
pick from:
https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20and%20issuetype%20%3D%20bug%20and%20resolution%20%3D%20unresolved%20and%20assignee%20is%20empty

From sthorger at redhat.com  Thu Oct 20 00:58:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 20 Oct 2016 06:58:41 +0200
Subject: [keycloak-dev] Setting fixed max results on REST endpoints
Message-ID: <CAJgngAeaM8QcBdNGiwNgKdiWdz4ArwjnRLDh5Z1POqcQc5hcGw@mail.gmail.com>

Would it make sense to set a fixed max results on REST endpoints for all
endpoints that are paginated?

I propose we set it to fetch maximum 100 entries by default. To fetch
everything ?max=-1 or alternatively we could use ?all.

From mposolda at redhat.com  Thu Oct 20 11:38:18 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 20 Oct 2016 17:38:18 +0200
Subject: [keycloak-dev] Setting fixed max results on REST endpoints
In-Reply-To: <CAJgngAeaM8QcBdNGiwNgKdiWdz4ArwjnRLDh5Z1POqcQc5hcGw@mail.gmail.com>
References: <CAJgngAeaM8QcBdNGiwNgKdiWdz4ArwjnRLDh5Z1POqcQc5hcGw@mail.gmail.com>
Message-ID: <0c19c71e-9d62-0f31-5e2a-f4f29f679962@redhat.com>

+1 for 100 entries by default.

One good side effect is, that it will also fix the REST calls with IBM 
DB2. Those are currently broken AFAIR if you not set "max" in the REST 
request, as the underlying JPA query without "max" won't work with DB2.

I like ?max=-1 slightly more than ?all . Despite on IBM DB2 people will 
still need something like ?max=1000000 instead :-)

Marek


On 20/10/16 06:58, Stian Thorgersen wrote:
> Would it make sense to set a fixed max results on REST endpoints for all
> endpoints that are paginated?
>
> I propose we set it to fetch maximum 100 entries by default. To fetch
> everything ?max=-1 or alternatively we could use ?all.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From max.catarino at rps.com.br  Thu Oct 20 14:47:35 2016
From: max.catarino at rps.com.br (max.catarino at rps.com.br)
Date: Thu, 20 Oct 2016 16:47:35 -0200
Subject: [keycloak-dev] It's possible to check if an user have an
 active/valid session through REST API?
Message-ID: <d71c17402558f36af7c80d4a33ce9a8b@rps.com.br>

 

It's possible to check if an user have an active/valid session through
REST API? 

I saw the UserSessionRepresentation returned by
Keycloak.realm("realmId").users().get("userId").getUserSessions(). But
UserSessionRepresentation do not have the information I want. 
 

From sthorger at redhat.com  Thu Oct 20 15:21:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 20 Oct 2016 21:21:12 +0200
Subject: [keycloak-dev] It's possible to check if an user have an
 active/valid session through REST API?
In-Reply-To: <d71c17402558f36af7c80d4a33ce9a8b@rps.com.br>
References: <d71c17402558f36af7c80d4a33ce9a8b@rps.com.br>
Message-ID: <CAJgngAeY1P8dOT9mJPoFgRAH33YJtsDOwUK282u_CHY25-Shog@mail.gmail.com>

Please send general questions to the user mailing list.

On 20 October 2016 at 20:47, <max.catarino at rps.com.br> wrote:

>
>
> It's possible to check if an user have an active/valid session through
> REST API?
>
> I saw the UserSessionRepresentation returned by
> Keycloak.realm("realmId").users().get("userId").getUserSessions(). But
> UserSessionRepresentation do not have the information I want.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Fri Oct 21 02:18:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 21 Oct 2016 08:18:18 +0200
Subject: [keycloak-dev] Remember to close responses using admin client
Message-ID: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>

For methods on the admin client that return a Response it's important to
remember to close it. Failing to do this causes:

* Not freeing up connections
* Tests can fail intermittently as the tx may not be completed before you
move on

Ideal would be to find a way to prevent this and have the admin client
close the responses, but I don't think that's possible.

From sthorger at redhat.com  Fri Oct 21 05:21:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 21 Oct 2016 11:21:11 +0200
Subject: [keycloak-dev] Keycloak 2.3.0.CR1 is out
Message-ID: <CAJgngAfMDDPAKGejtTGTCBLppL3=XOEA1YKaRukwmKSoLJk2Ag@mail.gmail.com>

We've just released Keycloak 2.3.0.CR1. This release brings a number of new
existing features!

Highlights of the release includes:


   - *OpenID Connect certification* - We've now completed the work on
   making our OpenID Connect implementation pass the OpenID Connect
   certification and we're currently passing all 5 profiles!
   - *User SPI* - We now have a new simpler User SPI. This will make it
   easier to implement a custom user provider to pull in users from any
   external user store. In the next release we'll port our LDAP provider to
   this SPI, which will make it possible to pull in users from LDAP without
   syncing data to the Keycloak database. Once this work is completed we'll
   remove the old User Federation SPI.
   - *Realm Key Rotation* - We now support multiple keys in a realm. This
   makes it possible to seamlessly rotate keys without any impact to
   applications and users.
   - *Client Registration CLI* - A while back we added dynamic client
   registration capabilities, we've now created a CLI that makes it easy to
   register and update clients from the command-line.
   - *Dynamic Client Registration Policies* - We've introduced a mechanism
   to control what clients can be dynamically created. This includes the
   ability to define policies to allow clients to register without the need to
   authenticate.
   - *Node.js Adapter* - We've had a Node.js adapter a while, but we've now
   polished it a lot and made it a first class citizen.

For the full list of issues resolved check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.3.0.CR1>
and
to download the release go to the Keycloak homepage
<http://blog.keycloak.org/www.keycloak.org/downloads>.

From mposolda at redhat.com  Fri Oct 21 06:09:59 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 21 Oct 2016 12:09:59 +0200
Subject: [keycloak-dev] Remember to close responses using admin client
In-Reply-To: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>
References: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>
Message-ID: <71b78048-8fc6-4e46-c189-bb620c70b1fe@redhat.com>

On 21/10/16 08:18, Stian Thorgersen wrote:
> For methods on the admin client that return a Response it's important to
> remember to close it. Failing to do this causes:
>
> * Not freeing up connections
> * Tests can fail intermittently as the tx may not be completed before you
> move on
>
> Ideal would be to find a way to prevent this and have the admin client
> close the responses, but I don't think that's possible.
Maybe we already discuss,  that we can possibly avoid using "Response" 
object at most admin client operations.

We typically use them in "create" methods (POST requests). So if we 
refactor server-side to return the actual created object with filled ID, 
we can use something like:

ClientRepresentation createdClient = 
realmResource.clients().create(clientRepresentation);
String createdUuid = createdClient.getId();

instead of current:

Response response = realm.clients().create(rep);
response.close();
String createdUuid = ApiUtil.getCreatedId(response);


The advantages is that:
- No need to care about closing response
- Better exception handling - instead of checking response status etc, 
the new code will throw exception directly. Which is usually cleaner
- You don't need to send separate GET request to retrieve newly created 
client. And in most cases, you usually want newly created client

The possible disadvantage:
- The POST response is bigger as it contains representation of newly 
created client. However you probably usually need the new client anyway. 
Not sure if it's possible to set admin console (angular) to avoid 
sending separate GET request when the entity was already retrieved 
through POST, but I suppose that yes.

Marek

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



From grossws at gmail.com  Fri Oct 21 07:06:31 2016
From: grossws at gmail.com (Konstantin Gribov)
Date: Fri, 21 Oct 2016 11:06:31 +0000
Subject: [keycloak-dev] Jenkins discloses email list on notifications
Message-ID: <CALvb29wcL2Pxivyog=wqNSQF79tKj6wYVOCdFyZct0h0eLSEXw@mail.gmail.com>

Hi, folks.

Jenkins should use BCC instead of To for sending mass emails to avoid
emails disclosure. I'd say that it's not a big issue: these emails are
present in somewhere in commit history or interacted with Keycloak
development some way with high probability. But it's still not a good style
of mass email notifications.

RedHat guys, could you please bring this issue to attention of your infra
team which manages Jenkins?

-- 

Best regards,
Konstantin Gribov

From ssilvert at redhat.com  Fri Oct 21 08:51:35 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 21 Oct 2016 08:51:35 -0400
Subject: [keycloak-dev] Remember to close responses using admin client
In-Reply-To: <71b78048-8fc6-4e46-c189-bb620c70b1fe@redhat.com>
References: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>
	<71b78048-8fc6-4e46-c189-bb620c70b1fe@redhat.com>
Message-ID: <580A0F57.3000902@redhat.com>

On 10/21/2016 6:09 AM, Marek Posolda wrote:
> On 21/10/16 08:18, Stian Thorgersen wrote:
>> For methods on the admin client that return a Response it's important to
>> remember to close it. Failing to do this causes:
>>
>> * Not freeing up connections
>> * Tests can fail intermittently as the tx may not be completed before you
>> move on
>>
>> Ideal would be to find a way to prevent this and have the admin client
>> close the responses, but I don't think that's possible.
> Maybe we already discuss,  that we can possibly avoid using "Response"
> object at most admin client operations.
>
> We typically use them in "create" methods (POST requests). So if we
> refactor server-side to return the actual created object with filled ID,
> we can use something like:
>
> ClientRepresentation createdClient =
> realmResource.clients().create(clientRepresentation);
> String createdUuid = createdClient.getId();
>
> instead of current:
>
> Response response = realm.clients().create(rep);
> response.close();
> String createdUuid = ApiUtil.getCreatedId(response);
>
>
> The advantages is that:
> - No need to care about closing response
> - Better exception handling - instead of checking response status etc,
> the new code will throw exception directly. Which is usually cleaner
> - You don't need to send separate GET request to retrieve newly created
> client. And in most cases, you usually want newly created client
>
> The possible disadvantage:
> - The POST response is bigger as it contains representation of newly
> created client. However you probably usually need the new client anyway.
> Not sure if it's possible to set admin console (angular) to avoid
> sending separate GET request when the entity was already retrieved
> through POST, but I suppose that yes.
>
> Marek
Anything is possible, but that's not what is expected from a POST 
request.   From RFC-7231:

If one or more resources has been created on the origin server as a
    result of successfully processing a POST request, the origin server
    SHOULD send a 201 (Created) response containing a Location header
    field that provides an identifier for the primary resource created
    (Section 7.1.2  <https://tools.ietf.org/html/rfc7231#section-7.1.2>) and a representation that describes the status of the
    request while referring to the new resource(s).

So basically, the expected result is the identifier of the created 
resource and not the resource itself.

Maybe the problem can be solved by letting the admin client cache the 
responses before returning them to the caller.  Then our test harness 
can clean them up.
>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Mon Oct 24 00:26:26 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 24 Oct 2016 06:26:26 +0200
Subject: [keycloak-dev] Remember to close responses using admin client
In-Reply-To: <580A0F57.3000902@redhat.com>
References: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>
	<71b78048-8fc6-4e46-c189-bb620c70b1fe@redhat.com>
	<580A0F57.3000902@redhat.com>
Message-ID: <CAJgngAd4rbO89ZJQDQiOViTUEf2+rv4L7TL721cTEbHHc=_TvA@mail.gmail.com>

Maybe there is a way (or we can send a PR) to make RestEasy client return
location as a string for a method?

On 21 October 2016 at 14:51, Stan Silvert <ssilvert at redhat.com> wrote:

> On 10/21/2016 6:09 AM, Marek Posolda wrote:
> > On 21/10/16 08:18, Stian Thorgersen wrote:
> >> For methods on the admin client that return a Response it's important to
> >> remember to close it. Failing to do this causes:
> >>
> >> * Not freeing up connections
> >> * Tests can fail intermittently as the tx may not be completed before
> you
> >> move on
> >>
> >> Ideal would be to find a way to prevent this and have the admin client
> >> close the responses, but I don't think that's possible.
> > Maybe we already discuss,  that we can possibly avoid using "Response"
> > object at most admin client operations.
> >
> > We typically use them in "create" methods (POST requests). So if we
> > refactor server-side to return the actual created object with filled ID,
> > we can use something like:
> >
> > ClientRepresentation createdClient =
> > realmResource.clients().create(clientRepresentation);
> > String createdUuid = createdClient.getId();
> >
> > instead of current:
> >
> > Response response = realm.clients().create(rep);
> > response.close();
> > String createdUuid = ApiUtil.getCreatedId(response);
> >
> >
> > The advantages is that:
> > - No need to care about closing response
> > - Better exception handling - instead of checking response status etc,
> > the new code will throw exception directly. Which is usually cleaner
> > - You don't need to send separate GET request to retrieve newly created
> > client. And in most cases, you usually want newly created client
> >
> > The possible disadvantage:
> > - The POST response is bigger as it contains representation of newly
> > created client. However you probably usually need the new client anyway.
> > Not sure if it's possible to set admin console (angular) to avoid
> > sending separate GET request when the entity was already retrieved
> > through POST, but I suppose that yes.
> >
> > Marek
> Anything is possible, but that's not what is expected from a POST
> request.   From RFC-7231:
>
> If one or more resources has been created on the origin server as a
>     result of successfully processing a POST request, the origin server
>     SHOULD send a 201 (Created) response containing a Location header
>     field that provides an identifier for the primary resource created
>     (Section 7.1.2  <https://tools.ietf.org/html/rfc7231#section-7.1.2>)
> and a representation that describes the status of the
>     request while referring to the new resource(s).
>
> So basically, the expected result is the identifier of the created
> resource and not the resource itself.
>
> Maybe the problem can be solved by letting the admin client cache the
> responses before returning them to the caller.  Then our test harness
> can clean them up.
> >
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct 24 00:27:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 24 Oct 2016 06:27:16 +0200
Subject: [keycloak-dev] Jenkins discloses email list on notifications
In-Reply-To: <CALvb29wcL2Pxivyog=wqNSQF79tKj6wYVOCdFyZct0h0eLSEXw@mail.gmail.com>
References: <CALvb29wcL2Pxivyog=wqNSQF79tKj6wYVOCdFyZct0h0eLSEXw@mail.gmail.com>
Message-ID: <CAJgngAeqy1gCuz6BFRVSU-+nakRBNLaRhFQTvWvyCzHDh-V12w@mail.gmail.com>

What emails are you referring to?

On 21 October 2016 at 13:06, Konstantin Gribov <grossws at gmail.com> wrote:

> Hi, folks.
>
> Jenkins should use BCC instead of To for sending mass emails to avoid
> emails disclosure. I'd say that it's not a big issue: these emails are
> present in somewhere in commit history or interacted with Keycloak
> development some way with high probability. But it's still not a good style
> of mass email notifications.
>
> RedHat guys, could you please bring this issue to attention of your infra
> team which manages Jenkins?
>
> --
>
> Best regards,
> Konstantin Gribov
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Mon Oct 24 05:20:39 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 24 Oct 2016 11:20:39 +0200
Subject: [keycloak-dev] Remember to close responses using admin client
In-Reply-To: <580A0F57.3000902@redhat.com>
References: <CAJgngAdHihZp37NGv77i06xTOe6myAtdqfQYqXB43Rf=WJO4iQ@mail.gmail.com>
	<71b78048-8fc6-4e46-c189-bb620c70b1fe@redhat.com>
	<580A0F57.3000902@redhat.com>
Message-ID: <cb9a2395-c925-0d5f-4c0c-aa403e0c4fdb@redhat.com>

On 10/21/2016 02:51 PM, Stan Silvert wrote:
> On 10/21/2016 6:09 AM, Marek Posolda wrote:
>> On 21/10/16 08:18, Stian Thorgersen wrote:
>>> For methods on the admin client that return a Response it's important to
>>> remember to close it. Failing to do this causes:
>>>
>>> * Not freeing up connections
>>> * Tests can fail intermittently as the tx may not be completed before you
>>> move on
>>>
>>> Ideal would be to find a way to prevent this and have the admin client
>>> close the responses, but I don't think that's possible.
>> Maybe we already discuss,  that we can possibly avoid using "Response"
>> object at most admin client operations.
>>
>> We typically use them in "create" methods (POST requests). So if we
>> refactor server-side to return the actual created object with filled ID,
>> we can use something like:
>>
>> ClientRepresentation createdClient =
>> realmResource.clients().create(clientRepresentation);
>> String createdUuid = createdClient.getId();
>>
>> instead of current:
>>
>> Response response = realm.clients().create(rep);
>> response.close();
>> String createdUuid = ApiUtil.getCreatedId(response);
>>
>>
>> The advantages is that:
>> - No need to care about closing response
>> - Better exception handling - instead of checking response status etc,
>> the new code will throw exception directly. Which is usually cleaner
>> - You don't need to send separate GET request to retrieve newly created
>> client. And in most cases, you usually want newly created client
>>
>> The possible disadvantage:
>> - The POST response is bigger as it contains representation of newly
>> created client. However you probably usually need the new client anyway.
>> Not sure if it's possible to set admin console (angular) to avoid
>> sending separate GET request when the entity was already retrieved
>> through POST, but I suppose that yes.
>>
>> Marek
> Anything is possible, but that's not what is expected from a POST
> request.   From RFC-7231:
>
> If one or more resources has been created on the origin server as a
>      result of successfully processing a POST request, the origin server
>      SHOULD send a 201 (Created) response containing a Location header
>      field that provides an identifier for the primary resource created
>      (Section 7.1.2  <https://tools.ietf.org/html/rfc7231#section-7.1.2>) and a representation that describes the status of the
>      request while referring to the new resource(s).
>
> So basically, the expected result is the identifier of the created
> resource and not the resource itself.

I second Marek's suggestions, it would also make API cleaner. AFAIR the 
RFC quote refers to Location header field, not the response body. So 
returning the ID in the Location header field (as it is now already) 
plus the detail of created object in the body would be in line with the 
spec. There are other samples of APIs returning object detail in the 
body when returning 201 Created, e.g. [1, 2]

--Hynek

[1] https://wiki.openstack.org/wiki/Neutron/APIv2-specification
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html-single/REST_API_Guide/

>
> Maybe the problem can be solved by letting the admin client cache the
> responses before returning them to the caller.  Then our test harness
> can clean them up.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From max.catarino at rps.com.br  Mon Oct 24 09:49:46 2016
From: max.catarino at rps.com.br (max.catarino at rps.com.br)
Date: Mon, 24 Oct 2016 11:49:46 -0200
Subject: [keycloak-dev] Fwd: It's possible to check if an user have an
 active/valid session through REST API?
In-Reply-To: <d71c17402558f36af7c80d4a33ce9a8b@rps.com.br>
References: <d71c17402558f36af7c80d4a33ce9a8b@rps.com.br>
Message-ID: <58ec4e9c5bac78e45dd0b93a9829a8f9@rps.com.br>

 

Please, someone can answer me? 

-------- Mensagem original -------- 

 		ASSUNTO:
 		It's possible to check if an user have an active/valid session
through REST API?

 		DATA:
 		20.10.2016 16:47

 		DE:
 		max.catarino at rps.com.br

 		PARA:
 		keycloak-dev at lists.jboss.org

It's possible to check if an user have an active/valid session through
REST API? 

I saw the UserSessionRepresentation returned by
Keycloak.realm("realmId").users().get("userId").getUserSessions(). But
UserSessionRepresentation do not have the information I want. 

 

From grossws at gmail.com  Mon Oct 24 10:00:34 2016
From: grossws at gmail.com (Konstantin Gribov)
Date: Mon, 24 Oct 2016 14:00:34 +0000
Subject: [keycloak-dev] Jenkins discloses email list on notifications
In-Reply-To: <CAJgngAeqy1gCuz6BFRVSU-+nakRBNLaRhFQTvWvyCzHDh-V12w@mail.gmail.com>
References: <CALvb29wcL2Pxivyog=wqNSQF79tKj6wYVOCdFyZct0h0eLSEXw@mail.gmail.com>
	<CAJgngAeqy1gCuz6BFRVSU-+nakRBNLaRhFQTvWvyCzHDh-V12w@mail.gmail.com>
Message-ID: <CALvb29wuBXkogYtvec0OWXvLRpxXOtJ+tYHdauCscQ7WUbgKpQ@mail.gmail.com>

Stian,
email from ci-builds at redhat.com with subject
"keycloak_master_jdk8-windows-TMP - Build # 3 - Failure!" with URL
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/keycloak_master_jdk8-windows-TMP/3/

Full message is attached below.

??, 24 ???. 2016 ?. ? 7:27, Stian Thorgersen <sthorger at redhat.com>:

> What emails are you referring to?
>
> On 21 October 2016 at 13:06, Konstantin Gribov <grossws at gmail.com> wrote:
>
> Hi, folks.
>
> Jenkins should use BCC instead of To for sending mass emails to avoid
> emails disclosure. I'd say that it's not a big issue: these emails are
> present in somewhere in commit history or interacted with Keycloak
> development some way with high probability. But it's still not a good style
> of mass email notifications.
>
> RedHat guys, could you please bring this issue to attention of your infra
> team which manages Jenkins?
>
>
> --
>
> Best regards,
> Konstantin Gribov
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --

Best regards,
Konstantin Gribov

From mposolda at redhat.com  Mon Oct 24 12:05:23 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 24 Oct 2016 18:05:23 +0200
Subject: [keycloak-dev] Jenkins discloses email list on notifications
In-Reply-To: <CALvb29wuBXkogYtvec0OWXvLRpxXOtJ+tYHdauCscQ7WUbgKpQ@mail.gmail.com>
References: <CALvb29wcL2Pxivyog=wqNSQF79tKj6wYVOCdFyZct0h0eLSEXw@mail.gmail.com>
	<CAJgngAeqy1gCuz6BFRVSU-+nakRBNLaRhFQTvWvyCzHDh-V12w@mail.gmail.com>
	<CALvb29wuBXkogYtvec0OWXvLRpxXOtJ+tYHdauCscQ7WUbgKpQ@mail.gmail.com>
Message-ID: <9050a8cc-6653-a9a4-765e-f489b0daa320@redhat.com>

I am not sure how it happened as the project 
"keycloak_master_jdk8-windows-TMP" was removed from our jenkins longer 
time ago. However I did some changes in the configuration, so hope you 
won't receive the notification anymore. Let me know if you still see them.

Marek

On 24/10/16 16:00, Konstantin Gribov wrote:
> Stian,
> email from ci-builds at redhat.com with subject
> "keycloak_master_jdk8-windows-TMP - Build # 3 - Failure!" with URL
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/keycloak_master_jdk8-windows-TMP/3/
>
> Full message is attached below.
>
> ??, 24 ???. 2016 ?. ? 7:27, Stian Thorgersen <sthorger at redhat.com>:
>
>> What emails are you referring to?
>>
>> On 21 October 2016 at 13:06, Konstantin Gribov <grossws at gmail.com> wrote:
>>
>> Hi, folks.
>>
>> Jenkins should use BCC instead of To for sending mass emails to avoid
>> emails disclosure. I'd say that it's not a big issue: these emails are
>> present in somewhere in commit history or interacted with Keycloak
>> development some way with high probability. But it's still not a good style
>> of mass email notifications.
>>
>> RedHat guys, could you please bring this issue to attention of your infra
>> team which manages Jenkins?
>>
>>
>> --
>>
>> Best regards,
>> Konstantin Gribov
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
> Best regards,
> Konstantin Gribov
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Wed Oct 26 06:45:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 26 Oct 2016 12:45:41 +0200
Subject: [keycloak-dev] Keycloak 2.3.0.Final Released
Message-ID: <CAJgngAfOfNQtCApxEUcZn6k+rY8ZVduMuL5BUEvO_HLwTB-xvA@mail.gmail.com>

Keycloak 2.3.0.Final has just been released.

For the list of resolved issues check out JIRA
<https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.3.0.Final>
and
to download the release go to the Keycloak homepage
<http://www.keycloak.org/downloads>. Before you upgrade refer to the migration
guide
<https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/MigrationFromOlderVersions.html>

From martin.hardselius at gmail.com  Wed Oct 26 10:16:28 2016
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Wed, 26 Oct 2016 14:16:28 +0000
Subject: [keycloak-dev] Keycloak 2.3.0.Final Released
In-Reply-To: <CAJgngAfOfNQtCApxEUcZn6k+rY8ZVduMuL5BUEvO_HLwTB-xvA@mail.gmail.com>
References: <CAJgngAfOfNQtCApxEUcZn6k+rY8ZVduMuL5BUEvO_HLwTB-xvA@mail.gmail.com>
Message-ID: <CAPJq0L9p_MTDusfsY6W7wki6zo5X7zvBjG9xvBKNLRsr0Rdu4Q@mail.gmail.com>

Awesome! I might come off as a bit impatient but the artifacts are missing
from https://mvnrepository.com/ ;)

Anyways, great job!

Regards,
Martin

On Wed, 26 Oct 2016 at 12:46 Stian Thorgersen <sthorger at redhat.com> wrote:

> Keycloak 2.3.0.Final has just been released.
>
> For the list of resolved issues check out JIRA
> <
> https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%202.3.0.Final
> >
> and
> to download the release go to the Keycloak homepage
> <http://www.keycloak.org/downloads>. Before you upgrade refer to the
> migration
> guide
> <
> https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/MigrationFromOlderVersions.html
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Thu Oct 27 02:29:55 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 27 Oct 2016 08:29:55 +0200
Subject: [keycloak-dev] Keycloak 2.3.0.Final Released
In-Reply-To: <CAPJq0L9p_MTDusfsY6W7wki6zo5X7zvBjG9xvBKNLRsr0Rdu4Q@mail.gmail.com>
References: <CAJgngAfOfNQtCApxEUcZn6k+rY8ZVduMuL5BUEvO_HLwTB-xvA@mail.gmail.com>
	<CAPJq0L9p_MTDusfsY6W7wki6zo5X7zvBjG9xvBKNLRsr0Rdu4Q@mail.gmail.com>
Message-ID: <CAJgngAfPnjR1TDGpJZxfSCyBKMZ1OQtfyer0BNZoY3eXJqrOLw@mail.gmail.com>

That'll be my fault. Fixing it now and they should be available soon.

On 26 October 2016 at 16:16, Martin Hardselius <martin.hardselius at gmail.com>
wrote:

> Awesome! I might come off as a bit impatient but the artifacts are missing
> from https://mvnrepository.com/ ;)
>
> Anyways, great job!
>
> Regards,
> Martin
>
> On Wed, 26 Oct 2016 at 12:46 Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> Keycloak 2.3.0.Final has just been released.
>>
>> For the list of resolved issues check out JIRA
>> <https://issues.jboss.org/issues/?jql=project%20%3D%
>> 20keycloak%20and%20fixVersion%20%3D%202.3.0.Final>
>> and
>> to download the release go to the Keycloak homepage
>> <http://www.keycloak.org/downloads>. Before you upgrade refer to the
>> migration
>> guide
>> <https://keycloak.gitbooks.io/server-adminstration-guide/content/topics/
>> MigrationFromOlderVersions.html>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

From martin.hardselius at gmail.com  Fri Oct 28 10:01:06 2016
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Fri, 28 Oct 2016 14:01:06 +0000
Subject: [keycloak-dev] 2.3.0.Final error when refreshing half-way into
	browser auth flow
Message-ID: <CAPJq0L_ro3EyiYZqo9sdPFW_Sg7gUbdVw8pbCffH7+W84RyE3w@mail.gmail.com>

There seems to be a problem with refreshing in the middle of browser auth
flow with more than one authenticators configured. The problem also appears
when refreshing the consent view.

ClientSessionCode#verifyCode() fails.

This was not an issue pre 2.3.0.Final to my knowledge.

Steps to reproduce the error.

1. Create a user
2. Log into the account client
3. Configure OTP
4. Logout
5. Login username/password
6. Refresh the page asking for OTP

or

1. Tick 'require consent' for the account client
2. Try to log in to the account client
3. Refresh consent view

Is this intended behaviour as of now, or is it an actual bug introduced in
the latest build?

From j.kamal at ymail.com  Fri Oct 28 13:24:17 2016
From: j.kamal at ymail.com (Kamal Jagadevan)
Date: Fri, 28 Oct 2016 17:24:17 +0000 (UTC)
Subject: [keycloak-dev] Memory leak fix merge to 1.9.x releases
References: <1772112574.590008.1477675457458.ref@mail.yahoo.com>
Message-ID: <1772112574.590008.1477675457458@mail.yahoo.com>

Hello Stian,? Currently we have Keycloak 1.9.2 in production and recently we observed memory leak issue with lots of users logging in and creating sessions simultaneously.Further noticed this has been taken care as part of [KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue TrackerBut unfortunately those fixes didnt? get merged to 1.9.x releases.
Are there any plans for merging those fixes to 1.9.x releases? Hope there is nothing blocking for this to be merged.If there are no plans, would you accept a PR from the DEV community to do so ....of course after testing...
Please let us know at your earliest!!
***** Happy Halloween *****
BestKamal


  
|  
|   
|   
|   |    |

   |

  |
|  
|   |  
[KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue Tracker
   |   |

  |

  |

 


From bburke at redhat.com  Fri Oct 28 16:45:30 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Oct 2016 16:45:30 -0400
Subject: [keycloak-dev] porting LDAP to new model
Message-ID: <7ec3f25c-d93a-9bd0-80cc-acdf9d9a32ac@redhat.com>

Was looking at LDAPFederationProvider today and thinking about how it 
would be ported to new model.

* I think it may be possible to re-use most of the code.  The code 
currently assumes that the UserModel is imported into keycloak local 
storage.  What I think we can do is have an in-memory implementation of 
UserModel.  If import is disabled, we create an instance of this pojo.  
This becomes a delegate, and we execute the import logic for mappers.  
Proxy would also be called and just proxy the pojo instance.

* we get rid of the "always read from LDAP" option.  For the new model, 
users will be cached.  If the cache is hit, then the provider is never 
hit.  Since we now have cache policies per UserStorageProvider, I don't 
think its an issue to remove this feature.

Devil is in the details, but I don't think this will be that bad.  Its 
just a matter of converting things to use the ComponentModel


From bburke at redhat.com  Fri Oct 28 16:50:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Oct 2016 16:50:49 -0400
Subject: [keycloak-dev] callback event when realm is cached
Message-ID: <3ed336e4-08ed-3057-f8b9-4b8975aaca4f@redhat.com>

There is a new callback event

CachedRealmModel.RealmCachedEvent

Whenever a realm is cached, this event is fired off.  Each cached 
RealmModel instance will can be typecasted to CachedRealmModel which 
will allow developers to cache additional things along with the realm.  
This will be very useful for providers that want to do some 
initialization to speed up processing.


From bburke at redhat.com  Fri Oct 28 16:53:04 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Oct 2016 16:53:04 -0400
Subject: [keycloak-dev] User SPI cache policies
Message-ID: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>

You can now define cache policies per UserStorageProvider.

* NO_CACHE - don't cache users loaded from this provider

* MAX_LIFESPAN - max lifespan of user in cache

* EVICT_DAILY - specify a time of day when the cache will be expired 
every day.

* EVICT_WEEKLY - specify a day of the week and time of day when the 
cache will be expired.


Bill


From bburke at redhat.com  Fri Oct 28 17:00:29 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 28 Oct 2016 17:00:29 -0400
Subject: [keycloak-dev] disabling credential types
Message-ID: <90db1da2-3d5a-6b29-7ce8-b7dffe142801@redhat.com>

Admin console user credential tab has been changed.  It will now list 
"disabable credential types".  This will be a list of credential types 
that can be disabled by the admin (i.e. OTP, PASSWORD, CERT, etc..).  
All this hooks into the Credential SPI that I went over a few weeks 
ago.  So, if new credential types are created, they should show up in 
the console too.

Note that disabling happens per credential type, and not per device 
(i.e. OTP).  I honestly could not figure out how to have an SPI and 
generic admin console UI that would take into account ideas like 
multiple OTPs, certs, etc...So, disabling is done per type, not per OTP 
generator.  These are the SPI items that are the backbone of this 
feature.  They are methods on UserCredentialManager

/** * Calls disableCredential on UserStorageProvider and 
UserFederationProviders first, then loop through * each 
CredentialProvider. * * @param realm * @param user * @param 
credentialType */ void disableCredentialType(RealmModel realm, UserModel user, String credentialType);

/** * Returns a set of credential types that can be disabled by 
disableCredentialType() method * * @param realm * @param user * @return */ Set<String> getDisableableCredentialTypes(RealmModel realm, UserModel user);

CredentialProviders and UserStorageProviders will be required to 
implement these methods if they support credential updates.

From sthorger at redhat.com  Mon Oct 31 01:43:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 06:43:29 +0100
Subject: [keycloak-dev] Memory leak fix merge to 1.9.x releases
In-Reply-To: <1772112574.590008.1477675457458@mail.yahoo.com>
References: <1772112574.590008.1477675457458.ref@mail.yahoo.com>
	<1772112574.590008.1477675457458@mail.yahoo.com>
Message-ID: <CAJgngAfSviq6bEpc056osQeEx9pif3kvugMA-iOEkxyCgWc7Vg@mail.gmail.com>

Hi,

We do not maintain 1.9 in community any longer. If you need long term
support of a release please get Red Hat Single Sign-On. 7.0 is based of
Keycloak 1.9.8.Final.

With regards to KEYCLOAK-3202 you don't actually need the fix as the
workaround I added to the comment in the issue is more than sufficient
solution if you are experiencing this issue.

On 28 October 2016 at 19:24, Kamal Jagadevan <j.kamal at ymail.com> wrote:

> Hello Stian,  Currently we have Keycloak 1.9.2 in production and recently
> we observed memory leak issue with lots of users logging in and creating
> sessions simultaneously.Further noticed this has been taken care as part of
> [KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue TrackerBut
> unfortunately those fixes didnt  get merged to 1.9.x releases.
> Are there any plans for merging those fixes to 1.9.x releases? Hope there
> is nothing blocking for this to be merged.If there are no plans, would you
> accept a PR from the DEV community to do so ....of course after testing...
> Please let us know at your earliest!!
> ***** Happy Halloween *****
> BestKamal
>
>
>
> |
> |
> |
> |   |    |
>
>    |
>
>   |
> |
> |   |
> [KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue Tracker
>    |   |
>
>   |
>
>   |
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



On 28 October 2016 at 19:24, Kamal Jagadevan <j.kamal at ymail.com> wrote:

> Hello Stian,  Currently we have Keycloak 1.9.2 in production and recently
> we observed memory leak issue with lots of users logging in and creating
> sessions simultaneously.Further noticed this has been taken care as part of
> [KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue TrackerBut
> unfortunately those fixes didnt  get merged to 1.9.x releases.
> Are there any plans for merging those fixes to 1.9.x releases? Hope there
> is nothing blocking for this to be merged.If there are no plans, would you
> accept a PR from the DEV community to do so ....of course after testing...
> Please let us know at your earliest!!
> ***** Happy Halloween *****
> BestKamal
>
>
>
> |
> |
> |
> |   |    |
>
>    |
>
>   |
> |
> |   |
> [KEYCLOAK-3202] Creating users causes memory leak - JBoss Issue Tracker
>    |   |
>
>   |
>
>   |
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Mon Oct 31 01:46:14 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 06:46:14 +0100
Subject: [keycloak-dev] disabling credential types
In-Reply-To: <90db1da2-3d5a-6b29-7ce8-b7dffe142801@redhat.com>
References: <90db1da2-3d5a-6b29-7ce8-b7dffe142801@redhat.com>
Message-ID: <CAJgngAfrjfnZvg3OdQnTT4A4CfG07HGEk1d7n7M0yQ3TSGMOVQ@mail.gmail.com>

Can you explain the rational behind this? I don't understand what the
use-case is and why you would want to "disable" credentials.

On 28 October 2016 at 23:00, Bill Burke <bburke at redhat.com> wrote:

> Admin console user credential tab has been changed.  It will now list
> "disabable credential types".  This will be a list of credential types
> that can be disabled by the admin (i.e. OTP, PASSWORD, CERT, etc..).
> All this hooks into the Credential SPI that I went over a few weeks
> ago.  So, if new credential types are created, they should show up in
> the console too.
>
> Note that disabling happens per credential type, and not per device
> (i.e. OTP).  I honestly could not figure out how to have an SPI and
> generic admin console UI that would take into account ideas like
> multiple OTPs, certs, etc...So, disabling is done per type, not per OTP
> generator.  These are the SPI items that are the backbone of this
> feature.  They are methods on UserCredentialManager
>
> /** * Calls disableCredential on UserStorageProvider and
> UserFederationProviders first, then loop through * each
> CredentialProvider. * * @param realm * @param user * @param
> credentialType */ void disableCredentialType(RealmModel realm, UserModel
> user, String credentialType);
>
> /** * Returns a set of credential types that can be disabled by
> disableCredentialType() method * * @param realm * @param user * @return */
> Set<String> getDisableableCredentialTypes(RealmModel realm, UserModel
> user);
>
> CredentialProviders and UserStorageProviders will be required to
> implement these methods if they support credential updates.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct 31 01:48:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 06:48:06 +0100
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
Message-ID: <CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>

What about evict on authenticate (load from store when user authenticates)?
I think that would be the most useful policy.

Should we have the same type of policy support on the KC database?



On 28 October 2016 at 22:53, Bill Burke <bburke at redhat.com> wrote:

> You can now define cache policies per UserStorageProvider.
>
> * NO_CACHE - don't cache users loaded from this provider
>
> * MAX_LIFESPAN - max lifespan of user in cache
>
> * EVICT_DAILY - specify a time of day when the cache will be expired
> every day.
>
> * EVICT_WEEKLY - specify a day of the week and time of day when the
> cache will be expired.
>
>
> Bill
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct 31 01:54:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 06:54:06 +0100
Subject: [keycloak-dev] callback event when realm is cached
In-Reply-To: <3ed336e4-08ed-3057-f8b9-4b8975aaca4f@redhat.com>
References: <3ed336e4-08ed-3057-f8b9-4b8975aaca4f@redhat.com>
Message-ID: <CAJgngAd2t0TJ3iHrG-JXBnLz02N7fQCUxdzd6yS+OK052v71TQ@mail.gmail.com>

I'm not sure I see how this would be used. Does it not mean that all
components need to know if they are used within the realm themselves? They
need to load/init everything when the realm is loaded rather than if/when
they are used? Also, don't see why this has to happen when the realm is
cached as we use a invalidation cache this data can be added anytime.

For key providers I needed a similar functionality so just added a map with
notes to the ComponentModel. I think that's simpler to use, see:
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/keys/AbstractRsaKeyProvider.java#L50

On 28 October 2016 at 22:50, Bill Burke <bburke at redhat.com> wrote:

> There is a new callback event
>
> CachedRealmModel.RealmCachedEvent
>
> Whenever a realm is cached, this event is fired off.  Each cached
> RealmModel instance will can be typecasted to CachedRealmModel which
> will allow developers to cache additional things along with the realm.
> This will be very useful for providers that want to do some
> initialization to speed up processing.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Mon Oct 31 02:29:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 07:29:10 +0100
Subject: [keycloak-dev] 2.3.0.Final error when refreshing half-way into
 browser auth flow
In-Reply-To: <CAPJq0L_ro3EyiYZqo9sdPFW_Sg7gUbdVw8pbCffH7+W84RyE3w@mail.gmail.com>
References: <CAPJq0L_ro3EyiYZqo9sdPFW_Sg7gUbdVw8pbCffH7+W84RyE3w@mail.gmail.com>
Message-ID: <CAJgngAc7bxyUXY52m2gE4dh-kPRVb1rgHfZ0GmdngAkC315Vbw@mail.gmail.com>

Can you create a JIRA please?

On 28 October 2016 at 16:01, Martin Hardselius <martin.hardselius at gmail.com>
wrote:

> There seems to be a problem with refreshing in the middle of browser auth
> flow with more than one authenticators configured. The problem also appears
> when refreshing the consent view.
>
> ClientSessionCode#verifyCode() fails.
>
> This was not an issue pre 2.3.0.Final to my knowledge.
>
> Steps to reproduce the error.
>
> 1. Create a user
> 2. Log into the account client
> 3. Configure OTP
> 4. Logout
> 5. Login username/password
> 6. Refresh the page asking for OTP
>
> or
>
> 1. Tick 'require consent' for the account client
> 2. Try to log in to the account client
> 3. Refresh consent view
>
> Is this intended behaviour as of now, or is it an actual bug introduced in
> the latest build?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From martin.hardselius at gmail.com  Mon Oct 31 04:14:22 2016
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Mon, 31 Oct 2016 08:14:22 +0000
Subject: [keycloak-dev] 2.3.0.Final error when refreshing half-way into
 browser auth flow
In-Reply-To: <CAJgngAc7bxyUXY52m2gE4dh-kPRVb1rgHfZ0GmdngAkC315Vbw@mail.gmail.com>
References: <CAPJq0L_ro3EyiYZqo9sdPFW_Sg7gUbdVw8pbCffH7+W84RyE3w@mail.gmail.com>
	<CAJgngAc7bxyUXY52m2gE4dh-kPRVb1rgHfZ0GmdngAkC315Vbw@mail.gmail.com>
Message-ID: <CAPJq0L_9kt7BwnWsRA3mfrK05828+xGUXQR=OgndLmgKbss9QA@mail.gmail.com>

Created https://issues.jboss.org/browse/KEYCLOAK-3835.

On Mon, 31 Oct 2016 at 07:29 Stian Thorgersen <sthorger at redhat.com> wrote:

> Can you create a JIRA please?
>
> On 28 October 2016 at 16:01, Martin Hardselius <
> martin.hardselius at gmail.com> wrote:
>
> There seems to be a problem with refreshing in the middle of browser auth
> flow with more than one authenticators configured. The problem also appears
> when refreshing the consent view.
>
> ClientSessionCode#verifyCode() fails.
>
> This was not an issue pre 2.3.0.Final to my knowledge.
>
> Steps to reproduce the error.
>
> 1. Create a user
> 2. Log into the account client
> 3. Configure OTP
> 4. Logout
> 5. Login username/password
> 6. Refresh the page asking for OTP
>
> or
>
> 1. Tick 'require consent' for the account client
> 2. Try to log in to the account client
> 3. Refresh consent view
>
> Is this intended behaviour as of now, or is it an actual bug introduced in
> the latest build?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

From mposolda at redhat.com  Mon Oct 31 04:51:50 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Oct 2016 09:51:50 +0100
Subject: [keycloak-dev] porting LDAP to new model
In-Reply-To: <7ec3f25c-d93a-9bd0-80cc-acdf9d9a32ac@redhat.com>
References: <7ec3f25c-d93a-9bd0-80cc-acdf9d9a32ac@redhat.com>
Message-ID: <4b5b487d-c977-29ca-d009-00586d97e038@redhat.com>

On 28/10/16 22:45, Bill Burke wrote:
> Was looking at LDAPFederationProvider today and thinking about how it
> would be ported to new model.
>
> * I think it may be possible to re-use most of the code.  The code
> currently assumes that the UserModel is imported into keycloak local
> storage.  What I think we can do is have an in-memory implementation of
> UserModel.  If import is disabled, we create an instance of this pojo.
> This becomes a delegate, and we execute the import logic for mappers.
> Proxy would also be called and just proxy the pojo instance.
>
> * we get rid of the "always read from LDAP" option.  For the new model,
> users will be cached.  If the cache is hit, then the provider is never
> hit.  Since we now have cache policies per UserStorageProvider, I don't
> think its an issue to remove this feature.
+1 for remove "always read from LDAP"

I also wonder about the UNSYNCED usecase (When user is updated in 
Keycloak, changes are saved into Keycloak DB, not to LDAP) . It seems 
that for this particular use-case, users will need to be imported?


Marek
>
> Devil is in the details, but I don't think this will be that bad.  Its
> just a matter of converting things to use the ComponentModel
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From mauriciogiacomini at hotmail.com  Mon Oct 31 07:33:42 2016
From: mauriciogiacomini at hotmail.com (=?iso-8859-1?Q?Maur=EDcio_Giacomini_Penteado?=)
Date: Mon, 31 Oct 2016 11:33:42 +0000
Subject: [keycloak-dev] Oauth_Token_Request_State change problem
Message-ID: <CY1PR0501MB180441B329BB99FE2CA4D603A8AE0@CY1PR0501MB1804.namprd05.prod.outlook.com>

Hello everybody.

In my app when I do login using keycloak javascript lib I receive correctly an Oauth_Token_Request_State but none of my rest service calls are returning their when page is loaded.

Strangely after login if I process a rest service call directly from the browser?s address bar I receive an error (*) reported on server but the Oauth_Token_Request_State is changed by a JSESSIONID and all my rest service calls pass to work without problems.

Is there some way to programmatically change Oauth_Token_Request_State by a JSESSIONID to avoid this situation?

Please, if anyone can help me, I will be very grateful.

Regards,
Maur?cio.

(*)
08:54:14,544 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-36) RESTEASY002010: Failed to execute: javax.ws.rs.NotFoundException: RESTEASY003210: Could not find resource for full path: http://mydomain.com:8080/services/rs/priv/auth/sayHello
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:114)
at org.jboss.resteasy.core.registry.RootNode.match(RootNode.java:43)
at org.jboss.resteasy.core.registry.RootClassNode.match(RootClassNode.java:48)
at org.jboss.resteasy.core.ResourceMethodRegistry.getResourceInvoker(ResourceMethodRegistry.java:445)
at org.jboss.resteasy.core.SynchronousDispatcher.getInvoker(SynchronousDispatcher.java:257)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:194)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
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: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 org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66)
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.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
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 org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
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)


From hmlnarik at redhat.com  Mon Oct 31 07:48:35 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Oct 2016 12:48:35 +0100
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
Message-ID: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>

Hi All,

re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used 
for signing for every signature (assertion/document-level) to validate 
the signature with the correct key. In POST binding, dsig:KeyInfo 
element bears this information in dsig:KeyName both for signed 
assertions and for the whole document (a.k.a. protocol message).

For REDIRECT binding in SAML, there is currently no place where KeyID 
can be inserted on document level. The document signature in REDIRECT 
binding has to be removed from the document (line 578 in [2]) and 
replaced by the Signature query parameter, so it is not advisable to put 
key ID there.

To solve this, there are multiple options:

1) Modify SAML assertion by adding <Extensions> element that would 
include document signing key ID. For consistency reasons, this would 
also be present for POST binding SAML documents. This only works for 
SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
2) Pass signing key ID in REDIRECT query parameter (next to Signature 
and SigAlg parameters) - seems not strictly against the spec but weird
3) Pass signing key ID in custom HTTP header - this might impact 
clustering setup and is even weirder than the previous item
4) Claim REDIRECT binding not supporting signatures signed with key 
rotation and only support them for POST bindings (for REDIRECT, it would 
only work for preset public keys). This is not a viable option for 
dynamic key retrieval, so including just for completeness.

Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?

Thanks

--Hynek

[1] https://issues.jboss.org/browse/KEYCLOAK-1881
[2] https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

From bburke at redhat.com  Mon Oct 31 08:42:32 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Oct 2016 08:42:32 -0400
Subject: [keycloak-dev] disabling credential types
In-Reply-To: <CAJgngAfrjfnZvg3OdQnTT4A4CfG07HGEk1d7n7M0yQ3TSGMOVQ@mail.gmail.com>
References: <90db1da2-3d5a-6b29-7ce8-b7dffe142801@redhat.com>
	<CAJgngAfrjfnZvg3OdQnTT4A4CfG07HGEk1d7n7M0yQ3TSGMOVQ@mail.gmail.com>
Message-ID: <70a15f00-ed8a-7082-9e81-b2563f0baf2c@redhat.com>

User has lost their mobile phone (OTP).  User's laptop was stolen 
(CERT).  For OTP it used to be a switch on the User "isOtp, setOtp".  
There was no way to turn off any other credential type. FYI disabling a 
credential type doesn't mean that the user can just login.  If the auth 
flow requires a credential type and it is not configured it will either 
abort or, if the credential type is optional, it will fire a required 
action to set up that type.


On 10/31/16 1:46 AM, Stian Thorgersen wrote:
> Can you explain the rational behind this? I don't understand what the 
> use-case is and why you would want to "disable" credentials.
>
> On 28 October 2016 at 23:00, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Admin console user credential tab has been changed.  It will now list
>     "disabable credential types".  This will be a list of credential types
>     that can be disabled by the admin (i.e. OTP, PASSWORD, CERT, etc..).
>     All this hooks into the Credential SPI that I went over a few weeks
>     ago.  So, if new credential types are created, they should show up in
>     the console too.
>
>     Note that disabling happens per credential type, and not per device
>     (i.e. OTP).  I honestly could not figure out how to have an SPI and
>     generic admin console UI that would take into account ideas like
>     multiple OTPs, certs, etc...So, disabling is done per type, not
>     per OTP
>     generator.  These are the SPI items that are the backbone of this
>     feature.  They are methods on UserCredentialManager
>
>     /** * Calls disableCredential on UserStorageProvider and
>     UserFederationProviders first, then loop through * each
>     CredentialProvider. * * @param realm * @param user * @param
>     credentialType */ void disableCredentialType(RealmModel realm,
>     UserModel user, String credentialType);
>
>     /** * Returns a set of credential types that can be disabled by
>     disableCredentialType() method * * @param realm * @param user *
>     @return */ Set<String> getDisableableCredentialTypes(RealmModel
>     realm, UserModel user);
>
>     CredentialProviders and UserStorageProviders will be required to
>     implement these methods if they support credential updates.
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From mitya at cargosoft.ru  Mon Oct 31 08:44:22 2016
From: mitya at cargosoft.ru (Dmitry Telegin)
Date: Mon, 31 Oct 2016 15:44:22 +0300
Subject: [keycloak-dev] BeerCloak: a comprehensive KeyCloak extension example
Message-ID: <1477917862.6853.1.camel@cargosoft.ru>

Hi,

For a while, I've been working on a complex KeyCloak extension (for
those interested - it adds support for hardware OTP generators with
lifecycle management, provisioning etc.)

In the course of my work, I have developed some techniques not
documented elsewhere that I'd like to share. The main focus is creating
custom realm admin resources (even not yet having an official admin
resource SPI). However, this could also serve as a general-purpose
example that combines several SPIs in a form of complete, ready-to-use
extension.

https://github.com/dteleguin/beercloak

As the name suggests, the extension brings into KeyCloak... well, beer
:) you can manage a list of beers, and even try to virtually "drink"
some amount to know how drunk you will be.

Humor aside, what's under the hood:

* a JPA entity (using Entity SPI) and LiquiBase changelog;
* a REST resource (using Realm Resource SPI) with CRUD operations and
one special operation ("drink");
* admin console GUI extensions (using theme mechanism) that work with
REST resource.

Now what makes it "admin resource":

* new roles "view-beer" and "manage-beer" are automatically added to
every existing and newly added realms, as well as included into the
master "admin" role;
* an AdminAuth instance is initialized and subsequently used to secure
REST operations;
* an AdminEventBuilder is initialized to be used for event logging.

Future ideas include adding "Beer" tab for users, where the favorite
beer kind could be chosen; this would be to demonstrate many-to-one and
many-to-one relationships between system entities and custom entities.
This could be later used to create a "secret question"-like
authenticator that would ask a user to enter his/her correct beer
preference.

If there is demand, I think I could turn this example into a complete
tutorial and maybe publish it on GitBooks. Let me know what you think.

Cheers, Dmitry

From bburke at redhat.com  Mon Oct 31 08:49:26 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Oct 2016 08:49:26 -0400
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
Message-ID: <a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>



On 10/31/16 1:48 AM, Stian Thorgersen wrote:
> What about evict on authenticate (load from store when user 
> authenticates)? I think that would be the most useful policy.
>
That would need to be implemented at the authenticator level.

> Should we have the same type of policy support on the KC database?
>
Thought about that, but isn't this already configured via infinispan?



From sthorger at redhat.com  Mon Oct 31 08:51:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 13:51:51 +0100
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
Message-ID: <CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>

On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>
>> What about evict on authenticate (load from store when user
>> authenticates)? I think that would be the most useful policy.
>>
>> That would need to be implemented at the authenticator level.


Implementation details aside, should we not have it? It seems like the most
likely time you want to fetch the user and especially credentials.


>
>
> Should we have the same type of policy support on the KC database?
>>
>> Thought about that, but isn't this already configured via infinispan?
>

Yes/no. It's configured globally for all realms and can't easily be
reconfigured through the admin console at runtime.

From bburke at redhat.com  Mon Oct 31 09:01:26 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Oct 2016 09:01:26 -0400
Subject: [keycloak-dev] callback event when realm is cached
In-Reply-To: <CAJgngAd2t0TJ3iHrG-JXBnLz02N7fQCUxdzd6yS+OK052v71TQ@mail.gmail.com>
References: <3ed336e4-08ed-3057-f8b9-4b8975aaca4f@redhat.com>
	<CAJgngAd2t0TJ3iHrG-JXBnLz02N7fQCUxdzd6yS+OK052v71TQ@mail.gmail.com>
Message-ID: <8d5e8981-a1e0-6567-7864-56ab8b3d08d9@redhat.com>



On 10/31/16 1:54 AM, Stian Thorgersen wrote:
> I'm not sure I see how this would be used. Does it not mean that all 
> components need to know if they are used within the realm themselves? 
> They need to load/init everything when the realm is loaded rather than 
> if/when they are used? Also, don't see why this has to happen when the 
> realm is cached as we use a invalidation cache this data can be added 
> anytime.
>

True enough.  I can remove the event then.

> For key providers I needed a similar functionality so just added a map 
> with notes to the ComponentModel. I think that's simpler to use, see:
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/keys/AbstractRsaKeyProvider.java#L50
>
Works, but in this case you don't know if you're working with a cached 
model or not.


From bburke at redhat.com  Mon Oct 31 09:08:19 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Oct 2016 09:08:19 -0400
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
	<CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
Message-ID: <aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>



On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>
>
> On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>
>         What about evict on authenticate (load from store when user
>         authenticates)? I think that would be the most useful policy.
>
>     That would need to be implemented at the authenticator level.
>
>
> Implementation details aside, should we not have it? It seems like the 
> most likely time you want to fetch the user and especially credentials.
Yeah, its a great idea.  Implementation details matter though as I'm not 
sure this can be reliably done without coding this in each top-level 
authenticator and requiring an authenticator provider developer to be 
aware of this policy.

Bill

From jdennis at redhat.com  Mon Oct 31 09:09:27 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 31 Oct 2016 09:09:27 -0400
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
Message-ID: <6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>

On 10/31/2016 07:48 AM, Hynek Mlnarik wrote:
> Hi All,
>
> re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
> for signing for every signature (assertion/document-level) to validate
> the signature with the correct key. In POST binding, dsig:KeyInfo
> element bears this information in dsig:KeyName both for signed
> assertions and for the whole document (a.k.a. protocol message).
>
> For REDIRECT binding in SAML, there is currently no place where KeyID
> can be inserted on document level. The document signature in REDIRECT
> binding has to be removed from the document (line 578 in [2]) and
> replaced by the Signature query parameter, so it is not advisable to put
> key ID there.
>
> To solve this, there are multiple options:
>
> 1) Modify SAML assertion by adding <Extensions> element that would
> include document signing key ID. For consistency reasons, this would
> also be present for POST binding SAML documents. This only works for
> SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
> 2) Pass signing key ID in REDIRECT query parameter (next to Signature
> and SigAlg parameters) - seems not strictly against the spec but weird
> 3) Pass signing key ID in custom HTTP header - this might impact
> clustering setup and is even weirder than the previous item
> 4) Claim REDIRECT binding not supporting signatures signed with key
> rotation and only support them for POST bindings (for REDIRECT, it would
> only work for preset public keys). This is not a viable option for
> dynamic key retrieval, so including just for completeness.
>
> Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
>
> Thanks
>
> --Hynek
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-1881
> [2] https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

I'm confused because I don't understand what problem you're trying to 
solve. It sounds like you want to lookup up a key based on an ID 
received in a SAML message. But you already know the keys associated 
with the client because they are bound to the client via the client's 
entityID. Could you clarify please?


-- 
John

From hmlnarik at redhat.com  Mon Oct 31 09:22:56 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Oct 2016 14:22:56 +0100
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
Message-ID: <876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>

The use case is to support key rotation with SAML, where the realm keys 
are used for signing the assertions, similarly to key rotation support 
for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound 
to a particular realm (IdP to SP direction, SP verifies IdP's 
signature), and can be rotated at IdP on demand. IdP can provide 
multiple valid keys for the realm, e.g. current and previous 
certificates for signature validation to allow seamless key rotation. 
Hence key ID information needs to be included with the assertion/message 
to provide hint on which key was used for signing. For details, please 
see comments KEYCLOAK-1881 [including comments].

--Hynek


On 10/31/2016 02:09 PM, John Dennis wrote:
> On 10/31/2016 07:48 AM, Hynek Mlnarik wrote:
>> Hi All,
>>
>> re KEYCLOAK-1881 [1]: Key rotation in SAML needs to distill key ID used
>> for signing for every signature (assertion/document-level) to validate
>> the signature with the correct key. In POST binding, dsig:KeyInfo
>> element bears this information in dsig:KeyName both for signed
>> assertions and for the whole document (a.k.a. protocol message).
>>
>> For REDIRECT binding in SAML, there is currently no place where KeyID
>> can be inserted on document level. The document signature in REDIRECT
>> binding has to be removed from the document (line 578 in [2]) and
>> replaced by the Signature query parameter, so it is not advisable to put
>> key ID there.
>>
>> To solve this, there are multiple options:
>>
>> 1) Modify SAML assertion by adding <Extensions> element that would
>> include document signing key ID. For consistency reasons, this would
>> also be present for POST binding SAML documents. This only works for
>> SAML 2.0 but that does not matter as REDIRECT is new to SAML2.0 anyway.
>> 2) Pass signing key ID in REDIRECT query parameter (next to Signature
>> and SigAlg parameters) - seems not strictly against the spec but weird
>> 3) Pass signing key ID in custom HTTP header - this might impact
>> clustering setup and is even weirder than the previous item
>> 4) Claim REDIRECT binding not supporting signatures signed with key
>> rotation and only support them for POST bindings (for REDIRECT, it would
>> only work for preset public keys). This is not a viable option for
>> dynamic key retrieval, so including just for completeness.
>>
>> Seems like Option 1 or 2 is the one to go. Any thoughts/suggestions?
>>
>> Thanks
>>
>> --Hynek
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-1881
>> [2] 
>> https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
>
> I'm confused because I don't understand what problem you're trying to 
> solve. It sounds like you want to lookup up a key based on an ID 
> received in a SAML message. But you already know the keys associated 
> with the client because they are bound to the client via the client's 
> entityID. Could you clarify please?
>
>


From sthorger at redhat.com  Mon Oct 31 09:41:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 14:41:46 +0100
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
	<CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
	<aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
Message-ID: <CAJgngAfxkCdOXnEa8Ob31zqJB_T_A6hWXwx3Mt8HgJfHiDsO6A@mail.gmail.com>

Could we not do it as a special first authenticator in the flow?

On 31 October 2016 at 14:08, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>
>
>
> On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>>
>>> What about evict on authenticate (load from store when user
>>> authenticates)? I think that would be the most useful policy.
>>>
>>> That would need to be implemented at the authenticator level.
>
>
> Implementation details aside, should we not have it? It seems like the
> most likely time you want to fetch the user and especially credentials.
>
>
> Yeah, its a great idea.  Implementation details matter though as I'm not
> sure this can be reliably done without coding this in each top-level
> authenticator and requiring an authenticator provider developer to be aware
> of this policy.
>
> Bill
>

From sthorger at redhat.com  Mon Oct 31 09:42:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 31 Oct 2016 14:42:54 +0100
Subject: [keycloak-dev] callback event when realm is cached
In-Reply-To: <8d5e8981-a1e0-6567-7864-56ab8b3d08d9@redhat.com>
References: <3ed336e4-08ed-3057-f8b9-4b8975aaca4f@redhat.com>
	<CAJgngAd2t0TJ3iHrG-JXBnLz02N7fQCUxdzd6yS+OK052v71TQ@mail.gmail.com>
	<8d5e8981-a1e0-6567-7864-56ab8b3d08d9@redhat.com>
Message-ID: <CAJgngAc+0DxS6WFw7KrcA4hzb3uLoeHEXa_qFp9iZMJPFv4xZA@mail.gmail.com>

On 31 October 2016 at 14:01, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 10/31/16 1:54 AM, Stian Thorgersen wrote:
>
> I'm not sure I see how this would be used. Does it not mean that all
> components need to know if they are used within the realm themselves? They
> need to load/init everything when the realm is loaded rather than if/when
> they are used? Also, don't see why this has to happen when the realm is
> cached as we use a invalidation cache this data can be added anytime.
>
>
> True enough.  I can remove the event then.
>
> For key providers I needed a similar functionality so just added a map
> with notes to the ComponentModel. I think that's simpler to use, see:
> https://github.com/keycloak/keycloak/blob/master/services/
> src/main/java/org/keycloak/keys/AbstractRsaKeyProvider.java#L50
>
> Works, but in this case you don't know if you're working with a cached
> model or not.
>
>
True. but my assumption was that a note can be available. So if the model
is not cached the note is only available for the session, but if it's
cached then it's available until the component is removed from the cache.

From mposolda at redhat.com  Mon Oct 31 09:50:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Oct 2016 14:50:07 +0100
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
	<CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
	<aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
Message-ID: <497aa628-e5d0-5d56-5000-825e07999894@redhat.com>

On 31/10/16 14:08, Bill Burke wrote:
>
> On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>
>> On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>      On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>>
>>          What about evict on authenticate (load from store when user
>>          authenticates)? I think that would be the most useful policy.
>>
>>      That would need to be implemented at the authenticator level.
>>
>>
>> Implementation details aside, should we not have it? It seems like the
>> most likely time you want to fetch the user and especially credentials.
> Yeah, its a great idea.  Implementation details matter though as I'm not
> sure this can be reliably done without coding this in each top-level
> authenticator and requiring an authenticator provider developer to be
> aware of this policy.
How about having separate methods on UserProvider for lookup user, which 
will allow to lookup user from storage and invalidate him afterwards in 
case that "authenticator-invalidation" policy is configured?

UserModel getUserByUsername(String username, RealmModel realm, boolean 
fresh);

if "fresh" is true, user will need to be lookup from persistent storage 
and invalidated from cache afterwards.


Or even have something on KeycloakSession like:

UserFederationManager users(boolean fresh);

which will return some proxy instance of UserFederationManager, which is 
doing it for all user lookup methods?

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



From mposolda at redhat.com  Mon Oct 31 09:52:14 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 31 Oct 2016 14:52:14 +0100
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <CAJgngAfxkCdOXnEa8Ob31zqJB_T_A6hWXwx3Mt8HgJfHiDsO6A@mail.gmail.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
	<CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
	<aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
	<CAJgngAfxkCdOXnEa8Ob31zqJB_T_A6hWXwx3Mt8HgJfHiDsO6A@mail.gmail.com>
Message-ID: <486251eb-5a72-deab-21e9-42aba384b9ed@redhat.com>

On 31/10/16 14:41, Stian Thorgersen wrote:
> Could we not do it as a special first authenticator in the flow?
It seems that won't handle for example authentication with identity 
providers? As Identity providers don't use authentication flows.

Marek
>
> On 31 October 2016 at 14:08, Bill Burke <bburke at redhat.com> wrote:
>
>>
>> On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>
>>
>>
>> On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>> On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>>>
>>>> What about evict on authenticate (load from store when user
>>>> authenticates)? I think that would be the most useful policy.
>>>>
>>>> That would need to be implemented at the authenticator level.
>>
>> Implementation details aside, should we not have it? It seems like the
>> most likely time you want to fetch the user and especially credentials.
>>
>>
>> Yeah, its a great idea.  Implementation details matter though as I'm not
>> sure this can be reliably done without coding this in each top-level
>> authenticator and requiring an authenticator provider developer to be aware
>> of this policy.
>>
>> Bill
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From jdennis at redhat.com  Mon Oct 31 09:56:33 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 31 Oct 2016 09:56:33 -0400
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
Message-ID: <dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>

On 10/31/2016 09:22 AM, Hynek Mlnarik wrote:
> The use case is to support key rotation with SAML, where the realm keys
> are used for signing the assertions, similarly to key rotation support
> for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
> to a particular realm (IdP to SP direction, SP verifies IdP's
> signature), and can be rotated at IdP on demand. IdP can provide
> multiple valid keys for the realm, e.g. current and previous
> certificates for signature validation to allow seamless key rotation.
> Hence key ID information needs to be included with the assertion/message
> to provide hint on which key was used for signing. For details, please
> see comments KEYCLOAK-1881 [including comments].

Yes, I understand the key rotation issue, what I don't understand is why 
you need a key id. Both the SP and the IdP can identify the key based on 
the entityID in the SAML message. In the case of key rotation there is 
an ordered list of keys. You obtain the list based on the entityID and 
iterate over the list trying each key in succession.

What value is there in sending the key id in the SAML message? It's an 
optimization that only works if each party knows how to interpret that 
value and to the best of my knowledge there is no interoperability 
mechanism defined for this. Remember it's the receiving party that must 
select the correct key to verify the signature or decrypt a message. 
Only the sending party can insert the key id into the message, so even 
if you included the key id I don't understand what it's accomplishing 
because the receiving party would have to interpret that value (the 
sending party which knows the key based on ID but it would never see the 
key id in a message).


-- 
John

From thomas.darimont at googlemail.com  Mon Oct 31 10:48:44 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 31 Oct 2016 15:48:44 +0100
Subject: [keycloak-dev] BeerCloak: a comprehensive KeyCloak extension
	example
In-Reply-To: <1477917862.6853.1.camel@cargosoft.ru>
References: <1477917862.6853.1.camel@cargosoft.ru>
Message-ID: <CAK-7U1hKHrTztGFT1_3VGEb=R+Yuegz5XK=ib612Hcg_TXL_3w@mail.gmail.com>

Hello Dmitry,

this is so cool! Just what I needed :)
Thank you very much!

Cheers,
Thomas

2016-10-31 13:44 GMT+01:00 Dmitry Telegin <mitya at cargosoft.ru>:

> Hi,
>
> For a while, I've been working on a complex KeyCloak extension (for
> those interested - it adds support for hardware OTP generators with
> lifecycle management, provisioning etc.)
>
> In the course of my work, I have developed some techniques not
> documented elsewhere that I'd like to share. The main focus is creating
> custom realm admin resources (even not yet having an official admin
> resource SPI). However, this could also serve as a general-purpose
> example that combines several SPIs in a form of complete, ready-to-use
> extension.
>
> https://github.com/dteleguin/beercloak
>
> As the name suggests, the extension brings into KeyCloak... well, beer
> :) you can manage a list of beers, and even try to virtually "drink"
> some amount to know how drunk you will be.
>
> Humor aside, what's under the hood:
>
> * a JPA entity (using Entity SPI) and LiquiBase changelog;
> * a REST resource (using Realm Resource SPI) with CRUD operations and
> one special operation ("drink");
> * admin console GUI extensions (using theme mechanism) that work with
> REST resource.
>
> Now what makes it "admin resource":
>
> * new roles "view-beer" and "manage-beer" are automatically added to
> every existing and newly added realms, as well as included into the
> master "admin" role;
> * an AdminAuth instance is initialized and subsequently used to secure
> REST operations;
> * an AdminEventBuilder is initialized to be used for event logging.
>
> Future ideas include adding "Beer" tab for users, where the favorite
> beer kind could be chosen; this would be to demonstrate many-to-one and
> many-to-one relationships between system entities and custom entities.
> This could be later used to create a "secret question"-like
> authenticator that would ask a user to enter his/her correct beer
> preference.
>
> If there is demand, I think I could turn this example into a complete
> tutorial and maybe publish it on GitBooks. Let me know what you think.
>
> Cheers, Dmitry
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Mon Oct 31 10:53:17 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Oct 2016 15:53:17 +0100
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
	<dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
Message-ID: <a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>

That trying to test every key is exactly what I'm trying to avoid. 
You're right that the verifying party needs to understand how to 
determine key ID. Fortunately, in the case where Keycloak is both 
signing and validating so this condition is satisfied.

I guess I'd have to go that way you suggest for REDIRECT if no other 
option proves viable, but trying to test every and each available public 
key to a verification of SAML signature seems both suboptimal and 
guessing - which is not a good sign of a secure solution. Though this 
may be needed for a communication between KC and non-KC, for KC-to-KC 
communication, this type of guessing should be avoided if a valid way 
exists.

On 10/31/2016 02:56 PM, John Dennis wrote:
> On 10/31/2016 09:22 AM, Hynek Mlnarik wrote:
>> The use case is to support key rotation with SAML, where the realm keys
>> are used for signing the assertions, similarly to key rotation support
>> for OIDC introduced in 2.3.0 ( KEYCLOAK-905). Hence the keys are bound
>> to a particular realm (IdP to SP direction, SP verifies IdP's
>> signature), and can be rotated at IdP on demand. IdP can provide
>> multiple valid keys for the realm, e.g. current and previous
>> certificates for signature validation to allow seamless key rotation.
>> Hence key ID information needs to be included with the assertion/message
>> to provide hint on which key was used for signing. For details, please
>> see comments KEYCLOAK-1881 [including comments].
>
> Yes, I understand the key rotation issue, what I don't understand is 
> why you need a key id. Both the SP and the IdP can identify the key 
> based on the entityID in the SAML message. In the case of key rotation 
> there is an ordered list of keys. You obtain the list based on the 
> entityID and iterate over the list trying each key in succession.
>
> What value is there in sending the key id in the SAML message? It's an 
> optimization that only works if each party knows how to interpret that 
> value and to the best of my knowledge there is no interoperability 
> mechanism defined for this. Remember it's the receiving party that 
> must select the correct key to verify the signature or decrypt a 
> message. Only the sending party can insert the key id into the 
> message, so even if you included the key id I don't understand what 
> it's accomplishing because the receiving party would have to interpret 
> that value (the sending party which knows the key based on ID but it 
> would never see the key id in a message).
>
>


From jdennis at redhat.com  Mon Oct 31 11:13:40 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 31 Oct 2016 11:13:40 -0400
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
	<dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
	<a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>
Message-ID: <4c74cea9-88a6-c79f-119f-f66d8f3c9d1b@redhat.com>

On 10/31/2016 10:53 AM, Hynek Mlnarik wrote:
> Fortunately, in the case where Keycloak is both signing and
> validating so this condition is satisfied.

When is KC both signing a SAML message and validating the same signature?

> Though this may be needed for a communication between KC and non-KC,
> for KC-to-KC communication, this type of guessing should be avoided
> if a valid way exists.

In SAML messages are one-way. There is KC-to-SP communication and 
SP-to-KC communication. What is this KC-to-KC communication you refer to?

-- 
John

From hmlnarik at redhat.com  Mon Oct 31 11:36:47 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Oct 2016 16:36:47 +0100
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <4c74cea9-88a6-c79f-119f-f66d8f3c9d1b@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
	<dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
	<a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>
	<4c74cea9-88a6-c79f-119f-f66d8f3c9d1b@redhat.com>
Message-ID: <91ba1884-c6dc-1b9a-d8d6-51c34a9b1f33@redhat.com>

Surely KC implements both SAML SP and IdP. I am afraid that in a strict 
sense, there is also no KC-to-SP or SP-to-KC communiication. But by 
natural extension of concepts, by "KC-to-KC", an IdP-to-SP communication 
is meant where KC is implementor of both parts. SAML 2.0 is designed to 
be extensible and allows Implementation specific extensions that are not 
interpreted if the receiving party does not know how to handle them. 
This is interoperable as long as the meaning of the original SAML 
message retains the same meaning. Hints like key ID are hence valid use 
of this extension.

Just for the record - SAML IdP is represented by KC server, SAML SP part 
is handled by KC adapters.

--Hynek


On 10/31/2016 04:13 PM, John Dennis wrote:
> On 10/31/2016 10:53 AM, Hynek Mlnarik wrote:
>> Fortunately, in the case where Keycloak is both signing and
>> validating so this condition is satisfied.
>
> When is KC both signing a SAML message and validating the same signature?
>
>> Though this may be needed for a communication between KC and non-KC,
>> for KC-to-KC communication, this type of guessing should be avoided
>> if a valid way exists.
>
> In SAML messages are one-way. There is KC-to-SP communication and 
> SP-to-KC communication. What is this KC-to-KC communication you refer to?
>


From jdennis at redhat.com  Mon Oct 31 13:14:32 2016
From: jdennis at redhat.com (John Dennis)
Date: Mon, 31 Oct 2016 13:14:32 -0400
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <91ba1884-c6dc-1b9a-d8d6-51c34a9b1f33@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
	<dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
	<a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>
	<4c74cea9-88a6-c79f-119f-f66d8f3c9d1b@redhat.com>
	<91ba1884-c6dc-1b9a-d8d6-51c34a9b1f33@redhat.com>
Message-ID: <abd74f72-4a48-c7de-c453-4df40f44f122@redhat.com>

On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
> Surely KC implements both SAML SP and IdP.

KC is mostly an IdP. The only case I'm aware of where KC operates as an 
SP is when KC federates to another IdP (i.e. KC is an identity hub that 
is configured to authenticate against other IdP's). For the optimization 
you're discussing to be workable the other IdP must also understand the 
key id usage (i.e. is another KC instance) *and* share the key id's. 
That seems to me to be an uncommon deployment.

> I am afraid that in a strict sense, there is also no KC-to-SP or
> SP-to-KC communiication.

Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.

> But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP
> communication is meant where KC is implementor of both parts.

See above.

> SAML 2.0 is designed to be extensible and allows Implementation
> specific extensions that are not interpreted if the receiving party
> does not know how to handle them. This is interoperable as long as
> the meaning of the original SAML message retains the same meaning.
> Hints like key ID are hence valid use of this extension.

Sure, but I still don't understand when you could take advantage of this 
(see above). How often do you think KC is going to federate to another 
KC instance that shares the same key ids?

> Just for the record - SAML IdP is represented by KC server, SAML SP
> part is handled by KC adapters.


-- 
John

From hmlnarik at redhat.com  Mon Oct 31 14:00:28 2016
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Mon, 31 Oct 2016 19:00:28 +0100
Subject: [keycloak-dev] Support for key rotation in SAML Redirect binding
In-Reply-To: <abd74f72-4a48-c7de-c453-4df40f44f122@redhat.com>
References: <58aa2fa8-3481-2c4a-49ac-b598df2ff560@redhat.com>
	<6099fbdc-08a3-ec73-7551-0613da4fc74d@redhat.com>
	<876cd989-74f1-58b9-922a-cadb382562fa@redhat.com>
	<dd42670b-cde6-d274-09fe-72cb22a6b62b@redhat.com>
	<a1e3d706-f8e8-9c08-899a-b5546036b47c@redhat.com>
	<4c74cea9-88a6-c79f-119f-f66d8f3c9d1b@redhat.com>
	<91ba1884-c6dc-1b9a-d8d6-51c34a9b1f33@redhat.com>
	<abd74f72-4a48-c7de-c453-4df40f44f122@redhat.com>
Message-ID: <fb99274f-09a7-100b-4d20-f07b54897c01@redhat.com>

Well, this discussion drove completely away from the original question. 
I prefer to focus on resolving the actual issue.

Just to summarize:

1. In SAML, typically IdP to SP communication and vice versa is relevant.

2. KC implements IdP (server) and securing part of SP (adapter). Indeed, 
it does not implement actual service provider's functionality, only the 
part that in involved in SAML-related communication.

3. There are other IdP and SP SAML implementors than KC.

4. There is high chance, even though definitely not 100%, that KC IdP 
would communicate with SP secured by KC-native adapter. Please see the 
KC guide for further information [1].

5. KC SAML adapters should be able to take advantage of knowledge of key 
ID to have signature validation performed using the right key on the 
first try.

The original question was how to achieve Item 5 in terms of how to pass 
the key ID - whether in SAML protocol message or outside of it.

Thank you

--Hynek

[1] 
https://keycloak.gitbooks.io/securing-client-applications-guide/content/v/2.3/topics/saml/java/general-config.html

On 10/31/2016 06:14 PM, John Dennis wrote:
> On 10/31/2016 11:36 AM, Hynek Mlnarik wrote:
>> Surely KC implements both SAML SP and IdP.
>
> KC is mostly an IdP. The only case I'm aware of where KC operates as 
> an SP is when KC federates to another IdP (i.e. KC is an identity hub 
> that is configured to authenticate against other IdP's). For the 
> optimization you're discussing to be workable the other IdP must also 
> understand the key id usage (i.e. is another KC instance) *and* share 
> the key id's. That seems to me to be an uncommon deployment.
>
>> I am afraid that in a strict sense, there is also no KC-to-SP or
>> SP-to-KC communiication.
>
> Really? SAML is mostly IdP-to-SP and SP-to-Idp communication.
Did I say anything else?
>
>> But by natural extension of concepts, by "KC-to-KC", an IdP-to-SP
>> communication is meant where KC is implementor of both parts.
>
> See above.
>
>> SAML 2.0 is designed to be extensible and allows Implementation
>> specific extensions that are not interpreted if the receiving party
>> does not know how to handle them. This is interoperable as long as
>> the meaning of the original SAML message retains the same meaning.
>> Hints like key ID are hence valid use of this extension.
>
> Sure, but I still don't understand when you could take advantage of 
> this (see above). How often do you think KC is going to federate to 
> another KC instance that shares the same key ids?
>
>> Just for the record - SAML IdP is represented by KC server, SAML SP
>> part is handled by KC adapters.
>
>


From bburke at redhat.com  Mon Oct 31 14:33:17 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 31 Oct 2016 14:33:17 -0400
Subject: [keycloak-dev] User SPI cache policies
In-Reply-To: <CAJgngAfxkCdOXnEa8Ob31zqJB_T_A6hWXwx3Mt8HgJfHiDsO6A@mail.gmail.com>
References: <ae3ad614-db6f-cbd7-37d7-f9f011ac35e6@redhat.com>
	<CAJgngAct5oOV3t_2ACFt9HZN9i3hgnJwOzM9j+BF2GPPdCaQpw@mail.gmail.com>
	<a6b434c9-af96-ec08-a95b-e2d0bab10530@redhat.com>
	<CAJgngAc1Hwqj2B4fyMLgfCFReaJ9iq6OV9m04LHbKMD+xu761g@mail.gmail.com>
	<aa5887a7-e11e-2524-8d32-418b4df5a03e@redhat.com>
	<CAJgngAfxkCdOXnEa8Ob31zqJB_T_A6hWXwx3Mt8HgJfHiDsO6A@mail.gmail.com>
Message-ID: <742bd089-d45b-d1f1-2fc4-db44c50dad18@redhat.com>

You need to know the user before you can evict it.  username can be 
obtained differently from multiple different authenticators: spnego, 
username/password UI, basic auth, etc..


On 10/31/16 9:41 AM, Stian Thorgersen wrote:
> Could we not do it as a special first authenticator in the flow?
>
> On 31 October 2016 at 14:08, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 10/31/16 8:51 AM, Stian Thorgersen wrote:
>>
>>
>>     On 31 October 2016 at 13:49, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>         On 10/31/16 1:48 AM, Stian Thorgersen wrote:
>>
>>             What about evict on authenticate (load from store when
>>             user authenticates)? I think that would be the most
>>             useful policy.
>>
>>         That would need to be implemented at the authenticator level.
>>
>>
>>     Implementation details aside, should we not have it? It seems
>>     like the most likely time you want to fetch the user and
>>     especially credentials.
>     Yeah, its a great idea.  Implementation details matter though as
>     I'm not sure this can be reliably done without coding this in each
>     top-level authenticator and requiring an authenticator provider
>     developer to be aware of this policy.
>
>     Bill
>
>