From aron.bustya.js at gmail.com  Sun Oct  1 14:23:20 2017
From: aron.bustya.js at gmail.com (Aron Bustya)
Date: Sun, 1 Oct 2017 20:23:20 +0200
Subject: [keycloak-dev] Claims parameter support
In-Reply-To: <CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A@mail.gmail.com>
References: <CAGZZ5OisW6n9Da3h0MokoRcN9tAVzzSYGTwckwcRkXKGTRRnwA@mail.gmail.com>
	<9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com>
	<CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A@mail.gmail.com>
Message-ID: <CAGZZ5OjKULV7i0rtkZf+q3JLjYz-oWcCs+wsqz5P2Bh5OaCObw@mail.gmail.com>

https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135

I have updated my code - now it doesn't include the mapper itself, but it
does include the processing of the param as a "known param" and some tests
for this.

On 30 September 2017 at 22:32, Aron Bustya <aron.bustya.js at gmail.com> wrote:

> Hi,
>
> Sorry for the long silence.
>
> >Maybe one small change, if you can add the "claims" to the
> AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note for
> it as other known OIDC params?
> This would be good, because the "additional" parameters have a maximum
> length of 200 characters to be processed.
>
>
>
> On 20 September 2017 at 09:55, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Great work!
>>
>> If I see it correctly, there are 2 parts:
>>
>> 1) improvements in request object parsing - I am all for include your
>> improvements. If you can create separate JIRA for current request object
>> limitation, add the test (there are existing tests for request object in
>> OIDCAdvancedRequestParamsTest. Feel free to add new test or change one of
>> existing tests) and create separate PR, it will be nice and will be merged.
>> If I understand correctly, this is the only part, which really blocks you
>> right? (As additional protocolMapper can be deployed to the existing
>> Keycloak instance as separate JAR and doesn't require changes in core
>> keycloak code?)
>>
>> 2) ProtocolMapper for claims - as you pointed, you don't have full
>> support for 'claims' parameter. Still it's better then nothing, so my vote
>> is to include your changes. I am not 100% convinced, maybe someone has
>> different opinion on it (new protocolMapper always adds a bit of additional
>> complexity. However I think it's ok as it's OIDC standard). Maybe one small
>> change, if you can add the "claims" to the AuthzEndpointRequestParser.KNOWN_PARAMS
>> and have separate client note for it as other known OIDC params?
>>
>> Thanks!
>> Marek
>>
>>
>>
>> On 19/09/17 22:49, Aron Bustya wrote:
>>
>> Hello!
>>
>> I need the 'claims parameter' support in keycloak that has been thought
>> about in this jira ticket and postponed/rejected:https://issues.jboss.org/browse/KEYCLOAK-3226
>> The proposed alternatives don't work for me, because I am implementing a
>> specification that explicitly requests data to be passed this way.
>> In addition to the JIRA above we also need to support passing the claims
>> parameter in the signed request object - not just as a separate query param.
>>
>> I've solved the problem for our own use case by writing a ProtocolMapper
>> but some changes were also needed in the keycloak request parser (to
>> support the parsing of json objects from the request object - not just
>> strings).
>>
>> The ProtocolMapper I've written doesn't support the whole claims parameter
>> feature though - it can only add the default value of the claim to the the
>> tokens.
>>
>> I'm now trying to figure out how much of this code could be put back into
>> keycloak, and what needs to be changed to do so.
>> My goal would be to use an 'official' keycloak with cutomization only in
>> Service Providers and configuration.
>>
>> Current code commit is here:https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
>>
>> 6e210d8bd302d23fa7884da
>>
>> What do you think about the direction of the development, does it make any
>> sense to put some of it back into keycloak?
>>
>> Regards,
>> ?ron Bustya
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>

From sthorger at redhat.com  Mon Oct  2 02:13:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 08:13:51 +0200
Subject: [keycloak-dev] Login UI Mockups
Message-ID: <CAJgngAeP2HrUCUEwjmX7JJLTo5-Vm=ES2thrjpkRciE+3OKUvw@mail.gmail.com>

We leverage PatternFly for UI patterns both in the login screens as well as
the admin console. One problem with the login screens is that the
pattern/recommendations from PatternFly only has simple username/password
and doesn't cover the more use-cases we have.

The PatternFly team is currently working on extending and improving the
login screen patterns to cover more of our use-cases.

Please review and comment on their mockups at
https://redhat.invisionapp.com/share/59DNSUUZT#/screens/255230613_1

From sthorger at redhat.com  Mon Oct  2 03:09:08 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 09:09:08 +0200
Subject: [keycloak-dev] Keycloak deadlines 3.x
Message-ID: <CAJgngAc3e3tq4pCBFkXvFrQfE3Q+Vrq-mR7hEmBQtwpwNm4WSg@mail.gmail.com>

RH-SSO 7.2 release date is coming up quickly so wanted to remind everyone
about the following dates:

11th October - Feature freeze / 3.4.0.CR1
15th November - Last enhancements and bug fixes / 3.4.1.Final

If you have feature work that you don't think is going to be ready for 11th
October let me know asap.

Once 3.4.0.CR1 is out we'll focus on bug fixing for 3.4.1. Let's try to see
how many bugs we can squash! If folks from the community wants to help out
that would be great :)

From herbert.muehlburger at bearingpoint.com  Mon Oct  2 04:36:05 2017
From: herbert.muehlburger at bearingpoint.com (Muehlburger, Herbert)
Date: Mon, 2 Oct 2017 08:36:05 +0000
Subject: [keycloak-dev] JSON document as claim JSON type on mapper
	configuration page
Message-ID: <1506933365657.58362@bearingpoint.com>

?Hello,


What is the best way to map a JSON document to a Token Claim? Currently I can only define "?String" in Claim JSON Type at the Mapper Configuration page. But this causes Keycloak to treat the value of my custom user attribute field field as string. The value is indeed a JSON document and it would be great if there is also a claim JSON type of "JSON Object" which is not treated as string and not escaped as happens now.


?Kind regards,

Herbert


Herbert M?hlburger
Senior System Engineer

[http://signature.bearingpoint.com/BrP_Logo.png]

T  +43 316 8003
F  +43 316 8003 1080

BearingPoint Technology GmbH
Seering 6, Block B
8141 Premst?tten
Austria

herbert.muehlburger at bearingpoint.com <mailto:herbert.muehlburger at bearingpoint.com>
www.bearingpoint.com<http://www.bearingpoint.com/>
________________________________
BearingPoint Technology GmbH
Sitz: Premst?tten bei Graz
Firmenbuchgericht: Landesgericht f?r ZRS Graz
Firmenbuchnummer: FN 44354b

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

From thomas.darimont at googlemail.com  Mon Oct  2 05:05:45 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 2 Oct 2017 11:05:45 +0200
Subject: [keycloak-dev] JSON document as claim JSON type on mapper
 configuration page
In-Reply-To: <1506933365657.58362@bearingpoint.com>
References: <1506933365657.58362@bearingpoint.com>
Message-ID: <CAK-7U1gka9Etku345MJt5V1KwcZoM4=v44zCZBhxeL5oV6__=g@mail.gmail.com>

Hello Herbert,

the code that performs the value conversion is here:
org.keycloak.protocol.oidc.mappers.OIDCAttributeMapperHelper#convertToType

At the moment the only way to customize the mapping in the desired way is
to provide your own AbstractOIDCProtocolMapper mapper implementation.
Note that the OIDCAttributeMapperHelper is used by the setClaim method so
you need to avoid using that method, or replace the resulting
string value of your attribute with an object structure which is then later
marshalled as an appropriate json structure.

Cheers,
Thomas

2017-10-02 10:36 GMT+02:00 Muehlburger, Herbert <
herbert.muehlburger at bearingpoint.com>:

> ?Hello,
>
>
> What is the best way to map a JSON document to a Token Claim? Currently I
> can only define "?String" in Claim JSON Type at the Mapper Configuration
> page. But this causes Keycloak to treat the value of my custom user
> attribute field field as string. The value is indeed a JSON document and it
> would be great if there is also a claim JSON type of "JSON Object" which is
> not treated as string and not escaped as happens now.
>
>
> ?Kind regards,
>
> Herbert
>
>
> Herbert M?hlburger
> Senior System Engineer
>
> [http://signature.bearingpoint.com/BrP_Logo.png]
>
> T  +43 316 8003
> F  +43 316 8003 1080
>
> BearingPoint Technology GmbH
> Seering 6, Block B
> 8141 Premst?tten
> Austria
>
> herbert.muehlburger at bearingpoint.com <mailto:herbert.muehlburger@
> bearingpoint.com>
> www.bearingpoint.com<http://www.bearingpoint.com/>
> ________________________________
> BearingPoint Technology GmbH
> Sitz: Premst?tten bei Graz
> Firmenbuchgericht: Landesgericht f?r ZRS Graz
> Firmenbuchnummer: FN 44354b
>
> The information in this email is confidential and may be legally
> privileged. If you are not the intended recipient of this message, any
> review, disclosure, copying, distribution, retention, or any action taken
> or omitted to be taken in reliance on it is prohibited and may be unlawful.
> If you are not the intended recipient, please reply to or forward a copy of
> this message to the sender and delete the message, any attachments, and any
> copies thereof from your system.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Mon Oct  2 05:57:21 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 2 Oct 2017 11:57:21 +0200
Subject: [keycloak-dev] JSON document as claim JSON type on mapper
 configuration page
In-Reply-To: <CAK-7U1gka9Etku345MJt5V1KwcZoM4=v44zCZBhxeL5oV6__=g@mail.gmail.com>
References: <1506933365657.58362@bearingpoint.com>
	<CAK-7U1gka9Etku345MJt5V1KwcZoM4=v44zCZBhxeL5oV6__=g@mail.gmail.com>
Message-ID: <CAK-7U1ifvfW6Ob-q3FgF6Qs4sNBWankP6taVcHcuPDnT_tjrYw@mail.gmail.com>

Hello,

I like the idea of supporting raw json output for custom attributes. I
think calling the custom type just 'JSON' would suffice.
I just gave this a quick spin, by adding support for "JSON" type conversion
to OIDCAttributeMapperHelper.

How could this work?
In case the mapper input is a String, then try to parse it as a JSON
Object. E.g. via:
jsonObject = objectMapper.readValue((String)attributeValue, Object.class);

If the input is an object or null return it as is.

This would work with values like:
user.singleAttribute("jsonData", "{\"intValue\":42,
\"stringValue\":\"hello\", \"listValue\": [1,2,3,\"test\"]}");
user.singleAttribute("jsonString", "\"jsonString\"");

which produce:
Map<String,Object> jsonData = new HashMap<>();
jsonData.put("intValue", 42);
jsonData.put("stringValue", "hello");
jsonData.put("listValue", Arrays.asList(1,2,3,"test"));

assertEquals(jsonData, accessToken.getOtherClaims().get("jsonData"));
assertEquals("jsonString", accessToken.getOtherClaims().get("jsonString"));

Question for the Keycloak Team:
- Is this a good idea?
- Is there a shared ObjectMapper available that could be reused here?

Cheers,
Thomas

2017-10-02 11:05 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello Herbert,
>
> the code that performs the value conversion is here:
> org.keycloak.protocol.oidc.mappers.OIDCAttributeMapperHelper#convertToType
>
> At the moment the only way to customize the mapping in the desired way is
> to provide your own AbstractOIDCProtocolMapper mapper implementation.
> Note that the OIDCAttributeMapperHelper is used by the setClaim method so
> you need to avoid using that method, or replace the resulting
> string value of your attribute with an object structure which is then
> later marshalled as an appropriate json structure.
>
> Cheers,
> Thomas
>
> 2017-10-02 10:36 GMT+02:00 Muehlburger, Herbert <herbert.muehlburger@
> bearingpoint.com>:
>
>> ?Hello,
>>
>>
>> What is the best way to map a JSON document to a Token Claim? Currently I
>> can only define "?String" in Claim JSON Type at the Mapper Configuration
>> page. But this causes Keycloak to treat the value of my custom user
>> attribute field field as string. The value is indeed a JSON document and it
>> would be great if there is also a claim JSON type of "JSON Object" which is
>> not treated as string and not escaped as happens now.
>>
>>
>> ?Kind regards,
>>
>> Herbert
>>
>>
>> Herbert M?hlburger
>> Senior System Engineer
>>
>> [http://signature.bearingpoint.com/BrP_Logo.png]
>>
>> T  +43 316 8003
>> F  +43 316 8003 1080
>>
>> BearingPoint Technology GmbH
>> Seering 6, Block B
>> 8141 Premst?tten
>> Austria
>>
>> herbert.muehlburger at bearingpoint.com <mailto:herbert.muehlburger at be
>> aringpoint.com>
>> www.bearingpoint.com<http://www.bearingpoint.com/>
>> ________________________________
>> BearingPoint Technology GmbH
>> Sitz: Premst?tten bei Graz
>> Firmenbuchgericht: Landesgericht f?r ZRS Graz
>> Firmenbuchnummer: FN 44354b
>>
>> The information in this email is confidential and may be legally
>> privileged. If you are not the intended recipient of this message, any
>> review, disclosure, copying, distribution, retention, or any action taken
>> or omitted to be taken in reliance on it is prohibited and may be unlawful.
>> If you are not the intended recipient, please reply to or forward a copy of
>> this message to the sender and delete the message, any attachments, and any
>> copies thereof from your system.
>> _______________________________________________
>> 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  2 06:13:10 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 2 Oct 2017 12:13:10 +0200
Subject: [keycloak-dev] Single-use cache for OAuth code,
 Code changed to be JWE
In-Reply-To: <171a2041-0fb9-8496-5999-dc240f619082@redhat.com>
References: <d612f215-59ba-34cd-c0c2-be8666181321@redhat.com>
	<CABRXCmwVA0tcLGgsGk=S9fzNrD=GHkzW8H2FW6010sQ=tpA7rA@mail.gmail.com>
	<171a2041-0fb9-8496-5999-dc240f619082@redhat.com>
Message-ID: <443ce1b7-7e76-c88f-3d5c-427842864372@redhat.com>

FYI: The remaining work from 
https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit 
is postponed to 3.4.1.Final for now and maybe further. As it's not an 
immediate blocker for cross-dc. Related JIRA is 
https://issues.jboss.org/browse/KEYCLOAK-5006 .

Marek

On 29/09/17 16:54, Marek Posolda wrote:
> I see. The current size of the code parameter is 351 characters. The 
> size of the JSON payload itself is 178 characters. The size of the 
> code is like:
> S + E
> where S is 95 (size of the header, AES initialization vector and MAC)
> E is size of the encrypted text (approximately payload_size * 1.5)
>
> Fortunately we already have limit for custom notes to be 1000 chars at 
> max - 
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/protocol/oidc/endpoints/request/AuthzEndpointRequestParser.java#L35-L45 
> . So I think we should be fine for URL limit of 2000 characters. Still 
> we can improve by:
>
> - Use deflate compression - It's supported by JWE specs
>
> - Fallback to have notes in clientSession in case of big code param. 
> Then clientSession will be still required in code-to-token endpoint
>
> Marek
>
>
> On 29/09/17 15:32, Bill Burke wrote:
>> Looks good.  Just worry about the size of the code JWT.
>>
>> On Fri, Sep 29, 2017 at 7:59 AM, Marek Posolda <mposolda at redhat.com> 
>> wrote:
>>> I've sent PR https://github.com/keycloak/keycloak/pull/4512, which
>>> implements first part of
>>> https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit 
>>>
>>>
>>> Some details:
>>> - Partially implemented support for JWE, so we can use encrypted JWT.
>>>
>>> - OAuth code is changed to be JWT. It's encrypted and
>>> integrity-protected with AES128-CBC-HMAC-SHA256 algorithm. Code is
>>> encrypted with realm AES key (new symmetric key generated by default 
>>> for
>>> every realm similar to HMAC key) and signed with HMAC key.
>>>
>>> - I've added support for AES keys, so we now have RSA, HMAC and AES 
>>> keys.
>>>
>>> - Code JWT doesn't yet contain much at this moment. There is just 
>>> unique
>>> ID, userSession ID, client UUID and expiration (60 seconds). Next step
>>> is to add more into it, especially notes as mentioned in the docs.
>>>
>>> - Single-use cache is used to track which codes were already used. For
>>> now, it's reusing existing "actionTokens" infinispan cache. It's using
>>> "putIfAbsent" to add codes into the cache, hence now we are sure that
>>> the particular code is really used just once. The previous approach 
>>> with
>>> the note on userSession didn't allow this. I've added new testcase to
>>> ConcurrentLoginTest for check that code is used just once. It's passing
>>> for cross-dc as well, however we may allow people to save some
>>> performance with the small possibility that same code will pass on both
>>> datacenters.
>>>
>>> - Now we also pass the scenario when SSO login with same client is
>>> opened on 2 browser tabs concurrently. Also added test to
>>> ConcurrentLoginTest and it's passing for cross-dc too. Previously this
>>> scenario may not work correctly as the "code" in the clientSession note
>>> may be generated concurrently by both requests and one of them will 
>>> then
>>> fail to verify.
>>>
>>>
>>> Next steps:
>>> - Continue with the stuff described in the docs
>>> https://docs.google.com/document/d/1C1vFhyGPBOnN3pprw6XPZnK08azyTm-HVIqO9dY3aTY/edit 
>>>
>>> (Remove protocolMappers and roles from clientSession etc).
>>>
>>> - It should be easy to use same stuff for refreshTokens . From what I
>>> see, the performance of AES128-CBC-HMAC-SHA256 is much better than RSA
>>> and provides the encryption too.
>>>
>>> Any comments?
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>


From carl-kristian.eriksen at telia.no  Mon Oct  2 06:25:07 2017
From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no)
Date: Mon, 2 Oct 2017 10:25:07 +0000
Subject: [keycloak-dev] Build on OS-X launches ForkedBooter UI when running
	Surefire tests
Message-ID: <327C4306FD53B84E9CD7BCBDDA3734AD173584B8@exmb04tstrz2.tcad.telia.se>

The UI launches as an application on top of what you are currently doing, stealing focus.

This is rather annoying, and can be fixed by including "-Djava.awt.headless=true" in the Surefire configuration.

Jira task: https://issues.jboss.org/browse/KEYCLOAK-5592

br
Carl Kristian Eriksen


From carl-kristian.eriksen at telia.no  Mon Oct  2 06:44:29 2017
From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no)
Date: Mon, 2 Oct 2017 10:44:29 +0000
Subject: [keycloak-dev] "mvn install"  fails on a fresh clone of Keycloak
Message-ID: <327C4306FD53B84E9CD7BCBDDA3734AD173584D0@exmb04tstrz2.tcad.telia.se>

The build works fine without the tests: mvn install -Dmaven.test.skip=true

But when running with the tests: mvn install
I get the following errors:
Failed tests:
  JaxrsFilterTest.testCors:285 expected:<200> but was:<403>
  JaxrsFilterTest.testRelativeUriAndPublicKey:171 expected:<500> but was:<401>
Tests in error:
  JaxrsBasicAuthTest.testBasic:140 ? ClientError HTTP 403 Forbidden
  JaxrsFilterTest.testBasic:140 ? ClientError HTTP 403 Forbidden
  JaxrsFilterTest.testResourceRoleMappings:235 ? ClientError HTTP 403 Forbidden

Tests run: 462, Failures: 2, Errors: 3, Skipped: 35

According to https://github.com/keycloak/keycloak/ this is supposed to work.
Am I missing something here?

Carl Kristian Eriksen

From velias at redhat.com  Mon Oct  2 07:06:38 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 2 Oct 2017 13:06:38 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <CABRXCmxR7maebLVszOxo6ig6Q2=ehEctcWS+GGSvza5_mReZig@mail.gmail.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<CABRXCmxR7maebLVszOxo6ig6Q2=ehEctcWS+GGSvza5_mReZig@mail.gmail.com>
Message-ID: <515c5997-13a2-6c43-fb51-3cf434f62174@redhat.com>

Hi,


On 29.9.2017 15:29, Bill Burke wrote:
> LoginFormsProvider has a setAttribute() method.   Isn't that enough?

Use of this means that we have to rewrite all authenticators (and 
reconfigure all flows) and potential other code parts where the 
LoginFormsProvider is called from. May be used for some use cases, but 
it is not usable for our use case where we need to pass some additional 
attributes always.

Vl.

> We have to let authenticator plugins drive the forms as down the road
> we might be required to build a SaaS which means our themes need to be
> secure enough to run in a multi-tenant environment.
>
> On Fri, Sep 29, 2017 at 7:30 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
>> Making the required methods protected is a simple way to work around the
>> issue, but bear in mind that the FreeMarker providers are likely to change
>> in the future.
>>
>> Another option could be to introduce an FreeMarkerAttributeProviderSPI, the
>> current freemarker providers would call all available providers to allow
>> them to add additional attributes. Something like:
>>
>> * registerAccountAttribute(FormContext..)
>> * registerLoginAttribute(FormContext..)
>>
>> Where FormContext would have access to KeycloakSession,
>> AuthenticationSession, etc..
>>
>> Slightly more work, but would be more future proof IMO.
>>
>>
>> On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I was asked by Stian to post my proposal around
>>> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
>>> wider KC dev team.
>>>
>>> What we need is to pass some additional attributes into Login and
>>> Account freemarker templates as part of our extensions  - eg. to
>>> configure client side validations for registration form based on actual
>>> authentication session. Other use case we need is selection of Theme
>>> based on calling client.
>>>
>>> There are already Login and Account Form providers which may be
>>> customized (they are SPI), only problem is that current Freemarker
>>> providers use private fields and methods, so it is hard to customize
>>> them (I have to copy complete code which is hardly maintainable during
>>> keycloak upgrades).
>>>
>>> I believe we should resolve the problem by small refactoring of existing
>>> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
>>> you already done in FreeMarkerEmailTemplateProvider. So things like:
>>>
>>>    * change fields and methods from private to protected to allow
>>>      use/override in subclasses
>>>    * refactor some features to protected methods (eg. Template loading
>>>      from template provider - again, you did it in
>>>      FreeMarkerEmailTemplateProvider provider already) to allow override
>>>      in subclasses
>>>    * add one protected callback method called just before template and
>>>      attributes are passed to the freemarker engine for the processing -
>>>      this allow subclass simply add additional attributes to be passed
>>>      into template
>>>
>>> Only bigger change (and blocker for one of our important features) is
>>> passing of current AuthenticationSessionModel to the LoginFormsProvider
>>> instance at all places where the form provider is called. This is really
>>> missing now to be able customize GUI based on current client and
>>> authentication flow needs.
>>>
>>> I don't think those are big changes, but they will make life of
>>> extension developers much easier.
>>>
>>> I believe I'm able to provide pull request for this change if no better
>>> solution will be found there by experienced KC dev team.
>>>
>>> Thanks a lot in advance for any comments to my proposal.
>>>
>>> Vlastimil
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer, Middleware Engineering Services
>>> Red Hat
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From sthorger at redhat.com  Mon Oct  2 07:06:57 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 13:06:57 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <CABRXCmxR7maebLVszOxo6ig6Q2=ehEctcWS+GGSvza5_mReZig@mail.gmail.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<CABRXCmxR7maebLVszOxo6ig6Q2=ehEctcWS+GGSvza5_mReZig@mail.gmail.com>
Message-ID: <CAJgngAfGuEPgmHnpHjk_UrD+0qjKwnf-NVxspL4fRm83ZoMq8w@mail.gmail.com>

On 29 September 2017 at 15:29, Bill Burke <bburke at redhat.com> wrote:

> LoginFormsProvider has a setAttribute() method.   Isn't that enough?
>

That only works if you have a custom authenticator and custom template. It
doesn't work if you just want to expose additional attributes to a custom
template.


>
> We have to let authenticator plugins drive the forms as down the road
> we might be required to build a SaaS which means our themes need to be
> secure enough to run in a multi-tenant environment.
>

Hence why I wouldn't want to expose KeycloakSession, AuthenticationSession,
etc. to templates ourselves, but rather allow custom providers to expose
additional attributes to templates if they want to.


>
> On Fri, Sep 29, 2017 at 7:30 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > Making the required methods protected is a simple way to work around the
> > issue, but bear in mind that the FreeMarker providers are likely to
> change
> > in the future.
> >
> > Another option could be to introduce an FreeMarkerAttributeProviderSPI,
> the
> > current freemarker providers would call all available providers to allow
> > them to add additional attributes. Something like:
> >
> > * registerAccountAttribute(FormContext..)
> > * registerLoginAttribute(FormContext..)
> >
> > Where FormContext would have access to KeycloakSession,
> > AuthenticationSession, etc..
> >
> > Slightly more work, but would be more future proof IMO.
> >
> >
> > On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com>
> wrote:
> >
> >> Hi,
> >>
> >> I was asked by Stian to post my proposal around
> >> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
> >> wider KC dev team.
> >>
> >> What we need is to pass some additional attributes into Login and
> >> Account freemarker templates as part of our extensions  - eg. to
> >> configure client side validations for registration form based on actual
> >> authentication session. Other use case we need is selection of Theme
> >> based on calling client.
> >>
> >> There are already Login and Account Form providers which may be
> >> customized (they are SPI), only problem is that current Freemarker
> >> providers use private fields and methods, so it is hard to customize
> >> them (I have to copy complete code which is hardly maintainable during
> >> keycloak upgrades).
> >>
> >> I believe we should resolve the problem by small refactoring of existing
> >> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
> >> you already done in FreeMarkerEmailTemplateProvider. So things like:
> >>
> >>   * change fields and methods from private to protected to allow
> >>     use/override in subclasses
> >>   * refactor some features to protected methods (eg. Template loading
> >>     from template provider - again, you did it in
> >>     FreeMarkerEmailTemplateProvider provider already) to allow override
> >>     in subclasses
> >>   * add one protected callback method called just before template and
> >>     attributes are passed to the freemarker engine for the processing -
> >>     this allow subclass simply add additional attributes to be passed
> >>     into template
> >>
> >> Only bigger change (and blocker for one of our important features) is
> >> passing of current AuthenticationSessionModel to the LoginFormsProvider
> >> instance at all places where the form provider is called. This is really
> >> missing now to be able customize GUI based on current client and
> >> authentication flow needs.
> >>
> >> I don't think those are big changes, but they will make life of
> >> extension developers much easier.
> >>
> >> I believe I'm able to provide pull request for this change if no better
> >> solution will be found there by experienced KC dev team.
> >>
> >> Thanks a lot in advance for any comments to my proposal.
> >>
> >> Vlastimil
> >>
> >> --
> >> Vlastimil Elias
> >> Principal Software Engineer, Middleware Engineering Services
> >> Red Hat
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From mposolda at redhat.com  Mon Oct  2 07:22:44 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 2 Oct 2017 13:22:44 +0200
Subject: [keycloak-dev] "mvn install" fails on a fresh clone of Keycloak
In-Reply-To: <327C4306FD53B84E9CD7BCBDDA3734AD173584D0@exmb04tstrz2.tcad.telia.se>
References: <327C4306FD53B84E9CD7BCBDDA3734AD173584D0@exmb04tstrz2.tcad.telia.se>
Message-ID: <ed8c8f1c-e8a3-2dbf-c64d-9e8f5a8c3163@redhat.com>

On 02/10/17 12:44, carl-kristian.eriksen at telia.no wrote:
> The build works fine without the tests: mvn install -Dmaven.test.skip=true
>
> But when running with the tests: mvn install
> I get the following errors:
> Failed tests:
>    JaxrsFilterTest.testCors:285 expected:<200> but was:<403>
>    JaxrsFilterTest.testRelativeUriAndPublicKey:171 expected:<500> but was:<401>
> Tests in error:
>    JaxrsBasicAuthTest.testBasic:140 ? ClientError HTTP 403 Forbidden
>    JaxrsFilterTest.testBasic:140 ? ClientError HTTP 403 Forbidden
>    JaxrsFilterTest.testResourceRoleMappings:235 ? ClientError HTTP 403 Forbidden
>
> Tests run: 462, Failures: 2, Errors: 3, Skipped: 35
>
> According to https://github.com/keycloak/keycloak/ this is supposed to work.
> Am I missing something here?
It's not supposed to work and I am not seeing "-Dmaven.test.skip=true" 
mentioned in that README. Anyway, I think this will work: mvn clean 
install -DskipTests=true

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



From carl-kristian.eriksen at telia.no  Mon Oct  2 07:33:00 2017
From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no)
Date: Mon, 2 Oct 2017 11:33:00 +0000
Subject: [keycloak-dev] "mvn install" fails on a fresh clone of Keycloak
In-Reply-To: <ed8c8f1c-e8a3-2dbf-c64d-9e8f5a8c3163@redhat.com>
References: <327C4306FD53B84E9CD7BCBDDA3734AD173584D0@exmb04tstrz2.tcad.telia.se>
	<ed8c8f1c-e8a3-2dbf-c64d-9e8f5a8c3163@redhat.com>
Message-ID: <1DD29D58-81F7-45A0-B569-B5382F7F3074@Telia.no>

You are right.
https://github.com/keycloak/keycloak/ states:

  To build Keycloak run:
       mvn install
  This will build all modules and run the testsuite.

I assume this used to work, but no longer.

It would make it easier to start with Keycloak, and also verify changes if this still worked.

If it is not supposed to work, please update the documentation accordingly.


Carl Kristian Eriksen

On 02/10/17 13:22, "Marek Posolda" <mposolda at redhat.com> wrote:

    On 02/10/17 12:44, carl-kristian.eriksen at telia.no wrote:
    > The build works fine without the tests: mvn install -Dmaven.test.skip=true
    >
    > But when running with the tests: mvn install
    > I get the following errors:
    > Failed tests:
    >    JaxrsFilterTest.testCors:285 expected:<200> but was:<403>
    >    JaxrsFilterTest.testRelativeUriAndPublicKey:171 expected:<500> but was:<401>
    > Tests in error:
    >    JaxrsBasicAuthTest.testBasic:140 ? ClientError HTTP 403 Forbidden
    >    JaxrsFilterTest.testBasic:140 ? ClientError HTTP 403 Forbidden
    >    JaxrsFilterTest.testResourceRoleMappings:235 ? ClientError HTTP 403 Forbidden
    >
    > Tests run: 462, Failures: 2, Errors: 3, Skipped: 35
    >
    > According to https://github.com/keycloak/keycloak/ this is supposed to work.
    > Am I missing something here?
    It's not supposed to work and I am not seeing "-Dmaven.test.skip=true" 
    mentioned in that README. Anyway, I think this will work: mvn clean 
    install -DskipTests=true
    
    Marek
    >
    > Carl Kristian Eriksen
    > _______________________________________________
    > keycloak-dev mailing list
    > keycloak-dev at lists.jboss.org
    > https://lists.jboss.org/mailman/listinfo/keycloak-dev
    
    
    



From carl-kristian.eriksen at telia.no  Mon Oct  2 07:34:05 2017
From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no)
Date: Mon, 2 Oct 2017 11:34:05 +0000
Subject: [keycloak-dev] KEYCLOAK-5032 - Implementation question
In-Reply-To: <B77FEC0A-32CD-4FA3-89B7-0FA54CEAA433@Telia.no>
References: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no>
	<CABRXCmx19uAA378Egdw8COjKMx=1NWdQxtC0BVAWxZdftLOpGg@mail.gmail.com>
	<B77FEC0A-32CD-4FA3-89B7-0FA54CEAA433@Telia.no>
Message-ID: <11C9C746-8334-424C-A608-7AD99B712418@Telia.no>

The second commit in the PR failed the CI build, but the tests does not fail locally.
Do you have any suggestions on how to handle this?

Carl Kristian Eriksen


On 29/09/17 16:41, "keycloak-dev-bounces at lists.jboss.org on behalf of carl-kristian.eriksen at telia.no" <keycloak-dev-bounces at lists.jboss.org on behalf of carl-kristian.eriksen at telia.no> wrote:

    Hi.
    
     I?ll follow up on the PR.
    
    Br / mvh
    Carl Kristian Eriksen
    On 29/09/17 15:50, "Bill Burke" <bburke at redhat.com> wrote:
    
        Do you want to continue talking on the PR or here?  I had some
        concerns with your PR.
        
        On Wed, Sep 27, 2017 at 5:45 AM,  <carl-kristian.eriksen at telia.no> wrote:
        > https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce
        >
        > Our requirements are for acr_values and prompt, and I?m working on a pull request for these two.
        >
        > How many pull requests do you want?
        > Should I make sure that (each)PR includes support for one, two or three query parameters
        >
        > Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I need another Jira task for the ?prompt? parameter?
        >
        > Br / mvh
        > Carl Kristian Eriksen
    > _______________________________________________
        > keycloak-dev mailing list
        > keycloak-dev at lists.jboss.org
        > https://lists.jboss.org/mailman/listinfo/keycloak-dev
        
        
        
        -- 
        Bill Burke
        Red Hat
        
    
    
    _______________________________________________
    keycloak-dev mailing list
    keycloak-dev at lists.jboss.org
    https://lists.jboss.org/mailman/listinfo/keycloak-dev



From velias at redhat.com  Mon Oct  2 08:12:34 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 2 Oct 2017 14:12:34 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
Message-ID: <700a3865-3544-0ea6-8006-185545779305@redhat.com>

Hi,


On 29.9.2017 13:30, Stian Thorgersen wrote:
> Making the required methods protected is a simple way to work around 
> the issue, but bear in mind that the FreeMarker providers are likely 
> to change in the future.

I'm aware of a potential change of the FreeMarker providers in the 
future. For now this is preferred way for me as we also need to change 
mechanism of Template selection (based on client), so we have to extend 
these providers anyway.

>
> Another option could be to introduce an 
> FreeMarkerAttributeProviderSPI, the current freemarker providers would 
> call all available providers to allow them to add additional 
> attributes. Something like:
>
> * registerAccountAttribute(FormContext..)
> * registerLoginAttribute(FormContext..)
>
> Where FormContext would have access to KeycloakSession, 
> AuthenticationSession, etc..
>
> Slightly more work, but would be more future proof IMO.

If you have a room to implement this SPI and make it stable (and 
supported in RH-SSO ;-), then I'm not against it, it may be very useful 
for most of custom extensions.
It is likely that we will get rid of template selection mechanism in the 
future, so we should switch to this SPI if it will be available.
Still some refactoring of FreeMarker providers may be performed as part 
of this change to make them easily usable for more complicated custom 
extensions ;-)

Thanks a lot
Vlastimil

>
> On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     I was asked by Stian to post my proposal around
>     https://issues.jboss.org/browse/KEYCLOAK-2671
>     <https://issues.jboss.org/browse/KEYCLOAK-2671> to be discussed
>     here with
>     wider KC dev team.
>
>     What we need is to pass some additional attributes into Login and
>     Account freemarker templates as part of our extensions? - eg. to
>     configure client side validations for registration form based on
>     actual
>     authentication session. Other use case we need is selection of Theme
>     based on calling client.
>
>     There are already Login and Account Form providers which may be
>     customized (they are SPI), only problem is that current Freemarker
>     providers use private fields and methods, so it is hard to customize
>     them (I have to copy complete code which is hardly maintainable during
>     keycloak upgrades).
>
>     I believe we should resolve the problem by small refactoring of
>     existing
>     FreeMarkerLoginProvider and FreeMarkerAccountProvider providers
>     similar
>     you already done in FreeMarkerEmailTemplateProvider. So things like:
>
>     ? * change fields and methods from private to protected to allow
>     ? ? use/override in subclasses
>     ? * refactor some features to protected methods (eg. Template loading
>     ? ? from template provider - again, you did it in
>     ? ? FreeMarkerEmailTemplateProvider provider already) to allow
>     override
>     ? ? in subclasses
>     ? * add one protected callback method called just before template and
>     ? ? attributes are passed to the freemarker engine for the
>     processing -
>     ? ? this allow subclass simply add additional attributes to be passed
>     ? ? into template
>
>     Only bigger change (and blocker for one of our important features) is
>     passing of current AuthenticationSessionModel to the
>     LoginFormsProvider
>     instance at all places where the form provider is called. This is
>     really
>     missing now to be able customize GUI based on current client and
>     authentication flow needs.
>
>     I don't think those are big changes, but they will make life of
>     extension developers much easier.
>
>     I believe I'm able to provide pull request for this change if no
>     better
>     solution will be found there by experienced KC dev team.
>
>     Thanks a lot in advance for any comments to my proposal.
>
>     Vlastimil
>
>     --
>     Vlastimil Elias
>     Principal Software Engineer, Middleware Engineering Services
>     Red Hat
>
>     _______________________________________________
>     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>
>
>

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From sthorger at redhat.com  Mon Oct  2 08:28:47 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 14:28:47 +0200
Subject: [keycloak-dev] "mvn install" fails on a fresh clone of Keycloak
In-Reply-To: <1DD29D58-81F7-45A0-B569-B5382F7F3074@Telia.no>
References: <327C4306FD53B84E9CD7BCBDDA3734AD173584D0@exmb04tstrz2.tcad.telia.se>
	<ed8c8f1c-e8a3-2dbf-c64d-9e8f5a8c3163@redhat.com>
	<1DD29D58-81F7-45A0-B569-B5382F7F3074@Telia.no>
Message-ID: <CAJgngAd4y4Z056WgfYV3ACPf0ie6kbSWxWShTLrhZTGRdsH66g@mail.gmail.com>

The following command

# mvn clean install

Should work. Travis runs the mentioned tests for all PRs. If it fails for
you, but not for others, it could be something specific to your environment.


On 2 October 2017 at 13:33, <carl-kristian.eriksen at telia.no> wrote:

> You are right.
> https://github.com/keycloak/keycloak/ states:
>
>   To build Keycloak run:
>        mvn install
>   This will build all modules and run the testsuite.
>
> I assume this used to work, but no longer.
>
> It would make it easier to start with Keycloak, and also verify changes if
> this still worked.
>
> If it is not supposed to work, please update the documentation accordingly.
>
>
> Carl Kristian Eriksen
>
> On 02/10/17 13:22, "Marek Posolda" <mposolda at redhat.com> wrote:
>
>     On 02/10/17 12:44, carl-kristian.eriksen at telia.no wrote:
>     > The build works fine without the tests: mvn install
> -Dmaven.test.skip=true
>     >
>     > But when running with the tests: mvn install
>     > I get the following errors:
>     > Failed tests:
>     >    JaxrsFilterTest.testCors:285 expected:<200> but was:<403>
>     >    JaxrsFilterTest.testRelativeUriAndPublicKey:171 expected:<500>
> but was:<401>
>     > Tests in error:
>     >    JaxrsBasicAuthTest.testBasic:140 ? ClientError HTTP 403 Forbidden
>     >    JaxrsFilterTest.testBasic:140 ? ClientError HTTP 403 Forbidden
>     >    JaxrsFilterTest.testResourceRoleMappings:235 ? ClientError HTTP
> 403 Forbidden
>     >
>     > Tests run: 462, Failures: 2, Errors: 3, Skipped: 35
>     >
>     > According to https://github.com/keycloak/keycloak/ this is supposed
> to work.
>     > Am I missing something here?
>     It's not supposed to work and I am not seeing "-Dmaven.test.skip=true"
>     mentioned in that README. Anyway, I think this will work: mvn clean
>     install -DskipTests=true
>
>     Marek
>     >
>     > Carl Kristian Eriksen
>     > _______________________________________________
>     > 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  2 08:32:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 14:32:04 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <700a3865-3544-0ea6-8006-185545779305@redhat.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<700a3865-3544-0ea6-8006-185545779305@redhat.com>
Message-ID: <CAJgngAcCkAy8Ud6-b=xDX6UrNms099Aw-ziemnQMhrX-UownrQ@mail.gmail.com>

I'm happy with a simple PR then to just change the methods you need to
protected.

We won't be able to look at any SPIs for 7.2 anyways unless you decided to
contribute it ;)

For the template selections. Are you picking different templates per-client
or different themes?

On 2 October 2017 at 14:12, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> On 29.9.2017 13:30, Stian Thorgersen wrote:
>
> Making the required methods protected is a simple way to work around the
> issue, but bear in mind that the FreeMarker providers are likely to change
> in the future.
>
>
> I'm aware of a potential change of the FreeMarker providers in the future.
> For now this is preferred way for me as we also need to change mechanism of
> Template selection (based on client), so we have to extend these providers
> anyway.
>
>
> Another option could be to introduce an FreeMarkerAttributeProviderSPI,
> the current freemarker providers would call all available providers to
> allow them to add additional attributes. Something like:
>
> * registerAccountAttribute(FormContext..)
> * registerLoginAttribute(FormContext..)
>
> Where FormContext would have access to KeycloakSession,
> AuthenticationSession, etc..
>
> Slightly more work, but would be more future proof IMO.
>
>
> If you have a room to implement this SPI and make it stable (and supported
> in RH-SSO ;-), then I'm not against it, it may be very useful for most of
> custom extensions.
> It is likely that we will get rid of template selection mechanism in the
> future, so we should switch to this SPI if it will be available.
> Still some refactoring of FreeMarker providers may be performed as part of
> this change to make them easily usable for more complicated custom
> extensions ;-)
>

> Thanks a lot
> Vlastimil
>
>
>
>
> On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> I was asked by Stian to post my proposal around
>> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
>> wider KC dev team.
>>
>> What we need is to pass some additional attributes into Login and
>> Account freemarker templates as part of our extensions  - eg. to
>> configure client side validations for registration form based on actual
>> authentication session. Other use case we need is selection of Theme
>> based on calling client.
>>
>> There are already Login and Account Form providers which may be
>> customized (they are SPI), only problem is that current Freemarker
>> providers use private fields and methods, so it is hard to customize
>> them (I have to copy complete code which is hardly maintainable during
>> keycloak upgrades).
>>
>> I believe we should resolve the problem by small refactoring of existing
>> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
>> you already done in FreeMarkerEmailTemplateProvider. So things like:
>>
>>   * change fields and methods from private to protected to allow
>>     use/override in subclasses
>>   * refactor some features to protected methods (eg. Template loading
>>     from template provider - again, you did it in
>>     FreeMarkerEmailTemplateProvider provider already) to allow override
>>     in subclasses
>>   * add one protected callback method called just before template and
>>     attributes are passed to the freemarker engine for the processing -
>>     this allow subclass simply add additional attributes to be passed
>>     into template
>>
>> Only bigger change (and blocker for one of our important features) is
>> passing of current AuthenticationSessionModel to the LoginFormsProvider
>> instance at all places where the form provider is called. This is really
>> missing now to be able customize GUI based on current client and
>> authentication flow needs.
>>
>> I don't think those are big changes, but they will make life of
>> extension developers much easier.
>>
>> I believe I'm able to provide pull request for this change if no better
>> solution will be found there by experienced KC dev team.
>>
>> Thanks a lot in advance for any comments to my proposal.
>>
>> Vlastimil
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Vlastimil Elias
> Principal Software Engineer, Middleware Engineering Services
> Red Hat
>
>

From velias at redhat.com  Mon Oct  2 08:41:11 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 2 Oct 2017 14:41:11 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <CAJgngAcCkAy8Ud6-b=xDX6UrNms099Aw-ziemnQMhrX-UownrQ@mail.gmail.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<700a3865-3544-0ea6-8006-185545779305@redhat.com>
	<CAJgngAcCkAy8Ud6-b=xDX6UrNms099Aw-ziemnQMhrX-UownrQ@mail.gmail.com>
Message-ID: <9116120e-84bf-d365-da88-a08bbaa7b991@redhat.com>

Hi,


On 2.10.2017 14:32, Stian Thorgersen wrote:
> I'm happy with a simple PR then to just change the methods you need to 
> protected.

great, I'll try to prepare PR against master branch and send it 
(hopefully this week).

>
> We won't be able to look at any SPIs for 7.2 anyways unless you 
> decided to contribute it ;)

:-D

> For the template selections. Are you picking different templates 
> per-client or different themes?

We select complete Theme per client in the code, using realm's default 
if nothing special is defined for the client.

Vl.

>
> On 2 October 2017 at 14:12, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>
>     On 29.9.2017 13:30, Stian Thorgersen wrote:
>>     Making the required methods protected is a simple way to work
>>     around the issue, but bear in mind that the FreeMarker providers
>>     are likely to change in the future.
>
>     I'm aware of a potential change of the FreeMarker providers in the
>     future. For now this is preferred way for me as we also need to
>     change mechanism of Template selection (based on client), so we
>     have to extend these providers anyway.
>
>>
>>     Another option could be to introduce an
>>     FreeMarkerAttributeProviderSPI, the current freemarker providers
>>     would call all available providers to allow them to add
>>     additional attributes. Something like:
>>
>>     * registerAccountAttribute(FormContext..)
>>     * registerLoginAttribute(FormContext..)
>>
>>     Where FormContext would have access to KeycloakSession,
>>     AuthenticationSession, etc..
>>
>>     Slightly more work, but would be more future proof IMO.
>
>     If you have a room to implement this SPI and make it stable (and
>     supported in RH-SSO ;-), then I'm not against it, it may be very
>     useful for most of custom extensions.
>     It is likely that we will get rid of template selection mechanism
>     in the future, so we should switch to this SPI if it will be
>     available.
>     Still some refactoring of FreeMarker providers may be performed as
>     part of this change to make them easily usable for more
>     complicated custom extensions ;-)
>
>
>     Thanks a lot
>     Vlastimil
>
>
>>
>>     On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi,
>>
>>         I was asked by Stian to post my proposal around
>>         https://issues.jboss.org/browse/KEYCLOAK-2671
>>         <https://issues.jboss.org/browse/KEYCLOAK-2671> to be
>>         discussed here with
>>         wider KC dev team.
>>
>>         What we need is to pass some additional attributes into Login and
>>         Account freemarker templates as part of our extensions? - eg. to
>>         configure client side validations for registration form based
>>         on actual
>>         authentication session. Other use case we need is selection
>>         of Theme
>>         based on calling client.
>>
>>         There are already Login and Account Form providers which may be
>>         customized (they are SPI), only problem is that current
>>         Freemarker
>>         providers use private fields and methods, so it is hard to
>>         customize
>>         them (I have to copy complete code which is hardly
>>         maintainable during
>>         keycloak upgrades).
>>
>>         I believe we should resolve the problem by small refactoring
>>         of existing
>>         FreeMarkerLoginProvider and FreeMarkerAccountProvider
>>         providers similar
>>         you already done in FreeMarkerEmailTemplateProvider. So
>>         things like:
>>
>>         ? * change fields and methods from private to protected to allow
>>         ? ? use/override in subclasses
>>         ? * refactor some features to protected methods (eg. Template
>>         loading
>>         ? ? from template provider - again, you did it in
>>         ? ? FreeMarkerEmailTemplateProvider provider already) to
>>         allow override
>>         ? ? in subclasses
>>         ? * add one protected callback method called just before
>>         template and
>>         ? ? attributes are passed to the freemarker engine for the
>>         processing -
>>         ? ? this allow subclass simply add additional attributes to
>>         be passed
>>         ? ? into template
>>
>>         Only bigger change (and blocker for one of our important
>>         features) is
>>         passing of current AuthenticationSessionModel to the
>>         LoginFormsProvider
>>         instance at all places where the form provider is called.
>>         This is really
>>         missing now to be able customize GUI based on current client and
>>         authentication flow needs.
>>
>>         I don't think those are big changes, but they will make life of
>>         extension developers much easier.
>>
>>         I believe I'm able to provide pull request for this change if
>>         no better
>>         solution will be found there by experienced KC dev team.
>>
>>         Thanks a lot in advance for any comments to my proposal.
>>
>>         Vlastimil
>>
>>         --
>>         Vlastimil Elias
>>         Principal Software Engineer, Middleware Engineering Services
>>         Red Hat
>>
>>         _______________________________________________
>>         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>
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer, Middleware Engineering Services
>     Red Hat
>
>

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From sthorger at redhat.com  Mon Oct  2 08:51:05 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 2 Oct 2017 14:51:05 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <9116120e-84bf-d365-da88-a08bbaa7b991@redhat.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<700a3865-3544-0ea6-8006-185545779305@redhat.com>
	<CAJgngAcCkAy8Ud6-b=xDX6UrNms099Aw-ziemnQMhrX-UownrQ@mail.gmail.com>
	<9116120e-84bf-d365-da88-a08bbaa7b991@redhat.com>
Message-ID: <CAJgngAfSYcCS0tjr60ESosi9YNaOYKQuXJcwtec_F3Miibibqw@mail.gmail.com>

On 2 October 2017 at 14:41, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> On 2.10.2017 14:32, Stian Thorgersen wrote:
>
> I'm happy with a simple PR then to just change the methods you need to
> protected.
>
>
> great, I'll try to prepare PR against master branch and send it
> (hopefully this week).
>
>
> We won't be able to look at any SPIs for 7.2 anyways unless you decided to
> contribute it ;)
>
>
> :-D
>
> For the template selections. Are you picking different templates
> per-client or different themes?
>
>
> We select complete Theme per client in the code, using realm's default if
> nothing special is defined for the client.
>

I reckon we can fairly easily add a ThemeSelectorSPI for that purpose.


>
> Vl.
>
>
>
> On 2 October 2017 at 14:12, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> On 29.9.2017 13:30, Stian Thorgersen wrote:
>>
>> Making the required methods protected is a simple way to work around the
>> issue, but bear in mind that the FreeMarker providers are likely to change
>> in the future.
>>
>>
>> I'm aware of a potential change of the FreeMarker providers in the
>> future. For now this is preferred way for me as we also need to change
>> mechanism of Template selection (based on client), so we have to extend
>> these providers anyway.
>>
>>
>> Another option could be to introduce an FreeMarkerAttributeProviderSPI,
>> the current freemarker providers would call all available providers to
>> allow them to add additional attributes. Something like:
>>
>> * registerAccountAttribute(FormContext..)
>> * registerLoginAttribute(FormContext..)
>>
>> Where FormContext would have access to KeycloakSession,
>> AuthenticationSession, etc..
>>
>> Slightly more work, but would be more future proof IMO.
>>
>>
>> If you have a room to implement this SPI and make it stable (and
>> supported in RH-SSO ;-), then I'm not against it, it may be very useful for
>> most of custom extensions.
>> It is likely that we will get rid of template selection mechanism in the
>> future, so we should switch to this SPI if it will be available.
>> Still some refactoring of FreeMarker providers may be performed as part
>> of this change to make them easily usable for more complicated custom
>> extensions ;-)
>>
>
>> Thanks a lot
>> Vlastimil
>>
>>
>>
>>
>> On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I was asked by Stian to post my proposal around
>>> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
>>> wider KC dev team.
>>>
>>> What we need is to pass some additional attributes into Login and
>>> Account freemarker templates as part of our extensions  - eg. to
>>> configure client side validations for registration form based on actual
>>> authentication session. Other use case we need is selection of Theme
>>> based on calling client.
>>>
>>> There are already Login and Account Form providers which may be
>>> customized (they are SPI), only problem is that current Freemarker
>>> providers use private fields and methods, so it is hard to customize
>>> them (I have to copy complete code which is hardly maintainable during
>>> keycloak upgrades).
>>>
>>> I believe we should resolve the problem by small refactoring of existing
>>> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
>>> you already done in FreeMarkerEmailTemplateProvider. So things like:
>>>
>>>   * change fields and methods from private to protected to allow
>>>     use/override in subclasses
>>>   * refactor some features to protected methods (eg. Template loading
>>>     from template provider - again, you did it in
>>>     FreeMarkerEmailTemplateProvider provider already) to allow override
>>>     in subclasses
>>>   * add one protected callback method called just before template and
>>>     attributes are passed to the freemarker engine for the processing -
>>>     this allow subclass simply add additional attributes to be passed
>>>     into template
>>>
>>> Only bigger change (and blocker for one of our important features) is
>>> passing of current AuthenticationSessionModel to the LoginFormsProvider
>>> instance at all places where the form provider is called. This is really
>>> missing now to be able customize GUI based on current client and
>>> authentication flow needs.
>>>
>>> I don't think those are big changes, but they will make life of
>>> extension developers much easier.
>>>
>>> I believe I'm able to provide pull request for this change if no better
>>> solution will be found there by experienced KC dev team.
>>>
>>> Thanks a lot in advance for any comments to my proposal.
>>>
>>> Vlastimil
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer, Middleware Engineering Services
>>> Red Hat
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer, Middleware Engineering Services
> Red Hat
>
>

From velias at redhat.com  Mon Oct  2 09:28:11 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 2 Oct 2017 15:28:11 +0200
Subject: [keycloak-dev] Allow additional attributes to be pushed into
 Freemarker templates (login and account themes) by extension developers
In-Reply-To: <CAJgngAfSYcCS0tjr60ESosi9YNaOYKQuXJcwtec_F3Miibibqw@mail.gmail.com>
References: <7fc947a7-f244-dd28-0e8c-b3d8b19fb063@redhat.com>
	<CAJgngAcKrh8Y=jxB+wy+U4hRYSSOCnf2e37KpGcO8xoeJk8xPg@mail.gmail.com>
	<700a3865-3544-0ea6-8006-185545779305@redhat.com>
	<CAJgngAcCkAy8Ud6-b=xDX6UrNms099Aw-ziemnQMhrX-UownrQ@mail.gmail.com>
	<9116120e-84bf-d365-da88-a08bbaa7b991@redhat.com>
	<CAJgngAfSYcCS0tjr60ESosi9YNaOYKQuXJcwtec_F3Miibibqw@mail.gmail.com>
Message-ID: <73c6c194-5339-e5b4-4e00-3e71dba736a9@redhat.com>

Yet another SPI :-D Seriously, design right granularity of SPI's may be 
tricky.

As I said, for me it looks like current FormProvider SPI is enough if 
existing FreeMarker providers will be written in a manner to allow 
simple partial extensibility. So use of protected fields and methods, 
and use of template method pattern may help a lot. I'll try to prepare 
PR in this manner and we will see.

Vl.


On 2.10.2017 14:51, Stian Thorgersen wrote:
>
>
> On 2 October 2017 at 14:41, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>
>     On 2.10.2017 14:32, Stian Thorgersen wrote:
>>     I'm happy with a simple PR then to just change the methods you
>>     need to protected.
>
>     great, I'll try to prepare PR against master branch and send it?
>     (hopefully this week).
>
>>
>>     We won't be able to look at any SPIs for 7.2 anyways unless you
>>     decided to contribute it ;)
>
>     :-D
>
>>     For the template selections. Are you picking different templates
>>     per-client or different themes?
>
>     We select complete Theme per client in the code, using realm's
>     default if nothing special is defined for the client.
>
>
> I reckon we can fairly easily add a ThemeSelectorSPI for that purpose.
>
>
>     Vl.
>
>
>>
>>     On 2 October 2017 at 14:12, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi,
>>
>>
>>         On 29.9.2017 13:30, Stian Thorgersen wrote:
>>>         Making the required methods protected is a simple way to
>>>         work around the issue, but bear in mind that the FreeMarker
>>>         providers are likely to change in the future.
>>
>>         I'm aware of a potential change of the FreeMarker providers
>>         in the future. For now this is preferred way for me as we
>>         also need to change mechanism of Template selection (based on
>>         client), so we have to extend these providers anyway.
>>
>>>
>>>         Another option could be to introduce an
>>>         FreeMarkerAttributeProviderSPI, the current freemarker
>>>         providers would call all available providers to allow them
>>>         to add additional attributes. Something like:
>>>
>>>         * registerAccountAttribute(FormContext..)
>>>         * registerLoginAttribute(FormContext..)
>>>
>>>         Where FormContext would have access to KeycloakSession,
>>>         AuthenticationSession, etc..
>>>
>>>         Slightly more work, but would be more future proof IMO.
>>
>>         If you have a room to implement this SPI and make it stable
>>         (and supported in RH-SSO ;-), then I'm not against it, it may
>>         be very useful for most of custom extensions.
>>         It is likely that we will get rid of template selection
>>         mechanism in the future, so we should switch to this SPI if
>>         it will be available.
>>         Still some refactoring of FreeMarker providers may be
>>         performed as part of this change to make them easily usable
>>         for more complicated custom extensions ;-)
>>
>>
>>         Thanks a lot
>>         Vlastimil
>>
>>
>>>
>>>         On 27 September 2017 at 15:20, Vlastimil Elias
>>>         <velias at redhat.com <mailto:velias at redhat.com>> wrote:
>>>
>>>             Hi,
>>>
>>>             I was asked by Stian to post my proposal around
>>>             https://issues.jboss.org/browse/KEYCLOAK-2671
>>>             <https://issues.jboss.org/browse/KEYCLOAK-2671> to be
>>>             discussed here with
>>>             wider KC dev team.
>>>
>>>             What we need is to pass some additional attributes into
>>>             Login and
>>>             Account freemarker templates as part of our extensions?
>>>             - eg. to
>>>             configure client side validations for registration form
>>>             based on actual
>>>             authentication session. Other use case we need is
>>>             selection of Theme
>>>             based on calling client.
>>>
>>>             There are already Login and Account Form providers which
>>>             may be
>>>             customized (they are SPI), only problem is that current
>>>             Freemarker
>>>             providers use private fields and methods, so it is hard
>>>             to customize
>>>             them (I have to copy complete code which is hardly
>>>             maintainable during
>>>             keycloak upgrades).
>>>
>>>             I believe we should resolve the problem by small
>>>             refactoring of existing
>>>             FreeMarkerLoginProvider and FreeMarkerAccountProvider
>>>             providers similar
>>>             you already done in FreeMarkerEmailTemplateProvider. So
>>>             things like:
>>>
>>>             ? * change fields and methods from private to protected
>>>             to allow
>>>             ? ? use/override in subclasses
>>>             ? * refactor some features to protected methods (eg.
>>>             Template loading
>>>             ? ? from template provider - again, you did it in
>>>             FreeMarkerEmailTemplateProvider provider already) to
>>>             allow override
>>>             ? ? in subclasses
>>>             ? * add one protected callback method called just before
>>>             template and
>>>             ? ? attributes are passed to the freemarker engine for
>>>             the processing -
>>>             ? ? this allow subclass simply add additional attributes
>>>             to be passed
>>>             ? ? into template
>>>
>>>             Only bigger change (and blocker for one of our important
>>>             features) is
>>>             passing of current AuthenticationSessionModel to the
>>>             LoginFormsProvider
>>>             instance at all places where the form provider is
>>>             called. This is really
>>>             missing now to be able customize GUI based on current
>>>             client and
>>>             authentication flow needs.
>>>
>>>             I don't think those are big changes, but they will make
>>>             life of
>>>             extension developers much easier.
>>>
>>>             I believe I'm able to provide pull request for this
>>>             change if no better
>>>             solution will be found there by experienced KC dev team.
>>>
>>>             Thanks a lot in advance for any comments to my proposal.
>>>
>>>             Vlastimil
>>>
>>>             --
>>>             Vlastimil Elias
>>>             Principal Software Engineer, Middleware Engineering Services
>>>             Red Hat
>>>
>>>             _______________________________________________
>>>             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>
>>>
>>>
>>
>>         -- 
>>         Vlastimil Elias
>>         Principal Software Engineer, Middleware Engineering Services
>>         Red Hat
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer, Middleware Engineering Services
>     Red Hat
>
>

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From mstrukel at redhat.com  Mon Oct  2 09:37:12 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 2 Oct 2017 15:37:12 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
Message-ID: <CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>

The more I look at the idea of having '-preview' in feature names the more
I think it will cause more trouble than it's worth.

The reason is it complicates migration when we promote feature to stable -
dropping '-preview' from its name, and it causes configuration names to be
fluid over time.

For example, consider how moving authorization from preview to stable would
look for a user.

User got used to using -Dfeature.authorization-preview=true

Now we change this setting to be called -Dfeature.authorization=true. User
still using -Dfeature.authorization-preview=true, will get a warning upon
startup: 'Unknown feature system property: feature.authorization-preview',
and the system property will have no effect. If user uses Keycloak
distribution then authorization-preview will be enabled by default. So no
need to explicitly enable it - a no-op operation in the first place, and a
no-op operation at upgrade. If user sets the property to false, then after
upgrade the feature will suddenly be enabled when before it was not.

It doesn't seem right to drop configuration like that. If we want old
config to keep working then every migration from preview to stable also has
to add backwards compatibility logic, so that surprises like this don't
happen. Also all documentation needs to be changed wherever the feature
name is referenced.

Whenever we promote any feature from '-preview' to stable this will be
needed, and it may become standard ritual that may to most users seem
completely redundant. Why not just call it -Dfeature.authorization in the
first place, and maybe just display a warning if any 'preview' feature is
enabled, something like:

[WARN] The following preview features are enabled: ...

WDYT?


On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> In standalone.xml I'd use "feature.scripts" sys properties instead of the
> longer "keycloak.feature.scripts". It's just shorter and simpler and
> won't cause any conflicts.
>
> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
> as is, including if set in profile.properties. This is important in case
> customers have explicitly disabled impersonation for example. +1 To
> printing a warning in this case. Then let's remove the old deprecated
> properties in Keycloak 3.5x as well as the profile.properties.
>
> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> This is a heads up about an upcoming change in how to enable or disable
>> features in Keycloak.
>>
>> Keycloak has a notion of features, which makes it possible to disable
>> certain functionality that is enabled by default, or enable certain
>> functionality that is disabled by default.
>>
>> There are four sets of functionality you can enable or disable as
>> features:
>> impersonation, script,  authorization, and docker. See [1] for more info.
>>
>> Currently a file called profile.properties can be used to enable / disable
>> features, or system properties can be used, which override any
>> configuration inside profile.properties as explained in [1].
>>
>> This is an aberration from how other configuration is specified on the
>> server via standalone.xml.
>>
>> Also, the reason config file is called profile.properties, and not
>> features.properties is because the set of enabled/disabled features is
>> different for upstream project (where all but 'docker' are enabled), for
>> product based on Keycloak - RHSSO (where only 'impersonation' is enabled),
>> and for technology preview versions of RHSSO.
>>
>> This additionally complicates things. The idea is to simplify that and
>> remove the notion of profiles, stop using profile.properties, and move all
>> configuration to standalone.xml where all the available features will be
>> listed with default values:
>>
>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>
>> ...
>>
>>   <features>
>>     <feature name="authorization" enabled="true" />
>>     <feature name="impersonation" enabled="true" />
>>     <feature name="scripts" enabled="true" />
>>     <feature name="docker" enabled="false" />
>>   </features>
>>
>> ...
>>
>> </subsystem>
>>
>> This is how configuration would look like in Keycloak distribution. In
>> product distributions different features would be enabled / disabled - no
>> more named profiles.
>>
>> However, in order to allow system properties override the idea is to do it
>> slightly differently:
>>
>>   <features>
>>     <feature name="authorization"
>> enabled="${keycloak.feature.authorization:true}" />
>>     <feature name="impersonation"
>> enabled="${keycloak.feature.impersonation:true}" />
>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}" />
>>     <feature name="docker" enabled="${keycloak.feature.docker:false}" />
>>   </features>
>>
>>
>> We should probably also facilitate transition for current deployments, and
>> take old style system properties into account if they are used -
>> converting
>> them to the new ones before configuration is applied.
>>
>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>> New style:    -Dkeycloak.feature.impersonation=true
>>
>> We don't want to keep support for this indefinitely (maybe for one minor
>> version?) so if use of deprecated system properties is detected a warning
>> will be logged.
>>
>> Also, Stian proposed that features not considered stable yet, should carry
>> a suffix '-preview' in the name. So the actual feature name, and system
>> property name may still change for some features.
>>
>> You can follow progress on JIRA issue [2].
>>
>> -
>>
>> [1]
>> https://keycloak.gitbooks.io/documentation/server_installati
>> on/topics/profiles.html
>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>> _______________________________________________
>> 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  2 10:25:21 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Oct 2017 10:25:21 -0400
Subject: [keycloak-dev] enable SSL and SSL policies out of the box?
Message-ID: <CABRXCmxSCnP0-z07spzw9gF8hRdp+mzAv1AMJYJg=44d+nZ8PQ@mail.gmail.com>

I'm not sure, but I believe the latest Wildfly can auto create an SSL
certificate at boot time.  Should we look into this prior to the end
of 3.4.1 and have realm SSL policies changed to reflect this?  I never
liked the idea that SSL is turned off and realm SSL policies don't
require SSL by default.

-- 
Bill Burke
Red Hat

From bburke at redhat.com  Mon Oct  2 10:29:52 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Oct 2017 10:29:52 -0400
Subject: [keycloak-dev] Standalone boot slow...Clustering introduced by
	accident?
Message-ID: <CABRXCmz6txir0LkqnPe0K4zytVxn9o=k5LvKi+Nv-FFNH5P6kA@mail.gmail.com>

I was wondering if the CrossDC worked introduced clustering into
standalone.xml by accident?  My standalone boot times are really slow
(60 seconds).  I'll look into it after I finish up the documentation
I'm doing, but maybe somebody knows something right now?

Thanks

-- 
Bill Burke
Red Hat

From bburke at redhat.com  Mon Oct  2 10:37:46 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Oct 2017 10:37:46 -0400
Subject: [keycloak-dev] Doc renaming and organization suggestion
Message-ID: <CABRXCmzewJn8jdFCTueeDXqab3KFR5ucEAKz_=c+5ba-5eUPdg@mail.gmail.com>

I suggest we rename Server Developer Guide to Keycloak (RH-SSO)
Developer Guide.  We move all programmer related SPIs, REST interface
docs (token exchange), Client Registration, adapter SPIs, really
anything a developer would do to this guide.

Securing Apps should be specifically configuration tasks for securing
an application.  Only things an admin would do and no developer
concerns should be there.

-- 
Bill Burke
Red Hat

From mstrukel at redhat.com  Mon Oct  2 12:32:07 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 2 Oct 2017 18:32:07 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
Message-ID: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>

I've been getting intermittent ConcurrencyTest failures.

Tests in error:

  ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->AbstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
? Runtime



I'm unable to reliably replicate it but it never happens when running
ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part of
full testsuite 30 mins into the run.

I propose to add:

static boolean runIntermittentlyFailingTests() {
    return "true".equals(System.getProperty("test.intermittent"));
}


in AbstractKeycloakTest.java and check at the beginning of
ConcurrencyTest.java#testAllConcurrently():

if (!runIntermittentlyFailingTests()) {
    System.out.println("TEST SKIPPED - This test currently suffers
from intermittent failures. Use -Dtest.intermittent=true to run it.");
    return;
}

From mposolda at redhat.com  Mon Oct  2 14:14:52 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 2 Oct 2017 20:14:52 +0200
Subject: [keycloak-dev] Standalone boot slow...Clustering introduced by
 accident?
In-Reply-To: <CABRXCmz6txir0LkqnPe0K4zytVxn9o=k5LvKi+Nv-FFNH5P6kA@mail.gmail.com>
References: <CABRXCmz6txir0LkqnPe0K4zytVxn9o=k5LvKi+Nv-FFNH5P6kA@mail.gmail.com>
Message-ID: <e28df733-7fa0-1ae5-f93e-e338e94e8b17@redhat.com>

Strange, Cross DC didn't add any configuration change by default.

And doesn't look to me that something was added by accident. I've just 
tried the fresh keycloak master build. The "standalone.sh" of 
keycloak-server distribution took me 10 seconds to start server. Second 
start just 7 seconds.

Marek


On 02/10/17 16:29, Bill Burke wrote:
> I was wondering if the CrossDC worked introduced clustering into
> standalone.xml by accident?  My standalone boot times are really slow
> (60 seconds).  I'll look into it after I finish up the documentation
> I'm doing, but maybe somebody knows something right now?
>
> Thanks
>


From mposolda at redhat.com  Mon Oct  2 14:21:35 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 2 Oct 2017 20:21:35 +0200
Subject: [keycloak-dev] Claims parameter support
In-Reply-To: <CAGZZ5OjKULV7i0rtkZf+q3JLjYz-oWcCs+wsqz5P2Bh5OaCObw@mail.gmail.com>
References: <CAGZZ5OisW6n9Da3h0MokoRcN9tAVzzSYGTwckwcRkXKGTRRnwA@mail.gmail.com>
	<9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com>
	<CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A@mail.gmail.com>
	<CAGZZ5OjKULV7i0rtkZf+q3JLjYz-oWcCs+wsqz5P2Bh5OaCObw@mail.gmail.com>
Message-ID: <a90993f3-f2bb-85db-7e90-49118348933d@redhat.com>

Cool, do you want to create JIRA and send PR with the commit?

Thanks,
Marek

On 01/10/17 20:23, Aron Bustya wrote:
> https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135
>
> I have updated my code - now it doesn't include the mapper itself, but 
> it does include the processing of the param as a "known param" and 
> some tests for this.
>
> On 30 September 2017 at 22:32, Aron Bustya <aron.bustya.js at gmail.com 
> <mailto:aron.bustya.js at gmail.com>> wrote:
>
>     Hi,
>
>     Sorry for the long silence.
>
>     >Maybe one small change, if you can add the "claims" to the AuthzEndpointRequestParser.KNOWN_PARAMS
>     and have separate client note for it as other known OIDC params?
>     This would be good, because the "additional" parameters have a
>     maximum length of 200 characters to be processed.
>
>
>
>     On 20 September 2017 at 09:55, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         Great work!
>
>         If I see it correctly, there are 2 parts:
>
>         1) improvements in request object parsing - I am all for
>         include your improvements. If you can create separate JIRA for
>         current request object limitation, add the test (there are
>         existing tests for request object in
>         OIDCAdvancedRequestParamsTest. Feel free to add new test or
>         change one of existing tests) and create separate PR, it will
>         be nice and will be merged. If I understand correctly, this is
>         the only part, which really blocks you right? (As additional
>         protocolMapper can be deployed to the existing Keycloak
>         instance as separate JAR and doesn't require changes in core
>         keycloak code?)
>
>         2) ProtocolMapper for claims - as you pointed, you don't have
>         full support for 'claims' parameter. Still it's better then
>         nothing, so my vote is to include your changes. I am not 100%
>         convinced, maybe someone has different opinion on it (new
>         protocolMapper always adds a bit of additional complexity.
>         However I think it's ok as it's OIDC standard). Maybe one
>         small change, if you can add the "claims" to the
>         AuthzEndpointRequestParser.KNOWN_PARAMS and have separate
>         client note for it as other known OIDC params?
>
>         Thanks!
>         Marek
>
>
>
>         On 19/09/17 22:49, Aron Bustya wrote:
>>         Hello! I need the 'claims parameter' support in keycloak that
>>         has been thought about in this jira ticket and
>>         postponed/rejected:
>>         https://issues.jboss.org/browse/KEYCLOAK-3226
>>         <https://issues.jboss.org/browse/KEYCLOAK-3226> The proposed
>>         alternatives don't work for me, because I am implementing a
>>         specification that explicitly requests data to be passed this
>>         way. In addition to the JIRA above we also need to support
>>         passing the claims parameter in the signed request object -
>>         not just as a separate query param. I've solved the problem
>>         for our own use case by writing a ProtocolMapper but some
>>         changes were also needed in the keycloak request parser (to
>>         support the parsing of json objects from the request object -
>>         not just strings). The ProtocolMapper I've written doesn't
>>         support the whole claims parameter feature though - it can
>>         only add the default value of the claim to the the tokens.
>>         I'm now trying to figure out how much of this code could be
>>         put back into keycloak, and what needs to be changed to do
>>         so. My goal would be to use an 'official' keycloak with
>>         cutomization only in Service Providers and configuration.
>>         Current code commit is here:
>>         https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
>>         <https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9>
>>
>>         6e210d8bd302d23fa7884da
>>
>>         What do you think about the direction of the development, does it make any
>>         sense to put some of it back into keycloak?
>>
>>         Regards,
>>         ?ron Bustya
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>


From bburke at redhat.com  Mon Oct  2 17:45:10 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Oct 2017 17:45:10 -0400
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
Message-ID: <CABRXCmyTp2uY8t3ihCW7Dt_fg_09sGVxzuwxTr543e4rn0f=kg@mail.gmail.com>

Adding per feature toggles is not a good idea.  We currently have
feature to feature dependencies.  For example, token exchange depends
on fine-grain admin permissions, and fine grain admin permissions
depends on authorization.  I've warned Stian about this and I guess he
doesn't care?  I still struggle to understand why we want to make
things more difficult on paying customers.

On Mon, Oct 2, 2017 at 9:37 AM, Marko Strukelj <mstrukel at redhat.com> wrote:
> The more I look at the idea of having '-preview' in feature names the more
> I think it will cause more trouble than it's worth.
>
> The reason is it complicates migration when we promote feature to stable -
> dropping '-preview' from its name, and it causes configuration names to be
> fluid over time.
>
> For example, consider how moving authorization from preview to stable would
> look for a user.
>
> User got used to using -Dfeature.authorization-preview=true
>
> Now we change this setting to be called -Dfeature.authorization=true. User
> still using -Dfeature.authorization-preview=true, will get a warning upon
> startup: 'Unknown feature system property: feature.authorization-preview',
> and the system property will have no effect. If user uses Keycloak
> distribution then authorization-preview will be enabled by default. So no
> need to explicitly enable it - a no-op operation in the first place, and a
> no-op operation at upgrade. If user sets the property to false, then after
> upgrade the feature will suddenly be enabled when before it was not.
>
> It doesn't seem right to drop configuration like that. If we want old
> config to keep working then every migration from preview to stable also has
> to add backwards compatibility logic, so that surprises like this don't
> happen. Also all documentation needs to be changed wherever the feature
> name is referenced.
>
> Whenever we promote any feature from '-preview' to stable this will be
> needed, and it may become standard ritual that may to most users seem
> completely redundant. Why not just call it -Dfeature.authorization in the
> first place, and maybe just display a warning if any 'preview' feature is
> enabled, something like:
>
> [WARN] The following preview features are enabled: ...
>
> WDYT?
>
>
> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> In standalone.xml I'd use "feature.scripts" sys properties instead of the
>> longer "keycloak.feature.scripts". It's just shorter and simpler and
>> won't cause any conflicts.
>>
>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>> as is, including if set in profile.properties. This is important in case
>> customers have explicitly disabled impersonation for example. +1 To
>> printing a warning in this case. Then let's remove the old deprecated
>> properties in Keycloak 3.5x as well as the profile.properties.
>>
>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> This is a heads up about an upcoming change in how to enable or disable
>>> features in Keycloak.
>>>
>>> Keycloak has a notion of features, which makes it possible to disable
>>> certain functionality that is enabled by default, or enable certain
>>> functionality that is disabled by default.
>>>
>>> There are four sets of functionality you can enable or disable as
>>> features:
>>> impersonation, script,  authorization, and docker. See [1] for more info.
>>>
>>> Currently a file called profile.properties can be used to enable / disable
>>> features, or system properties can be used, which override any
>>> configuration inside profile.properties as explained in [1].
>>>
>>> This is an aberration from how other configuration is specified on the
>>> server via standalone.xml.
>>>
>>> Also, the reason config file is called profile.properties, and not
>>> features.properties is because the set of enabled/disabled features is
>>> different for upstream project (where all but 'docker' are enabled), for
>>> product based on Keycloak - RHSSO (where only 'impersonation' is enabled),
>>> and for technology preview versions of RHSSO.
>>>
>>> This additionally complicates things. The idea is to simplify that and
>>> remove the notion of profiles, stop using profile.properties, and move all
>>> configuration to standalone.xml where all the available features will be
>>> listed with default values:
>>>
>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>
>>> ...
>>>
>>>   <features>
>>>     <feature name="authorization" enabled="true" />
>>>     <feature name="impersonation" enabled="true" />
>>>     <feature name="scripts" enabled="true" />
>>>     <feature name="docker" enabled="false" />
>>>   </features>
>>>
>>> ...
>>>
>>> </subsystem>
>>>
>>> This is how configuration would look like in Keycloak distribution. In
>>> product distributions different features would be enabled / disabled - no
>>> more named profiles.
>>>
>>> However, in order to allow system properties override the idea is to do it
>>> slightly differently:
>>>
>>>   <features>
>>>     <feature name="authorization"
>>> enabled="${keycloak.feature.authorization:true}" />
>>>     <feature name="impersonation"
>>> enabled="${keycloak.feature.impersonation:true}" />
>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}" />
>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}" />
>>>   </features>
>>>
>>>
>>> We should probably also facilitate transition for current deployments, and
>>> take old style system properties into account if they are used -
>>> converting
>>> them to the new ones before configuration is applied.
>>>
>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>> New style:    -Dkeycloak.feature.impersonation=true
>>>
>>> We don't want to keep support for this indefinitely (maybe for one minor
>>> version?) so if use of deprecated system properties is detected a warning
>>> will be logged.
>>>
>>> Also, Stian proposed that features not considered stable yet, should carry
>>> a suffix '-preview' in the name. So the actual feature name, and system
>>> property name may still change for some features.
>>>
>>> You can follow progress on JIRA issue [2].
>>>
>>> -
>>>
>>> [1]
>>> https://keycloak.gitbooks.io/documentation/server_installati
>>> on/topics/profiles.html
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Mon Oct  2 18:29:27 2017
From: bburke at redhat.com (Bill Burke)
Date: Mon, 2 Oct 2017 18:29:27 -0400
Subject: [keycloak-dev] Standalone boot slow...Clustering introduced by
	accident?
In-Reply-To: <e28df733-7fa0-1ae5-f93e-e338e94e8b17@redhat.com>
References: <CABRXCmz6txir0LkqnPe0K4zytVxn9o=k5LvKi+Nv-FFNH5P6kA@mail.gmail.com>
	<e28df733-7fa0-1ae5-f93e-e338e94e8b17@redhat.com>
Message-ID: <CABRXCmyQCn61zhFy6t2mHDJXnzUctxNC2BUMzY052sTDWiFAfQ@mail.gmail.com>

Maybe its just my machine

On Mon, Oct 2, 2017 at 2:14 PM, Marek Posolda <mposolda at redhat.com> wrote:
> Strange, Cross DC didn't add any configuration change by default.
>
> And doesn't look to me that something was added by accident. I've just tried
> the fresh keycloak master build. The "standalone.sh" of keycloak-server
> distribution took me 10 seconds to start server. Second start just 7
> seconds.
>
> Marek
>
>
>
> On 02/10/17 16:29, Bill Burke wrote:
>>
>> I was wondering if the CrossDC worked introduced clustering into
>> standalone.xml by accident?  My standalone boot times are really slow
>> (60 seconds).  I'll look into it after I finish up the documentation
>> I'm doing, but maybe somebody knows something right now?
>>
>> Thanks
>>
>



-- 
Bill Burke
Red Hat

From sthorger at redhat.com  Tue Oct  3 00:11:08 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 06:11:08 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
Message-ID: <CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>

Having '-preview' in the name clearly communicates the fact that it's a
tech preview feature. When it is made fully supported it should be enabled
out of the box by default. If we don't do this then users that haven't
enabled the feature when it was tech preview won't have it enabled when
it's fully supported. Alternatively, if you automatically change it from
disabled to enabled when it's moved from tech preview you don't know if
users actually had chosen to disable it or if that was just the default. In
either case I think it's cleaner and safer to rename, because the feature
does indeed change from preview to supported.

On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:

> The more I look at the idea of having '-preview' in feature names the more
> I think it will cause more trouble than it's worth.
>
> The reason is it complicates migration when we promote feature to stable -
> dropping '-preview' from its name, and it causes configuration names to be
> fluid over time.
>
> For example, consider how moving authorization from preview to stable
> would look for a user.
>
> User got used to using -Dfeature.authorization-preview=true
>
> Now we change this setting to be called -Dfeature.authorization=true. User
> still using -Dfeature.authorization-preview=true, will get a warning upon
> startup: 'Unknown feature system property: feature.authorization-preview',
> and the system property will have no effect. If user uses Keycloak
> distribution then authorization-preview will be enabled by default. So no
> need to explicitly enable it - a no-op operation in the first place, and a
> no-op operation at upgrade. If user sets the property to false, then after
> upgrade the feature will suddenly be enabled when before it was not.
>
> It doesn't seem right to drop configuration like that. If we want old
> config to keep working then every migration from preview to stable also has
> to add backwards compatibility logic, so that surprises like this don't
> happen. Also all documentation needs to be changed wherever the feature
> name is referenced.
>
> Whenever we promote any feature from '-preview' to stable this will be
> needed, and it may become standard ritual that may to most users seem
> completely redundant. Why not just call it -Dfeature.authorization in the
> first place, and maybe just display a warning if any 'preview' feature is
> enabled, something like:
>
> [WARN] The following preview features are enabled: ...
>
> WDYT?
>
>
> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> In standalone.xml I'd use "feature.scripts" sys properties instead of
>> the longer "keycloak.feature.scripts". It's just shorter and simpler and
>> won't cause any conflicts.
>>
>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>> as is, including if set in profile.properties. This is important in case
>> customers have explicitly disabled impersonation for example. +1 To
>> printing a warning in this case. Then let's remove the old deprecated
>> properties in Keycloak 3.5x as well as the profile.properties.
>>
>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> This is a heads up about an upcoming change in how to enable or disable
>>> features in Keycloak.
>>>
>>> Keycloak has a notion of features, which makes it possible to disable
>>> certain functionality that is enabled by default, or enable certain
>>> functionality that is disabled by default.
>>>
>>> There are four sets of functionality you can enable or disable as
>>> features:
>>> impersonation, script,  authorization, and docker. See [1] for more info.
>>>
>>> Currently a file called profile.properties can be used to enable /
>>> disable
>>> features, or system properties can be used, which override any
>>> configuration inside profile.properties as explained in [1].
>>>
>>> This is an aberration from how other configuration is specified on the
>>> server via standalone.xml.
>>>
>>> Also, the reason config file is called profile.properties, and not
>>> features.properties is because the set of enabled/disabled features is
>>> different for upstream project (where all but 'docker' are enabled), for
>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>> enabled),
>>> and for technology preview versions of RHSSO.
>>>
>>> This additionally complicates things. The idea is to simplify that and
>>> remove the notion of profiles, stop using profile.properties, and move
>>> all
>>> configuration to standalone.xml where all the available features will be
>>> listed with default values:
>>>
>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>
>>> ...
>>>
>>>   <features>
>>>     <feature name="authorization" enabled="true" />
>>>     <feature name="impersonation" enabled="true" />
>>>     <feature name="scripts" enabled="true" />
>>>     <feature name="docker" enabled="false" />
>>>   </features>
>>>
>>> ...
>>>
>>> </subsystem>
>>>
>>> This is how configuration would look like in Keycloak distribution. In
>>> product distributions different features would be enabled / disabled - no
>>> more named profiles.
>>>
>>> However, in order to allow system properties override the idea is to do
>>> it
>>> slightly differently:
>>>
>>>   <features>
>>>     <feature name="authorization"
>>> enabled="${keycloak.feature.authorization:true}" />
>>>     <feature name="impersonation"
>>> enabled="${keycloak.feature.impersonation:true}" />
>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>> />
>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}" />
>>>   </features>
>>>
>>>
>>> We should probably also facilitate transition for current deployments,
>>> and
>>> take old style system properties into account if they are used -
>>> converting
>>> them to the new ones before configuration is applied.
>>>
>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>> New style:    -Dkeycloak.feature.impersonation=true
>>>
>>> We don't want to keep support for this indefinitely (maybe for one minor
>>> version?) so if use of deprecated system properties is detected a warning
>>> will be logged.
>>>
>>> Also, Stian proposed that features not considered stable yet, should
>>> carry
>>> a suffix '-preview' in the name. So the actual feature name, and system
>>> property name may still change for some features.
>>>
>>> You can follow progress on JIRA issue [2].
>>>
>>> -
>>>
>>> [1]
>>> https://keycloak.gitbooks.io/documentation/server_installati
>>> on/topics/profiles.html
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>> _______________________________________________
>>> 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  3 00:13:18 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 06:13:18 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CABRXCmyTp2uY8t3ihCW7Dt_fg_09sGVxzuwxTr543e4rn0f=kg@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CABRXCmyTp2uY8t3ihCW7Dt_fg_09sGVxzuwxTr543e4rn0f=kg@mail.gmail.com>
Message-ID: <CAJgngAcLSyTBruBdWidHn+if6t13juOmYPqqe_coxZh=uyoVKw@mail.gmail.com>

Bill - I told you that if you want this changed you need to talk to John
about it, not me.

On 2 October 2017 at 23:45, Bill Burke <bburke at redhat.com> wrote:

> Adding per feature toggles is not a good idea.  We currently have
> feature to feature dependencies.  For example, token exchange depends
> on fine-grain admin permissions, and fine grain admin permissions
> depends on authorization.  I've warned Stian about this and I guess he
> doesn't care?  I still struggle to understand why we want to make
> things more difficult on paying customers.
>
> On Mon, Oct 2, 2017 at 9:37 AM, Marko Strukelj <mstrukel at redhat.com>
> wrote:
> > The more I look at the idea of having '-preview' in feature names the
> more
> > I think it will cause more trouble than it's worth.
> >
> > The reason is it complicates migration when we promote feature to stable
> -
> > dropping '-preview' from its name, and it causes configuration names to
> be
> > fluid over time.
> >
> > For example, consider how moving authorization from preview to stable
> would
> > look for a user.
> >
> > User got used to using -Dfeature.authorization-preview=true
> >
> > Now we change this setting to be called -Dfeature.authorization=true.
> User
> > still using -Dfeature.authorization-preview=true, will get a warning
> upon
> > startup: 'Unknown feature system property: feature.authorization-preview'
> ,
> > and the system property will have no effect. If user uses Keycloak
> > distribution then authorization-preview will be enabled by default. So no
> > need to explicitly enable it - a no-op operation in the first place, and
> a
> > no-op operation at upgrade. If user sets the property to false, then
> after
> > upgrade the feature will suddenly be enabled when before it was not.
> >
> > It doesn't seem right to drop configuration like that. If we want old
> > config to keep working then every migration from preview to stable also
> has
> > to add backwards compatibility logic, so that surprises like this don't
> > happen. Also all documentation needs to be changed wherever the feature
> > name is referenced.
> >
> > Whenever we promote any feature from '-preview' to stable this will be
> > needed, and it may become standard ritual that may to most users seem
> > completely redundant. Why not just call it -Dfeature.authorization in the
> > first place, and maybe just display a warning if any 'preview' feature is
> > enabled, something like:
> >
> > [WARN] The following preview features are enabled: ...
> >
> > WDYT?
> >
> >
> > On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
> > wrote:
> >
> >> In standalone.xml I'd use "feature.scripts" sys properties instead of
> the
> >> longer "keycloak.feature.scripts". It's just shorter and simpler and
> >> won't cause any conflicts.
> >>
> >> We need to support the old "keycloak.profile.feature.<
> featurename>=enabled|disabled"
> >> as is, including if set in profile.properties. This is important in case
> >> customers have explicitly disabled impersonation for example. +1 To
> >> printing a warning in this case. Then let's remove the old deprecated
> >> properties in Keycloak 3.5x as well as the profile.properties.
> >>
> >> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
> >>
> >>> This is a heads up about an upcoming change in how to enable or disable
> >>> features in Keycloak.
> >>>
> >>> Keycloak has a notion of features, which makes it possible to disable
> >>> certain functionality that is enabled by default, or enable certain
> >>> functionality that is disabled by default.
> >>>
> >>> There are four sets of functionality you can enable or disable as
> >>> features:
> >>> impersonation, script,  authorization, and docker. See [1] for more
> info.
> >>>
> >>> Currently a file called profile.properties can be used to enable /
> disable
> >>> features, or system properties can be used, which override any
> >>> configuration inside profile.properties as explained in [1].
> >>>
> >>> This is an aberration from how other configuration is specified on the
> >>> server via standalone.xml.
> >>>
> >>> Also, the reason config file is called profile.properties, and not
> >>> features.properties is because the set of enabled/disabled features is
> >>> different for upstream project (where all but 'docker' are enabled),
> for
> >>> product based on Keycloak - RHSSO (where only 'impersonation' is
> enabled),
> >>> and for technology preview versions of RHSSO.
> >>>
> >>> This additionally complicates things. The idea is to simplify that and
> >>> remove the notion of profiles, stop using profile.properties, and move
> all
> >>> configuration to standalone.xml where all the available features will
> be
> >>> listed with default values:
> >>>
> >>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
> >>>
> >>> ...
> >>>
> >>>   <features>
> >>>     <feature name="authorization" enabled="true" />
> >>>     <feature name="impersonation" enabled="true" />
> >>>     <feature name="scripts" enabled="true" />
> >>>     <feature name="docker" enabled="false" />
> >>>   </features>
> >>>
> >>> ...
> >>>
> >>> </subsystem>
> >>>
> >>> This is how configuration would look like in Keycloak distribution. In
> >>> product distributions different features would be enabled / disabled -
> no
> >>> more named profiles.
> >>>
> >>> However, in order to allow system properties override the idea is to
> do it
> >>> slightly differently:
> >>>
> >>>   <features>
> >>>     <feature name="authorization"
> >>> enabled="${keycloak.feature.authorization:true}" />
> >>>     <feature name="impersonation"
> >>> enabled="${keycloak.feature.impersonation:true}" />
> >>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
> />
> >>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
> />
> >>>   </features>
> >>>
> >>>
> >>> We should probably also facilitate transition for current deployments,
> and
> >>> take old style system properties into account if they are used -
> >>> converting
> >>> them to the new ones before configuration is applied.
> >>>
> >>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
> >>> New style:    -Dkeycloak.feature.impersonation=true
> >>>
> >>> We don't want to keep support for this indefinitely (maybe for one
> minor
> >>> version?) so if use of deprecated system properties is detected a
> warning
> >>> will be logged.
> >>>
> >>> Also, Stian proposed that features not considered stable yet, should
> carry
> >>> a suffix '-preview' in the name. So the actual feature name, and system
> >>> property name may still change for some features.
> >>>
> >>> You can follow progress on JIRA issue [2].
> >>>
> >>> -
> >>>
> >>> [1]
> >>> https://keycloak.gitbooks.io/documentation/server_installati
> >>> on/topics/profiles.html
> >>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Bill Burke
> Red Hat
>

From sthorger at redhat.com  Tue Oct  3 00:18:33 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 06:18:33 +0200
Subject: [keycloak-dev] enable SSL and SSL policies out of the box?
In-Reply-To: <CABRXCmxSCnP0-z07spzw9gF8hRdp+mzAv1AMJYJg=44d+nZ8PQ@mail.gmail.com>
References: <CABRXCmxSCnP0-z07spzw9gF8hRdp+mzAv1AMJYJg=44d+nZ8PQ@mail.gmail.com>
Message-ID: <CAJgngAfLJ5vgcJsfaU9H626qmJB3ZkPjS2PDWDcXePkMkEu5mQ@mail.gmail.com>

Keycloak 3.4.0.CR1 has SSL enabled out of the box as it builds on top of
WildFly 11.

As it's a self-signed certificate it's not secure and not that easy to use
though. Users would have to manually accept the cert in their browsers and
even worse they would have to import the cert into truststores for
applications. So it would make it harder to use in development even though
the cert is automatically generated.

On 2 October 2017 at 16:25, Bill Burke <bburke at redhat.com> wrote:

> I'm not sure, but I believe the latest Wildfly can auto create an SSL
> certificate at boot time.  Should we look into this prior to the end
> of 3.4.1 and have realm SSL policies changed to reflect this?  I never
> liked the idea that SSL is turned off and realm SSL policies don't
> require SSL by default.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> 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  3 00:21:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 06:21:30 +0200
Subject: [keycloak-dev] Doc renaming and organization suggestion
In-Reply-To: <CABRXCmzewJn8jdFCTueeDXqab3KFR5ucEAKz_=c+5ba-5eUPdg@mail.gmail.com>
References: <CABRXCmzewJn8jdFCTueeDXqab3KFR5ucEAKz_=c+5ba-5eUPdg@mail.gmail.com>
Message-ID: <CAJgngAdrU=j_6ifF+_jmCN5YPK1P17mtE6pFOYxMccUnXmM0JA@mail.gmail.com>

-1 I see a clear distinction between someone that wants to secure
applications/services with Keycloak and someone that wants to extend the
Keycloak server. Even when it's the same person they are very different
tasks.

On 2 October 2017 at 16:37, Bill Burke <bburke at redhat.com> wrote:

> I suggest we rename Server Developer Guide to Keycloak (RH-SSO)
> Developer Guide.  We move all programmer related SPIs, REST interface
> docs (token exchange), Client Registration, adapter SPIs, really
> anything a developer would do to this guide.
>
> Securing Apps should be specifically configuration tasks for securing
> an application.  Only things an admin would do and no developer
> concerns should be there.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> 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  3 00:22:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 06:22:43 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
In-Reply-To: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
References: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
Message-ID: <CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>

-1000 The tests needs fixing not ignoring. Can you create a JIRA for the
test that is unstable please?

On 2 October 2017 at 18:32, Marko Strukelj <mstrukel at redhat.com> wrote:

> I've been getting intermittent ConcurrencyTest failures.
>
> Tests in error:
>
>   ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->
> AbstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
> ? Runtime
>
>
>
> I'm unable to reliably replicate it but it never happens when running
> ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part of
> full testsuite 30 mins into the run.
>
> I propose to add:
>
> static boolean runIntermittentlyFailingTests() {
>     return "true".equals(System.getProperty("test.intermittent"));
> }
>
>
> in AbstractKeycloakTest.java and check at the beginning of
> ConcurrencyTest.java#testAllConcurrently():
>
> if (!runIntermittentlyFailingTests()) {
>     System.out.println("TEST SKIPPED - This test currently suffers
> from intermittent failures. Use -Dtest.intermittent=true to run it.");
>     return;
> }
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mstrukel at redhat.com  Tue Oct  3 04:40:46 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 3 Oct 2017 10:40:46 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
In-Reply-To: <CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>
References: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
	<CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>
Message-ID: <CA+1OW+i9cH0RuAhMt8zkNMMGjOaxHJu2=jmR-fNKrqAu+rZtYg@mail.gmail.com>

But now that we know it's failing, and I need to run four full builds with
slightly different options, that will take twice as long unless I disable
this test that is unrelated to my PR :)


On Oct 3, 2017 06:22, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> -1000 The tests needs fixing not ignoring. Can you create a JIRA for the
> test that is unstable please?
>
> On 2 October 2017 at 18:32, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> I've been getting intermittent ConcurrencyTest failures.
>>
>> Tests in error:
>>
>>   ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->A
>> bstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
>> ? Runtime
>>
>>
>>
>> I'm unable to reliably replicate it but it never happens when running
>> ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part of
>> full testsuite 30 mins into the run.
>>
>> I propose to add:
>>
>> static boolean runIntermittentlyFailingTests() {
>>     return "true".equals(System.getProperty("test.intermittent"));
>> }
>>
>>
>> in AbstractKeycloakTest.java and check at the beginning of
>> ConcurrencyTest.java#testAllConcurrently():
>>
>> if (!runIntermittentlyFailingTests()) {
>>     System.out.println("TEST SKIPPED - This test currently suffers
>> from intermittent failures. Use -Dtest.intermittent=true to run it.");
>>     return;
>> }
>> _______________________________________________
>> 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  3 04:43:16 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 10:43:16 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
In-Reply-To: <CA+1OW+i9cH0RuAhMt8zkNMMGjOaxHJu2=jmR-fNKrqAu+rZtYg@mail.gmail.com>
References: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
	<CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>
	<CA+1OW+i9cH0RuAhMt8zkNMMGjOaxHJu2=jmR-fNKrqAu+rZtYg@mail.gmail.com>
Message-ID: <CAJgngAd3V2yfg_RXdPqpRoVzvMyCXniaoHUTBvYCwNO3MGVdbg@mail.gmail.com>

Or, why not just ignore the fact that the test is failing?

On 3 October 2017 at 10:40, Marko Strukelj <mstrukel at redhat.com> wrote:

> But now that we know it's failing, and I need to run four full builds with
> slightly different options, that will take twice as long unless I disable
> this test that is unrelated to my PR :)
>
>
> On Oct 3, 2017 06:22, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> -1000 The tests needs fixing not ignoring. Can you create a JIRA for the
>> test that is unstable please?
>>
>> On 2 October 2017 at 18:32, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> I've been getting intermittent ConcurrencyTest failures.
>>>
>>> Tests in error:
>>>
>>>   ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->A
>>> bstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
>>> ? Runtime
>>>
>>>
>>>
>>> I'm unable to reliably replicate it but it never happens when running
>>> ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part of
>>> full testsuite 30 mins into the run.
>>>
>>> I propose to add:
>>>
>>> static boolean runIntermittentlyFailingTests() {
>>>     return "true".equals(System.getProperty("test.intermittent"));
>>> }
>>>
>>>
>>> in AbstractKeycloakTest.java and check at the beginning of
>>> ConcurrencyTest.java#testAllConcurrently():
>>>
>>> if (!runIntermittentlyFailingTests()) {
>>>     System.out.println("TEST SKIPPED - This test currently suffers
>>> from intermittent failures. Use -Dtest.intermittent=true to run it.");
>>>     return;
>>> }
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>

From mstrukel at redhat.com  Tue Oct  3 06:22:19 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 3 Oct 2017 12:22:19 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
In-Reply-To: <CAJgngAd3V2yfg_RXdPqpRoVzvMyCXniaoHUTBvYCwNO3MGVdbg@mail.gmail.com>
References: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
	<CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>
	<CA+1OW+i9cH0RuAhMt8zkNMMGjOaxHJu2=jmR-fNKrqAu+rZtYg@mail.gmail.com>
	<CAJgngAd3V2yfg_RXdPqpRoVzvMyCXniaoHUTBvYCwNO3MGVdbg@mail.gmail.com>
Message-ID: <CA+1OW+jVJHK-aM1qdDBNy08yJA=o7f4NsFazD8VqtnX_04nmRA@mail.gmail.com>

Created a JIRA: https://issues.jboss.org/browse/KEYCLOAK-5617

It's not as black and white as you put it. My assumption is that this test
will not get fixed for a forseable future because concurrency issues are
very hard to debug and fix. During that time everyone to whom this issue
manifests will stumble upon it multiple times unless disabling the test
locally manually, and taking extra care to not commit those changes.


On Tue, Oct 3, 2017 at 10:43 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Or, why not just ignore the fact that the test is failing?
>
> On 3 October 2017 at 10:40, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> But now that we know it's failing, and I need to run four full builds
>> with slightly different options, that will take twice as long unless I
>> disable this test that is unrelated to my PR :)
>>
>>
>> On Oct 3, 2017 06:22, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>>> -1000 The tests needs fixing not ignoring. Can you create a JIRA for the
>>> test that is unstable please?
>>>
>>> On 2 October 2017 at 18:32, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>>> I've been getting intermittent ConcurrencyTest failures.
>>>>
>>>> Tests in error:
>>>>
>>>>   ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->A
>>>> bstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
>>>> ? Runtime
>>>>
>>>>
>>>>
>>>> I'm unable to reliably replicate it but it never happens when running
>>>> ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part
>>>> of
>>>> full testsuite 30 mins into the run.
>>>>
>>>> I propose to add:
>>>>
>>>> static boolean runIntermittentlyFailingTests() {
>>>>     return "true".equals(System.getProperty("test.intermittent"));
>>>> }
>>>>
>>>>
>>>> in AbstractKeycloakTest.java and check at the beginning of
>>>> ConcurrencyTest.java#testAllConcurrently():
>>>>
>>>> if (!runIntermittentlyFailingTests()) {
>>>>     System.out.println("TEST SKIPPED - This test currently suffers
>>>> from intermittent failures. Use -Dtest.intermittent=true to run it.");
>>>>     return;
>>>> }
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>

From mstrukel at redhat.com  Tue Oct  3 06:26:36 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 3 Oct 2017 12:26:36 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
Message-ID: <CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>

On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:

Having '-preview' in the name clearly communicates the fact that it's a
tech preview feature. When it is made fully supported it should be enabled
out of the box by default. If we don't do this then users that haven't
enabled the feature when it was tech preview won't have it enabled when
it's fully supported. Alternatively, if you automatically change it from
disabled to enabled when it's moved from tech preview you don't know if
users actually had chosen to disable it or if that was just the default. In
either case I think it's cleaner and safer to rename, because the feature
does indeed change from preview to supported.


The case you point out with feature not getting disabled ...

Consider the case where user disables a preview feature with
-Dfeature.authorization-preview=false. It's a no-op for product, but not
for community distro. When we upgrade feature to stable user will get a
warning for an unknown feature, and the old config will not turn off the
feature any more - on product as well. So did we solve anything?

Do we want -Dfeature.authorization-preview=false to keep having effect even
after it's not called feature.authorization-preview any more? That's what I
call backwards compatibility. Will it remain in place forever or we give
ourself extra work not only adding it in the first place, but also removing
it at some point?

My point is that '-preview' adds complexity to maintain, may introduce
extra bugs, JIRAs, will require extra documentation ... so what it brings
to the table should outweigh the burden. Maybe there is another way to
achieve obviousness of the fact that some feature is 'preview' without
actually naming the feature, and all config options as such.



On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:

> The more I look at the idea of having '-preview' in feature names the more
> I think it will cause more trouble than it's worth.
>
> The reason is it complicates migration when we promote feature to stable -
> dropping '-preview' from its name, and it causes configuration names to be
> fluid over time.
>
> For example, consider how moving authorization from preview to stable
> would look for a user.
>
> User got used to using -Dfeature.authorization-preview=true
>
> Now we change this setting to be called -Dfeature.authorization=true. User
> still using -Dfeature.authorization-preview=true, will get a warning upon
> startup: 'Unknown feature system property: feature.authorization-preview',
> and the system property will have no effect. If user uses Keycloak
> distribution then authorization-preview will be enabled by default. So no
> need to explicitly enable it - a no-op operation in the first place, and a
> no-op operation at upgrade. If user sets the property to false, then after
> upgrade the feature will suddenly be enabled when before it was not.
>
> It doesn't seem right to drop configuration like that. If we want old
> config to keep working then every migration from preview to stable also has
> to add backwards compatibility logic, so that surprises like this don't
> happen. Also all documentation needs to be changed wherever the feature
> name is referenced.
>
> Whenever we promote any feature from '-preview' to stable this will be
> needed, and it may become standard ritual that may to most users seem
> completely redundant. Why not just call it -Dfeature.authorization in the
> first place, and maybe just display a warning if any 'preview' feature is
> enabled, something like:
>
> [WARN] The following preview features are enabled: ...
>
> WDYT?
>
>
> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> In standalone.xml I'd use "feature.scripts" sys properties instead of
>> the longer "keycloak.feature.scripts". It's just shorter and simpler and
>> won't cause any conflicts.
>>
>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>> as is, including if set in profile.properties. This is important in case
>> customers have explicitly disabled impersonation for example. +1 To
>> printing a warning in this case. Then let's remove the old deprecated
>> properties in Keycloak 3.5x as well as the profile.properties.
>>
>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> This is a heads up about an upcoming change in how to enable or disable
>>> features in Keycloak.
>>>
>>> Keycloak has a notion of features, which makes it possible to disable
>>> certain functionality that is enabled by default, or enable certain
>>> functionality that is disabled by default.
>>>
>>> There are four sets of functionality you can enable or disable as
>>> features:
>>> impersonation, script,  authorization, and docker. See [1] for more info.
>>>
>>> Currently a file called profile.properties can be used to enable /
>>> disable
>>> features, or system properties can be used, which override any
>>> configuration inside profile.properties as explained in [1].
>>>
>>> This is an aberration from how other configuration is specified on the
>>> server via standalone.xml.
>>>
>>> Also, the reason config file is called profile.properties, and not
>>> features.properties is because the set of enabled/disabled features is
>>> different for upstream project (where all but 'docker' are enabled), for
>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>> enabled),
>>> and for technology preview versions of RHSSO.
>>>
>>> This additionally complicates things. The idea is to simplify that and
>>> remove the notion of profiles, stop using profile.properties, and move
>>> all
>>> configuration to standalone.xml where all the available features will be
>>> listed with default values:
>>>
>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>
>>> ...
>>>
>>>   <features>
>>>     <feature name="authorization" enabled="true" />
>>>     <feature name="impersonation" enabled="true" />
>>>     <feature name="scripts" enabled="true" />
>>>     <feature name="docker" enabled="false" />
>>>   </features>
>>>
>>> ...
>>>
>>> </subsystem>
>>>
>>> This is how configuration would look like in Keycloak distribution. In
>>> product distributions different features would be enabled / disabled - no
>>> more named profiles.
>>>
>>> However, in order to allow system properties override the idea is to do
>>> it
>>> slightly differently:
>>>
>>>   <features>
>>>     <feature name="authorization"
>>> enabled="${keycloak.feature.authorization:true}" />
>>>     <feature name="impersonation"
>>> enabled="${keycloak.feature.impersonation:true}" />
>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>> />
>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}" />
>>>   </features>
>>>
>>>
>>> We should probably also facilitate transition for current deployments,
>>> and
>>> take old style system properties into account if they are used -
>>> converting
>>> them to the new ones before configuration is applied.
>>>
>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>> New style:    -Dkeycloak.feature.impersonation=true
>>>
>>> We don't want to keep support for this indefinitely (maybe for one minor
>>> version?) so if use of deprecated system properties is detected a warning
>>> will be logged.
>>>
>>> Also, Stian proposed that features not considered stable yet, should
>>> carry
>>> a suffix '-preview' in the name. So the actual feature name, and system
>>> property name may still change for some features.
>>>
>>> You can follow progress on JIRA issue [2].
>>>
>>> -
>>>
>>> [1]
>>> https://keycloak.gitbooks.io/documentation/server_installati
>>> on/topics/profiles.html
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>

From mstrukel at redhat.com  Tue Oct  3 06:37:49 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 3 Oct 2017 12:37:49 +0200
Subject: [keycloak-dev] KEYCLOAK-5032 - Implementation question
In-Reply-To: <11C9C746-8334-424C-A608-7AD99B712418@Telia.no>
References: <890BFF49-124B-4099-8D3F-4430EAAA6ABF@Telia.no>
	<CABRXCmx19uAA378Egdw8COjKMx=1NWdQxtC0BVAWxZdftLOpGg@mail.gmail.com>
	<B77FEC0A-32CD-4FA3-89B7-0FA54CEAA433@Telia.no>
	<11C9C746-8334-424C-A608-7AD99B712418@Telia.no>
Message-ID: <CA+1OW+iZ_5+f_b2A14SkYbtqbu9rgCwNnsJCMoT4Djr9BoZ8nw@mail.gmail.com>

CI uses extra options. Try running your tests with -Pauth-server-wildfly.
That usually exposes extra issues.

On Mon, Oct 2, 2017 at 1:34 PM, <carl-kristian.eriksen at telia.no> wrote:

> The second commit in the PR failed the CI build, but the tests does not
> fail locally.
> Do you have any suggestions on how to handle this?
>
> Carl Kristian Eriksen
>
>
> On 29/09/17 16:41, "keycloak-dev-bounces at lists.jboss.org on behalf of
> carl-kristian.eriksen at telia.no" <keycloak-dev-bounces at lists.jboss.org on
> behalf of carl-kristian.eriksen at telia.no> wrote:
>
>     Hi.
>
>      I?ll follow up on the PR.
>
>     Br / mvh
>     Carl Kristian Eriksen
>     On 29/09/17 15:50, "Bill Burke" <bburke at redhat.com> wrote:
>
>         Do you want to continue talking on the PR or here?  I had some
>         concerns with your PR.
>
>         On Wed, Sep 27, 2017 at 5:45 AM,  <carl-kristian.eriksen at telia.no>
> wrote:
>         > https://issues.jboss.org/browse/KEYCLOAK-5032 describes two
> requested query parameters: acr_values and nonce
>         >
>         > Our requirements are for acr_values and prompt, and I?m working
> on a pull request for these two.
>         >
>         > How many pull requests do you want?
>         > Should I make sure that (each)PR includes support for one, two
> or three query parameters
>         >
>         > Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I
> need another Jira task for the ?prompt? parameter?
>         >
>         > Br / mvh
>         > Carl Kristian Eriksen
>     > _______________________________________________
>         > keycloak-dev mailing list
>         > keycloak-dev at lists.jboss.org
>         > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>         --
>         Bill Burke
>         Red Hat
>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From sthorger at redhat.com  Tue Oct  3 07:33:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 13:33:51 +0200
Subject: [keycloak-dev] ConcurrencyTest failures
In-Reply-To: <CA+1OW+jVJHK-aM1qdDBNy08yJA=o7f4NsFazD8VqtnX_04nmRA@mail.gmail.com>
References: <CA+1OW+jNMR88YwokoD7qeTqfneou=OOMfPcD+r+s2+kmckcvkA@mail.gmail.com>
	<CAJgngActSvJL6wyEA6XJX3Z1SL=U+kt-EMa3r=nYR81rVw9TSw@mail.gmail.com>
	<CA+1OW+i9cH0RuAhMt8zkNMMGjOaxHJu2=jmR-fNKrqAu+rZtYg@mail.gmail.com>
	<CAJgngAd3V2yfg_RXdPqpRoVzvMyCXniaoHUTBvYCwNO3MGVdbg@mail.gmail.com>
	<CA+1OW+jVJHK-aM1qdDBNy08yJA=o7f4NsFazD8VqtnX_04nmRA@mail.gmail.com>
Message-ID: <CAJgngAc73ZriHjuAtBOiE893X+B76QYPi=wqPuMccXUg1LTLuQ@mail.gmail.com>

If we want to have stable CI and run CI as part of PRs the tests have to be
stable. So we just have to put the effort into stabilizing tests.

On 3 October 2017 at 12:22, Marko Strukelj <mstrukel at redhat.com> wrote:

> Created a JIRA: https://issues.jboss.org/browse/KEYCLOAK-5617
>
> It's not as black and white as you put it. My assumption is that this test
> will not get fixed for a forseable future because concurrency issues are
> very hard to debug and fix. During that time everyone to whom this issue
> manifests will stumble upon it multiple times unless disabling the test
> locally manually, and taking extra care to not commit those changes.
>
>
> On Tue, Oct 3, 2017 at 10:43 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Or, why not just ignore the fact that the test is failing?
>>
>> On 3 October 2017 at 10:40, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> But now that we know it's failing, and I need to run four full builds
>>> with slightly different options, that will take twice as long unless I
>>> disable this test that is unrelated to my PR :)
>>>
>>>
>>> On Oct 3, 2017 06:22, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>
>>>> -1000 The tests needs fixing not ignoring. Can you create a JIRA for
>>>> the test that is unstable please?
>>>>
>>>> On 2 October 2017 at 18:32, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>>
>>>>> I've been getting intermittent ConcurrencyTest failures.
>>>>>
>>>>> Tests in error:
>>>>>
>>>>>   ConcurrencyTest.testAllConcurrently:57->concurrentTest:49->A
>>>>> bstractConcurrencyTest.run:53->AbstractConcurrencyTest.run:96
>>>>> ? Runtime
>>>>>
>>>>>
>>>>>
>>>>> I'm unable to reliably replicate it but it never happens when running
>>>>> ConcurrencyTest alone (i.e. -Dtest=ConcurrencyTest) but always as part
>>>>> of
>>>>> full testsuite 30 mins into the run.
>>>>>
>>>>> I propose to add:
>>>>>
>>>>> static boolean runIntermittentlyFailingTests() {
>>>>>     return "true".equals(System.getProperty("test.intermittent"));
>>>>> }
>>>>>
>>>>>
>>>>> in AbstractKeycloakTest.java and check at the beginning of
>>>>> ConcurrencyTest.java#testAllConcurrently():
>>>>>
>>>>> if (!runIntermittentlyFailingTests()) {
>>>>>     System.out.println("TEST SKIPPED - This test currently suffers
>>>>> from intermittent failures. Use -Dtest.intermittent=true to run it.");
>>>>>     return;
>>>>> }
>>>>> _______________________________________________
>>>>> 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  3 07:36:17 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 13:36:17 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
Message-ID: <CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>

In what you are proposing what happens when a feature goes from tech
preview to supported? It would still be disabled by default right?

On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com> wrote:

>
> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
> Having '-preview' in the name clearly communicates the fact that it's a
> tech preview feature. When it is made fully supported it should be enabled
> out of the box by default. If we don't do this then users that haven't
> enabled the feature when it was tech preview won't have it enabled when
> it's fully supported. Alternatively, if you automatically change it from
> disabled to enabled when it's moved from tech preview you don't know if
> users actually had chosen to disable it or if that was just the default. In
> either case I think it's cleaner and safer to rename, because the feature
> does indeed change from preview to supported.
>
>
> The case you point out with feature not getting disabled ...
>
> Consider the case where user disables a preview feature with
> -Dfeature.authorization-preview=false. It's a no-op for product, but not
> for community distro. When we upgrade feature to stable user will get a
> warning for an unknown feature, and the old config will not turn off the
> feature any more - on product as well. So did we solve anything?
>
> Do we want -Dfeature.authorization-preview=false to keep having effect
> even after it's not called feature.authorization-preview any more? That's
> what I call backwards compatibility. Will it remain in place forever or we
> give ourself extra work not only adding it in the first place, but also
> removing it at some point?
>
> My point is that '-preview' adds complexity to maintain, may introduce
> extra bugs, JIRAs, will require extra documentation ... so what it brings
> to the table should outweigh the burden. Maybe there is another way to
> achieve obviousness of the fact that some feature is 'preview' without
> actually naming the feature, and all config options as such.
>
>
>
> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> The more I look at the idea of having '-preview' in feature names the
>> more I think it will cause more trouble than it's worth.
>>
>> The reason is it complicates migration when we promote feature to stable
>> - dropping '-preview' from its name, and it causes configuration names to
>> be fluid over time.
>>
>> For example, consider how moving authorization from preview to stable
>> would look for a user.
>>
>> User got used to using -Dfeature.authorization-preview=true
>>
>> Now we change this setting to be called -Dfeature.authorization=true.
>> User still using -Dfeature.authorization-preview=true, will get a
>> warning upon startup: 'Unknown feature system property:
>> feature.authorization-preview', and the system property will have no
>> effect. If user uses Keycloak distribution then authorization-preview will
>> be enabled by default. So no need to explicitly enable it - a no-op
>> operation in the first place, and a no-op operation at upgrade. If user
>> sets the property to false, then after upgrade the feature will suddenly be
>> enabled when before it was not.
>>
>> It doesn't seem right to drop configuration like that. If we want old
>> config to keep working then every migration from preview to stable also has
>> to add backwards compatibility logic, so that surprises like this don't
>> happen. Also all documentation needs to be changed wherever the feature
>> name is referenced.
>>
>> Whenever we promote any feature from '-preview' to stable this will be
>> needed, and it may become standard ritual that may to most users seem
>> completely redundant. Why not just call it -Dfeature.authorization in the
>> first place, and maybe just display a warning if any 'preview' feature is
>> enabled, something like:
>>
>> [WARN] The following preview features are enabled: ...
>>
>> WDYT?
>>
>>
>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> In standalone.xml I'd use "feature.scripts" sys properties instead of
>>> the longer "keycloak.feature.scripts". It's just shorter and simpler
>>> and won't cause any conflicts.
>>>
>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>> as is, including if set in profile.properties. This is important in
>>> case customers have explicitly disabled impersonation for example. +1 To
>>> printing a warning in this case. Then let's remove the old deprecated
>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>
>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>>> This is a heads up about an upcoming change in how to enable or disable
>>>> features in Keycloak.
>>>>
>>>> Keycloak has a notion of features, which makes it possible to disable
>>>> certain functionality that is enabled by default, or enable certain
>>>> functionality that is disabled by default.
>>>>
>>>> There are four sets of functionality you can enable or disable as
>>>> features:
>>>> impersonation, script,  authorization, and docker. See [1] for more
>>>> info.
>>>>
>>>> Currently a file called profile.properties can be used to enable /
>>>> disable
>>>> features, or system properties can be used, which override any
>>>> configuration inside profile.properties as explained in [1].
>>>>
>>>> This is an aberration from how other configuration is specified on the
>>>> server via standalone.xml.
>>>>
>>>> Also, the reason config file is called profile.properties, and not
>>>> features.properties is because the set of enabled/disabled features is
>>>> different for upstream project (where all but 'docker' are enabled), for
>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>> enabled),
>>>> and for technology preview versions of RHSSO.
>>>>
>>>> This additionally complicates things. The idea is to simplify that and
>>>> remove the notion of profiles, stop using profile.properties, and move
>>>> all
>>>> configuration to standalone.xml where all the available features will be
>>>> listed with default values:
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>
>>>> ...
>>>>
>>>>   <features>
>>>>     <feature name="authorization" enabled="true" />
>>>>     <feature name="impersonation" enabled="true" />
>>>>     <feature name="scripts" enabled="true" />
>>>>     <feature name="docker" enabled="false" />
>>>>   </features>
>>>>
>>>> ...
>>>>
>>>> </subsystem>
>>>>
>>>> This is how configuration would look like in Keycloak distribution. In
>>>> product distributions different features would be enabled / disabled -
>>>> no
>>>> more named profiles.
>>>>
>>>> However, in order to allow system properties override the idea is to do
>>>> it
>>>> slightly differently:
>>>>
>>>>   <features>
>>>>     <feature name="authorization"
>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>     <feature name="impersonation"
>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>> />
>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>> />
>>>>   </features>
>>>>
>>>>
>>>> We should probably also facilitate transition for current deployments,
>>>> and
>>>> take old style system properties into account if they are used -
>>>> converting
>>>> them to the new ones before configuration is applied.
>>>>
>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>
>>>> We don't want to keep support for this indefinitely (maybe for one minor
>>>> version?) so if use of deprecated system properties is detected a
>>>> warning
>>>> will be logged.
>>>>
>>>> Also, Stian proposed that features not considered stable yet, should
>>>> carry
>>>> a suffix '-preview' in the name. So the actual feature name, and system
>>>> property name may still change for some features.
>>>>
>>>> You can follow progress on JIRA issue [2].
>>>>
>>>> -
>>>>
>>>> [1]
>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>> on/topics/profiles.html
>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
>

From aron.bustya.js at gmail.com  Tue Oct  3 10:12:10 2017
From: aron.bustya.js at gmail.com (Aron Bustya)
Date: Tue, 3 Oct 2017 16:12:10 +0200
Subject: [keycloak-dev] Claims parameter support
In-Reply-To: <a90993f3-f2bb-85db-7e90-49118348933d@redhat.com>
References: <CAGZZ5OisW6n9Da3h0MokoRcN9tAVzzSYGTwckwcRkXKGTRRnwA@mail.gmail.com>
	<9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com>
	<CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A@mail.gmail.com>
	<CAGZZ5OjKULV7i0rtkZf+q3JLjYz-oWcCs+wsqz5P2Bh5OaCObw@mail.gmail.com>
	<a90993f3-f2bb-85db-7e90-49118348933d@redhat.com>
Message-ID: <CAGZZ5OieteeAPAGLWoBcw8ScPU--x=2eS+29pYHRVHoWKoxopA@mail.gmail.com>

Here's the JIRA - with pull request sent:

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

On 2 October 2017 at 20:21, Marek Posolda <mposolda at redhat.com> wrote:

> Cool, do you want to create JIRA and send PR with the commit?
>
> Thanks,
> Marek
>
>
> On 01/10/17 20:23, Aron Bustya wrote:
>
> https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa
> 25affa5135
>
> I have updated my code - now it doesn't include the mapper itself, but it
> does include the processing of the param as a "known param" and some tests
> for this.
>
> On 30 September 2017 at 22:32, Aron Bustya <aron.bustya.js at gmail.com>
> wrote:
>
>> Hi,
>>
>> Sorry for the long silence.
>>
>> >Maybe one small change, if you can add the "claims" to the
>> AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note
>> for it as other known OIDC params?
>> This would be good, because the "additional" parameters have a maximum
>> length of 200 characters to be processed.
>>
>>
>>
>> On 20 September 2017 at 09:55, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> Great work!
>>>
>>> If I see it correctly, there are 2 parts:
>>>
>>> 1) improvements in request object parsing - I am all for include your
>>> improvements. If you can create separate JIRA for current request object
>>> limitation, add the test (there are existing tests for request object in
>>> OIDCAdvancedRequestParamsTest. Feel free to add new test or change one of
>>> existing tests) and create separate PR, it will be nice and will be merged.
>>> If I understand correctly, this is the only part, which really blocks you
>>> right? (As additional protocolMapper can be deployed to the existing
>>> Keycloak instance as separate JAR and doesn't require changes in core
>>> keycloak code?)
>>>
>>> 2) ProtocolMapper for claims - as you pointed, you don't have full
>>> support for 'claims' parameter. Still it's better then nothing, so my vote
>>> is to include your changes. I am not 100% convinced, maybe someone has
>>> different opinion on it (new protocolMapper always adds a bit of additional
>>> complexity. However I think it's ok as it's OIDC standard). Maybe one small
>>> change, if you can add the "claims" to the
>>> AuthzEndpointRequestParser.KNOWN_PARAMS and have separate client note
>>> for it as other known OIDC params?
>>>
>>> Thanks!
>>> Marek
>>>
>>>
>>>
>>> On 19/09/17 22:49, Aron Bustya wrote:
>>>
>>> Hello!
>>>
>>> I need the 'claims parameter' support in keycloak that has been thought
>>> about in this jira ticket and postponed/rejected:https://issues.jboss.org/browse/KEYCLOAK-3226
>>> The proposed alternatives don't work for me, because I am implementing a
>>> specification that explicitly requests data to be passed this way.
>>> In addition to the JIRA above we also need to support passing the claims
>>> parameter in the signed request object - not just as a separate query param.
>>>
>>> I've solved the problem for our own use case by writing a ProtocolMapper
>>> but some changes were also needed in the keycloak request parser (to
>>> support the parsing of json objects from the request object - not just
>>> strings).
>>>
>>> The ProtocolMapper I've written doesn't support the whole claims parameter
>>> feature though - it can only add the default value of the claim to the the
>>> tokens.
>>>
>>> I'm now trying to figure out how much of this code could be put back into
>>> keycloak, and what needs to be changed to do so.
>>> My goal would be to use an 'official' keycloak with cutomization only in
>>> Service Providers and configuration.
>>>
>>> Current code commit is here:https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
>>>
>>> 6e210d8bd302d23fa7884da
>>>
>>> What do you think about the direction of the development, does it make any
>>> sense to put some of it back into keycloak?
>>>
>>> Regards,
>>> ?ron Bustya
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>
>

From mstrukel at redhat.com  Tue Oct  3 11:12:52 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 3 Oct 2017 17:12:52 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
	<CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
Message-ID: <CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>

I guess changing enabled status of features is a requirement, so feature
would become enabled after transition to supported. There would still be
different enabled statuses for community and product. It would just not be
reflected in feature's name.

If we just use -Dfeature.authorization=true / false (no -preview suffix)
while feature has preview status, then if user is oblivious of the setting
and doesn't use it to override defaults, enabling the feature by default
will have effect.

But if user wants to make sure feature doesn't get enabled (both while it's
preview, and for the future when it's stable) then
-Dfeature.authorization=false can be set, and now when newer version of
community or product is used this setting will have effect - it will not
become deprecated, it will just work like it worked when the feature had
preview status.

All we have to figure out is how best to have users aware that some feature
has preview status since it would not be part of feature's name any more.

We will want to document it in the docs - point out preview features in
features.adoc, and changes in enabled status in changes.adoc.
And we can log a warning during startup when features with preview status
are enabled. I already list the disabled features, so it's clear what
functionalities of the server are not available.

I don't know about finegrained permitions Bill has mentioned. The list of
features currently is: authorization-preview, impersonation,
scripts-preview, docker, account2-preview, token-exchange

(the last two have been added recently - I took the liberty to give
account2 preview status - maybe it should not have it, and maybe
token-exchange should have it?)

So, I don't know where fine grained permissions come to play here - I would
assume it simply means that if someone enables token-exchange that also
requires authorization in order to take effect. And we can make that check,
and either display warnings that feature can't take effect or automatically
enable the dependency feature.

But my proposal is essentially just to not name features with '-preview' at
all while still knowing for each feature if it has preview status, so we
can display warnings when it's enabled.


On Tue, Oct 3, 2017 at 1:36 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> In what you are proposing what happens when a feature goes from tech
> preview to supported? It would still be disabled by default right?
>
> On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>>
>> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>
>> Having '-preview' in the name clearly communicates the fact that it's a
>> tech preview feature. When it is made fully supported it should be enabled
>> out of the box by default. If we don't do this then users that haven't
>> enabled the feature when it was tech preview won't have it enabled when
>> it's fully supported. Alternatively, if you automatically change it from
>> disabled to enabled when it's moved from tech preview you don't know if
>> users actually had chosen to disable it or if that was just the default. In
>> either case I think it's cleaner and safer to rename, because the feature
>> does indeed change from preview to supported.
>>
>>
>> The case you point out with feature not getting disabled ...
>>
>> Consider the case where user disables a preview feature with
>> -Dfeature.authorization-preview=false. It's a no-op for product, but not
>> for community distro. When we upgrade feature to stable user will get a
>> warning for an unknown feature, and the old config will not turn off the
>> feature any more - on product as well. So did we solve anything?
>>
>> Do we want -Dfeature.authorization-preview=false to keep having effect
>> even after it's not called feature.authorization-preview any more? That's
>> what I call backwards compatibility. Will it remain in place forever or we
>> give ourself extra work not only adding it in the first place, but also
>> removing it at some point?
>>
>> My point is that '-preview' adds complexity to maintain, may introduce
>> extra bugs, JIRAs, will require extra documentation ... so what it brings
>> to the table should outweigh the burden. Maybe there is another way to
>> achieve obviousness of the fact that some feature is 'preview' without
>> actually naming the feature, and all config options as such.
>>
>>
>>
>> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> The more I look at the idea of having '-preview' in feature names the
>>> more I think it will cause more trouble than it's worth.
>>>
>>> The reason is it complicates migration when we promote feature to stable
>>> - dropping '-preview' from its name, and it causes configuration names to
>>> be fluid over time.
>>>
>>> For example, consider how moving authorization from preview to stable
>>> would look for a user.
>>>
>>> User got used to using -Dfeature.authorization-preview=true
>>>
>>> Now we change this setting to be called -Dfeature.authorization=true.
>>> User still using -Dfeature.authorization-preview=true, will get a
>>> warning upon startup: 'Unknown feature system property:
>>> feature.authorization-preview', and the system property will have no
>>> effect. If user uses Keycloak distribution then authorization-preview will
>>> be enabled by default. So no need to explicitly enable it - a no-op
>>> operation in the first place, and a no-op operation at upgrade. If user
>>> sets the property to false, then after upgrade the feature will suddenly be
>>> enabled when before it was not.
>>>
>>> It doesn't seem right to drop configuration like that. If we want old
>>> config to keep working then every migration from preview to stable also has
>>> to add backwards compatibility logic, so that surprises like this don't
>>> happen. Also all documentation needs to be changed wherever the feature
>>> name is referenced.
>>>
>>> Whenever we promote any feature from '-preview' to stable this will be
>>> needed, and it may become standard ritual that may to most users seem
>>> completely redundant. Why not just call it -Dfeature.authorization in the
>>> first place, and maybe just display a warning if any 'preview' feature is
>>> enabled, something like:
>>>
>>> [WARN] The following preview features are enabled: ...
>>>
>>> WDYT?
>>>
>>>
>>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> In standalone.xml I'd use "feature.scripts" sys properties instead of
>>>> the longer "keycloak.feature.scripts". It's just shorter and simpler
>>>> and won't cause any conflicts.
>>>>
>>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>>> as is, including if set in profile.properties. This is important in
>>>> case customers have explicitly disabled impersonation for example. +1 To
>>>> printing a warning in this case. Then let's remove the old deprecated
>>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>>
>>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>>
>>>>> This is a heads up about an upcoming change in how to enable or disable
>>>>> features in Keycloak.
>>>>>
>>>>> Keycloak has a notion of features, which makes it possible to disable
>>>>> certain functionality that is enabled by default, or enable certain
>>>>> functionality that is disabled by default.
>>>>>
>>>>> There are four sets of functionality you can enable or disable as
>>>>> features:
>>>>> impersonation, script,  authorization, and docker. See [1] for more
>>>>> info.
>>>>>
>>>>> Currently a file called profile.properties can be used to enable /
>>>>> disable
>>>>> features, or system properties can be used, which override any
>>>>> configuration inside profile.properties as explained in [1].
>>>>>
>>>>> This is an aberration from how other configuration is specified on the
>>>>> server via standalone.xml.
>>>>>
>>>>> Also, the reason config file is called profile.properties, and not
>>>>> features.properties is because the set of enabled/disabled features is
>>>>> different for upstream project (where all but 'docker' are enabled),
>>>>> for
>>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>>> enabled),
>>>>> and for technology preview versions of RHSSO.
>>>>>
>>>>> This additionally complicates things. The idea is to simplify that and
>>>>> remove the notion of profiles, stop using profile.properties, and move
>>>>> all
>>>>> configuration to standalone.xml where all the available features will
>>>>> be
>>>>> listed with default values:
>>>>>
>>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>>
>>>>> ...
>>>>>
>>>>>   <features>
>>>>>     <feature name="authorization" enabled="true" />
>>>>>     <feature name="impersonation" enabled="true" />
>>>>>     <feature name="scripts" enabled="true" />
>>>>>     <feature name="docker" enabled="false" />
>>>>>   </features>
>>>>>
>>>>> ...
>>>>>
>>>>> </subsystem>
>>>>>
>>>>> This is how configuration would look like in Keycloak distribution. In
>>>>> product distributions different features would be enabled / disabled -
>>>>> no
>>>>> more named profiles.
>>>>>
>>>>> However, in order to allow system properties override the idea is to
>>>>> do it
>>>>> slightly differently:
>>>>>
>>>>>   <features>
>>>>>     <feature name="authorization"
>>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>>     <feature name="impersonation"
>>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>>> />
>>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>>> />
>>>>>   </features>
>>>>>
>>>>>
>>>>> We should probably also facilitate transition for current deployments,
>>>>> and
>>>>> take old style system properties into account if they are used -
>>>>> converting
>>>>> them to the new ones before configuration is applied.
>>>>>
>>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>>
>>>>> We don't want to keep support for this indefinitely (maybe for one
>>>>> minor
>>>>> version?) so if use of deprecated system properties is detected a
>>>>> warning
>>>>> will be logged.
>>>>>
>>>>> Also, Stian proposed that features not considered stable yet, should
>>>>> carry
>>>>> a suffix '-preview' in the name. So the actual feature name, and system
>>>>> property name may still change for some features.
>>>>>
>>>>> You can follow progress on JIRA issue [2].
>>>>>
>>>>> -
>>>>>
>>>>> [1]
>>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>>> on/topics/profiles.html
>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>>
>

From tberry at redhat.com  Tue Oct  3 11:20:16 2017
From: tberry at redhat.com (Tana Berry)
Date: Tue, 3 Oct 2017 10:20:16 -0500
Subject: [keycloak-dev] DOCS: change to Auth Services /topics file structure
Message-ID: <CACj2hjSqA9YwG3aXY0VFBHaZJaC3cAvrCwQsjNV=zKhQGy=a+w@mail.gmail.com>

Hello Keycloakers and Red Hatters. I'm Tana, good to meet you all,
virtually! :-) As I am new to Red Hat and to the Keycloak community, here's
a bit more background about me, hopefully nothing too shocking:
https://github.com/tanberry and https://twitter.com/tanamarieberry.

This is a quick heads up to our community and developers that we plan to
merge PR #184 <https://github.com/keycloak/keycloak-documentation/pull/184>
this
week, probably Wednesday or Thursday. This merge will convert the
Authorization Services Guide to a flat file structure, meaning all topics
for this book will be in a single dir, and not nested into separate
directories or  "chapters". We plan to convert only this one book for
3.x/7.2, and use it as a POC, because we want to keep changes to a minimum
for 7.2.

In RH-SSO 7.3 release we will convert the remaining books. There are
several reason for changing to a flat-file structure (visual findability in
dirs, flexibility when new topics are added or existing topics are moved,
to have unique file names, enhanced SEO...).

Please let us know if you have any questions, concerns, or comments; we
want your feedback!

Thanks, and I look forward to working with the Keycloak/SSO team!

tana

From jdennis at redhat.com  Tue Oct  3 11:29:34 2017
From: jdennis at redhat.com (John Dennis)
Date: Tue, 3 Oct 2017 11:29:34 -0400
Subject: [keycloak-dev] mechanisms to deploy/install for testing
Message-ID: <7dd4fa9d-48c7-190d-2f26-cb9bf6c643ce@redhat.com>

We utilize RH-SSO/Keycloak as the authentication component in many of 
our products. When our QE team does testing the automated testing needs 
to install and configure RH-SSO/Keycloak. At the moment the QE team is 
bypassing automation and is installing and configuring RH-SSO/Keycloak 
manually because they lack an automated process.

I was asked to inquire how the keycloak team does their automated 
testing with the hope your tools can be utilized so we don't have to 
build something from scratch.

To put things in context this is for the platform group which does not 
traditionally deal with middleware and the Java ecosystem. Software 
installation is exclusively done with RPM's. Preferred methods are:

1) Ansible playbooks
2) Puppet manifests
3) Shell scripts

Can you describe how your testing is performed and/or point us to 
documentation and/or repositories with the tools.

Thanks,
-- 
John

From alkazako at redhat.com  Tue Oct  3 13:37:25 2017
From: alkazako at redhat.com (Alexey Kazakov)
Date: Tue, 3 Oct 2017 10:37:25 -0700
Subject: [keycloak-dev] regarding expired sessions and token life-span
In-Reply-To: <CABRXCmzGr0FYJS0qyUAVc0wi3YQNZF=8RnNF2P+TX6t35eKjQw@mail.gmail.com>
References: <CADbX+RWW1r+223TtbYP2Mm5upN5-5kpS4Cd2ti9nxA0RumBQDA@mail.gmail.com>
	<CABRXCmzGr0FYJS0qyUAVc0wi3YQNZF=8RnNF2P+TX6t35eKjQw@mail.gmail.com>
Message-ID: <e2d79dba-93f3-5d33-cb62-7cce4bf62b18@redhat.com>

So, if all Keycloak nodes are down the user login sessions will be lost?

1. Start a few KC nodes. Some user logs into KC and the refresh token is
stored in the app.
2. Kill all the KC nodes, so, cache cannot be replicated across the
cluster. Re-start them again.
3. The app tries to refresh the token using the refresh token from step #1.
4. KC fails to refresh the token because there is no active session
associated with that token. So, user has to re-login.

Is this correct?

On 09/29/2017 06:49 AM, Bill Burke wrote:
> TLDR; only offline tokens require database storage.
>
> We have regular tokens and offline tokens.  We do not store regular
> tokens in memory or on disk.  Instead, we have the concept of a login
> session (UserSessionModel) which hold metadata about the login.  These
> sessions are stored in memory and within a distributed cache if in a
> cluster.  Access and Refresh tokens are minted, digitally signed and
> validated and created against metadata within the login session.
>
> Offline tokens are very long lived and thus require their login
> session being persisted in a database.
>
>
>
> On Thu, Sep 28, 2017 at 9:05 AM, Kishan Sagathiya <ksagathi at redhat.com> wrote:
>> Hi,
>> I am trying to figure out how Keycloak deals with expired sessions and how
>> token lifespan affects Keycloak database size and performance.
>> But I dont understand the directory structure and where to find the
>> relevant code.
>> If someone could give some pointers regarding this that would be great
>> Thanks :)
>>
>> -Kishan Sagathiya
>> _______________________________________________
>> 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  3 14:20:35 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 3 Oct 2017 20:20:35 +0200
Subject: [keycloak-dev] mechanisms to deploy/install for testing
In-Reply-To: <7dd4fa9d-48c7-190d-2f26-cb9bf6c643ce@redhat.com>
References: <7dd4fa9d-48c7-190d-2f26-cb9bf6c643ce@redhat.com>
Message-ID: <CAJgngAfv4G5jix07ad7yse-KegWRcucw0RywHhwfZ0-Xu0vjEA@mail.gmail.com>

I don't think our testsuite will be very useful to your QE team as it's
very Java heavy.

I'd recommend creating a realm import file to make it easy to bulk
configure RH-SSO/Keycloak at startup. See [1] for example. Then it's just a
matter of getting a Keycloak server up and running and adding
"-Dkeycloak.import=<path to realm json file>" to startup command. Use RPMs,
Docker or an Ansible playbook to unzip the zips, whatever is easier for
you. I'd use Docker if it was up to me.

[1]
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/testrealm.json

On 3 October 2017 at 17:29, John Dennis <jdennis at redhat.com> wrote:

> We utilize RH-SSO/Keycloak as the authentication component in many of
> our products. When our QE team does testing the automated testing needs
> to install and configure RH-SSO/Keycloak. At the moment the QE team is
> bypassing automation and is installing and configuring RH-SSO/Keycloak
> manually because they lack an automated process.
>
> I was asked to inquire how the keycloak team does their automated
> testing with the hope your tools can be utilized so we don't have to
> build something from scratch.
>
> To put things in context this is for the platform group which does not
> traditionally deal with middleware and the Java ecosystem. Software
> installation is exclusively done with RPM's. Preferred methods are:
>
> 1) Ansible playbooks
> 2) Puppet manifests
> 3) Shell scripts
>
> Can you describe how your testing is performed and/or point us to
> documentation and/or repositories with the tools.
>
> Thanks,
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From takashi.norimatsu.ws at hitachi.com  Wed Oct  4 00:03:55 2017
From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=)
Date: Wed, 4 Oct 2017 04:03:55 +0000
Subject: [keycloak-dev] Including OAuth Scope in Response from Token
 Endpoint (Financial API Read Only Profile Requirement)
Message-ID: <831D472326678942A9B4BB933AAA103D68CF1C82@GSjpTK1DCembx01.service.hitachi.net>

Hello.

I've investigated into keycloak to find out whether it completely conforms to Financial API Read Only Profile Requirements for Authorization Server and found that it does not satisfy only one point.

Therefore, I've implemented this point, namely always including OAuth scope in the response from Token Endpoint.

Financial API is API's security requirement for API services in financial sector.
It is specified by OpenID Foundation.
http://openid.net/wg/fapi/

Financial API Read Only Profile Requirements for Authorization Server is the following.
http://openid.net/specs/openid-financial-api-part-1.html#authorization-server
* shall return the list of allowed scopes with the issued access token;
is met by this PR.
https://github.com/keycloak/keycloak/pull/4527

Hope this PR is reviewed and merged.

Best Regards
Takashi Norimatsu
Hitachi, Ltd.


From sthorger at redhat.com  Wed Oct  4 02:49:29 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 4 Oct 2017 08:49:29 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
	<CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
	<CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>
Message-ID: <CAJgngAed7LhRMRzRZMGaReuZVb_D1qzdyoiXft9vBSAvjqse2g@mail.gmail.com>

That doesn't answer my question really.

Let's assume a user doesn't change anything or use system properties. In
that case "authorization" would be disabled by default in 7.2. Then in 7.3
it should be supported and made enabled by default. How would you do that?

If you do it with migration scripts to enable it you don't know if the user
has actively decided to disable it or not.

So you either left with the option to require users to manually change it
(not an option) or you simply have to override what the user has set.

No on the other hand if you have -preview to the name you can remove
"authorization-preview" and add the new "authorization". In this case
you're making it explicit to the user that something has changed, so I
think this approach is better rather than just doing it without the users
knowledge.

On 3 October 2017 at 17:12, Marko Strukelj <mstrukel at redhat.com> wrote:

> I guess changing enabled status of features is a requirement, so feature
> would become enabled after transition to supported. There would still be
> different enabled statuses for community and product. It would just not be
> reflected in feature's name.
>
> If we just use -Dfeature.authorization=true / false (no -preview suffix)
> while feature has preview status, then if user is oblivious of the setting
> and doesn't use it to override defaults, enabling the feature by default
> will have effect.
>
> But if user wants to make sure feature doesn't get enabled (both while
> it's preview, and for the future when it's stable) then
> -Dfeature.authorization=false can be set, and now when newer version of
> community or product is used this setting will have effect - it will not
> become deprecated, it will just work like it worked when the feature had
> preview status.
>
> All we have to figure out is how best to have users aware that some
> feature has preview status since it would not be part of feature's name any
> more.
>
> We will want to document it in the docs - point out preview features in
> features.adoc, and changes in enabled status in changes.adoc.
> And we can log a warning during startup when features with preview status
> are enabled. I already list the disabled features, so it's clear what
> functionalities of the server are not available.
>
> I don't know about finegrained permitions Bill has mentioned. The list of
> features currently is: authorization-preview, impersonation,
> scripts-preview, docker, account2-preview, token-exchange
>
> (the last two have been added recently - I took the liberty to give
> account2 preview status - maybe it should not have it, and maybe
> token-exchange should have it?)
>
> So, I don't know where fine grained permissions come to play here - I
> would assume it simply means that if someone enables token-exchange that
> also requires authorization in order to take effect. And we can make that
> check, and either display warnings that feature can't take effect or
> automatically enable the dependency feature.
>
> But my proposal is essentially just to not name features with '-preview'
> at all while still knowing for each feature if it has preview status, so we
> can display warnings when it's enabled.
>
>
> On Tue, Oct 3, 2017 at 1:36 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> In what you are proposing what happens when a feature goes from tech
>> preview to supported? It would still be disabled by default right?
>>
>> On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>>
>>> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>
>>> Having '-preview' in the name clearly communicates the fact that it's a
>>> tech preview feature. When it is made fully supported it should be enabled
>>> out of the box by default. If we don't do this then users that haven't
>>> enabled the feature when it was tech preview won't have it enabled when
>>> it's fully supported. Alternatively, if you automatically change it from
>>> disabled to enabled when it's moved from tech preview you don't know if
>>> users actually had chosen to disable it or if that was just the default. In
>>> either case I think it's cleaner and safer to rename, because the feature
>>> does indeed change from preview to supported.
>>>
>>>
>>> The case you point out with feature not getting disabled ...
>>>
>>> Consider the case where user disables a preview feature with
>>> -Dfeature.authorization-preview=false. It's a no-op for product, but
>>> not for community distro. When we upgrade feature to stable user will get a
>>> warning for an unknown feature, and the old config will not turn off the
>>> feature any more - on product as well. So did we solve anything?
>>>
>>> Do we want -Dfeature.authorization-preview=false to keep having effect
>>> even after it's not called feature.authorization-preview any more? That's
>>> what I call backwards compatibility. Will it remain in place forever or we
>>> give ourself extra work not only adding it in the first place, but also
>>> removing it at some point?
>>>
>>> My point is that '-preview' adds complexity to maintain, may introduce
>>> extra bugs, JIRAs, will require extra documentation ... so what it brings
>>> to the table should outweigh the burden. Maybe there is another way to
>>> achieve obviousness of the fact that some feature is 'preview' without
>>> actually naming the feature, and all config options as such.
>>>
>>>
>>>
>>> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>>> The more I look at the idea of having '-preview' in feature names the
>>>> more I think it will cause more trouble than it's worth.
>>>>
>>>> The reason is it complicates migration when we promote feature to
>>>> stable - dropping '-preview' from its name, and it causes configuration
>>>> names to be fluid over time.
>>>>
>>>> For example, consider how moving authorization from preview to stable
>>>> would look for a user.
>>>>
>>>> User got used to using -Dfeature.authorization-preview=true
>>>>
>>>> Now we change this setting to be called -Dfeature.authorization=true.
>>>> User still using -Dfeature.authorization-preview=true, will get a
>>>> warning upon startup: 'Unknown feature system property:
>>>> feature.authorization-preview', and the system property will have no
>>>> effect. If user uses Keycloak distribution then authorization-preview will
>>>> be enabled by default. So no need to explicitly enable it - a no-op
>>>> operation in the first place, and a no-op operation at upgrade. If user
>>>> sets the property to false, then after upgrade the feature will suddenly be
>>>> enabled when before it was not.
>>>>
>>>> It doesn't seem right to drop configuration like that. If we want old
>>>> config to keep working then every migration from preview to stable also has
>>>> to add backwards compatibility logic, so that surprises like this don't
>>>> happen. Also all documentation needs to be changed wherever the feature
>>>> name is referenced.
>>>>
>>>> Whenever we promote any feature from '-preview' to stable this will be
>>>> needed, and it may become standard ritual that may to most users seem
>>>> completely redundant. Why not just call it -Dfeature.authorization in the
>>>> first place, and maybe just display a warning if any 'preview' feature is
>>>> enabled, something like:
>>>>
>>>> [WARN] The following preview features are enabled: ...
>>>>
>>>> WDYT?
>>>>
>>>>
>>>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> In standalone.xml I'd use "feature.scripts" sys properties instead of
>>>>> the longer "keycloak.feature.scripts". It's just shorter and simpler
>>>>> and won't cause any conflicts.
>>>>>
>>>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>>>> as is, including if set in profile.properties. This is important in
>>>>> case customers have explicitly disabled impersonation for example. +1 To
>>>>> printing a warning in this case. Then let's remove the old deprecated
>>>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>>>
>>>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> This is a heads up about an upcoming change in how to enable or
>>>>>> disable
>>>>>> features in Keycloak.
>>>>>>
>>>>>> Keycloak has a notion of features, which makes it possible to disable
>>>>>> certain functionality that is enabled by default, or enable certain
>>>>>> functionality that is disabled by default.
>>>>>>
>>>>>> There are four sets of functionality you can enable or disable as
>>>>>> features:
>>>>>> impersonation, script,  authorization, and docker. See [1] for more
>>>>>> info.
>>>>>>
>>>>>> Currently a file called profile.properties can be used to enable /
>>>>>> disable
>>>>>> features, or system properties can be used, which override any
>>>>>> configuration inside profile.properties as explained in [1].
>>>>>>
>>>>>> This is an aberration from how other configuration is specified on the
>>>>>> server via standalone.xml.
>>>>>>
>>>>>> Also, the reason config file is called profile.properties, and not
>>>>>> features.properties is because the set of enabled/disabled features is
>>>>>> different for upstream project (where all but 'docker' are enabled),
>>>>>> for
>>>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>>>> enabled),
>>>>>> and for technology preview versions of RHSSO.
>>>>>>
>>>>>> This additionally complicates things. The idea is to simplify that and
>>>>>> remove the notion of profiles, stop using profile.properties, and
>>>>>> move all
>>>>>> configuration to standalone.xml where all the available features will
>>>>>> be
>>>>>> listed with default values:
>>>>>>
>>>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>   <features>
>>>>>>     <feature name="authorization" enabled="true" />
>>>>>>     <feature name="impersonation" enabled="true" />
>>>>>>     <feature name="scripts" enabled="true" />
>>>>>>     <feature name="docker" enabled="false" />
>>>>>>   </features>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> </subsystem>
>>>>>>
>>>>>> This is how configuration would look like in Keycloak distribution. In
>>>>>> product distributions different features would be enabled / disabled
>>>>>> - no
>>>>>> more named profiles.
>>>>>>
>>>>>> However, in order to allow system properties override the idea is to
>>>>>> do it
>>>>>> slightly differently:
>>>>>>
>>>>>>   <features>
>>>>>>     <feature name="authorization"
>>>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>>>     <feature name="impersonation"
>>>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>>>> />
>>>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>>>> />
>>>>>>   </features>
>>>>>>
>>>>>>
>>>>>> We should probably also facilitate transition for current
>>>>>> deployments, and
>>>>>> take old style system properties into account if they are used -
>>>>>> converting
>>>>>> them to the new ones before configuration is applied.
>>>>>>
>>>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>>>
>>>>>> We don't want to keep support for this indefinitely (maybe for one
>>>>>> minor
>>>>>> version?) so if use of deprecated system properties is detected a
>>>>>> warning
>>>>>> will be logged.
>>>>>>
>>>>>> Also, Stian proposed that features not considered stable yet, should
>>>>>> carry
>>>>>> a suffix '-preview' in the name. So the actual feature name, and
>>>>>> system
>>>>>> property name may still change for some features.
>>>>>>
>>>>>> You can follow progress on JIRA issue [2].
>>>>>>
>>>>>> -
>>>>>>
>>>>>> [1]
>>>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>>>> on/topics/profiles.html
>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>>>> _______________________________________________
>>>>>> 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  4 03:42:42 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 4 Oct 2017 09:42:42 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CAJgngAed7LhRMRzRZMGaReuZVb_D1qzdyoiXft9vBSAvjqse2g@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
	<CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
	<CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>
	<CAJgngAed7LhRMRzRZMGaReuZVb_D1qzdyoiXft9vBSAvjqse2g@mail.gmail.com>
Message-ID: <CA+1OW+iodiwHh_bg4o0Ozz+aUfnwVZfGTtnyAsracu5OJgBuVQ@mail.gmail.com>

Migration scripts use conditional logic - which currently doesn't remove
existing configuration for a specific feature if already present.

Once configuration for a feature is in a standalone.xml you have two
choices during script upgrade:
  a) you can remove the old configuration and write in the new one - with
the new default.
  b) you don't touch the configuration at all - maybe user made changes,
and now you will delete their changes - you probably don't want that unless
policy is - don't make any changes to keycloak-subsystem.

I prefer to have policy b) in place, but then you can't automatically
enable a previously disabled-by-default feature in this case like you point
out.
If user changed the configuration - maybe removing system property and
hardcoding enabled="false" to make sure it doesn't get enabled, then using
option a) we would automatically enable the feature overwriting user's
change - and we may get an angry user.

We could probably have an option c) only automatically enable the feature
if current configuration is exactly as we shipped it - for example value of
'enabled' attribute exactly equal to "${feature.authorization:false}".

We can output some text during script execution that some feature is now
enabled, or that some other feature configuration wasn't migrated because
it appears to be changed: 'Feature 'authorization' is now supported. Its
configuration appears to be changed so it won't be migrated automatically.'

We can also notify user during migrate script of every preview feature
added - 'Feature 'authorization' has preview status and will be disabled by
default. Use -Dfeature.authorization=true when running the server to enable
it.'

Or when upgrading to mature with successful automatic migration: 'Feature
'authorization' is now supported and is enabled by default. Use
-Dfeature.authorization=false when running the server to disable it.'

That will make .cli script files bigger but should make for a good user
experience. I need to make sure that it can be done with .cli scripts in
the first place.


On Wed, Oct 4, 2017 at 8:49 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> That doesn't answer my question really.
>
> Let's assume a user doesn't change anything or use system properties. In
> that case "authorization" would be disabled by default in 7.2. Then in 7.3
> it should be supported and made enabled by default. How would you do that?
>
> If you do it with migration scripts to enable it you don't know if the
> user has actively decided to disable it or not.
>
> So you either left with the option to require users to manually change it
> (not an option) or you simply have to override what the user has set.
>
> No on the other hand if you have -preview to the name you can remove
> "authorization-preview" and add the new "authorization". In this case
> you're making it explicit to the user that something has changed, so I
> think this approach is better rather than just doing it without the users
> knowledge.
>
> On 3 October 2017 at 17:12, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> I guess changing enabled status of features is a requirement, so feature
>> would become enabled after transition to supported. There would still be
>> different enabled statuses for community and product. It would just not be
>> reflected in feature's name.
>>
>> If we just use -Dfeature.authorization=true / false (no -preview suffix)
>> while feature has preview status, then if user is oblivious of the setting
>> and doesn't use it to override defaults, enabling the feature by default
>> will have effect.
>>
>> But if user wants to make sure feature doesn't get enabled (both while
>> it's preview, and for the future when it's stable) then
>> -Dfeature.authorization=false can be set, and now when newer version of
>> community or product is used this setting will have effect - it will not
>> become deprecated, it will just work like it worked when the feature had
>> preview status.
>>
>> All we have to figure out is how best to have users aware that some
>> feature has preview status since it would not be part of feature's name any
>> more.
>>
>> We will want to document it in the docs - point out preview features in
>> features.adoc, and changes in enabled status in changes.adoc.
>> And we can log a warning during startup when features with preview status
>> are enabled. I already list the disabled features, so it's clear what
>> functionalities of the server are not available.
>>
>> I don't know about finegrained permitions Bill has mentioned. The list of
>> features currently is: authorization-preview, impersonation,
>> scripts-preview, docker, account2-preview, token-exchange
>>
>> (the last two have been added recently - I took the liberty to give
>> account2 preview status - maybe it should not have it, and maybe
>> token-exchange should have it?)
>>
>> So, I don't know where fine grained permissions come to play here - I
>> would assume it simply means that if someone enables token-exchange that
>> also requires authorization in order to take effect. And we can make that
>> check, and either display warnings that feature can't take effect or
>> automatically enable the dependency feature.
>>
>> But my proposal is essentially just to not name features with '-preview'
>> at all while still knowing for each feature if it has preview status, so we
>> can display warnings when it's enabled.
>>
>>
>> On Tue, Oct 3, 2017 at 1:36 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> In what you are proposing what happens when a feature goes from tech
>>> preview to supported? It would still be disabled by default right?
>>>
>>> On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>>>
>>>> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>>
>>>> Having '-preview' in the name clearly communicates the fact that it's a
>>>> tech preview feature. When it is made fully supported it should be enabled
>>>> out of the box by default. If we don't do this then users that haven't
>>>> enabled the feature when it was tech preview won't have it enabled when
>>>> it's fully supported. Alternatively, if you automatically change it from
>>>> disabled to enabled when it's moved from tech preview you don't know if
>>>> users actually had chosen to disable it or if that was just the default. In
>>>> either case I think it's cleaner and safer to rename, because the feature
>>>> does indeed change from preview to supported.
>>>>
>>>>
>>>> The case you point out with feature not getting disabled ...
>>>>
>>>> Consider the case where user disables a preview feature with
>>>> -Dfeature.authorization-preview=false. It's a no-op for product, but
>>>> not for community distro. When we upgrade feature to stable user will get a
>>>> warning for an unknown feature, and the old config will not turn off the
>>>> feature any more - on product as well. So did we solve anything?
>>>>
>>>> Do we want -Dfeature.authorization-preview=false to keep having effect
>>>> even after it's not called feature.authorization-preview any more? That's
>>>> what I call backwards compatibility. Will it remain in place forever or we
>>>> give ourself extra work not only adding it in the first place, but also
>>>> removing it at some point?
>>>>
>>>> My point is that '-preview' adds complexity to maintain, may introduce
>>>> extra bugs, JIRAs, will require extra documentation ... so what it brings
>>>> to the table should outweigh the burden. Maybe there is another way to
>>>> achieve obviousness of the fact that some feature is 'preview' without
>>>> actually naming the feature, and all config options as such.
>>>>
>>>>
>>>>
>>>> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>>
>>>>> The more I look at the idea of having '-preview' in feature names the
>>>>> more I think it will cause more trouble than it's worth.
>>>>>
>>>>> The reason is it complicates migration when we promote feature to
>>>>> stable - dropping '-preview' from its name, and it causes configuration
>>>>> names to be fluid over time.
>>>>>
>>>>> For example, consider how moving authorization from preview to stable
>>>>> would look for a user.
>>>>>
>>>>> User got used to using -Dfeature.authorization-preview=true
>>>>>
>>>>> Now we change this setting to be called -Dfeature.authorization=true.
>>>>> User still using -Dfeature.authorization-preview=true, will get a
>>>>> warning upon startup: 'Unknown feature system property:
>>>>> feature.authorization-preview', and the system property will have no
>>>>> effect. If user uses Keycloak distribution then authorization-preview will
>>>>> be enabled by default. So no need to explicitly enable it - a no-op
>>>>> operation in the first place, and a no-op operation at upgrade. If user
>>>>> sets the property to false, then after upgrade the feature will suddenly be
>>>>> enabled when before it was not.
>>>>>
>>>>> It doesn't seem right to drop configuration like that. If we want old
>>>>> config to keep working then every migration from preview to stable also has
>>>>> to add backwards compatibility logic, so that surprises like this don't
>>>>> happen. Also all documentation needs to be changed wherever the feature
>>>>> name is referenced.
>>>>>
>>>>> Whenever we promote any feature from '-preview' to stable this will be
>>>>> needed, and it may become standard ritual that may to most users seem
>>>>> completely redundant. Why not just call it -Dfeature.authorization in the
>>>>> first place, and maybe just display a warning if any 'preview' feature is
>>>>> enabled, something like:
>>>>>
>>>>> [WARN] The following preview features are enabled: ...
>>>>>
>>>>> WDYT?
>>>>>
>>>>>
>>>>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <sthorger at redhat.com
>>>>> > wrote:
>>>>>
>>>>>> In standalone.xml I'd use "feature.scripts" sys properties instead
>>>>>> of the longer "keycloak.feature.scripts". It's just shorter and
>>>>>> simpler and won't cause any conflicts.
>>>>>>
>>>>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>>>>> as is, including if set in profile.properties. This is important in
>>>>>> case customers have explicitly disabled impersonation for example. +1 To
>>>>>> printing a warning in this case. Then let's remove the old deprecated
>>>>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>>>>
>>>>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> This is a heads up about an upcoming change in how to enable or
>>>>>>> disable
>>>>>>> features in Keycloak.
>>>>>>>
>>>>>>> Keycloak has a notion of features, which makes it possible to disable
>>>>>>> certain functionality that is enabled by default, or enable certain
>>>>>>> functionality that is disabled by default.
>>>>>>>
>>>>>>> There are four sets of functionality you can enable or disable as
>>>>>>> features:
>>>>>>> impersonation, script,  authorization, and docker. See [1] for more
>>>>>>> info.
>>>>>>>
>>>>>>> Currently a file called profile.properties can be used to enable /
>>>>>>> disable
>>>>>>> features, or system properties can be used, which override any
>>>>>>> configuration inside profile.properties as explained in [1].
>>>>>>>
>>>>>>> This is an aberration from how other configuration is specified on
>>>>>>> the
>>>>>>> server via standalone.xml.
>>>>>>>
>>>>>>> Also, the reason config file is called profile.properties, and not
>>>>>>> features.properties is because the set of enabled/disabled features
>>>>>>> is
>>>>>>> different for upstream project (where all but 'docker' are enabled),
>>>>>>> for
>>>>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>>>>> enabled),
>>>>>>> and for technology preview versions of RHSSO.
>>>>>>>
>>>>>>> This additionally complicates things. The idea is to simplify that
>>>>>>> and
>>>>>>> remove the notion of profiles, stop using profile.properties, and
>>>>>>> move all
>>>>>>> configuration to standalone.xml where all the available features
>>>>>>> will be
>>>>>>> listed with default values:
>>>>>>>
>>>>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>   <features>
>>>>>>>     <feature name="authorization" enabled="true" />
>>>>>>>     <feature name="impersonation" enabled="true" />
>>>>>>>     <feature name="scripts" enabled="true" />
>>>>>>>     <feature name="docker" enabled="false" />
>>>>>>>   </features>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> </subsystem>
>>>>>>>
>>>>>>> This is how configuration would look like in Keycloak distribution.
>>>>>>> In
>>>>>>> product distributions different features would be enabled / disabled
>>>>>>> - no
>>>>>>> more named profiles.
>>>>>>>
>>>>>>> However, in order to allow system properties override the idea is to
>>>>>>> do it
>>>>>>> slightly differently:
>>>>>>>
>>>>>>>   <features>
>>>>>>>     <feature name="authorization"
>>>>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>>>>     <feature name="impersonation"
>>>>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>>>>> />
>>>>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>>>>> />
>>>>>>>   </features>
>>>>>>>
>>>>>>>
>>>>>>> We should probably also facilitate transition for current
>>>>>>> deployments, and
>>>>>>> take old style system properties into account if they are used -
>>>>>>> converting
>>>>>>> them to the new ones before configuration is applied.
>>>>>>>
>>>>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>>>>
>>>>>>> We don't want to keep support for this indefinitely (maybe for one
>>>>>>> minor
>>>>>>> version?) so if use of deprecated system properties is detected a
>>>>>>> warning
>>>>>>> will be logged.
>>>>>>>
>>>>>>> Also, Stian proposed that features not considered stable yet, should
>>>>>>> carry
>>>>>>> a suffix '-preview' in the name. So the actual feature name, and
>>>>>>> system
>>>>>>> property name may still change for some features.
>>>>>>>
>>>>>>> You can follow progress on JIRA issue [2].
>>>>>>>
>>>>>>> -
>>>>>>>
>>>>>>> [1]
>>>>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>>>>> on/topics/profiles.html
>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>>>>> _______________________________________________
>>>>>>> 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  4 05:54:04 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 4 Oct 2017 11:54:04 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CA+1OW+iodiwHh_bg4o0Ozz+aUfnwVZfGTtnyAsracu5OJgBuVQ@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
	<CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
	<CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>
	<CAJgngAed7LhRMRzRZMGaReuZVb_D1qzdyoiXft9vBSAvjqse2g@mail.gmail.com>
	<CA+1OW+iodiwHh_bg4o0Ozz+aUfnwVZfGTtnyAsracu5OJgBuVQ@mail.gmail.com>
Message-ID: <CAJgngAcpe_-qcH5YHbBcBeaZS9BS0ESVV_meCTajDYdLaLmWKA@mail.gmail.com>

This all sounds messy and complicated compared to just having it called
authorization-preview and renamed to authorization.

On 4 October 2017 at 09:42, Marko Strukelj <mstrukel at redhat.com> wrote:

> Migration scripts use conditional logic - which currently doesn't remove
> existing configuration for a specific feature if already present.
>
> Once configuration for a feature is in a standalone.xml you have two
> choices during script upgrade:
>   a) you can remove the old configuration and write in the new one - with
> the new default.
>   b) you don't touch the configuration at all - maybe user made changes,
> and now you will delete their changes - you probably don't want that unless
> policy is - don't make any changes to keycloak-subsystem.
>
> I prefer to have policy b) in place, but then you can't automatically
> enable a previously disabled-by-default feature in this case like you point
> out.
> If user changed the configuration - maybe removing system property and
> hardcoding enabled="false" to make sure it doesn't get enabled, then using
> option a) we would automatically enable the feature overwriting user's
> change - and we may get an angry user.
>
> We could probably have an option c) only automatically enable the feature
> if current configuration is exactly as we shipped it - for example value of
> 'enabled' attribute exactly equal to "${feature.authorization:false}".
>
> We can output some text during script execution that some feature is now
> enabled, or that some other feature configuration wasn't migrated because
> it appears to be changed: 'Feature 'authorization' is now supported. Its
> configuration appears to be changed so it won't be migrated automatically.'
>
> We can also notify user during migrate script of every preview feature
> added - 'Feature 'authorization' has preview status and will be disabled by
> default. Use -Dfeature.authorization=true when running the server to enable
> it.'
>
> Or when upgrading to mature with successful automatic migration: 'Feature
> 'authorization' is now supported and is enabled by default. Use
> -Dfeature.authorization=false when running the server to disable it.'
>
> That will make .cli script files bigger but should make for a good user
> experience. I need to make sure that it can be done with .cli scripts in
> the first place.
>
>
> On Wed, Oct 4, 2017 at 8:49 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> That doesn't answer my question really.
>>
>> Let's assume a user doesn't change anything or use system properties. In
>> that case "authorization" would be disabled by default in 7.2. Then in 7.3
>> it should be supported and made enabled by default. How would you do that?
>>
>> If you do it with migration scripts to enable it you don't know if the
>> user has actively decided to disable it or not.
>>
>> So you either left with the option to require users to manually change it
>> (not an option) or you simply have to override what the user has set.
>>
>> No on the other hand if you have -preview to the name you can remove
>> "authorization-preview" and add the new "authorization". In this case
>> you're making it explicit to the user that something has changed, so I
>> think this approach is better rather than just doing it without the users
>> knowledge.
>>
>> On 3 October 2017 at 17:12, Marko Strukelj <mstrukel at redhat.com> wrote:
>>
>>> I guess changing enabled status of features is a requirement, so feature
>>> would become enabled after transition to supported. There would still be
>>> different enabled statuses for community and product. It would just not be
>>> reflected in feature's name.
>>>
>>> If we just use -Dfeature.authorization=true / false (no -preview suffix)
>>> while feature has preview status, then if user is oblivious of the setting
>>> and doesn't use it to override defaults, enabling the feature by default
>>> will have effect.
>>>
>>> But if user wants to make sure feature doesn't get enabled (both while
>>> it's preview, and for the future when it's stable) then
>>> -Dfeature.authorization=false can be set, and now when newer version of
>>> community or product is used this setting will have effect - it will not
>>> become deprecated, it will just work like it worked when the feature had
>>> preview status.
>>>
>>> All we have to figure out is how best to have users aware that some
>>> feature has preview status since it would not be part of feature's name any
>>> more.
>>>
>>> We will want to document it in the docs - point out preview features in
>>> features.adoc, and changes in enabled status in changes.adoc.
>>> And we can log a warning during startup when features with preview
>>> status are enabled. I already list the disabled features, so it's clear
>>> what functionalities of the server are not available.
>>>
>>> I don't know about finegrained permitions Bill has mentioned. The list
>>> of features currently is: authorization-preview, impersonation,
>>> scripts-preview, docker, account2-preview, token-exchange
>>>
>>> (the last two have been added recently - I took the liberty to give
>>> account2 preview status - maybe it should not have it, and maybe
>>> token-exchange should have it?)
>>>
>>> So, I don't know where fine grained permissions come to play here - I
>>> would assume it simply means that if someone enables token-exchange that
>>> also requires authorization in order to take effect. And we can make that
>>> check, and either display warnings that feature can't take effect or
>>> automatically enable the dependency feature.
>>>
>>> But my proposal is essentially just to not name features with '-preview'
>>> at all while still knowing for each feature if it has preview status, so we
>>> can display warnings when it's enabled.
>>>
>>>
>>> On Tue, Oct 3, 2017 at 1:36 PM, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> In what you are proposing what happens when a feature goes from tech
>>>> preview to supported? It would still be disabled by default right?
>>>>
>>>> On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>>
>>>>>
>>>>> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>>>
>>>>> Having '-preview' in the name clearly communicates the fact that it's
>>>>> a tech preview feature. When it is made fully supported it should be
>>>>> enabled out of the box by default. If we don't do this then users that
>>>>> haven't enabled the feature when it was tech preview won't have it enabled
>>>>> when it's fully supported. Alternatively, if you automatically change it
>>>>> from disabled to enabled when it's moved from tech preview you don't know
>>>>> if users actually had chosen to disable it or if that was just the default.
>>>>> In either case I think it's cleaner and safer to rename, because the
>>>>> feature does indeed change from preview to supported.
>>>>>
>>>>>
>>>>> The case you point out with feature not getting disabled ...
>>>>>
>>>>> Consider the case where user disables a preview feature with
>>>>> -Dfeature.authorization-preview=false. It's a no-op for product, but
>>>>> not for community distro. When we upgrade feature to stable user will get a
>>>>> warning for an unknown feature, and the old config will not turn off the
>>>>> feature any more - on product as well. So did we solve anything?
>>>>>
>>>>> Do we want -Dfeature.authorization-preview=false to keep having
>>>>> effect even after it's not called feature.authorization-preview any more?
>>>>> That's what I call backwards compatibility. Will it remain in place forever
>>>>> or we give ourself extra work not only adding it in the first place, but
>>>>> also removing it at some point?
>>>>>
>>>>> My point is that '-preview' adds complexity to maintain, may introduce
>>>>> extra bugs, JIRAs, will require extra documentation ... so what it brings
>>>>> to the table should outweigh the burden. Maybe there is another way to
>>>>> achieve obviousness of the fact that some feature is 'preview' without
>>>>> actually naming the feature, and all config options as such.
>>>>>
>>>>>
>>>>>
>>>>> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> The more I look at the idea of having '-preview' in feature names the
>>>>>> more I think it will cause more trouble than it's worth.
>>>>>>
>>>>>> The reason is it complicates migration when we promote feature to
>>>>>> stable - dropping '-preview' from its name, and it causes configuration
>>>>>> names to be fluid over time.
>>>>>>
>>>>>> For example, consider how moving authorization from preview to stable
>>>>>> would look for a user.
>>>>>>
>>>>>> User got used to using -Dfeature.authorization-preview=true
>>>>>>
>>>>>> Now we change this setting to be called -Dfeature.authorization=true.
>>>>>> User still using -Dfeature.authorization-preview=true, will get a
>>>>>> warning upon startup: 'Unknown feature system property:
>>>>>> feature.authorization-preview', and the system property will have no
>>>>>> effect. If user uses Keycloak distribution then authorization-preview will
>>>>>> be enabled by default. So no need to explicitly enable it - a no-op
>>>>>> operation in the first place, and a no-op operation at upgrade. If user
>>>>>> sets the property to false, then after upgrade the feature will suddenly be
>>>>>> enabled when before it was not.
>>>>>>
>>>>>> It doesn't seem right to drop configuration like that. If we want old
>>>>>> config to keep working then every migration from preview to stable also has
>>>>>> to add backwards compatibility logic, so that surprises like this don't
>>>>>> happen. Also all documentation needs to be changed wherever the feature
>>>>>> name is referenced.
>>>>>>
>>>>>> Whenever we promote any feature from '-preview' to stable this will
>>>>>> be needed, and it may become standard ritual that may to most users seem
>>>>>> completely redundant. Why not just call it -Dfeature.authorization in the
>>>>>> first place, and maybe just display a warning if any 'preview' feature is
>>>>>> enabled, something like:
>>>>>>
>>>>>> [WARN] The following preview features are enabled: ...
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>>
>>>>>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> In standalone.xml I'd use "feature.scripts" sys properties instead
>>>>>>> of the longer "keycloak.feature.scripts". It's just shorter and
>>>>>>> simpler and won't cause any conflicts.
>>>>>>>
>>>>>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>>>>>> as is, including if set in profile.properties. This is important in
>>>>>>> case customers have explicitly disabled impersonation for example. +1 To
>>>>>>> printing a warning in this case. Then let's remove the old deprecated
>>>>>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>>>>>
>>>>>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> This is a heads up about an upcoming change in how to enable or
>>>>>>>> disable
>>>>>>>> features in Keycloak.
>>>>>>>>
>>>>>>>> Keycloak has a notion of features, which makes it possible to
>>>>>>>> disable
>>>>>>>> certain functionality that is enabled by default, or enable certain
>>>>>>>> functionality that is disabled by default.
>>>>>>>>
>>>>>>>> There are four sets of functionality you can enable or disable as
>>>>>>>> features:
>>>>>>>> impersonation, script,  authorization, and docker. See [1] for more
>>>>>>>> info.
>>>>>>>>
>>>>>>>> Currently a file called profile.properties can be used to enable /
>>>>>>>> disable
>>>>>>>> features, or system properties can be used, which override any
>>>>>>>> configuration inside profile.properties as explained in [1].
>>>>>>>>
>>>>>>>> This is an aberration from how other configuration is specified on
>>>>>>>> the
>>>>>>>> server via standalone.xml.
>>>>>>>>
>>>>>>>> Also, the reason config file is called profile.properties, and not
>>>>>>>> features.properties is because the set of enabled/disabled features
>>>>>>>> is
>>>>>>>> different for upstream project (where all but 'docker' are
>>>>>>>> enabled), for
>>>>>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>>>>>> enabled),
>>>>>>>> and for technology preview versions of RHSSO.
>>>>>>>>
>>>>>>>> This additionally complicates things. The idea is to simplify that
>>>>>>>> and
>>>>>>>> remove the notion of profiles, stop using profile.properties, and
>>>>>>>> move all
>>>>>>>> configuration to standalone.xml where all the available features
>>>>>>>> will be
>>>>>>>> listed with default values:
>>>>>>>>
>>>>>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>   <features>
>>>>>>>>     <feature name="authorization" enabled="true" />
>>>>>>>>     <feature name="impersonation" enabled="true" />
>>>>>>>>     <feature name="scripts" enabled="true" />
>>>>>>>>     <feature name="docker" enabled="false" />
>>>>>>>>   </features>
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> </subsystem>
>>>>>>>>
>>>>>>>> This is how configuration would look like in Keycloak distribution.
>>>>>>>> In
>>>>>>>> product distributions different features would be enabled /
>>>>>>>> disabled - no
>>>>>>>> more named profiles.
>>>>>>>>
>>>>>>>> However, in order to allow system properties override the idea is
>>>>>>>> to do it
>>>>>>>> slightly differently:
>>>>>>>>
>>>>>>>>   <features>
>>>>>>>>     <feature name="authorization"
>>>>>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>>>>>     <feature name="impersonation"
>>>>>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>>>>>> />
>>>>>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>>>>>> />
>>>>>>>>   </features>
>>>>>>>>
>>>>>>>>
>>>>>>>> We should probably also facilitate transition for current
>>>>>>>> deployments, and
>>>>>>>> take old style system properties into account if they are used -
>>>>>>>> converting
>>>>>>>> them to the new ones before configuration is applied.
>>>>>>>>
>>>>>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>>>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>>>>>
>>>>>>>> We don't want to keep support for this indefinitely (maybe for one
>>>>>>>> minor
>>>>>>>> version?) so if use of deprecated system properties is detected a
>>>>>>>> warning
>>>>>>>> will be logged.
>>>>>>>>
>>>>>>>> Also, Stian proposed that features not considered stable yet,
>>>>>>>> should carry
>>>>>>>> a suffix '-preview' in the name. So the actual feature name, and
>>>>>>>> system
>>>>>>>> property name may still change for some features.
>>>>>>>>
>>>>>>>> You can follow progress on JIRA issue [2].
>>>>>>>>
>>>>>>>> -
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>>>>>> on/topics/profiles.html
>>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>>>>>> _______________________________________________
>>>>>>>> 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  4 05:54:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 4 Oct 2017 11:54:30 +0200
Subject: [keycloak-dev] Change in enabling / disabling features
In-Reply-To: <CAJgngAcpe_-qcH5YHbBcBeaZS9BS0ESVV_meCTajDYdLaLmWKA@mail.gmail.com>
References: <CA+1OW+gU5_vC6ZcfRv9c=Bvqn5jWAim2XWFTYeDaSFM=C6kWeA@mail.gmail.com>
	<CAJgngAfDFZnpPW2T6qHpFp++BdrOWcJMPoD8nw-2VDn7AA1A7g@mail.gmail.com>
	<CA+1OW+jHCsXohVRdrZLTnmMUbas1vaP4GMjuN-nW6abqE=cKPg@mail.gmail.com>
	<CAJgngAdskgvXOCk25Dqo5mk9RKreKtNZZ9kG75zaH+mLdK6DiA@mail.gmail.com>
	<CA+1OW+ht0SuGJX-YDGq+Bja41_YibsZcnCU5TScABfom_4NJVw@mail.gmail.com>
	<CAJgngAeLT4efH9kZ97uKjWm-GdvT_XP-M8vGDsX10W-ZvHGUeQ@mail.gmail.com>
	<CA+1OW+hoxPs84dOBR5sMyZEJwXFdHPmSm4J4XbYn0b5C_QyzGg@mail.gmail.com>
	<CAJgngAed7LhRMRzRZMGaReuZVb_D1qzdyoiXft9vBSAvjqse2g@mail.gmail.com>
	<CA+1OW+iodiwHh_bg4o0Ozz+aUfnwVZfGTtnyAsracu5OJgBuVQ@mail.gmail.com>
	<CAJgngAcpe_-qcH5YHbBcBeaZS9BS0ESVV_meCTajDYdLaLmWKA@mail.gmail.com>
Message-ID: <CAJgngAckSs2pphiTTidz+yq771hQia=C4L4tnXiDz8=ESSE1SQ@mail.gmail.com>

As we're getting close to feature freeze and still have open discussions on
how this should be resolved I'd like to hold off on this work until after
7.2 is out.

On 4 October 2017 at 11:54, Stian Thorgersen <sthorger at redhat.com> wrote:

> This all sounds messy and complicated compared to just having it called
> authorization-preview and renamed to authorization.
>
> On 4 October 2017 at 09:42, Marko Strukelj <mstrukel at redhat.com> wrote:
>
>> Migration scripts use conditional logic - which currently doesn't remove
>> existing configuration for a specific feature if already present.
>>
>> Once configuration for a feature is in a standalone.xml you have two
>> choices during script upgrade:
>>   a) you can remove the old configuration and write in the new one - with
>> the new default.
>>   b) you don't touch the configuration at all - maybe user made changes,
>> and now you will delete their changes - you probably don't want that unless
>> policy is - don't make any changes to keycloak-subsystem.
>>
>> I prefer to have policy b) in place, but then you can't automatically
>> enable a previously disabled-by-default feature in this case like you point
>> out.
>> If user changed the configuration - maybe removing system property and
>> hardcoding enabled="false" to make sure it doesn't get enabled, then using
>> option a) we would automatically enable the feature overwriting user's
>> change - and we may get an angry user.
>>
>> We could probably have an option c) only automatically enable the feature
>> if current configuration is exactly as we shipped it - for example value of
>> 'enabled' attribute exactly equal to "${feature.authorization:false}".
>>
>> We can output some text during script execution that some feature is now
>> enabled, or that some other feature configuration wasn't migrated because
>> it appears to be changed: 'Feature 'authorization' is now supported. Its
>> configuration appears to be changed so it won't be migrated automatically.'
>>
>> We can also notify user during migrate script of every preview feature
>> added - 'Feature 'authorization' has preview status and will be disabled by
>> default. Use -Dfeature.authorization=true when running the server to enable
>> it.'
>>
>> Or when upgrading to mature with successful automatic migration: 'Feature
>> 'authorization' is now supported and is enabled by default. Use
>> -Dfeature.authorization=false when running the server to disable it.'
>>
>> That will make .cli script files bigger but should make for a good user
>> experience. I need to make sure that it can be done with .cli scripts in
>> the first place.
>>
>>
>> On Wed, Oct 4, 2017 at 8:49 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> That doesn't answer my question really.
>>>
>>> Let's assume a user doesn't change anything or use system properties. In
>>> that case "authorization" would be disabled by default in 7.2. Then in 7.3
>>> it should be supported and made enabled by default. How would you do that?
>>>
>>> If you do it with migration scripts to enable it you don't know if the
>>> user has actively decided to disable it or not.
>>>
>>> So you either left with the option to require users to manually change
>>> it (not an option) or you simply have to override what the user has set.
>>>
>>> No on the other hand if you have -preview to the name you can remove
>>> "authorization-preview" and add the new "authorization". In this case
>>> you're making it explicit to the user that something has changed, so I
>>> think this approach is better rather than just doing it without the users
>>> knowledge.
>>>
>>> On 3 October 2017 at 17:12, Marko Strukelj <mstrukel at redhat.com> wrote:
>>>
>>>> I guess changing enabled status of features is a requirement, so
>>>> feature would become enabled after transition to supported. There would
>>>> still be different enabled statuses for community and product. It would
>>>> just not be reflected in feature's name.
>>>>
>>>> If we just use -Dfeature.authorization=true / false (no -preview
>>>> suffix) while feature has preview status, then if user is oblivious of the
>>>> setting and doesn't use it to override defaults, enabling the feature by
>>>> default will have effect.
>>>>
>>>> But if user wants to make sure feature doesn't get enabled (both while
>>>> it's preview, and for the future when it's stable) then
>>>> -Dfeature.authorization=false can be set, and now when newer version of
>>>> community or product is used this setting will have effect - it will not
>>>> become deprecated, it will just work like it worked when the feature had
>>>> preview status.
>>>>
>>>> All we have to figure out is how best to have users aware that some
>>>> feature has preview status since it would not be part of feature's name any
>>>> more.
>>>>
>>>> We will want to document it in the docs - point out preview features in
>>>> features.adoc, and changes in enabled status in changes.adoc.
>>>> And we can log a warning during startup when features with preview
>>>> status are enabled. I already list the disabled features, so it's clear
>>>> what functionalities of the server are not available.
>>>>
>>>> I don't know about finegrained permitions Bill has mentioned. The list
>>>> of features currently is: authorization-preview, impersonation,
>>>> scripts-preview, docker, account2-preview, token-exchange
>>>>
>>>> (the last two have been added recently - I took the liberty to give
>>>> account2 preview status - maybe it should not have it, and maybe
>>>> token-exchange should have it?)
>>>>
>>>> So, I don't know where fine grained permissions come to play here - I
>>>> would assume it simply means that if someone enables token-exchange that
>>>> also requires authorization in order to take effect. And we can make that
>>>> check, and either display warnings that feature can't take effect or
>>>> automatically enable the dependency feature.
>>>>
>>>> But my proposal is essentially just to not name features with
>>>> '-preview' at all while still knowing for each feature if it has preview
>>>> status, so we can display warnings when it's enabled.
>>>>
>>>>
>>>> On Tue, Oct 3, 2017 at 1:36 PM, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>> In what you are proposing what happens when a feature goes from tech
>>>>> preview to supported? It would still be disabled by default right?
>>>>>
>>>>> On 3 October 2017 at 12:26, Marko Strukelj <mstrukel at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Oct 3, 2017 06:11, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>>>>>>
>>>>>> Having '-preview' in the name clearly communicates the fact that it's
>>>>>> a tech preview feature. When it is made fully supported it should be
>>>>>> enabled out of the box by default. If we don't do this then users that
>>>>>> haven't enabled the feature when it was tech preview won't have it enabled
>>>>>> when it's fully supported. Alternatively, if you automatically change it
>>>>>> from disabled to enabled when it's moved from tech preview you don't know
>>>>>> if users actually had chosen to disable it or if that was just the default.
>>>>>> In either case I think it's cleaner and safer to rename, because the
>>>>>> feature does indeed change from preview to supported.
>>>>>>
>>>>>>
>>>>>> The case you point out with feature not getting disabled ...
>>>>>>
>>>>>> Consider the case where user disables a preview feature with
>>>>>> -Dfeature.authorization-preview=false. It's a no-op for product, but
>>>>>> not for community distro. When we upgrade feature to stable user will get a
>>>>>> warning for an unknown feature, and the old config will not turn off the
>>>>>> feature any more - on product as well. So did we solve anything?
>>>>>>
>>>>>> Do we want -Dfeature.authorization-preview=false to keep having
>>>>>> effect even after it's not called feature.authorization-preview any more?
>>>>>> That's what I call backwards compatibility. Will it remain in place forever
>>>>>> or we give ourself extra work not only adding it in the first place, but
>>>>>> also removing it at some point?
>>>>>>
>>>>>> My point is that '-preview' adds complexity to maintain, may
>>>>>> introduce extra bugs, JIRAs, will require extra documentation ... so what
>>>>>> it brings to the table should outweigh the burden. Maybe there is another
>>>>>> way to achieve obviousness of the fact that some feature is 'preview'
>>>>>> without actually naming the feature, and all config options as such.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2 October 2017 at 15:37, Marko Strukelj <mstrukel at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> The more I look at the idea of having '-preview' in feature names
>>>>>>> the more I think it will cause more trouble than it's worth.
>>>>>>>
>>>>>>> The reason is it complicates migration when we promote feature to
>>>>>>> stable - dropping '-preview' from its name, and it causes configuration
>>>>>>> names to be fluid over time.
>>>>>>>
>>>>>>> For example, consider how moving authorization from preview to
>>>>>>> stable would look for a user.
>>>>>>>
>>>>>>> User got used to using -Dfeature.authorization-preview=true
>>>>>>>
>>>>>>> Now we change this setting to be called
>>>>>>> -Dfeature.authorization=true. User still using
>>>>>>> -Dfeature.authorization-preview=true, will get a warning upon
>>>>>>> startup: 'Unknown feature system property: feature.authorization-preview',
>>>>>>> and the system property will have no effect. If user uses Keycloak
>>>>>>> distribution then authorization-preview will be enabled by default. So no
>>>>>>> need to explicitly enable it - a no-op operation in the first place, and a
>>>>>>> no-op operation at upgrade. If user sets the property to false, then after
>>>>>>> upgrade the feature will suddenly be enabled when before it was not.
>>>>>>>
>>>>>>> It doesn't seem right to drop configuration like that. If we want
>>>>>>> old config to keep working then every migration from preview to stable also
>>>>>>> has to add backwards compatibility logic, so that surprises like this don't
>>>>>>> happen. Also all documentation needs to be changed wherever the feature
>>>>>>> name is referenced.
>>>>>>>
>>>>>>> Whenever we promote any feature from '-preview' to stable this will
>>>>>>> be needed, and it may become standard ritual that may to most users seem
>>>>>>> completely redundant. Why not just call it -Dfeature.authorization in the
>>>>>>> first place, and maybe just display a warning if any 'preview' feature is
>>>>>>> enabled, something like:
>>>>>>>
>>>>>>> [WARN] The following preview features are enabled: ...
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Aug 30, 2017 at 8:28 AM, Stian Thorgersen <
>>>>>>> sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>> In standalone.xml I'd use "feature.scripts" sys properties instead
>>>>>>>> of the longer "keycloak.feature.scripts". It's just shorter and
>>>>>>>> simpler and won't cause any conflicts.
>>>>>>>>
>>>>>>>> We need to support the old "keycloak.profile.feature.<featurename>=enabled|disabled"
>>>>>>>> as is, including if set in profile.properties. This is important
>>>>>>>> in case customers have explicitly disabled impersonation for example. +1 To
>>>>>>>> printing a warning in this case. Then let's remove the old deprecated
>>>>>>>> properties in Keycloak 3.5x as well as the profile.properties.
>>>>>>>>
>>>>>>>> On 28 August 2017 at 15:57, Marko Strukelj <mstrukel at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This is a heads up about an upcoming change in how to enable or
>>>>>>>>> disable
>>>>>>>>> features in Keycloak.
>>>>>>>>>
>>>>>>>>> Keycloak has a notion of features, which makes it possible to
>>>>>>>>> disable
>>>>>>>>> certain functionality that is enabled by default, or enable certain
>>>>>>>>> functionality that is disabled by default.
>>>>>>>>>
>>>>>>>>> There are four sets of functionality you can enable or disable as
>>>>>>>>> features:
>>>>>>>>> impersonation, script,  authorization, and docker. See [1] for
>>>>>>>>> more info.
>>>>>>>>>
>>>>>>>>> Currently a file called profile.properties can be used to enable /
>>>>>>>>> disable
>>>>>>>>> features, or system properties can be used, which override any
>>>>>>>>> configuration inside profile.properties as explained in [1].
>>>>>>>>>
>>>>>>>>> This is an aberration from how other configuration is specified on
>>>>>>>>> the
>>>>>>>>> server via standalone.xml.
>>>>>>>>>
>>>>>>>>> Also, the reason config file is called profile.properties, and not
>>>>>>>>> features.properties is because the set of enabled/disabled
>>>>>>>>> features is
>>>>>>>>> different for upstream project (where all but 'docker' are
>>>>>>>>> enabled), for
>>>>>>>>> product based on Keycloak - RHSSO (where only 'impersonation' is
>>>>>>>>> enabled),
>>>>>>>>> and for technology preview versions of RHSSO.
>>>>>>>>>
>>>>>>>>> This additionally complicates things. The idea is to simplify that
>>>>>>>>> and
>>>>>>>>> remove the notion of profiles, stop using profile.properties, and
>>>>>>>>> move all
>>>>>>>>> configuration to standalone.xml where all the available features
>>>>>>>>> will be
>>>>>>>>> listed with default values:
>>>>>>>>>
>>>>>>>>> <subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>   <features>
>>>>>>>>>     <feature name="authorization" enabled="true" />
>>>>>>>>>     <feature name="impersonation" enabled="true" />
>>>>>>>>>     <feature name="scripts" enabled="true" />
>>>>>>>>>     <feature name="docker" enabled="false" />
>>>>>>>>>   </features>
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> </subsystem>
>>>>>>>>>
>>>>>>>>> This is how configuration would look like in Keycloak
>>>>>>>>> distribution. In
>>>>>>>>> product distributions different features would be enabled /
>>>>>>>>> disabled - no
>>>>>>>>> more named profiles.
>>>>>>>>>
>>>>>>>>> However, in order to allow system properties override the idea is
>>>>>>>>> to do it
>>>>>>>>> slightly differently:
>>>>>>>>>
>>>>>>>>>   <features>
>>>>>>>>>     <feature name="authorization"
>>>>>>>>> enabled="${keycloak.feature.authorization:true}" />
>>>>>>>>>     <feature name="impersonation"
>>>>>>>>> enabled="${keycloak.feature.impersonation:true}" />
>>>>>>>>>     <feature name="scripts" enabled="${keycloak.feature.scripts:true}"
>>>>>>>>> />
>>>>>>>>>     <feature name="docker" enabled="${keycloak.feature.docker:false}"
>>>>>>>>> />
>>>>>>>>>   </features>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We should probably also facilitate transition for current
>>>>>>>>> deployments, and
>>>>>>>>> take old style system properties into account if they are used -
>>>>>>>>> converting
>>>>>>>>> them to the new ones before configuration is applied.
>>>>>>>>>
>>>>>>>>> Deprecated: -Dkeycloak.profile.feature.impersonation=enabled
>>>>>>>>> New style:    -Dkeycloak.feature.impersonation=true
>>>>>>>>>
>>>>>>>>> We don't want to keep support for this indefinitely (maybe for one
>>>>>>>>> minor
>>>>>>>>> version?) so if use of deprecated system properties is detected a
>>>>>>>>> warning
>>>>>>>>> will be logged.
>>>>>>>>>
>>>>>>>>> Also, Stian proposed that features not considered stable yet,
>>>>>>>>> should carry
>>>>>>>>> a suffix '-preview' in the name. So the actual feature name, and
>>>>>>>>> system
>>>>>>>>> property name may still change for some features.
>>>>>>>>>
>>>>>>>>> You can follow progress on JIRA issue [2].
>>>>>>>>>
>>>>>>>>> -
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://keycloak.gitbooks.io/documentation/server_installati
>>>>>>>>> on/topics/profiles.html
>>>>>>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4994
>>>>>>>>> _______________________________________________
>>>>>>>>> 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  4 06:15:51 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 4 Oct 2017 12:15:51 +0200
Subject: [keycloak-dev] Make built-in themes read/write
Message-ID: <CAJgngAdni71=HcEn7gcR-hcaO8+bC_gfVhDddzq4a+R3va6yqg@mail.gmail.com>

Currently the built-in themes are read-only to prevent people from
modifying them as they should create a custom theme to override instead.

The problem is that read-only files is causing an issue with patching in
RH-SSO.

The simplest solution would be to just change the files to read/write.

From bruno at abstractj.org  Wed Oct  4 08:03:31 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 4 Oct 2017 09:03:31 -0300
Subject: [keycloak-dev] Keycloak Website Updates - Security section
Message-ID: <20171004120331.GA23299@abstractj.org>

Good morning,

Today, we sometimes have people disclosing vulnerabilities at
the public mailing list. And later, they will find out that
there's a process to report it.

Now that we have the keycloak-security ML, I would like to suggest to make
such process evident into our website.

It's a common practice to have a "/security" path into your website. We
could do the same just creating an HTML and extracting the content from:
https://github.com/keycloak/keycloak.github.io/blob/master/community.html#L102-L113.
And of course, adding more details about how to do it.

Also, I would like to add it to the main page. That could be
done by replacing "Source" into the main menu with "Security".
"Source" is already referenced inside "Community" page,
people will figure out where to get the sources.

Does anything make sense?

--

abstractj

From sthorger at redhat.com  Wed Oct  4 08:44:48 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 4 Oct 2017 14:44:48 +0200
Subject: [keycloak-dev] Keycloak Website Updates - Security section
In-Reply-To: <20171004120331.GA23299@abstractj.org>
References: <20171004120331.GA23299@abstractj.org>
Message-ID: <CAJgngAfVfGqeViPhWa=gEn_RPmZkcGaa_mCrrHLiDAseRzZJ0w@mail.gmail.com>

+1 As you say remove "Source" it's not needed and I'd add "Security"
in-between "Community" and "Support"

On 4 October 2017 at 14:03, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> Today, we sometimes have people disclosing vulnerabilities at
> the public mailing list. And later, they will find out that
> there's a process to report it.
>
> Now that we have the keycloak-security ML, I would like to suggest to make
> such process evident into our website.
>
> It's a common practice to have a "/security" path into your website. We
> could do the same just creating an HTML and extracting the content from:
> https://github.com/keycloak/keycloak.github.io/blob/
> master/community.html#L102-L113.
> And of course, adding more details about how to do it.
>
> Also, I would like to add it to the main page. That could be
> done by replacing "Source" into the main menu with "Security".
> "Source" is already referenced inside "Community" page,
> people will figure out where to get the sources.
>
> Does anything make sense?
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From romain.poiffaut at elca.ch  Wed Oct  4 10:54:10 2017
From: romain.poiffaut at elca.ch (Poiffaut Romain)
Date: Wed, 4 Oct 2017 14:54:10 +0000
Subject: [keycloak-dev] Concurrency & EventsListener SPI
Message-ID: <245B52FB2334B147AE35533DEA5E5AA2A15754C4@MAILDBLS1.elcaNet.local>

Hi,

I am writing a provider for eventsListener SPI.
Could anyone tell me if the provider and its provider factory need to be thread safe ?
With more details, I need to store some events. To do so, I am using a collection created by the factory and a reference to this collection is passed to the constructor to update it.
Does my collection needs to be concurrency-safe or is it not needed?

Best regards,
Romain

From mposolda at redhat.com  Wed Oct  4 14:38:04 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 4 Oct 2017 20:38:04 +0200
Subject: [keycloak-dev] Concurrency & EventsListener SPI
In-Reply-To: <245B52FB2334B147AE35533DEA5E5AA2A15754C4@MAILDBLS1.elcaNet.local>
References: <245B52FB2334B147AE35533DEA5E5AA2A15754C4@MAILDBLS1.elcaNet.local>
Message-ID: <ad0e2e48-b943-7e7f-473d-879315a50359@redhat.com>

Factory is typically application-scoped when provider is typically 
request-scoped (hence single-threaded). Different threads can use more 
providers concurrently. In other words, provider doesn't need to be 
thread-safe (EG. if you are using collection scoped just to the 
lifecycle of single provider instance), but factory should be.

For your use-case, your collection needs to be concurrency-safe if I 
understand correctly, as it's shared for whole factory and it's possible 
that more providers (requests/threads) will concurrently update it.

Marek

On 04/10/17 16:54, Poiffaut Romain wrote:
> Hi,
>
> I am writing a provider for eventsListener SPI.
> Could anyone tell me if the provider and its provider factory need to be thread safe ?
> With more details, I need to store some events. To do so, I am using a collection created by the factory and a reference to this collection is passed to the constructor to update it.
> Does my collection needs to be concurrency-safe or is it not needed?
>
> Best regards,
> Romain
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From Joze.Mlakar at ixtlan-team.si  Thu Oct  5 04:02:39 2017
From: Joze.Mlakar at ixtlan-team.si (=?iso-8859-2?Q?Jo=BEe_Mlakar?=)
Date: Thu, 5 Oct 2017 08:02:39 +0000
Subject: [keycloak-dev] LDAP with Kerberos, login with different user
Message-ID: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>

We are considering implementing this feature.
The feature requires Keycloak to allow the user to logon as another user even if Kerberos works.

The user scenario is two fold:

*         Have an admin hold two accounts (normal with Kerberos and elevated using username/pass) and switch between them

*         Have a user logged on using Kerberos when another user visits and wants to logon as himself without logging on to the computer.

The feature would be implemented via a new query parameter (i.e. skipAuthMechanism=cookie,kerberos) that would allow the client to skip certain methods of authentication.

I would like to make sure such a PR would not be rejected as work would have been wasted.



From Joze.Mlakar at ixtlan-team.si  Thu Oct  5 04:15:48 2017
From: Joze.Mlakar at ixtlan-team.si (=?iso-8859-2?Q?Jo=BEe_Mlakar?=)
Date: Thu, 5 Oct 2017 08:15:48 +0000
Subject: [keycloak-dev] LDAP with Kerberos, login with different user
In-Reply-To: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>
References: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>
Message-ID: <f4bd44ba08a848729bd0063de6faada2@NETIX.ixtlan-team.si>

Also, before you comment, read https://github.com/keycloak/keycloak/pull/1644

I believe there is no harm in skip_auth_mechanisms query parameter. I agree there are scenarios where other options are also good, but not globally.

From romain.poiffaut at elca.ch  Thu Oct  5 05:25:30 2017
From: romain.poiffaut at elca.ch (Poiffaut Romain)
Date: Thu, 5 Oct 2017 09:25:30 +0000
Subject: [keycloak-dev] Concurrency & EventsListener SPI
In-Reply-To: <ad0e2e48-b943-7e7f-473d-879315a50359@redhat.com>
References: <245B52FB2334B147AE35533DEA5E5AA2A15754C4@MAILDBLS1.elcaNet.local>
	<ad0e2e48-b943-7e7f-473d-879315a50359@redhat.com>
Message-ID: <245B52FB2334B147AE35533DEA5E5AA2A15755A0@MAILDBLS1.elcaNet.local>

Thanks a lot for your answer.

Romain

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com] 
Sent: mercredi 4 octobre 2017 20:38
To: Poiffaut Romain <romain.poiffaut at elca.ch>; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Concurrency & EventsListener SPI

Factory is typically application-scoped when provider is typically request-scoped (hence single-threaded). Different threads can use more providers concurrently. In other words, provider doesn't need to be thread-safe (EG. if you are using collection scoped just to the lifecycle of single provider instance), but factory should be.

For your use-case, your collection needs to be concurrency-safe if I understand correctly, as it's shared for whole factory and it's possible that more providers (requests/threads) will concurrently update it.

Marek

On 04/10/17 16:54, Poiffaut Romain wrote:
> Hi,
>
> I am writing a provider for eventsListener SPI.
> Could anyone tell me if the provider and its provider factory need to be thread safe ?
> With more details, I need to store some events. To do so, I am using a collection created by the factory and a reference to this collection is passed to the constructor to update it.
> Does my collection needs to be concurrency-safe or is it not needed?
>
> Best regards,
> Romain
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




From velias at redhat.com  Thu Oct  5 08:55:46 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Thu, 5 Oct 2017 14:55:46 +0200
Subject: [keycloak-dev] Atlassian (Jira,
	Confluence) SSO adapters for OIDC/Keycloak
Message-ID: <de982659-1c72-3a30-0543-2c703955aa5d@redhat.com>

Hi,

I'm going to implement OIDC/Keycloak SSO adapters for Atlassian SW like 
Jira or Confluence, starting with Jira first.

My intention is to have full SSO integration there, so keycloak will be 
used for all logins to Jira (jira login page not used in any way), and 
even automatic login on first jira visit if user has SSO session in 
keycloak already. I wrote similar stuff for CAS protocol so I believe it 
is possible to implement it.

Do you think a repo for these adapters (one shared for all of them) 
should be hosted in https://github.com/keycloak organization? Or should 
I implement them in independent repo first and move under keycloak org 
later if my implementation will be worth it?

I plan to use OIDC adapter from keycloak project for my implementation, 
but my intention is to write them as universal OIDC adapters, not bound 
to Keycloak SSO server itself.

Vlastimil


-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From sthorger at redhat.com  Fri Oct  6 03:47:39 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 06 Oct 2017 09:47:39 +0200
Subject: [keycloak-dev] Update to 3.4 release dates
Message-ID: <1507276059.3676.10@smtp.gmail.com>

Update release dates:

* 16 October - Feature freeze! Only bug fixes after this point please
* 30 October - 3.4.0.CR1
* 6 November - 3.4.0.Final
* 20 November - 3.4.1.Final
* Mid December - master switches to 4.x

Community contribution deadlines for 3.x:

* 12 October - deadline for feature requests and bigger enhancements
* 26 October - deadline for small enhancements
* 1 November - deadline for bug fixes

Anything contributed after these dates will most likely not be 
reviewed/merged until 4.x

From sthorger at redhat.com  Fri Oct  6 03:51:14 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 06 Oct 2017 09:51:14 +0200
Subject: [keycloak-dev] Atlassian (Jira,
 Confluence) SSO adapters for OIDC/Keycloak
In-Reply-To: <1507264995.3676.4@smtp.gmail.com>
References: <de982659-1c72-3a30-0543-2c703955aa5d@redhat.com>
	<1507264995.3676.4@smtp.gmail.com>
Message-ID: <1507276274.3676.12@smtp.gmail.com>

Do they really need separate adapters? I would have thought Atlassian 
would be smart enough to let you write one auth plugin for all.

Would be good to have this in Keycloak for sure. I can add a repo for 
you and make you admin of the repo. Does keycloak-atlassian-plugin 
sound right? We already have one for Jenkins 
(https://github.com/keycloak/jenkins-keycloak-plugin) although I have 
no clue what state it is in.

On Fri, Oct 6, 2017 at 6:43 AM, Stian Thorgersen <sthorger at redhat.com> 
wrote:
> Do they really need separate adapters? I would have thought Atlassian 
> would be smart enough to let you write one auth plugin for all.
> 
> Would be good to have this in Keycloak for sure. I can add a repo for 
> you and make you admin of the repo. Does keycloak-atlassian-plugin 
> sound right? We already have one for Jenkins 
> (https://github.com/keycloak/jenkins-keycloak-plugin) although I have 
> no clue what state it is in.
> 
> On Thu, Oct 5, 2017 at 2:55 PM, Vlastimil Elias <velias at redhat.com> 
> wrote:
>> Hi,
>> 
>> I'm going to implement OIDC/Keycloak SSO adapters for Atlassian SW 
>> like
>> Jira or Confluence, starting with Jira first.
>> 
>> My intention is to have full SSO integration there, so keycloak will 
>> be
>> used for all logins to Jira (jira login page not used in any way), 
>> and
>> even automatic login on first jira visit if user has SSO session in
>> keycloak already. I wrote similar stuff for CAS protocol so I 
>> believe it
>> is possible to implement it.
>> 
>> Do you think a repo for these adapters (one shared for all of them)
>> should be hosted in https://github.com/keycloak organization? Or 
>> should
>> I implement them in independent repo first and move under keycloak 
>> org
>> later if my implementation will be worth it?
>> 
>> I plan to use OIDC adapter from keycloak project for my 
>> implementation,
>> but my intention is to write them as universal OIDC adapters, not 
>> bound
>> to Keycloak SSO server itself.
>> 
>> Vlastimil
>> 
>> 
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From velias at redhat.com  Fri Oct  6 05:05:45 2017
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 6 Oct 2017 11:05:45 +0200
Subject: [keycloak-dev] Atlassian (Jira,
 Confluence) SSO adapters for OIDC/Keycloak
In-Reply-To: <1507264995.3676.4@smtp.gmail.com>
References: <de982659-1c72-3a30-0543-2c703955aa5d@redhat.com>
	<1507264995.3676.4@smtp.gmail.com>
Message-ID: <3ebd6eae-9927-0d69-c2da-91049eb162a8@redhat.com>

Hi,


On 6.10.2017 06:43, Stian Thorgersen wrote:
> Do they really need separate adapters? I would have thought Atlassian 
> would be smart enough to let you write one auth plugin for all.

They have some common frameworks around auth and user management like 
Seraph and Crowd-Embedded used in most of their products, but there are 
still some differences in some areas (as some atlassian products are 
from acquisitions so not totally same internally). Sometimes even new 
version of one product requires changed implementation. My intention is 
to create common base for the adapter, and then as tiny special wrappers 
for distinct products/versions as possible.

>
> Would be good to have this in Keycloak for sure. I can add a repo for 
> you and make you admin of the repo. Does keycloak-atlassian-plugin 
> sound right? We already have one for Jenkins 
> (https://github.com/keycloak/jenkins-keycloak-plugin) although I have 
> no clue what state it is in.

If you can create the repo now and let me work in it then cool, 
keycloak-atlassian-plugin name works for me. I'll use same OSS License 
as Keycloak for this code.

Thanks

Vlastimil

>
> On Thu, Oct 5, 2017 at 2:55 PM, Vlastimil Elias <velias at redhat.com> wrote:
>> Hi, I'm going to implement OIDC/Keycloak SSO adapters for Atlassian 
>> SW like Jira or Confluence, starting with Jira first. My intention is 
>> to have full SSO integration there, so keycloak will be used for all 
>> logins to Jira (jira login page not used in any way), and even 
>> automatic login on first jira visit if user has SSO session in 
>> keycloak already. I wrote similar stuff for CAS protocol so I believe 
>> it is possible to implement it. Do you think a repo for these 
>> adapters (one shared for all of them) should be hosted in 
>> https://github.com/keycloak organization? Or should I implement them 
>> in independent repo first and move under keycloak org later if my 
>> implementation will be worth it? I plan to use OIDC adapter from 
>> keycloak project for my implementation, but my intention is to write 
>> them as universal OIDC adapters, not bound to Keycloak SSO server 
>> itself. Vlastimil
>> -- 
>> Vlastimil Elias Principal Software Engineer, Middleware Engineering 
>> Services Red Hat _______________________________________________ 
>> keycloak-dev mailing list keycloak-dev at lists.jboss.org 
>> <mailto:keycloak-dev at lists.jboss.org> 
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat


From thomas.darimont at googlemail.com  Fri Oct  6 19:14:03 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 7 Oct 2017 01:14:03 +0200
Subject: [keycloak-dev] Current server distribution build broken?
Message-ID: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>

Hello,

I cannot build a working keycloak server distribution from current master
(7774d5c6b8) with:
 mvn clean install -Pdistribution -DskipTests

When I try to run the keycloak server-distribution, I see an exception:
WFLYCTL0083: Failed to load module org.keycloak.keycloak-server-subsystem

....
00:01:29,788 INFO  [org.jboss.as.controller] (Controller Boot Thread)
OPVDX002: Failed to pretty print validation error: null
00:01:29,789 ERROR [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0055: Caught exception during boot:
org.jboss.as.controller.persistence.ConfigurationPersistenceException:
WFLYCTL0085: Failed to parse configuration
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:387)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load
module org.keycloak.keycloak-server-subsystem
at
org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:154)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXit
ml.java:131) [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
[wildfly-server-3.0.1.Final.jar:3.0.1.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
[staxmapper-1.3.0.Final.jar:1.3.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
[staxmapper-1.3.0.Final.jar:1.3.0.Final]
at
org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:126)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 3 more
Caused by: java.util.concurrent.ExecutionException:
javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load module
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
[rt.jar:1.8.0_144]
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
[rt.jar:1.8.0_144]
at
org.jboss.as.controller.parsing.ExtensionXml.parseExtensions(ExtensionXml.java:146)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 11 more
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to load
module
at
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:195)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at
org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_144]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_144]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_144]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
[jboss-threads-2.2.1.Final.jar:2.2.1.Final]
Caused by: org.jboss.modules.ModuleNotFoundException:
org.keycloak.keycloak-server-subsystem
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:285)
[jboss-modules.jar:1.6.0.Final]
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
[jboss-modules.jar:1.6.0.Final]
at
org.jboss.as.controller.parsing.ExtensionXml.loadModule(ExtensionXml.java:177)
[wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
... 8 more

00:01:29,791 FATAL [org.jboss.as.server] (Controller Boot Thread)
WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
See previous messages for details.
00:01:29,804 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050:
WildFly Core 3.0.1.Final "Kenny" stopped in 8ms
....

Cheers,
Thomas

From thomas.darimont at googlemail.com  Fri Oct  6 19:37:37 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sat, 7 Oct 2017 01:37:37 +0200
Subject: [keycloak-dev] Current server distribution build broken?
In-Reply-To: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>
References: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>
Message-ID: <CAK-7U1jtYZJdmVOERaQhyxfdyzYxoZx1MqGbC=9L-fZMsPfTGA@mail.gmail.com>

... ignore the previous mail. It was just PEBKAC - server distribution
works fine.

Cheers,
Thomas

2017-10-07 1:14 GMT+02:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Hello,
>
> I cannot build a working keycloak server distribution from current master
> (7774d5c6b8) with:
>  mvn clean install -Pdistribution -DskipTests
>
> When I try to run the keycloak server-distribution, I see an exception:
> WFLYCTL0083: Failed to load module org.keycloak.keycloak-server-subsystem
>
> ....
> 00:01:29,788 INFO  [org.jboss.as.controller] (Controller Boot Thread)
> OPVDX002: Failed to pretty print validation error: null
> 00:01:29,789 ERROR [org.jboss.as.server] (Controller Boot Thread)
> WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.
> persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to
> parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(
> XmlConfigurationPersister.java:143) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> at org.jboss.as.server.ServerService.boot(ServerService.java:387)
> [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.controller.AbstractControllerService$1.
> run(AbstractControllerService.java:370) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to
> load module org.keycloak.keycloak-server-subsystem
> at org.jboss.as.controller.parsing.ExtensionXml.
> parseExtensions(ExtensionXml.java:154) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> at org.jboss.as.server.parsing.StandaloneXml$DefaultExtensionHandler.parseExtensions(StandaloneXit
> ml.java:131) [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.server.parsing.StandaloneXml_5.readServerElement(StandaloneXml_5.java:219)
> [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.server.parsing.StandaloneXml_5.readElement(StandaloneXml_5.java:142)
> [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107)
> [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:49)
> [wildfly-server-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:122)
> [staxmapper-1.3.0.Final.jar:1.3.0.Final]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:76)
> [staxmapper-1.3.0.Final.jar:1.3.0.Final]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(
> XmlConfigurationPersister.java:126) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> ... 3 more
> Caused by: java.util.concurrent.ExecutionException: javax.xml.stream.XMLStreamException:
> WFLYCTL0083: Failed to load module
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [rt.jar:1.8.0_144]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> [rt.jar:1.8.0_144]
> at org.jboss.as.controller.parsing.ExtensionXml.
> parseExtensions(ExtensionXml.java:146) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> ... 11 more
> Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0083: Failed to
> load module
> at org.jboss.as.controller.parsing.ExtensionXml.
> loadModule(ExtensionXml.java:195) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> at org.jboss.as.controller.parsing.ExtensionXml.access$000(ExtensionXml.java:68)
> [wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:126)
> [wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
> at org.jboss.as.controller.parsing.ExtensionXml$1.call(ExtensionXml.java:123)
> [wildfly-controller-3.0.1.Final.jar:3.0.1.Final]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [rt.jar:1.8.0_144]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [rt.jar:1.8.0_144]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [rt.jar:1.8.0_144]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [jboss-threads-2.2.1.Final.jar:2.2.1.Final]
> Caused by: org.jboss.modules.ModuleNotFoundException:
> org.keycloak.keycloak-server-subsystem
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:285)
> [jboss-modules.jar:1.6.0.Final]
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:271)
> [jboss-modules.jar:1.6.0.Final]
> at org.jboss.as.controller.parsing.ExtensionXml.
> loadModule(ExtensionXml.java:177) [wildfly-controller-3.0.1.
> Final.jar:3.0.1.Final]
> ... 8 more
>
> 00:01:29,791 FATAL [org.jboss.as.server] (Controller Boot Thread)
> WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting.
> See previous messages for details.
> 00:01:29,804 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050:
> WildFly Core 3.0.1.Final "Kenny" stopped in 8ms
> ....
>
> Cheers,
> Thomas
>

From pnalyvayko at agi.com  Sun Oct  8 14:58:42 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Sun, 8 Oct 2017 18:58:42 +0000
Subject: [keycloak-dev] Pull Request #4546: Enable X.509 client certificate
 user authentication when hosting KC behind a reverse proxy
In-Reply-To: <CAK-7U1jtYZJdmVOERaQhyxfdyzYxoZx1MqGbC=9L-fZMsPfTGA@mail.gmail.com>
References: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>,
	<CAK-7U1jtYZJdmVOERaQhyxfdyzYxoZx1MqGbC=9L-fZMsPfTGA@mail.gmail.com>
Message-ID: <DM5PR07MB2937780621FF209A49EB6B4EDA770@DM5PR07MB2937.namprd07.prod.outlook.com>

Hello kc team,

This is a request for review & comments. In in the pull request is a refactored implementation of the original X509 client cert user authentication to enable x509 auth when behind a reverse proxy. Let me know whether this is a feature that KC team deems useful. Comments how to improve the implementation are welcome
Regards,
--Peter

From Joze.Mlakar at ixtlan-team.si  Mon Oct  9 01:02:04 2017
From: Joze.Mlakar at ixtlan-team.si (=?iso-8859-2?Q?Jo=BEe_Mlakar?=)
Date: Mon, 9 Oct 2017 05:02:04 +0000
Subject: [keycloak-dev] Pull Request #4546: Enable X.509 client
 certificate user authentication when hosting KC behind a reverse proxy
In-Reply-To: <DM5PR07MB2937780621FF209A49EB6B4EDA770@DM5PR07MB2937.namprd07.prod.outlook.com>
References: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>,
	<CAK-7U1jtYZJdmVOERaQhyxfdyzYxoZx1MqGbC=9L-fZMsPfTGA@mail.gmail.com>
	<DM5PR07MB2937780621FF209A49EB6B4EDA770@DM5PR07MB2937.namprd07.prod.outlook.com>
Message-ID: <70e83813b6f3460ab620e60ba3837de7@NETIX.ixtlan-team.si>

We need this feature :)


From mposolda at redhat.com  Mon Oct  9 02:52:01 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 9 Oct 2017 08:52:01 +0200
Subject: [keycloak-dev] Pull Request #4546: Enable X.509 client
 certificate user authentication when hosting KC behind a reverse proxy
In-Reply-To: <DM5PR07MB2937780621FF209A49EB6B4EDA770@DM5PR07MB2937.namprd07.prod.outlook.com>
References: <CAK-7U1ija+xauvdYMRNOUGFFv99v_sfF7jSu6r8tLquKFYtyvA@mail.gmail.com>
	<CAK-7U1jtYZJdmVOERaQhyxfdyzYxoZx1MqGbC=9L-fZMsPfTGA@mail.gmail.com>
	<DM5PR07MB2937780621FF209A49EB6B4EDA770@DM5PR07MB2937.namprd07.prod.outlook.com>
Message-ID: <10971ef6-ad70-7862-8644-bd225bade811@redhat.com>

Hi Peter,

Thanks for the PR. I will try to take a look at PR today or tomorrow.

Marek

On 08/10/17 20:58, Nalyvayko, Peter wrote:
> Hello kc team,
>
> This is a request for review & comments. In in the pull request is a refactored implementation of the original X509 client cert user authentication to enable x509 auth when behind a reverse proxy. Let me know whether this is a feature that KC team deems useful. Comments how to improve the implementation are welcome
> Regards,
> --Peter
> _______________________________________________
> 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  9 05:22:05 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 9 Oct 2017 11:22:05 +0200
Subject: [keycloak-dev] Claims parameter support
In-Reply-To: <CAGZZ5OieteeAPAGLWoBcw8ScPU--x=2eS+29pYHRVHoWKoxopA@mail.gmail.com>
References: <CAGZZ5OisW6n9Da3h0MokoRcN9tAVzzSYGTwckwcRkXKGTRRnwA@mail.gmail.com>
	<9432de62-9275-14c5-8b8e-6211e151d6c5@redhat.com>
	<CAGZZ5Og4bdyQ3OvsThB+8gCVCOJu_LZ-Wr7Y-RHs02xH0wyD5A@mail.gmail.com>
	<CAGZZ5OjKULV7i0rtkZf+q3JLjYz-oWcCs+wsqz5P2Bh5OaCObw@mail.gmail.com>
	<a90993f3-f2bb-85db-7e90-49118348933d@redhat.com>
	<CAGZZ5OieteeAPAGLWoBcw8ScPU--x=2eS+29pYHRVHoWKoxopA@mail.gmail.com>
Message-ID: <847a1efa-e4ba-3d33-f4c5-eb90b971df7f@redhat.com>

Thanks, I've merged the PR.

My vote is then to also include the protocolMapper for claims parameter 
support.  I can't guarantee for sure that it will be added (need to 
discuss with other team members), but if it's not big issue for you to 
send PR, it will be welcome. Thanks :)

Marek

On 03/10/17 16:12, Aron Bustya wrote:
> Here's the JIRA - with pull request sent:
>
> https://issues.jboss.org/browse/KEYCLOAK-5616
>
> On 2 October 2017 at 20:21, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Cool, do you want to create JIRA and send PR with the commit?
>
>     Thanks,
>     Marek
>
>
>     On 01/10/17 20:23, Aron Bustya wrote:
>>     https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135
>>     <https://github.com/abustya/keycloak/commit/aa507cb0e4271ff1166cb45a1248aa25affa5135>
>>
>>     I have updated my code - now it doesn't include the mapper
>>     itself, but it does include the processing of the param as a
>>     "known param" and some tests for this.
>>
>>     On 30 September 2017 at 22:32, Aron Bustya
>>     <aron.bustya.js at gmail.com <mailto:aron.bustya.js at gmail.com>> wrote:
>>
>>         Hi,
>>
>>         Sorry for the long silence.
>>
>>         >Maybe one small change, if you can add the "claims" to the
>>         AuthzEndpointRequestParser.KNOWN_PARAMS and have separate
>>         client note for it as other known OIDC params?
>>         This would be good, because the "additional" parameters have
>>         a maximum length of 200 characters to be processed.
>>
>>
>>
>>         On 20 September 2017 at 09:55, Marek Posolda
>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>
>>             Great work!
>>
>>             If I see it correctly, there are 2 parts:
>>
>>             1) improvements in request object parsing - I am all for
>>             include your improvements. If you can create separate
>>             JIRA for current request object limitation, add the test
>>             (there are existing tests for request object in
>>             OIDCAdvancedRequestParamsTest. Feel free to add new test
>>             or change one of existing tests) and create separate PR,
>>             it will be nice and will be merged. If I understand
>>             correctly, this is the only part, which really blocks you
>>             right? (As additional protocolMapper can be deployed to
>>             the existing Keycloak instance as separate JAR and
>>             doesn't require changes in core keycloak code?)
>>
>>             2) ProtocolMapper for claims - as you pointed, you don't
>>             have full support for 'claims' parameter. Still it's
>>             better then nothing, so my vote is to include your
>>             changes. I am not 100% convinced, maybe someone has
>>             different opinion on it (new protocolMapper always adds a
>>             bit of additional complexity. However I think it's ok as
>>             it's OIDC standard). Maybe one small change, if you can
>>             add the "claims" to the
>>             AuthzEndpointRequestParser.KNOWN_PARAMS and have separate
>>             client note for it as other known OIDC params?
>>
>>             Thanks!
>>             Marek
>>
>>
>>
>>             On 19/09/17 22:49, Aron Bustya wrote:
>>>             Hello! I need the 'claims parameter' support in keycloak
>>>             that has been thought about in this jira ticket and
>>>             postponed/rejected:
>>>             https://issues.jboss.org/browse/KEYCLOAK-3226
>>>             <https://issues.jboss.org/browse/KEYCLOAK-3226> The
>>>             proposed alternatives don't work for me, because I am
>>>             implementing a specification that explicitly requests
>>>             data to be passed this way. In addition to the JIRA
>>>             above we also need to support passing the claims
>>>             parameter in the signed request object - not just as a
>>>             separate query param. I've solved the problem for our
>>>             own use case by writing a ProtocolMapper but some
>>>             changes were also needed in the keycloak request parser
>>>             (to support the parsing of json objects from the request
>>>             object - not just strings). The ProtocolMapper I've
>>>             written doesn't support the whole claims parameter
>>>             feature though - it can only add the default value of
>>>             the claim to the the tokens. I'm now trying to figure
>>>             out how much of this code could be put back into
>>>             keycloak, and what needs to be changed to do so. My goal
>>>             would be to use an 'official' keycloak with cutomization
>>>             only in Service Providers and configuration. Current
>>>             code commit is here:
>>>             https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9
>>>             <https://github.com/abustya/keycloak/commit/41fecf57a982ffdb9>
>>>
>>>             6e210d8bd302d23fa7884da
>>>
>>>             What do you think about the direction of the development, does it make any
>>>             sense to put some of it back into keycloak?
>>>
>>>             Regards,
>>>             ?ron Bustya
>>>             _______________________________________________
>>>             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  9 06:47:13 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 9 Oct 2017 12:47:13 +0200
Subject: [keycloak-dev] LDAP with Kerberos, login with different user
In-Reply-To: <f4bd44ba08a848729bd0063de6faada2@NETIX.ixtlan-team.si>
References: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>
	<f4bd44ba08a848729bd0063de6faada2@NETIX.ixtlan-team.si>
Message-ID: <9241110a-0c46-6025-5130-28a2188c20ec@redhat.com>

As you can see in the older discussions in the PR in JIRA, we were still 
discussing what exactly to do. Some approaches were:

1) Use the parameter like skip_auth_mechanisms

2) Use another confirmation screen (Account chooser authenticator or 
something like that) - Something, which will be shown after successful 
Kerberos authentication as user "jdoe" and will display "Do you really 
want to authenticate as John Doe, click <link>here</link> . Do you want 
to authenticate as the other user click <link>here</link>". In the 
latter case, Kerberos authentication will be bypassed and 
username/password screen shown

3) Automatically skip Kerberos after the logout. I personally didn't 
like this approach. IMO if we do this, we will anyway need the config 
option on the Kerberos authenticator.

My personal preference is 1, then 2, then 3.

For your usecase, I suspect that in most of the cases you want to 
authenticate as Kerberos user, but just in some special cases (admin 
needs to authenticate with some special account etc) bypass Kerberos. Is 
it correct? So the query parameter is your preferred way right?

Anyway, I wouldn't start contribute to Keycloak for now until it's 
agreed what exactly to do. You can already handle it in your environment 
with your own Authenticator implementation where you can implement 
"skip_auth_mechanisms" or something like that.

Marek

On 05/10/17 10:15, Jo?e Mlakar wrote:
> Also, before you comment, read https://github.com/keycloak/keycloak/pull/1644
>
> I believe there is no harm in skip_auth_mechanisms query parameter. I agree there are scenarios where other options are also good, but not globally.
> _______________________________________________
> 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  9 06:55:14 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 9 Oct 2017 12:55:14 +0200
Subject: [keycloak-dev] LDAP with Kerberos, login with different user
In-Reply-To: <9241110a-0c46-6025-5130-28a2188c20ec@redhat.com>
References: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>
	<f4bd44ba08a848729bd0063de6faada2@NETIX.ixtlan-team.si>
	<9241110a-0c46-6025-5130-28a2188c20ec@redhat.com>
Message-ID: <10de974a-1f7f-d353-e494-ffa2956b64fb@redhat.com>

Another thing is, that we are planning to add the support for the "acr" 
OIDC parameter (aka authentication levels) and I believe that this 
usecase should be addressed through this.

For now, I would do something on your own as we still need to discuss 
how exactly to address this and when (My guess is Keycloak 4.x somewhen 
next year).

Marek


On 09/10/17 12:47, Marek Posolda wrote:
> As you can see in the older discussions in the PR in JIRA, we were 
> still discussing what exactly to do. Some approaches were:
>
> 1) Use the parameter like skip_auth_mechanisms
>
> 2) Use another confirmation screen (Account chooser authenticator or 
> something like that) - Something, which will be shown after successful 
> Kerberos authentication as user "jdoe" and will display "Do you really 
> want to authenticate as John Doe, click <link>here</link> . Do you 
> want to authenticate as the other user click <link>here</link>". In 
> the latter case, Kerberos authentication will be bypassed and 
> username/password screen shown
>
> 3) Automatically skip Kerberos after the logout. I personally didn't 
> like this approach. IMO if we do this, we will anyway need the config 
> option on the Kerberos authenticator.
>
> My personal preference is 1, then 2, then 3.
>
> For your usecase, I suspect that in most of the cases you want to 
> authenticate as Kerberos user, but just in some special cases (admin 
> needs to authenticate with some special account etc) bypass Kerberos. 
> Is it correct? So the query parameter is your preferred way right?
>
> Anyway, I wouldn't start contribute to Keycloak for now until it's 
> agreed what exactly to do. You can already handle it in your 
> environment with your own Authenticator implementation where you can 
> implement "skip_auth_mechanisms" or something like that.
>
> Marek
>
> On 05/10/17 10:15, Jo?e Mlakar wrote:
>> Also, before you comment, read 
>> https://github.com/keycloak/keycloak/pull/1644
>>
>> I believe there is no harm in skip_auth_mechanisms query parameter. I 
>> agree there are scenarios where other options are also good, but not 
>> globally.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>


From Joze.Mlakar at ixtlan-team.si  Mon Oct  9 13:20:33 2017
From: Joze.Mlakar at ixtlan-team.si (=?utf-8?B?Sm/FvmUgTWxha2Fy?=)
Date: Mon, 9 Oct 2017 17:20:33 +0000
Subject: [keycloak-dev] LDAP with Kerberos, login with different user
In-Reply-To: <10de974a-1f7f-d353-e494-ffa2956b64fb@redhat.com>
References: <a87f5a3d214d42a3afa3f8d88ddafeb9@NETIX.ixtlan-team.si>
	<f4bd44ba08a848729bd0063de6faada2@NETIX.ixtlan-team.si>
	<9241110a-0c46-6025-5130-28a2188c20ec@redhat.com>
	<10de974a-1f7f-d353-e494-ffa2956b64fb@redhat.com>
Message-ID: <CDCE8D66-9994-4403-BC1B-BA3BAC723344@ixtlan-team.si>

Understood, I have the changes for option 1 ready, however it?s usablity is very limited. As was noted by one of the developers the pressure is now on the clients to decide if and when to use the skip_auth_mechanisms. In case of keycloak.js client the client is forced to use some sort of storage (cookie) to rembember that the user logged of and have the next login use the new parameter. As said this is ready for a PR but i kind of hate it.

I am on board for option 2. If I get some more devs supporting this option, we will go ahead and create a PR (separate of option 1?).

Option 3 is a killer for user experience. Users would have no idea why they got a login screen.


From carl-kristian.eriksen at telia.no  Tue Oct 10 03:23:18 2017
From: carl-kristian.eriksen at telia.no (carl-kristian.eriksen at telia.no)
Date: Tue, 10 Oct 2017 07:23:18 +0000
Subject: [keycloak-dev] KEYCLOAK-5032 - Pull Request
Message-ID: <20454063-F93E-4562-9CE9-EA1ACF8BADE4@Telia.no>

Hi.

Thanks. Everything seems ok now.
The commit now includes forwarding of acr_values and prompt. The nonce work has been removed from the commit.

Could any of you give it a review and merge it?

Carl Kristian Eriksen

From: Marko Strukelj <mstrukel at redhat.com>
Date: Tuesday 3 October 2017 at 12:37
To: "Eriksen, Carl Kristian K. /External" <carl-kristian.eriksen at telia.no>
Cc: Bill Burke <bburke at redhat.com>, keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] KEYCLOAK-5032 - Implementation question

CI uses extra options. Try running your tests with -Pauth-server-wildfly. That usually exposes extra issues.

On Mon, Oct 2, 2017 at 1:34 PM, <carl-kristian.eriksen at telia.no<mailto:carl-kristian.eriksen at telia.no>> wrote:
The second commit in the PR failed the CI build, but the tests does not fail locally.
Do you have any suggestions on how to handle this?

Carl Kristian Eriksen


On 29/09/17 16:41, "keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> on behalf of carl-kristian.eriksen at telia.no<mailto:carl-kristian.eriksen at telia.no>" <keycloak-dev-bounces at lists.jboss.org<mailto:keycloak-dev-bounces at lists.jboss.org> on behalf of carl-kristian.eriksen at telia.no<mailto:carl-kristian.eriksen at telia.no>> wrote:

    Hi.

     I?ll follow up on the PR.

    Br / mvh
    Carl Kristian Eriksen
    On 29/09/17 15:50, "Bill Burke" <bburke at redhat.com<mailto:bburke at redhat.com>> wrote:

        Do you want to continue talking on the PR or here?  I had some
        concerns with your PR.

        On Wed, Sep 27, 2017 at 5:45 AM,  <carl-kristian.eriksen at telia.no<mailto:carl-kristian.eriksen at telia.no>> wrote:
        > https://issues.jboss.org/browse/KEYCLOAK-5032 describes two requested query parameters: acr_values and nonce
        >
        > Our requirements are for acr_values and prompt, and I?m working on a pull request for these two.
        >
        > How many pull requests do you want?
        > Should I make sure that (each)PR includes support for one, two or three query parameters
        >
        > Can the ?prompt? parameter be added to KEYCLOAK-5032, or do I need another Jira task for the ?prompt? parameter?
        >
        > Br / mvh
        > Carl Kristian Eriksen
    > _______________________________________________
        > keycloak-dev mailing list
        > keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
        > https://lists.jboss.org/mailman/listinfo/keycloak-dev



        --
        Bill Burke
        Red Hat



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


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


From vramik at redhat.com  Tue Oct 10 04:44:55 2017
From: vramik at redhat.com (Vlasta Ramik)
Date: Tue, 10 Oct 2017 10:44:55 +0200
Subject: [keycloak-dev] server-config-migration
Message-ID: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>

I'm working on rewriting server-config-migration tests. Currently there 
is used wildfly-maven-plugin which does the migration in online mode, 
I've redone this using exec plugin and the migration is done in offline 
mode.

My question is how do we should handle changes what are done to 
standalone.xml (or standalone-ha.xml, etc.) between different versions 
of wildfly. It is out of keycloak scope, but according to migration 
guide [1], users are supposed to replace default version (current) of 
config with previous version.

As far as I was able to find out WF uses a tool [2] for migration. There 
is not migration from WF10 to WF11.

Should be it somehow incorporated into our migration scripts?

If not then the migration guide should be updated with supported 
migration steps.

[1] 
http://www.keycloak.org/docs/latest/server_admin/topics/MigrationFromOlderVersions.html
[2] https://github.com/wildfly/wildfly-server-migration/releases

From mstrukel at redhat.com  Tue Oct 10 06:26:59 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 10 Oct 2017 12:26:59 +0200
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
Message-ID: <CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>

I've been looking at server-config-migration tests a little so I have some
thoughts on this.

As a criteria - most elegant solution is for our migration scripts to
perform the minimum necessary migration operations. I think we only target
these scripts for keycloak server distribution - not overlay - thus we have
full knowledge of what Wildfly version is underneath a specific Keycloak
version, and we can add all the necessary .cli commands to address
configuration changes due to Wildfly upgrade whould that be necessary. But,
AFAICT no explicit Wildfly upgrade is necessary because it happens
automatically in this scenario.

Our migration scripts presume latest Keycloak (not Wildfly) installation.
And what that means is that you already have all the underlying Wildfly
updates in place (i.e. modules) because latest Keycloak distribution
already contains them - except that you overwrite standalone.xml with old
one like you say. Wildfly subsystems are supposed to take care of their own
migration as far as configuration goes. Most of the work of
wildfly-server-migration tool, I believe, is to apply modules changes. Any
configuration updates as reflected in standalone.xml are delegated to
subsystems, and if they are not performed by migration tool, or
automatically by subsystems during offline migration, they are performed
automatically by subsystems the first time you start migrated Keycloak.

So, I don't think we need to concern ourselves with Wildfly to Wildfly
migration at all.


On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:

> I'm working on rewriting server-config-migration tests. Currently there
> is used wildfly-maven-plugin which does the migration in online mode,
> I've redone this using exec plugin and the migration is done in offline
> mode.
>
> My question is how do we should handle changes what are done to
> standalone.xml (or standalone-ha.xml, etc.) between different versions
> of wildfly. It is out of keycloak scope, but according to migration
> guide [1], users are supposed to replace default version (current) of
> config with previous version.
>
> As far as I was able to find out WF uses a tool [2] for migration. There
> is not migration from WF10 to WF11.
>
> Should be it somehow incorporated into our migration scripts?
>
> If not then the migration guide should be updated with supported
> migration steps.
>
> [1]
> http://www.keycloak.org/docs/latest/server_admin/topics/
> MigrationFromOlderVersions.html
> [2] https://github.com/wildfly/wildfly-server-migration/releases
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From vramik at redhat.com  Tue Oct 10 07:51:54 2017
From: vramik at redhat.com (Vlasta Ramik)
Date: Tue, 10 Oct 2017 13:51:54 +0200
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
	<CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
Message-ID: <df036383-1110-3c18-b343-9f81d3a4e0ba@redhat.com>

Thanks Marko,

if I understand correctly changes performed within subsystems are 
handled by the subsystem itself during the first container start (at the 
latest). But changes like removing subsystem should be added as a 
command to our migration script, right?

There is <subsystem xmlns="urn:jboss:domain:jdr:1.0"/> remained after 
migration (and after container start) on my env.

If so, I'll add the command, if not a JIRA should be fired.

On 10/10/2017 12:26 PM, Marko Strukelj wrote:
> I've been looking at server-config-migration tests a little so I have 
> some thoughts on this.
>
> As a criteria - most elegant solution is for our migration scripts to 
> perform the minimum necessary migration operations. I think we only 
> target these scripts for keycloak server distribution - not overlay - 
> thus we have full knowledge of what Wildfly version is underneath a 
> specific Keycloak version, and we can add all the necessary .cli 
> commands to address configuration changes due to Wildfly upgrade 
> whould that be necessary. But, AFAICT no explicit Wildfly upgrade is 
> necessary because it happens automatically in this scenario.
>
> Our migration scripts presume latest Keycloak (not Wildfly) 
> installation. And what that means is that you already have all the 
> underlying Wildfly updates in place (i.e. modules) because latest 
> Keycloak distribution already contains them - except that you 
> overwrite standalone.xml with old one like you say. Wildfly subsystems 
> are supposed to take care of their own migration as far as 
> configuration goes. Most of the work of wildfly-server-migration tool, 
> I believe, is to apply modules changes. Any configuration updates as 
> reflected in standalone.xml are delegated to subsystems, and if they 
> are not performed by migration tool, or automatically by subsystems 
> during offline migration, they are performed automatically by 
> subsystems the first time you start migrated Keycloak.
>
> So, I don't think we need to concern ourselves with Wildfly to Wildfly 
> migration at all.
>
>
> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com 
> <mailto:vramik at redhat.com>> wrote:
>
>     I'm working on rewriting server-config-migration tests. Currently
>     there
>     is used wildfly-maven-plugin which does the migration in online mode,
>     I've redone this using exec plugin and the migration is done in
>     offline
>     mode.
>
>     My question is how do we should handle changes what are done to
>     standalone.xml (or standalone-ha.xml, etc.) between different versions
>     of wildfly. It is out of keycloak scope, but according to migration
>     guide [1], users are supposed to replace default version (current) of
>     config with previous version.
>
>     As far as I was able to find out WF uses a tool [2] for migration.
>     There
>     is not migration from WF10 to WF11.
>
>     Should be it somehow incorporated into our migration scripts?
>
>     If not then the migration guide should be updated with supported
>     migration steps.
>
>     [1]
>     http://www.keycloak.org/docs/latest/server_admin/topics/MigrationFromOlderVersions.html
>     <http://www.keycloak.org/docs/latest/server_admin/topics/MigrationFromOlderVersions.html>
>     [2] https://github.com/wildfly/wildfly-server-migration/releases
>     <https://github.com/wildfly/wildfly-server-migration/releases>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From ssilvert at redhat.com  Tue Oct 10 07:57:06 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 10 Oct 2017 07:57:06 -0400
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
	<CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
Message-ID: <5eba238f-c718-5813-2bf8-9a3b2148a0ea@redhat.com>

I agree with Marko about WildFly to WildFly migration.  It would be 
possible for the migration scripts to check the WildFly version though.  
Maybe that should be added?

Vlasta, the current migration test has an important overarching 
purpose.  That is, it can tell if someone changed the config files 
(standlone.xml, etc.) without updating the migration scripts.

I suspect that most developers on our team don't think about the 
migration scripts much (if they even know about them).  So it would be 
easy for migration to get out of sync with configs.  No matter what you 
do to the tests, please keep this sanity check intact.

On 10/10/2017 6:26 AM, Marko Strukelj wrote:
> I've been looking at server-config-migration tests a little so I have some
> thoughts on this.
>
> As a criteria - most elegant solution is for our migration scripts to
> perform the minimum necessary migration operations. I think we only target
> these scripts for keycloak server distribution - not overlay - thus we have
> full knowledge of what Wildfly version is underneath a specific Keycloak
> version, and we can add all the necessary .cli commands to address
> configuration changes due to Wildfly upgrade whould that be necessary. But,
> AFAICT no explicit Wildfly upgrade is necessary because it happens
> automatically in this scenario.
>
> Our migration scripts presume latest Keycloak (not Wildfly) installation.
> And what that means is that you already have all the underlying Wildfly
> updates in place (i.e. modules) because latest Keycloak distribution
> already contains them - except that you overwrite standalone.xml with old
> one like you say. Wildfly subsystems are supposed to take care of their own
> migration as far as configuration goes. Most of the work of
> wildfly-server-migration tool, I believe, is to apply modules changes. Any
> configuration updates as reflected in standalone.xml are delegated to
> subsystems, and if they are not performed by migration tool, or
> automatically by subsystems during offline migration, they are performed
> automatically by subsystems the first time you start migrated Keycloak.
>
> So, I don't think we need to concern ourselves with Wildfly to Wildfly
> migration at all.
>
>
> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:
>
>> I'm working on rewriting server-config-migration tests. Currently there
>> is used wildfly-maven-plugin which does the migration in online mode,
>> I've redone this using exec plugin and the migration is done in offline
>> mode.
>>
>> My question is how do we should handle changes what are done to
>> standalone.xml (or standalone-ha.xml, etc.) between different versions
>> of wildfly. It is out of keycloak scope, but according to migration
>> guide [1], users are supposed to replace default version (current) of
>> config with previous version.
>>
>> As far as I was able to find out WF uses a tool [2] for migration. There
>> is not migration from WF10 to WF11.
>>
>> Should be it somehow incorporated into our migration scripts?
>>
>> If not then the migration guide should be updated with supported
>> migration steps.
>>
>> [1]
>> http://www.keycloak.org/docs/latest/server_admin/topics/
>> MigrationFromOlderVersions.html
>> [2] https://github.com/wildfly/wildfly-server-migration/releases
>> _______________________________________________
>> 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 mstrukel at redhat.com  Tue Oct 10 08:13:59 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 10 Oct 2017 14:13:59 +0200
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <df036383-1110-3c18-b343-9f81d3a4e0ba@redhat.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
	<CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
	<df036383-1110-3c18-b343-9f81d3a4e0ba@redhat.com>
Message-ID: <CA+1OW+jK3MWJ0Hs0J36otnT5==4V1C19RKXNV30bvc-EY_eL4Q@mail.gmail.com>

I see, that sounds like the right approach, yes.

On Oct 10, 2017 13:51, "Vlasta Ramik" <vramik at redhat.com> wrote:

> Thanks Marko,
> if I understand correctly changes performed within subsystems are handled
> by the subsystem itself during the first container start (at the latest).
> But changes like removing subsystem should be added as a command to our
> migration script, right?
>
> There is <subsystem xmlns="urn:jboss:domain:jdr:1.0"/> remained after
> migration (and after container start) on my env.
>
> If so, I'll add the command, if not a JIRA should be fired.
>
> On 10/10/2017 12:26 PM, Marko Strukelj wrote:
>
> I've been looking at server-config-migration tests a little so I have some
> thoughts on this.
>
> As a criteria - most elegant solution is for our migration scripts to
> perform the minimum necessary migration operations. I think we only target
> these scripts for keycloak server distribution - not overlay - thus we have
> full knowledge of what Wildfly version is underneath a specific Keycloak
> version, and we can add all the necessary .cli commands to address
> configuration changes due to Wildfly upgrade whould that be necessary. But,
> AFAICT no explicit Wildfly upgrade is necessary because it happens
> automatically in this scenario.
>
> Our migration scripts presume latest Keycloak (not Wildfly) installation.
> And what that means is that you already have all the underlying Wildfly
> updates in place (i.e. modules) because latest Keycloak distribution
> already contains them - except that you overwrite standalone.xml with old
> one like you say. Wildfly subsystems are supposed to take care of their own
> migration as far as configuration goes. Most of the work of
> wildfly-server-migration tool, I believe, is to apply modules changes. Any
> configuration updates as reflected in standalone.xml are delegated to
> subsystems, and if they are not performed by migration tool, or
> automatically by subsystems during offline migration, they are performed
> automatically by subsystems the first time you start migrated Keycloak.
>
> So, I don't think we need to concern ourselves with Wildfly to Wildfly
> migration at all.
>
>
> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:
>
>> I'm working on rewriting server-config-migration tests. Currently there
>> is used wildfly-maven-plugin which does the migration in online mode,
>> I've redone this using exec plugin and the migration is done in offline
>> mode.
>>
>> My question is how do we should handle changes what are done to
>> standalone.xml (or standalone-ha.xml, etc.) between different versions
>> of wildfly. It is out of keycloak scope, but according to migration
>> guide [1], users are supposed to replace default version (current) of
>> config with previous version.
>>
>> As far as I was able to find out WF uses a tool [2] for migration. There
>> is not migration from WF10 to WF11.
>>
>> Should be it somehow incorporated into our migration scripts?
>>
>> If not then the migration guide should be updated with supported
>> migration steps.
>>
>> [1]
>> http://www.keycloak.org/docs/latest/server_admin/topics/Migr
>> ationFromOlderVersions.html
>> [2] https://github.com/wildfly/wildfly-server-migration/releases
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From vramik at redhat.com  Tue Oct 10 08:30:26 2017
From: vramik at redhat.com (Vlasta Ramik)
Date: Tue, 10 Oct 2017 14:30:26 +0200
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <5eba238f-c718-5813-2bf8-9a3b2148a0ea@redhat.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
	<CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
	<5eba238f-c718-5813-2bf8-9a3b2148a0ea@redhat.com>
Message-ID: <61fd9612-de96-5eb3-e74e-458bdd34d0aa@redhat.com>

On 10/10/2017 01:57 PM, Stan Silvert wrote:
> I agree with Marko about WildFly to WildFly migration.  It would be
> possible for the migration scripts to check the WildFly version though.
> Maybe that should be added?
>
> Vlasta, the current migration test has an important overarching
> purpose.  That is, it can tell if someone changed the config files
> (standlone.xml, etc.) without updating the migration scripts.
How exactly is that done? There is comparison of master and migrated 
config and it fails if there is not match. Do you mean that or something 
else?
>
> I suspect that most developers on our team don't think about the
> migration scripts much (if they even know about them).  So it would be
> easy for migration to get out of sync with configs.  No matter what you
> do to the tests, please keep this sanity check intact.
>
> On 10/10/2017 6:26 AM, Marko Strukelj wrote:
>> I've been looking at server-config-migration tests a little so I have some
>> thoughts on this.
>>
>> As a criteria - most elegant solution is for our migration scripts to
>> perform the minimum necessary migration operations. I think we only target
>> these scripts for keycloak server distribution - not overlay - thus we have
>> full knowledge of what Wildfly version is underneath a specific Keycloak
>> version, and we can add all the necessary .cli commands to address
>> configuration changes due to Wildfly upgrade whould that be necessary. But,
>> AFAICT no explicit Wildfly upgrade is necessary because it happens
>> automatically in this scenario.
>>
>> Our migration scripts presume latest Keycloak (not Wildfly) installation.
>> And what that means is that you already have all the underlying Wildfly
>> updates in place (i.e. modules) because latest Keycloak distribution
>> already contains them - except that you overwrite standalone.xml with old
>> one like you say. Wildfly subsystems are supposed to take care of their own
>> migration as far as configuration goes. Most of the work of
>> wildfly-server-migration tool, I believe, is to apply modules changes. Any
>> configuration updates as reflected in standalone.xml are delegated to
>> subsystems, and if they are not performed by migration tool, or
>> automatically by subsystems during offline migration, they are performed
>> automatically by subsystems the first time you start migrated Keycloak.
>>
>> So, I don't think we need to concern ourselves with Wildfly to Wildfly
>> migration at all.
>>
>>
>> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:
>>
>>> I'm working on rewriting server-config-migration tests. Currently there
>>> is used wildfly-maven-plugin which does the migration in online mode,
>>> I've redone this using exec plugin and the migration is done in offline
>>> mode.
>>>
>>> My question is how do we should handle changes what are done to
>>> standalone.xml (or standalone-ha.xml, etc.) between different versions
>>> of wildfly. It is out of keycloak scope, but according to migration
>>> guide [1], users are supposed to replace default version (current) of
>>> config with previous version.
>>>
>>> As far as I was able to find out WF uses a tool [2] for migration. There
>>> is not migration from WF10 to WF11.
>>>
>>> Should be it somehow incorporated into our migration scripts?
>>>
>>> If not then the migration guide should be updated with supported
>>> migration steps.
>>>
>>> [1]
>>> http://www.keycloak.org/docs/latest/server_admin/topics/
>>> MigrationFromOlderVersions.html
>>> [2] https://github.com/wildfly/wildfly-server-migration/releases
>>> _______________________________________________
>>> 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 bburke at redhat.com  Tue Oct 10 10:19:29 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 10 Oct 2017 10:19:29 -0400
Subject: [keycloak-dev] Keycloak and Kubernetes
Message-ID: <CABRXCmy0CPPnaLGrU_sivEGuV71YqUs56Vr_dB2nER3=5BCm9Q@mail.gmail.com>

I believe there will be two distinct integration points of Keycloak
with Kubernetes.

* Kubernetes relies on Keycloak for authentication and even authorization
* Keycloak is offered as a Kubernetes services for appliations and users to use

These should be 2 distinct use cases.

-- 
Bill Burke
Red Hat

From ssilvert at redhat.com  Tue Oct 10 12:39:27 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 10 Oct 2017 12:39:27 -0400
Subject: [keycloak-dev] server-config-migration
In-Reply-To: <61fd9612-de96-5eb3-e74e-458bdd34d0aa@redhat.com>
References: <b650ed60-0dc4-27b3-44e0-799e66734d35@redhat.com>
	<CA+1OW+gGw7J5uNwTPALD2mC2k0o2BHDZWzFn7c7LNmHLUKphvA@mail.gmail.com>
	<5eba238f-c718-5813-2bf8-9a3b2148a0ea@redhat.com>
	<61fd9612-de96-5eb3-e74e-458bdd34d0aa@redhat.com>
Message-ID: <1e9033b6-985c-25ac-1637-813df7e4ea29@redhat.com>

On 10/10/2017 8:30 AM, Vlasta Ramik wrote:
> On 10/10/2017 01:57 PM, Stan Silvert wrote:
>> I agree with Marko about WildFly to WildFly migration.  It would be
>> possible for the migration scripts to check the WildFly version though.
>> Maybe that should be added?
>>
>> Vlasta, the current migration test has an important overarching
>> purpose.  That is, it can tell if someone changed the config files
>> (standlone.xml, etc.) without updating the migration scripts.
> How exactly is that done? There is comparison of master and migrated
> config and it fails if there is not match. Do you mean that or something
> else?
Yes, that's what I'm talking about.  A migrated standalone.xml should 
match the standalone.xml that ships with the latest Keycloak.   The test 
we have now does that comparison for standalone.xml, standalone-ha.xml, 
and domain.xml.  So if anybody changes the config without changing the 
migration script it will fail.
>> I suspect that most developers on our team don't think about the
>> migration scripts much (if they even know about them).  So it would be
>> easy for migration to get out of sync with configs.  No matter what you
>> do to the tests, please keep this sanity check intact.
>>
>> On 10/10/2017 6:26 AM, Marko Strukelj wrote:
>>> I've been looking at server-config-migration tests a little so I have some
>>> thoughts on this.
>>>
>>> As a criteria - most elegant solution is for our migration scripts to
>>> perform the minimum necessary migration operations. I think we only target
>>> these scripts for keycloak server distribution - not overlay - thus we have
>>> full knowledge of what Wildfly version is underneath a specific Keycloak
>>> version, and we can add all the necessary .cli commands to address
>>> configuration changes due to Wildfly upgrade whould that be necessary. But,
>>> AFAICT no explicit Wildfly upgrade is necessary because it happens
>>> automatically in this scenario.
>>>
>>> Our migration scripts presume latest Keycloak (not Wildfly) installation.
>>> And what that means is that you already have all the underlying Wildfly
>>> updates in place (i.e. modules) because latest Keycloak distribution
>>> already contains them - except that you overwrite standalone.xml with old
>>> one like you say. Wildfly subsystems are supposed to take care of their own
>>> migration as far as configuration goes. Most of the work of
>>> wildfly-server-migration tool, I believe, is to apply modules changes. Any
>>> configuration updates as reflected in standalone.xml are delegated to
>>> subsystems, and if they are not performed by migration tool, or
>>> automatically by subsystems during offline migration, they are performed
>>> automatically by subsystems the first time you start migrated Keycloak.
>>>
>>> So, I don't think we need to concern ourselves with Wildfly to Wildfly
>>> migration at all.
>>>
>>>
>>> On Tue, Oct 10, 2017 at 10:44 AM, Vlasta Ramik <vramik at redhat.com> wrote:
>>>
>>>> I'm working on rewriting server-config-migration tests. Currently there
>>>> is used wildfly-maven-plugin which does the migration in online mode,
>>>> I've redone this using exec plugin and the migration is done in offline
>>>> mode.
>>>>
>>>> My question is how do we should handle changes what are done to
>>>> standalone.xml (or standalone-ha.xml, etc.) between different versions
>>>> of wildfly. It is out of keycloak scope, but according to migration
>>>> guide [1], users are supposed to replace default version (current) of
>>>> config with previous version.
>>>>
>>>> As far as I was able to find out WF uses a tool [2] for migration. There
>>>> is not migration from WF10 to WF11.
>>>>
>>>> Should be it somehow incorporated into our migration scripts?
>>>>
>>>> If not then the migration guide should be updated with supported
>>>> migration steps.
>>>>
>>>> [1]
>>>> http://www.keycloak.org/docs/latest/server_admin/topics/
>>>> MigrationFromOlderVersions.html
>>>> [2] https://github.com/wildfly/wildfly-server-migration/releases
>>>> _______________________________________________
>>>> 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 bdawidow at redhat.com  Tue Oct 10 13:43:13 2017
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 10 Oct 2017 17:43:13 +0000
Subject: [keycloak-dev] Keycloak and Kubernetes
In-Reply-To: <CABRXCmy0CPPnaLGrU_sivEGuV71YqUs56Vr_dB2nER3=5BCm9Q@mail.gmail.com>
References: <CABRXCmy0CPPnaLGrU_sivEGuV71YqUs56Vr_dB2nER3=5BCm9Q@mail.gmail.com>
Message-ID: <CABbwURFaVK9PJbZCx_0BTo7Rsc-WqBe01K+07p-w9uc+GYZEOA@mail.gmail.com>

The first one is wider though. Kubernetes using Keycloak as OAuth2 provider
or delegating to external Keycloak instance like in case of OpenShift right
now.

On Tue, Oct 10, 2017 at 5:46 PM Bill Burke <bburke at redhat.com> wrote:

> I believe there will be two distinct integration points of Keycloak
> with Kubernetes.
>
> * Kubernetes relies on Keycloak for authentication and even authorization
> * Keycloak is offered as a Kubernetes services for appliations and users
> to use
>
> These should be 2 distinct use cases.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Tue Oct 10 21:38:57 2017
From: bburke at redhat.com (Bill Burke)
Date: Tue, 10 Oct 2017 21:38:57 -0400
Subject: [keycloak-dev] master failing build?
Message-ID: <CABRXCmzYJ_QOq79AykjO-3yTJtRqTr_4_HPZdtJKLhvV6kwgHw@mail.gmail.com>

I pulled latest in fresh copy of master and a ton of tests are
failing.  I'll take a look tomorrow if Europeans don't get there
first.

-- 
Bill Burke
Red Hat

From ksagathi at redhat.com  Wed Oct 11 07:10:05 2017
From: ksagathi at redhat.com (Kishan Sagathiya)
Date: Wed, 11 Oct 2017 16:40:05 +0530
Subject: [keycloak-dev] 405 on importing a realm
Message-ID: <CADbX+RXShaAJpQ2GDtTdap1+kvtT5QSGjoo2XP3day0U6LXuvg@mail.gmail.com>

Hi,
I am getting '405 Method Not Allowed'  on trying to create a realm using
keycloak's admin rest api.

Following is the command that I am running


curl -H "Content-Type: application/json" -H "Authorization: bearer
$ACCESS_TOKEN" -d 'rep=$CONTENT_OF_THE_JSONFILE' -D- -X POST  "
http://mykeycloakurl.com/auth/admin/realms/master"

Is this the right way?

From thomas.darimont at googlemail.com  Wed Oct 11 08:26:06 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Wed, 11 Oct 2017 14:26:06 +0200
Subject: [keycloak-dev] Flexible HTTP Proxy support for HttpClientProvider
Message-ID: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>

Hello,

I've sent a PR [1] for KEYCLOAK-4743 [2] Add proxy support to
HttpClientProvider SPI.
The proposed implementation is based on the discussions from an older
(rejected) PR [3]

The current DefaultHttpClientProviderFactory doesn't support HTTP proxies
which makes
it very difficult to integrate social Identity Providers like google /
facebook etc...
when you are required to tunnel all external communications though a proxy
server.

Server Developers are currently required to either convince their network
admins to
loosen the proxy rules ... or provide a custom implementation of a
HttpClientProvider,
which is quite complex. Therefore it would be great if keycloak would add
support
for this out of the box.

Since keycloak needs to be able to selectively use a (dedicated) proxy
server
for external and potentially no proxy for internal connections the
configuration
for that needs to be quite flexible.

The current PR proposes to use an ordered list of proxymappings that match
a http request host based on a regex pattern to a proxy uri which are
processed
by a new ProxyMappingsAwareRoutePlanner that is added to the internal
HttpClient.

A ProxyMapping has the form hostname-pattern;proxy-uri e.g.:

      .*\.(google|googleapis)\.com;http://www-proxy.acme.corp.com:8080
      .*\.acme\.corp\.com;NO_PROXY
      .*;http://fallback:8080

(the catch all is optional)
The first matching mapping defines the proxy to use. If no pattern matches
then no proxy is used. One can also explicity define that certain
connections should
not use a proxy.

... and can be configured via jboss-cli

  echo SETUP: Configure proxy routes for HttpClient SPI

/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:add(enabled=true)

/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:write-attribute(name=properties.proxy-mappings,value=[".*\\.(google|googleapis)\\.com;
http://www-proxy.acme.corp.com:8080",".*\\.acme\\.corp\\.com;NO_PROXY",".*;
http://fallback:8080"])

This can be tested as follows:
1) Apply the PR in branch, build a server distribution.
2) Start Keycloak with portOffset 10000 for http/https/ajp port.
Configure the ProxyMappings in standalone.xml:
via jboss-cli:
  echo SETUP: Configure proxy routes for HttpClient SPI

/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:add(enabled=true)

/subsystem=keycloak-server/spi=connectionsHttpClient/provider=default:write-attribute(name=properties.proxy-mappings,value=[".*\\.(google|googleapis)\\.com;
http://localhost:8080"])

3) Download and start BurpSuite [4]
4) By default burpsuite starts a proxy server on port 8080
5) Register google as auth provider and check entries in burp proxy log
   (Note that you potentially need to explicitly forward the request in the
proxy tab in Burp)

WDYT?

Cheers,
Thomas

[1] https://github.com/keycloak/keycloak/pull/4543
[2] https://issues.jboss.org/browse/KEYCLOAK-4743
[3] https://github.com/keycloak/keycloak/pull/4040
[4] https://portswigger.net/burp/help/suite_gettingstarted.html

From bburke at redhat.com  Wed Oct 11 10:27:30 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 10:27:30 -0400
Subject: [keycloak-dev] Keycloak proxy written in Go
Message-ID: <CABRXCmynUenSqVX+wKXT62cBvCXgNPkUZJK4yH-WjFTB_jRyAg@mail.gmail.com>

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


-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 14:55:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 14:55:49 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
Message-ID: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>

I still can't figure out why my build isn't running.  I cloned fresh
from master and RequiredActionEmailVerificationTest is failing (I
think) when sending any email.  I get read timeout errors on login
submit, but no other errors.

Anybody else seeing failures in RequiredActionEmailVerificationTests?

-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 15:09:38 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 15:09:38 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
Message-ID: <CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>

I'm getting connection errors to GreenMail...Don't get it...I can
telnet to the host/port

On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
> I still can't figure out why my build isn't running.  I cloned fresh
> from master and RequiredActionEmailVerificationTest is failing (I
> think) when sending any email.  I get read timeout errors on login
> submit, but no other errors.
>
> Anybody else seeing failures in RequiredActionEmailVerificationTests?
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From abhi.raghav007 at gmail.com  Wed Oct 11 16:12:38 2017
From: abhi.raghav007 at gmail.com (abhishek raghav)
Date: Thu, 12 Oct 2017 01:42:38 +0530
Subject: [keycloak-dev] Keycloak proxy written in Go
In-Reply-To: <CABRXCmynUenSqVX+wKXT62cBvCXgNPkUZJK4yH-WjFTB_jRyAg@mail.gmail.com>
References: <CABRXCmynUenSqVX+wKXT62cBvCXgNPkUZJK4yH-WjFTB_jRyAg@mail.gmail.com>
Message-ID: <CAJmz6fuTj5yD1=wNzmEncY1zCsDAXmp+62UXEaBCFxL8uGziaQ@mail.gmail.com>

Hi Bill,


We have been trying to look for a set-up keycloak proxy, but it seems to be
breaking. We had problem understanding how logout works in keycloak proxy
and we run into issues clearing the local keycloak proxy cookie on browser
when the openidc logout is called.

Now we are trying to migrate on to mod_auth_openidc, In your opinion which
one should be a better to go it among the *Go-Keycloak proxy  or
mod_auth_openidc in terms *performance, security *and* interoperability with
keycloak.*

Looking forward to some valuable inputs from you.

Thanks.

Cheers
Abhishek Raghav







On Wed, Oct 11, 2017 at 7:57 PM, Bill Burke <bburke at redhat.com> wrote:

> https://github.com/gambol99/keycloak-proxy
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From hmlnarik at redhat.com  Wed Oct 11 16:19:39 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Wed, 11 Oct 2017 22:19:39 +0200
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
Message-ID: <CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>

Just checked, the RequiredActionEmailVerificationTest works for me, all
tests passed. Is it possible that GreenMail does not start fast enough? Do
all tests fail or only few of them at the beginning?

--Hynek

On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:

> I'm getting connection errors to GreenMail...Don't get it...I can
> telnet to the host/port
>
> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
> > I still can't figure out why my build isn't running.  I cloned fresh
> > from master and RequiredActionEmailVerificationTest is failing (I
> > think) when sending any email.  I get read timeout errors on login
> > submit, but no other errors.
> >
> > Anybody else seeing failures in RequiredActionEmailVerificationTests?
> >
> > --
> > Bill Burke
> > Red Hat
>
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--Hynek

From bburke at redhat.com  Wed Oct 11 17:41:23 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 17:41:23 -0400
Subject: [keycloak-dev] Keycloak proxy written in Go
In-Reply-To: <CAJmz6fuTj5yD1=wNzmEncY1zCsDAXmp+62UXEaBCFxL8uGziaQ@mail.gmail.com>
References: <CABRXCmynUenSqVX+wKXT62cBvCXgNPkUZJK4yH-WjFTB_jRyAg@mail.gmail.com>
	<CAJmz6fuTj5yD1=wNzmEncY1zCsDAXmp+62UXEaBCFxL8uGziaQ@mail.gmail.com>
Message-ID: <CABRXCmzGThTSwzHVV3p=ULKgW61gjXQi24Z_OeY5LbNEf+ZSPw@mail.gmail.com>

The GO proxy is something that somebody on the internet created (When
I googles "Keycloak proxy".  Just found it today and it looks good,
but haven't tried it out.  We're looking to put effort into some kind
of proxy going forward.  In planning stages now.  As far as
mod_auth_openidc, I don't have experience with it or how well it works
with logout.

On Wed, Oct 11, 2017 at 4:12 PM, abhishek raghav
<abhi.raghav007 at gmail.com> wrote:
> Hi Bill,
>
>
> We have been trying to look for a set-up keycloak proxy, but it seems to be
> breaking. We had problem understanding how logout works in keycloak proxy
> and we run into issues clearing the local keycloak proxy cookie on browser
> when the openidc logout is called.
>
> Now we are trying to migrate on to mod_auth_openidc, In your opinion which
> one should be a better to go it among the *Go-Keycloak proxy  or
> mod_auth_openidc in terms performance, security and interoperability with
> keycloak.
>
> Looking forward to some valuable inputs from you.
>
> Thanks.
>
> Cheers
> Abhishek Raghav
>
>
>
>
>
>
>
> On Wed, Oct 11, 2017 at 7:57 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> https://github.com/gambol99/keycloak-proxy
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 17:42:43 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 17:42:43 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
Message-ID: <CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>

Seems any test using GreenMail fails for me.  I tried changing
host/port and everything.  I'll put in a sleep and see if that helps.

On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
> Just checked, the RequiredActionEmailVerificationTest works for me, all
> tests passed. Is it possible that GreenMail does not start fast enough? Do
> all tests fail or only few of them at the beginning?
>
> --Hynek
>
> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> I'm getting connection errors to GreenMail...Don't get it...I can
>> telnet to the host/port
>>
>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
>> > I still can't figure out why my build isn't running.  I cloned fresh
>> > from master and RequiredActionEmailVerificationTest is failing (I
>> > think) when sending any email.  I get read timeout errors on login
>> > submit, but no other errors.
>> >
>> > Anybody else seeing failures in RequiredActionEmailVerificationTests?
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> --
>
> --Hynek



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 17:59:49 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 17:59:49 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
Message-ID: <CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>

Its really weird...I put a sleep at the beginning of the test.  I can
telnet to Greenmail (localhost 3025) and Greenmail will respond with
error message if I type random stuff in.  But I get connection errors
on test.  Doesn't make sense.

On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
> Seems any test using GreenMail fails for me.  I tried changing
> host/port and everything.  I'll put in a sleep and see if that helps.
>
> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>> Just checked, the RequiredActionEmailVerificationTest works for me, all
>> tests passed. Is it possible that GreenMail does not start fast enough? Do
>> all tests fail or only few of them at the beginning?
>>
>> --Hynek
>>
>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>>
>>> I'm getting connection errors to GreenMail...Don't get it...I can
>>> telnet to the host/port
>>>
>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>> > I still can't figure out why my build isn't running.  I cloned fresh
>>> > from master and RequiredActionEmailVerificationTest is failing (I
>>> > think) when sending any email.  I get read timeout errors on login
>>> > submit, but no other errors.
>>> >
>>> > Anybody else seeing failures in RequiredActionEmailVerificationTests?
>>> >
>>> > --
>>> > Bill Burke
>>> > Red Hat
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> --
>>
>> --Hynek
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 18:03:22 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 18:03:22 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
Message-ID: <CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>

Caused by: javax.mail.MessagingException: Could not connect to SMTP
host: localhost, port: 3025, response: -1

On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
> Its really weird...I put a sleep at the beginning of the test.  I can
> telnet to Greenmail (localhost 3025) and Greenmail will respond with
> error message if I type random stuff in.  But I get connection errors
> on test.  Doesn't make sense.
>
> On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
>> Seems any test using GreenMail fails for me.  I tried changing
>> host/port and everything.  I'll put in a sleep and see if that helps.
>>
>> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>> Just checked, the RequiredActionEmailVerificationTest works for me, all
>>> tests passed. Is it possible that GreenMail does not start fast enough? Do
>>> all tests fail or only few of them at the beginning?
>>>
>>> --Hynek
>>>
>>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>> I'm getting connection errors to GreenMail...Don't get it...I can
>>>> telnet to the host/port
>>>>
>>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>>> > I still can't figure out why my build isn't running.  I cloned fresh
>>>> > from master and RequiredActionEmailVerificationTest is failing (I
>>>> > think) when sending any email.  I get read timeout errors on login
>>>> > submit, but no other errors.
>>>> >
>>>> > Anybody else seeing failures in RequiredActionEmailVerificationTests?
>>>> >
>>>> > --
>>>> > Bill Burke
>>>> > Red Hat
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --Hynek
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From bburke at redhat.com  Wed Oct 11 21:42:05 2017
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Oct 2017 21:42:05 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
Message-ID: <CABRXCmy+7DEX+B--yfSpzwkKcgxKFJkLr-pPBAz=sL0a7QOzxQ@mail.gmail.com>

Gotta be my laptop...checked out 3.3 branch and I'm still getting the problem.

On Wed, Oct 11, 2017 at 6:03 PM, Bill Burke <bburke at redhat.com> wrote:
> Caused by: javax.mail.MessagingException: Could not connect to SMTP
> host: localhost, port: 3025, response: -1
>
> On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
>> Its really weird...I put a sleep at the beginning of the test.  I can
>> telnet to Greenmail (localhost 3025) and Greenmail will respond with
>> error message if I type random stuff in.  But I get connection errors
>> on test.  Doesn't make sense.
>>
>> On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
>>> Seems any test using GreenMail fails for me.  I tried changing
>>> host/port and everything.  I'll put in a sleep and see if that helps.
>>>
>>> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>>> Just checked, the RequiredActionEmailVerificationTest works for me, all
>>>> tests passed. Is it possible that GreenMail does not start fast enough? Do
>>>> all tests fail or only few of them at the beginning?
>>>>
>>>> --Hynek
>>>>
>>>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>> I'm getting connection errors to GreenMail...Don't get it...I can
>>>>> telnet to the host/port
>>>>>
>>>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>> > I still can't figure out why my build isn't running.  I cloned fresh
>>>>> > from master and RequiredActionEmailVerificationTest is failing (I
>>>>> > think) when sending any email.  I get read timeout errors on login
>>>>> > submit, but no other errors.
>>>>> >
>>>>> > Anybody else seeing failures in RequiredActionEmailVerificationTests?
>>>>> >
>>>>> > --
>>>>> > Bill Burke
>>>>> > Red Hat
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> Red Hat
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> --Hynek
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>
>
> --
> Bill Burke
> Red Hat



-- 
Bill Burke
Red Hat

From mposolda at redhat.com  Thu Oct 12 02:50:48 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 12 Oct 2017 08:50:48 +0200
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmy+7DEX+B--yfSpzwkKcgxKFJkLr-pPBAz=sL0a7QOzxQ@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CABRXCmy+7DEX+B--yfSpzwkKcgxKFJkLr-pPBAz=sL0a7QOzxQ@mail.gmail.com>
Message-ID: <d343392a-feeb-d493-0fde-9d8f4def25ad@redhat.com>

Test works here too. And in travis as well.

Strange that telnet works, but Java not. Maybe there is some strange 
security settings in your JVM itself, which refuse to connect to port 
3025? Maybe I would try with different JVM? Or try some easy 
socket-connect helloWorld program written in Java if it successfully 
connects to localhost:3025?

Marek

On 12/10/17 03:42, Bill Burke wrote:
> Gotta be my laptop...checked out 3.3 branch and I'm still getting the problem.
>
> On Wed, Oct 11, 2017 at 6:03 PM, Bill Burke <bburke at redhat.com> wrote:
>> Caused by: javax.mail.MessagingException: Could not connect to SMTP
>> host: localhost, port: 3025, response: -1
>>
>> On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
>>> Its really weird...I put a sleep at the beginning of the test.  I can
>>> telnet to Greenmail (localhost 3025) and Greenmail will respond with
>>> error message if I type random stuff in.  But I get connection errors
>>> on test.  Doesn't make sense.
>>>
>>> On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
>>>> Seems any test using GreenMail fails for me.  I tried changing
>>>> host/port and everything.  I'll put in a sleep and see if that helps.
>>>>
>>>> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>>>> Just checked, the RequiredActionEmailVerificationTest works for me, all
>>>>> tests passed. Is it possible that GreenMail does not start fast enough? Do
>>>>> all tests fail or only few of them at the beginning?
>>>>>
>>>>> --Hynek
>>>>>
>>>>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>> I'm getting connection errors to GreenMail...Don't get it...I can
>>>>>> telnet to the host/port
>>>>>>
>>>>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>>> I still can't figure out why my build isn't running.  I cloned fresh
>>>>>>> from master and RequiredActionEmailVerificationTest is failing (I
>>>>>>> think) when sending any email.  I get read timeout errors on login
>>>>>>> submit, but no other errors.
>>>>>>>
>>>>>>> Anybody else seeing failures in RequiredActionEmailVerificationTests?
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> Red Hat
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> Red Hat
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> --Hynek
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> Red Hat
>>>
>>>
>>> --
>>> Bill Burke
>>> Red Hat
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>


From Joze.Mlakar at ixtlan-team.si  Thu Oct 12 03:29:10 2017
From: Joze.Mlakar at ixtlan-team.si (=?iso-8859-2?Q?Jo=BEe_Mlakar?=)
Date: Thu, 12 Oct 2017 07:29:10 +0000
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <d343392a-feeb-d493-0fde-9d8f4def25ad@redhat.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CABRXCmy+7DEX+B--yfSpzwkKcgxKFJkLr-pPBAz=sL0a7QOzxQ@mail.gmail.com>
	<d343392a-feeb-d493-0fde-9d8f4def25ad@redhat.com>
Message-ID: <d48ce6559b534a7d91fcb09d60072088@NETIX.ixtlan-team.si>

IPV6 maybe? Try ip 127.0.0.1 instead of localhost.


From hmlnarik at redhat.com  Thu Oct 12 04:33:10 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 12 Oct 2017 10:33:10 +0200
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
Message-ID: <CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>

GreenMail seems to start, otherwise it would be "java.net.ConnectException:
Connection refused" rather than "response: -1". This error seems to come
out of SMTP client. Can you set up logging of JavaMail in by adding
            session.setDebug(true);
to DefaultEmailSenderProvider, that might give some hint on what's wrong.

[1] https://javaee.github.io/javamail/FAQ#debug

On Thu, Oct 12, 2017 at 12:03 AM, Bill Burke <bburke at redhat.com> wrote:

> Caused by: javax.mail.MessagingException: Could not connect to SMTP
> host: localhost, port: 3025, response: -1
>
> On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
> > Its really weird...I put a sleep at the beginning of the test.  I can
> > telnet to Greenmail (localhost 3025) and Greenmail will respond with
> > error message if I type random stuff in.  But I get connection errors
> > on test.  Doesn't make sense.
> >
> > On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
> >> Seems any test using GreenMail fails for me.  I tried changing
> >> host/port and everything.  I'll put in a sleep and see if that helps.
> >>
> >> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
> >>> Just checked, the RequiredActionEmailVerificationTest works for me,
> all
> >>> tests passed. Is it possible that GreenMail does not start fast
> enough? Do
> >>> all tests fail or only few of them at the beginning?
> >>>
> >>> --Hynek
> >>>
> >>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com> wrote:
> >>>>
> >>>> I'm getting connection errors to GreenMail...Don't get it...I can
> >>>> telnet to the host/port
> >>>>
> >>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >>>> > I still can't figure out why my build isn't running.  I cloned fresh
> >>>> > from master and RequiredActionEmailVerificationTest is failing (I
> >>>> > think) when sending any email.  I get read timeout errors on login
> >>>> > submit, but no other errors.
> >>>> >
> >>>> > Anybody else seeing failures in RequiredActionEmailVerificatio
> nTests?
> >>>> >
> >>>> > --
> >>>> > Bill Burke
> >>>> > Red Hat
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> Red Hat
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> --Hynek
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
>
>
>
> --
> Bill Burke
> Red Hat
>



-- 

--Hynek

From mstrukel at redhat.com  Thu Oct 12 04:52:55 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 12 Oct 2017 10:52:55 +0200
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>
Message-ID: <CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>

This sounds very familiar to the issue I had some time ago, that was only
failing for me on macOS.

See: https://issues.jboss.org/browse/KEYCLOAK-4278

and https://github.com/keycloak/keycloak/pull/3944#issuecomment-297535534

On Thu, Oct 12, 2017 at 10:33 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:

> GreenMail seems to start, otherwise it would be "java.net.ConnectException:
> Connection refused" rather than "response: -1". This error seems to come
> out of SMTP client. Can you set up logging of JavaMail in by adding
>             session.setDebug(true);
> to DefaultEmailSenderProvider, that might give some hint on what's wrong.
>
> [1] https://javaee.github.io/javamail/FAQ#debug
>
> On Thu, Oct 12, 2017 at 12:03 AM, Bill Burke <bburke at redhat.com> wrote:
>
> > Caused by: javax.mail.MessagingException: Could not connect to SMTP
> > host: localhost, port: 3025, response: -1
> >
> > On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
> > > Its really weird...I put a sleep at the beginning of the test.  I can
> > > telnet to Greenmail (localhost 3025) and Greenmail will respond with
> > > error message if I type random stuff in.  But I get connection errors
> > > on test.  Doesn't make sense.
> > >
> > > On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
> > >> Seems any test using GreenMail fails for me.  I tried changing
> > >> host/port and everything.  I'll put in a sleep and see if that helps.
> > >>
> > >> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com>
> > wrote:
> > >>> Just checked, the RequiredActionEmailVerificationTest works for me,
> > all
> > >>> tests passed. Is it possible that GreenMail does not start fast
> > enough? Do
> > >>> all tests fail or only few of them at the beginning?
> > >>>
> > >>> --Hynek
> > >>>
> > >>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com>
> wrote:
> > >>>>
> > >>>> I'm getting connection errors to GreenMail...Don't get it...I can
> > >>>> telnet to the host/port
> > >>>>
> > >>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com>
> > wrote:
> > >>>> > I still can't figure out why my build isn't running.  I cloned
> fresh
> > >>>> > from master and RequiredActionEmailVerificationTest is failing (I
> > >>>> > think) when sending any email.  I get read timeout errors on login
> > >>>> > submit, but no other errors.
> > >>>> >
> > >>>> > Anybody else seeing failures in RequiredActionEmailVerificatio
> > nTests?
> > >>>> >
> > >>>> > --
> > >>>> > Bill Burke
> > >>>> > Red Hat
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Bill Burke
> > >>>> Red Hat
> > >>>> _______________________________________________
> > >>>> keycloak-dev mailing list
> > >>>> keycloak-dev at lists.jboss.org
> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> --Hynek
> > >>
> > >>
> > >>
> > >> --
> > >> Bill Burke
> > >> Red Hat
> > >
> > >
> > >
> > > --
> > > Bill Burke
> > > Red Hat
> >
> >
> >
> > --
> > Bill Burke
> > Red Hat
> >
>
>
>
> --
>
> --Hynek
> _______________________________________________
> 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 12 04:53:29 2017
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 12 Oct 2017 10:53:29 +0200
Subject: [keycloak-dev] Keycloak proxy written in Go
In-Reply-To: <CABRXCmzGThTSwzHVV3p=ULKgW61gjXQi24Z_OeY5LbNEf+ZSPw@mail.gmail.com>
References: <CABRXCmynUenSqVX+wKXT62cBvCXgNPkUZJK4yH-WjFTB_jRyAg@mail.gmail.com>
	<CAJmz6fuTj5yD1=wNzmEncY1zCsDAXmp+62UXEaBCFxL8uGziaQ@mail.gmail.com>
	<CABRXCmzGThTSwzHVV3p=ULKgW61gjXQi24Z_OeY5LbNEf+ZSPw@mail.gmail.com>
Message-ID: <CAMZCGg-QytP2Wd-BQX5OTZuZ5MbyjAXhC4AaLRDSdp-Vp9y86Q@mail.gmail.com>

On Wed, Oct 11, 2017 at 11:41 PM, Bill Burke <bburke at redhat.com> wrote:

> The GO proxy is something that somebody on the internet created (When
> I googles "Keycloak proxy".  Just found it today and it looks good,
> but haven't tried it out.


Yeah , haven't tried it yet but it looks like solid stuff and it's very
well documented.
I wonder if some pieces of this couldn't be used for the istio integration
as well (since the wrapper modules around the "proxy/side-car" are written
in Go).

We're looking to put effort into some kind
> of proxy going forward.  In planning stages now.  As far as
> mod_auth_openidc, I don't have experience with it or how well it works
> with logout.
>
> On Wed, Oct 11, 2017 at 4:12 PM, abhishek raghav
> <abhi.raghav007 at gmail.com> wrote:
> > Hi Bill,
> >
> >
> > We have been trying to look for a set-up keycloak proxy, but it seems to
> be
> > breaking. We had problem understanding how logout works in keycloak proxy
> > and we run into issues clearing the local keycloak proxy cookie on
> browser
> > when the openidc logout is called.
> >
> > Now we are trying to migrate on to mod_auth_openidc, In your opinion
> which
> > one should be a better to go it among the *Go-Keycloak proxy  or
> > mod_auth_openidc in terms performance, security and interoperability with
> > keycloak.
> >
> > Looking forward to some valuable inputs from you.
> >
> > Thanks.
> >
> > Cheers
> > Abhishek Raghav
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Oct 11, 2017 at 7:57 PM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> https://github.com/gambol99/keycloak-proxy
> >>
> >>
> >> --
> >> Bill Burke
> >> Red Hat
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Thu Oct 12 05:14:59 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 12 Oct 2017 09:14:59 +0000
Subject: [keycloak-dev] master failing build?
In-Reply-To: <CABRXCmzYJ_QOq79AykjO-3yTJtRqTr_4_HPZdtJKLhvV6kwgHw@mail.gmail.com>
References: <CABRXCmzYJ_QOq79AykjO-3yTJtRqTr_4_HPZdtJKLhvV6kwgHw@mail.gmail.com>
Message-ID: <CAM5SUC4QgXBQYybJKLdbGMFNo81wC_kL8AgtLzYjQNgTjCd3Hg@mail.gmail.com>

I'm not sure if that's the case, but I found this
https://stackoverflow.com/questions/14064111/java-mail-mystery-smtp-blocked

On Tue, Oct 10, 2017 at 10:39 PM Bill Burke <bburke at redhat.com> wrote:

> I pulled latest in fresh copy of master and a ton of tests are
> failing.  I'll take a look tomorrow if Europeans don't get there
> first.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Thu Oct 12 05:17:59 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 12 Oct 2017 09:17:59 +0000
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>
	<CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>
Message-ID: <CAM5SUC6OvxHt3LuhMZy6kWZqPXEmm=Z+Enq_GzrP8XtuJstQMA@mail.gmail.com>

Sorry, replied in the wrong thread.

I'm not sure if that's the case, but I found this
https://stackoverflow.com/questions/14064111/java-mail-mystery-smtp-blocked

On Thu, Oct 12, 2017 at 5:52 AM Marko Strukelj <mstrukel at redhat.com> wrote:

> This sounds very familiar to the issue I had some time ago, that was only
> failing for me on macOS.
>
> See: https://issues.jboss.org/browse/KEYCLOAK-4278
>
> and https://github.com/keycloak/keycloak/pull/3944#issuecomment-297535534
>
> On Thu, Oct 12, 2017 at 10:33 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
>
> > GreenMail seems to start, otherwise it would be
> "java.net.ConnectException:
> > Connection refused" rather than "response: -1". This error seems to come
> > out of SMTP client. Can you set up logging of JavaMail in by adding
> >             session.setDebug(true);
> > to DefaultEmailSenderProvider, that might give some hint on what's wrong.
> >
> > [1] https://javaee.github.io/javamail/FAQ#debug
> >
> > On Thu, Oct 12, 2017 at 12:03 AM, Bill Burke <bburke at redhat.com> wrote:
> >
> > > Caused by: javax.mail.MessagingException: Could not connect to SMTP
> > > host: localhost, port: 3025, response: -1
> > >
> > > On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
> > > > Its really weird...I put a sleep at the beginning of the test.  I can
> > > > telnet to Greenmail (localhost 3025) and Greenmail will respond with
> > > > error message if I type random stuff in.  But I get connection errors
> > > > on test.  Doesn't make sense.
> > > >
> > > > On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com>
> wrote:
> > > >> Seems any test using GreenMail fails for me.  I tried changing
> > > >> host/port and everything.  I'll put in a sleep and see if that
> helps.
> > > >>
> > > >> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com
> >
> > > wrote:
> > > >>> Just checked, the RequiredActionEmailVerificationTest works for me,
> > > all
> > > >>> tests passed. Is it possible that GreenMail does not start fast
> > > enough? Do
> > > >>> all tests fail or only few of them at the beginning?
> > > >>>
> > > >>> --Hynek
> > > >>>
> > > >>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com>
> > wrote:
> > > >>>>
> > > >>>> I'm getting connection errors to GreenMail...Don't get it...I can
> > > >>>> telnet to the host/port
> > > >>>>
> > > >>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com>
> > > wrote:
> > > >>>> > I still can't figure out why my build isn't running.  I cloned
> > fresh
> > > >>>> > from master and RequiredActionEmailVerificationTest is failing
> (I
> > > >>>> > think) when sending any email.  I get read timeout errors on
> login
> > > >>>> > submit, but no other errors.
> > > >>>> >
> > > >>>> > Anybody else seeing failures in RequiredActionEmailVerificatio
> > > nTests?
> > > >>>> >
> > > >>>> > --
> > > >>>> > Bill Burke
> > > >>>> > Red Hat
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Bill Burke
> > > >>>> Red Hat
> > > >>>> _______________________________________________
> > > >>>> keycloak-dev mailing list
> > > >>>> keycloak-dev at lists.jboss.org
> > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> --Hynek
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Bill Burke
> > > >> Red Hat
> > > >
> > > >
> > > >
> > > > --
> > > > Bill Burke
> > > > Red Hat
> > >
> > >
> > >
> > > --
> > > Bill Burke
> > > Red Hat
> > >
> >
> >
> >
> > --
> >
> > --Hynek
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Thu Oct 12 08:58:59 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Oct 2017 08:58:59 -0400
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>
	<CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>
Message-ID: <CABRXCmy1Mt=4aMJjrz5Fv0MTVmfrThyzhJpNCzAz+sC=ofXRug@mail.gmail.com>

MARKO YOU ARE A GOD!!!

Thank you so much...This was driving me absolutely bonkers.  I was
looking at router tables and stuff trying to figure out if I turned on
some IP filtering or something.

FYI this worked:  https://thoeni.io/post/macos-sierra-java/

I had just recently upgraded to Sierra.


On Thu, Oct 12, 2017 at 4:52 AM, Marko Strukelj <mstrukel at redhat.com> wrote:
> This sounds very familiar to the issue I had some time ago, that was only
> failing for me on macOS.
>
> See: https://issues.jboss.org/browse/KEYCLOAK-4278
>
> and https://github.com/keycloak/keycloak/pull/3944#issuecomment-297535534
>
> On Thu, Oct 12, 2017 at 10:33 AM, Hynek Mlnarik <hmlnarik at redhat.com> wrote:
>>
>> GreenMail seems to start, otherwise it would be
>> "java.net.ConnectException:
>> Connection refused" rather than "response: -1". This error seems to come
>> out of SMTP client. Can you set up logging of JavaMail in by adding
>>             session.setDebug(true);
>> to DefaultEmailSenderProvider, that might give some hint on what's wrong.
>>
>> [1] https://javaee.github.io/javamail/FAQ#debug
>>
>> On Thu, Oct 12, 2017 at 12:03 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> > Caused by: javax.mail.MessagingException: Could not connect to SMTP
>> > host: localhost, port: 3025, response: -1
>> >
>> > On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com> wrote:
>> > > Its really weird...I put a sleep at the beginning of the test.  I can
>> > > telnet to Greenmail (localhost 3025) and Greenmail will respond with
>> > > error message if I type random stuff in.  But I get connection errors
>> > > on test.  Doesn't make sense.
>> > >
>> > > On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com> wrote:
>> > >> Seems any test using GreenMail fails for me.  I tried changing
>> > >> host/port and everything.  I'll put in a sleep and see if that helps.
>> > >>
>> > >> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <hmlnarik at redhat.com>
>> > wrote:
>> > >>> Just checked, the RequiredActionEmailVerificationTest works for me,
>> > all
>> > >>> tests passed. Is it possible that GreenMail does not start fast
>> > enough? Do
>> > >>> all tests fail or only few of them at the beginning?
>> > >>>
>> > >>> --Hynek
>> > >>>
>> > >>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com>
>> > >>> wrote:
>> > >>>>
>> > >>>> I'm getting connection errors to GreenMail...Don't get it...I can
>> > >>>> telnet to the host/port
>> > >>>>
>> > >>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com>
>> > wrote:
>> > >>>> > I still can't figure out why my build isn't running.  I cloned
>> > >>>> > fresh
>> > >>>> > from master and RequiredActionEmailVerificationTest is failing (I
>> > >>>> > think) when sending any email.  I get read timeout errors on
>> > >>>> > login
>> > >>>> > submit, but no other errors.
>> > >>>> >
>> > >>>> > Anybody else seeing failures in RequiredActionEmailVerificatio
>> > nTests?
>> > >>>> >
>> > >>>> > --
>> > >>>> > Bill Burke
>> > >>>> > Red Hat
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> --
>> > >>>> Bill Burke
>> > >>>> Red Hat
>> > >>>> _______________________________________________
>> > >>>> keycloak-dev mailing list
>> > >>>> keycloak-dev at lists.jboss.org
>> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>>
>> > >>> --Hynek
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> Bill Burke
>> > >> Red Hat
>> > >
>> > >
>> > >
>> > > --
>> > > Bill Burke
>> > > Red Hat
>> >
>> >
>> >
>> > --
>> > Bill Burke
>> > Red Hat
>> >
>>
>>
>>
>> --
>>
>> --Hynek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>



-- 
Bill Burke
Red Hat

From mstrukel at redhat.com  Thu Oct 12 09:03:50 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 12 Oct 2017 15:03:50 +0200
Subject: [keycloak-dev] RequiredActionEmailVerificationTest failures
In-Reply-To: <CABRXCmy1Mt=4aMJjrz5Fv0MTVmfrThyzhJpNCzAz+sC=ofXRug@mail.gmail.com>
References: <CABRXCmzQx0PB+FYngxqhtwKkesf364HBZZGiBbtigXp_TpAJFg@mail.gmail.com>
	<CABRXCmyM6w1_3b0xiy17w=p-HHwsZjSezDqoLHq0g2HrkAs+=g@mail.gmail.com>
	<CAMvXD=H0KCh4-+kc-jErWJP9PEtYUWD4Ae1GHt8eKzw8o1M_aA@mail.gmail.com>
	<CABRXCmwvyVKv0ZEki5WG3osPQAp3eGYDuz+gH6qQkjKbbWrGbg@mail.gmail.com>
	<CABRXCmzKHpEDy745s7FFbc=QpgkcPMJ96nM1K3uUeLMnWPAn=Q@mail.gmail.com>
	<CABRXCmydV1JinWsA4VnP7rk2u5NT2FEPFJODTRi8No_5_VYyYA@mail.gmail.com>
	<CAMvXD=GHYER6FH=svENH6r3jLMXoHvdwchBO6uUEGyva5_CEtw@mail.gmail.com>
	<CA+1OW+hraByoa2QLkT7QZo8fN+3JVMBK-LF3M=HpzMWEtioAUw@mail.gmail.com>
	<CABRXCmy1Mt=4aMJjrz5Fv0MTVmfrThyzhJpNCzAz+sC=ofXRug@mail.gmail.com>
Message-ID: <CA+1OW+iz7WfhZMAjdfPJ36KWawWhTY-quqQv8=2Ye5oLcQTBkQ@mail.gmail.com>

Glad to hear it worked for you :)

On Thu, Oct 12, 2017 at 2:58 PM, Bill Burke <bburke at redhat.com> wrote:

> MARKO YOU ARE A GOD!!!
>
> Thank you so much...This was driving me absolutely bonkers.  I was
> looking at router tables and stuff trying to figure out if I turned on
> some IP filtering or something.
>
> FYI this worked:  https://thoeni.io/post/macos-sierra-java/
>
> I had just recently upgraded to Sierra.
>
>
> On Thu, Oct 12, 2017 at 4:52 AM, Marko Strukelj <mstrukel at redhat.com>
> wrote:
> > This sounds very familiar to the issue I had some time ago, that was only
> > failing for me on macOS.
> >
> > See: https://issues.jboss.org/browse/KEYCLOAK-4278
> >
> > and https://github.com/keycloak/keycloak/pull/3944#
> issuecomment-297535534
> >
> > On Thu, Oct 12, 2017 at 10:33 AM, Hynek Mlnarik <hmlnarik at redhat.com>
> wrote:
> >>
> >> GreenMail seems to start, otherwise it would be
> >> "java.net.ConnectException:
> >> Connection refused" rather than "response: -1". This error seems to come
> >> out of SMTP client. Can you set up logging of JavaMail in by adding
> >>             session.setDebug(true);
> >> to DefaultEmailSenderProvider, that might give some hint on what's
> wrong.
> >>
> >> [1] https://javaee.github.io/javamail/FAQ#debug
> >>
> >> On Thu, Oct 12, 2017 at 12:03 AM, Bill Burke <bburke at redhat.com> wrote:
> >>
> >> > Caused by: javax.mail.MessagingException: Could not connect to SMTP
> >> > host: localhost, port: 3025, response: -1
> >> >
> >> > On Wed, Oct 11, 2017 at 5:59 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> > > Its really weird...I put a sleep at the beginning of the test.  I
> can
> >> > > telnet to Greenmail (localhost 3025) and Greenmail will respond with
> >> > > error message if I type random stuff in.  But I get connection
> errors
> >> > > on test.  Doesn't make sense.
> >> > >
> >> > > On Wed, Oct 11, 2017 at 5:42 PM, Bill Burke <bburke at redhat.com>
> wrote:
> >> > >> Seems any test using GreenMail fails for me.  I tried changing
> >> > >> host/port and everything.  I'll put in a sleep and see if that
> helps.
> >> > >>
> >> > >> On Wed, Oct 11, 2017 at 4:19 PM, Hynek Mlnarik <
> hmlnarik at redhat.com>
> >> > wrote:
> >> > >>> Just checked, the RequiredActionEmailVerificationTest works for
> me,
> >> > all
> >> > >>> tests passed. Is it possible that GreenMail does not start fast
> >> > enough? Do
> >> > >>> all tests fail or only few of them at the beginning?
> >> > >>>
> >> > >>> --Hynek
> >> > >>>
> >> > >>> On Wed, Oct 11, 2017 at 9:09 PM, Bill Burke <bburke at redhat.com>
> >> > >>> wrote:
> >> > >>>>
> >> > >>>> I'm getting connection errors to GreenMail...Don't get it...I can
> >> > >>>> telnet to the host/port
> >> > >>>>
> >> > >>>> On Wed, Oct 11, 2017 at 2:55 PM, Bill Burke <bburke at redhat.com>
> >> > wrote:
> >> > >>>> > I still can't figure out why my build isn't running.  I cloned
> >> > >>>> > fresh
> >> > >>>> > from master and RequiredActionEmailVerificationTest is
> failing (I
> >> > >>>> > think) when sending any email.  I get read timeout errors on
> >> > >>>> > login
> >> > >>>> > submit, but no other errors.
> >> > >>>> >
> >> > >>>> > Anybody else seeing failures in RequiredActionEmailVerificatio
> >> > nTests?
> >> > >>>> >
> >> > >>>> > --
> >> > >>>> > Bill Burke
> >> > >>>> > Red Hat
> >> > >>>>
> >> > >>>>
> >> > >>>>
> >> > >>>> --
> >> > >>>> Bill Burke
> >> > >>>> Red Hat
> >> > >>>> _______________________________________________
> >> > >>>> keycloak-dev mailing list
> >> > >>>> keycloak-dev at lists.jboss.org
> >> > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>>
> >> > >>> --Hynek
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Bill Burke
> >> > >> Red Hat
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Bill Burke
> >> > > Red Hat
> >> >
> >> >
> >> >
> >> > --
> >> > Bill Burke
> >> > Red Hat
> >> >
> >>
> >>
> >>
> >> --
> >>
> >> --Hynek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
>
>
>
> --
> Bill Burke
> Red Hat
>

From herbert.muehlburger at bearingpoint.com  Thu Oct 12 10:06:51 2017
From: herbert.muehlburger at bearingpoint.com (Muehlburger, Herbert)
Date: Thu, 12 Oct 2017 14:06:51 +0000
Subject: [keycloak-dev] Compression of Token Claims
Message-ID: <1507817211271.8930@bearingpoint.com>

Hi,

does Keycloak compress token claims before base64 encoding? I have a custom claim that might get big. I'd like to always compress this claim but I'm not sure if this is already done by keycloak?

Best,
Herbert
________________________________
BearingPoint Technology GmbH
Sitz: Premst?tten bei Graz
Firmenbuchgericht: Landesgericht f?r ZRS Graz
Firmenbuchnummer: FN 44354b

The information in this email is confidential and may be legally privileged. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.

From bburke at redhat.com  Thu Oct 12 19:49:14 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Oct 2017 19:49:14 -0400
Subject: [keycloak-dev] disable GitLab provider? Feedback desired
Message-ID: <CABRXCmxN9_JTOtH6EEvcMMKUKVwxR4SZmd5jA5h7zPyDeDJmXw@mail.gmail.com>

Seems that Gitlab tokens take a little bit to propagate.  Our GitLab
identity provider will get a 401 error when it calls the Gitlab user
info service intermittently.  This is solved by putting in a 1 second
delay.  Seems like a hack.  Should we just not provide Gitlab social
login?

Thanks,

Bill

-- 
Bill Burke
Red Hat

From mposolda at redhat.com  Fri Oct 13 02:48:42 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 13 Oct 2017 08:48:42 +0200
Subject: [keycloak-dev] disable GitLab provider? Feedback desired
In-Reply-To: <CABRXCmxN9_JTOtH6EEvcMMKUKVwxR4SZmd5jA5h7zPyDeDJmXw@mail.gmail.com>
References: <CABRXCmxN9_JTOtH6EEvcMMKUKVwxR4SZmd5jA5h7zPyDeDJmXw@mail.gmail.com>
Message-ID: <2a08c5b6-e161-2d23-7652-38854621f9e8@redhat.com>

Looks like known issue on their side 
https://gitlab.com/gitlab-org/gitlab-ce/issues/29468 .

Maybe instead of hardcode 1 second pause, we can rather poll their 
UserInfo endpoint in some periodic interval? Similar approach like the 
"Retry" class from our testsuite is using.

Marek

On 13/10/17 01:49, Bill Burke wrote:
> Seems that Gitlab tokens take a little bit to propagate.  Our GitLab
> identity provider will get a 401 error when it calls the Gitlab user
> info service intermittently.  This is solved by putting in a 1 second
> delay.  Seems like a hack.  Should we just not provide Gitlab social
> login?
>
> Thanks,
>
> Bill
>


From sthorger at redhat.com  Fri Oct 13 08:03:06 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 13 Oct 2017 14:03:06 +0200
Subject: [keycloak-dev] disable GitLab provider? Feedback desired
In-Reply-To: <2a08c5b6-e161-2d23-7652-38854621f9e8@redhat.com>
References: <CABRXCmxN9_JTOtH6EEvcMMKUKVwxR4SZmd5jA5h7zPyDeDJmXw@mail.gmail.com>
	<2a08c5b6-e161-2d23-7652-38854621f9e8@redhat.com>
Message-ID: <CAJgngAfjJhcJ0+KfWBfcT-YfARdSw2d8tzpGD88zsHXy_5a1=w@mail.gmail.com>

+1 Why not just do one or two retries if the first attempt fails?

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

> Looks like known issue on their side
> https://gitlab.com/gitlab-org/gitlab-ce/issues/29468 .
>
> Maybe instead of hardcode 1 second pause, we can rather poll their
> UserInfo endpoint in some periodic interval? Similar approach like the
> "Retry" class from our testsuite is using.
>
> Marek
>
> On 13/10/17 01:49, Bill Burke wrote:
> > Seems that Gitlab tokens take a little bit to propagate.  Our GitLab
> > identity provider will get a 401 error when it calls the Gitlab user
> > info service intermittently.  This is solved by putting in a 1 second
> > delay.  Seems like a hack.  Should we just not provide Gitlab social
> > login?
> >
> > Thanks,
> >
> > Bill
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From quynhnhat.nguyen at gmail.com  Sun Oct 15 20:23:28 2017
From: quynhnhat.nguyen at gmail.com (Quynh Nhat Nguyen)
Date: Sun, 15 Oct 2017 17:23:28 -0700
Subject: [keycloak-dev] Keycloak REST API Authenticator
Message-ID: <CAMCBena-sVCAwD61-YH_t4Q8njmvsUXcn3cOHyOHneyDb7PDSw@mail.gmail.com>

Hi,

I want to implement REST API as one of keycloak authenticators.
Specifically, when a user authenticates with keycloak, keycloak will
contact the REST API to request for authentication decision, for example
PrivacyIDEA REST API server (https://www.privacyidea.org/).

I would appreciate any feedback, and advice on this proposal!

Thank you.

From sthorger at redhat.com  Mon Oct 16 06:55:36 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Oct 2017 12:55:36 +0200
Subject: [keycloak-dev] Flexible HTTP Proxy support for
	HttpClientProvider
In-Reply-To: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>
References: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>
Message-ID: <CAJgngAfkcUB_M-eNJU-T8CyLNS=BQJB=dHyGVXx1y3rgJnG7Dw@mail.gmail.com>

We'd need some way of automatically testing HTTP proxy support, which is
non-trivial. The steps you've listed only manually checks Google, but what
about everything else that may need to go through the HTTP proxy? Captcha,
other IdPs, external clients, etc..

On 11 October 2017 at 14:26, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hello,
>
> I've sent a PR [1] for KEYCLOAK-4743 [2] Add proxy support to
> HttpClientProvider SPI.
> The proposed implementation is based on the discussions from an older
> (rejected) PR [3]
>
> The current DefaultHttpClientProviderFactory doesn't support HTTP proxies
> which makes
> it very difficult to integrate social Identity Providers like google /
> facebook etc...
> when you are required to tunnel all external communications though a proxy
> server.
>
> Server Developers are currently required to either convince their network
> admins to
> loosen the proxy rules ... or provide a custom implementation of a
> HttpClientProvider,
> which is quite complex. Therefore it would be great if keycloak would add
> support
> for this out of the box.
>
> Since keycloak needs to be able to selectively use a (dedicated) proxy
> server
> for external and potentially no proxy for internal connections the
> configuration
> for that needs to be quite flexible.
>
> The current PR proposes to use an ordered list of proxymappings that match
> a http request host based on a regex pattern to a proxy uri which are
> processed
> by a new ProxyMappingsAwareRoutePlanner that is added to the internal
> HttpClient.
>
> A ProxyMapping has the form hostname-pattern;proxy-uri e.g.:
>
>       .*\.(google|googleapis)\.com;http://www-proxy.acme.corp.com:8080
>       .*\.acme\.corp\.com;NO_PROXY
>       .*;http://fallback:8080
>
> (the catch all is optional)
> The first matching mapping defines the proxy to use. If no pattern matches
> then no proxy is used. One can also explicity define that certain
> connections should
> not use a proxy.
>
> ... and can be configured via jboss-cli
>
>   echo SETUP: Configure proxy routes for HttpClient SPI
>
> /subsystem=keycloak-server/spi=connectionsHttpClient/
> provider=default:add(enabled=true)
>
> /subsystem=keycloak-server/spi=connectionsHttpClient/
> provider=default:write-attribute(name=properties.
> proxy-mappings,value=[".*\\.(google|googleapis)\\.com;
> http://www-proxy.acme.corp.com:8080",".*\\.acme\\.corp\\.
> com;NO_PROXY",".*;
> http://fallback:8080"])
>
> This can be tested as follows:
> 1) Apply the PR in branch, build a server distribution.
> 2) Start Keycloak with portOffset 10000 for http/https/ajp port.
> Configure the ProxyMappings in standalone.xml:
> via jboss-cli:
>   echo SETUP: Configure proxy routes for HttpClient SPI
>
> /subsystem=keycloak-server/spi=connectionsHttpClient/
> provider=default:add(enabled=true)
>
> /subsystem=keycloak-server/spi=connectionsHttpClient/
> provider=default:write-attribute(name=properties.
> proxy-mappings,value=[".*\\.(google|googleapis)\\.com;
> http://localhost:8080"])
>
> 3) Download and start BurpSuite [4]
> 4) By default burpsuite starts a proxy server on port 8080
> 5) Register google as auth provider and check entries in burp proxy log
>    (Note that you potentially need to explicitly forward the request in the
> proxy tab in Burp)
>
> WDYT?
>
> Cheers,
> Thomas
>
> [1] https://github.com/keycloak/keycloak/pull/4543
> [2] https://issues.jboss.org/browse/KEYCLOAK-4743
> [3] https://github.com/keycloak/keycloak/pull/4040
> [4] https://portswigger.net/burp/help/suite_gettingstarted.html
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.darimont at googlemail.com  Mon Oct 16 08:00:33 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 16 Oct 2017 14:00:33 +0200
Subject: [keycloak-dev] Flexible HTTP Proxy support for
	HttpClientProvider
In-Reply-To: <CAJgngAfkcUB_M-eNJU-T8CyLNS=BQJB=dHyGVXx1y3rgJnG7Dw@mail.gmail.com>
References: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>
	<CAJgngAfkcUB_M-eNJU-T8CyLNS=BQJB=dHyGVXx1y3rgJnG7Dw@mail.gmail.com>
Message-ID: <CAK-7U1iri3yy60Bznbsch7n36kgLbeXx6VrwM1Vi+u6+04R8Pg@mail.gmail.com>

Hello,

I agree that one needs to be able to test this automatically... but this
needs some additional thought.
For now how about rolling out the proxy support behind a feature flag and
ask the community for feedback?

I tested this for google APIs but I'd assume that since the proxy is
transparently applied in case the target hostname
of a request matches the configured proxy pattern it will work just fine.

Btw. I just gave this a try with the registration recaptcha and it worked
fine.

I had to adjust the default Content-Security-Policy sent by Keycloak though:
from:
  frame-src self; frame-ancestors 'self'; object-src 'none';
to:
  frame-src self https://www.google.com/recaptcha/; frame-ancestors 'self';
object-src 'none';

One thing that are currently missing in the proxy-support is support for
proxy authentication,
but this could be added later.

Cheers,
Thomas

2017-10-16 12:55 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:

> We'd need some way of automatically testing HTTP proxy support, which is
> non-trivial. The steps you've listed only manually checks Google, but what
> about everything else that may need to go through the HTTP proxy? Captcha,
> other IdPs, external clients, etc..
>
> On 11 October 2017 at 14:26, Thomas Darimont <thomas.darimont at googlemail.
> com> wrote:
>
>> Hello,
>>
>> I've sent a PR [1] for KEYCLOAK-4743 [2] Add proxy support to
>> HttpClientProvider SPI.
>> The proposed implementation is based on the discussions from an older
>> (rejected) PR [3]
>>
>> The current DefaultHttpClientProviderFactory doesn't support HTTP proxies
>> which makes
>> it very difficult to integrate social Identity Providers like google /
>> facebook etc...
>> when you are required to tunnel all external communications though a proxy
>> server.
>>
>> Server Developers are currently required to either convince their network
>> admins to
>> loosen the proxy rules ... or provide a custom implementation of a
>> HttpClientProvider,
>> which is quite complex. Therefore it would be great if keycloak would add
>> support
>> for this out of the box.
>>
>> Since keycloak needs to be able to selectively use a (dedicated) proxy
>> server
>> for external and potentially no proxy for internal connections the
>> configuration
>> for that needs to be quite flexible.
>>
>> The current PR proposes to use an ordered list of proxymappings that match
>> a http request host based on a regex pattern to a proxy uri which are
>> processed
>> by a new ProxyMappingsAwareRoutePlanner that is added to the internal
>> HttpClient.
>>
>> A ProxyMapping has the form hostname-pattern;proxy-uri e.g.:
>>
>>       .*\.(google|googleapis)\.com;http://www-proxy.acme.corp.com:8080
>>       .*\.acme\.corp\.com;NO_PROXY
>>       .*;http://fallback:8080
>>
>> (the catch all is optional)
>> The first matching mapping defines the proxy to use. If no pattern matches
>> then no proxy is used. One can also explicity define that certain
>> connections should
>> not use a proxy.
>>
>> ... and can be configured via jboss-cli
>>
>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>
>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>> r=default:add(enabled=true)
>>
>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>> r=default:write-attribute(name=properties.proxy-
>> mappings,value=[".*\\.(google|googleapis)\\.com;
>> http://www-proxy.acme.corp.com:8080",".*\\.acme\\.corp\\.com
>> ;NO_PROXY",".*;
>> http://fallback:8080"])
>>
>> This can be tested as follows:
>> 1) Apply the PR in branch, build a server distribution.
>> 2) Start Keycloak with portOffset 10000 for http/https/ajp port.
>> Configure the ProxyMappings in standalone.xml:
>> via jboss-cli:
>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>
>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>> r=default:add(enabled=true)
>>
>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>> r=default:write-attribute(name=properties.proxy-
>> mappings,value=[".*\\.(google|googleapis)\\.com;
>> http://localhost:8080"])
>>
>> 3) Download and start BurpSuite [4]
>> 4) By default burpsuite starts a proxy server on port 8080
>> 5) Register google as auth provider and check entries in burp proxy log
>>    (Note that you potentially need to explicitly forward the request in
>> the
>> proxy tab in Burp)
>>
>> WDYT?
>>
>> Cheers,
>> Thomas
>>
>> [1] https://github.com/keycloak/keycloak/pull/4543
>> [2] https://issues.jboss.org/browse/KEYCLOAK-4743
>> [3] https://github.com/keycloak/keycloak/pull/4040
>> [4] https://portswigger.net/burp/help/suite_gettingstarted.html
>> _______________________________________________
>> 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 16 08:05:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Oct 2017 14:05:30 +0200
Subject: [keycloak-dev] Flexible HTTP Proxy support for
	HttpClientProvider
In-Reply-To: <CAK-7U1iri3yy60Bznbsch7n36kgLbeXx6VrwM1Vi+u6+04R8Pg@mail.gmail.com>
References: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>
	<CAJgngAfkcUB_M-eNJU-T8CyLNS=BQJB=dHyGVXx1y3rgJnG7Dw@mail.gmail.com>
	<CAK-7U1iri3yy60Bznbsch7n36kgLbeXx6VrwM1Vi+u6+04R8Pg@mail.gmail.com>
Message-ID: <CAJgngAed1ft0pLG+Em98UJZy4TM9SjrtKAuCUqEdo68hw6bUHw@mail.gmail.com>

I'm afraid we need contributions to come with full automated testing as
well as documentation as we don't have the capacity to add this on behalf
of the community. Obviously if adding HTTP proxy support became a priority
to us we would consider doing it, but at the moment we have many other
higher priority things to work on.

On 16 October 2017 at 14:00, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hello,
>
> I agree that one needs to be able to test this automatically... but this
> needs some additional thought.
> For now how about rolling out the proxy support behind a feature flag and
> ask the community for feedback?
>
> I tested this for google APIs but I'd assume that since the proxy is
> transparently applied in case the target hostname
> of a request matches the configured proxy pattern it will work just fine.
>
> Btw. I just gave this a try with the registration recaptcha and it worked
> fine.
>
> I had to adjust the default Content-Security-Policy sent by Keycloak
> though:
> from:
>   frame-src self; frame-ancestors 'self'; object-src 'none';
> to:
>   frame-src self https://www.google.com/recaptcha/; frame-ancestors
> 'self'; object-src 'none';
>
> One thing that are currently missing in the proxy-support is support for
> proxy authentication,
> but this could be added later.
>
> Cheers,
> Thomas
>
> 2017-10-16 12:55 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We'd need some way of automatically testing HTTP proxy support, which is
>> non-trivial. The steps you've listed only manually checks Google, but what
>> about everything else that may need to go through the HTTP proxy? Captcha,
>> other IdPs, external clients, etc..
>>
>> On 11 October 2017 at 14:26, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> I've sent a PR [1] for KEYCLOAK-4743 [2] Add proxy support to
>>> HttpClientProvider SPI.
>>> The proposed implementation is based on the discussions from an older
>>> (rejected) PR [3]
>>>
>>> The current DefaultHttpClientProviderFactory doesn't support HTTP
>>> proxies
>>> which makes
>>> it very difficult to integrate social Identity Providers like google /
>>> facebook etc...
>>> when you are required to tunnel all external communications though a
>>> proxy
>>> server.
>>>
>>> Server Developers are currently required to either convince their network
>>> admins to
>>> loosen the proxy rules ... or provide a custom implementation of a
>>> HttpClientProvider,
>>> which is quite complex. Therefore it would be great if keycloak would add
>>> support
>>> for this out of the box.
>>>
>>> Since keycloak needs to be able to selectively use a (dedicated) proxy
>>> server
>>> for external and potentially no proxy for internal connections the
>>> configuration
>>> for that needs to be quite flexible.
>>>
>>> The current PR proposes to use an ordered list of proxymappings that
>>> match
>>> a http request host based on a regex pattern to a proxy uri which are
>>> processed
>>> by a new ProxyMappingsAwareRoutePlanner that is added to the internal
>>> HttpClient.
>>>
>>> A ProxyMapping has the form hostname-pattern;proxy-uri e.g.:
>>>
>>>       .*\.(google|googleapis)\.com;http://www-proxy.acme.corp.com:8080
>>>       .*\.acme\.corp\.com;NO_PROXY
>>>       .*;http://fallback:8080
>>>
>>> (the catch all is optional)
>>> The first matching mapping defines the proxy to use. If no pattern
>>> matches
>>> then no proxy is used. One can also explicity define that certain
>>> connections should
>>> not use a proxy.
>>>
>>> ... and can be configured via jboss-cli
>>>
>>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>>
>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>> r=default:add(enabled=true)
>>>
>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>> r=default:write-attribute(name=properties.proxy-mappings,
>>> value=[".*\\.(google|googleapis)\\.com;
>>> http://www-proxy.acme.corp.com:8080",".*\\.acme\\.corp\\.com
>>> ;NO_PROXY",".*;
>>> http://fallback:8080"])
>>>
>>> This can be tested as follows:
>>> 1) Apply the PR in branch, build a server distribution.
>>> 2) Start Keycloak with portOffset 10000 for http/https/ajp port.
>>> Configure the ProxyMappings in standalone.xml:
>>> via jboss-cli:
>>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>>
>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>> r=default:add(enabled=true)
>>>
>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>> r=default:write-attribute(name=properties.proxy-mappings,
>>> value=[".*\\.(google|googleapis)\\.com;
>>> http://localhost:8080"])
>>>
>>> 3) Download and start BurpSuite [4]
>>> 4) By default burpsuite starts a proxy server on port 8080
>>> 5) Register google as auth provider and check entries in burp proxy log
>>>    (Note that you potentially need to explicitly forward the request in
>>> the
>>> proxy tab in Burp)
>>>
>>> WDYT?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> [1] https://github.com/keycloak/keycloak/pull/4543
>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4743
>>> [3] https://github.com/keycloak/keycloak/pull/4040
>>> [4] https://portswigger.net/burp/help/suite_gettingstarted.html
>>> _______________________________________________
>>> 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 16 08:07:05 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Oct 2017 14:07:05 +0200
Subject: [keycloak-dev] Flexible HTTP Proxy support for
	HttpClientProvider
In-Reply-To: <CAJgngAed1ft0pLG+Em98UJZy4TM9SjrtKAuCUqEdo68hw6bUHw@mail.gmail.com>
References: <CAK-7U1j_vrq0Dm7G6MwW+5HQZN5CH_sOiR5eaE4=1DM92zYyrQ@mail.gmail.com>
	<CAJgngAfkcUB_M-eNJU-T8CyLNS=BQJB=dHyGVXx1y3rgJnG7Dw@mail.gmail.com>
	<CAK-7U1iri3yy60Bznbsch7n36kgLbeXx6VrwM1Vi+u6+04R8Pg@mail.gmail.com>
	<CAJgngAed1ft0pLG+Em98UJZy4TM9SjrtKAuCUqEdo68hw6bUHw@mail.gmail.com>
Message-ID: <CAJgngAdYep290HS_M6wTk6cpJ0t+v2bZKfkoF3RRO-1-R1Xdgw@mail.gmail.com>

By the way "preview" features need testing as well.

On 16 October 2017 at 14:05, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'm afraid we need contributions to come with full automated testing as
> well as documentation as we don't have the capacity to add this on behalf
> of the community. Obviously if adding HTTP proxy support became a priority
> to us we would consider doing it, but at the moment we have many other
> higher priority things to work on.
>
> On 16 October 2017 at 14:00, Thomas Darimont <thomas.darimont at googlemail.
> com> wrote:
>
>> Hello,
>>
>> I agree that one needs to be able to test this automatically... but this
>> needs some additional thought.
>> For now how about rolling out the proxy support behind a feature flag and
>> ask the community for feedback?
>>
>> I tested this for google APIs but I'd assume that since the proxy is
>> transparently applied in case the target hostname
>> of a request matches the configured proxy pattern it will work just fine.
>>
>> Btw. I just gave this a try with the registration recaptcha and it worked
>> fine.
>>
>> I had to adjust the default Content-Security-Policy sent by Keycloak
>> though:
>> from:
>>   frame-src self; frame-ancestors 'self'; object-src 'none';
>> to:
>>   frame-src self https://www.google.com/recaptcha/; frame-ancestors
>> 'self'; object-src 'none';
>>
>> One thing that are currently missing in the proxy-support is support for
>> proxy authentication,
>> but this could be added later.
>>
>> Cheers,
>> Thomas
>>
>> 2017-10-16 12:55 GMT+02:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> We'd need some way of automatically testing HTTP proxy support, which is
>>> non-trivial. The steps you've listed only manually checks Google, but what
>>> about everything else that may need to go through the HTTP proxy? Captcha,
>>> other IdPs, external clients, etc..
>>>
>>> On 11 October 2017 at 14:26, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I've sent a PR [1] for KEYCLOAK-4743 [2] Add proxy support to
>>>> HttpClientProvider SPI.
>>>> The proposed implementation is based on the discussions from an older
>>>> (rejected) PR [3]
>>>>
>>>> The current DefaultHttpClientProviderFactory doesn't support HTTP
>>>> proxies
>>>> which makes
>>>> it very difficult to integrate social Identity Providers like google /
>>>> facebook etc...
>>>> when you are required to tunnel all external communications though a
>>>> proxy
>>>> server.
>>>>
>>>> Server Developers are currently required to either convince their
>>>> network
>>>> admins to
>>>> loosen the proxy rules ... or provide a custom implementation of a
>>>> HttpClientProvider,
>>>> which is quite complex. Therefore it would be great if keycloak would
>>>> add
>>>> support
>>>> for this out of the box.
>>>>
>>>> Since keycloak needs to be able to selectively use a (dedicated) proxy
>>>> server
>>>> for external and potentially no proxy for internal connections the
>>>> configuration
>>>> for that needs to be quite flexible.
>>>>
>>>> The current PR proposes to use an ordered list of proxymappings that
>>>> match
>>>> a http request host based on a regex pattern to a proxy uri which are
>>>> processed
>>>> by a new ProxyMappingsAwareRoutePlanner that is added to the internal
>>>> HttpClient.
>>>>
>>>> A ProxyMapping has the form hostname-pattern;proxy-uri e.g.:
>>>>
>>>>       .*\.(google|googleapis)\.com;http://www-proxy.acme.corp.com:8080
>>>>       .*\.acme\.corp\.com;NO_PROXY
>>>>       .*;http://fallback:8080
>>>>
>>>> (the catch all is optional)
>>>> The first matching mapping defines the proxy to use. If no pattern
>>>> matches
>>>> then no proxy is used. One can also explicity define that certain
>>>> connections should
>>>> not use a proxy.
>>>>
>>>> ... and can be configured via jboss-cli
>>>>
>>>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>>>
>>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>>> r=default:add(enabled=true)
>>>>
>>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>>> r=default:write-attribute(name=properties.proxy-mappings,val
>>>> ue=[".*\\.(google|googleapis)\\.com;
>>>> http://www-proxy.acme.corp.com:8080",".*\\.acme\\.corp\\.com
>>>> ;NO_PROXY",".*;
>>>> http://fallback:8080"])
>>>>
>>>> This can be tested as follows:
>>>> 1) Apply the PR in branch, build a server distribution.
>>>> 2) Start Keycloak with portOffset 10000 for http/https/ajp port.
>>>> Configure the ProxyMappings in standalone.xml:
>>>> via jboss-cli:
>>>>   echo SETUP: Configure proxy routes for HttpClient SPI
>>>>
>>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>>> r=default:add(enabled=true)
>>>>
>>>> /subsystem=keycloak-server/spi=connectionsHttpClient/provide
>>>> r=default:write-attribute(name=properties.proxy-mappings,val
>>>> ue=[".*\\.(google|googleapis)\\.com;
>>>> http://localhost:8080"])
>>>>
>>>> 3) Download and start BurpSuite [4]
>>>> 4) By default burpsuite starts a proxy server on port 8080
>>>> 5) Register google as auth provider and check entries in burp proxy log
>>>>    (Note that you potentially need to explicitly forward the request in
>>>> the
>>>> proxy tab in Burp)
>>>>
>>>> WDYT?
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> [1] https://github.com/keycloak/keycloak/pull/4543
>>>> [2] https://issues.jboss.org/browse/KEYCLOAK-4743
>>>> [3] https://github.com/keycloak/keycloak/pull/4040
>>>> [4] https://portswigger.net/burp/help/suite_gettingstarted.html
>>>> _______________________________________________
>>>> 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 16 09:19:30 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 16 Oct 2017 15:19:30 +0200
Subject: [keycloak-dev] Release Keycloak 3.3.0.Final on WildFly 11 CR1?
Message-ID: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>

Still no WildFly 11 Final and it may be weeks until it is out.

Question - should we just release Keycloak 3.3.0.Final based on WildFly 11
CR1?

From Joze.Mlakar at ixtlan-team.si  Mon Oct 16 11:47:33 2017
From: Joze.Mlakar at ixtlan-team.si (=?Windows-1252?Q?Jo=9Ee_Mlakar?=)
Date: Mon, 16 Oct 2017 15:47:33 +0000
Subject: [keycloak-dev] Release Keycloak 3.3.0.Final on WildFly 11 CR1?
In-Reply-To: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>
References: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>
Message-ID: <333E1CC6-DD61-4A40-BACE-09F7A5216511@ixtlan-team.si>

My vote: yes. Been running now on it, no problems.

J



From psilva at redhat.com  Mon Oct 16 14:38:21 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 16 Oct 2017 16:38:21 -0200
Subject: [keycloak-dev] Keycloak and Kubernetes
In-Reply-To: <CABRXCmy0CPPnaLGrU_sivEGuV71YqUs56Vr_dB2nER3=5BCm9Q@mail.gmail.com>
References: <CABRXCmy0CPPnaLGrU_sivEGuV71YqUs56Vr_dB2nER3=5BCm9Q@mail.gmail.com>
Message-ID: <CAJrcDBennLxSrGfz5s312hzOXV34-mkN19+=JUxXQhXV45vAeQ@mail.gmail.com>

Doesn't make more sense a subject like "Keycloak and Kubernetes/Istio" or
just "Keycloak and Istio". Although makes a lot sense Keycloak and
Kubernetes integration, Istio is more related with the application layer
and where we can push all capabilities provided by Keycloak.

One thing that would be awesome to see is specific metrics from Prometheus
related with security. Or even define adapter config outside deployments
(move keycloak.json out of deployments) just like you do with other
components in kube/istio.

On Tue, Oct 10, 2017 at 11:19 AM, Bill Burke <bburke at redhat.com> wrote:

> I believe there will be two distinct integration points of Keycloak
> with Kubernetes.
>
> * Kubernetes relies on Keycloak for authentication and even authorization
> * Keycloak is offered as a Kubernetes services for appliations and users
> to use
>
> These should be 2 distinct use cases.
>
> --
> Bill Burke
> Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From psilva at redhat.com  Tue Oct 17 08:09:37 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 17 Oct 2017 10:09:37 -0200
Subject: [keycloak-dev] Release Keycloak 3.3.0.Final on WildFly 11 CR1?
In-Reply-To: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>
References: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>
Message-ID: <CAJrcDBdXfeu0UNWQaPgOAQtPU=9YZqVisSzaYaUCbrpwiFS00w@mail.gmail.com>

I think we can do that for this particular version.

But there are some discussions around some very specific changes to
Elytron's HTTP API that can impact our Elytron adapters. After talking with
Darran, these changes should not have a huge impact to our code but will
require some changes and a round of tests to make sure it is still working
as expected.

Maybe you should forward this e-mail to jboss-as list and gather more
feedback about any change that may impact future releases.

On Mon, Oct 16, 2017 at 11:19 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Still no WildFly 11 Final and it may be weeks until it is out.
>
> Question - should we just release Keycloak 3.3.0.Final based on WildFly 11
> CR1?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Tue Oct 17 16:29:08 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 17 Oct 2017 16:29:08 -0400
Subject: [keycloak-dev] Groups completely hosed
Message-ID: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>

The Groups section of the Admin Console is completely messed up in master.

I see that the main screen has a table control on the bottom (not sure 
why).  It says "1 of Infinity".

If you create more than one group off of the root then only the first 
one will show up.  Also, it appears that the Default Groups tab doesn't 
fill the Available Groups section.

Anyone else see what I see?  Anyone know how it got so broken?

Stan

From psilva at redhat.com  Wed Oct 18 07:17:23 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Oct 2017 09:17:23 -0200
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
Message-ID: <CAJrcDBeV84hGRgcHtB33iHdkyU2zFuzizf1SqSOY3vig1Y_J7A@mail.gmail.com>

I see. The group-list.html seems to affected
by ea33af2c5918b00b23724f71a249bdb8a0b1893b.

We also use the same component in a group policy and there it looks fine.

On Tue, Oct 17, 2017 at 6:29 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> The Groups section of the Admin Console is completely messed up in master.
>
> I see that the main screen has a table control on the bottom (not sure
> why).  It says "1 of Infinity".
>
> If you create more than one group off of the root then only the first
> one will show up.  Also, it appears that the Default Groups tab doesn't
> fill the Available Groups section.
>
> Anyone else see what I see?  Anyone know how it got so broken?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Wed Oct 18 08:53:10 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Oct 2017 08:53:10 -0400
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <CAJrcDBeV84hGRgcHtB33iHdkyU2zFuzizf1SqSOY3vig1Y_J7A@mail.gmail.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
	<CAJrcDBeV84hGRgcHtB33iHdkyU2zFuzizf1SqSOY3vig1Y_J7A@mail.gmail.com>
Message-ID: <2a0537f4-84b6-04ff-f486-57cb98a094d4@redhat.com>

On 10/18/2017 7:17 AM, Pedro Igor Silva wrote:
> I see. The group-list.html seems to affected 
> by ea33af2c5918b00b23724f71a249bdb8a0b1893b.
That commit is from January 21, 2016.  Surely it's not the culprit?

https://github.com/keycloak/keycloak/commit/ea33af2c5918b00b23724f71a249bdb8a0b1893b
>
> We also use the same component in a group policy and there it looks fine.
>
> On Tue, Oct 17, 2017 at 6:29 PM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     The Groups section of the Admin Console is completely messed up in
>     master.
>
>     I see that the main screen has a table control on the bottom (not sure
>     why).  It says "1 of Infinity".
>
>     If you create more than one group off of the root then only the first
>     one will show up.  Also, it appears that the Default Groups tab
>     doesn't
>     fill the Available Groups section.
>
>     Anyone else see what I see?  Anyone know how it got so broken?
>
>     Stan
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>


From bruno at abstractj.org  Wed Oct 18 09:41:59 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Oct 2017 11:41:59 -0200
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
Message-ID: <20171018134159.GA599@abstractj.org>

Same here. I'm trying to find when we introduced this bug. Also, I don't
get why we have tons of console.log every time we do something related
with group.

On 2017-10-17, Stan Silvert wrote:
> The Groups section of the Admin Console is completely messed up in master.
>
> I see that the main screen has a table control on the bottom (not sure
> why).  It says "1 of Infinity".
>
> If you create more than one group off of the root then only the first
> one will show up.  Also, it appears that the Default Groups tab doesn't
> fill the Available Groups section.
>
> Anyone else see what I see?  Anyone know how it got so broken?
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From psilva at redhat.com  Wed Oct 18 10:19:23 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Oct 2017 12:19:23 -0200
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <2a0537f4-84b6-04ff-f486-57cb98a094d4@redhat.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
	<CAJrcDBeV84hGRgcHtB33iHdkyU2zFuzizf1SqSOY3vig1Y_J7A@mail.gmail.com>
	<2a0537f4-84b6-04ff-f486-57cb98a094d4@redhat.com>
Message-ID: <CAJrcDBdcnLZATo4-Q3VaPdTZKjdCeAA=M8yxF6dR0mBu+FmLbg@mail.gmail.com>

Gave you the wrong ID. Can you check this one
https://github.com/keycloak/keycloak/commit/2c24b3926853ca08bb41bf0e9a4da82c075b08ff#diff-7d04beec4ccb9f8c474534c933735027
.

There is an addition of "kc-paging" directive.

On Wed, Oct 18, 2017 at 10:53 AM, Stan Silvert <ssilvert at redhat.com> wrote:

> On 10/18/2017 7:17 AM, Pedro Igor Silva wrote:
>
> I see. The group-list.html seems to affected by
> ea33af2c5918b00b23724f71a249bdb8a0b1893b.
>
> That commit is from January 21, 2016.  Surely it's not the culprit?
>
> https://github.com/keycloak/keycloak/commit/ea33af2c5918b00b23724f71a249bd
> b8a0b1893b
>
>
> We also use the same component in a group policy and there it looks fine.
>
> On Tue, Oct 17, 2017 at 6:29 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> The Groups section of the Admin Console is completely messed up in master.
>>
>> I see that the main screen has a table control on the bottom (not sure
>> why).  It says "1 of Infinity".
>>
>> If you create more than one group off of the root then only the first
>> one will show up.  Also, it appears that the Default Groups tab doesn't
>> fill the Available Groups section.
>>
>> Anyone else see what I see?  Anyone know how it got so broken?
>>
>> Stan
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>

From ssilvert at redhat.com  Wed Oct 18 10:39:50 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 18 Oct 2017 10:39:50 -0400
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <CAJrcDBdcnLZATo4-Q3VaPdTZKjdCeAA=M8yxF6dR0mBu+FmLbg@mail.gmail.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
	<CAJrcDBeV84hGRgcHtB33iHdkyU2zFuzizf1SqSOY3vig1Y_J7A@mail.gmail.com>
	<2a0537f4-84b6-04ff-f486-57cb98a094d4@redhat.com>
	<CAJrcDBdcnLZATo4-Q3VaPdTZKjdCeAA=M8yxF6dR0mBu+FmLbg@mail.gmail.com>
Message-ID: <75a675de-de1d-5a37-4a58-d60ef0fdac65@redhat.com>

Bruno found it was this one:
https://github.com/keycloak/keycloak/commit/1a50e77a4d51a1c8b284b8f8b58648650cafcff9

It's a big commit that doesn't even compile.


On 10/18/2017 10:19 AM, Pedro Igor Silva wrote:
> Gave you the wrong ID. Can you check this one 
> https://github.com/keycloak/keycloak/commit/2c24b3926853ca08bb41bf0e9a4da82c075b08ff#diff-7d04beec4ccb9f8c474534c933735027. 
>
>
> There is an addition of "kc-paging" directive.
>
> On Wed, Oct 18, 2017 at 10:53 AM, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 10/18/2017 7:17 AM, Pedro Igor Silva wrote:
>>     I see. The group-list.html seems to affected by
>>     ea33af2c5918b00b23724f71a249bdb8a0b1893b.
>     That commit is from January 21, 2016.  Surely it's not the culprit?
>
>     https://github.com/keycloak/keycloak/commit/ea33af2c5918b00b23724f71a249bdb8a0b1893b
>     <https://github.com/keycloak/keycloak/commit/ea33af2c5918b00b23724f71a249bdb8a0b1893b>
>>
>>     We also use the same component in a group policy and there it
>>     looks fine.
>>
>>     On Tue, Oct 17, 2017 at 6:29 PM, Stan Silvert
>>     <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>
>>         The Groups section of the Admin Console is completely messed
>>         up in master.
>>
>>         I see that the main screen has a table control on the bottom
>>         (not sure
>>         why).  It says "1 of Infinity".
>>
>>         If you create more than one group off of the root then only
>>         the first
>>         one will show up.  Also, it appears that the Default Groups
>>         tab doesn't
>>         fill the Available Groups section.
>>
>>         Anyone else see what I see?  Anyone know how it got so broken?
>>
>>         Stan
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>         <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>


From sthorger at redhat.com  Wed Oct 18 11:43:43 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 18 Oct 2017 17:43:43 +0200
Subject: [keycloak-dev] Groups completely hosed
In-Reply-To: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
References: <b4bee2d4-9e43-b074-e00b-3420cf54e30f@redhat.com>
Message-ID: <CAJgngAfVRcw4_AW8OzqvzEp=yddepFLCeAXgXKS4NZKaD7PRcg@mail.gmail.com>

Looks like this is caused by https://issues.jboss.org/browse/KEYCLOAK-2538

On 17 October 2017 at 22:29, Stan Silvert <ssilvert at redhat.com> wrote:

> The Groups section of the Admin Console is completely messed up in master.
>
> I see that the main screen has a table control on the bottom (not sure
> why).  It says "1 of Infinity".
>
> If you create more than one group off of the root then only the first
> one will show up.  Also, it appears that the Default Groups tab doesn't
> fill the Available Groups section.
>
> Anyone else see what I see?  Anyone know how it got so broken?
>
> Stan
> _______________________________________________
> 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 19 00:59:19 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 19 Oct 2017 06:59:19 +0200
Subject: [keycloak-dev] Release Keycloak 3.3.0.Final on WildFly 11 CR1?
In-Reply-To: <CAJrcDBdXfeu0UNWQaPgOAQtPU=9YZqVisSzaYaUCbrpwiFS00w@mail.gmail.com>
References: <CAJgngAc2_EnFotkrAwKJ3Tv37FZ8wKmyXaT9nw++b5At3gF3Dw@mail.gmail.com>
	<CAJrcDBdXfeu0UNWQaPgOAQtPU=9YZqVisSzaYaUCbrpwiFS00w@mail.gmail.com>
Message-ID: <CAJgngAcG3iQrmRsCp=yQD5KZFXaNhKmQN63=w7XA21FC8Z9ctA@mail.gmail.com>

Going for it and releasing 3.3.0.Final soon.

With regards to Elytron API changes we'll just adopt those for 3.4. I
assume KC 3.3 Elytron adapters won't work with WF 11 FInal then, but we're
probably going to wait for WF 11 Final to release 3.4 anyways and we can
sort that out then.

On 17 October 2017 at 14:09, Pedro Igor Silva <psilva at redhat.com> wrote:

> I think we can do that for this particular version.
>
> But there are some discussions around some very specific changes to
> Elytron's HTTP API that can impact our Elytron adapters. After talking with
> Darran, these changes should not have a huge impact to our code but will
> require some changes and a round of tests to make sure it is still working
> as expected.
>
> Maybe you should forward this e-mail to jboss-as list and gather more
> feedback about any change that may impact future releases.
>
> On Mon, Oct 16, 2017 at 11:19 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Still no WildFly 11 Final and it may be weeks until it is out.
>>
>> Question - should we just release Keycloak 3.3.0.Final based on WildFly 11
>> CR1?
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>

From hmlnarik at redhat.com  Thu Oct 19 08:08:14 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Thu, 19 Oct 2017 14:08:14 +0200
Subject: [keycloak-dev] Conditional testing of cross-dc on Travis
Message-ID: <CAMvXD=Hnho0=1vxKycMbUrnzXzjXA8Nygjg4qrW_RFauXiC8tQ@mail.gmail.com>

Hi

as part of the cross-dc, we need to introduce some means of running
cross-dc tests on PRs that touch critical classes. On the other hand, these
tests are not necessary for every and each PR as they take 15-20 minutes to
complete and for many changes bring no additional value to regular
testsuite run.

I've implemented a straightforward test for checking whether the given
group in travis should be tested [1] and would love to hear your feedback
on it. It is intentionally simple, based on filename pattern matching, in
the future the checks can become more complex, based on our needs.

There are two types of check:
- global which is run regardless of the current test group (as defined by
.travis.yml). Currently it checks whether only a change in .md documents
and if yes, it blocks running the TS
- per test-group condition on whether a particular test group should be
executed or not (it is "crossdc" group in the PR). If the check is not
defined for a given test group, the test group is run (e.g. "server-group1")

Thanks

--Hynek

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

From narendra at naidmincloud.com  Fri Oct 20 02:11:29 2017
From: narendra at naidmincloud.com (Narendra Kadali)
Date: Fri, 20 Oct 2017 11:41:29 +0530
Subject: [keycloak-dev] Enhancement to Keycloak logging
Message-ID: <CAKo57XW=yuuAJa3k-LLGt0POrxGnQ3vMjia=Hy5apwzwfzARSQ@mail.gmail.com>

Hi,

I feel that logging information in Keycloak is not sufficient to debug
issues. Sometimes I struggle to debug issues in our environment due to lack
of enough logs. When I look at the Keycloak source code, I noticed that
most of the classes doesn't have any loggers in it code.

I believe that with logs we should be able to identify what classes are
being called for executing an request and what data is passed to various
methods. This will make our life simple while debugging issues.

Do we have any plans for enhancing existing logging in Keycloak?

Thanks!

From martin.hardselius at gmail.com  Fri Oct 20 03:34:56 2017
From: martin.hardselius at gmail.com (Martin Hardselius)
Date: Fri, 20 Oct 2017 07:34:56 +0000
Subject: [keycloak-dev] Execution order of required actions
Message-ID: <CAPJq0L_TUxYbmr1cbaC2RX6S58fL9YQ-h-jq2Wkhuan3e2ukNQ@mail.gmail.com>

Hi,

This might be a question for the user list, but I haven't seen any activity
there in a while.

Is there a way to ensure execution order of required actions? Like "action
x to always fire last", or "action x should fire after action y".

Cheers,
Martin

From bruno at abstractj.org  Fri Oct 20 06:13:05 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 20 Oct 2017 10:13:05 +0000
Subject: [keycloak-dev] X509 integration tests
Message-ID: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>

Good morning,

While investigating an issue with X509 certificates, I was wondering if we
run integration tests for it on Travis. Looking at travis.yml I don't see
any reference like `run-server-tests org.keycloak.testsuite.x*`.

What I'm trying to do is pretty much:

mvn clean install -Pdistribution -DskipTests=true && cd
testsuite/integration-arquillian && cd tests/base && mvn clean test -B -nsu
-Pauth-server-wildfly -Dtest=*X509BrowserLoginTest

But all the tests are failing. Am I missing something?

From bruno at abstractj.org  Fri Oct 20 06:39:25 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 20 Oct 2017 10:39:25 +0000
Subject: [keycloak-dev] X509 integration tests
In-Reply-To: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>
References: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>
Message-ID: <CAM5SUC4_yO-N8=-1ypV-3en7WXJ_ypARYzmzaN91ZN04RWNhdQ@mail.gmail.com>

Vaclav pointed me to this
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-x509-tests

But I get:

Tests in error:

X509BrowserLoginTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound

X509DirectGrantTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound

X509OCSPResponderTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound


On Fri, Oct 20, 2017 at 8:13 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> While investigating an issue with X509 certificates, I was wondering if we
> run integration tests for it on Travis. Looking at travis.yml I don't see
> any reference like `run-server-tests org.keycloak.testsuite.x*`.
>
> What I'm trying to do is pretty much:
>
> mvn clean install -Pdistribution -DskipTests=true && cd
> testsuite/integration-arquillian && cd tests/base && mvn clean test -B -nsu
> -Pauth-server-wildfly -Dtest=*X509BrowserLoginTest
>
> But all the tests are failing. Am I missing something?
>

From sthorger at redhat.com  Fri Oct 20 06:45:53 2017
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 20 Oct 2017 12:45:53 +0200
Subject: [keycloak-dev] Enhancement to Keycloak logging
In-Reply-To: <CAKo57XW=yuuAJa3k-LLGt0POrxGnQ3vMjia=Hy5apwzwfzARSQ@mail.gmail.com>
References: <CAKo57XW=yuuAJa3k-LLGt0POrxGnQ3vMjia=Hy5apwzwfzARSQ@mail.gmail.com>
Message-ID: <CAJgngAeWDtr--_4gLwtkBVo49mCBmB9Jz91TeAVLhA8CMpvvAw@mail.gmail.com>

Yes, but it's a big task and probably best addressed gradually rather than
in one big chunk of work. Would be very interested in JIRAs for specific
scenarios that are hard to debug and even better if they come with PRs.

On 20 October 2017 at 08:11, Narendra Kadali <narendra at naidmincloud.com>
wrote:

> Hi,
>
> I feel that logging information in Keycloak is not sufficient to debug
> issues. Sometimes I struggle to debug issues in our environment due to lack
> of enough logs. When I look at the Keycloak source code, I noticed that
> most of the classes doesn't have any loggers in it code.
>
> I believe that with logs we should be able to identify what classes are
> being called for executing an request and what data is passed to various
> methods. This will make our life simple while debugging issues.
>
> Do we have any plans for enhancing existing logging in Keycloak?
>
> Thanks!
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From mstrukel at redhat.com  Fri Oct 20 09:03:31 2017
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 20 Oct 2017 15:03:31 +0200
Subject: [keycloak-dev] Enhancement to Keycloak logging
In-Reply-To: <CAKo57XW=yuuAJa3k-LLGt0POrxGnQ3vMjia=Hy5apwzwfzARSQ@mail.gmail.com>
References: <CAKo57XW=yuuAJa3k-LLGt0POrxGnQ3vMjia=Hy5apwzwfzARSQ@mail.gmail.com>
Message-ID: <CA+1OW+hJktdeTBZJJa0ELRdk+27E4JMfLF0y1ueOOX0ZrmzUBA@mail.gmail.com>

Could you describe in more detail what you have been trying to debug, and
what information you couldn't get to?

To see what classes are invoked it is enough to configure logging subsystem
such that it produces that info. See:
https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
(especially the comment by James Perkins at the bottom of the page) and
sub-chapters. There's more in-depth info at this page:
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuration_guide/logging_with_jboss_eap#log_formatters

You can see full http requests, and responses by properly configuring
undertow loggers, or even adding logging interceptors to undertow (see:
https://mirocupak.com/logging-requests-with-undertow/)

I think we should have enough logging in place to support common issues. So
it's important to let us know what you were trying to debug and what info
was missing for you. But we will almost certainly not apply logging that
displays method arguments across our codebase, because that's just too much
logging. Such verbose logging is better solved with class instrumentation
(e.g. by using project Byteman - byteman.jboss.org).


On Fri, Oct 20, 2017 at 8:11 AM, Narendra Kadali <narendra at naidmincloud.com>
wrote:

> Hi,
>
> I feel that logging information in Keycloak is not sufficient to debug
> issues. Sometimes I struggle to debug issues in our environment due to lack
> of enough logs. When I look at the Keycloak source code, I noticed that
> most of the classes doesn't have any loggers in it code.
>
> I believe that with logs we should be able to identify what classes are
> being called for executing an request and what data is passed to various
> methods. This will make our life simple while debugging issues.
>
> Do we have any plans for enhancing existing logging in Keycloak?
>
> Thanks!
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From pnalyvayko at agi.com  Fri Oct 20 11:33:43 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Fri, 20 Oct 2017 15:33:43 +0000
Subject: [keycloak-dev] X509 integration tests
In-Reply-To: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>
References: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>
Message-ID: <CY1PR0701MB1694529C73BA4412490A2B88DA430@CY1PR0701MB1694.namprd07.prod.outlook.com>

Hey Bruno,

Try  the following command to run x509 integration tests:

    mvn -f testsuite/integration-arquillian/pom.xml \
          clean install \
	  -Pauth-server-wildfly \
	  -Dauth.server.ssl.required \
	  -Dbrowser=phantomjs \
	  "-Dtest=*.x509.*"

The instructions how to run x509 tests are in:

testsuite\integration-arquillian\HOW-TO-RUN.md

--Peter

________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Bruno Oliveira [bruno at abstractj.org]
Sent: Friday, October 20, 2017 6:13 AM
To: keycloak-dev
Subject: [keycloak-dev] X509 integration tests

Good morning,

While investigating an issue with X509 certificates, I was wondering if we
run integration tests for it on Travis. Looking at travis.yml I don't see
any reference like `run-server-tests org.keycloak.testsuite.x*`.

What I'm trying to do is pretty much:

mvn clean install -Pdistribution -DskipTests=true && cd
testsuite/integration-arquillian && cd tests/base && mvn clean test -B -nsu
-Pauth-server-wildfly -Dtest=*X509BrowserLoginTest

But all the tests are failing. Am I missing something?
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From pnalyvayko at agi.com  Fri Oct 20 11:50:19 2017
From: pnalyvayko at agi.com (Nalyvayko, Peter)
Date: Fri, 20 Oct 2017 15:50:19 +0000
Subject: [keycloak-dev] X509 integration tests
In-Reply-To: <CAM5SUC4_yO-N8=-1ypV-3en7WXJ_ypARYzmzaN91ZN04RWNhdQ@mail.gmail.com>
References: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>,
	<CAM5SUC4_yO-N8=-1ypV-3en7WXJ_ypARYzmzaN91ZN04RWNhdQ@mail.gmail.com>
Message-ID: <CY1PR0701MB16948AB440EFB2A88550D48FDA430@CY1PR0701MB1694.namprd07.prod.outlook.com>

I am also getting the same error:

Running org.keycloak.testsuite.x509.X509OCSPResponderTest
11:44:19,510 INFO  [org.keycloak.testsuite.arquillian.AppServerTestEnricher]
TEST CONTEXT: org.keycloak.testsuite.x509.X509OCSPResponderTest
Oct 20, 2017 11:44:19 AM org.jboss.arquillian.core.impl.ObserverImpl resolveArguments
WARNING: Argument 1 for ReusableRemoteWebDriverExtension.destroyLastRemoteWebDriver is null. It won't be invoked.
11:44:19,541 ERROR [org.keycloak.testsuite.x509.X509OCSPResponderTest] [X509OCSPResponderTest] null() FAILED

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<< FAILURE! - in 
org.keycloak.testsuite.x509.X509OCSPResponderTest
org.keycloak.testsuite.x509.X509OCSPResponderTest  Time elapsed: 0 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/jboss/as/cli/CliInitializationException
Caused by: java.lang.ClassNotFoundException: org.jboss.as.cli.CliInitializationException


________________________________________
From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Bruno Oliveira [bruno at abstractj.org]
Sent: Friday, October 20, 2017 6:39 AM
To: keycloak-dev
Subject: Re: [keycloak-dev] X509 integration tests

Vaclav pointed me to this
https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-x509-tests

But I get:

Tests in error:

X509BrowserLoginTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound

X509DirectGrantTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound

X509OCSPResponderTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
? NoClassDefFound


On Fri, Oct 20, 2017 at 8:13 AM Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning,
>
> While investigating an issue with X509 certificates, I was wondering if we
> run integration tests for it on Travis. Looking at travis.yml I don't see
> any reference like `run-server-tests org.keycloak.testsuite.x*`.
>
> What I'm trying to do is pretty much:
>
> mvn clean install -Pdistribution -DskipTests=true && cd
> testsuite/integration-arquillian && cd tests/base && mvn clean test -B -nsu
> -Pauth-server-wildfly -Dtest=*X509BrowserLoginTest
>
> But all the tests are failing. Am I missing something?
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Fri Oct 20 14:24:49 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 20 Oct 2017 18:24:49 +0000
Subject: [keycloak-dev] X509 integration tests
In-Reply-To: <CY1PR0701MB16948AB440EFB2A88550D48FDA430@CY1PR0701MB1694.namprd07.prod.outlook.com>
References: <CAM5SUC4xLRRQsTzdcQVUfoSDQvGbM6oEOq+t9HBx0ow6=gYPTQ@mail.gmail.com>
	<CAM5SUC4_yO-N8=-1ypV-3en7WXJ_ypARYzmzaN91ZN04RWNhdQ@mail.gmail.com>
	<CY1PR0701MB16948AB440EFB2A88550D48FDA430@CY1PR0701MB1694.namprd07.prod.outlook.com>
Message-ID: <CAM5SUC5Rtj8WrNDb+UVYe4g9mmWV83BQtWpUnaWFrNLRZ7Y+Mg@mail.gmail.com>

It looks like Vaclav spotted the problem
https://github.com/keycloak/keycloak/pull/4593. But now we found out that
these tests tests weren't run for some time they seem to be completely
broken.

We created this Jira to track the issue:
https://issues.jboss.org/browse/KEYCLOAK-5720

Thanks Peter

On Fri, Oct 20, 2017 at 1:50 PM Nalyvayko, Peter <pnalyvayko at agi.com> wrote:

> I am also getting the same error:
>
> Running org.keycloak.testsuite.x509.X509OCSPResponderTest
> 11:44:19,510 INFO
> [org.keycloak.testsuite.arquillian.AppServerTestEnricher]
> TEST CONTEXT: org.keycloak.testsuite.x509.X509OCSPResponderTest
> Oct 20, 2017 11:44:19 AM org.jboss.arquillian.core.impl.ObserverImpl
> resolveArguments
> WARNING: Argument 1 for
> ReusableRemoteWebDriverExtension.destroyLastRemoteWebDriver is null. It
> won't be invoked.
> 11:44:19,541 ERROR [org.keycloak.testsuite.x509.X509OCSPResponderTest]
> [X509OCSPResponderTest] null() FAILED
>
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 sec <<<
> FAILURE! - in
> org.keycloak.testsuite.x509.X509OCSPResponderTest
> org.keycloak.testsuite.x509.X509OCSPResponderTest  Time elapsed: 0 sec
> <<< ERROR!
> java.lang.NoClassDefFoundError: org/jboss/as/cli/CliInitializationException
> Caused by: java.lang.ClassNotFoundException:
> org.jboss.as.cli.CliInitializationException
>
>
> ________________________________________
> From: keycloak-dev-bounces at lists.jboss.org [
> keycloak-dev-bounces at lists.jboss.org] on behalf of Bruno Oliveira [
> bruno at abstractj.org]
> Sent: Friday, October 20, 2017 6:39 AM
> To: keycloak-dev
> Subject: Re: [keycloak-dev] X509 integration tests
>
> Vaclav pointed me to this
>
> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/HOW-TO-RUN.md#run-x509-tests
>
> But I get:
>
> Tests in error:
>
>
> X509BrowserLoginTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
> ? NoClassDefFound
>
>
> X509DirectGrantTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
> ? NoClassDefFound
>
>
> X509OCSPResponderTest>AbstractKeycloakTest.setUpAuthServer:144->AbstractKeycloakTest.enableHTTPSForAuthServer:437
> ? NoClassDefFound
>
>
> On Fri, Oct 20, 2017 at 8:13 AM Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
> > Good morning,
> >
> > While investigating an issue with X509 certificates, I was wondering if
> we
> > run integration tests for it on Travis. Looking at travis.yml I don't see
> > any reference like `run-server-tests org.keycloak.testsuite.x*`.
> >
> > What I'm trying to do is pretty much:
> >
> > mvn clean install -Pdistribution -DskipTests=true && cd
> > testsuite/integration-arquillian && cd tests/base && mvn clean test -B
> -nsu
> > -Pauth-server-wildfly -Dtest=*X509BrowserLoginTest
> >
> > But all the tests are failing. Am I missing something?
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From ssilvert at redhat.com  Mon Oct 23 12:16:32 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Oct 2017 12:16:32 -0400
Subject: [keycloak-dev] If you ever touch Freemarker....
Message-ID: <7cd30619-3f43-a7fd-df97-3dd12d791743@redhat.com>

If you ever touch our Freemarker code, you need to be aware that we have 
changed the way that HTML is escaped.  Don't use ?html any more.

Freemarker is now upgraded to the latest version which provides 
automatic escaping of all variables by default.  The ?html suffix is no 
longer allowed.  This is far more secure as we err on the side of caution.

If you intend to include html in a Freemarker variable value you need to 
tell Freemarker that it shouldn't escape it.  Use the ?no_esc suffix.

For example, let's say you have a message bundle entry that looks like this:
totpStep1=Install <a href="https://myurl/">FreeOTP</a> or Google 
Authenticator on your device.

In Freemarker, you need to say:
<p>${msg("totpStep1")?no_esc}</p>

Also, be aware that you are responsible for the safety of anything 
marked with ?no_esc.  Make sure there is no way it can be modified from 
outside Keycloak or you will be opening Keycloak to an XSS attack.

Stan

From psilva at redhat.com  Thu Oct 26 16:08:00 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Oct 2017 18:08:00 -0200
Subject: [keycloak-dev] Permission and Obligation
Message-ID: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>

Hi,

This is about https://issues.jboss.org/browse/KEYCLOAK-5728.

The idea is allow policies to push information to a policy enforcer (PEP)
in order to enrich the final decision if a resource can be accessed or not.

In XACML there is a well known concept called Obligation, which can be used
to pass information to a policy enforcer in order to take some action or
verify something before granting or denying access to a resource.

Suppose you have a JS policy and want to push obligations when evaluating a
permission:

if (someCondition) {
    var permission = $evaluation.getPermission();
    permission.addObligation('transfer.limit', '200');
}

On the resource server side, you will be able to obtain *transfer.limit*
and check whether a request satisfy the obligation.

Any comments ?

Regards.
Pedro Igor

From bburke at redhat.com  Thu Oct 26 17:07:42 2017
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Oct 2017 17:07:42 -0400
Subject: [keycloak-dev] thoughts on file migration?
Message-ID: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>

Need input on this JIRA:

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

The problem is that our json exports do not have a version assigned to
them and we may have  org.keycloak.migration.migrators.Migration
objects that need to run.

Should we force people doing upgrades in this way to add a version tag
somewhere in the json?  We should then add a "fromJson" MIgration
method to be invoked for each appropriate migrator.

That sound like a plan?

-- 
Bill Burke
Red Hat

From thomas.darimont at googlemail.com  Thu Oct 26 17:57:29 2017
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Thu, 26 Oct 2017 23:57:29 +0200
Subject: [keycloak-dev] Some community feedback & service-to-service calls
Message-ID: <CAK-7U1heU-crUfm8K=wD-w0a1agSb8L-rqtug+-cGxZEwJQo7g@mail.gmail.com>

Hello Keycloak Team,

sorry for the (again long email)
TLDR:
- some community feedback
- people want examples / guidelines for secure service to service
communication
- Ideas for a blog post about that

---

This week I gave a talk about Keycloak at a small Java conference
in D?sseldorf / Germany: jcon.one.

In my talk I gave a brief overview on Keycloak and explained how SSO
via OpenID Connect works in detail. I also explained and briefly showed
how to work with the various token types e.g. how to query a bearer-only
API backend from a confidential client. I also demonstrated the
KeycloakInstalled-adapter, which apparently isn?t shown very often.
The talk was very well received.

During the days after the talk I got a lot of questions about Keycloak and
in particular
about how general service-to-service communication could be secured by
Keycloak.

I explained that there are some options like using
service-accounts or explicit technical user accounts to represent a service
which can obtain AccessTokens by itself and use those tokens to access
other
services secured by one of the various Keycloak adapters.

However many folks didn't seem to be aware of those options.
I think the reason for this is because although many articles
about Keycloak describe how to secure a common web application,
[perhaps with a SPA frontend and an API backend which gets accessed via an
AccessToken] one (IMHO) hardly finds articles with some detailed
discussions about how to properly secure service-to-service communication.
E.g. some mentioned scenarios were
- service calls another service on it's own (cron job)
- ... or triggered by an event or some messaging system.
both without direct user interaction.

In the examples project there is also (only?) one example about
using service accounts which looks a bit verbose:

https://github.com/keycloak/keycloak/blob/master/examples/demo-template/service-account/src/main/java/org/keycloak/example/ProductServiceAccountServlet.java#L108

I think a blog post about "Best practices for securing service-to-service
communication with keycloak" would be a good topic for the Keycloak blog.

I think one should highlight some APIs like the KeycloakAdmin Client API
which makes it fairly easy to retrieve tokens for the client_credentials
grant.

E.g:
    Keycloak keycloak = KeycloakBuilder.builder() //
      .serverUrl("http://localhost:8081/auth")
      .realm("service-to-service")
      .clientId("service-a")
      .clientSecret("73e7a71a-015e-4896-80ae-8e39ccb41deb")
      .grantType(OAuth2Constants.CLIENT_CREDENTIALS)
      .build();

    System.out.println(keycloak.tokenManager().getAccessTokenString());

Another point could be when an AccessToken should/needs to be verified
(e.g. via RSATokenVerifier).

One could also show the differences between the two approaches of using a
service-account and a "technical" user account.

Service Account:
- Enablement: Whole Service or just Service Account can be enabled /
disabled
- Credential: Service Account uses client credential
- Username: service-account-${client_id}
- Email: ${username}@placeholder.org
- Attributes: In datamodel but not exposeable to tokens
- Password Policy: does not apply
- Bruteforce Protection: does not apply
- Credential handling: visible in AdminConsole
- Grant type to obtain AccessToken: client_credentials
e.g.:
curl -X POST \

http://localhost:8081/auth/realms/service-to-service/protocol/openid-connect/token
\
  -d 'grant_type=client_credentials' \
  -d 'client_id=service-a' \
  -d 'client_secret=1e1ebe68-96f2-4dca-bda8-03df44d3be13'


Technical User Account:
- Enablement: User can be enabled / disabled
- Username: arbitrary
- Email: arbitrary
- Attributes: arbitrary attributes can be exposed to tokens via
ProtocolMapper
- Password Policy: applies
- Bruteforce Protection: applies
- Credential handling: hidden in AdminConsole
- Roles: can be assigned arbitrarily
- Grant type to obtain AccessToken: password -> needs Direct Access Grants
enabled
e.g:
curl -X POST \

http://localhost:8081/auth/realms/service-to-service/protocol/openid-connect/token
\
  -d 'grant_type=password' \
  -d 'client_id=admin-cli' \
  -d 'username=svc-onboarding' \
  -d 'password=secret'

When using technical user accounts it is IMHO advisable to prefix the
username of the
service users to ease differentiation between real users and "technical"
users, e.g.
"svc-onboarding", "svc-shipping".

I'm still undecided which of these approaches is best but I'm currently
leaning towards 1) for simplicity but 2) for security....

Another thing that I found:
One can define some kind of "locked-down client" that only allows
client_credentials grants
to obtain AccessTokens / RefreshTokens(IMHO).

To do that one needs to set "Standard Flow Enabled", "Implicit Flow
enabled",
"Direct Access Grants enabled" to "off" but "Service Accounts enabled" to
"On".

One could also describe how such clients could protected, e.g.
"bearer-only" or a
"confidential" client with autodetect-bearer set to true protected by one
of
the many Keycloak adapters.

Another thing to note is that using a secured channel like TLS for the
communication
between two services is IMHO still a good idea.

Cheers,
Thomas

From ssilvert at redhat.com  Thu Oct 26 21:35:11 2017
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 26 Oct 2017 21:35:11 -0400
Subject: [keycloak-dev] thoughts on file migration?
In-Reply-To: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>
References: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>
Message-ID: <b74b2cbc-3f0e-1481-9f45-82ddcf6f5216@redhat.com>

On 10/26/2017 5:07 PM, Bill Burke wrote:
> Need input on this JIRA:
>
> https://issues.jboss.org/browse/KEYCLOAK-4715
>
> The problem is that our json exports do not have a version assigned to
> them and we may have  org.keycloak.migration.migrators.Migration
> objects that need to run.
>
> Should we force people doing upgrades in this way to add a version tag
> somewhere in the json?  We should then add a "fromJson" MIgration
> method to be invoked for each appropriate migrator.
>
> That sound like a plan?
>
+1

From list-keycloak at ad-schmidt.de  Fri Oct 27 02:47:53 2017
From: list-keycloak at ad-schmidt.de (Daniel Schmidt)
Date: Fri, 27 Oct 2017 08:47:53 +0200
Subject: [keycloak-dev] Issue with BrowserHandler using the saml2 adapter in
	wildfly 10
Message-ID: <4c0dd839-cc8a-2f07-5f4a-2b90a91afc4c@ad-schmidt.de>

Hi everybody,

I just started to use the SAML2-authentication-adapter of Keycloak in 
Wildfly 10. I use it according to this documentation: 
http://www.keycloak.org/docs/3.0/securing_apps/topics/saml/java/jboss-adapter/securing_wars.html

As it did not work, I debugged into the adapter code and narrowed the 
problem down to 
org.keycloak.adapters.saml.undertow.UndertowSamlAuthenticator.createBrowserHandler(HttpFacade, 
SamlDeployment, SamlSessionStore) where a 
org.keycloak.adapters.saml.profile.webbrowsersso.BrowserHandler is 
instantiated.

This BrowserHandler always passes null as samlRequest, samlResponse and 
relayState. When I create a 
org.keycloak.adapters.saml.profile.webbrowsersso.WebBrowserSsoAuthenticationHandler 
instead, the code works as expected.

Is this a bug in the BrowserHandler or am I missing some important 
configuration option?

--

Another question on this topic:
The configuration with <secure-deployment >...</secure-deployment> 
bypasses any existing <login-module> as far as I can see. Is this the case?

Is there any possibility to configure a custom login-module that could 
authenticate a user before using the Keycloak authentication mechanism? 
I would like to use the Keycloak authentication as a fallback only.


Thanks in advance,

Daniel Schmidt


From hmlnarik at redhat.com  Fri Oct 27 03:34:27 2017
From: hmlnarik at redhat.com (Hynek Mlnarik)
Date: Fri, 27 Oct 2017 09:34:27 +0200
Subject: [keycloak-dev] Issue with BrowserHandler using the saml2
 adapter in wildfly 10
In-Reply-To: <4c0dd839-cc8a-2f07-5f4a-2b90a91afc4c@ad-schmidt.de>
References: <4c0dd839-cc8a-2f07-5f4a-2b90a91afc4c@ad-schmidt.de>
Message-ID: <CAMvXD=G5dp3tgxjANrcbGBmjj5vOsaPLad_VLvx-8DpKo1=5Bg@mail.gmail.com>

What URL have you set for the client saml endpoint in configuration at the
identity provider site? The url needs to end in "/saml" without quotes

On Fri, Oct 27, 2017 at 8:47 AM, Daniel Schmidt <list-keycloak at ad-schmidt.de
> wrote:

> Hi everybody,
>
> I just started to use the SAML2-authentication-adapter of Keycloak in
> Wildfly 10. I use it according to this documentation:
> http://www.keycloak.org/docs/3.0/securing_apps/topics/saml/
> java/jboss-adapter/securing_wars.html
>
> As it did not work, I debugged into the adapter code and narrowed the
> problem down to
> org.keycloak.adapters.saml.undertow.UndertowSamlAuthenticator.
> createBrowserHandler(HttpFacade,
> SamlDeployment, SamlSessionStore) where a
> org.keycloak.adapters.saml.profile.webbrowsersso.BrowserHandler is
> instantiated.
>
> This BrowserHandler always passes null as samlRequest, samlResponse and
> relayState. When I create a
> org.keycloak.adapters.saml.profile.webbrowsersso.
> WebBrowserSsoAuthenticationHandler
> instead, the code works as expected.
>
> Is this a bug in the BrowserHandler or am I missing some important
> configuration option?
>
> --
>
> Another question on this topic:
> The configuration with <secure-deployment >...</secure-deployment>
> bypasses any existing <login-module> as far as I can see. Is this the case?
>
> Is there any possibility to configure a custom login-module that could
> authenticate a user before using the Keycloak authentication mechanism?
> I would like to use the Keycloak authentication as a fallback only.
>
>
> Thanks in advance,
>
> Daniel Schmidt
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

--Hynek

From mposolda at redhat.com  Fri Oct 27 04:46:31 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Oct 2017 10:46:31 +0200
Subject: [keycloak-dev] Keycloak 3.3.0.Final Released
Message-ID: <b7ac46fd-67dc-0acc-84cd-296542920a1e@redhat.com>

We've just released Keycloak 3.3.0.Final.

The release contains upgrade of Keycloak server to Wildfly 11.0.0.Final. 
There are also few bugfixes there.

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

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

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

Marek

From mposolda at redhat.com  Fri Oct 27 05:48:56 2017
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Oct 2017 11:48:56 +0200
Subject: [keycloak-dev] thoughts on file migration?
In-Reply-To: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>
References: <CABRXCmwH8qgkSGq7fAfihmGEbXym2Yeh0UUjCWNLhPanjAQhZQ@mail.gmail.com>
Message-ID: <c19be06d-48cd-d046-b149-ab9b46608b7f@redhat.com>

We have version already. It's "keycloakVersion" property on 
RealmRepresentation and it's added during export. This was added in 
1.9.2.Final, so all the realm JSON exported in 1.9.2 or later will have 
that available . See https://issues.jboss.org/browse/KEYCLOAK-2613 .

But it's not used anywhere until now. The problem are hand-written JSON 
files, which don't contain the "keycloakVersion" and they also don't 
contain required built-in objects. So we're usually trying to decide 
what built-in objects should be automatically added/updated during 
import on some best-effort basis, which sometimes doesn't work 
(especially if new role was added to some existing built-in client etc) .

Maybe we can:
- Decide if JSON was hand-written based on the "keycloakVersion" present 
or not.
- For hand-written JSON, add the built-in objects automatically
- For exported JSON, use the proper migrators. We know the version, so 
we know what migrators to run.

Is it what you meant?

Marek

On 26/10/17 23:07, Bill Burke wrote:
> Need input on this JIRA:
>
> https://issues.jboss.org/browse/KEYCLOAK-4715
>
> The problem is that our json exports do not have a version assigned to
> them and we may have  org.keycloak.migration.migrators.Migration
> objects that need to run.
>
> Should we force people doing upgrades in this way to add a version tag
> somewhere in the json?  We should then add a "fromJson" MIgration
> method to be invoked for each appropriate migrator.
>
> That sound like a plan?
>


From asaldanha1947 at gmail.com  Fri Oct 27 09:28:30 2017
From: asaldanha1947 at gmail.com (Anil Saldanha)
Date: Fri, 27 Oct 2017 08:28:30 -0500
Subject: [keycloak-dev] Permission and Obligation
In-Reply-To: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>
References: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>
Message-ID: <C8644172-9AED-433F-A8B6-A9A0B3E450C4@gmail.com>

Pedro - if you are able to use a better term than ?obligation?, then you will have success in adoption. 

XACML obligations are least understood and not very well used. I never liked them unfortunately. :-(

Maybe ?condition?,?requirement? or a better term?

Ensure that these are sent from PDP to PEP.

This is an important construct that has a potential to confuse users. In my view, this is a hack in the enforcement model that xacml tries to solve. *my opinion only*


> On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> 
> Hi,
> 
> This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
> 
> The idea is allow policies to push information to a policy enforcer (PEP)
> in order to enrich the final decision if a resource can be accessed or not.
> 
> In XACML there is a well known concept called Obligation, which can be used
> to pass information to a policy enforcer in order to take some action or
> verify something before granting or denying access to a resource.
> 
> Suppose you have a JS policy and want to push obligations when evaluating a
> permission:
> 
> if (someCondition) {
>    var permission = $evaluation.getPermission();
>    permission.addObligation('transfer.limit', '200');
> }
> 
> On the resource server side, you will be able to obtain *transfer.limit*
> and check whether a request satisfy the obligation.
> 
> Any comments ?
> 
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Fri Oct 27 10:25:38 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Oct 2017 12:25:38 -0200
Subject: [keycloak-dev] Permission and Obligation
In-Reply-To: <C8644172-9AED-433F-A8B6-A9A0B3E450C4@gmail.com>
References: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>
	<C8644172-9AED-433F-A8B6-A9A0B3E450C4@gmail.com>
Message-ID: <CAJrcDBcwn1YJhA4Q+Z+0S_LRW87awObmbzKrEQdBYXSrCARhvQ@mail.gmail.com>

Hey Anil, thanks for the feedback.

You are right, obligation is probably not the best term to use here.

I did something already using "claim". Where a *permission claim*
represents assertions of the result of the decision as well a demand or
request from the PDP to PEP.

Sounds better ?

I gave just one example, but we could also use permission claims to, for
instance, force the application to ask user to raise his security level
(using some stronger authentication mechanism/flow).

On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947 at gmail.com>
wrote:

> Pedro - if you are able to use a better term than ?obligation?, then you
> will have success in adoption.
>
> XACML obligations are least understood and not very well used. I never
> liked them unfortunately. :-(
>
> Maybe ?condition?,?requirement? or a better term?
>
> Ensure that these are sent from PDP to PEP.
>
> This is an important construct that has a potential to confuse users. In
> my view, this is a hack in the enforcement model that xacml tries to solve.
> *my opinion only*
>
>
> > On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> >
> > Hi,
> >
> > This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
> >
> > The idea is allow policies to push information to a policy enforcer (PEP)
> > in order to enrich the final decision if a resource can be accessed or
> not.
> >
> > In XACML there is a well known concept called Obligation, which can be
> used
> > to pass information to a policy enforcer in order to take some action or
> > verify something before granting or denying access to a resource.
> >
> > Suppose you have a JS policy and want to push obligations when
> evaluating a
> > permission:
> >
> > if (someCondition) {
> >    var permission = $evaluation.getPermission();
> >    permission.addObligation('transfer.limit', '200');
> > }
> >
> > On the resource server side, you will be able to obtain *transfer.limit*
> > and check whether a request satisfy the obligation.
> >
> > Any comments ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From Sebastian.Schuster at bosch-si.com  Fri Oct 27 11:55:41 2017
From: Sebastian.Schuster at bosch-si.com (Schuster Sebastian (INST/ESY1))
Date: Fri, 27 Oct 2017 15:55:41 +0000
Subject: [keycloak-dev] Permission and Obligation
In-Reply-To: <CAJrcDBcwn1YJhA4Q+Z+0S_LRW87awObmbzKrEQdBYXSrCARhvQ@mail.gmail.com>
References: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>
	<C8644172-9AED-433F-A8B6-A9A0B3E450C4@gmail.com>
	<CAJrcDBcwn1YJhA4Q+Z+0S_LRW87awObmbzKrEQdBYXSrCARhvQ@mail.gmail.com>
Message-ID: <123160394b984c349f705515b38cef33@FE-MBX1028.de.bosch.com>

Hi all,

I would argue that "claim" is pretty much used by token claims. Personally, I like "obligation" as a kind of opposite to "permission".

Best regards,
Sebastian


Mit freundlichen Gr??en / Best regards

Dr.-Ing.  Sebastian Schuster

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

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



-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Freitag, 27. Oktober 2017 16:26
To: Anil Saldanha <asaldanha1947 at gmail.com>
Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Permission and Obligation

Hey Anil, thanks for the feedback.

You are right, obligation is probably not the best term to use here.

I did something already using "claim". Where a *permission claim* represents assertions of the result of the decision as well a demand or request from the PDP to PEP.

Sounds better ?

I gave just one example, but we could also use permission claims to, for instance, force the application to ask user to raise his security level (using some stronger authentication mechanism/flow).

On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947 at gmail.com>
wrote:

> Pedro - if you are able to use a better term than ?obligation?, then 
> you will have success in adoption.
>
> XACML obligations are least understood and not very well used. I never 
> liked them unfortunately. :-(
>
> Maybe ?condition?,?requirement? or a better term?
>
> Ensure that these are sent from PDP to PEP.
>
> This is an important construct that has a potential to confuse users. 
> In my view, this is a hack in the enforcement model that xacml tries to solve.
> *my opinion only*
>
>
> > On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva at redhat.com> wrote:
> >
> > Hi,
> >
> > This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
> >
> > The idea is allow policies to push information to a policy enforcer 
> > (PEP) in order to enrich the final decision if a resource can be 
> > accessed or
> not.
> >
> > In XACML there is a well known concept called Obligation, which can 
> > be
> used
> > to pass information to a policy enforcer in order to take some 
> > action or verify something before granting or denying access to a resource.
> >
> > Suppose you have a JS policy and want to push obligations when
> evaluating a
> > permission:
> >
> > if (someCondition) {
> >    var permission = $evaluation.getPermission();
> >    permission.addObligation('transfer.limit', '200'); }
> >
> > On the resource server side, you will be able to obtain 
> > *transfer.limit* and check whether a request satisfy the obligation.
> >
> > Any comments ?
> >
> > Regards.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev


From psilva at redhat.com  Fri Oct 27 14:05:08 2017
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Oct 2017 16:05:08 -0200
Subject: [keycloak-dev] Permission and Obligation
In-Reply-To: <123160394b984c349f705515b38cef33@FE-MBX1028.de.bosch.com>
References: <CAJrcDBfojUnFxHteHf2UY=ZnL+CLfkRWSuMH3qTUh6xPWUwvqQ@mail.gmail.com>
	<C8644172-9AED-433F-A8B6-A9A0B3E450C4@gmail.com>
	<CAJrcDBcwn1YJhA4Q+Z+0S_LRW87awObmbzKrEQdBYXSrCARhvQ@mail.gmail.com>
	<123160394b984c349f705515b38cef33@FE-MBX1028.de.bosch.com>
Message-ID: <CAJrcDBfJkGBPGAF-Orb_cECyf6qj0SaZ+ApbT_5ABCEL=w5DGg@mail.gmail.com>

Hi,

I think Anil has a point on the context behind obligation. Someone will
probably ask if we support advice in the future :)

The idea behind a permission claim is that it is also a claim, but related
with the a permission being granted. And its context is pretty much related
with a token: RPT.

A claim should always align with the permission, considering that it is
pushed by policies with additional information on how a resource *should*
be accessed. If PEP is going to respect these claims or not is another
thing :)

On Fri, Oct 27, 2017 at 1:55 PM, Schuster Sebastian (INST/ESY1) <
Sebastian.Schuster at bosch-si.com> wrote:

> Hi all,
>
> I would argue that "claim" is pretty much used by token claims.
> Personally, I like "obligation" as a kind of opposite to "permission".
>
> Best regards,
> Sebastian
>
>
> Mit freundlichen Gr??en / Best regards
>
> Dr.-Ing.  Sebastian Schuster
>
> Engineering and Support (INST/ESY1)
> Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin |
> GERMANY | www.bosch-si.com
> Tel. +49 30 726112-485 | Fax +49 30 726112-100 |
> Sebastian.Schuster at bosch-si.com
>
> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
> Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung:
> Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces@
> lists.jboss.org] On Behalf Of Pedro Igor Silva
> Sent: Freitag, 27. Oktober 2017 16:26
> To: Anil Saldanha <asaldanha1947 at gmail.com>
> Cc: keycloak-dev <keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Permission and Obligation
>
> Hey Anil, thanks for the feedback.
>
> You are right, obligation is probably not the best term to use here.
>
> I did something already using "claim". Where a *permission claim*
> represents assertions of the result of the decision as well a demand or
> request from the PDP to PEP.
>
> Sounds better ?
>
> I gave just one example, but we could also use permission claims to, for
> instance, force the application to ask user to raise his security level
> (using some stronger authentication mechanism/flow).
>
> On Fri, Oct 27, 2017 at 11:28 AM, Anil Saldanha <asaldanha1947 at gmail.com>
> wrote:
>
> > Pedro - if you are able to use a better term than ?obligation?, then
> > you will have success in adoption.
> >
> > XACML obligations are least understood and not very well used. I never
> > liked them unfortunately. :-(
> >
> > Maybe ?condition?,?requirement? or a better term?
> >
> > Ensure that these are sent from PDP to PEP.
> >
> > This is an important construct that has a potential to confuse users.
> > In my view, this is a hack in the enforcement model that xacml tries to
> solve.
> > *my opinion only*
> >
> >
> > > On Oct 26, 2017, at 3:08 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
> > >
> > > Hi,
> > >
> > > This is about https://issues.jboss.org/browse/KEYCLOAK-5728.
> > >
> > > The idea is allow policies to push information to a policy enforcer
> > > (PEP) in order to enrich the final decision if a resource can be
> > > accessed or
> > not.
> > >
> > > In XACML there is a well known concept called Obligation, which can
> > > be
> > used
> > > to pass information to a policy enforcer in order to take some
> > > action or verify something before granting or denying access to a
> resource.
> > >
> > > Suppose you have a JS policy and want to push obligations when
> > evaluating a
> > > permission:
> > >
> > > if (someCondition) {
> > >    var permission = $evaluation.getPermission();
> > >    permission.addObligation('transfer.limit', '200'); }
> > >
> > > On the resource server side, you will be able to obtain
> > > *transfer.limit* and check whether a request satisfy the obligation.
> > >
> > > Any comments ?
> > >
> > > Regards.
> > > Pedro Igor
> > > _______________________________________________
> > > 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 rafa.ladis at gmail.com  Sun Oct 29 20:13:57 2017
From: rafa.ladis at gmail.com (Rafael Ladislau)
Date: Mon, 30 Oct 2017 00:13:57 +0000
Subject: [keycloak-dev] Use LDAP's PasswordPolicy
Message-ID: <CABbNsjyfJv0FkHfU6FOKAnNrfP8qXV5DEFAdcdaN7Xf=aMhaOw@mail.gmail.com>

Hello, I'm pretty new here, but I've been using Keycloak with an OpenLDAP
as the user federation and I've noted some problems that I had to fix by
myself and I would like to share with the community the fixes I've made.

I'm Software Developer at NYU and I had to change the Keycloak source code
to make it works in one of our Projects. It's not a big refactoring. It's
reasonable.


Problems and my solutions:

1 - Keycloak changes the password of the users coming from LDAP sending a
replace command to LDAP using a connection bound to the LDAP administrator.
(WRITE mode). It allows the users not respect the
password policy installed in LDAP if it has it installed. In order to fix
it, you need to use a connection bound to the user changing the password,
and Keyucloak should send two commands to LDAP: a command to delete the
password field with the current password value and a command to add the
password field with the new value. It makes Keycloak respect the password
policy installed in LDAP, the operation raises an exception when the
password is not compliant, after my fixes, I'm handling this exception and
I'm letting the user knows about the error. (I'm doing this in the
UPDATE_PASSWORD required action and in the manage account screen)


2 - Because I was making Keycloak respect the password policy in LDAP, I
had to create a Password Policy User Account Control Mapper. This Mapper is
based on the MSAD User Account Control Mapper. It has the same idea, but it
writes the properties "pwdReset" and "pwdAccountLockedTime" to make
Keycloak knows and let OpenLDAP knows when the user must reset his password
and when the user is locked.


3 - The step 2 is necessary because when you have a password policy in LDAP
saying the min age is one day, and you set a temporary password for the
user. If Keycloak doesn't set the pwdReset flag, the user will not be able
to change his password. (only after 24 hours)


4 - I've made some changes in the User Federation Configuration in order to
allow the Keycloak administrator turn on and turn off this feature.


The issue https://issues.jboss.org/browse/KEYCLOAK-4052 has made the users
coming from LDAP go through the Keycloak's Password Policy before they
change their passwords, but what I'm proposing is making Keycloak be aware
of the Password Policy installed in LDAP.


Do you think it would be a good feature?

From bruno at abstractj.org  Tue Oct 31 17:51:09 2017
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 31 Oct 2017 22:51:09 +0100
Subject: [keycloak-dev] Merge of Node.js modules
Message-ID: <20171031215109.GA5152@abstractj.org>


Aloha,

We're considering the merge keycloak-nodejs-connect and keycloak-nodejs-auth-utils into a single codebase for the next release. What does that mean? That the whole codebase will live under keycloak-nodejs-connect repository and module.

The reason behind is that there are few good reasons to keep both separated today. This is going to make our release process better, as well the maintenance of the codebase.

I would like to gather some feedback before moving forward. So comments on this thread are more than welcome!

-- 

abstractj