From sthorger at redhat.com  Mon Jan  4 03:35:06 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Jan 2016 09:35:06 +0100
Subject: [keycloak-dev] Login Rest Service Service Delay
In-Reply-To: <CA+oCsRp0PXDQG05ah2Ssjf2x7rYyPZLonTKz6w9Jz27MnugXOw@mail.gmail.com>
References: <CA+oCsRp0PXDQG05ah2Ssjf2x7rYyPZLonTKz6w9Jz27MnugXOw@mail.gmail.com>
Message-ID: <CAJgngAfG1ArOiMgqWddOhxA8QMO0P1M-3DFzKuAK89QC_1gzMg@mail.gmail.com>

Not sure what you mean about fetching token id. Are you talking about the
code -> token exchange?

We'd certainly need a lot more information to have any chance on
reproducing this. How are you reproducing this? How many realms, client,
users, etc.. do you have? What db do you have?

On 29 December 2015 at 10:13, Satyajit Das <satyajit.das at spire2grow.com>
wrote:

> Hi Team,
>
> We are using login restful service of 1.4.0 final version.
>
> Sometimes the login takes quite some time(around 15 secs) to fetch the
> token id given back by login service.
>
> On subsequent call for login rest service takes very less time(75 milisecs)
>
> This is a complete random behavior.
>
> Kindly let me know how to overcome this issue.
> below is the snap of Token timeouts.
>
>
> [image: Inline image 1]
>
> Regards,
> Satya.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/bff07a93/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 23676 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/bff07a93/attachment-0001.png 

From sthorger at redhat.com  Mon Jan  4 03:37:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 4 Jan 2016 09:37:08 +0100
Subject: [keycloak-dev] Allow TOTP issuer name to be set in the admin
	console?
In-Reply-To: <399F82CA-7785-4147-AAC0-80CDE7D177C7@iland.com>
References: <399F82CA-7785-4147-AAC0-80CDE7D177C7@iland.com>
Message-ID: <CAJgngAeZ-xB0z-rg2ditR1yNShzKqD6xfG11hgX2K4UfAadc0Q@mail.gmail.com>

In 1.8 we're introducing an option to set a display name for the realm.
Would it be sufficient to use this?

On 30 December 2015 at 15:05, Cory Snyder <csnyder at iland.com> wrote:

> Hey guys,
>
> Currently the TOTP issuer is just set to the name of the realm. Since the
> issuer name is the heading of the entry that appears in the Google
> Authenticator app, we?d love to be able to customize the issuer name in the
> admin console. Would this be reasonable? Can I create a ticket?
>
> Thanks,
>
> Cory Snyder
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/4096dac3/attachment.html 

From thomas.darimont at googlemail.com  Mon Jan  4 03:39:21 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 4 Jan 2016 09:39:21 +0100
Subject: [keycloak-dev] Allow TOTP issuer name to be set in the admin
	console?
In-Reply-To: <CAJgngAeZ-xB0z-rg2ditR1yNShzKqD6xfG11hgX2K4UfAadc0Q@mail.gmail.com>
References: <399F82CA-7785-4147-AAC0-80CDE7D177C7@iland.com>
	<CAJgngAeZ-xB0z-rg2ditR1yNShzKqD6xfG11hgX2K4UfAadc0Q@mail.gmail.com>
Message-ID: <CAK-7U1iAXfjtCNOu9CMj6xMFsiqrHVPEkuTOF1se4KoBjrBqQw@mail.gmail.com>

FYI the corresponding Keycloak issue can be found here:
https://issues.jboss.org/browse/KEYCLOAK-1919

2016-01-04 9:37 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> In 1.8 we're introducing an option to set a display name for the realm.
> Would it be sufficient to use this?
>
> On 30 December 2015 at 15:05, Cory Snyder <csnyder at iland.com> wrote:
>
>> Hey guys,
>>
>> Currently the TOTP issuer is just set to the name of the realm. Since the
>> issuer name is the heading of the entry that appears in the Google
>> Authenticator app, we?d love to be able to customize the issuer name in the
>> admin console. Would this be reasonable? Can I create a ticket?
>>
>> Thanks,
>>
>> Cory Snyder
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/5aaa1416/attachment.html 

From thomas.darimont at googlemail.com  Mon Jan  4 06:11:47 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 4 Jan 2016 12:11:47 +0100
Subject: [keycloak-dev] Configurable User Federation Providers
Message-ID: <CAK-7U1gjswcu7CTbnA8g7+5gp0UcX45G=vZMFX=nuiqYJmMvSQ@mail.gmail.com>

Hello list and happy new year!

I'm implementing a custom org.keycloak.models.UserFederationProviderFactory
which should
be configurable via the keycloak admin console.

The possible configuration are currently specified via the "Set<String>
getConfigurationOptions()"
method of the UserFederationProviderFactory  interface,

Since the "Set<String" only describes the raw option names there seems to
be no way to
specify custom labels, help texts, default options, etc.

it would be great if it were possible to configure custom keycloak
federation provider factories like
custom ConfigurableAuthenticatorFactory. For the latter one can specify a
list of configuration options
via the "List<ProviderConfigProperty> getConfigProperties()" method on the
"org.keycloak.provider.ConfiguredProvider" interface.

"org.keycloak.provider.ProviderConfigProperty" has name, label, helptext,
type and defaultValue which is all I need.

It seems that currently
"org.keycloak.services.resources.admin.UserFederationProvidersResource.getProvider(String)"
isn't aware of the "ConfiguredProvider" interface. I guess making it aware
of ConfiguredProvider with some additional UI tweaks should do the trick.

What do you guys think?

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

From thomas.raehalme at aitiofinland.com  Mon Jan  4 06:53:35 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 4 Jan 2016 13:53:35 +0200
Subject: [keycloak-dev] Accessing KeycloakDeployment from
	KeycloakSecurityContext
Message-ID: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>

Hi!

At the moment KeycloakDeployment is accessible from
RefreshableKeycloakSecurityContext, but now from its superclass
KeycloakSecurityContext. Is there a reason why the deployment cannot be
accessed through the base class?

When using KeycloakConfigResolver it would simplify things if one could
access the deployment context from the security context.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/bdded4e6/attachment.html 

From mposolda at redhat.com  Mon Jan  4 08:26:44 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 4 Jan 2016 14:26:44 +0100
Subject: [keycloak-dev] Configurable User Federation Providers
In-Reply-To: <CAK-7U1gjswcu7CTbnA8g7+5gp0UcX45G=vZMFX=nuiqYJmMvSQ@mail.gmail.com>
References: <CAK-7U1gjswcu7CTbnA8g7+5gp0UcX45G=vZMFX=nuiqYJmMvSQ@mail.gmail.com>
Message-ID: <568A7314.7050101@redhat.com>

+1

I think the only reason why UserFederationProvider is not using 
ConfiguredProvider is, that ConfiguredProvider was introduced later than 
UserFederationProvier and there wasn't time for refactoring yet... Feel 
free to create JIRA for this.

Marek

On 04/01/16 12:11, Thomas Darimont wrote:
> Hello list and happy new year!
>
> I'm implementing a custom 
> org.keycloak.models.UserFederationProviderFactory which should
> be configurable via the keycloak admin console.
>
> The possible configuration are currently specified via the 
> "Set<String> getConfigurationOptions()"
> method of the UserFederationProviderFactory  interface,
>
> Since the "Set<String" only describes the raw option names there seems 
> to be no way to
> specify custom labels, help texts, default options, etc.
>
> it would be great if it were possible to configure custom keycloak 
> federation provider factories like
> custom ConfigurableAuthenticatorFactory. For the latter one can 
> specify a list of configuration options
> via the "List<ProviderConfigProperty> getConfigProperties()" method on 
> the
> "org.keycloak.provider.ConfiguredProvider" interface.
>
> "org.keycloak.provider.ProviderConfigProperty" has name, label, 
> helptext, type and defaultValue which is all I need.
>
> It seems that currently 
> "org.keycloak.services.resources.admin.UserFederationProvidersResource.getProvider(String)"
> isn't aware of the "ConfiguredProvider" interface. I guess making it 
> aware of ConfiguredProvider with some additional UI tweaks should do 
> the trick.
>
> What do you guys think?
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From csnyder at iland.com  Mon Jan  4 08:40:22 2016
From: csnyder at iland.com (Cory Snyder)
Date: Mon, 4 Jan 2016 13:40:22 +0000
Subject: [keycloak-dev] Allow TOTP issuer name to be set in the admin
 console?
In-Reply-To: <CAJgngAeZ-xB0z-rg2ditR1yNShzKqD6xfG11hgX2K4UfAadc0Q@mail.gmail.com>
References: <399F82CA-7785-4147-AAC0-80CDE7D177C7@iland.com>
	<CAJgngAeZ-xB0z-rg2ditR1yNShzKqD6xfG11hgX2K4UfAadc0Q@mail.gmail.com>
Message-ID: <B8E990BA-6652-4F18-926D-3BF82394B25C@iland.com>

This will be perfect. Thanks Stian!

Cory Snyder

On Jan 4, 2016, at 3:37 AM, Stian Thorgersen <sthorger at redhat.com<mailto:sthorger at redhat.com>> wrote:

In 1.8 we're introducing an option to set a display name for the realm. Would it be sufficient to use this?

On 30 December 2015 at 15:05, Cory Snyder <csnyder at iland.com<mailto:csnyder at iland.com>> wrote:
Hey guys,

Currently the TOTP issuer is just set to the name of the realm. Since the issuer name is the heading of the entry that appears in the Google Authenticator app, we?d love to be able to customize the issuer name in the admin console. Would this be reasonable? Can I create a ticket?

Thanks,

Cory Snyder

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


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

From thomas.darimont at googlemail.com  Mon Jan  4 09:09:04 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 4 Jan 2016 15:09:04 +0100
Subject: [keycloak-dev] Configurable User Federation Providers
In-Reply-To: <568A7314.7050101@redhat.com>
References: <CAK-7U1gjswcu7CTbnA8g7+5gp0UcX45G=vZMFX=nuiqYJmMvSQ@mail.gmail.com>
	<568A7314.7050101@redhat.com>
Message-ID: <CAK-7U1hAvVpzFD0nvFZFjyqRWWuEJA0qqHNH9G_m=EUXWt8XTA@mail.gmail.com>

Great!

Here you are:
https://issues.jboss.org/browse/KEYCLOAK-2253 - Add support for
ConfiguredProvider based UserFederationProviderFactory


2016-01-04 14:26 GMT+01:00 Marek Posolda <mposolda at redhat.com>:

> +1
>
> I think the only reason why UserFederationProvider is not using
> ConfiguredProvider is, that ConfiguredProvider was introduced later than
> UserFederationProvier and there wasn't time for refactoring yet... Feel
> free to create JIRA for this.
>
> Marek
>
>
> On 04/01/16 12:11, Thomas Darimont wrote:
>
> Hello list and happy new year!
>
> I'm implementing a custom
> org.keycloak.models.UserFederationProviderFactory which should
> be configurable via the keycloak admin console.
>
> The possible configuration are currently specified via the "Set<String>
> getConfigurationOptions()"
> method of the UserFederationProviderFactory  interface,
>
> Since the "Set<String" only describes the raw option names there seems to
> be no way to
> specify custom labels, help texts, default options, etc.
>
> it would be great if it were possible to configure custom keycloak
> federation provider factories like
> custom ConfigurableAuthenticatorFactory. For the latter one can specify a
> list of configuration options
> via the "List<ProviderConfigProperty> getConfigProperties()" method on the
> "org.keycloak.provider.ConfiguredProvider" interface.
>
> "org.keycloak.provider.ProviderConfigProperty" has name, label, helptext,
> type and defaultValue which is all I need.
>
> It seems that currently
> "org.keycloak.services.resources.admin.UserFederationProvidersResource.getProvider(String)"
> isn't aware of the "ConfiguredProvider" interface. I guess making it aware
> of ConfiguredProvider with some additional UI tweaks should do the trick.
>
> What do you guys think?
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160104/668a4490/attachment.html 

From thomas.raehalme at aitiofinland.com  Tue Jan  5 02:14:07 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 5 Jan 2016 09:14:07 +0200
Subject: [keycloak-dev] Release notes for the next release
Message-ID: <CAPyAMoaCFcg0k0rXyWmvWyx4b029k-8ZcG998yNp2vE81d9B0A@mail.gmail.com>

Hi!

My pull request #1945 [1] was merged yesterday, that's great!

Since the changes may break backwards compatibility I suggest something
like the following is added to the release notes regarding the Spring
Security adapter:

The AdapterDeploymentContextBean has been replaced with
AdapterDeploymentContextFactoryBean which is a Spring BeanFactory
implementation for AdapterDeploymentContext. The constructor accepts either
a Resource to specify where the keycloak.json resides (as before), or a
KeycloakConfigResolver which will then resolve the configuration at
runtime.

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

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160105/198a04a2/attachment.html 

From satyajit.das at spire2grow.com  Tue Jan  5 02:47:54 2016
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Tue, 5 Jan 2016 13:17:54 +0530
Subject: [keycloak-dev] Additional Required functionalities
Message-ID: <CA+oCsRqk2WGZH1PpMRx1PGd7zRqAVRCw6JO5eMRzMPA2qenEmg@mail.gmail.com>

Hi Team,

Can you guys please incorporate the below functionalities in subsequent
releases.

1)Bulk User creation via restful services(for a particular realm)
2)Reset password/ Forgot password functionality for a particular user via
restful services.
3)Social network ids registration and login via restful services eg: google
or facebook registering to keycloak.


Regards,
Satya.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160105/69893eba/attachment.html 

From sthorger at redhat.com  Tue Jan  5 03:06:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 5 Jan 2016 09:06:00 +0100
Subject: [keycloak-dev] Additional Required functionalities
In-Reply-To: <CA+oCsRqk2WGZH1PpMRx1PGd7zRqAVRCw6JO5eMRzMPA2qenEmg@mail.gmail.com>
References: <CA+oCsRqk2WGZH1PpMRx1PGd7zRqAVRCw6JO5eMRzMPA2qenEmg@mail.gmail.com>
Message-ID: <CAJgngAcFPM2hxKAd2GuN3ospzhNFWfuSXa=0EKHauzJCDo6yxw@mail.gmail.com>

On 5 January 2016 at 08:47, Satyajit Das <satyajit.das at spire2grow.com>
wrote:

> Hi Team,
>
> Can you guys please incorporate the below functionalities in subsequent
> releases.
>
> 1)Bulk User creation via restful services(for a particular realm)
>

Should be coming soon through partial import/export feature we're adding


> 2)Reset password/ Forgot password functionality for a particular user via
> restful services.
>

We have this for admin endpoints


> 3)Social network ids registration and login via restful services eg:
> google or facebook registering to keycloak.
>

Not sure what you mean, but you can create users and register social links
through the admin endpoints


>
>
> Regards,
> Satya.
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160105/3f6a21cc/attachment.html 

From erik.mulder at docdatapayments.com  Wed Jan  6 03:29:44 2016
From: erik.mulder at docdatapayments.com (Erik Mulder)
Date: Wed, 6 Jan 2016 09:29:44 +0100
Subject: [keycloak-dev] Control over audience parameter in JWT token
References: <9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local>
Message-ID: <9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local>

Bump...
Can anybody shed his light on this? Thanks!


On 31/12/15 12:42, Erik Mulder wrote:
In the JWT token there is a field 'aud', or audience, which function is to state for which client(s) that token is intended.
Currently (TokenManager:433) this is set to the client id:

token.audience(client.getClientId());

This seems fine in general, but we would like to have a token with multiple entries in the audience field. This is possible and an array value is even claimed to be the 'general case': https://tools.ietf.org/html/rfc7519#section-4.1.3 (where one single value is the 'special case')

Background is that we have a Keycloak running for a login of a frontend that talks to multiple different resource servers. We'd prefer to use one token for all of those resource servers. The resource servers use Spring Security, which explicitly checks that the 'name' you give to your Spring service is matched by (a value of) the audience field of the JWT token. So now we have to give all resource servers the same 'name', which doesn't feel right.

So we need some way to influence the value of the audience field. This could be achieved by following this RFC: https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 which suggests to include a parameter to the request for the token. But that RFC does not consider multiple values for the audience. Another option would be to add an audience field in the settings of a Client in Keycloak. Which would, if set, define the audience field of the JWT token. This could be a comma separated string value that would translate to a JSON array. A question about this could be: 'then where to leave the client id?'. As suggested by this: https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token the best place to put the client id is in the 'azp' field (authorized party).

Does the KeyCloak team see this as a valuable addition? Will it be implemented somewhere in the future? Or can we make a pull request ourselves that will be merged?

Thanks, Erik

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

From mposolda at redhat.com  Wed Jan  6 03:49:53 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 6 Jan 2016 09:49:53 +0100
Subject: [keycloak-dev] Control over audience parameter in JWT token
In-Reply-To: <9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local>
References: <9A5619B792BBA041AE094585791BB71C013B9D4BE4AC@DDPEX01.DDP.dcloud.local>
	<9A5619B792BBA041AE094585791BB71C013B9D4BE4AD@DDPEX01.DDP.dcloud.local>
Message-ID: <568CD531.2060508@redhat.com>

I think you can write custom protocol mapper, which will change the 
value of audience in accessToken according to your preferences.

Some more comments/options inline...

On 06/01/16 09:29, Erik Mulder wrote:
> Bump...
> Can anybody shed his light on this? Thanks!
>
>
> On 31/12/15 12:42, Erik Mulder wrote:
>> In the JWT token there is a field 'aud', or audience, which function 
>> is to state for which client(s) that token is intended.
>> Currently (TokenManager:433) this is set to the client id:
>>
>> token.audience(client.getClientId());
>>
>> This seems fine in general, but we would like to have a token with 
>> multiple entries in the audience field. This is possible and an array 
>> value is even claimed to be the 'general case': 
>> https://tools.ietf.org/html/rfc7519#section-4.1.3 (where one single 
>> value is the 'special case')
>>
>> Background is that we have a Keycloak running for a login of a 
>> frontend that talks to multiple different resource servers. We'd 
>> prefer to use one token for all of those resource servers. The 
>> resource servers use Spring Security, which explicitly checks that 
>> the 'name' you give to your Spring service is matched by (a value of) 
>> the audience field of the JWT token. So now we have to give all 
>> resource servers the same 'name', which doesn't feel right.
Isn't is possible to disable this checking in Spring security on 
Resource server side? I think once you verify token signature and 
issuer, you should be fine.

Btv. Our adapters doesn't require that. You can have same resource 
server (REST service etc), which allows to serve requests from multiple 
different clients with different audiences in token. For example see our 
demo where "customer-portal" and "product-portal" are different clients, 
but they both access same REST service ( database.war ).

So another option for you might be to migrate to use our adapters? We 
even have Spring adapter.
>>
>> So we need some way to influence the value of the audience field. 
>> This could be achieved by following this RFC: 
>> https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 which 
>> suggests to include a parameter to the request for the token. But 
>> that RFC does not consider multiple values for the audience. Another 
>> option would be to add an audience field in the settings of a Client 
>> in Keycloak. Which would, if set, define the audience field of the 
>> JWT token. This could be a comma separated string value that would 
>> translate to a JSON array. A question about this could be: 'then 
>> where to leave the client id?'. As suggested by this: 
>> https://stackoverflow.com/questions/32013835/client-id-or-multiple-audiences-in-json-web-token 
>> the best place to put the client id is in the 'azp' field (authorized 
>> party).
Maybe we can add it, but can't promise at 100%... Feel free to create 
JIRA. But IMO the audience field in client settings shouldn't be 
mandatory and if it's not set, it will default to clientId like it's 
now. This will be also backwards compatible.

Marek
>>
>> Does the KeyCloak team see this as a valuable addition? Will it be 
>> implemented somewhere in the future? Or can we make a pull request 
>> ourselves that will be merged?
>>
>> Thanks, Erik
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mposolda at redhat.com  Wed Jan  6 04:11:11 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 6 Jan 2016 10:11:11 +0100
Subject: [keycloak-dev] Accessing KeycloakDeployment from
 KeycloakSecurityContext
In-Reply-To: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>
References: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>
Message-ID: <568CDA2F.8010800@redhat.com>

Not sure, I am like 50/50 . I agree it can simplify some scenarios when 
KeycloakDeployment is accessible from KeycloakSecurityContext. On the 
other hand, KeycloakDeployment exposes some info, which is not necessary 
to be exposed in client apps.

I think you can just cast KeycloakSecurityContext to 
RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?

Marek

On 04/01/16 12:53, Thomas Raehalme wrote:
> Hi!
>
> At the moment KeycloakDeployment is accessible from 
> RefreshableKeycloakSecurityContext, but now from its superclass 
> KeycloakSecurityContext. Is there a reason why the deployment cannot 
> be accessed through the base class?
>
> When using KeycloakConfigResolver it would simplify things if one 
> could access the deployment context from the security context.
>
> Best regards,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From Shankar_Bhaskaran at infosys.com  Wed Jan  6 04:17:54 2016
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Wed, 6 Jan 2016 09:17:54 +0000
Subject: [keycloak-dev] Keycloak Pentaho Integration
Message-ID: <1fedf55682134c47a1c74305bc27be91@CHNSHLMBX32.ad.infosys.com>

Hi ,

I want to integrates SSO to Pentaho 6 BI server. On checking with the Pentaho team they informed that : If Keycloak can authenticate a visitor via a webservice, you can write the Spring Security based Pentaho extensions to authenticate using Keycloak. Again, they don't  directly support Keycloak, but they  can give you information about how to switch to a web services based authentication and authorization system.

Does keycloak authenticate a user via webservice. If so could you direct me to the documentation

Regards,
Shankar

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/122fac5f/attachment.html 

From pawan at knowledgeflux.com  Wed Jan  6 04:45:16 2016
From: pawan at knowledgeflux.com (Pawan Thakur)
Date: Wed, 6 Jan 2016 09:45:16 +0000
Subject: [keycloak-dev] Help with Integration on Spring App on Tomcat 7
Message-ID: <KL1PR04MB106132B899BE4DA15294869AA9F40@KL1PR04MB1061.apcprd04.prod.outlook.com>

Hello All,

I am new to Key Cloak and trying to integrate this with a very basic two-page application to understand the working and integration basics.

Environment:


1.       KeyCloack 1.7.1 Final Standalone

2.       A Basic Spring Application deployed on Tomcat 7

What I have referred:

http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html_single/index.html#tomcat-adapter
Tutorial Videos from Youtube Basic 1 and 2

Issues am facing:

When I set auth-method to KEYCLOAK

<login-config>
       <auth-method>KEYCLOAK</auth-method>
       <realm-name>KnowledgeFlux</realm-name>
</login-config>

I get the following error

Jan 06, 2016 2:12:58 PM org.apache.catalina.startup.ContextConfig authenticatorConfig
SEVERE: Cannot configure an authenticator for method KEYCLOAK
Jan 06, 2016 2:12:58 PM org.apache.catalina.startup.ContextConfig configureStart
SEVERE: Marking this application unavailable due to previous error(s)

When I set auth-method to BASIC

<login-config>
       <auth-method>BASIC</auth-method>
       <realm-name>KnowledgeFlux</realm-name>
</login-config>

Application runs fine but doesn't authenticate even though the user is able to login to Keycloak Realm's account.

What my files look like

Web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns="http://java.sun.com/xml/ns/javaee"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
       id="WebApp_ID" version="3.0">
       <display-name>Archetype Created Web Application</display-name>
       <servlet>
              <servlet-name>dispatcher</servlet-name>
              <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
              <load-on-startup>1</load-on-startup>
       </servlet>

       <servlet-mapping>
              <servlet-name>dispatcher</servlet-name>
              <url-pattern>/</url-pattern>
       </servlet-mapping>

       <context-param>
              <param-name>contextConfigLocation</param-name>
              <param-value>/WEB-INF/dispatcher-servlet.xml</param-value>
       </context-param>

       <listener>
              <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
       </listener>

       <security-constraint>
              <web-resource-collection>
                     <web-resource-name>CloakTest</web-resource-name>
                     <url-pattern>/*</url-pattern>
              </web-resource-collection>
              <auth-constraint>
                     <role-name>User</role-name>
              </auth-constraint>
       </security-constraint>

       <login-config>
              <auth-method>KEYCLOAK</auth-method>
              <realm-name>KnowledgeFlux</realm-name>
       </login-config>

       <security-role>
              <role-name>admin</role-name>
       </security-role>
       <security-role>
              <role-name>User</role-name>
       </security-role>

</web-app>

Keycloak.json

{
  "realm": "KnowledgeFlux",
  "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAggGsu2SLSsgi7WmVb4O2HGQX7CjcZQG3+LK0Ael6ErNf3dsv4eAR7dTw7OP3hSl57ByCuX5srFFnOMQR+WrjGFv6osaabzRAqYgfKF9H0dIuBLDfFcohGG1EIWh6jVn+jifflnEw7kbycKlXypuvrev7FXi0v1/8Iy/VPdRk+iVgSSIwU/InNPOrodVF/CV6p9VcPqGbDcOSdC0gu6kUA8S4Y6zVRtszlBD3g07p8QhkjoUeKHgHAT0CeCpLoe57ud9iTPTpX0iBnDCysJOQYK3FGAiz6Z9C/puolcrUIcuiasM6Z9bgglNTFvZCbk/XSDGTFKqkJGdcraeVdbQx3wIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "external",
  "resource": "CloakTest",
  "public-client": true
}

META-INF/context.xml

<?xml version="1.0"?>
<Context path="/CloakTest">
    <Valve className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>
</Context>


Note:  Application's name is CloakTest and am using the same name for the client and my realm's name is KnowledgeFlux

I have googled for similar issues with no luck and it's been a while since I am stuck here.
Please assist.

P.S. Sorry for the essay but I added as much detail as I thought would be necessary.

Thanks,
Pawan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/99fd74bb/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Wed Jan  6 04:51:44 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 6 Jan 2016 11:51:44 +0200
Subject: [keycloak-dev] Accessing KeycloakDeployment from
	KeycloakSecurityContext
In-Reply-To: <568CDA2F.8010800@redhat.com>
References: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>
	<568CDA2F.8010800@redhat.com>
Message-ID: <CAPyAMobbDDzF04GvfsxwFJFFcDGw6DOdFJb--UQdhCFyYwLaXQ@mail.gmail.com>

On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Not sure, I am like 50/50 . I agree it can simplify some scenarios when
> KeycloakDeployment is accessible from KeycloakSecurityContext. On the other
> hand, KeycloakDeployment exposes some info, which is not necessary to be
> exposed in client apps.
>

I haven't really studied the details of KeycloakDeployment, but was under
the impression that it just holds the data from keycloak.json with the
addition of some client related info obtained from Keycloak. Is there
anything that needs to be hidden from the client especially if the client
can still obtain the object through RefreshableKeycloakSecurityContext?

What I was interested in was the accountUrl and resourceName so that I can
provide a link to users to change their password.


> I think you can just cast KeycloakSecurityContext to
> RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?
>

That's what I'm doing now, but I think it's more of a hack than a real
solution.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/8dd5513c/attachment.html 

From bburke at redhat.com  Wed Jan  6 08:24:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 6 Jan 2016 08:24:10 -0500
Subject: [keycloak-dev] Keycloak Pentaho Integration
In-Reply-To: <1fedf55682134c47a1c74305bc27be91@CHNSHLMBX32.ad.infosys.com>
References: <1fedf55682134c47a1c74305bc27be91@CHNSHLMBX32.ad.infosys.com>
Message-ID: <568D157A.3030800@redhat.com>

You mean a backend call?  You can do it, but you won't get SSO this way.

On 1/6/2016 4:17 AM, Shankar_Bhaskaran wrote:
> Hi ,
>
> I want to integrates SSO to Pentaho 6 BI server. On checking with the
> Pentaho team they informed that : If Keycloak can authenticate a visitor
> via a webservice, you can write the Spring Security based Pentaho
> extensions to authenticate using Keycloak. Again, they don?t  directly
> support Keycloak, but they  can give you information about how to switch
> to a web services based authentication and authorization system.
>
> Does keycloak authenticate a user via webservice. If so could you direct
> me to the documentation
>
> Regards,
>
> Shankar
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From srossillo at smartling.com  Wed Jan  6 09:48:27 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Wed, 6 Jan 2016 09:48:27 -0500
Subject: [keycloak-dev] Accessing KeycloakDeployment from
	KeycloakSecurityContext
In-Reply-To: <CAPyAMobbDDzF04GvfsxwFJFFcDGw6DOdFJb--UQdhCFyYwLaXQ@mail.gmail.com>
References: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>
	<568CDA2F.8010800@redhat.com>
	<CAPyAMobbDDzF04GvfsxwFJFFcDGw6DOdFJb--UQdhCFyYwLaXQ@mail.gmail.com>
Message-ID: <ACBF3B22-D112-4CF9-AB78-5616B8B19BE9@smartling.com>

We?re casting as well. I think the only time a KeycloakSecurityContext is not a RefreshableKeycloakSecurityContext is when you make a request from one client to another. I agree the codebase could really be improved here to avoid the constant casts. I?m thinking of sending a PR to improve this.


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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Jan 6, 2016, at 4:51 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com> wrote:
> 
> On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
> Not sure, I am like 50/50 . I agree it can simplify some scenarios when KeycloakDeployment is accessible from KeycloakSecurityContext. On the other hand, KeycloakDeployment exposes some info, which is not necessary to be exposed in client apps. 
> 
> I haven't really studied the details of KeycloakDeployment, but was under the impression that it just holds the data from keycloak.json with the addition of some client related info obtained from Keycloak. Is there anything that needs to be hidden from the client especially if the client can still obtain the object through RefreshableKeycloakSecurityContext?
> 
> What I was interested in was the accountUrl and resourceName so that I can provide a link to users to change their password. 
>  
> I think you can just cast KeycloakSecurityContext to RefreshableKeycloakSecurityContext and get KeycloakDeployment from there?
> 
> That's what I'm doing now, but I think it's more of a hack than a real solution.
> 
> Best regards,
> Thomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Wed Jan  6 10:13:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 6 Jan 2016 16:13:50 +0100
Subject: [keycloak-dev] 1.8.0.CR1 release and remaining work
Message-ID: <CAJgngAcVqun6QKPp6ihDOABOOCeA=kmVvhxE7Cmh1viimXpkwQ@mail.gmail.com>

All,

I want all remaining work to be completed by end of Friday, this includes
any features and bugs.

We'll start testing on Monday and aim to release on Wednesday by the latest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160106/6efde97a/attachment.html 

From bburke at redhat.com  Wed Jan  6 10:17:34 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 6 Jan 2016 10:17:34 -0500
Subject: [keycloak-dev] Accessing KeycloakDeployment from
 KeycloakSecurityContext
In-Reply-To: <ACBF3B22-D112-4CF9-AB78-5616B8B19BE9@smartling.com>
References: <CAPyAMoZLS326hM5ekGchmxj79O-G1AAfM=fHq5aUgKi0_nZeOg@mail.gmail.com>
	<568CDA2F.8010800@redhat.com>
	<CAPyAMobbDDzF04GvfsxwFJFFcDGw6DOdFJb--UQdhCFyYwLaXQ@mail.gmail.com>
	<ACBF3B22-D112-4CF9-AB78-5616B8B19BE9@smartling.com>
Message-ID: <568D300E.8010300@redhat.com>

A bearer token request does not have RefreshableKeycloakSecurityContext.

On 1/6/2016 9:48 AM, Scott Rossillo wrote:
> We?re casting as well. I think the only time a KeycloakSecurityContext
> is not a RefreshableKeycloakSecurityContext is when you make a request
> from one client to another. I agree the codebase could really be
> improved here to avoid the constant casts. I?m thinking of sending a PR
> to improve this.
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
> Latest News + Events <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> Powered by Sigstr <http://www.sigstr.com/>
>
>> On Jan 6, 2016, at 4:51 AM, Thomas Raehalme
>> <thomas.raehalme at aitiofinland.com
>> <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>>
>> On Wed, Jan 6, 2016 at 11:11 AM, Marek Posolda <mposolda at redhat.com
>> <mailto:mposolda at redhat.com>> wrote:
>>
>>     Not sure, I am like 50/50 . I agree it can simplify some scenarios
>>     when KeycloakDeployment is accessible from
>>     KeycloakSecurityContext. On the other hand, KeycloakDeployment
>>     exposes some info, which is not necessary to be exposed in client
>>     apps.
>>
>>
>> I haven't really studied the details of KeycloakDeployment, but was
>> under the impression that it just holds the data from keycloak.json
>> with the addition of some client related info obtained from Keycloak.
>> Is there anything that needs to be hidden from the client especially
>> if the client can still obtain the object through
>> RefreshableKeycloakSecurityContext?
>>
>> What I was interested in was the accountUrl and resourceName so that I
>> can provide a link to users to change their password.
>>
>>     I think you can just cast KeycloakSecurityContext to
>>     RefreshableKeycloakSecurityContext and get KeycloakDeployment from
>>     there?
>>
>>
>> That's what I'm doing now, but I think it's more of a hack than a real
>> solution.
>>
>> Best regards,
>> Thomas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Wed Jan  6 11:09:58 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 6 Jan 2016 17:09:58 +0100
Subject: [keycloak-dev] 1.8.0.CR1 release and remaining work
In-Reply-To: <CAJgngAcVqun6QKPp6ihDOABOOCeA=kmVvhxE7Cmh1viimXpkwQ@mail.gmail.com>
References: <CAJgngAcVqun6QKPp6ihDOABOOCeA=kmVvhxE7Cmh1viimXpkwQ@mail.gmail.com>
Message-ID: <568D3C56.4020303@redhat.com>

I am out on Thu+Fri and likely won't be able to finish support of 
PostgresPlus and DB2 by today. I hope not a blocker to postpone this to 
1.9 ? Will continue investigating this after release, so should be avail 
for 1.9.

Marek

On 06/01/16 16:13, Stian Thorgersen wrote:
> All,
>
> I want all remaining work to be completed by end of Friday, this 
> includes any features and bugs.
>
> We'll start testing on Monday and aim to release on Wednesday by the 
> latest.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From psilva at redhat.com  Wed Jan  6 13:18:33 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Jan 2016 13:18:33 -0500 (EST)
Subject: [keycloak-dev] An STS for the Rest of Us
In-Reply-To: <1105618809.5343373.1452104254228.JavaMail.zimbra@redhat.com>
Message-ID: <2045173140.5345448.1452104313354.JavaMail.zimbra@redhat.com>

Hi All !

Is anyone interest on this [1] ?

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

From psilva at redhat.com  Wed Jan  6 14:46:54 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 6 Jan 2016 14:46:54 -0500 (EST)
Subject: [keycloak-dev] OAuth2 Token Introspection
Message-ID: <1012958015.5486937.1452109614908.JavaMail.zimbra@redhat.com>

Hi All!

Any thoughts on this one [1] ?

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

Regards.
Pedro Igor

From ayoung at redhat.com  Thu Jan  7 13:44:19 2016
From: ayoung at redhat.com (Adam Young)
Date: Thu, 7 Jan 2016 13:44:19 -0500
Subject: [keycloak-dev] Deploying Keycloak via Ansible
Message-ID: <568EB203.8010509@redhat.com>

For my work, I need to be able to automate deploying Keycloak.  I've 
been using Ansible, so, here is my first hack at it:

http://adam.younglogic.com/2016/01/deploying-keycloak-via-ansible/

Feedback welcome.



From bruno at abstractj.org  Thu Jan  7 21:35:28 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 8 Jan 2016 00:35:28 -0200
Subject: [keycloak-dev] Integration tests for Brute force
Message-ID: <CAM5SUC4rwfZ4uxO43tDz3jGnzdHDEAPhK2GuaQ40+X=Lh6RWiw@mail.gmail.com>

Good morning, I'm looking at this
https://issues.jboss.org/browse/KEYCLOAK-2151 and would like to know
where I can find the integration tests for brute force. If they don't
exist, which place would be the best to add?

I would like to reproduce exactly the same scenario described on that jira:

1. try to login several times with a username that doesn't exist
2. register the user
3. try to login with the correct credentials

I started to look at
https://github.com/keycloak/keycloak/blob/a5c159eeffaec051a15b94ac5129c42d511fce29/testsuite/integration/src/test/java/org/keycloak/testsuite/model/UserSessionProviderTest.java#L27-L27
with not too much luck.

Thanks in advance.

-- 
- abstractj

From sthorger at redhat.com  Fri Jan  8 02:31:31 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Jan 2016 08:31:31 +0100
Subject: [keycloak-dev] Integration tests for Brute force
In-Reply-To: <CAM5SUC4rwfZ4uxO43tDz3jGnzdHDEAPhK2GuaQ40+X=Lh6RWiw@mail.gmail.com>
References: <CAM5SUC4rwfZ4uxO43tDz3jGnzdHDEAPhK2GuaQ40+X=Lh6RWiw@mail.gmail.com>
Message-ID: <CAJgngAfz-j7ua6mXK-KVjvsj8p3dzYA5D3u6zMD8jhBaRNe5qA@mail.gmail.com>

This is the one:
org.keycloak.testsuite.forms.BruteForceTest

For user registration look at:
org.keycloak.testsuite.forms.RegisterTest

For extra brownie points you could also migrate the above tests to the
Arquillian based integration testsuite (integration-arquillian).

On 8 January 2016 at 03:35, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning, I'm looking at this
> https://issues.jboss.org/browse/KEYCLOAK-2151 and would like to know
> where I can find the integration tests for brute force. If they don't
> exist, which place would be the best to add?
>
> I would like to reproduce exactly the same scenario described on that jira:
>
> 1. try to login several times with a username that doesn't exist
> 2. register the user
> 3. try to login with the correct credentials
>
> I started to look at
>
> https://github.com/keycloak/keycloak/blob/a5c159eeffaec051a15b94ac5129c42d511fce29/testsuite/integration/src/test/java/org/keycloak/testsuite/model/UserSessionProviderTest.java#L27-L27
> with not too much luck.
>
> Thanks in advance.
>
> --
> - abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/5e413bd2/attachment.html 

From juraci at kroehling.de  Fri Jan  8 04:08:40 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Fri, 8 Jan 2016 10:08:40 +0100
Subject: [keycloak-dev] Deploying Keycloak via Ansible
In-Reply-To: <568EB203.8010509@redhat.com>
References: <568EB203.8010509@redhat.com>
Message-ID: <568F7C98.8030501@kroehling.de>

Looks really nice! A couple of comments:

1) I'd rather not open the management port on firewalld. If I would need 
to access the Wildfly console, I'd make a SSH tunnel and load it as if 
it were localhost. IIRC, the management ports are bound only to 
localhost anyway, so, opening the management port is not effective.

2) I'd follow the standards from the Wildfly package. Run

$ rpm -ql wildfly

to see where Wildfly puts the stuff. But instead of installing things on 
/usr/share/wildfly, for instance, you could install on 
/usr/share/keycloak , copying the SELinux context from 
/usr/share/wildfly . This way, you get the extra security features from 
that.

Those are only "nice things to have" and all in all, I think you did a 
great job with this!

- Juca.

On 07.01.2016 19:44, Adam Young wrote:
> For my work, I need to be able to automate deploying Keycloak.  I've
> been using Ansible, so, here is my first hack at it:
>
> http://adam.younglogic.com/2016/01/deploying-keycloak-via-ansible/
>
> Feedback welcome.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bruno at abstractj.org  Fri Jan  8 06:14:08 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 08 Jan 2016 11:14:08 +0000
Subject: [keycloak-dev] Integration tests for Brute force
In-Reply-To: <CAJgngAfz-j7ua6mXK-KVjvsj8p3dzYA5D3u6zMD8jhBaRNe5qA@mail.gmail.com>
References: <CAM5SUC4rwfZ4uxO43tDz3jGnzdHDEAPhK2GuaQ40+X=Lh6RWiw@mail.gmail.com>
	<CAJgngAfz-j7ua6mXK-KVjvsj8p3dzYA5D3u6zMD8jhBaRNe5qA@mail.gmail.com>
Message-ID: <CAM5SUC4eMXTb6y8ixXg60v7burHuKL3zJNPhXccoi-G8hGjkBg@mail.gmail.com>

Thank you!

On Fri, Jan 8, 2016, 5:31 AM Stian Thorgersen <sthorger at redhat.com> wrote:

> This is the one:
> org.keycloak.testsuite.forms.BruteForceTest
>
> For user registration look at:
> org.keycloak.testsuite.forms.RegisterTest
>
> For extra brownie points you could also migrate the above tests to the
> Arquillian based integration testsuite (integration-arquillian).
>
> On 8 January 2016 at 03:35, Bruno Oliveira <bruno at abstractj.org> wrote:
>
>> Good morning, I'm looking at this
>> https://issues.jboss.org/browse/KEYCLOAK-2151 and would like to know
>> where I can find the integration tests for brute force. If they don't
>> exist, which place would be the best to add?
>>
>> I would like to reproduce exactly the same scenario described on that
>> jira:
>>
>> 1. try to login several times with a username that doesn't exist
>> 2. register the user
>> 3. try to login with the correct credentials
>>
>> I started to look at
>>
>> https://github.com/keycloak/keycloak/blob/a5c159eeffaec051a15b94ac5129c42d511fce29/testsuite/integration/src/test/java/org/keycloak/testsuite/model/UserSessionProviderTest.java#L27-L27
>> with not too much luck.
>>
>> Thanks in advance.
>>
>
>> --
>> - abstractj
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/f0ac1f84/attachment.html 

From thomas.raehalme at aitiofinland.com  Fri Jan  8 06:32:43 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 8 Jan 2016 13:32:43 +0200
Subject: [keycloak-dev] Why the provider prefix in username?
Message-ID: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>

Hi,

If I login to Keycloak using a federated identity such as Google, Keycloak
inserts a prefix "google." to my username.

Maybe I'm missing something, but isn't this kind of unnecessary when the
email address is already a unique property?

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/2adbe3e7/attachment.html 

From sthorger at redhat.com  Fri Jan  8 07:05:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Jan 2016 13:05:35 +0100
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
Message-ID: <CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>

It's to make it less likely that the username is already in use. We could
use email for the username in those cases, but email is not always
available. In the past we didn't have a way to allow the user to change the
username if there was a conflict and instead the first login would just
fail. With the introduction of first time social flows we could improve on
this.

We could allow selecting the strategy to use. Then allow the user to change
if there's a conflict. We already allow users to change email if there's a
conflict so can do the same for username.

On 8 January 2016 at 12:32, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> Hi,
>
> If I login to Keycloak using a federated identity such as Google, Keycloak
> inserts a prefix "google." to my username.
>
> Maybe I'm missing something, but isn't this kind of unnecessary when the
> email address is already a unique property?
>
> Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/c6aa2cd6/attachment-0001.html 

From velias at redhat.com  Fri Jan  8 07:40:46 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 8 Jan 2016 13:40:46 +0100
Subject: [keycloak-dev] Is keycloak Java 8 only now? Where is it documented?
Message-ID: <568FAE4E.3050300@redhat.com>

Hi,

I rebased my local Keycloak source codes to latest master yesterday, and
got compilation error in
org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
class, because of import of classes from java.util.function package.
Investigation shown me that these classes are available in Java 8+ only.

Does this mean that next version of Keycloak (1.8) is targeted to run on
Java 8 only?

Is this documented somewhere? Main readme at
https://github.com/keycloak/keycloak still states "Ensure you have JDK 7
(or newer)" in build section. And I was not able to find any other info
about required java version in user doc (eg Installation chapter).

And I also realized that Keycloak's parent pom file (and all subprojet
poms also) miss any information about target java version.
There was this definition in pom file a year ago, but looks like Stian
removed it 9 months ago:

        <!-- maven-compiler-plugin -->

        <maven.compiler.target>1.7</maven.compiler.target>

        <maven.compiler.source>1.7</maven.compiler.source>

This brings a small problem when importing the project into Eclipse, as
it is not able to correctly set java version for the project.
But maybe there is some reason why this is not in the pom? (I can
imagine that adapters use lower java version than the Keycloak server)

Is it possible to clear this somehow, at least in the documentation?

Thanks

Vlastimil

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team




From sthorger at redhat.com  Fri Jan  8 07:53:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Jan 2016 13:53:00 +0100
Subject: [keycloak-dev] Is keycloak Java 8 only now? Where is it
	documented?
In-Reply-To: <568FAE4E.3050300@redhat.com>
References: <568FAE4E.3050300@redhat.com>
Message-ID: <CAJgngAeb-oL3zvcWLXncMpgGmf4FDhMZsPkCx94erVAp=knhpA@mail.gmail.com>

Java 8 is now required to build due to switch to WildFly 10. The target
Java version is inherited from JBoss parent (
https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L132).

Next release (1.8) will require Java 8 on server-side, but still support
Java 7 on the client-side.

Oracle stopped supporting Java 7 early last year, so maybe it's time to
move on ;)

I'll update the readme's though.

On 8 January 2016 at 13:40, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> I rebased my local Keycloak source codes to latest master yesterday, and
> got compilation error in
> org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
> class, because of import of classes from java.util.function package.
> Investigation shown me that these classes are available in Java 8+ only.
>
> Does this mean that next version of Keycloak (1.8) is targeted to run on
> Java 8 only?
>
> Is this documented somewhere? Main readme at
> https://github.com/keycloak/keycloak still states "Ensure you have JDK 7
> (or newer)" in build section. And I was not able to find any other info
> about required java version in user doc (eg Installation chapter).
>
> And I also realized that Keycloak's parent pom file (and all subprojet
> poms also) miss any information about target java version.
> There was this definition in pom file a year ago, but looks like Stian
> removed it 9 months ago:
>
>         <!-- maven-compiler-plugin -->
>
>         <maven.compiler.target>1.7</maven.compiler.target>
>
>         <maven.compiler.source>1.7</maven.compiler.source>
>
> This brings a small problem when importing the project into Eclipse, as
> it is not able to correctly set java version for the project.
> But maybe there is some reason why this is not in the pom? (I can
> imagine that adapters use lower java version than the Keycloak server)
>
> Is it possible to clear this somehow, at least in the documentation?
>
> Thanks
>
> Vlastimil
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/93d0eba8/attachment.html 

From velias at redhat.com  Fri Jan  8 09:01:59 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Fri, 8 Jan 2016 15:01:59 +0100
Subject: [keycloak-dev] Is keycloak Java 8 only now? Where is it
 documented?
In-Reply-To: <CAJgngAeb-oL3zvcWLXncMpgGmf4FDhMZsPkCx94erVAp=knhpA@mail.gmail.com>
References: <568FAE4E.3050300@redhat.com>
	<CAJgngAeb-oL3zvcWLXncMpgGmf4FDhMZsPkCx94erVAp=knhpA@mail.gmail.com>
Message-ID: <568FC157.1070203@redhat.com>

Sure thing, I only want to be sure what is going on and if it is
documented properly.
Looks like EAP 6.4 can run on Java 8 so it shouldn't be so big problem
for us.

Vlastimil

On 8.1.2016 13:53, Stian Thorgersen wrote:
> Java 8 is now required to build due to switch to WildFly 10. The
> target Java version is inherited from JBoss parent
> (https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L132).
>
> Next release (1.8) will require Java 8 on server-side, but still
> support Java 7 on the client-side.
>
> Oracle stopped supporting Java 7 early last year, so maybe it's time
> to move on ;)
>
> I'll update the readme's though.
>
> On 8 January 2016 at 13:40, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     I rebased my local Keycloak source codes to latest master
>     yesterday, and
>     got compilation error in
>     org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
>     class, because of import of classes from java.util.function package.
>     Investigation shown me that these classes are available in Java 8+
>     only.
>
>     Does this mean that next version of Keycloak (1.8) is targeted to
>     run on
>     Java 8 only?
>
>     Is this documented somewhere? Main readme at
>     https://github.com/keycloak/keycloak still states "Ensure you have
>     JDK 7
>     (or newer)" in build section. And I was not able to find any other
>     info
>     about required java version in user doc (eg Installation chapter).
>
>     And I also realized that Keycloak's parent pom file (and all subprojet
>     poms also) miss any information about target java version.
>     There was this definition in pom file a year ago, but looks like Stian
>     removed it 9 months ago:
>
>             <!-- maven-compiler-plugin -->
>
>             <maven.compiler.target>1.7</maven.compiler.target>
>
>             <maven.compiler.source>1.7</maven.compiler.source>
>
>     This brings a small problem when importing the project into
>     Eclipse, as
>     it is not able to correctly set java version for the project.
>     But maybe there is some reason why this is not in the pom? (I can
>     imagine that adapters use lower java version than the Keycloak server)
>
>     Is it possible to clear this somehow, at least in the documentation?
>
>     Thanks
>
>     Vlastimil
>
>     --
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From bburke at redhat.com  Fri Jan  8 09:28:03 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 8 Jan 2016 09:28:03 -0500
Subject: [keycloak-dev] Deploying Keycloak via Ansible
In-Reply-To: <568EB203.8010509@redhat.com>
References: <568EB203.8010509@redhat.com>
Message-ID: <568FC773.9070707@redhat.com>

I see some  "keyclock" instead of "keycloak" in the scripts.

Also, none of us here know much about being linux friendly for 
installation.  Glad somebody is looking into it.

On 1/7/2016 1:44 PM, Adam Young wrote:
> For my work, I need to be able to automate deploying Keycloak.  I've
> been using Ansible, so, here is my first hack at it:
>
> http://adam.younglogic.com/2016/01/deploying-keycloak-via-ansible/
>
> Feedback welcome.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From sthorger at redhat.com  Fri Jan  8 09:42:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 8 Jan 2016 15:42:45 +0100
Subject: [keycloak-dev] Is keycloak Java 8 only now? Where is it
	documented?
In-Reply-To: <568FC157.1070203@redhat.com>
References: <568FAE4E.3050300@redhat.com>
	<CAJgngAeb-oL3zvcWLXncMpgGmf4FDhMZsPkCx94erVAp=knhpA@mail.gmail.com>
	<568FC157.1070203@redhat.com>
Message-ID: <CAJgngAchjzkVucV1r1++qPqV4k51a6=_K9iiS2wnhQsn-cMM5Q@mail.gmail.com>

It'll probably even run on Java 7 with EAP 6.4 as the particular code above
is not in used with older Infinispan versions.

On 8 January 2016 at 15:01, Vlastimil Elias <velias at redhat.com> wrote:

> Sure thing, I only want to be sure what is going on and if it is
> documented properly.
> Looks like EAP 6.4 can run on Java 8 so it shouldn't be so big problem for
> us.
>
> Vlastimil
>
>
> On 8.1.2016 13:53, Stian Thorgersen wrote:
>
> Java 8 is now required to build due to switch to WildFly 10. The target
> Java version is inherited from JBoss parent (
> https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L132).
>
> Next release (1.8) will require Java 8 on server-side, but still support
> Java 7 on the client-side.
>
> Oracle stopped supporting Java 7 early last year, so maybe it's time to
> move on ;)
>
> I'll update the readme's though.
>
> On 8 January 2016 at 13:40, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> I rebased my local Keycloak source codes to latest master yesterday, and
>> got compilation error in
>> org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
>> class, because of import of classes from java.util.function package.
>> Investigation shown me that these classes are available in Java 8+ only.
>>
>> Does this mean that next version of Keycloak (1.8) is targeted to run on
>> Java 8 only?
>>
>> Is this documented somewhere? Main readme at
>> https://github.com/keycloak/keycloak still states "Ensure you have JDK 7
>> (or newer)" in build section. And I was not able to find any other info
>> about required java version in user doc (eg Installation chapter).
>>
>> And I also realized that Keycloak's parent pom file (and all subprojet
>> poms also) miss any information about target java version.
>> There was this definition in pom file a year ago, but looks like Stian
>> removed it 9 months ago:
>>
>>         <!-- maven-compiler-plugin -->
>>
>>         <maven.compiler.target>1.7</maven.compiler.target>
>>
>>         <maven.compiler.source>1.7</maven.compiler.source>
>>
>> This brings a small problem when importing the project into Eclipse, as
>> it is not able to correctly set java version for the project.
>> But maybe there is some reason why this is not in the pom? (I can
>> imagine that adapters use lower java version than the Keycloak server)
>>
>> Is it possible to clear this somehow, at least in the documentation?
>>
>> Thanks
>>
>> Vlastimil
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/061332c3/attachment-0001.html 

From j.kamal at ymail.com  Fri Jan  8 10:24:27 2016
From: j.kamal at ymail.com (Kamal Jagadevan)
Date: Fri, 8 Jan 2016 15:24:27 +0000 (UTC)
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
Message-ID: <349241432.1668136.1452266667024.JavaMail.yahoo@mail.yahoo.com>

Hi Thomas,???? When we started using keycloak for federated identity, we observed similar behavior but there is a work around to get away from this using mappers.It works like a charm for us without any prefix.
MapperType : Username Template ImporterTemplate : ${NAMEID}

BestKamal

 

      From: Thomas Raehalme <thomas.raehalme at aitiofinland.com>
 To: keycloak-dev <keycloak-dev at lists.jboss.org> 
 Sent: Friday, January 8, 2016 6:32 AM
 Subject: [keycloak-dev] Why the provider prefix in username?
   
Hi,
If I login to Keycloak using a federated identity such as Google, Keycloak inserts a prefix "google." to my username.?
Maybe I'm missing something, but isn't this kind of unnecessary when the email address is already a unique property?
Best regards,Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From thomas.raehalme at aitiofinland.com  Fri Jan  8 10:27:19 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 8 Jan 2016 17:27:19 +0200
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <349241432.1668136.1452266667024.JavaMail.yahoo@mail.yahoo.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
	<349241432.1668136.1452266667024.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAPyAMoajPn8ytm6dPhS8-PKWB6oYSg1034n5RcDjyjW+vDNoZA@mail.gmail.com>

Thanks for the tip!

Best regards,
Thomas
On Jan 8, 2016 17:24, "Kamal Jagadevan" <j.kamal at ymail.com> wrote:

> Hi Thomas,
>      When we started using keycloak for federated identity, we observed
> similar behavior but there is a work around to get away from this using
> mappers.
> It works like a charm for us without any prefix.
>
> MapperType : Username Template Importer
> Template : ${NAMEID}
>
>
> Best
> Kamal
>
>
>
> ------------------------------
> *From:* Thomas Raehalme <thomas.raehalme at aitiofinland.com>
> *To:* keycloak-dev <keycloak-dev at lists.jboss.org>
> *Sent:* Friday, January 8, 2016 6:32 AM
> *Subject:* [keycloak-dev] Why the provider prefix in username?
>
> Hi,
>
> If I login to Keycloak using a federated identity such as Google, Keycloak
> inserts a prefix "google." to my username.
>
> Maybe I'm missing something, but isn't this kind of unnecessary when the
> email address is already a unique property?
>
> Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160108/584c853e/attachment.html 

From bburke at redhat.com  Fri Jan  8 10:40:26 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 8 Jan 2016 10:40:26 -0500
Subject: [keycloak-dev] Is keycloak Java 8 only now? Where is it
 documented?
In-Reply-To: <CAJgngAchjzkVucV1r1++qPqV4k51a6=_K9iiS2wnhQsn-cMM5Q@mail.gmail.com>
References: <568FAE4E.3050300@redhat.com>
	<CAJgngAeb-oL3zvcWLXncMpgGmf4FDhMZsPkCx94erVAp=knhpA@mail.gmail.com>
	<568FC157.1070203@redhat.com>
	<CAJgngAchjzkVucV1r1++qPqV4k51a6=_K9iiS2wnhQsn-cMM5Q@mail.gmail.com>
Message-ID: <568FD86A.2010009@redhat.com>

I set JDK 8 for maven-compiler-plugin only for appropriate infinispan 
module, so everything else should be JDK 7 or 6 bytecode.

On 1/8/2016 9:42 AM, Stian Thorgersen wrote:
> It'll probably even run on Java 7 with EAP 6.4 as the particular code 
> above is not in used with older Infinispan versions.
>
> On 8 January 2016 at 15:01, Vlastimil Elias <velias at redhat.com 
> <mailto:velias at redhat.com>> wrote:
>
>     Sure thing, I only want to be sure what is going on and if it is
>     documented properly.
>     Looks like EAP 6.4 can run on Java 8 so it shouldn't be so big
>     problem for us.
>
>     Vlastimil
>
>
>     On 8.1.2016 13:53, Stian Thorgersen wrote:
>>     Java 8 is now required to build due to switch to WildFly 10. The
>>     target Java version is inherited from JBoss parent
>>     (https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L132).
>>
>>
>>     Next release (1.8) will require Java 8 on server-side, but still
>>     support Java 7 on the client-side.
>>
>>     Oracle stopped supporting Java 7 early last year, so maybe it's
>>     time to move on ;)
>>
>>     I'll update the readme's though.
>>
>>     On 8 January 2016 at 13:40, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi,
>>
>>         I rebased my local Keycloak source codes to latest master
>>         yesterday, and
>>         got compilation error in
>>         org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
>>         class, because of import of classes from java.util.function
>>         package.
>>         Investigation shown me that these classes are available in
>>         Java 8+ only.
>>
>>         Does this mean that next version of Keycloak (1.8) is
>>         targeted to run on
>>         Java 8 only?
>>
>>         Is this documented somewhere? Main readme at
>>         https://github.com/keycloak/keycloak still states "Ensure you
>>         have JDK 7
>>         (or newer)" in build section. And I was not able to find any
>>         other info
>>         about required java version in user doc (eg Installation
>>         chapter).
>>
>>         And I also realized that Keycloak's parent pom file (and all
>>         subprojet
>>         poms also) miss any information about target java version.
>>         There was this definition in pom file a year ago, but looks
>>         like Stian
>>         removed it 9 months ago:
>>
>>                 <!-- maven-compiler-plugin -->
>>
>>         <maven.compiler.target>1.7</maven.compiler.target>
>>
>>         <maven.compiler.source>1.7</maven.compiler.source>
>>
>>         This brings a small problem when importing the project into
>>         Eclipse, as
>>         it is not able to correctly set java version for the project.
>>         But maybe there is some reason why this is not in the pom? (I can
>>         imagine that adapters use lower java version than the
>>         Keycloak server)
>>
>>         Is it possible to clear this somehow, at least in the
>>         documentation?
>>
>>         Thanks
>>
>>         Vlastimil
>>
>>         --
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From mstrukel at redhat.com  Mon Jan 11 06:16:42 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Mon, 11 Jan 2016 12:16:42 +0100
Subject: [keycloak-dev] New truststore provider
Message-ID: <CA+1OW+idOhYGwQVDDHmGVgC5xjm7BM3gNQRM_hv1VNXC4KDxYg@mail.gmail.com>

The new truststore provider I?ve been working on for the last several
weeks has been merged to master.

It brings some changes in how to configure https connectivity between
Keycloak server and backend services like brokers, LDAP identity
providers, SMTP servers, and client applications for backchannel
events.

Previously it was possible to configure a truststore on HttpClient
provider using the following properties:

"connectionsHttpClient": {
   "truststore": "path to your .jks file containing public
certificates you trust",
   "truststorePassword': "password",
   "hostname-verification-policy": "WILDCARD",
   "disable-trust-manager": false
}


Not every outgoing connectivity used HttpClient provider though. LDAP
connectivity uses java?s internal LDAP JNDI factory implementation
that uses java.net.URLConnection, similarly connectivity to SMTP
servers via JavaMail API used java.net.URLConnection directly. These
would bypass HttpClient truststore configuration completely, and
default to JSSE configuration - that is whatever is configured at jvm
level using javax.net.ssl.trustStore system property or fallback to
cacerts file that comes with java.

By moving truststore configuration out of HttpClient provider it can
now be used by all these other facilities as well, and thus we truly
have a server-wide truststore configuration for our services.

The new truststore provider removes truststore and certificate
checking configuration from HttpClient provider. The above mentioned
configuration properties no longer have any effect. Instead, one has
to configure the truststore provider:

"truststore": {
   "file": {
       "file": "path to your .jks file containing public certificates
you trust",
       "password": "password",
       "hostname-verification-policy": "WILDCARD",
       "disabled": false
   }
}


If truststore provider is configured, it is used by HttpClient
provider and other services, if it is not configured (which is a
default - by missing entirely from keycloak-server.json file), or if
?disabled?,  then HttpClient provider will fallback to JSSE
configuration. Note that this is not the same as the removed
?disable-trust-manager? setting in HttpClient provider configuration,
which rather than falling back to JSSE, turns off certificate checking
itself - accepting any certificate including self-signed ones. By the
way - that?s something that should never be enabled in a production
system, but was the default configuration. This mode is now no longer
available - you can?t disable certificate checking any more, you can
only delegate it downwards to the JVM.

More docs on this is available in ?truststore? section of Server
Installation (https://github.com/keycloak/keycloak/blob/master/docbook/auth-server-docs/reference/en/en-US/modules/server-installation.xml)

- marko


From thomas.darimont at googlemail.com  Mon Jan 11 09:58:06 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 11 Jan 2016 15:58:06 +0100
Subject: [keycloak-dev] Conditional OTP Authentication based on HTTP header
	or Role
Message-ID: <CAK-7U1hu9DpTO5V3PgFNWCaV224S1QUt9nmL3gQsrLBWq4iyug@mail.gmail.com>

Hello,

since this was requested multiple times, I implemented a custom OTP
Authenticator
that can conditionally show the OTP form over the weekend.

You can find more details in the following JIRA issue:
https://issues.jboss.org/browse/KEYCLOAK-2040

I build something along the lines based on keycloak 1.8 (already adapted
this for Keycloak 1.7) which allows you to conditionally require OTP
authentication - I can contribute that if desired.
The solution consists of a custom ConditionalOtpFormAuthenticator that
extends the OTPFormAuthenticator which can be configured with some
conditions via the admin interface.
The decision for whether or not to require OTP authentication can be made
based on multiple conditions which are evaluated in the following order.
The first matching condition determines the outcome.
The list of supported conditions include:
- User Attribute
- Role
- Request Header
- Configured Default
If no condition matches, the ConditionalOtpFormAuthenticator fallback is to
require OTP authentication.

User Attribute:
A User Attribute like otp_auth can be used to control OTP authentication on
individual user level. The supported values are skip and force. If the
value is set to skip then the OTP auth is skipped for the user, otherwise
if the value is force then the OTP auth is enforced. The setting is ignored
for any other value.

Role:
A role can be used to control the OTP authentication. If the user has the
specified role the OTP authentication is forced. Otherwise if no role is
selected the setting is ignored.

Request Header:
Request Headers are matched via regex Patterns and can be specified as a
whitelist and blacklist. No OTP for Header specifies the pattern for which
OTP authentication is not required. This can be used to specify trusted
networks, e.g. via: X-Forwarded-Host: (1.2.3.4|1.2.3.5) where The IPs
1.2.3.4, 1.2.3.5 denote trusted machines. Force OTP for Header specifies
the pattern for which OTP authentication is required. Whitelist entries
take precedence before blacklist entries.

Configured Default:
A default fall-though behavior can be specified to handle cases where all
previous conditions did not lead to a conclusion. An OTP authentication is
required in case no default is configured.

The code can be found here
https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-2040-Conditional-OTP-Authentication
- I can make a PR if this has a chance to get in.

Cheers
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160111/721a7f05/attachment.html 

From bburke at redhat.com  Mon Jan 11 12:39:00 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Jan 2016 12:39:00 -0500
Subject: [keycloak-dev] Conditional OTP Authentication based on HTTP
 header or Role
In-Reply-To: <CAK-7U1hu9DpTO5V3PgFNWCaV224S1QUt9nmL3gQsrLBWq4iyug@mail.gmail.com>
References: <CAK-7U1hu9DpTO5V3PgFNWCaV224S1QUt9nmL3gQsrLBWq4iyug@mail.gmail.com>
Message-ID: <5693E8B4.1030007@redhat.com>

Thats cool!  Thanks.  Something we've been wanting to add.  If you want 
to submit a PR we would welcome it.

On 1/11/2016 9:58 AM, Thomas Darimont wrote:
> Hello,
>
> since this was requested multiple times, I implemented a custom OTP 
> Authenticator
> that can conditionally show the OTP form over the weekend.
>
> You can find more details in the following JIRA issue:
> https://issues.jboss.org/browse/KEYCLOAK-2040
>
> I build something along the lines based on keycloak 1.8 (already 
> adapted this for Keycloak 1.7) which allows you to conditionally 
> require OTP authentication - I can contribute that if desired.
> The solution consists of a custom ConditionalOtpFormAuthenticator that 
> extends the OTPFormAuthenticator which can be configured with some 
> conditions via the admin interface.
> The decision for whether or not to require OTP authentication can be 
> made based on multiple conditions which are evaluated in the following 
> order. The first matching condition determines the outcome.
> The list of supported conditions include:
> - User Attribute
> - Role
> - Request Header
> - Configured Default
> If no condition matches, the ConditionalOtpFormAuthenticator fallback 
> is to require OTP authentication.
>
> User Attribute:
> A User Attribute like otp_auth can be used to control OTP 
> authentication on individual user level. The supported values are skip 
> and force. If the value is set to skip then the OTP auth is skipped 
> for the user, otherwise if the value is force then the OTP auth is 
> enforced. The setting is ignored for any other value.
>
> Role:
> A role can be used to control the OTP authentication. If the user has 
> the specified role the OTP authentication is forced. Otherwise if no 
> role is selected the setting is ignored.
>
> Request Header:
> Request Headers are matched via regex Patterns and can be specified as 
> a whitelist and blacklist. No OTP for Header specifies the pattern for 
> which OTP authentication is not required. This can be used to specify 
> trusted networks, e.g. via: X-Forwarded-Host: (1.2.3.4|1.2.3.5) where 
> The IPs 1.2.3.4, 1.2.3.5 denote trusted machines. Force OTP for Header 
> specifies the pattern for which OTP authentication is required. 
> Whitelist entries take precedence before blacklist entries.
>
> Configured Default:
> A default fall-though behavior can be specified to handle cases where 
> all previous conditions did not lead to a conclusion. An OTP 
> authentication is required in case no default is configured.
>
> The code can be found here 
> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-2040-Conditional-OTP-Authentication 
> - I can make a PR if this has a chance to get in.
>
> Cheers
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From srossillo at smartling.com  Mon Jan 11 12:39:11 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 11 Jan 2016 12:39:11 -0500
Subject: [keycloak-dev] Exception in 1.7.0 during login using federation
	provider
Message-ID: <06604867-52FD-4661-8EAC-B1BD31638867@smartling.com>

Hey,

I?m trying to publish an example of how to do on demand user migration using a federation provider. It?s a modified version of what we use on an older Keycloak version.  The error I?m getting (with H2, Keycloak 1.7.0 out-of-the-box) is below.

At the time the exception is thrown, Kecyloak hasn?t attempted to validate credentials yet.

It has only called these methods:
- UserModel getUserByUsername(RealmModel realm, String username);
- public boolean isValid(RealmModel realm, UserModel local);

After calling session.users().addUser() am I supposed to release something?

Thanks,
Scott

-------

Methods:

@Override
public UserModel getUserByUsername(RealmModel realm, String username) { {

    String username = rawUsername.toLowerCase().trim();
    FederatedUserModel remoteUser = federatedUserService.getUserDetails(username);
    LOG.infof("Creating user model for: %s", username);
    UserModel userModel = session.users().addUser(realm, username);

    if (!username.equals(remoteUser.getEmail())) {
        throw new IllegalStateException(String.format("Local and remote users differ: [%s != %s]", username, remoteUser.getUsername()));
    }

    userModel.setFederationLink(model.getId());
    userModel.setEnabled(remoteUser.isEnabled());
    userModel.setEmail(username);
    userModel.setEmailVerified(remoteUser.isEmailVerified());
    userModel.setFirstName(remoteUser.getFirstName());
    userModel.setLastName(remoteUser.getLastName());

    if (remoteUser.getAttributes() != null) {
        Map<String, List<String>> attributes = remoteUser.getAttributes();
        for (String attributeName : attributes.keySet())
            userModel.setAttribute(attributeName, attributes.get(attributeName));
    }

    if (remoteUser.getRoles() != null) {
        for (String role : remoteUser.getRoles()) {
            RoleModel roleModel = realm.getRole(role);
            if (roleModel != null) {
                userModel.grantRole(roleModel);
                LOG.infof("Granted user %s, role %s", username, role);
            }
        }
    }

    return userModel;
}

@Override
public boolean isValid(RealmModel realm, UserModel local)
{
    Response response = federatedUserService.validateUserExists(local.getUsername());
    return HttpStatus.SC_ACCEPTED == response.getStatus();
}

Exception:

2:13:51,497 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) SQL Error: 50200, SQLState: HYT00
12:13:51,498 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) Timeout trying to lock table "USER_ENTITY"; SQL statement:
select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
12:13:51,499 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-88) failed authentication: javax.persistence.PessimisticLockException: could not extract ResultSet
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.wrapLockException(AbstractEntityManagerImpl.java:1831)
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1720)
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458)
	at org.keycloak.models.jpa.JpaUserProvider.getUserById(JpaUserProvider.java:260)
	at org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.getUserById(DefaultCacheUserProvider.java:122)
	at org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:112)
	at org.keycloak.models.UserFederationManager.validateUser(UserFederationManager.java:100)
	at org.keycloak.models.UserFederationManager.validCredentials(UserFederationManager.java:409)
	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validatePassword(AbstractUsernameFormAuthenticator.java:152)
	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validateUserAndPassword(AbstractUsernameFormAuthenticator.java:128)
	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.validateForm(UsernamePasswordForm.java:41)
	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.action(UsernamePasswordForm.java:34)
	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:65)
	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:57)
	at org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:744)
	at org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:299)
	at org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:280)
	at org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:326)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)
Caused by: org.hibernate.PessimisticLockException: could not extract ResultSet
	at org.hibernate.dialect.H2Dialect$2.convert(H2Dialect.java:342)
	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:91)
	at org.hibernate.loader.Loader.getResultSet(Loader.java:2066)
	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1863)
	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839)
	at org.hibernate.loader.Loader.doQuery(Loader.java:910)
	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355)
	at org.hibernate.loader.Loader.doList(Loader.java:2554)
	at org.hibernate.loader.Loader.doList(Loader.java:2540)
	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370)
	at org.hibernate.loader.Loader.list(Loader.java:2365)
	at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:497)
	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387)
	at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:236)
	at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1300)
	at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103)
	at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573)
	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449)
	... 62 more
Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table "USER_ENTITY"; SQL statement:
select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
	at org.h2.message.DbException.get(DbException.java:171)
	at org.h2.message.DbException.get(DbException.java:148)
	at org.h2.table.RegularTable.doLock(RegularTable.java:521)
	at org.h2.table.RegularTable.lock(RegularTable.java:455)
	at org.h2.table.TableFilter.lock(TableFilter.java:145)
	at org.h2.command.dml.Select.queryWithoutCache(Select.java:611)
	at org.h2.command.dml.Query.query(Query.java:314)
	at org.h2.command.dml.Query.query(Query.java:284)
	at org.h2.command.dml.Query.query(Query.java:36)
	at org.h2.command.CommandContainer.query(CommandContainer.java:91)
	at org.h2.command.Command.executeQuery(Command.java:195)
	at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:106)
	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:82)
	... 78 more





From bburke at redhat.com  Mon Jan 11 12:39:50 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Jan 2016 12:39:50 -0500
Subject: [keycloak-dev] Conditional OTP Authentication based on HTTP
 header or Role
In-Reply-To: <5693E8B4.1030007@redhat.com>
References: <CAK-7U1hu9DpTO5V3PgFNWCaV224S1QUt9nmL3gQsrLBWq4iyug@mail.gmail.com>
	<5693E8B4.1030007@redhat.com>
Message-ID: <5693E8E6.6080406@redhat.com>

Whoops, ou already submitted a PR! :)

On 1/11/2016 12:39 PM, Bill Burke wrote:
> Thats cool!  Thanks.  Something we've been wanting to add.  If you 
> want to submit a PR we would welcome it.
>
> On 1/11/2016 9:58 AM, Thomas Darimont wrote:
>> Hello,
>>
>> since this was requested multiple times, I implemented a custom OTP 
>> Authenticator
>> that can conditionally show the OTP form over the weekend.
>>
>> You can find more details in the following JIRA issue:
>> https://issues.jboss.org/browse/KEYCLOAK-2040
>>
>> I build something along the lines based on keycloak 1.8 (already 
>> adapted this for Keycloak 1.7) which allows you to conditionally 
>> require OTP authentication - I can contribute that if desired.
>> The solution consists of a custom ConditionalOtpFormAuthenticator 
>> that extends the OTPFormAuthenticator which can be configured with 
>> some conditions via the admin interface.
>> The decision for whether or not to require OTP authentication can be 
>> made based on multiple conditions which are evaluated in the 
>> following order. The first matching condition determines the outcome.
>> The list of supported conditions include:
>> - User Attribute
>> - Role
>> - Request Header
>> - Configured Default
>> If no condition matches, the ConditionalOtpFormAuthenticator fallback 
>> is to require OTP authentication.
>>
>> User Attribute:
>> A User Attribute like otp_auth can be used to control OTP 
>> authentication on individual user level. The supported values are 
>> skip and force. If the value is set to skip then the OTP auth is 
>> skipped for the user, otherwise if the value is force then the OTP 
>> auth is enforced. The setting is ignored for any other value.
>>
>> Role:
>> A role can be used to control the OTP authentication. If the user has 
>> the specified role the OTP authentication is forced. Otherwise if no 
>> role is selected the setting is ignored.
>>
>> Request Header:
>> Request Headers are matched via regex Patterns and can be specified 
>> as a whitelist and blacklist. No OTP for Header specifies the pattern 
>> for which OTP authentication is not required. This can be used to 
>> specify trusted networks, e.g. via: X-Forwarded-Host: 
>> (1.2.3.4|1.2.3.5) where The IPs 1.2.3.4, 1.2.3.5 denote trusted 
>> machines. Force OTP for Header specifies the pattern for which OTP 
>> authentication is required. Whitelist entries take precedence before 
>> blacklist entries.
>>
>> Configured Default:
>> A default fall-though behavior can be specified to handle cases where 
>> all previous conditions did not lead to a conclusion. An OTP 
>> authentication is required in case no default is configured.
>>
>> The code can be found here 
>> https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-2040-Conditional-OTP-Authentication 
>> - I can make a PR if this has a chance to get in.
>>
>> Cheers
>> Thomas
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From thomas.darimont at googlemail.com  Mon Jan 11 16:15:33 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 11 Jan 2016 22:15:33 +0100
Subject: [keycloak-dev] Two Factor Authentication via Email.
Message-ID: <CAK-7U1hC9AMjJdqeW1FYWqX5LAaUVxkTgMoCawR3hJoHpOycLQ@mail.gmail.com>

I'm currently working on a PR that provides "Two factor authentication via
email" https://issues.jboss.org/browse/KEYCLOAK-240.

My current implementation comes with a custom EmailCodeAuthenticator
that generates a short code String in the challenge(...) Method and
sends an email to the email address that is configured for the current user.

The user can then copy and paste the code into an input field, similar
to OTP codes are handled. If the user entered the wrong code, a new
email is sent to the user's email address.

The email code is saved as a user level credential.

I wonder whether this is the right approach or whether it would be better
to allow the user to regenerate the code on demand instead of
regenerating it every time?

For the former I'd have to provide a REST endpoint similar to what happens
for verifying an email
during registration - where should this be placed?

For sending the actual email I'm currently using a EmailSenderProvider,
however I think a EmailTemplateProvider might be more appropriate ;-)
May I simply add a method to the EmailTemplateProvider interface?

Btw. I think this would be a good base for having an SMS based 2nd factor
authenticator, as requested here:
https://issues.jboss.org/browse/KEYCLOAK-241

It would make sense to have the mobile phone number as a first-class user
attribute and showing it on the profile page by default instead of just
having it only in the data model.

Another point that comes to my mind is that I could make sense to specify
an email code policy in the same way OTP policies are supported. This could
then be used to differentiate between email
codes that are usually handled via copy&paste whereas codes
that come via SMS are usually typed in by hand and should therefore
be somewhat short ;-)

My current WIP can be found here:
https://github.com/thomasdarimont/keycloak/commits/issue/KEYCLOAK-240-2nd-factor-auth-via-email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160111/9091aff3/attachment.html 

From bburke at redhat.com  Mon Jan 11 16:29:40 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Jan 2016 16:29:40 -0500
Subject: [keycloak-dev] Two Factor Authentication via Email.
In-Reply-To: <CAK-7U1hC9AMjJdqeW1FYWqX5LAaUVxkTgMoCawR3hJoHpOycLQ@mail.gmail.com>
References: <CAK-7U1hC9AMjJdqeW1FYWqX5LAaUVxkTgMoCawR3hJoHpOycLQ@mail.gmail.com>
Message-ID: <56941EC4.8080902@redhat.com>


On 1/11/2016 4:15 PM, Thomas Darimont wrote:
> I'm currently working on a PR that provides "Two factor authentication 
> via email" https://issues.jboss.org/browse/KEYCLOAK-240.
>
> My current implementation comes with a custom EmailCodeAuthenticator
> that generates a short code String in the challenge(...) Method and
> sends an email to the email address that is configured for the current 
> user.
>
> The user can then copy and paste the code into an input field, similar
> to OTP codes are handled. If the user entered the wrong code, a new
> email is sent to the user's email address.
>
> The email code is saved as a user level credential.
>
> I wonder whether this is the right approach or whether it would be better
> to allow the user to regenerate the code on demand instead of
> regenerating it every time?
>

Don't know what you mean by that.  Just store the OTP within the 
ClientSessionModel.  Generate the OTP, store it within the ClientSession 
model, send the OTP to the user, display the OTP input page.  IMO, you 
also should not resend the email on failure. Instead, supply a button 
that they can click to resend the email.

> For the former I'd have to provide a REST endpoint similar to what 
> happens for verifying an email
> during registration - where should this be placed?
>
> For sending the actual email I'm currently using a 
> EmailSenderProvider, however I think a EmailTemplateProvider might be 
> more appropriate ;-)
> May I simply add a method to the EmailTemplateProvider interface?
>

We should have a more generic method on EmailTemplateProvider.

> Btw. I think this would be a good base for having an SMS based 2nd 
> factor authenticator, as requested here: 
> https://issues.jboss.org/browse/KEYCLOAK-241
>
> It would make sense to have the mobile phone number as a first-class 
> user attribute and showing it on the profile page by default instead 
> of just having it only in the data model.
>
> Another point that comes to my mind is that I could make sense to 
> specify an email code policy in the same way OTP policies are 
> supported. This could then be used to differentiate between email
> codes that are usually handled via copy&paste whereas codes
> that come via SMS are usually typed in by hand and should therefore
> be somewhat short ;-)
>

All that makes sense.  Never did an SMS based module as the SDKs used 
differ per country, are quite diverse, and most of the time(?) cost money.


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


From mposolda at redhat.com  Mon Jan 11 16:34:07 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 11 Jan 2016 22:34:07 +0100
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
	<CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>
Message-ID: <56941FCF.5000800@redhat.com>

On 08/01/16 13:05, Stian Thorgersen wrote:
> It's to make it less likely that the username is already in use. We 
> could use email for the username in those cases, but email is not 
> always available. In the past we didn't have a way to allow the user 
> to change the username if there was a conflict and instead the first 
> login would just fail. With the introduction of first time social 
> flows we could improve on this.
>
> We could allow selecting the strategy to use. Then allow the user to 
> change if there's a conflict. We already allow users to change email 
> if there's a conflict so can do the same for username.
We already detect conflicts in both email and username. So user can 
either use different username or link the account corresponding to 
existing username. Also as Kamal mentioned, we already have the 
IdentityProviderMapper, which allows to configure how is username 
generated ( UsernameTemplateMapper ). We don't need any other strategy 
IMO as the mapper is flexible enough.

Maybe we can improve how is username generated if mapper is not used? 
Currently the username is generated based on algorithm like this:
1) If there is IdentityProviderMapper which sets username, it has priority
2) Otherwise if realm.isRegistrationEmailAsUsername, then email from 
social provider is used as username
3) Otherwise if username from Identity provider is set, we generate the 
keycloak username like "<IDP alias>.<IDP username>" (For example 
"facebook.mposolda" )
4) Otherwise if username from identity provider is null, we generate the 
keycloak username like "<IDP alias>.<IDP ID>" (For example 
"facebook.12345" )

IMO the one thing, which can be improved is removing the IDP prefix in 
step 3 and use just the username "mposolda" . If there is conflict, it 
can be easily resolved thanks to first broker login flow. I would likely 
keep the IDP alias in step 4 as having just username "12345" is a bit 
confusing IMO.

WDYT?
Marek
>
> On 8 January 2016 at 12:32, Thomas Raehalme 
> <thomas.raehalme at aitiofinland.com 
> <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>
>     Hi,
>
>     If I login to Keycloak using a federated identity such as Google,
>     Keycloak inserts a prefix "google." to my username.
>
>     Maybe I'm missing something, but isn't this kind of unnecessary
>     when the email address is already a unique property?
>
>     Best regards,
>     Thomas
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From josh.cain at redhat.com  Mon Jan 11 17:24:49 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Mon, 11 Jan 2016 16:24:49 -0600
Subject: [keycloak-dev] Why isn't the configuration/providers directory on
 my classpath when attempting to load a file?
Message-ID: <CA+z0A8Cp+aMBzuXZMEvRWyq2Y50CMDUdN1p2wwGLSH5ysU5JkQ@mail.gmail.com>

Hi all,

I'm in the process of writing an SPI for a federation provider that relies
on a third party library, and the library in turn uses a number of files.
I placed my SPI .jar, the third party library .jar, as well as its required
files in the keycloak-1.7.0.Final/standalone/configuration/providers
directory.  However, when the third party library attempts to locate its
required files on the classpath, it cannot find them.

Just for a sanity check, I've placed the files places like the sun/jdk/main
module on the AS, and observed that the files were picked up properly since
that particular folder was on the classpath.

Can anyone help me understand why those files are not being picked up as
classpath resources?  Does the configuration/providers directory not get
added to the classpath?

Just FYI, I poked through the library a bit, and it doesn't seem to be
doing anything strange.  It winds up doing the equivalent of:

Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160111/e7aeceeb/attachment.html 

From srossillo at smartling.com  Mon Jan 11 18:36:16 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 11 Jan 2016 18:36:16 -0500
Subject: [keycloak-dev] Exception in 1.7.0 during login using federation
	provider
In-Reply-To: <06604867-52FD-4661-8EAC-B1BD31638867@smartling.com>
References: <06604867-52FD-4661-8EAC-B1BD31638867@smartling.com>
Message-ID: <2A0537FF-B48C-45DC-A76D-E265ED0E7FDC@smartling.com>

I published the full code if that?s easier to look at.

Project: https://github.com/Smartling/keycloak-user-migration-provider

Federation Provider: https://github.com/Smartling/keycloak-user-migration-provider/blob/master/user-migration-federation-provider/src/main/java/com/smartling/keycloak/provider/RemoteUserFederationProvider.java

Any help would be greatly appreciated with the exception below.

Best,
Scott
 <http://www.sigstr.com/>

> On Jan 11, 2016, at 12:39 PM, Scott Rossillo <srossillo at smartling.com> wrote:
> 
> Hey,
> 
> I?m trying to publish an example of how to do on demand user migration using a federation provider. It?s a modified version of what we use on an older Keycloak version.  The error I?m getting (with H2, Keycloak 1.7.0 out-of-the-box) is below.
> 
> At the time the exception is thrown, Kecyloak hasn?t attempted to validate credentials yet.
> 
> It has only called these methods:
> - UserModel getUserByUsername(RealmModel realm, String username);
> - public boolean isValid(RealmModel realm, UserModel local);
> 
> After calling session.users().addUser() am I supposed to release something?
> 
> Thanks,
> Scott
> 
> -------
> 
> Methods:
> 
> @Override
> public UserModel getUserByUsername(RealmModel realm, String username) { {
> 
>    String username = rawUsername.toLowerCase().trim();
>    FederatedUserModel remoteUser = federatedUserService.getUserDetails(username);
>    LOG.infof("Creating user model for: %s", username);
>    UserModel userModel = session.users().addUser(realm, username);
> 
>    if (!username.equals(remoteUser.getEmail())) {
>        throw new IllegalStateException(String.format("Local and remote users differ: [%s != %s]", username, remoteUser.getUsername()));
>    }
> 
>    userModel.setFederationLink(model.getId());
>    userModel.setEnabled(remoteUser.isEnabled());
>    userModel.setEmail(username);
>    userModel.setEmailVerified(remoteUser.isEmailVerified());
>    userModel.setFirstName(remoteUser.getFirstName());
>    userModel.setLastName(remoteUser.getLastName());
> 
>    if (remoteUser.getAttributes() != null) {
>        Map<String, List<String>> attributes = remoteUser.getAttributes();
>        for (String attributeName : attributes.keySet())
>            userModel.setAttribute(attributeName, attributes.get(attributeName));
>    }
> 
>    if (remoteUser.getRoles() != null) {
>        for (String role : remoteUser.getRoles()) {
>            RoleModel roleModel = realm.getRole(role);
>            if (roleModel != null) {
>                userModel.grantRole(roleModel);
>                LOG.infof("Granted user %s, role %s", username, role);
>            }
>        }
>    }
> 
>    return userModel;
> }
> 
> @Override
> public boolean isValid(RealmModel realm, UserModel local)
> {
>    Response response = federatedUserService.validateUserExists(local.getUsername());
>    return HttpStatus.SC_ACCEPTED == response.getStatus();
> }
> 
> Exception:
> 
> 2:13:51,497 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) SQL Error: 50200, SQLState: HYT00
> 12:13:51,498 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) Timeout trying to lock table "USER_ENTITY"; SQL statement:
> select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
> 12:13:51,499 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-88) failed authentication: javax.persistence.PessimisticLockException: could not extract ResultSet
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.wrapLockException(AbstractEntityManagerImpl.java:1831)
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1720)
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
> 	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458)
> 	at org.keycloak.models.jpa.JpaUserProvider.getUserById(JpaUserProvider.java:260)
> 	at org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.getUserById(DefaultCacheUserProvider.java:122)
> 	at org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:112)
> 	at org.keycloak.models.UserFederationManager.validateUser(UserFederationManager.java:100)
> 	at org.keycloak.models.UserFederationManager.validCredentials(UserFederationManager.java:409)
> 	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validatePassword(AbstractUsernameFormAuthenticator.java:152)
> 	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validateUserAndPassword(AbstractUsernameFormAuthenticator.java:128)
> 	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.validateForm(UsernamePasswordForm.java:41)
> 	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.action(UsernamePasswordForm.java:34)
> 	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:65)
> 	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:57)
> 	at org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:744)
> 	at org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:299)
> 	at org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:280)
> 	at org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:326)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> 	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> Caused by: org.hibernate.PessimisticLockException: could not extract ResultSet
> 	at org.hibernate.dialect.H2Dialect$2.convert(H2Dialect.java:342)
> 	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
> 	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
> 	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
> 	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:91)
> 	at org.hibernate.loader.Loader.getResultSet(Loader.java:2066)
> 	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1863)
> 	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839)
> 	at org.hibernate.loader.Loader.doQuery(Loader.java:910)
> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355)
> 	at org.hibernate.loader.Loader.doList(Loader.java:2554)
> 	at org.hibernate.loader.Loader.doList(Loader.java:2540)
> 	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370)
> 	at org.hibernate.loader.Loader.list(Loader.java:2365)
> 	at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:497)
> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387)
> 	at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:236)
> 	at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1300)
> 	at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103)
> 	at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573)
> 	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449)
> 	... 62 more
> Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table "USER_ENTITY"; SQL statement:
> select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.table.RegularTable.doLock(RegularTable.java:521)
> 	at org.h2.table.RegularTable.lock(RegularTable.java:455)
> 	at org.h2.table.TableFilter.lock(TableFilter.java:145)
> 	at org.h2.command.dml.Select.queryWithoutCache(Select.java:611)
> 	at org.h2.command.dml.Query.query(Query.java:314)
> 	at org.h2.command.dml.Query.query(Query.java:284)
> 	at org.h2.command.dml.Query.query(Query.java:36)
> 	at org.h2.command.CommandContainer.query(CommandContainer.java:91)
> 	at org.h2.command.Command.executeQuery(Command.java:195)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:106)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
> 	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:82)
> 	... 78 more
> 
> 
> 

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

From bburke at redhat.com  Mon Jan 11 21:22:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 11 Jan 2016 21:22:02 -0500
Subject: [keycloak-dev] module re-org
Message-ID: <5694634A.9010201@redhat.com>

I can't find the original email on this, but we need to do this for 
1.9.  I can start doing it one module at a time:

Common:
keycloak-common
keycloak-common-saml
keycloak-common-oidc

Libraries server:

keycloak-server-spi - all SPI interfaces and common code
keycloak-server-saml - all saml server code, broker and protocol plugins
keycloak-server-oidc - all oidc code, broker and protocol plugins
keycloak-server-impl - everything

Libraries client:

This structure is not going to change as it is already broken out the 
way it should be to gain re-use between servlet containers.

Questions:

Do we care about breaking out server side OIDC and SAML?



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


From sthorger at redhat.com  Tue Jan 12 02:45:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 08:45:35 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <5694634A.9010201@redhat.com>
References: <5694634A.9010201@redhat.com>
Message-ID: <CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>

On 12 January 2016 at 03:22, Bill Burke <bburke at redhat.com> wrote:

> I can't find the original email on this, but we need to do this for
> 1.9.  I can start doing it one module at a time:


> Common:
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> Libraries server:
>
> keycloak-server-spi - all SPI interfaces and common code
> keycloak-server-saml - all saml server code, broker and protocol plugins
> keycloak-server-oidc - all oidc code, broker and protocol plugins
> keycloak-server-impl - everything
>

I'm not 100% sure we should put all implementations of SPIs into
keycloak-server-impl. We at least need to keep Mongo separate as it's not
part of the product.

If we put all SPI implementations, including services, into the same module
we'd end up with one huge module. There's also a risk that we'd end up with
strong relationships between them, rather than having them properly linked
via SPI interfaces.

I'm a bit 50/50 on it though.


>
> Libraries client:
>
> This structure is not going to change as it is already broken out the
> way it should be to gain re-use between servlet containers.
>
> Questions:
>
> Do we care about breaking out server side OIDC and SAML?
>

I don't


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

From sthorger at redhat.com  Tue Jan 12 02:51:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 08:51:30 +0100
Subject: [keycloak-dev] Two Factor Authentication via Email.
In-Reply-To: <56941EC4.8080902@redhat.com>
References: <CAK-7U1hC9AMjJdqeW1FYWqX5LAaUVxkTgMoCawR3hJoHpOycLQ@mail.gmail.com>
	<56941EC4.8080902@redhat.com>
Message-ID: <CAJgngAfxn+f0vX1Ax9hxrTyxtkhycjDRJiNqgksPKHBhDx0mMA@mail.gmail.com>

On 11 January 2016 at 22:29, Bill Burke <bburke at redhat.com> wrote:

>
> On 1/11/2016 4:15 PM, Thomas Darimont wrote:
> > I'm currently working on a PR that provides "Two factor authentication
> > via email" https://issues.jboss.org/browse/KEYCLOAK-240.
> >
> > My current implementation comes with a custom EmailCodeAuthenticator
> > that generates a short code String in the challenge(...) Method and
> > sends an email to the email address that is configured for the current
> > user.
> >
> > The user can then copy and paste the code into an input field, similar
> > to OTP codes are handled. If the user entered the wrong code, a new
> > email is sent to the user's email address.
> >
> > The email code is saved as a user level credential.
> >
> > I wonder whether this is the right approach or whether it would be better
> > to allow the user to regenerate the code on demand instead of
> > regenerating it every time?
> >
>
> Don't know what you mean by that.  Just store the OTP within the
> ClientSessionModel.  Generate the OTP, store it within the ClientSession
> model, send the OTP to the user, display the OTP input page.  IMO, you
> also should not resend the email on failure. Instead, supply a button
> that they can click to resend the email.
>

+1 Just leverage what we already have for OTPs to generate codes to send in
email. In fact we could even use the same OTP secret already stored for OTP
when sending emails and SMS.


>
> > For the former I'd have to provide a REST endpoint similar to what
> > happens for verifying an email
> > during registration - where should this be placed?
> >
> > For sending the actual email I'm currently using a
> > EmailSenderProvider, however I think a EmailTemplateProvider might be
> > more appropriate ;-)
> > May I simply add a method to the EmailTemplateProvider interface?
> >
>
> We should have a more generic method on EmailTemplateProvider.
>

+1 Something like sendEmail(String template,...)


>
> > Btw. I think this would be a good base for having an SMS based 2nd
> > factor authenticator, as requested here:
> > https://issues.jboss.org/browse/KEYCLOAK-241
> >
> > It would make sense to have the mobile phone number as a first-class
> > user attribute and showing it on the profile page by default instead
> > of just having it only in the data model.
> >
> > Another point that comes to my mind is that I could make sense to
> > specify an email code policy in the same way OTP policies are
> > supported. This could then be used to differentiate between email
> > codes that are usually handled via copy&paste whereas codes
> > that come via SMS are usually typed in by hand and should therefore
> > be somewhat short ;-)
> >
>
> All that makes sense.  Never did an SMS based module as the SDKs used
> differ per country, are quite diverse, and most of the time(?) cost money.
>

Yup, there's no standard to send SMS, but we could introduce a
SMSSenderProvider which it would delegate to. That way it's relatively
simple to implement an SMS sender.


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

From sthorger at redhat.com  Tue Jan 12 02:54:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 08:54:27 +0100
Subject: [keycloak-dev] Two Factor Authentication via Email.
In-Reply-To: <CAJgngAfxn+f0vX1Ax9hxrTyxtkhycjDRJiNqgksPKHBhDx0mMA@mail.gmail.com>
References: <CAK-7U1hC9AMjJdqeW1FYWqX5LAaUVxkTgMoCawR3hJoHpOycLQ@mail.gmail.com>
	<56941EC4.8080902@redhat.com>
	<CAJgngAfxn+f0vX1Ax9hxrTyxtkhycjDRJiNqgksPKHBhDx0mMA@mail.gmail.com>
Message-ID: <CAJgngAcC2mQes4Z6ot+qq5hi=zGzTTVYYpa8D+L1WTB5KQHn4w@mail.gmail.com>

Another thing is that if we're introducing more two factor auth mechanisms
we need to be able to:

* Allow a realm to have one or more alternative two factor mechanisms. For
example a realm could either require a user to use a specific hardware
token or it could require user to simply have two factor enabled.
* Allow users to select which two factor mechanisms to use if a realm
supports more than one.
* Allow a user to have more than one two factor mechanisms registered with
their account and be able to select which one to use on login if they have
more than one.

Does the current authentication SPI support those?

On 12 January 2016 at 08:51, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 11 January 2016 at 22:29, Bill Burke <bburke at redhat.com> wrote:
>
>>
>> On 1/11/2016 4:15 PM, Thomas Darimont wrote:
>> > I'm currently working on a PR that provides "Two factor authentication
>> > via email" https://issues.jboss.org/browse/KEYCLOAK-240.
>> >
>> > My current implementation comes with a custom EmailCodeAuthenticator
>> > that generates a short code String in the challenge(...) Method and
>> > sends an email to the email address that is configured for the current
>> > user.
>> >
>> > The user can then copy and paste the code into an input field, similar
>> > to OTP codes are handled. If the user entered the wrong code, a new
>> > email is sent to the user's email address.
>> >
>> > The email code is saved as a user level credential.
>> >
>> > I wonder whether this is the right approach or whether it would be
>> better
>> > to allow the user to regenerate the code on demand instead of
>> > regenerating it every time?
>> >
>>
>> Don't know what you mean by that.  Just store the OTP within the
>> ClientSessionModel.  Generate the OTP, store it within the ClientSession
>> model, send the OTP to the user, display the OTP input page.  IMO, you
>> also should not resend the email on failure. Instead, supply a button
>> that they can click to resend the email.
>>
>
> +1 Just leverage what we already have for OTPs to generate codes to send
> in email. In fact we could even use the same OTP secret already stored for
> OTP when sending emails and SMS.
>
>
>>
>> > For the former I'd have to provide a REST endpoint similar to what
>> > happens for verifying an email
>> > during registration - where should this be placed?
>> >
>> > For sending the actual email I'm currently using a
>> > EmailSenderProvider, however I think a EmailTemplateProvider might be
>> > more appropriate ;-)
>> > May I simply add a method to the EmailTemplateProvider interface?
>> >
>>
>> We should have a more generic method on EmailTemplateProvider.
>>
>
> +1 Something like sendEmail(String template,...)
>
>
>>
>> > Btw. I think this would be a good base for having an SMS based 2nd
>> > factor authenticator, as requested here:
>> > https://issues.jboss.org/browse/KEYCLOAK-241
>> >
>> > It would make sense to have the mobile phone number as a first-class
>> > user attribute and showing it on the profile page by default instead
>> > of just having it only in the data model.
>> >
>> > Another point that comes to my mind is that I could make sense to
>> > specify an email code policy in the same way OTP policies are
>> > supported. This could then be used to differentiate between email
>> > codes that are usually handled via copy&paste whereas codes
>> > that come via SMS are usually typed in by hand and should therefore
>> > be somewhat short ;-)
>> >
>>
>> All that makes sense.  Never did an SMS based module as the SDKs used
>> differ per country, are quite diverse, and most of the time(?) cost money.
>>
>
> Yup, there's no standard to send SMS, but we could introduce a
> SMSSenderProvider which it would delegate to. That way it's relatively
> simple to implement an SMS sender.
>
>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/f160dc5b/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Tue Jan 12 02:57:48 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 12 Jan 2016 09:57:48 +0200
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <56941FCF.5000800@redhat.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
	<CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>
	<56941FCF.5000800@redhat.com>
Message-ID: <CAPyAMoZ8BLzfQh++=+0R6x0gTRK=WUU=_RHnd3ykwrSmaPUjAA@mail.gmail.com>

Hi,

On Mon, Jan 11, 2016 at 11:34 PM, Marek Posolda <mposolda at redhat.com> wrote:

> On 08/01/16 13:05, Stian Thorgersen wrote:
>
> It's to make it less likely that the username is already in use. We could
> use email for the username in those cases, but email is not always
> available. In the past we didn't have a way to allow the user to change the
> username if there was a conflict and instead the first login would just
> fail. With the introduction of first time social flows we could improve on
> this.
>
> We could allow selecting the strategy to use. Then allow the user to
> change if there's a conflict. We already allow users to change email if
> there's a conflict so can do the same for username.
>
> We already detect conflicts in both email and username. So user can either
> use different username or link the account corresponding to existing
> username. Also as Kamal mentioned, we already have the
> IdentityProviderMapper, which allows to configure how is username generated
> ( UsernameTemplateMapper ). We don't need any other strategy IMO as the
> mapper is flexible enough.
>
> Maybe we can improve how is username generated if mapper is not used?
> Currently the username is generated based on algorithm like this:
> 1) If there is IdentityProviderMapper which sets username, it has priority
> 2) Otherwise if realm.isRegistrationEmailAsUsername, then email from
> social provider is used as username
> 3) Otherwise if username from Identity provider is set, we generate the
> keycloak username like "<IDP alias>.<IDP username>" (For example
> "facebook.mposolda" )
> 4) Otherwise if username from identity provider is null, we generate the
> keycloak username like "<IDP alias>.<IDP ID>" (For example
> "facebook.12345" )
>
> IMO the one thing, which can be improved is removing the IDP prefix in
> step 3 and use just the username "mposolda" . If there is conflict, it can
> be easily resolved thanks to first broker login flow. I would likely keep
> the IDP alias in step 4 as having just username "12345" is a bit confusing
> IMO.
>
>
+1 sounds good to me!

In case there's a conflict, I'd appreciate if the user could either a)
change username/password, or b) connect to an existing account.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/ff7367b0/attachment.html 

From sthorger at redhat.com  Tue Jan 12 02:57:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 08:57:58 +0100
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <56941FCF.5000800@redhat.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
	<CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>
	<56941FCF.5000800@redhat.com>
Message-ID: <CAJgngAdc3uv9YZ4qEX4No9aK777tqs5U2AM7+dTj8_JtX+BVEw@mail.gmail.com>

On 11 January 2016 at 22:34, Marek Posolda <mposolda at redhat.com> wrote:

> On 08/01/16 13:05, Stian Thorgersen wrote:
>
> It's to make it less likely that the username is already in use. We could
> use email for the username in those cases, but email is not always
> available. In the past we didn't have a way to allow the user to change the
> username if there was a conflict and instead the first login would just
> fail. With the introduction of first time social flows we could improve on
> this.
>
> We could allow selecting the strategy to use. Then allow the user to
> change if there's a conflict. We already allow users to change email if
> there's a conflict so can do the same for username.
>
> We already detect conflicts in both email and username. So user can either
> use different username or link the account corresponding to existing
> username. Also as Kamal mentioned, we already have the
> IdentityProviderMapper, which allows to configure how is username generated
> ( UsernameTemplateMapper ). We don't need any other strategy IMO as the
> mapper is flexible enough.
>
> Maybe we can improve how is username generated if mapper is not used?
> Currently the username is generated based on algorithm like this:
> 1) If there is IdentityProviderMapper which sets username, it has priority
> 2) Otherwise if realm.isRegistrationEmailAsUsername, then email from
> social provider is used as username
> 3) Otherwise if username from Identity provider is set, we generate the
> keycloak username like "<IDP alias>.<IDP username>" (For example
> "facebook.mposolda" )
> 4) Otherwise if username from identity provider is null, we generate the
> keycloak username like "<IDP alias>.<IDP ID>" (For example
> "facebook.12345" )
>
> IMO the one thing, which can be improved is removing the IDP prefix in
> step 3 and use just the username "mposolda" . If there is conflict, it can
> be easily resolved thanks to first broker login flow. I would likely keep
> the IDP alias in step 4 as having just username "12345" is a bit confusing
> IMO.
>
> WDYT?
>

I didn't know that. Is the UsernameTemplateMapper documented?

I agree the only thing we need to do is in step 34 remove the "<IDP alias>"
prefix.


> Marek
>
>
> On 8 January 2016 at 12:32, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> Hi,
>>
>> If I login to Keycloak using a federated identity such as Google,
>> Keycloak inserts a prefix "google." to my username.
>>
>> Maybe I'm missing something, but isn't this kind of unnecessary when the
>> email address is already a unique property?
>>
>> Best regards,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/8eb8003b/attachment.html 

From sthorger at redhat.com  Tue Jan 12 03:02:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 09:02:35 +0100
Subject: [keycloak-dev] Why isn't the configuration/providers directory
 on my classpath when attempting to load a file?
In-Reply-To: <CA+z0A8Cp+aMBzuXZMEvRWyq2Y50CMDUdN1p2wwGLSH5ysU5JkQ@mail.gmail.com>
References: <CA+z0A8Cp+aMBzuXZMEvRWyq2Y50CMDUdN1p2wwGLSH5ysU5JkQ@mail.gmail.com>
Message-ID: <CAJgngAce3ArNKSBS=MhemBJ-jLqLK3bP5uTg+nwbG2ceA9Y2TA@mail.gmail.com>

The problem is in the library you're using as it shouldn't be using
the Thread.currentThread().getContextClassLoader(). It should use
getClass().getResource or getClass().getClassLoader(). Is there a way
around it?

On 11 January 2016 at 23:24, Josh Cain <josh.cain at redhat.com> wrote:

> Hi all,
>
> I'm in the process of writing an SPI for a federation provider that relies
> on a third party library, and the library in turn uses a number of files.
> I placed my SPI .jar, the third party library .jar, as well as its required
> files in the keycloak-1.7.0.Final/standalone/configuration/providers
> directory.  However, when the third party library attempts to locate its
> required files on the classpath, it cannot find them.
>
> Just for a sanity check, I've placed the files places like the
> sun/jdk/main module on the AS, and observed that the files were picked up
> properly since that particular folder was on the classpath.
>
> Can anyone help me understand why those files are not being picked up as
> classpath resources?  Does the configuration/providers directory not get
> added to the classpath?
>
> Just FYI, I poked through the library a bit, and it doesn't seem to be
> doing anything strange.  It winds up doing the equivalent of:
>
> Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/06aaf684/attachment.html 

From mstrukel at redhat.com  Tue Jan 12 04:55:30 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 12 Jan 2016 10:55:30 +0100
Subject: [keycloak-dev] Why isn't the configuration/providers directory
 on my classpath when attempting to load a file?
In-Reply-To: <CAJgngAce3ArNKSBS=MhemBJ-jLqLK3bP5uTg+nwbG2ceA9Y2TA@mail.gmail.com>
References: <CA+z0A8Cp+aMBzuXZMEvRWyq2Y50CMDUdN1p2wwGLSH5ysU5JkQ@mail.gmail.com>
	<CAJgngAce3ArNKSBS=MhemBJ-jLqLK3bP5uTg+nwbG2ceA9Y2TA@mail.gmail.com>
Message-ID: <CA+1OW+giY9UmoeAxGhMK=iCgB-qgSMdWRu89BxfZDEo87mvs2Q@mail.gmail.com>

What about simply wrapping the call in your provider that triggers
third party loading the configuration with the TCCL wrapping code
like:

ClassLoader old = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());

    callThirdPartyLibrary();

} finally {
    if (old != null) {
        Thread.currentThread().getContextClassLoader(old);
    }
}

If third party library only loads its files at init time, then one
time call from within ProviderFactory init() should be enough, and
other invocations should not require the TCCL wrapping code.

On Tue, Jan 12, 2016 at 9:02 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> The problem is in the library you're using as it shouldn't be using the
> Thread.currentThread().getContextClassLoader(). It should use
> getClass().getResource or getClass().getClassLoader(). Is there a way around
> it?
>
> On 11 January 2016 at 23:24, Josh Cain <josh.cain at redhat.com> wrote:
>>
>> Hi all,
>>
>> I'm in the process of writing an SPI for a federation provider that relies
>> on a third party library, and the library in turn uses a number of files.  I
>> placed my SPI .jar, the third party library .jar, as well as its required
>> files in the keycloak-1.7.0.Final/standalone/configuration/providers
>> directory.  However, when the third party library attempts to locate its
>> required files on the classpath, it cannot find them.
>>
>> Just for a sanity check, I've placed the files places like the
>> sun/jdk/main module on the AS, and observed that the files were picked up
>> properly since that particular folder was on the classpath.
>>
>> Can anyone help me understand why those files are not being picked up as
>> classpath resources?  Does the configuration/providers directory not get
>> added to the classpath?
>>
>> Just FYI, I poked through the library a bit, and it doesn't seem to be
>> doing anything strange.  It winds up doing the equivalent of:
>>
>>
>> Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);
>>
>> Josh Cain | Software Applications Engineer
>> Identity and Access Management
>> Red Hat
>> +1 843-737-1735
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Tue Jan 12 05:10:32 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 12 Jan 2016 11:10:32 +0100
Subject: [keycloak-dev] Why the provider prefix in username?
In-Reply-To: <CAJgngAdc3uv9YZ4qEX4No9aK777tqs5U2AM7+dTj8_JtX+BVEw@mail.gmail.com>
References: <CAPyAMoZFbPMTWHnmj7Q=YaNYGnVonaSjbTL-yTttiieY3=Yfdw@mail.gmail.com>
	<CAJgngAey+xuO=gf9u96L7e5-zuJf6nAZdPE1XEKGymLadr2-YA@mail.gmail.com>
	<56941FCF.5000800@redhat.com>
	<CAJgngAdc3uv9YZ4qEX4No9aK777tqs5U2AM7+dTj8_JtX+BVEw@mail.gmail.com>
Message-ID: <5694D118.3090304@redhat.com>

On 12/01/16 08:57, Stian Thorgersen wrote:
>
>
> On 11 January 2016 at 22:34, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 08/01/16 13:05, Stian Thorgersen wrote:
>>     It's to make it less likely that the username is already in use.
>>     We could use email for the username in those cases, but email is
>>     not always available. In the past we didn't have a way to allow
>>     the user to change the username if there was a conflict and
>>     instead the first login would just fail. With the introduction of
>>     first time social flows we could improve on this.
>>
>>     We could allow selecting the strategy to use. Then allow the user
>>     to change if there's a conflict. We already allow users to change
>>     email if there's a conflict so can do the same for username.
>     We already detect conflicts in both email and username. So user
>     can either use different username or link the account
>     corresponding to existing username. Also as Kamal mentioned, we
>     already have the IdentityProviderMapper, which allows to configure
>     how is username generated ( UsernameTemplateMapper ). We don't
>     need any other strategy IMO as the mapper is flexible enough.
>
>     Maybe we can improve how is username generated if mapper is not
>     used? Currently the username is generated based on algorithm like
>     this:
>     1) If there is IdentityProviderMapper which sets username, it has
>     priority
>     2) Otherwise if realm.isRegistrationEmailAsUsername, then email
>     from social provider is used as username
>     3) Otherwise if username from Identity provider is set, we
>     generate the keycloak username like "<IDP alias>.<IDP username>"
>     (For example "facebook.mposolda" )
>     4) Otherwise if username from identity provider is null, we
>     generate the keycloak username like "<IDP alias>.<IDP ID>" (For
>     example "facebook.12345" )
>
>     IMO the one thing, which can be improved is removing the IDP
>     prefix in step 3 and use just the username "mposolda" . If there
>     is conflict, it can be easily resolved thanks to first broker
>     login flow. I would likely keep the IDP alias in step 4 as having
>     just username "12345" is a bit confusing IMO.
>
>     WDYT?
>
>
> I didn't know that. Is the UsernameTemplateMapper documented?
There is some generic info about broker mappers in identity broker 
chapter in 10.8 and 10.9 : 
http://keycloak.github.io/docs/userguide/keycloak-server/html/identity-broker.html#d4e2135 
. Besides that there are tooltips in admin console on details how to use 
various template tokens to generate username.
>
> I agree the only thing we need to do is in step 34 remove the "<IDP 
> alias>" prefix.
Created https://issues.jboss.org/browse/KEYCLOAK-2292 for 1.9

Marek
>
>
>     Marek
>>
>>     On 8 January 2016 at 12:32, Thomas Raehalme
>>     <thomas.raehalme at aitiofinland.com
>>     <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>>
>>         Hi,
>>
>>         If I login to Keycloak using a federated identity such as
>>         Google, Keycloak inserts a prefix "google." to my username.
>>
>>         Maybe I'm missing something, but isn't this kind of
>>         unnecessary when the email address is already a unique property?
>>
>>         Best regards,
>>         Thomas
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From josh.cain at redhat.com  Tue Jan 12 09:51:43 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Tue, 12 Jan 2016 08:51:43 -0600
Subject: [keycloak-dev] Why isn't the configuration/providers directory
 on my classpath when attempting to load a file?
In-Reply-To: <CA+1OW+giY9UmoeAxGhMK=iCgB-qgSMdWRu89BxfZDEo87mvs2Q@mail.gmail.com>
References: <CA+z0A8Cp+aMBzuXZMEvRWyq2Y50CMDUdN1p2wwGLSH5ysU5JkQ@mail.gmail.com>
	<CAJgngAce3ArNKSBS=MhemBJ-jLqLK3bP5uTg+nwbG2ceA9Y2TA@mail.gmail.com>
	<CA+1OW+giY9UmoeAxGhMK=iCgB-qgSMdWRu89BxfZDEo87mvs2Q@mail.gmail.com>
Message-ID: <CA+z0A8CtRQ5DkoVBrfyBpkwgbu1v46AvM09TLmdJscjK1RhV3Q@mail.gmail.com>

Sounds good, thanks for pointing that out Stian and Marko.  Might work
through a little wrapping code now, but should be able to work with the lib
authors to get that changed.

Appreciate the help!

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Tue, Jan 12, 2016 at 3:55 AM, Marko Strukelj <mstrukel at redhat.com> wrote:

> What about simply wrapping the call in your provider that triggers
> third party loading the configuration with the TCCL wrapping code
> like:
>
> ClassLoader old = Thread.currentThread().getContextClassLoader();
> try {
>
> Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
>
>     callThirdPartyLibrary();
>
> } finally {
>     if (old != null) {
>         Thread.currentThread().getContextClassLoader(old);
>     }
> }
>
> If third party library only loads its files at init time, then one
> time call from within ProviderFactory init() should be enough, and
> other invocations should not require the TCCL wrapping code.
>
> On Tue, Jan 12, 2016 at 9:02 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> > The problem is in the library you're using as it shouldn't be using the
> > Thread.currentThread().getContextClassLoader(). It should use
> > getClass().getResource or getClass().getClassLoader(). Is there a way
> around
> > it?
> >
> > On 11 January 2016 at 23:24, Josh Cain <josh.cain at redhat.com> wrote:
> >>
> >> Hi all,
> >>
> >> I'm in the process of writing an SPI for a federation provider that
> relies
> >> on a third party library, and the library in turn uses a number of
> files.  I
> >> placed my SPI .jar, the third party library .jar, as well as its
> required
> >> files in the keycloak-1.7.0.Final/standalone/configuration/providers
> >> directory.  However, when the third party library attempts to locate its
> >> required files on the classpath, it cannot find them.
> >>
> >> Just for a sanity check, I've placed the files places like the
> >> sun/jdk/main module on the AS, and observed that the files were picked
> up
> >> properly since that particular folder was on the classpath.
> >>
> >> Can anyone help me understand why those files are not being picked up as
> >> classpath resources?  Does the configuration/providers directory not get
> >> added to the classpath?
> >>
> >> Just FYI, I poked through the library a bit, and it doesn't seem to be
> >> doing anything strange.  It winds up doing the equivalent of:
> >>
> >>
> >>
> Thread.currentThread().getContextClassLoader().getResourceAsStream(filePath);
> >>
> >> Josh Cain | Software Applications Engineer
> >> Identity and Access Management
> >> Red Hat
> >> +1 843-737-1735
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/d159edb7/attachment.html 

From bburke at redhat.com  Tue Jan 12 10:26:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 12 Jan 2016 10:26:11 -0500
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
Message-ID: <56951B13.7020401@redhat.com>



On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>
>
> On 12 January 2016 at 03:22, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I can't find the original email on this, but we need to do this for
>     1.9.  I can start doing it one module at a time: 
>
>
>     Common:
>     keycloak-common
>     keycloak-common-saml
>     keycloak-common-oidc
>
>     Libraries server:
>
>     keycloak-server-spi - all SPI interfaces and common code
>     keycloak-server-saml - all saml server code, broker and protocol
>     plugins
>     keycloak-server-oidc - all oidc code, broker and protocol plugins
>     keycloak-server-impl - everything
>
>
> I'm not 100% sure we should put all implementations of SPIs into 
> keycloak-server-impl. We at least need to keep Mongo separate as it's 
> not part of the product.
>
> If we put all SPI implementations, including services, into the same 
> module we'd end up with one huge module. There's also a risk that we'd 
> end up with strong relationships between them, rather than having them 
> properly linked via SPI interfaces.
>
> I'm a bit 50/50 on it though.
You do remember how many modules we currently have don't you? Minimally, 
we should have a big SPI module right?


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

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

From srossillo at smartling.com  Tue Jan 12 11:32:36 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 12 Jan 2016 11:32:36 -0500
Subject: [keycloak-dev] Exception in 1.7.0 during login using federation
	provider
In-Reply-To: <2A0537FF-B48C-45DC-A76D-E265ED0E7FDC@smartling.com>
References: <06604867-52FD-4661-8EAC-B1BD31638867@smartling.com>
	<2A0537FF-B48C-45DC-A76D-E265ED0E7FDC@smartling.com>
Message-ID: <CF406C52-7A0B-4C1D-B1CC-727B4E8070DD@smartling.com>

I figured it out myself. No need to reply.



> On Jan 11, 2016, at 6:36 PM, Scott Rossillo <srossillo at smartling.com> wrote:
> 
> I published the full code if that?s easier to look at.
> 
> Project: https://github.com/Smartling/keycloak-user-migration-provider <https://github.com/Smartling/keycloak-user-migration-provider>
> 
> Federation Provider: https://github.com/Smartling/keycloak-user-migration-provider/blob/master/user-migration-federation-provider/src/main/java/com/smartling/keycloak/provider/RemoteUserFederationProvider.java <https://github.com/Smartling/keycloak-user-migration-provider/blob/master/user-migration-federation-provider/src/main/java/com/smartling/keycloak/provider/RemoteUserFederationProvider.java>
> 
> Any help would be greatly appreciated with the exception below.
> 
> Best,
> Scott
>  <http://www.sigstr.com/>
> 
>> On Jan 11, 2016, at 12:39 PM, Scott Rossillo <srossillo at smartling.com <mailto:srossillo at smartling.com>> wrote:
>> 
>> Hey,
>> 
>> I?m trying to publish an example of how to do on demand user migration using a federation provider. It?s a modified version of what we use on an older Keycloak version.  The error I?m getting (with H2, Keycloak 1.7.0 out-of-the-box) is below.
>> 
>> At the time the exception is thrown, Kecyloak hasn?t attempted to validate credentials yet.
>> 
>> It has only called these methods:
>> - UserModel getUserByUsername(RealmModel realm, String username);
>> - public boolean isValid(RealmModel realm, UserModel local);
>> 
>> After calling session.users().addUser() am I supposed to release something?
>> 
>> Thanks,
>> Scott
>> 
>> -------
>> 
>> Methods:
>> 
>> @Override
>> public UserModel getUserByUsername(RealmModel realm, String username) { {
>> 
>>    String username = rawUsername.toLowerCase().trim();
>>    FederatedUserModel remoteUser = federatedUserService.getUserDetails(username);
>>    LOG.infof("Creating user model for: %s", username);
>>    UserModel userModel = session.users().addUser(realm, username);
>> 
>>    if (!username.equals(remoteUser.getEmail())) {
>>        throw new IllegalStateException(String.format("Local and remote users differ: [%s != %s]", username, remoteUser.getUsername()));
>>    }
>> 
>>    userModel.setFederationLink(model.getId());
>>    userModel.setEnabled(remoteUser.isEnabled());
>>    userModel.setEmail(username);
>>    userModel.setEmailVerified(remoteUser.isEmailVerified());
>>    userModel.setFirstName(remoteUser.getFirstName());
>>    userModel.setLastName(remoteUser.getLastName());
>> 
>>    if (remoteUser.getAttributes() != null) {
>>        Map<String, List<String>> attributes = remoteUser.getAttributes();
>>        for (String attributeName : attributes.keySet())
>>            userModel.setAttribute(attributeName, attributes.get(attributeName));
>>    }
>> 
>>    if (remoteUser.getRoles() != null) {
>>        for (String role : remoteUser.getRoles()) {
>>            RoleModel roleModel = realm.getRole(role);
>>            if (roleModel != null) {
>>                userModel.grantRole(roleModel);
>>                LOG.infof("Granted user %s, role %s", username, role);
>>            }
>>        }
>>    }
>> 
>>    return userModel;
>> }
>> 
>> @Override
>> public boolean isValid(RealmModel realm, UserModel local)
>> {
>>    Response response = federatedUserService.validateUserExists(local.getUsername());
>>    return HttpStatus.SC_ACCEPTED == response.getStatus();
>> }
>> 
>> Exception:
>> 
>> 2:13:51,497 WARN  [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) SQL Error: 50200, SQLState: HYT00
>> 12:13:51,498 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-88) Timeout trying to lock table "USER_ENTITY"; SQL statement:
>> select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
>> 12:13:51,499 ERROR [org.keycloak.authentication.AuthenticationProcessor] (default task-88) failed authentication: javax.persistence.PessimisticLockException: could not extract ResultSet
>> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.wrapLockException(AbstractEntityManagerImpl.java:1831)
>> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1720)
>> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
>> 	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:458)
>> 	at org.keycloak.models.jpa.JpaUserProvider.getUserById(JpaUserProvider.java:260)
>> 	at org.keycloak.models.cache.infinispan.DefaultCacheUserProvider.getUserById(DefaultCacheUserProvider.java:122)
>> 	at org.keycloak.models.UserFederationManager.deleteInvalidUser(UserFederationManager.java:112)
>> 	at org.keycloak.models.UserFederationManager.validateUser(UserFederationManager.java:100)
>> 	at org.keycloak.models.UserFederationManager.validCredentials(UserFederationManager.java:409)
>> 	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validatePassword(AbstractUsernameFormAuthenticator.java:152)
>> 	at org.keycloak.authentication.authenticators.browser.AbstractUsernameFormAuthenticator.validateUserAndPassword(AbstractUsernameFormAuthenticator.java:128)
>> 	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.validateForm(UsernamePasswordForm.java:41)
>> 	at org.keycloak.authentication.authenticators.browser.UsernamePasswordForm.action(UsernamePasswordForm.java:34)
>> 	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:65)
>> 	at org.keycloak.authentication.DefaultAuthenticationFlow.processAction(DefaultAuthenticationFlow.java:57)
>> 	at org.keycloak.authentication.AuthenticationProcessor.authenticationAction(AuthenticationProcessor.java:744)
>> 	at org.keycloak.services.resources.LoginActionsService.processFlow(LoginActionsService.java:299)
>> 	at org.keycloak.services.resources.LoginActionsService.processAuthentication(LoginActionsService.java:280)
>> 	at org.keycloak.services.resources.LoginActionsService.authenticateForm(LoginActionsService.java:326)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(Method.java:606)
>> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
>> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
>> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
>> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
>> 	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
>> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
>> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
>> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
>> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
>> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
>> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
>> 	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:61)
>> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
>> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
>> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:282)
>> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:261)
>> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> 	at java.lang.Thread.run(Thread.java:745)
>> Caused by: org.hibernate.PessimisticLockException: could not extract ResultSet
>> 	at org.hibernate.dialect.H2Dialect$2.convert(H2Dialect.java:342)
>> 	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
>> 	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126)
>> 	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112)
>> 	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:91)
>> 	at org.hibernate.loader.Loader.getResultSet(Loader.java:2066)
>> 	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1863)
>> 	at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1839)
>> 	at org.hibernate.loader.Loader.doQuery(Loader.java:910)
>> 	at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:355)
>> 	at org.hibernate.loader.Loader.doList(Loader.java:2554)
>> 	at org.hibernate.loader.Loader.doList(Loader.java:2540)
>> 	at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2370)
>> 	at org.hibernate.loader.Loader.list(Loader.java:2365)
>> 	at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:497)
>> 	at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387)
>> 	at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:236)
>> 	at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1300)
>> 	at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103)
>> 	at org.hibernate.jpa.internal.QueryImpl.list(QueryImpl.java:573)
>> 	at org.hibernate.jpa.internal.QueryImpl.getResultList(QueryImpl.java:449)
>> 	... 62 more
>> Caused by: org.h2.jdbc.JdbcSQLException: Timeout trying to lock table "USER_ENTITY"; SQL statement:
>> select userentity0_.ID as ID1_46_, userentity0_.CREATED_TIMESTAMP as CREATED_2_46_, userentity0_.EMAIL as EMAIL3_46_, userentity0_.EMAIL_CONSTRAINT as EMAIL_CO4_46_, userentity0_.EMAIL_VERIFIED as EMAIL_VE5_46_, userentity0_.ENABLED as ENABLED6_46_, userentity0_.FEDERATION_LINK as FEDERATI7_46_, userentity0_.FIRST_NAME as FIRST_NA8_46_, userentity0_.LAST_NAME as LAST_NAM9_46_, userentity0_.REALM_ID as REALM_I10_46_, userentity0_.SERVICE_ACCOUNT_CLIENT_LINK as SERVICE11_46_, userentity0_.TOTP as TOTP12_46_, userentity0_.USERNAME as USERNAM13_46_ from USER_ENTITY userentity0_ where userentity0_.ID=? and userentity0_.REALM_ID=? [50200-173]
>> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
>> 	at org.h2.message.DbException.get(DbException.java:171)
>> 	at org.h2.message.DbException.get(DbException.java:148)
>> 	at org.h2.table.RegularTable.doLock(RegularTable.java:521)
>> 	at org.h2.table.RegularTable.lock(RegularTable.java:455)
>> 	at org.h2.table.TableFilter.lock(TableFilter.java:145)
>> 	at org.h2.command.dml.Select.queryWithoutCache(Select.java:611)
>> 	at org.h2.command.dml.Query.query(Query.java:314)
>> 	at org.h2.command.dml.Query.query(Query.java:284)
>> 	at org.h2.command.dml.Query.query(Query.java:36)
>> 	at org.h2.command.CommandContainer.query(CommandContainer.java:91)
>> 	at org.h2.command.Command.executeQuery(Command.java:195)
>> 	at org.h2.jdbc.JdbcPreparedStatement.executeQuery(JdbcPreparedStatement.java:106)
>> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
>> 	at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:82)
>> 	... 78 more
>> 
>> 
>> 
> 

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

From thomas.raehalme at aitiofinland.com  Tue Jan 12 12:37:42 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 12 Jan 2016 19:37:42 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
Message-ID: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>

Hi!

We have a need to publish Keycloak events to external systems, for example
when user updates her profile. I was thinking of publishing messages to a
JMS topic by implementing an event listener.

What do you think, would you be interested in such a pull request? I think
the topic should be preconfigured in Keycloak/Wildfly, but the admin would
enable the functionality by adding "jms" to event listeners in the admin
console.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/3336bde4/attachment.html 

From sthorger at redhat.com  Tue Jan 12 13:32:16 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 19:32:16 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <56951B13.7020401@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
Message-ID: <CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>

On 12 January 2016 at 16:26, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>
>
>
> On 12 January 2016 at 03:22, Bill Burke <bburke at redhat.com> wrote:
>
>> I can't find the original email on this, but we need to do this for
>> 1.9.  I can start doing it one module at a time:
>
>
>> Common:
>> keycloak-common
>> keycloak-common-saml
>> keycloak-common-oidc
>>
>> Libraries server:
>>
>> keycloak-server-spi - all SPI interfaces and common code
>> keycloak-server-saml - all saml server code, broker and protocol plugins
>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>> keycloak-server-impl - everything
>>
>
> I'm not 100% sure we should put all implementations of SPIs into
> keycloak-server-impl. We at least need to keep Mongo separate as it's not
> part of the product.
>
> If we put all SPI implementations, including services, into the same
> module we'd end up with one huge module. There's also a risk that we'd end
> up with strong relationships between them, rather than having them properly
> linked via SPI interfaces.
>
> I'm a bit 50/50 on it though.
>
> You do remember how many modules we currently have don't you?  Minimally,
> we should have a big SPI module right?
>

I'm absolutely on board with:

Common:
keycloak-common
keycloak-common-saml
keycloak-common-oidc

Libraries server:
keycloak-server-spi

So we can agree on that, I'm just not 100% sure about a single module for
all SPI implementations and services.



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

From sthorger at redhat.com  Tue Jan 12 13:33:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 19:33:42 +0100
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
Message-ID: <CAJgngAcT=Asn4iRxEHNT+n1-tfaWJLUNCM-Xd34M8VzdeqwTEg@mail.gmail.com>

+1 From me

On 12 January 2016 at 18:37, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> Hi!
>
> We have a need to publish Keycloak events to external systems, for example
> when user updates her profile. I was thinking of publishing messages to a
> JMS topic by implementing an event listener.
>
> What do you think, would you be interested in such a pull request? I think
> the topic should be preconfigured in Keycloak/Wildfly, but the admin would
> enable the functionality by adding "jms" to event listeners in the admin
> console.
>
> Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/6b179da9/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 12 13:34:35 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 12 Jan 2016 19:34:35 +0100
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
Message-ID: <CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>

Hi Thomas,

would be great to have that!

Cheers,
Thomas

2016-01-12 18:37 GMT+01:00 Thomas Raehalme <thomas.raehalme at aitiofinland.com
>:

> Hi!
>
> We have a need to publish Keycloak events to external systems, for example
> when user updates her profile. I was thinking of publishing messages to a
> JMS topic by implementing an event listener.
>
> What do you think, would you be interested in such a pull request? I think
> the topic should be preconfigured in Keycloak/Wildfly, but the admin would
> enable the functionality by adding "jms" to event listeners in the admin
> console.
>
> Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/a757700e/attachment.html 

From sthorger at redhat.com  Tue Jan 12 13:44:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 19:44:48 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
Message-ID: <CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>

On 12 January 2016 at 19:32, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 12 January 2016 at 16:26, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>
>>
>>
>> On 12 January 2016 at 03:22, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I can't find the original email on this, but we need to do this for
>>> 1.9.  I can start doing it one module at a time:
>>
>>
>>> Common:
>>> keycloak-common
>>> keycloak-common-saml
>>> keycloak-common-oidc
>>>
>>> Libraries server:
>>>
>>> keycloak-server-spi - all SPI interfaces and common code
>>> keycloak-server-saml - all saml server code, broker and protocol plugins
>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>> keycloak-server-impl - everything
>>>
>>
>> I'm not 100% sure we should put all implementations of SPIs into
>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>> part of the product.
>>
>> If we put all SPI implementations, including services, into the same
>> module we'd end up with one huge module. There's also a risk that we'd end
>> up with strong relationships between them, rather than having them properly
>> linked via SPI interfaces.
>>
>> I'm a bit 50/50 on it though.
>>
>> You do remember how many modules we currently have don't you?  Minimally,
>> we should have a big SPI module right?
>>
>
> I'm absolutely on board with:
>
> Common:
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> Libraries server:
> keycloak-server-spi
>
> So we can agree on that, I'm just not 100% sure about a single module for
> all SPI implementations and services.
>

We can go with a single module if you want. Only thing that needs to be
separate is Mongo at least for now as it's not going to be supported and we
need to be able to remove it easily.


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

From azenk at umn.edu  Tue Jan 12 14:12:00 2016
From: azenk at umn.edu (Andrew Zenk)
Date: Tue, 12 Jan 2016 13:12:00 -0600
Subject: [keycloak-dev] Mvn artifact: org.keycloak:keycloak-admin-client
Message-ID: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>

I'm writing some code that will hook into the keycloak admin rest api.  I
noticed that this client module exists under the integration tree in the
repo, though it doesn't seem to align with the current rest api 100%.  Is
it something that is currently being maintained?

-- 
Andrew Zenk, EIT
Polar Geospatial Center
University of Minnesota
Office: (612) 625-0872
Cell: (612) 414-9617
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/062a3d69/attachment.html 

From sthorger at redhat.com  Tue Jan 12 14:28:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 12 Jan 2016 20:28:56 +0100
Subject: [keycloak-dev] Mvn artifact: org.keycloak:keycloak-admin-client
In-Reply-To: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>
References: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>
Message-ID: <CAJgngAfeJwd-6141Zts4FwNYJmi3+Ct3E8QkKrpf4GFCjz2O1Q@mail.gmail.com>

It is being maintained, but it's lagging a bit behind.

On 12 January 2016 at 20:12, Andrew Zenk <azenk at umn.edu> wrote:

> I'm writing some code that will hook into the keycloak admin rest api.  I
> noticed that this client module exists under the integration tree in the
> repo, though it doesn't seem to align with the current rest api 100%.  Is
> it something that is currently being maintained?
>
> --
> Andrew Zenk, EIT
> Polar Geospatial Center
> University of Minnesota
> Office: (612) 625-0872
> Cell: (612) 414-9617
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/12ebe351/attachment.html 

From azenk at umn.edu  Tue Jan 12 14:39:31 2016
From: azenk at umn.edu (Andrew Zenk)
Date: Tue, 12 Jan 2016 13:39:31 -0600
Subject: [keycloak-dev] Mvn artifact: org.keycloak:keycloak-admin-client
In-Reply-To: <CAJgngAfeJwd-6141Zts4FwNYJmi3+Ct3E8QkKrpf4GFCjz2O1Q@mail.gmail.com>
References: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>
	<CAJgngAfeJwd-6141Zts4FwNYJmi3+Ct3E8QkKrpf4GFCjz2O1Q@mail.gmail.com>
Message-ID: <CA+Evd+HUHj6DXPj-+LqORRnHyEqCjz-fmzH3Ce7wT=LU3Z4KDg@mail.gmail.com>

I'm sure I'll need to clean up a few things for my purposes, would you like
the feedback via jira, and perhaps a pull request or two?

On Tue, Jan 12, 2016 at 1:28 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> It is being maintained, but it's lagging a bit behind.
>
> On 12 January 2016 at 20:12, Andrew Zenk <azenk at umn.edu> wrote:
>
>> I'm writing some code that will hook into the keycloak admin rest api.  I
>> noticed that this client module exists under the integration tree in the
>> repo, though it doesn't seem to align with the current rest api 100%.  Is
>> it something that is currently being maintained?
>>
>> --
>> Andrew Zenk, EIT
>> Polar Geospatial Center
>> University of Minnesota
>> Office: (612) 625-0872
>> Cell: (612) 414-9617
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>


-- 
Andrew Zenk, EIT
Polar Geospatial Center
University of Minnesota
Office: (612) 625-0872
Cell: (612) 414-9617
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/fa3bf897/attachment.html 

From josh.cain at redhat.com  Tue Jan 12 17:42:34 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Tue, 12 Jan 2016 16:42:34 -0600
Subject: [keycloak-dev] Mvn artifact: org.keycloak:keycloak-admin-client
In-Reply-To: <CA+Evd+HUHj6DXPj-+LqORRnHyEqCjz-fmzH3Ce7wT=LU3Z4KDg@mail.gmail.com>
References: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>
	<CAJgngAfeJwd-6141Zts4FwNYJmi3+Ct3E8QkKrpf4GFCjz2O1Q@mail.gmail.com>
	<CA+Evd+HUHj6DXPj-+LqORRnHyEqCjz-fmzH3Ce7wT=LU3Z4KDg@mail.gmail.com>
Message-ID: <CA+z0A8BL_SAUzh1xhbDEiZ4=JLbE39mYHwSVzOejd1CLo7QHUw@mail.gmail.com>

Right behind you Andrew, this is going to be very useful for me as well in
the near future.  Perhaps we can revive this?

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Tue, Jan 12, 2016 at 1:39 PM, Andrew Zenk <azenk at umn.edu> wrote:

> I'm sure I'll need to clean up a few things for my purposes, would you
> like the feedback via jira, and perhaps a pull request or two?
>
> On Tue, Jan 12, 2016 at 1:28 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> It is being maintained, but it's lagging a bit behind.
>>
>> On 12 January 2016 at 20:12, Andrew Zenk <azenk at umn.edu> wrote:
>>
>>> I'm writing some code that will hook into the keycloak admin rest api.
>>> I noticed that this client module exists under the integration tree in the
>>> repo, though it doesn't seem to align with the current rest api 100%.  Is
>>> it something that is currently being maintained?
>>>
>>> --
>>> Andrew Zenk, EIT
>>> Polar Geospatial Center
>>> University of Minnesota
>>> Office: (612) 625-0872
>>> Cell: (612) 414-9617
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
> --
> Andrew Zenk, EIT
> Polar Geospatial Center
> University of Minnesota
> Office: (612) 625-0872
> Cell: (612) 414-9617
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/94ef68b5/attachment.html 

From josh.cain at redhat.com  Tue Jan 12 17:56:03 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Tue, 12 Jan 2016 16:56:03 -0600
Subject: [keycloak-dev] UserFederationProvider with non-trivial configuration
Message-ID: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>

Hi all,

I've got a UserFederationProvider that needs 6-8 configuration elements, to
include enumerated types and even a couple of files.  I'd like to keep the
configuration of this provider in the Keycloak admin console, but am not
sure how to do so.

I've read through the themes documentation
<http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
but I have not been able to find a suitable solution.  I thought of just
dropping a new partial in there to handle more straightforward
configuration items like enumerated types, but couldn't find a way to do so
without having to override the entire app.js.  What's more, I was not
certain if Keycloak was already set up to handle something like a File
object in the REST/DB backend.

I suppose my question boils down to "How can I integrate enumerated and
file type configuration options for my UserFederationProvider into the
Keycloak administration system?"  Any help would be much appreciated -
thanks!

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/233bf264/attachment.html 

From sthorger at redhat.com  Wed Jan 13 02:40:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 08:40:27 +0100
Subject: [keycloak-dev] Mvn artifact: org.keycloak:keycloak-admin-client
In-Reply-To: <CA+Evd+HUHj6DXPj-+LqORRnHyEqCjz-fmzH3Ce7wT=LU3Z4KDg@mail.gmail.com>
References: <CA+Evd+H+Mw1ZX-UQbrfr4OmzXuy+r7ryhwEFCDg8qD0oFSCwhQ@mail.gmail.com>
	<CAJgngAfeJwd-6141Zts4FwNYJmi3+Ct3E8QkKrpf4GFCjz2O1Q@mail.gmail.com>
	<CA+Evd+HUHj6DXPj-+LqORRnHyEqCjz-fmzH3Ce7wT=LU3Z4KDg@mail.gmail.com>
Message-ID: <CAJgngAd_2yWwnT=5hErjR=OnTBFjVptOptPYwoK2X4GGaFgd+g@mail.gmail.com>

On 12 January 2016 at 20:39, Andrew Zenk <azenk at umn.edu> wrote:

> I'm sure I'll need to clean up a few things for my purposes, would you
> like the feedback via jira, and perhaps a pull request or two?
>

Yes please. PRs would be great.


>
> On Tue, Jan 12, 2016 at 1:28 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> It is being maintained, but it's lagging a bit behind.
>>
>> On 12 January 2016 at 20:12, Andrew Zenk <azenk at umn.edu> wrote:
>>
>>> I'm writing some code that will hook into the keycloak admin rest api.
>>> I noticed that this client module exists under the integration tree in the
>>> repo, though it doesn't seem to align with the current rest api 100%.  Is
>>> it something that is currently being maintained?
>>>
>>> --
>>> Andrew Zenk, EIT
>>> Polar Geospatial Center
>>> University of Minnesota
>>> Office: (612) 625-0872
>>> Cell: (612) 414-9617
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
> --
> Andrew Zenk, EIT
> Polar Geospatial Center
> University of Minnesota
> Office: (612) 625-0872
> Cell: (612) 414-9617
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/74626e87/attachment-0001.html 

From sthorger at redhat.com  Wed Jan 13 05:52:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 11:52:41 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
Message-ID: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>

Keycloak 1.8.0.CR1 has just been released. As usual we will follow with a
final release next week as long as no major issues are reported.


   - *Default Admin User Removed* - we no longer have a built in admin
   account, instead a new account has to be created initially from
   http://localhost:8080/auth or with the bin/add-user[sh|bat] script
   - *Client Templates* - with the introduction of client templates it's
   now possible to share mappers and scope configuration between clients
   - *Partial Import* - it's now possible to import users, clients,
   identity brokers and user federators from a json file into an existing realm
   - *Truststore SPI* - we've introduced a Truststore SPI which provides a
   centralized place to manage the truststore for clients, email, user
   federation and identity brokering
   - *Password Hashing SPI* - if you want to import existing users into
   Keycloak you can implement a password hashing provider so existing hashed
   passwords can be used (thanks to tsudo <https://github.com/tsudot> for
   the contribution)
   - *Identity Brokering Login Flow* - this allows customizing the flow
   used when a user logs in through an identity broker
   - *SAML v2 Enhanced Client or Proxy Profile (ECP)
   <http://wiki.oasis-open.org/security/SAML2EnhancedClientProfile>* - this
   SAML profile is useful for non-browser based clients (for example a desktop
   application)
   - *OAuth2 Token Introspection <https://tools.ietf.org/html/rfc7662>* -
   the OAuth2 token introspection specification provides a standard way to
   obtain the active state of a token
   - *Conditional OTP* - requiring OTP used to be either enabled or
   disabled for a realm, it's now possible to conditionally choose which users
   require OTP based on for example a role or a request header (thanks to
   thomasdarimont <https://github.com/thomasdarimont> for the contribution)
   - *Realm Display Name* - a display name has been added to realms, which
   makes it possible to set a human readable name to be shown on login
   screens, emails, etc.
   - *WildFly 10.0.0.CR5* - Keycloak is now built on top of WildFly
   10.0.0.CR5. Deploying the server overlay to WildFly 9 is no longer supported

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

From kga.official at gmail.com  Wed Jan 13 05:57:04 2016
From: kga.official at gmail.com (Akshay Kini)
Date: Wed, 13 Jan 2016 16:27:04 +0530
Subject: [keycloak-dev] Possible defect when using SAML Client Java Servlet
	Filter
Message-ID: <CAFtx=TmhMvqU14G6WyH3QgCjbJuesWkkGb9xWMoTzqq7FeBLVg@mail.gmail.com>

Hi Folks,

I was using the filter: org.keycloak.adapters.saml.servlet.SamlFilter in
our application.

I got the following exception in the logs:

ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/].[AppName]]
Servlet.service() for servlet NasDefault threw exception:
java.lang.RuntimeException: This method is not supported in a restored
authenticated request
    at
org.keycloak.adapters.servlet.FilterSessionStore$1.getDateHeader(FilterSessionStore.java:178)
[:1.7.0.CR1]
    at
org.apache.catalina.servlets.DefaultServlet.checkIfModifiedSince(DefaultServlet.java:1731)
[:]
    at
org.apache.catalina.servlets.DefaultServlet.checkIfHeaders(DefaultServlet.java:608)
[:]
    at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:714)
[:]
    at
org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:368)
[:]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
[:1.0.0.Final]
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
[:1.0.0.Final]
    at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
[:]
    at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
[:]
... (trimmed)
...
    at
org.keycloak.adapters.saml.servlet.SamlFilter.doFilter(SamlFilter.java:125)
[:1.7.0.CR1]
...(trimmed)
...
etc.

After looking into the Keycloak code base, I saw the method (implemented in
an anonymous class):
javax.servlet.http.HttpServletRequestWrapper#getDateHeader
inside the class: org.keycloak.adapters.servlet.FilterSessionStore

The code was:
@Override
public long getDateHeader(String name) {
    if (!needRequestRestore) return super.getDateHeader(name);
         throw new RuntimeException("This method is not supported in a
restored authenticated request");
    }

Looks like a particular case isn't implemented yet, and an exception is
thrown.

After looking into the JEE API at:
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#getDateHeader-java.lang.String-

It is required that any class implementing HttpServletRequest
getDateHeader() method, return a -1 in case it cannot get the required
header.

Hence, I suggest that instead of throwing an exception to handle the error
condition, we should return -1.

*Any help appreciated.*

Thanks,
Regards,
Akshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/3ffe10b7/attachment.html 

From Edgar at info.nl  Wed Jan 13 07:40:07 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Wed, 13 Jan 2016 12:40:07 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
	password policies
Message-ID: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>

Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?

cheers

Edgar



From thomas.raehalme at aitiofinland.com  Wed Jan 13 08:13:50 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Jan 2016 15:13:50 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
Message-ID: <CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>

Hi,

Thanks for the feedback! I hope to send a PR in the next few days or so.

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

Best regards,
Thomas


On Tue, Jan 12, 2016 at 8:34 PM, Thomas Darimont <
thomas.darimont at googlemail.com> wrote:

> Hi Thomas,
>
> would be great to have that!
>
> Cheers,
> Thomas
>
> 2016-01-12 18:37 GMT+01:00 Thomas Raehalme <
> thomas.raehalme at aitiofinland.com>:
>
>> Hi!
>>
>> We have a need to publish Keycloak events to external systems, for
>> example when user updates her profile. I was thinking of publishing
>> messages to a JMS topic by implementing an event listener.
>>
>> What do you think, would you be interested in such a pull request? I
>> think the topic should be preconfigured in Keycloak/Wildfly, but the admin
>> would enable the functionality by adding "jms" to event listeners in the
>> admin console.
>>
>> Best regards,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/32517ec0/attachment-0001.html 

From juraci at kroehling.de  Wed Jan 13 08:25:04 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 13 Jan 2016 14:25:04 +0100
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
Message-ID: <56965030.5020208@kroehling.de>

I have something like this implemented already. It listens to KC events 
and publishes those to a REST endpoint (if the target server is remote), 
or to a JMS topic.

JMS - https://git.io/vzZBf
REST - https://git.io/vzZBe

- Juca.


On 13.01.2016 14:13, Thomas Raehalme wrote:
> Hi,
>
> Thanks for the feedback! I hope to send a PR in the next few days or so.
>
> https://issues.jboss.org/browse/KEYCLOAK-2302
>
> Best regards,
> Thomas
>
>
> On Tue, Jan 12, 2016 at 8:34 PM, Thomas Darimont
> <thomas.darimont at googlemail.com <mailto:thomas.darimont at googlemail.com>>
> wrote:
>
>     Hi Thomas,
>
>     would be great to have that!
>
>     Cheers,
>     Thomas
>
>     2016-01-12 18:37 GMT+01:00 Thomas Raehalme
>     <thomas.raehalme at aitiofinland.com
>     <mailto:thomas.raehalme at aitiofinland.com>>:
>
>         Hi!
>
>         We have a need to publish Keycloak events to external systems,
>         for example when user updates her profile. I was thinking of
>         publishing messages to a JMS topic by implementing an event
>         listener.
>
>         What do you think, would you be interested in such a pull
>         request? I think the topic should be preconfigured in
>         Keycloak/Wildfly, but the admin would enable the functionality
>         by adding "jms" to event listeners in the admin console.
>
>         Best regards,
>         Thomas
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From thomas.raehalme at aitiofinland.com  Wed Jan 13 08:31:39 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Jan 2016 15:31:39 +0200
Subject: [keycloak-dev] Publishing events to JMS topic
In-Reply-To: <56965030.5020208@kroehling.de>
References: <CAPyAMoaotiTVCTpx4UxKWOyAYXCrqes1nYRth2L9oyr07nLX5g@mail.gmail.com>
	<CAK-7U1h0DS1NiosNVOA8s8Aabfc_d0w2Ot0mhU+apVEf_cYu2w@mail.gmail.com>
	<CAPyAMoafvAXbGD5k8DryLE=fHh3pshKrfMSgB_s_e_BdS3sL0w@mail.gmail.com>
	<56965030.5020208@kroehling.de>
Message-ID: <CAPyAMoZN4+QRYrk672EZcqqoK830Hkg7d0cXAE5c=USfbtS3Cw@mail.gmail.com>

On Wed, Jan 13, 2016 at 3:25 PM, Juraci Paix?o Kr?hling <juraci at kroehling.de
> wrote:

> I have something like this implemented already. It listens to KC events
> and publishes those to a REST endpoint (if the target server is remote),
> or to a JMS topic.
>

That's great, thanks for the info! I also have the JMS implementation
ready, but the necessary Wildfly configuration still needs to be thought
through...

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/019347b5/attachment.html 

From sthorger at redhat.com  Wed Jan 13 09:06:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 15:06:34 +0100
Subject: [keycloak-dev] Upgrading to Jackson2
Message-ID: <CAJgngAewEJwk81xgmNN062drEczNFns=TP=7pbT+x0dO7hpPEQ@mail.gmail.com>

Now that we no longer need to support EAP 6.4 on the server side we can
upgrade to Jackson2, which is supposed to be significantly faster than
Jackson.

Question - Can we require Jackson2 for adapters as well? Or should we make
JSON serialization support on the adapter side pluggable somehow? Or should
we support both Jackson and Jackson2 on the adapter side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/f62ff29a/attachment.html 

From sthorger at redhat.com  Wed Jan 13 09:08:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 15:08:56 +0100
Subject: [keycloak-dev] EAP 6.4 support for server removed from master
Message-ID: <CAJgngAdKrTcO=OPq8FY6gaSSTHMD=rEuH7piJg0J_1EpqfRFAA@mail.gmail.com>

I've removed support to deploy server on EAP 6.4 from master. The
server-overlay can be deployed to either WildFly 10 or EAP 7.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/eba9b10a/attachment.html 

From bburke at redhat.com  Wed Jan 13 09:41:50 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 09:41:50 -0500
Subject: [keycloak-dev] UserFederationProvider with non-trivial
 configuration
In-Reply-To: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
Message-ID: <5696622E.9050600@redhat.com>

Right now, you're going to have to modify app.js, I can refactor app.js 
so you don't have to modify it, but, you'll have to wait until next 
release to get these changes.

Unfortunately, the UserFederationProvider only supports name/value pairs 
for configuration and a max size for Value of 255 characters. I can 
expand the SPI to allow you to plug ina  backend REST service that would 
allow you to parse the file and add the appropriate config, but at this 
time, we can't really provide a brand new config model for 
UserFederation as this is supposed to be feature freeze right now.

On 1/12/2016 5:56 PM, Josh Cain wrote:
> Hi all,
>
> I've got a UserFederationProvider that needs 6-8 configuration 
> elements, to include enumerated types and even a couple of files.  I'd 
> like to keep the configuration of this provider in the Keycloak admin 
> console, but am not sure how to do so.
>
> I've read through the themes documentation 
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>, 
> but I have not been able to find a suitable solution.  I thought of 
> just dropping a new partial in there to handle more straightforward 
> configuration items like enumerated types, but couldn't find a way to 
> do so without having to override the entire app.js.  What's more, I 
> was not certain if Keycloak was already set up to handle something 
> like a File object in the REST/DB backend.
>
> I suppose my question boils down to "How can I integrate enumerated 
> and file type configuration options for my UserFederationProvider into 
> the Keycloak administration system?"  Any help would be much 
> appreciated - thanks!
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Wed Jan 13 09:55:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 09:55:08 -0500
Subject: [keycloak-dev] Upgrading to Jackson2
In-Reply-To: <CAJgngAewEJwk81xgmNN062drEczNFns=TP=7pbT+x0dO7hpPEQ@mail.gmail.com>
References: <CAJgngAewEJwk81xgmNN062drEczNFns=TP=7pbT+x0dO7hpPEQ@mail.gmail.com>
Message-ID: <5696654C.9040106@redhat.com>

Can't make it pluggable as it relies on annotations.

On 1/13/2016 9:06 AM, Stian Thorgersen wrote:
> Now that we no longer need to support EAP 6.4 on the server side we 
> can upgrade to Jackson2, which is supposed to be significantly faster 
> than Jackson.
>
> Question - Can we require Jackson2 for adapters as well? Or should we 
> make JSON serialization support on the adapter side pluggable somehow? 
> Or should we support both Jackson and Jackson2 on the adapter side.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Wed Jan 13 10:00:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 16:00:27 +0100
Subject: [keycloak-dev] Upgrading to Jackson2
In-Reply-To: <5696654C.9040106@redhat.com>
References: <CAJgngAewEJwk81xgmNN062drEczNFns=TP=7pbT+x0dO7hpPEQ@mail.gmail.com>
	<5696654C.9040106@redhat.com>
Message-ID: <CAJgngAciJPZ1v1RsqKhts96dexdr3wgLssZVu0jPNE1DpeGcog@mail.gmail.com>

Simplest would just be to do Jackson2 only. Would mean we'd need to have a
Jackson2 module for EAP6 subsystem. For other adapters it's just a
dependency so shouldn't matter.

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

> Can't make it pluggable as it relies on annotations.
>
> On 1/13/2016 9:06 AM, Stian Thorgersen wrote:
>
> Now that we no longer need to support EAP 6.4 on the server side we can
> upgrade to Jackson2, which is supposed to be significantly faster than
> Jackson.
>
> Question - Can we require Jackson2 for adapters as well? Or should we make
> JSON serialization support on the adapter side pluggable somehow? Or should
> we support both Jackson and Jackson2 on the adapter side.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/072a7892/attachment-0001.html 

From josh.cain at redhat.com  Wed Jan 13 10:18:41 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Wed, 13 Jan 2016 09:18:41 -0600
Subject: [keycloak-dev] UserFederationProvider with non-trivial
	configuration
In-Reply-To: <5696622E.9050600@redhat.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
	<5696622E.9050600@redhat.com>
Message-ID: <CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>

Bill,

Thanks for the quick response.

I do think it would be very useful for us if the federation provider
configuration were more verbose.  I saw where some work was done recently
on this (PR-1973 <https://github.com/keycloak/keycloak/pull/1973>) to allow
for better customization on labels and help texts and such.  Extending the
REST endpoints for configuration could potentially be useful as well.

We're using certificate files for a portion of our configuration, so we'd
actually need to store the file objects in the DB, as opposed to just
parsing configuration files.

Totally understand about feature freeze.  Let me know what I can do to
help, I'm still getting my feet wet with Keycloak, but don't mind jumping
in when necessary.


Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke <bburke at redhat.com> wrote:

> Right now, you're going to have to modify app.js, I can refactor app.js so
> you don't have to modify it, but, you'll have to wait until next release to
> get these changes.
>
> Unfortunately, the UserFederationProvider only supports name/value pairs
> for configuration and a max size for Value of 255 characters.  I can expand
> the SPI to allow you to plug ina  backend REST service that would allow you
> to parse the file and add the appropriate config, but at this time, we
> can't really provide a brand new config model for UserFederation as this is
> supposed to be feature freeze right now.
>
>
> On 1/12/2016 5:56 PM, Josh Cain wrote:
>
> Hi all,
>
> I've got a UserFederationProvider that needs 6-8 configuration elements,
> to include enumerated types and even a couple of files.  I'd like to keep
> the configuration of this provider in the Keycloak admin console, but am
> not sure how to do so.
>
> I've read through the themes documentation
> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
> but I have not been able to find a suitable solution.  I thought of just
> dropping a new partial in there to handle more straightforward
> configuration items like enumerated types, but couldn't find a way to do so
> without having to override the entire app.js.  What's more, I was not
> certain if Keycloak was already set up to handle something like a File
> object in the REST/DB backend.
>
> I suppose my question boils down to "How can I integrate enumerated and
> file type configuration options for my UserFederationProvider into the
> Keycloak administration system?"  Any help would be much appreciated -
> thanks!
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/2a20bb20/attachment.html 

From bburke at redhat.com  Wed Jan 13 10:28:03 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 10:28:03 -0500
Subject: [keycloak-dev] UserFederationProvider with non-trivial
 configuration
In-Reply-To: <CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
	<5696622E.9050600@redhat.com>
	<CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>
Message-ID: <56966D03.5030506@redhat.com>

I totally forgot about that PR.  Are those PR changes good enough for 
you?  Can you live with just that new interface?  I can change and 
increase the value for user federation config to 2048 to support things 
like certificate pem files.

On 1/13/2016 10:18 AM, Josh Cain wrote:
> Bill,
>
> Thanks for the quick response.
>
> I do think it would be very useful for us if the federation provider 
> configuration were more verbose.  I saw where some work was done 
> recently on this (PR-1973 
> <https://github.com/keycloak/keycloak/pull/1973>) to allow for better 
> customization on labels and help texts and such.  Extending the REST 
> endpoints for configuration could potentially be useful as well.
>
> We're using certificate files for a portion of our configuration, so 
> we'd actually need to store the file objects in the DB, as opposed to 
> just parsing configuration files.
>
> Totally understand about feature freeze.  Let me know what I can do to 
> help, I'm still getting my feet wet with Keycloak, but don't mind 
> jumping in when necessary.
>
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
> On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Right now, you're going to have to modify app.js, I can refactor
>     app.js so you don't have to modify it, but, you'll have to wait
>     until next release to get these changes.
>
>     Unfortunately, the UserFederationProvider only supports name/value
>     pairs for configuration and a max size for Value of 255
>     characters.  I can expand the SPI to allow you to plug ina 
>     backend REST service that would allow you to parse the file and
>     add the appropriate config, but at this time, we can't really
>     provide a brand new config model for UserFederation as this is
>     supposed to be feature freeze right now.
>
>
>     On 1/12/2016 5:56 PM, Josh Cain wrote:
>>     Hi all,
>>
>>     I've got a UserFederationProvider that needs 6-8 configuration
>>     elements, to include enumerated types and even a couple of
>>     files.  I'd like to keep the configuration of this provider in
>>     the Keycloak admin console, but am not sure how to do so.
>>
>>     I've read through the themes documentation
>>     <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
>>     but I have not been able to find a suitable solution.  I thought
>>     of just dropping a new partial in there to handle more
>>     straightforward configuration items like enumerated types, but
>>     couldn't find a way to do so without having to override the
>>     entire app.js.  What's more, I was not certain if Keycloak was
>>     already set up to handle something like a File object in the
>>     REST/DB backend.
>>
>>     I suppose my question boils down to "How can I integrate
>>     enumerated and file type configuration options for my
>>     UserFederationProvider into the Keycloak administration system?" 
>>     Any help would be much appreciated - thanks!
>>
>>     Josh Cain | Software Applications Engineer
>>     /Identity and Access Management/
>>     *Red Hat*
>>     +1 843-737-1735 <tel:%2B1%20843-737-1735>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

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

From josh.cain at redhat.com  Wed Jan 13 10:41:52 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Wed, 13 Jan 2016 09:41:52 -0600
Subject: [keycloak-dev] UserFederationProvider with non-trivial
	configuration
In-Reply-To: <56966D03.5030506@redhat.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
	<5696622E.9050600@redhat.com>
	<CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>
	<56966D03.5030506@redhat.com>
Message-ID: <CA+z0A8C8ztP1yifjaVC2BQTzda9cPxSk3baeUA08UX_Db_DXNA@mail.gmail.com>

That PR will be enough for me to get by for now.  We've been using .pkcs12
files and including chains at times, so not positive that 2048 is going to
be big enough.  For now, I think that we'll just plan on dropping
associated cert files with the SPI libraries.  Shouldn't be too bad to do
that, and maybe in the future we can look at extending that SPI to
accommodate files?

The only other note I would have is that enumerated types aren't supported
(I.E. as a dropdown with selectable values).  I see where that won't be too
difficult; I'll get together a PR for selectable options.  Do you want me
to file a FR for supporting file types for provider configuration?

In the end it would be really nice to have a fully extensible configuration
mechanism (in the same ways that LDAP or kerberos are configured).  For
instance, LDAP configurations allow you to run validation to make sure your
authentication works.  I would (ideally) like to leverage a similar
function for my federation provider.  Not saying it's an essential, but
would certainly add some polish to the federation provider SPI.


Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Wed, Jan 13, 2016 at 9:28 AM, Bill Burke <bburke at redhat.com> wrote:

> I totally forgot about that PR.  Are those PR changes good enough for
> you?  Can you live with just that new interface?  I can change and increase
> the value for user federation config to 2048 to support things like
> certificate pem files.
>
> On 1/13/2016 10:18 AM, Josh Cain wrote:
>
> Bill,
>
> Thanks for the quick response.
>
> I do think it would be very useful for us if the federation provider
> configuration were more verbose.  I saw where some work was done recently
> on this (PR-1973 <https://github.com/keycloak/keycloak/pull/1973>) to
> allow for better customization on labels and help texts and such.
> Extending the REST endpoints for configuration could potentially be useful
> as well.
>
> We're using certificate files for a portion of our configuration, so we'd
> actually need to store the file objects in the DB, as opposed to just
> parsing configuration files.
>
> Totally understand about feature freeze.  Let me know what I can do to
> help, I'm still getting my feet wet with Keycloak, but don't mind jumping
> in when necessary.
>
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735
>
> On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> Right now, you're going to have to modify app.js, I can refactor app.js
>> so you don't have to modify it, but, you'll have to wait until next release
>> to get these changes.
>>
>> Unfortunately, the UserFederationProvider only supports name/value pairs
>> for configuration and a max size for Value of 255 characters.  I can expand
>> the SPI to allow you to plug ina  backend REST service that would allow you
>> to parse the file and add the appropriate config, but at this time, we
>> can't really provide a brand new config model for UserFederation as this is
>> supposed to be feature freeze right now.
>>
>>
>> On 1/12/2016 5:56 PM, Josh Cain wrote:
>>
>> Hi all,
>>
>> I've got a UserFederationProvider that needs 6-8 configuration elements,
>> to include enumerated types and even a couple of files.  I'd like to keep
>> the configuration of this provider in the Keycloak admin console, but am
>> not sure how to do so.
>>
>> I've read through the themes documentation
>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
>> but I have not been able to find a suitable solution.  I thought of just
>> dropping a new partial in there to handle more straightforward
>> configuration items like enumerated types, but couldn't find a way to do so
>> without having to override the entire app.js.  What's more, I was not
>> certain if Keycloak was already set up to handle something like a File
>> object in the REST/DB backend.
>>
>> I suppose my question boils down to "How can I integrate enumerated and
>> file type configuration options for my UserFederationProvider into the
>> Keycloak administration system?"  Any help would be much appreciated -
>> thanks!
>>
>> Josh Cain | Software Applications Engineer
>> *Identity and Access Management*
>> *Red Hat*
>> +1 843-737-1735 <%2B1%20843-737-1735>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/c56a55da/attachment-0001.html 

From srossillo at smartling.com  Wed Jan 13 10:44:21 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Wed, 13 Jan 2016 10:44:21 -0500
Subject: [keycloak-dev] Upgrading to Jackson2
In-Reply-To: <CAJgngAciJPZ1v1RsqKhts96dexdr3wgLssZVu0jPNE1DpeGcog@mail.gmail.com>
References: <CAJgngAewEJwk81xgmNN062drEczNFns=TP=7pbT+x0dO7hpPEQ@mail.gmail.com>
	<5696654C.9040106@redhat.com>
	<CAJgngAciJPZ1v1RsqKhts96dexdr3wgLssZVu0jPNE1DpeGcog@mail.gmail.com>
Message-ID: <B392525C-A907-4FE1-984E-26969BAF13BE@smartling.com>

+1 for just supporting Jackson 2 in adapters.

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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Jan 13, 2016, at 10:00 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Simplest would just be to do Jackson2 only. Would mean we'd need to have a Jackson2 module for EAP6 subsystem. For other adapters it's just a dependency so shouldn't matter.
> 
> On 13 January 2016 at 15:55, Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
> Can't make it pluggable as it relies on annotations.
> 
> On 1/13/2016 9:06 AM, Stian Thorgersen wrote:
>> Now that we no longer need to support EAP 6.4 on the server side we can upgrade to Jackson2, which is supposed to be significantly faster than Jackson.
>> 
>> Question - Can we require Jackson2 for adapters as well? Or should we make JSON serialization support on the adapter side pluggable somehow? Or should we support both Jackson and Jackson2 on the adapter side.
>> 
>> 
>> _______________________________________________
>> 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>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com <http://bill.burkecentral.com/>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Wed Jan 13 10:45:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 10:45:49 -0500
Subject: [keycloak-dev] UserFederationProvider with non-trivial
 configuration
In-Reply-To: <CA+z0A8C8ztP1yifjaVC2BQTzda9cPxSk3baeUA08UX_Db_DXNA@mail.gmail.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
	<5696622E.9050600@redhat.com>
	<CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>
	<56966D03.5030506@redhat.com>
	<CA+z0A8C8ztP1yifjaVC2BQTzda9cPxSk3baeUA08UX_Db_DXNA@mail.gmail.com>
Message-ID: <5696712D.1000109@redhat.com>

PRs are welcome.  Not sure what you mean by enumerated types.  I believe 
there is a LIST object ou can specify values of?

On 1/13/2016 10:41 AM, Josh Cain wrote:
> That PR will be enough for me to get by for now.  We've been using 
> .pkcs12 files and including chains at times, so not positive that 2048 
> is going to be big enough.  For now, I think that we'll just plan on 
> dropping associated cert files with the SPI libraries.  Shouldn't be 
> too bad to do that, and maybe in the future we can look at extending 
> that SPI to accommodate files?
>
> The only other note I would have is that enumerated types aren't 
> supported (I.E. as a dropdown with selectable values). I see where 
> that won't be too difficult; I'll get together a PR for selectable 
> options.  Do you want me to file a FR for supporting file types for 
> provider configuration?
>
> In the end it would be really nice to have a fully extensible 
> configuration mechanism (in the same ways that LDAP or kerberos are 
> configured).  For instance, LDAP configurations allow you to run 
> validation to make sure your authentication works.  I would (ideally) 
> like to leverage a similar function for my federation provider.  Not 
> saying it's an essential, but would certainly add some polish to the 
> federation provider SPI.
>
>
> Josh Cain | Software Applications Engineer
> /Identity and Access Management/
> *Red Hat*
> +1 843-737-1735
>
> On Wed, Jan 13, 2016 at 9:28 AM, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I totally forgot about that PR.  Are those PR changes good enough
>     for you? Can you live with just that new interface?  I can change
>     and increase the value for user federation config to 2048 to
>     support things like certificate pem files.
>
>     On 1/13/2016 10:18 AM, Josh Cain wrote:
>>     Bill,
>>
>>     Thanks for the quick response.
>>
>>     I do think it would be very useful for us if the federation
>>     provider configuration were more verbose.  I saw where some work
>>     was done recently on this (PR-1973
>>     <https://github.com/keycloak/keycloak/pull/1973>) to allow for
>>     better customization on labels and help texts and such. 
>>     Extending the REST endpoints for configuration could potentially
>>     be useful as well.
>>
>>     We're using certificate files for a portion of our configuration,
>>     so we'd actually need to store the file objects in the DB, as
>>     opposed to just parsing configuration files.
>>
>>     Totally understand about feature freeze.  Let me know what I can
>>     do to help, I'm still getting my feet wet with Keycloak, but
>>     don't mind jumping in when necessary.
>>
>>
>>     Josh Cain | Software Applications Engineer
>>     /Identity and Access Management/
>>     *Red Hat*
>>     +1 843-737-1735 <tel:%2B1%20843-737-1735>
>>
>>     On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         Right now, you're going to have to modify app.js, I can
>>         refactor app.js so you don't have to modify it, but, you'll
>>         have to wait until next release to get these changes.
>>
>>         Unfortunately, the UserFederationProvider only supports
>>         name/value pairs for configuration and a max size for Value
>>         of 255 characters.  I can expand the SPI to allow you to plug
>>         ina  backend REST service that would allow you to parse the
>>         file and add the appropriate config, but at this time, we
>>         can't really provide a brand new config model for
>>         UserFederation as this is supposed to be feature freeze right
>>         now.
>>
>>
>>         On 1/12/2016 5:56 PM, Josh Cain wrote:
>>>         Hi all,
>>>
>>>         I've got a UserFederationProvider that needs 6-8
>>>         configuration elements, to include enumerated types and even
>>>         a couple of files.  I'd like to keep the configuration of
>>>         this provider in the Keycloak admin console, but am not sure
>>>         how to do so.
>>>
>>>         I've read through the themes documentation
>>>         <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
>>>         but I have not been able to find a suitable solution.  I
>>>         thought of just dropping a new partial in there to handle
>>>         more straightforward configuration items like enumerated
>>>         types, but couldn't find a way to do so without having to
>>>         override the entire app.js.  What's more, I was not certain
>>>         if Keycloak was already set up to handle something like a
>>>         File object in the REST/DB backend.
>>>
>>>         I suppose my question boils down to "How can I integrate
>>>         enumerated and file type configuration options for my
>>>         UserFederationProvider into the Keycloak administration
>>>         system?" Any help would be much appreciated - thanks!
>>>
>>>         Josh Cain | Software Applications Engineer
>>>         /Identity and Access Management/
>>>         *Red Hat*
>>>         +1 843-737-1735 <tel:%2B1%20843-737-1735>
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>         -- 
>>         Bill Burke
>>         JBoss, a division of Red Hat
>>         http://bill.burkecentral.com
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From josh.cain at redhat.com  Wed Jan 13 11:49:30 2016
From: josh.cain at redhat.com (Josh Cain)
Date: Wed, 13 Jan 2016 10:49:30 -0600
Subject: [keycloak-dev] UserFederationProvider with non-trivial
	configuration
In-Reply-To: <5696712D.1000109@redhat.com>
References: <CA+z0A8AqcdtXPsQok3tMbOqgfZBp6tHBTmDH+OPvVgjCpHFCrA@mail.gmail.com>
	<5696622E.9050600@redhat.com>
	<CA+z0A8C=bzT7ugihXBiH7u=c8v1CdKzBtU1Ep_N1zawuAOSVnw@mail.gmail.com>
	<56966D03.5030506@redhat.com>
	<CA+z0A8C8ztP1yifjaVC2BQTzda9cPxSk3baeUA08UX_Db_DXNA@mail.gmail.com>
	<5696712D.1000109@redhat.com>
Message-ID: <CA+z0A8CnFd58yOUNwDk5E9Ft-GDVUHzM2Li7r6seKNMrwkEheA@mail.gmail.com>

you're right, I missed that type.  Looks like we're good then, thanks!

Josh Cain | Software Applications Engineer
*Identity and Access Management*
*Red Hat*
+1 843-737-1735

On Wed, Jan 13, 2016 at 9:45 AM, Bill Burke <bburke at redhat.com> wrote:

> PRs are welcome.  Not sure what you mean by enumerated types.  I believe
> there is a LIST object ou can specify values of?
>
>
> On 1/13/2016 10:41 AM, Josh Cain wrote:
>
> That PR will be enough for me to get by for now.  We've been using .pkcs12
> files and including chains at times, so not positive that 2048 is going to
> be big enough.  For now, I think that we'll just plan on dropping
> associated cert files with the SPI libraries.  Shouldn't be too bad to do
> that, and maybe in the future we can look at extending that SPI to
> accommodate files?
>
> The only other note I would have is that enumerated types aren't supported
> (I.E. as a dropdown with selectable values).  I see where that won't be too
> difficult; I'll get together a PR for selectable options.  Do you want me
> to file a FR for supporting file types for provider configuration?
>
> In the end it would be really nice to have a fully extensible
> configuration mechanism (in the same ways that LDAP or kerberos are
> configured).  For instance, LDAP configurations allow you to run validation
> to make sure your authentication works.  I would (ideally) like to leverage
> a similar function for my federation provider.  Not saying it's an
> essential, but would certainly add some polish to the federation provider
> SPI.
>
>
> Josh Cain | Software Applications Engineer
> *Identity and Access Management*
> *Red Hat*
> +1 843-737-1735
>
> On Wed, Jan 13, 2016 at 9:28 AM, Bill Burke <bburke at redhat.com> wrote:
>
>> I totally forgot about that PR.  Are those PR changes good enough for
>> you?  Can you live with just that new interface?  I can change and increase
>> the value for user federation config to 2048 to support things like
>> certificate pem files.
>>
>> On 1/13/2016 10:18 AM, Josh Cain wrote:
>>
>> Bill,
>>
>> Thanks for the quick response.
>>
>> I do think it would be very useful for us if the federation provider
>> configuration were more verbose.  I saw where some work was done recently
>> on this (PR-1973 <https://github.com/keycloak/keycloak/pull/1973>) to
>> allow for better customization on labels and help texts and such.
>> Extending the REST endpoints for configuration could potentially be useful
>> as well.
>>
>> We're using certificate files for a portion of our configuration, so we'd
>> actually need to store the file objects in the DB, as opposed to just
>> parsing configuration files.
>>
>> Totally understand about feature freeze.  Let me know what I can do to
>> help, I'm still getting my feet wet with Keycloak, but don't mind jumping
>> in when necessary.
>>
>>
>> Josh Cain | Software Applications Engineer
>> *Identity and Access Management*
>> *Red Hat*
>> +1 843-737-1735 <%2B1%20843-737-1735>
>>
>> On Wed, Jan 13, 2016 at 8:41 AM, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>> Right now, you're going to have to modify app.js, I can refactor app.js
>>> so you don't have to modify it, but, you'll have to wait until next release
>>> to get these changes.
>>>
>>> Unfortunately, the UserFederationProvider only supports name/value pairs
>>> for configuration and a max size for Value of 255 characters.  I can expand
>>> the SPI to allow you to plug ina  backend REST service that would allow you
>>> to parse the file and add the appropriate config, but at this time, we
>>> can't really provide a brand new config model for UserFederation as this is
>>> supposed to be feature freeze right now.
>>>
>>>
>>> On 1/12/2016 5:56 PM, Josh Cain wrote:
>>>
>>> Hi all,
>>>
>>> I've got a UserFederationProvider that needs 6-8 configuration elements,
>>> to include enumerated types and even a couple of files.  I'd like to keep
>>> the configuration of this provider in the Keycloak admin console, but am
>>> not sure how to do so.
>>>
>>> I've read through the themes documentation
>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/themes.html>,
>>> but I have not been able to find a suitable solution.  I thought of just
>>> dropping a new partial in there to handle more straightforward
>>> configuration items like enumerated types, but couldn't find a way to do so
>>> without having to override the entire app.js.  What's more, I was not
>>> certain if Keycloak was already set up to handle something like a File
>>> object in the REST/DB backend.
>>>
>>> I suppose my question boils down to "How can I integrate enumerated and
>>> file type configuration options for my UserFederationProvider into the
>>> Keycloak administration system?"  Any help would be much appreciated -
>>> thanks!
>>>
>>> Josh Cain | Software Applications Engineer
>>> *Identity and Access Management*
>>> *Red Hat*
>>> +1 843-737-1735 <%2B1%20843-737-1735>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/04fb4859/attachment.html 

From sthorger at redhat.com  Wed Jan 13 13:14:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 19:14:41 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
Message-ID: <CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>

How about:

keycloak-common
keycloak-common-saml
keycloak-common-oidc

keycloak-server-spi
keycloak-server-jpa
keycloak-server-mongo
keycloak-server-infinispan
keycloak-server-freemarker
keycloak-server-ldap
keycloak-server-themes
keycloak-server-wildfly
keycloak-server-services

All providers that are don't fall into one of the above categories (for
example timer, protocol mappers, etc..) can just go into
keycloak-server-services.


On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 12 January 2016 at 19:32, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 12 January 2016 at 16:26, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 12 January 2016 at 03:22, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> I can't find the original email on this, but we need to do this for
>>>> 1.9.  I can start doing it one module at a time:
>>>
>>>
>>>> Common:
>>>> keycloak-common
>>>> keycloak-common-saml
>>>> keycloak-common-oidc
>>>>
>>>> Libraries server:
>>>>
>>>> keycloak-server-spi - all SPI interfaces and common code
>>>> keycloak-server-saml - all saml server code, broker and protocol plugins
>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>> keycloak-server-impl - everything
>>>>
>>>
>>> I'm not 100% sure we should put all implementations of SPIs into
>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>> part of the product.
>>>
>>> If we put all SPI implementations, including services, into the same
>>> module we'd end up with one huge module. There's also a risk that we'd end
>>> up with strong relationships between them, rather than having them properly
>>> linked via SPI interfaces.
>>>
>>> I'm a bit 50/50 on it though.
>>>
>>> You do remember how many modules we currently have don't you?
>>> Minimally, we should have a big SPI module right?
>>>
>>
>> I'm absolutely on board with:
>>
>> Common:
>> keycloak-common
>> keycloak-common-saml
>> keycloak-common-oidc
>>
>> Libraries server:
>> keycloak-server-spi
>>
>> So we can agree on that, I'm just not 100% sure about a single module for
>> all SPI implementations and services.
>>
>
> We can go with a single module if you want. Only thing that needs to be
> separate is Mongo at least for now as it's not going to be supported and we
> need to be able to remove it easily.
>
>
>>
>>
>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/54b23058/attachment-0001.html 

From bburke at redhat.com  Wed Jan 13 13:17:13 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 13:17:13 -0500
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
Message-ID: <569694A9.80008@redhat.com>

Why do you want freemarker separate?

On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
> How about:
>
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> keycloak-server-spi
> keycloak-server-jpa
> keycloak-server-mongo
> keycloak-server-infinispan
> keycloak-server-freemarker
> keycloak-server-ldap
> keycloak-server-themes
> keycloak-server-wildfly
> keycloak-server-services
>
> All providers that are don't fall into one of the above categories 
> (for example timer, protocol mappers, etc..) can just go into 
> keycloak-server-services.
>
>
> On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>
>
>     On 12 January 2016 at 19:32, Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>
>
>
>         On 12 January 2016 at 16:26, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>
>
>             On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>
>>
>>             On 12 January 2016 at 03:22, Bill Burke
>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>
>>                 I can't find the original email on this, but we need
>>                 to do this for
>>                 1.9.  I can start doing it one module at a time: 
>>
>>
>>                 Common:
>>                 keycloak-common
>>                 keycloak-common-saml
>>                 keycloak-common-oidc
>>
>>                 Libraries server:
>>
>>                 keycloak-server-spi - all SPI interfaces and common code
>>                 keycloak-server-saml - all saml server code, broker
>>                 and protocol plugins
>>                 keycloak-server-oidc - all oidc code, broker and
>>                 protocol plugins
>>                 keycloak-server-impl - everything
>>
>>
>>             I'm not 100% sure we should put all implementations of
>>             SPIs into keycloak-server-impl. We at least need to keep
>>             Mongo separate as it's not part of the product.
>>
>>             If we put all SPI implementations, including services,
>>             into the same module we'd end up with one huge module.
>>             There's also a risk that we'd end up with strong
>>             relationships between them, rather than having them
>>             properly linked via SPI interfaces.
>>
>>             I'm a bit 50/50 on it though.
>             You do remember how many modules we currently have don't
>             you?  Minimally, we should have a big SPI module right?
>
>
>         I'm absolutely on board with:
>
>         Common:
>         keycloak-common
>         keycloak-common-saml
>         keycloak-common-oidc
>
>         Libraries server:
>         keycloak-server-spi
>
>         So we can agree on that, I'm just not 100% sure about a single
>         module for all SPI implementations and services.
>
>
>     We can go with a single module if you want. Only thing that needs
>     to be separate is Mongo at least for now as it's not going to be
>     supported and we need to be able to remove it easily.
>
>
>
>
>             -- 
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>
>
>

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

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

From sthorger at redhat.com  Wed Jan 13 13:19:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 19:19:32 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <569694A9.80008@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
Message-ID: <CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>

It seems like a logically grouping. Is there a reason you don't want it
separate?

On 13 January 2016 at 19:17, Bill Burke <bburke at redhat.com> wrote:

> Why do you want freemarker separate?
>
>
> On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>
> How about:
>
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> keycloak-server-spi
> keycloak-server-jpa
> keycloak-server-mongo
> keycloak-server-infinispan
> keycloak-server-freemarker
> keycloak-server-ldap
> keycloak-server-themes
> keycloak-server-wildfly
> keycloak-server-services
>
> All providers that are don't fall into one of the above categories (for
> example timer, protocol mappers, etc..) can just go into
> keycloak-server-services.
>
>
> On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> I can't find the original email on this, but we need to do this for
>>>>> 1.9.  I can start doing it one module at a time:
>>>>
>>>>
>>>>> Common:
>>>>> keycloak-common
>>>>> keycloak-common-saml
>>>>> keycloak-common-oidc
>>>>>
>>>>> Libraries server:
>>>>>
>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>> plugins
>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>> keycloak-server-impl - everything
>>>>>
>>>>
>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>> part of the product.
>>>>
>>>> If we put all SPI implementations, including services, into the same
>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>> up with strong relationships between them, rather than having them properly
>>>> linked via SPI interfaces.
>>>>
>>>> I'm a bit 50/50 on it though.
>>>>
>>>> You do remember how many modules we currently have don't you?
>>>> Minimally, we should have a big SPI module right?
>>>>
>>>
>>> I'm absolutely on board with:
>>>
>>> Common:
>>> keycloak-common
>>> keycloak-common-saml
>>> keycloak-common-oidc
>>>
>>> Libraries server:
>>> keycloak-server-spi
>>>
>>> So we can agree on that, I'm just not 100% sure about a single module
>>> for all SPI implementations and services.
>>>
>>
>> We can go with a single module if you want. Only thing that needs to be
>> separate is Mongo at least for now as it's not going to be supported and we
>> need to be able to remove it easily.
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/f0963955/attachment-0001.html 

From bburke at redhat.com  Wed Jan 13 14:00:19 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 14:00:19 -0500
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
Message-ID: <56969EC3.6020206@redhat.com>

Because it isn't something that would ever be removed like JPA or mongo?

Themes would just be .js and .html and .css right?

On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
> It seems like a logically grouping. Is there a reason you don't want 
> it separate?
>
> On 13 January 2016 at 19:17, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Why do you want freemarker separate?
>
>
>     On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>     How about:
>>
>>     keycloak-common
>>     keycloak-common-saml
>>     keycloak-common-oidc
>>
>>     keycloak-server-spi
>>     keycloak-server-jpa
>>     keycloak-server-mongo
>>     keycloak-server-infinispan
>>     keycloak-server-freemarker
>>     keycloak-server-ldap
>>     keycloak-server-themes
>>     keycloak-server-wildfly
>>     keycloak-server-services
>>
>>     All providers that are don't fall into one of the above
>>     categories (for example timer, protocol mappers, etc..) can just
>>     go into keycloak-server-services.
>>
>>
>>     On 12 January 2016 at 19:44, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>
>>
>>         On 12 January 2016 at 19:32, Stian Thorgersen
>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>
>>
>>             On 12 January 2016 at 16:26, Bill Burke
>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>                 On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>
>>>
>>>                 On 12 January 2016 at 03:22, Bill Burke
>>>                 <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>
>>>                     I can't find the original email on this, but we
>>>                     need to do this for
>>>                     1.9.  I can start doing it one module at a time: 
>>>
>>>
>>>                     Common:
>>>                     keycloak-common
>>>                     keycloak-common-saml
>>>                     keycloak-common-oidc
>>>
>>>                     Libraries server:
>>>
>>>                     keycloak-server-spi - all SPI interfaces and
>>>                     common code
>>>                     keycloak-server-saml - all saml server code,
>>>                     broker and protocol plugins
>>>                     keycloak-server-oidc - all oidc code, broker and
>>>                     protocol plugins
>>>                     keycloak-server-impl - everything
>>>
>>>
>>>                 I'm not 100% sure we should put all implementations
>>>                 of SPIs into keycloak-server-impl. We at least need
>>>                 to keep Mongo separate as it's not part of the product.
>>>
>>>                 If we put all SPI implementations, including
>>>                 services, into the same module we'd end up with one
>>>                 huge module. There's also a risk that we'd end up
>>>                 with strong relationships between them, rather than
>>>                 having them properly linked via SPI interfaces.
>>>
>>>                 I'm a bit 50/50 on it though.
>>                 You do remember how many modules we currently have
>>                 don't you? Minimally, we should have a big SPI module
>>                 right?
>>
>>
>>             I'm absolutely on board with:
>>
>>             Common:
>>             keycloak-common
>>             keycloak-common-saml
>>             keycloak-common-oidc
>>
>>             Libraries server:
>>             keycloak-server-spi
>>
>>             So we can agree on that, I'm just not 100% sure about a
>>             single module for all SPI implementations and services.
>>
>>
>>         We can go with a single module if you want. Only thing that
>>         needs to be separate is Mongo at least for now as it's not
>>         going to be supported and we need to be able to remove it easily.
>>
>>
>>
>>
>>                 -- 
>>                 Bill Burke
>>                 JBoss, a division of Red Hat
>>                 http://bill.burkecentral.com
>>
>>
>>
>>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From sthorger at redhat.com  Wed Jan 13 14:02:43 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 20:02:43 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <56969EC3.6020206@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
Message-ID: <CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>

On 13 January 2016 at 20:00, Bill Burke <bburke at redhat.com> wrote:

> Because it isn't something that would ever be removed like JPA or mongo?
>

Actually, in theory it could. That's why I thought it was a sensible
separation. It all relies on Freemarker so if we decided to use something
else or to support another templating mechanism as well. Or even to stop
using templates and use AngularJS+rest.


>
> Themes would just be .js and .html and .css right?
>

Yep. I think it's worth keeping them separate.


>
>
> On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>
> It seems like a logically grouping. Is there a reason you don't want it
> separate?
>
> On 13 January 2016 at 19:17, Bill Burke <bburke at redhat.com> wrote:
>
>> Why do you want freemarker separate?
>>
>>
>> On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>
>> How about:
>>
>> keycloak-common
>> keycloak-common-saml
>> keycloak-common-oidc
>>
>> keycloak-server-spi
>> keycloak-server-jpa
>> keycloak-server-mongo
>> keycloak-server-infinispan
>> keycloak-server-freemarker
>> keycloak-server-ldap
>> keycloak-server-themes
>> keycloak-server-wildfly
>> keycloak-server-services
>>
>> All providers that are don't fall into one of the above categories (for
>> example timer, protocol mappers, etc..) can just go into
>> keycloak-server-services.
>>
>>
>> On 12 January 2016 at 19:44, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>>> bburke at redhat.com> wrote:
>>>>>
>>>>>> I can't find the original email on this, but we need to do this for
>>>>>> 1.9.  I can start doing it one module at a time:
>>>>>
>>>>>
>>>>>> Common:
>>>>>> keycloak-common
>>>>>> keycloak-common-saml
>>>>>> keycloak-common-oidc
>>>>>>
>>>>>> Libraries server:
>>>>>>
>>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>>> plugins
>>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>>> keycloak-server-impl - everything
>>>>>>
>>>>>
>>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>>> part of the product.
>>>>>
>>>>> If we put all SPI implementations, including services, into the same
>>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>>> up with strong relationships between them, rather than having them properly
>>>>> linked via SPI interfaces.
>>>>>
>>>>> I'm a bit 50/50 on it though.
>>>>>
>>>>> You do remember how many modules we currently have don't you?
>>>>> Minimally, we should have a big SPI module right?
>>>>>
>>>>
>>>> I'm absolutely on board with:
>>>>
>>>> Common:
>>>> keycloak-common
>>>> keycloak-common-saml
>>>> keycloak-common-oidc
>>>>
>>>> Libraries server:
>>>> keycloak-server-spi
>>>>
>>>> So we can agree on that, I'm just not 100% sure about a single module
>>>> for all SPI implementations and services.
>>>>
>>>
>>> We can go with a single module if you want. Only thing that needs to be
>>> separate is Mongo at least for now as it's not going to be supported and we
>>> need to be able to remove it easily.
>>>
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>
>>>>>
>>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/b6f3bc65/attachment-0001.html 

From bburke at redhat.com  Wed Jan 13 14:17:46 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 14:17:46 -0500
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
	<CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
Message-ID: <5696A2DA.4060009@redhat.com>



On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>
>
> On 13 January 2016 at 20:00, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Because it isn't something that would ever be removed like JPA or
>     mongo?
>
>
> Actually, in theory it could. That's why I thought it was a sensible 
> separation. It all relies on Freemarker so if we decided to use 
> something else or to support another templating mechanism as well. Or 
> even to stop using templates and use AngularJS+rest.

No way it is removed for a LOONNGGG time.  Too many users are dependent 
on it now.  Our own codebase depends on it too.

>
>     Themes would just be .js and .html and .css right?
>
>
> Yep. I think it's worth keeping them separate.
>
>
>
>     On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>     It seems like a logically grouping. Is there a reason you don't
>>     want it separate?
>>
>>     On 13 January 2016 at 19:17, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         Why do you want freemarker separate?
>>
>>
>>         On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>>         How about:
>>>
>>>         keycloak-common
>>>         keycloak-common-saml
>>>         keycloak-common-oidc
>>>
>>>         keycloak-server-spi
>>>         keycloak-server-jpa
>>>         keycloak-server-mongo
>>>         keycloak-server-infinispan
>>>         keycloak-server-freemarker
>>>         keycloak-server-ldap
>>>         keycloak-server-themes
>>>         keycloak-server-wildfly
>>>         keycloak-server-services
>>>
>>>         All providers that are don't fall into one of the above
>>>         categories (for example timer, protocol mappers, etc..) can
>>>         just go into keycloak-server-services.
>>>
>>>
>>>         On 12 January 2016 at 19:44, Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>
>>>
>>>             On 12 January 2016 at 19:32, Stian Thorgersen
>>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>
>>>
>>>                 On 12 January 2016 at 16:26, Bill Burke
>>>                 <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>
>>>
>>>
>>>                     On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>                     On 12 January 2016 at 03:22, Bill Burke
>>>>                     <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>                     wrote:
>>>>
>>>>                         I can't find the original email on this,
>>>>                         but we need to do this for
>>>>                         1.9.  I can start doing it one module at a
>>>>                         time: 
>>>>
>>>>
>>>>                         Common:
>>>>                         keycloak-common
>>>>                         keycloak-common-saml
>>>>                         keycloak-common-oidc
>>>>
>>>>                         Libraries server:
>>>>
>>>>                         keycloak-server-spi - all SPI interfaces
>>>>                         and common code
>>>>                         keycloak-server-saml - all saml server
>>>>                         code, broker and protocol plugins
>>>>                         keycloak-server-oidc - all oidc code,
>>>>                         broker and protocol plugins
>>>>                         keycloak-server-impl - everything
>>>>
>>>>
>>>>                     I'm not 100% sure we should put all
>>>>                     implementations of SPIs into
>>>>                     keycloak-server-impl. We at least need to keep
>>>>                     Mongo separate as it's not part of the product.
>>>>
>>>>                     If we put all SPI implementations, including
>>>>                     services, into the same module we'd end up with
>>>>                     one huge module. There's also a risk that we'd
>>>>                     end up with strong relationships between them,
>>>>                     rather than having them properly linked via SPI
>>>>                     interfaces.
>>>>
>>>>                     I'm a bit 50/50 on it though.
>>>                     You do remember how many modules we currently
>>>                     have don't you? Minimally, we should have a big
>>>                     SPI module right?
>>>
>>>
>>>                 I'm absolutely on board with:
>>>
>>>                 Common:
>>>                 keycloak-common
>>>                 keycloak-common-saml
>>>                 keycloak-common-oidc
>>>
>>>                 Libraries server:
>>>                 keycloak-server-spi
>>>
>>>                 So we can agree on that, I'm just not 100% sure
>>>                 about a single module for all SPI implementations
>>>                 and services.
>>>
>>>
>>>             We can go with a single module if you want. Only thing
>>>             that needs to be separate is Mongo at least for now as
>>>             it's not going to be supported and we need to be able to
>>>             remove it easily.
>>>
>>>
>>>
>>>
>>>                     -- 
>>>                     Bill Burke
>>>                     JBoss, a division of Red Hat
>>>                     http://bill.burkecentral.com
>>>
>>>
>>>
>>>
>>
>>         -- 
>>         Bill Burke
>>         JBoss, a division of Red Hat
>>         http://bill.burkecentral.com
>>
>>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From sthorger at redhat.com  Wed Jan 13 14:37:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 20:37:30 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <5696A2DA.4060009@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
	<CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
	<5696A2DA.4060009@redhat.com>
Message-ID: <CAJgngAd6nDXxsW7uWEEJ9W0351DkfSwjfpf4ao1k2Qv2szO7Fg@mail.gmail.com>

On 13 January 2016 at 20:17, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>
>
>
> On 13 January 2016 at 20:00, Bill Burke <bburke at redhat.com> wrote:
>
>> Because it isn't something that would ever be removed like JPA or mongo?
>>
>
> Actually, in theory it could. That's why I thought it was a sensible
> separation. It all relies on Freemarker so if we decided to use something
> else or to support another templating mechanism as well. Or even to stop
> using templates and use AngularJS+rest.
>
>
>
> No way it is removed for a LOONNGGG time.  Too many users are dependent on
> it now.  Our own codebase depends on it too.
>

Sure, I'm just saying in theory. My vote goes to keep it separate.


>
>
>> Themes would just be .js and .html and .css right?
>>
>
> Yep. I think it's worth keeping them separate.
>
>
>>
>>
>> On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>
>> It seems like a logically grouping. Is there a reason you don't want it
>> separate?
>>
>> On 13 January 2016 at 19:17, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>> Why do you want freemarker separate?
>>>
>>>
>>> On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>>
>>> How about:
>>>
>>> keycloak-common
>>> keycloak-common-saml
>>> keycloak-common-oidc
>>>
>>> keycloak-server-spi
>>> keycloak-server-jpa
>>> keycloak-server-mongo
>>> keycloak-server-infinispan
>>> keycloak-server-freemarker
>>> keycloak-server-ldap
>>> keycloak-server-themes
>>> keycloak-server-wildfly
>>> keycloak-server-services
>>>
>>> All providers that are don't fall into one of the above categories (for
>>> example timer, protocol mappers, etc..) can just go into
>>> keycloak-server-services.
>>>
>>>
>>> On 12 January 2016 at 19:44, Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>>>> sthorger at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>>>> bburke at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>>>> bburke at redhat.com> wrote:
>>>>>>
>>>>>>> I can't find the original email on this, but we need to do this for
>>>>>>> 1.9.  I can start doing it one module at a time:
>>>>>>
>>>>>>
>>>>>>> Common:
>>>>>>> keycloak-common
>>>>>>> keycloak-common-saml
>>>>>>> keycloak-common-oidc
>>>>>>>
>>>>>>> Libraries server:
>>>>>>>
>>>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>>>> plugins
>>>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>>>> keycloak-server-impl - everything
>>>>>>>
>>>>>>
>>>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>>>> part of the product.
>>>>>>
>>>>>> If we put all SPI implementations, including services, into the same
>>>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>>>> up with strong relationships between them, rather than having them properly
>>>>>> linked via SPI interfaces.
>>>>>>
>>>>>> I'm a bit 50/50 on it though.
>>>>>>
>>>>>> You do remember how many modules we currently have don't you?
>>>>>> Minimally, we should have a big SPI module right?
>>>>>>
>>>>>
>>>>> I'm absolutely on board with:
>>>>>
>>>>> Common:
>>>>> keycloak-common
>>>>> keycloak-common-saml
>>>>> keycloak-common-oidc
>>>>>
>>>>> Libraries server:
>>>>> keycloak-server-spi
>>>>>
>>>>> So we can agree on that, I'm just not 100% sure about a single module
>>>>> for all SPI implementations and services.
>>>>>
>>>>
>>>> We can go with a single module if you want. Only thing that needs to be
>>>> separate is Mongo at least for now as it's not going to be supported and we
>>>> need to be able to remove it easily.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/016f2c18/attachment-0001.html 

From sthorger at redhat.com  Wed Jan 13 14:38:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 20:38:24 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAd6nDXxsW7uWEEJ9W0351DkfSwjfpf4ao1k2Qv2szO7Fg@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
	<CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
	<5696A2DA.4060009@redhat.com>
	<CAJgngAd6nDXxsW7uWEEJ9W0351DkfSwjfpf4ao1k2Qv2szO7Fg@mail.gmail.com>
Message-ID: <CAJgngAcKueQb-5vSmc+vSVdESR9O-51CfZ3gnHJxJxFzuBa9sQ@mail.gmail.com>

BTW I'm doing the switch from Jackson to Jackson2 now, so hope you haven't
started this yet. I'm touching classes everywhere :/

On 13 January 2016 at 20:37, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 13 January 2016 at 20:17, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>>
>>
>>
>> On 13 January 2016 at 20:00, Bill Burke <bburke at redhat.com> wrote:
>>
>>> Because it isn't something that would ever be removed like JPA or mongo?
>>>
>>
>> Actually, in theory it could. That's why I thought it was a sensible
>> separation. It all relies on Freemarker so if we decided to use something
>> else or to support another templating mechanism as well. Or even to stop
>> using templates and use AngularJS+rest.
>>
>>
>>
>> No way it is removed for a LOONNGGG time.  Too many users are dependent
>> on it now.  Our own codebase depends on it too.
>>
>
> Sure, I'm just saying in theory. My vote goes to keep it separate.
>
>
>>
>>
>>> Themes would just be .js and .html and .css right?
>>>
>>
>> Yep. I think it's worth keeping them separate.
>>
>>
>>>
>>>
>>> On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>>
>>> It seems like a logically grouping. Is there a reason you don't want it
>>> separate?
>>>
>>> On 13 January 2016 at 19:17, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> Why do you want freemarker separate?
>>>>
>>>>
>>>> On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>>>
>>>> How about:
>>>>
>>>> keycloak-common
>>>> keycloak-common-saml
>>>> keycloak-common-oidc
>>>>
>>>> keycloak-server-spi
>>>> keycloak-server-jpa
>>>> keycloak-server-mongo
>>>> keycloak-server-infinispan
>>>> keycloak-server-freemarker
>>>> keycloak-server-ldap
>>>> keycloak-server-themes
>>>> keycloak-server-wildfly
>>>> keycloak-server-services
>>>>
>>>> All providers that are don't fall into one of the above categories (for
>>>> example timer, protocol mappers, etc..) can just go into
>>>> keycloak-server-services.
>>>>
>>>>
>>>> On 12 January 2016 at 19:44, Stian Thorgersen < <sthorger at redhat.com>
>>>> sthorger at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>>>>> bburke at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>>>>> bburke at redhat.com> wrote:
>>>>>>>
>>>>>>>> I can't find the original email on this, but we need to do this for
>>>>>>>> 1.9.  I can start doing it one module at a time:
>>>>>>>
>>>>>>>
>>>>>>>> Common:
>>>>>>>> keycloak-common
>>>>>>>> keycloak-common-saml
>>>>>>>> keycloak-common-oidc
>>>>>>>>
>>>>>>>> Libraries server:
>>>>>>>>
>>>>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>>>>> plugins
>>>>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>>>>> keycloak-server-impl - everything
>>>>>>>>
>>>>>>>
>>>>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>>>>> part of the product.
>>>>>>>
>>>>>>> If we put all SPI implementations, including services, into the same
>>>>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>>>>> up with strong relationships between them, rather than having them properly
>>>>>>> linked via SPI interfaces.
>>>>>>>
>>>>>>> I'm a bit 50/50 on it though.
>>>>>>>
>>>>>>> You do remember how many modules we currently have don't you?
>>>>>>> Minimally, we should have a big SPI module right?
>>>>>>>
>>>>>>
>>>>>> I'm absolutely on board with:
>>>>>>
>>>>>> Common:
>>>>>> keycloak-common
>>>>>> keycloak-common-saml
>>>>>> keycloak-common-oidc
>>>>>>
>>>>>> Libraries server:
>>>>>> keycloak-server-spi
>>>>>>
>>>>>> So we can agree on that, I'm just not 100% sure about a single module
>>>>>> for all SPI implementations and services.
>>>>>>
>>>>>
>>>>> We can go with a single module if you want. Only thing that needs to
>>>>> be separate is Mongo at least for now as it's not going to be supported and
>>>>> we need to be able to remove it easily.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Bill Burke
>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/336b5c3d/attachment-0001.html 

From bburke at redhat.com  Wed Jan 13 14:44:32 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 14:44:32 -0500
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAcKueQb-5vSmc+vSVdESR9O-51CfZ3gnHJxJxFzuBa9sQ@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
	<CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
	<5696A2DA.4060009@redhat.com>
	<CAJgngAd6nDXxsW7uWEEJ9W0351DkfSwjfpf4ao1k2Qv2szO7Fg@mail.gmail.com>
	<CAJgngAcKueQb-5vSmc+vSVdESR9O-51CfZ3gnHJxJxFzuBa9sQ@mail.gmail.com>
Message-ID: <5696A920.10504@redhat.com>

I'm working on removing most of our nefarious redirects in the auth flow.

On 1/13/2016 2:38 PM, Stian Thorgersen wrote:
> BTW I'm doing the switch from Jackson to Jackson2 now, so hope you 
> haven't started this yet. I'm touching classes everywhere :/
>
> On 13 January 2016 at 20:37, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>
>
>     On 13 January 2016 at 20:17, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>
>
>         On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>>
>>
>>         On 13 January 2016 at 20:00, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>             Because it isn't something that would ever be removed
>>             like JPA or mongo?
>>
>>
>>         Actually, in theory it could. That's why I thought it was a
>>         sensible separation. It all relies on Freemarker so if we
>>         decided to use something else or to support another
>>         templating mechanism as well. Or even to stop using templates
>>         and use AngularJS+rest.
>
>         No way it is removed for a LOONNGGG time.  Too many users are
>         dependent on it now. Our own codebase depends on it too.
>
>
>     Sure, I'm just saying in theory. My vote goes to keep it separate.
>
>
>>
>>             Themes would just be .js and .html and .css right?
>>
>>
>>         Yep. I think it's worth keeping them separate.
>>
>>
>>
>>             On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>>             It seems like a logically grouping. Is there a reason
>>>             you don't want it separate?
>>>
>>>             On 13 January 2016 at 19:17, Bill Burke
>>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>
>>>                 Why do you want freemarker separate?
>>>
>>>
>>>                 On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>>>                 How about:
>>>>
>>>>                 keycloak-common
>>>>                 keycloak-common-saml
>>>>                 keycloak-common-oidc
>>>>
>>>>                 keycloak-server-spi
>>>>                 keycloak-server-jpa
>>>>                 keycloak-server-mongo
>>>>                 keycloak-server-infinispan
>>>>                 keycloak-server-freemarker
>>>>                 keycloak-server-ldap
>>>>                 keycloak-server-themes
>>>>                 keycloak-server-wildfly
>>>>                 keycloak-server-services
>>>>
>>>>                 All providers that are don't fall into one of the
>>>>                 above categories (for example timer, protocol
>>>>                 mappers, etc..) can just go into
>>>>                 keycloak-server-services.
>>>>
>>>>
>>>>                 On 12 January 2016 at 19:44, Stian Thorgersen
>>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>>                 wrote:
>>>>
>>>>
>>>>
>>>>                     On 12 January 2016 at 19:32, Stian Thorgersen
>>>>                     <sthorger at redhat.com
>>>>                     <mailto:sthorger at redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>>                         On 12 January 2016 at 16:26, Bill Burke
>>>>                         <bburke at redhat.com
>>>>                         <mailto:bburke at redhat.com>> wrote:
>>>>
>>>>
>>>>
>>>>                             On 1/12/2016 2:45 AM, Stian Thorgersen
>>>>                             wrote:
>>>>>
>>>>>
>>>>>                             On 12 January 2016 at 03:22, Bill
>>>>>                             Burke <bburke at redhat.com
>>>>>                             <mailto:bburke at redhat.com>> wrote:
>>>>>
>>>>>                                 I can't find the original email on
>>>>>                                 this, but we need to do this for
>>>>>                                 1.9.  I can start doing it one
>>>>>                                 module at a time: 
>>>>>
>>>>>
>>>>>                                 Common:
>>>>>                                 keycloak-common
>>>>>                                 keycloak-common-saml
>>>>>                                 keycloak-common-oidc
>>>>>
>>>>>                                 Libraries server:
>>>>>
>>>>>                                 keycloak-server-spi - all SPI
>>>>>                                 interfaces and common code
>>>>>                                 keycloak-server-saml - all saml
>>>>>                                 server code, broker and protocol
>>>>>                                 plugins
>>>>>                                 keycloak-server-oidc - all oidc
>>>>>                                 code, broker and protocol plugins
>>>>>                                 keycloak-server-impl - everything
>>>>>
>>>>>
>>>>>                             I'm not 100% sure we should put all
>>>>>                             implementations of SPIs into
>>>>>                             keycloak-server-impl. We at least need
>>>>>                             to keep Mongo separate as it's not
>>>>>                             part of the product.
>>>>>
>>>>>                             If we put all SPI implementations,
>>>>>                             including services, into the same
>>>>>                             module we'd end up with one huge
>>>>>                             module. There's also a risk that we'd
>>>>>                             end up with strong relationships
>>>>>                             between them, rather than having them
>>>>>                             properly linked via SPI interfaces.
>>>>>
>>>>>                             I'm a bit 50/50 on it though.
>>>>                             You do remember how many modules we
>>>>                             currently have don't you? Minimally, we
>>>>                             should have a big SPI module right?
>>>>
>>>>
>>>>                         I'm absolutely on board with:
>>>>
>>>>                         Common:
>>>>                         keycloak-common
>>>>                         keycloak-common-saml
>>>>                         keycloak-common-oidc
>>>>
>>>>                         Libraries server:
>>>>                         keycloak-server-spi
>>>>
>>>>                         So we can agree on that, I'm just not 100%
>>>>                         sure about a single module for all SPI
>>>>                         implementations and services.
>>>>
>>>>
>>>>                     We can go with a single module if you want.
>>>>                     Only thing that needs to be separate is Mongo
>>>>                     at least for now as it's not going to be
>>>>                     supported and we need to be able to remove it
>>>>                     easily.
>>>>
>>>>
>>>>
>>>>
>>>>                             -- 
>>>>                             Bill Burke
>>>>                             JBoss, a division of Red Hat
>>>>                             http://bill.burkecentral.com
>>>>
>>>>
>>>>
>>>>
>>>
>>>                 -- 
>>>                 Bill Burke
>>>                 JBoss, a division of Red Hat
>>>                 http://bill.burkecentral.com
>>>
>>>
>>
>>             -- 
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>
>>
>
>         -- 
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>
>

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

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

From sthorger at redhat.com  Wed Jan 13 14:52:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 13 Jan 2016 20:52:19 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <5696A920.10504@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<569694A9.80008@redhat.com>
	<CAJgngAcYVwACi2fmze+RDk=Z3NOq3wOxG4jE4CVy-akvhg-Dxg@mail.gmail.com>
	<56969EC3.6020206@redhat.com>
	<CAJgngAfjZX+zQDUk5s25_JwmC6ohNxEKwzeO_qwhNX+aho43qw@mail.gmail.com>
	<5696A2DA.4060009@redhat.com>
	<CAJgngAd6nDXxsW7uWEEJ9W0351DkfSwjfpf4ao1k2Qv2szO7Fg@mail.gmail.com>
	<CAJgngAcKueQb-5vSmc+vSVdESR9O-51CfZ3gnHJxJxFzuBa9sQ@mail.gmail.com>
	<5696A920.10504@redhat.com>
Message-ID: <CAJgngAcPa-HpLj-TMMvUaadLRJnJsJCW-AXU4ZWJJweUT1c9jA@mail.gmail.com>

Good - changing to Jackson2 is fun. They've changed all package names,
Maven groupId and artifactIds and also done a fair bit of refactoring to
classes. 162 files changes!

On 13 January 2016 at 20:44, Bill Burke <bburke at redhat.com> wrote:

> I'm working on removing most of our nefarious redirects in the auth flow.
>
>
> On 1/13/2016 2:38 PM, Stian Thorgersen wrote:
>
> BTW I'm doing the switch from Jackson to Jackson2 now, so hope you haven't
> started this yet. I'm touching classes everywhere :/
>
> On 13 January 2016 at 20:37, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 13 January 2016 at 20:17, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 1/13/2016 2:02 PM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 13 January 2016 at 20:00, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> Because it isn't something that would ever be removed like JPA or mongo?
>>>>
>>>
>>> Actually, in theory it could. That's why I thought it was a sensible
>>> separation. It all relies on Freemarker so if we decided to use something
>>> else or to support another templating mechanism as well. Or even to stop
>>> using templates and use AngularJS+rest.
>>>
>>>
>>>
>>> No way it is removed for a LOONNGGG time.  Too many users are dependent
>>> on it now.  Our own codebase depends on it too.
>>>
>>
>> Sure, I'm just saying in theory. My vote goes to keep it separate.
>>
>>
>>>
>>>
>>>> Themes would just be .js and .html and .css right?
>>>>
>>>
>>> Yep. I think it's worth keeping them separate.
>>>
>>>
>>>>
>>>>
>>>> On 1/13/2016 1:19 PM, Stian Thorgersen wrote:
>>>>
>>>> It seems like a logically grouping. Is there a reason you don't want it
>>>> separate?
>>>>
>>>> On 13 January 2016 at 19:17, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> Why do you want freemarker separate?
>>>>>
>>>>>
>>>>> On 1/13/2016 1:14 PM, Stian Thorgersen wrote:
>>>>>
>>>>> How about:
>>>>>
>>>>> keycloak-common
>>>>> keycloak-common-saml
>>>>> keycloak-common-oidc
>>>>>
>>>>> keycloak-server-spi
>>>>> keycloak-server-jpa
>>>>> keycloak-server-mongo
>>>>> keycloak-server-infinispan
>>>>> keycloak-server-freemarker
>>>>> keycloak-server-ldap
>>>>> keycloak-server-themes
>>>>> keycloak-server-wildfly
>>>>> keycloak-server-services
>>>>>
>>>>> All providers that are don't fall into one of the above categories
>>>>> (for example timer, protocol mappers, etc..) can just go into
>>>>> keycloak-server-services.
>>>>>
>>>>>
>>>>> On 12 January 2016 at 19:44, Stian Thorgersen < <sthorger at redhat.com>
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>>>>>> bburke at redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>>>>>> bburke at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> I can't find the original email on this, but we need to do this for
>>>>>>>>> 1.9.  I can start doing it one module at a time:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Common:
>>>>>>>>> keycloak-common
>>>>>>>>> keycloak-common-saml
>>>>>>>>> keycloak-common-oidc
>>>>>>>>>
>>>>>>>>> Libraries server:
>>>>>>>>>
>>>>>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>>>>>> plugins
>>>>>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>>>>>> keycloak-server-impl - everything
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>>>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>>>>>> part of the product.
>>>>>>>>
>>>>>>>> If we put all SPI implementations, including services, into the
>>>>>>>> same module we'd end up with one huge module. There's also a risk that we'd
>>>>>>>> end up with strong relationships between them, rather than having them
>>>>>>>> properly linked via SPI interfaces.
>>>>>>>>
>>>>>>>> I'm a bit 50/50 on it though.
>>>>>>>>
>>>>>>>> You do remember how many modules we currently have don't you?
>>>>>>>> Minimally, we should have a big SPI module right?
>>>>>>>>
>>>>>>>
>>>>>>> I'm absolutely on board with:
>>>>>>>
>>>>>>> Common:
>>>>>>> keycloak-common
>>>>>>> keycloak-common-saml
>>>>>>> keycloak-common-oidc
>>>>>>>
>>>>>>> Libraries server:
>>>>>>> keycloak-server-spi
>>>>>>>
>>>>>>> So we can agree on that, I'm just not 100% sure about a single
>>>>>>> module for all SPI implementations and services.
>>>>>>>
>>>>>>
>>>>>> We can go with a single module if you want. Only thing that needs to
>>>>>> be separate is Mongo at least for now as it's not going to be supported and
>>>>>> we need to be able to remove it easily.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Bill Burke
>>>>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>>
>>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/f4582118/attachment-0001.html 

From mposolda at redhat.com  Wed Jan 13 15:47:02 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Jan 2016 21:47:02 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
Message-ID: <5696B7C6.4010000@redhat.com>

+1 for structure around this. I would personally put every SPI 
implementation, which can be theoretically replaced and which brings any 
dependency into separate module.

For example liquibase JpaUpdaterProvider is another module, which I 
would put separately, so there is easy to get rid of liquibase 
dependency and replace with another JPA updater implementation. On the 
other hand, the very basic SPI implementations like BasicTimer doesn't 
need to be in separate module IMO, as it is simple implementation 
dependent just on pure JDK.

Marek

On 13/01/16 19:14, Stian Thorgersen wrote:
> How about:
>
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> keycloak-server-spi
> keycloak-server-jpa
> keycloak-server-mongo
> keycloak-server-infinispan
> keycloak-server-freemarker
> keycloak-server-ldap
> keycloak-server-themes
> keycloak-server-wildfly
> keycloak-server-services
>
> All providers that are don't fall into one of the above categories 
> (for example timer, protocol mappers, etc..) can just go into 
> keycloak-server-services.
>
>
> On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>
>
>     On 12 January 2016 at 19:32, Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>
>
>
>         On 12 January 2016 at 16:26, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>
>
>             On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>
>>
>>             On 12 January 2016 at 03:22, Bill Burke
>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>
>>                 I can't find the original email on this, but we need
>>                 to do this for
>>                 1.9.  I can start doing it one module at a time: 
>>
>>
>>                 Common:
>>                 keycloak-common
>>                 keycloak-common-saml
>>                 keycloak-common-oidc
>>
>>                 Libraries server:
>>
>>                 keycloak-server-spi - all SPI interfaces and common code
>>                 keycloak-server-saml - all saml server code, broker
>>                 and protocol plugins
>>                 keycloak-server-oidc - all oidc code, broker and
>>                 protocol plugins
>>                 keycloak-server-impl - everything
>>
>>
>>             I'm not 100% sure we should put all implementations of
>>             SPIs into keycloak-server-impl. We at least need to keep
>>             Mongo separate as it's not part of the product.
>>
>>             If we put all SPI implementations, including services,
>>             into the same module we'd end up with one huge module.
>>             There's also a risk that we'd end up with strong
>>             relationships between them, rather than having them
>>             properly linked via SPI interfaces.
>>
>>             I'm a bit 50/50 on it though.
>             You do remember how many modules we currently have don't
>             you?  Minimally, we should have a big SPI module right?
>
>
>         I'm absolutely on board with:
>
>         Common:
>         keycloak-common
>         keycloak-common-saml
>         keycloak-common-oidc
>
>         Libraries server:
>         keycloak-server-spi
>
>         So we can agree on that, I'm just not 100% sure about a single
>         module for all SPI implementations and services.
>
>
>     We can go with a single module if you want. Only thing that needs
>     to be separate is Mongo at least for now as it's not going to be
>     supported and we need to be able to remove it easily.
>
>
>
>
>             -- 
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Wed Jan 13 15:51:24 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 15:51:24 -0500
Subject: [keycloak-dev] Impersonate should be logged like an error?
Message-ID: <5696B8CC.5010608@redhat.com>

IMO, impersonate events should not be treated as a success (debug) event 
and should be logged to the console/log file.  Agreed?

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


From thomas.raehalme at aitiofinland.com  Wed Jan 13 16:09:22 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Wed, 13 Jan 2016 23:09:22 +0200
Subject: [keycloak-dev] Google redirect url
Message-ID: <CAPyAMoYW_5UEX0iExca9_4MCvSe2iF3djEhKq1Fboof_dBPSjQ@mail.gmail.com>

Hi!

Google doesn't accept wildcards in redirect URLs. This means I have to
create a separate client for every realm in the Google console.

Any chance we could have a shared redirect URL across realms? Maybe as an
option in the federation configuration? Then I could share the same Google
config for each tenant.

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160113/faa68f90/attachment.html 

From mposolda at redhat.com  Wed Jan 13 16:16:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Jan 2016 22:16:40 +0100
Subject: [keycloak-dev] Impersonate should be logged like an error?
In-Reply-To: <5696B8CC.5010608@redhat.com>
References: <5696B8CC.5010608@redhat.com>
Message-ID: <5696BEB8.5090806@redhat.com>

Wonder if impersonated events shouldn't be normal events, but just have 
some prefix for them in type? For example IMPERSONATED_LOGIN, 
IMPERSONATED_LOGOUT, IMPERSONATED_TOKEN_REFRESH etc. Similarly like we 
have prefix in type for error events.

And in all impersonated events, there might be also detail in the event 
identifying admin user who is impersonating.

Hopefully this is easy to implement without touching too much files in 
codebase (but not sure) :)

Marek


On 13/01/16 21:51, Bill Burke wrote:
> IMO, impersonate events should not be treated as a success (debug) event
> and should be logged to the console/log file.  Agreed?
>


From bburke at redhat.com  Wed Jan 13 16:29:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 16:29:28 -0500
Subject: [keycloak-dev] Impersonate should be logged like an error?
In-Reply-To: <5696BEB8.5090806@redhat.com>
References: <5696B8CC.5010608@redhat.com> <5696BEB8.5090806@redhat.com>
Message-ID: <5696C1B8.50707@redhat.com>

IMPERONATE replaces LOGIN event.  So, based on that you can just group 
all events under a certain user session to the impersonate one.

I changed my mind, I don't think this should be logged to the 
console/log file by default.  The event manage can be set up to manage 
all this.

On 1/13/2016 4:16 PM, Marek Posolda wrote:
> Wonder if impersonated events shouldn't be normal events, but just 
> have some prefix for them in type? For example IMPERSONATED_LOGIN, 
> IMPERSONATED_LOGOUT, IMPERSONATED_TOKEN_REFRESH etc. Similarly like we 
> have prefix in type for error events.
>
> And in all impersonated events, there might be also detail in the 
> event identifying admin user who is impersonating.
>
> Hopefully this is easy to implement without touching too much files in 
> codebase (but not sure) :)
>
> Marek
>
>
> On 13/01/16 21:51, Bill Burke wrote:
>> IMO, impersonate events should not be treated as a success (debug) event
>> and should be logged to the console/log file.  Agreed?
>>
>

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


From bburke at redhat.com  Wed Jan 13 16:34:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 13 Jan 2016 16:34:58 -0500
Subject: [keycloak-dev] browser refresh again
Message-ID: <5696C302.9010500@redhat.com>

I'm changing browse refresh behavior again.

I've removed all the extra redirects, so now, you can end up being on 
the OTP page, but the URL is the one posted to by password page. Refresh 
page will repost the password, keycloak will see that the current action 
is not the same, and just ask the flow to put the browser in the right 
state.  Similarly with required actions.

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


From mposolda at redhat.com  Wed Jan 13 16:53:24 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 13 Jan 2016 22:53:24 +0100
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
Message-ID: <5696C754.2080909@redhat.com>

On 13/01/16 13:40, Edgar Vonk - Info.nl wrote:
> Hi all,
>
> We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.
>
> Our password policies in AD are as follows:
> - password complexity (min length + special chars)
> - account lock out after 3 attempts
> - password history (not allowed to use previous 5 passwords)
>
> Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
> - Password complexity policy seems to work fine.
> - Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through 
userAccountControl attribute? In the Keycloak 1.8 I've added the MSAD 
UserAccountControl mapper, which allows to integrate the MSAD account 
state more tightly into Keycloak state. For example enable user in 
Keycloak admin console will remove the ACCOUNTDISABLE flag from 
userAccountControl value in MSAD as well and hence enable this user in 
MSAD too.

However support for lock/unlock is not included in the mapper though. So 
feel free to create JIRA.

Until it's implemented, you can possibly use adminEvent listener (There 
is admin event triggered when you click "Unlock user" in Keycloak UI. So 
you can listen to this event and propagate the call to MSAD once you 
successfully enable it)
> - The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's 
strange the MSAD allows to change password through this API when it 
breaks password history policy. Are you sure you have WRITABLE LDAP and 
password update from Keycloak is propagated to MSAD?

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


From sthorger at redhat.com  Thu Jan 14 02:45:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 08:45:39 +0100
Subject: [keycloak-dev] module re-org
In-Reply-To: <5696B7C6.4010000@redhat.com>
References: <5694634A.9010201@redhat.com>
	<CAJgngAc1YAhVuwQ0=Z6wHo8-K2LwoVJfrx9rfspnnovLBKnMUQ@mail.gmail.com>
	<56951B13.7020401@redhat.com>
	<CAJgngAd6e1_H5K3czRoJ5Ju0ErU8ASe3Xm_2ZQPFvtBeu2OcpQ@mail.gmail.com>
	<CAJgngAc1gM4LyxRaf0VrT5T=hCpK+Siz-3JcE3mt+PmwDSaP=w@mail.gmail.com>
	<CAJgngAe5Pj6sRsxOQL0tz0KxoNyFSaqaozuVzBKFTjj-b7tneQ@mail.gmail.com>
	<5696B7C6.4010000@redhat.com>
Message-ID: <CAJgngAdXsZh5BF4pGSdW4q5JPjHR=9pvqOHXtbYaUnag+560-w@mail.gmail.com>

On 13 January 2016 at 21:47, Marek Posolda <mposolda at redhat.com> wrote:

> +1 for structure around this. I would personally put every SPI
> implementation, which can be theoretically replaced and which brings any
> dependency into separate module.
>

I agree. A structure based on a major dependency like Mongo, JPA,
FreeMarker, etc makes sense to me.


>
> For example liquibase JpaUpdaterProvider is another module, which I would
> put separately, so there is easy to get rid of liquibase dependency and
> replace with another JPA updater implementation. On the other hand, the
> very basic SPI implementations like BasicTimer doesn't need to be in
> separate module IMO, as it is simple implementation dependent just on pure
> JDK.
>

The JPA stores are pretty dependent on Liquibase so I would just keep them
together. Otherwise we're splitting up a store implementation into multiple
pieces.


>
>
> Marek
>
>
> On 13/01/16 19:14, Stian Thorgersen wrote:
>
> How about:
>
> keycloak-common
> keycloak-common-saml
> keycloak-common-oidc
>
> keycloak-server-spi
> keycloak-server-jpa
> keycloak-server-mongo
> keycloak-server-infinispan
> keycloak-server-freemarker
> keycloak-server-ldap
> keycloak-server-themes
> keycloak-server-wildfly
> keycloak-server-services
>
> All providers that are don't fall into one of the above categories (for
> example timer, protocol mappers, etc..) can just go into
> keycloak-server-services.
>
>
> On 12 January 2016 at 19:44, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 12 January 2016 at 19:32, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On 12 January 2016 at 16:26, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 1/12/2016 2:45 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> On 12 January 2016 at 03:22, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> I can't find the original email on this, but we need to do this for
>>>>> 1.9.  I can start doing it one module at a time:
>>>>
>>>>
>>>>> Common:
>>>>> keycloak-common
>>>>> keycloak-common-saml
>>>>> keycloak-common-oidc
>>>>>
>>>>> Libraries server:
>>>>>
>>>>> keycloak-server-spi - all SPI interfaces and common code
>>>>> keycloak-server-saml - all saml server code, broker and protocol
>>>>> plugins
>>>>> keycloak-server-oidc - all oidc code, broker and protocol plugins
>>>>> keycloak-server-impl - everything
>>>>>
>>>>
>>>> I'm not 100% sure we should put all implementations of SPIs into
>>>> keycloak-server-impl. We at least need to keep Mongo separate as it's not
>>>> part of the product.
>>>>
>>>> If we put all SPI implementations, including services, into the same
>>>> module we'd end up with one huge module. There's also a risk that we'd end
>>>> up with strong relationships between them, rather than having them properly
>>>> linked via SPI interfaces.
>>>>
>>>> I'm a bit 50/50 on it though.
>>>>
>>>> You do remember how many modules we currently have don't you?
>>>> Minimally, we should have a big SPI module right?
>>>>
>>>
>>> I'm absolutely on board with:
>>>
>>> Common:
>>> keycloak-common
>>> keycloak-common-saml
>>> keycloak-common-oidc
>>>
>>> Libraries server:
>>> keycloak-server-spi
>>>
>>> So we can agree on that, I'm just not 100% sure about a single module
>>> for all SPI implementations and services.
>>>
>>
>> We can go with a single module if you want. Only thing that needs to be
>> separate is Mongo at least for now as it's not going to be supported and we
>> need to be able to remove it easily.
>>
>>
>>>
>>>
>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/1d9c3cac/attachment.html 

From sthorger at redhat.com  Thu Jan 14 02:48:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 08:48:49 +0100
Subject: [keycloak-dev] Google redirect url
In-Reply-To: <CAPyAMoYW_5UEX0iExca9_4MCvSe2iF3djEhKq1Fboof_dBPSjQ@mail.gmail.com>
References: <CAPyAMoYW_5UEX0iExca9_4MCvSe2iF3djEhKq1Fboof_dBPSjQ@mail.gmail.com>
Message-ID: <CAJgngAcV_09p+7HVpx4p_JCW5d8TmNk_Wf71uSLPYAGcbHf2wQ@mail.gmail.com>

On 13 January 2016 at 22:09, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> Hi!
>
> Google doesn't accept wildcards in redirect URLs. This means I have to
> create a separate client for every realm in the Google console.
>
> Any chance we could have a shared redirect URL across realms? Maybe as an
> option in the federation configuration? Then I could share the same Google
> config for each tenant.
>
-1 The client in Google should be per-realm as otherwise you're also
sharing the config in Google (logo, contact email, etc) and also consent.
Also, all logic here is per-realm so it would be a fair bit of special code
to be able to support this.

Best regards,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/cd93ba24/attachment-0001.html 

From sthorger at redhat.com  Thu Jan 14 02:50:30 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 08:50:30 +0100
Subject: [keycloak-dev] Impersonate should be logged like an error?
In-Reply-To: <5696C1B8.50707@redhat.com>
References: <5696B8CC.5010608@redhat.com> <5696BEB8.5090806@redhat.com>
	<5696C1B8.50707@redhat.com>
Message-ID: <CAJgngAcoABvUNzn_Qhfe0fYqq+Gz-tk3ozAyHUT6DaHqnNbtJw@mail.gmail.com>

So we already have an IMPERSONATE event? Does it include details about the
admin?

On 13 January 2016 at 22:29, Bill Burke <bburke at redhat.com> wrote:

> IMPERONATE replaces LOGIN event.  So, based on that you can just group
> all events under a certain user session to the impersonate one.
>
> I changed my mind, I don't think this should be logged to the
> console/log file by default.  The event manage can be set up to manage
> all this.
>
> On 1/13/2016 4:16 PM, Marek Posolda wrote:
> > Wonder if impersonated events shouldn't be normal events, but just
> > have some prefix for them in type? For example IMPERSONATED_LOGIN,
> > IMPERSONATED_LOGOUT, IMPERSONATED_TOKEN_REFRESH etc. Similarly like we
> > have prefix in type for error events.
> >
> > And in all impersonated events, there might be also detail in the
> > event identifying admin user who is impersonating.
> >
> > Hopefully this is easy to implement without touching too much files in
> > codebase (but not sure) :)
> >
> > Marek
> >
> >
> > On 13/01/16 21:51, Bill Burke wrote:
> >> IMO, impersonate events should not be treated as a success (debug) event
> >> and should be logged to the console/log file.  Agreed?
> >>
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/35a94f89/attachment.html 

From sthorger at redhat.com  Thu Jan 14 02:53:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 08:53:10 +0100
Subject: [keycloak-dev] browser refresh again
In-Reply-To: <5696C302.9010500@redhat.com>
References: <5696C302.9010500@redhat.com>
Message-ID: <CAJgngAeWWsd0sWbehubeM=dD_UeHEKXjBGHgQndXvn-7Xb9T8w@mail.gmail.com>

Do we support async authenticators? I'm thinking about something like:

* User logs in on desktop with username/password
* As two factor auth we send a notification to a mobile phone app
* When user clicks ok on the mobile phone app the login on the desktop
continues

This type of authentication is used by banks in Norway, which is very nice
as you don't need to manually write a code.


On 13 January 2016 at 22:34, Bill Burke <bburke at redhat.com> wrote:

> I'm changing browse refresh behavior again.
>
> I've removed all the extra redirects, so now, you can end up being on
> the OTP page, but the URL is the one posted to by password page. Refresh
> page will repost the password, keycloak will see that the current action
> is not the same, and just ask the flow to put the browser in the right
> state.  Similarly with required actions.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/64af0bc2/attachment.html 

From thomas.raehalme at aitiofinland.com  Thu Jan 14 03:12:24 2016
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 14 Jan 2016 10:12:24 +0200
Subject: [keycloak-dev] Google redirect url
In-Reply-To: <CAJgngAcV_09p+7HVpx4p_JCW5d8TmNk_Wf71uSLPYAGcbHf2wQ@mail.gmail.com>
References: <CAPyAMoYW_5UEX0iExca9_4MCvSe2iF3djEhKq1Fboof_dBPSjQ@mail.gmail.com>
	<CAJgngAcV_09p+7HVpx4p_JCW5d8TmNk_Wf71uSLPYAGcbHf2wQ@mail.gmail.com>
Message-ID: <CAPyAMoY7Ds9wb0G9SiTsx_JpE9_Pi=L=Z-VYmc7v=V=W-qyBjg@mail.gmail.com>

On Thu, Jan 14, 2016 at 9:48 AM, Stian Thorgersen <sthorger at redhat.com>
wrote:
>
>
> On 13 January 2016 at 22:09, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
>> Hi!
>>
>> Google doesn't accept wildcards in redirect URLs. This means I have to
>> create a separate client for every realm in the Google console.
>>
>> Any chance we could have a shared redirect URL across realms? Maybe as an
>> option in the federation configuration? Then I could share the same Google
>> config for each tenant.
>>
> -1 The client in Google should be per-realm as otherwise you're also
> sharing the config in Google (logo, contact email, etc) and also consent.
> Also, all logic here is per-realm so it would be a fair bit of special code
> to be able to support this.
>

I understand your points, but in a SaaS application with a realm per
tenant, it would simplify operations a great deal. You'd probably be
sharing the config in Google anyways.

For example, themes are also shared across realms so would it really be
such a big problem considering the advantages?

Best regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/19f4c565/attachment.html 

From Edgar at info.nl  Thu Jan 14 03:54:22 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 14 Jan 2016 08:54:22 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <5696C754.2080909@redhat.com>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
Message-ID: <92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>

Hi Marek,

Thanks very much for your reply. See remarks below.

On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

On 13/01/16 13:40, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?

Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.


In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.


This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.

We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.

I will create a JIRA issue so that I can send you some more details.


However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.


Ok, will do.


Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?

Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.

cheers

Edgar


Marek

cheers

Edgar


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

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

From sthorger at redhat.com  Thu Jan 14 03:57:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 09:57:23 +0100
Subject: [keycloak-dev] Google redirect url
In-Reply-To: <CAPyAMoY7Ds9wb0G9SiTsx_JpE9_Pi=L=Z-VYmc7v=V=W-qyBjg@mail.gmail.com>
References: <CAPyAMoYW_5UEX0iExca9_4MCvSe2iF3djEhKq1Fboof_dBPSjQ@mail.gmail.com>
	<CAJgngAcV_09p+7HVpx4p_JCW5d8TmNk_Wf71uSLPYAGcbHf2wQ@mail.gmail.com>
	<CAPyAMoY7Ds9wb0G9SiTsx_JpE9_Pi=L=Z-VYmc7v=V=W-qyBjg@mail.gmail.com>
Message-ID: <CAJgngAfsS2f6Y2knmbQWHLZ=Q_NXM=AUVwPqb_7soQ=TYssf3g@mail.gmail.com>

On 14 January 2016 at 09:12, Thomas Raehalme <
thomas.raehalme at aitiofinland.com> wrote:

> On Thu, Jan 14, 2016 at 9:48 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>>
>>
>> On 13 January 2016 at 22:09, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>>> Hi!
>>>
>>> Google doesn't accept wildcards in redirect URLs. This means I have to
>>> create a separate client for every realm in the Google console.
>>>
>>> Any chance we could have a shared redirect URL across realms? Maybe as
>>> an option in the federation configuration? Then I could share the same
>>> Google config for each tenant.
>>>
>> -1 The client in Google should be per-realm as otherwise you're also
>> sharing the config in Google (logo, contact email, etc) and also consent.
>> Also, all logic here is per-realm so it would be a fair bit of special code
>> to be able to support this.
>>
>
> I understand your points, but in a SaaS application with a realm per
> tenant, it would simplify operations a great deal. You'd probably be
> sharing the config in Google anyways.
>

In a SaaS application it's even more important to have a separate client at
Google. You want the owner of the tenant to bring their own and not have
one shared between all tenants. Another issue is number of requests
per-client. Google limits the number of free API calls you can do (can't
remember how many) and you have to pay after that. I don't think you want
to pay for all tenants of a SaaS platform in one go?


>
> For example, themes are also shared across realms so would it really be
> such a big problem considering the advantages?
>

Theme sources are shared, but they are still configured individually
per-realm and also bring in config from the realm itself. A theme is just
like a JAR in this perspective.

Having shared redirect uri for a identity broker would mean we'd need a
non-realm specific endpoint for this, which means the endpoint would have
to somehow figure out what realm the redirect belongs to before processing
it. This may be even more complicated in the future if we introduce more
isolation between realms. For example having a different store for each
realm.


>
> Best regards,
> Thomas
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/86a3507b/attachment.html 

From Edgar at info.nl  Thu Jan 14 04:01:02 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 14 Jan 2016 09:01:02 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
Message-ID: <37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>

Hi Marek,

Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!

Thanks again for your help.

cheers

Edgar


On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

Thanks very much for your reply. See remarks below.

On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

On 13/01/16 13:40, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?

Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.


In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.


This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.

We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.

I will create a JIRA issue so that I can send you some more details.


However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.


Ok, will do.


Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?

Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.

cheers

Edgar


Marek

cheers

Edgar


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


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

From mposolda at redhat.com  Thu Jan 14 04:28:41 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 14 Jan 2016 10:28:41 +0100
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
Message-ID: <56976A49.20504@redhat.com>

Yeah, the new MSAD mapper added in 1.8 should help you with this. Once 
the user has in MSAD userAccountControl of 514, he will be marked as 
disabled in Keycloak. Then when you enable it in Keycloak, it should be 
propagated to MSAD and user will be put in MSAD to 512. Hope it will 
work for you.

Not sure about password history issue.

Will wait for your feedback. Hope we can sort your issues.

Marek

On 14/01/16 10:01, Edgar Vonk - Info.nl wrote:
> Hi Marek,
>
> Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 
> while we are still on Keycloak 1.7.. I will upgrade and let you know 
> a.s.a.p!
>
> Thanks again for your help.
>
> cheers
>
> Edgar
>
>
>> On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl <http://info.nl> 
>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>
>> Hi Marek,
>>
>> Thanks very much for your reply. See remarks below.
>>
>>> On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com 
>>> <mailto:mposolda at redhat.com>> wrote:
>>>
>>> On 13/01/16 13:40, Edgar Vonk -Info.nl <http://info.nl/>wrote:
>>>> Hi all,
>>>>
>>>> We use Keycloak?s user federation to integrate with a (Windows 
>>>> 2012) Active Directory (AD) server. We want to store all users and 
>>>> groups in AD and also want to manage the password policies from AD 
>>>> so we do not have any password policies in Keycloak set up. We also 
>>>> want to use Keycloak for all user management functionality. We have 
>>>> set up the password policies in AD at the domain level where we 
>>>> connect to from Keycloak.
>>>>
>>>> Our password policies in AD are as follows:
>>>> - password complexity (min length + special chars)
>>>> - account lock out after 3 attempts
>>>> - password history (not allowed to use previous 5 passwords)
>>>>
>>>> Users and admins can set and change passwords in AD from Keycloak 
>>>> fine. However the password policies do not quite do what we want 
>>>> them to:
>>>> - Password complexity policy seems to work fine.
>>>> - Account is indeed locked in AD after three failed attempts. 
>>>> However the ?Unlock users? functionality in Keycloak does not 
>>>> unlock the users in AD. Users can only be unlocked in AD itself it 
>>>> seems. We would like to be able to do this from Keycloak however 
>>>> (and really per user and not for all users in one go). Should this 
>>>> work in Keycloak or is this a new feature request?
>>> Is the fact that user is locked tracked in your MSAD through 
>>> userAccountControl attribute?
>>
>> Yes it is. I see this working when I look at a normal LDAP browser 
>> connected to MSAD. When I disable a user in MSAD I see the 
>> userAccountControl attribute change from 512 to 514.
>>
>>
>>> In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, 
>>> which allows to integrate the MSAD account state more tightly into 
>>> Keycloak state. For example enable user in Keycloak admin console 
>>> will remove the ACCOUNTDISABLE flag from userAccountControl value in 
>>> MSAD as well and hence enable this user in MSAD too.
>>
>>
>> This sounds good, however unfortunately we do not see this happening. 
>>  When I disable the user in Keycloak the userAccountControl attribute 
>> does not change at all so the propagation to MSAD does not seem to 
>> work here.
>>
>> We have indeed configured the user federation in Keycloak to WRITABLE 
>> LDAP and all other user attributes (like user name etc) are 
>> propagated from Keycloak to MSAD just fine.
>>
>> I will create a JIRA issue so that I can send you some more details.
>>
>>>
>>> However support for lock/unlock is not included in the mapper 
>>> though. So feel free to create JIRA.
>>>
>>
>> Ok, will do.
>>
>>
>>> Until it's implemented, you can possibly use adminEvent listener 
>>> (There is admin event triggered when you click "Unlock user" in 
>>> Keycloak UI. So you can listen to this event and propagate the call 
>>> to MSAD once you successfully enable it)
>>>> - The password history policy does not seem to work at all. Users 
>>>> can currently set their password to a previous password without a 
>>>> problem. Does anyone have an idea why this policy in AD does not 
>>>> work from Keycloak?
>>> No idea. Keycloak is just using Directory API for change password. 
>>> It's strange the MSAD allows to change password through this API 
>>> when it breaks password history policy. Are you sure you have 
>>> WRITABLE LDAP and password update from Keycloak is propagated to MSAD?
>>
>> Yes, we have writable ldap configured and indeed the password is 
>> propagated to MSAD. Maybe it is related to the issue we see with the 
>> userAccountControl attribute.
>>
>> cheers
>>
>> Edgar
>>
>>>
>>> Marek
>>>>
>>>> cheers
>>>>
>>>> Edgar
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From Edgar at info.nl  Thu Jan 14 05:23:21 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 14 Jan 2016 10:23:21 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <56976A49.20504@redhat.com>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
Message-ID: <EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>

Hi Marek,

On 14 Jan 2016, at 10:28, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

Yeah, the new MSAD mapper added in 1.8 should help you with this. Once the user has in MSAD userAccountControl of 514, he will be marked as disabled in Keycloak. Then when you enable it in Keycloak, it should be propagated to MSAD and user will be put in MSAD to 512. Hope it will work for you.



Thanks but I?m afraid it does not work for us. I am using Keycloak 1.8.0.CR1 now. When I disable the user in MSAD I see the userAccountControl attribute change to 514, however this is not reflected in Keycloak. Not even when I force a resync of all users.

I will see if I can do some debugging and create a JIRA issue for you.

cheers

Edgar


Not sure about password history issue.

Will wait for your feedback. Hope we can sort your issues.

Marek

On 14/01/16 10:01, Edgar Vonk - Info.nl<http://info.nl> wrote:
Hi Marek,

Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!

Thanks again for your help.

cheers

Edgar


On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl<http://info.nl/> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

Thanks very much for your reply. See remarks below.

On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

On 13/01/16 13:40, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?

Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.


In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.


This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.

We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.

I will create a JIRA issue so that I can send you some more details.


However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.


Ok, will do.


Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?

Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.

cheers

Edgar


Marek

cheers

Edgar


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




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

From Edgar at info.nl  Thu Jan 14 06:09:24 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 14 Jan 2016 11:09:24 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
	<EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
Message-ID: <1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>

Ah, sorry about this. I had not added a MSAD User Account Control mapper in our existing AD user federation in Keycloak yet. I thought it might be implicit and that I would not have to define an actual mapper or something. However this fixed the synching of the enabled status between AD and Keycloak. Nice work!




On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

On 14 Jan 2016, at 10:28, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

Yeah, the new MSAD mapper added in 1.8 should help you with this. Once the user has in MSAD userAccountControl of 514, he will be marked as disabled in Keycloak. Then when you enable it in Keycloak, it should be propagated to MSAD and user will be put in MSAD to 512. Hope it will work for you.



Thanks but I?m afraid it does not work for us. I am using Keycloak 1.8.0.CR1 now. When I disable the user in MSAD I see the userAccountControl attribute change to 514, however this is not reflected in Keycloak. Not even when I force a resync of all users.

I will see if I can do some debugging and create a JIRA issue for you.

cheers

Edgar


Not sure about password history issue.

Will wait for your feedback. Hope we can sort your issues.

Marek

On 14/01/16 10:01, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi Marek,

Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!

Thanks again for your help.

cheers

Edgar


On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl<http://info.nl/> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

Thanks very much for your reply. See remarks below.

On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

On 13/01/16 13:40, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?

Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.


In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.


This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.

We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.

I will create a JIRA issue so that I can send you some more details.


However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.


Ok, will do.


Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?

Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.

cheers

Edgar


Marek

cheers

Edgar


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





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

From jm85martins at gmail.com  Thu Jan 14 07:17:56 2016
From: jm85martins at gmail.com (Jorge M.)
Date: Thu, 14 Jan 2016 12:17:56 +0000
Subject: [keycloak-dev] Custom federation - webservice
In-Reply-To: <5679AF75.2000600@redhat.com>
References: <CAHEpHRL1tuZbp-DU-aQeQt9GZ1JyRhJUdw3L0H2Ca_Qj1wnLfw@mail.gmail.com>
	<5668755C.6040500@redhat.com>
	<CAHEpHRLRHiqNAQUm0KJnCDrtMWp9ZNOPY5ffLDEfhbZJsRLSNg@mail.gmail.com>
	<566A9C53.1080401@redhat.com> <566AB137.3050107@redhat.com>
	<566ABE50.8020606@redhat.com>
	<CAHEpHR+bnYfcgNyFeCC0obP7meymoo+R_zCuD3+Jrmc7scOUow@mail.gmail.com>
	<566F24AC.4020904@redhat.com>
	<CAJgngAf2hWHtGkBh1DiS1UkcPhJ7MkqBuPu=Mx6B3JYYsw920Q@mail.gmail.com>
	<CAHEpHRKTABJekKKp3XG=Rj+d=R-k_W4fwTmv5tcO3oVc-918DA@mail.gmail.com>
	<5679AF75.2000600@redhat.com>
Message-ID: <CAHEpHRLS6SsmiCFs+4iDv+BQG4_xhT=PAHSwD7d4vs08kOJf1w@mail.gmail.com>

Hi,

Is this improvement part of the 1.8.0.CR1 ?
"We will likely improve that for 1.8 by allow enlist transaction with
priorities, which will allow to specify if your federationProvider commit
should be called before or after JPA commit."

Thank you,
Jorge

2015-12-22 20:15 GMT+00:00 Marek Posolda <mposolda at redhat.com>:

> On 22/12/15 11:43, Jorge M. wrote:
>
> Hi,
>
> "I think I'm in the right track now. I'm being able to call the webservice
> before commit. However, when the user is sucessfully created by the
> webservice, I need to update my local user to add a property with the
> external user id. How can I do that in the same transaction?
> I'm trying to set the property on the managed delegate user model, but it
> has no effect."
>
> Is there any workaround for this? Basically, after the webservice call
> (I'm doing the job with an approach based on TxAwareLDAPUserModelDelegate)
> I need to get the previously saved userStorage user, set an attribute and
> save it again. At UserProvider interface I can't see any update method.
>
> Yes, there is no any update method. It's because data of UserModel are
> automatically persistent and attached with DB. For example if you call:
>
> UserModel john = session.users().getUserByUsername("john");
>
> The "john" instance is persistent. So then if you call:
>
> john.setFirstName("Johnnn");
>
> the firstName is updated automatically in DB. No reason to call any
> additional update method.
>
> So if you are really able to call your webservice before commit, then you
> can just do something like:
>
> Object wsOutput = callYourWebService(...);
> john.setFirstName(wsOutput.getSomethingFromWSOutput);
> john.setAttribute("foo", wsOutput.getSomethingElseFromWSOutput);
>
> and it should work. If it doesn't work, then you're probably calling your
> web service after DB commit (this is what TxAwareLDAPUserModelDelegate is
> also doing btv. LDAP commit is send after DB commit).
>
> We will likely improve that for 1.8 by allow enlist transaction with
> priorities, which will allow to specify if your federationProvider commit
> should be called before or after JPA commit (See my previous email).
>
> Marek
>
>
> Thanks
>
> 2015-12-17 8:50 GMT+00:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> I guess in certain situations this can be helpful. It doesn't solve the
>> problem though so we need something smarter at some point, but we don't
>> have the time to do it right now so would have to be for 2.x.
>>
>> On 14 December 2015 at 21:21, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> I think yes. It should be quite easy to change the signature of
>>> KeycloakTransactionManager methods. Just waiting if other team members
>>> agree and then we can possibly change fix version of
>>> <https://issues.jboss.org/browse/KEYCLOAK-1075>
>>> https://issues.jboss.org/browse/KEYCLOAK-1075 to 1.8 and do it for this
>>> release.
>>>
>>> Marek
>>>
>>>
>>> On 14/12/15 17:15, Jorge M. wrote:
>>>
>>> I agree. I think that could solve these issues. Is that something that
>>> can go on a near release?
>>>
>>> Thank yoy
>>> On 11 Dec 2015 12:15, "Vlastimil Elias" < <velias at redhat.com>
>>> velias at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 11.12.2015 12:19, Marek Posolda wrote:
>>>>
>>>> I think what we can possibly do is:
>>>>
>>>> 1) Improve KeycloakTransactionManager to allow enlist with "priority" .
>>>> Instead of methods:
>>>>
>>>> void enlist(KeycloakTransaction transaction);
>>>> void enlistAfterCompletion(KeycloakTransaction transaction);
>>>>
>>>> we will have single method:
>>>>
>>>> void enlist(KeycloakTransaction transaction, int priority);
>>>>
>>>> By default, JPA will enlist transaction with priority 10 and infinispan
>>>> with priority 20 or something like that.
>>>>
>>>> This change will allow to enlist your transaction in your
>>>> FederationProvider with exact priority. So you can choose whether the
>>>> commit will happen  before JPA commit, or after JPA commit or even after
>>>> infinispan commit etc.
>>>>
>>>>
>>>> +1, this may help to resolve current problems
>>>>
>>>> 2) Make TxAwareLDAPUserModelDelegate class more generic and reusable
>>>> for other federation providers
>>>>
>>>>
>>>> may also help, but point 1 with correct documentation is main what we
>>>> have to do
>>>>
>>>> Thanks
>>>>
>>>> Vlastimil
>>>>
>>>>
>>>> Marek
>>>>
>>>> On 11/12/15 10:50, Vlastimil Elias wrote:
>>>>
>>>> Hi,
>>>>
>>>> I use similar approach and problem is (at least I think) that local DB
>>>> transaction is already commited when our code runs. It has two negative
>>>> effects:
>>>> - if remote service call is successful you are not able to write
>>>> anything locally as Jorge mentioned
>>>> - if remote service call fails local DB record is commited already and
>>>> it is hard to implement correct error handling
>>>>
>>>> So I think User Federation SPI should be extended by exact method which
>>>> allows atomic call of backend during user creation or update before local
>>>> transaction is commited. I already created issue for it but not resolved
>>>> yet <https://issues.jboss.org/browse/KEYCLOAK-1075>
>>>> https://issues.jboss.org/browse/KEYCLOAK-1075
>>>>
>>>> Vlastimil
>>>>
>>>> On 10.12.2015 18:49, Jorge M. wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think I'm in the right track now. I'm being able to call the
>>>> webservice before commit. However, when the user is sucessfully created by
>>>> the webservice, I need to update my local user to add a property with the
>>>> external user id. How can I do that in the same transaction?
>>>> I'm trying to set the property on the managed delegate user model, but
>>>> it has no effect.
>>>>
>>>> Thank you!
>>>> On 9 Dec 2015 18:39, "Marek Posolda" < <mposolda at redhat.com>
>>>> mposolda at redhat.com> wrote:
>>>>
>>>>> On 09/12/15 19:33, Jorge M. wrote:
>>>>>
>>>>> I'm developing a custom federation that communicates with my user
>>>>> repository via webservices.
>>>>> Probably this is a very strange scenario for a federation but that's
>>>>> the unique way that I have to communicate with the repository.
>>>>>
>>>>> My problem is that, as the webservices only exposes methods such as
>>>>> createUser and updateUser, I'm having problems with registrations and user
>>>>> profile updates because I'm not being able to do atomic calls to the
>>>>> webservice methods, with all the information that I need.
>>>>>
>>>>> As far as I know, from the properties file example and from the ldap
>>>>> federation source (probably I'm missing something) it seems that the
>>>>> federation api is intended to update and sync attribute by attribute
>>>>> (Keycloak <-> Federation).
>>>>> Am i wrong? Do you suggest another approach? Should I give up from
>>>>> having a federation that uses a webservice?
>>>>>
>>>>> You can use "transaction wrapper", which will allow you to store all
>>>>> the updates to user locally, but send the UPDATE request to your webservice
>>>>> later at transaction commit time. You may need to create custom transaction
>>>>> and enlist it with Keycloak TransactionManager.
>>>>>
>>>>> This is what we have for LDAP federation provider right now. See
>>>>> TxAwareLDAPUserModelDelegate.
>>>>>
>>>>> Marek
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>> --
>>>> Vlastimil Elias
>>>> Principal Software Engineer
>>>> Developer Portal Engineering Team
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Vlastimil Elias
>>>> Principal Software Engineer
>>>> Developer Portal Engineering Team
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/c86cbcfb/attachment-0001.html 

From lkrzyzan at redhat.com  Thu Jan 14 07:37:54 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Thu, 14 Jan 2016 13:37:54 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
In-Reply-To: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
References: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
Message-ID: <16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>

Appreciated the CR1 !

here is small improvement for Realm Display Name: https://issues.jboss.org/browse/KEYCLOAK-2313 <https://issues.jboss.org/browse/KEYCLOAK-2313>

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Jan 13, 2016, at 11:52 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Realm Display Name - a display name has been added to realms, which makes it possible to set a human readable name to be shown on login screens, emails, etc.

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

From sthorger at redhat.com  Thu Jan 14 08:00:39 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 14:00:39 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
In-Reply-To: <16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>
References: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
	<16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>
Message-ID: <CAJgngAcVBC+=AJVRA+cxsHBCdWoQri2UBVz8mL0SkOzwoH9bnw@mail.gmail.com>

Do you need that for 1.8.Final or is it ok if we add it to 1.9?

On 14 January 2016 at 13:37, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> Appreciated the CR1 !
>
> here is small improvement for Realm Display Name:
> https://issues.jboss.org/browse/KEYCLOAK-2313
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
> On Jan 13, 2016, at 11:52 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>
>    - *Realm Display Name* - a display name has been added to realms,
>    which makes it possible to set a human readable name to be shown on login
>    screens, emails, etc.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/a16ad7d3/attachment.html 

From mhajas at redhat.com  Thu Jan 14 08:34:02 2016
From: mhajas at redhat.com (Michal Hajas)
Date: Thu, 14 Jan 2016 08:34:02 -0500 (EST)
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <1683011400.15573161.1452774616935.JavaMail.zimbra@redhat.com>
Message-ID: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>

Hi,

I'm trying to run apache + mod_auth_mellon with keycloak as indentity provider.

Steps:
1. Install apache and mod_auth_mellon module
2. Generate .key, .cert, .xml files with mellon_create_metadata.sh and copy them to /mellon directory
3. Download idp_metadata.xml from keycloak/auth/realm/{REALM}/protocol/saml/descriptor and copy it to /mellon directory
4. Configure auth_mod_mellon with enclosed file auth_mellon.conf
5. Create client in keycloak from xml file generated in step 2 (There must be enabled Sign Documents, Sign Assertions signing and Force POST Binding)

Login works, when I access /auth, mellon redirect me to keycloak and after successful login it redirect me back to protected resource.

Problem:
I'm not able to logout. When I access localhost/mellon/logout?ReturnTo=/, it doesn't destroy session in keycloak and in apache's error log there is:
Current identity provider does not support single logout. Destroying local session only.

Only way I was able to log out is change 

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/auth/realms/mellon-test/protocol/saml"/>

to

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8080/auth/realms/mellon-test/protocol/saml"/>

POST -> Redirect

in idp_metadata.xml and set "Logout Service Redirect Binding URL" to http://localhost/mellon/logout in admin console. 

Is it correct or it should work with POST binding too?

Thank you,
Michal.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: auth_mellon.conf
Type: application/octet-stream
Size: 1047 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/8fa59165/attachment.obj 

From bburke at redhat.com  Thu Jan 14 09:09:44 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 14 Jan 2016 09:09:44 -0500
Subject: [keycloak-dev] Impersonate should be logged like an error?
In-Reply-To: <CAJgngAcoABvUNzn_Qhfe0fYqq+Gz-tk3ozAyHUT6DaHqnNbtJw@mail.gmail.com>
References: <5696B8CC.5010608@redhat.com> <5696BEB8.5090806@redhat.com>
	<5696C1B8.50707@redhat.com>
	<CAJgngAcoABvUNzn_Qhfe0fYqq+Gz-tk3ozAyHUT6DaHqnNbtJw@mail.gmail.com>
Message-ID: <5697AC28.4090102@redhat.com>

It includes the username of the admin.

On 1/14/2016 2:50 AM, Stian Thorgersen wrote:
> So we already have an IMPERSONATE event? Does it include details about 
> the admin?
>
> On 13 January 2016 at 22:29, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     IMPERONATE replaces LOGIN event.  So, based on that you can just group
>     all events under a certain user session to the impersonate one.
>
>     I changed my mind, I don't think this should be logged to the
>     console/log file by default.  The event manage can be set up to manage
>     all this.
>
>     On 1/13/2016 4:16 PM, Marek Posolda wrote:
>     > Wonder if impersonated events shouldn't be normal events, but just
>     > have some prefix for them in type? For example IMPERSONATED_LOGIN,
>     > IMPERSONATED_LOGOUT, IMPERSONATED_TOKEN_REFRESH etc. Similarly
>     like we
>     > have prefix in type for error events.
>     >
>     > And in all impersonated events, there might be also detail in the
>     > event identifying admin user who is impersonating.
>     >
>     > Hopefully this is easy to implement without touching too much
>     files in
>     > codebase (but not sure) :)
>     >
>     > Marek
>     >
>     >
>     > On 13/01/16 21:51, Bill Burke wrote:
>     >> IMO, impersonate events should not be treated as a success
>     (debug) event
>     >> and should be logged to the console/log file. Agreed?
>     >>
>     >
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

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

From bburke at redhat.com  Thu Jan 14 09:17:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 14 Jan 2016 09:17:31 -0500
Subject: [keycloak-dev] browser refresh again
In-Reply-To: <CAJgngAeWWsd0sWbehubeM=dD_UeHEKXjBGHgQndXvn-7Xb9T8w@mail.gmail.com>
References: <5696C302.9010500@redhat.com>
	<CAJgngAeWWsd0sWbehubeM=dD_UeHEKXjBGHgQndXvn-7Xb9T8w@mail.gmail.com>
Message-ID: <5697ADFB.2030204@redhat.com>

To make this work, we would need a way to plug in a REST service that 
could receive input from the mobile device.  It would search through 
client sessions of the user to see which one was waiting for a mobile 
authentication. Then change the state of the client session.  The 
browser session could poll the client session until a flag was set.


On 1/14/2016 2:53 AM, Stian Thorgersen wrote:
> Do we support async authenticators? I'm thinking about something like:
>
> * User logs in on desktop with username/password
> * As two factor auth we send a notification to a mobile phone app
> * When user clicks ok on the mobile phone app the login on the desktop 
> continues
>
> This type of authentication is used by banks in Norway, which is very 
> nice as you don't need to manually write a code.
>
>
> On 13 January 2016 at 22:34, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I'm changing browse refresh behavior again.
>
>     I've removed all the extra redirects, so now, you can end up being on
>     the OTP page, but the URL is the one posted to by password page.
>     Refresh
>     page will repost the password, keycloak will see that the current
>     action
>     is not the same, and just ask the flow to put the browser in the right
>     state.  Similarly with required actions.
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

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

From bburke at redhat.com  Thu Jan 14 09:28:36 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 14 Jan 2016 09:28:36 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
Message-ID: <5697B094.9030607@redhat.com>

Is mellon actually sending a logout request to Keycloak?
Do you see any error message on the keycloak server side?  We definitely 
support POST binding for logout.
On 1/14/2016 8:34 AM, Michal Hajas wrote:
> Hi,
>
> I'm trying to run apache + mod_auth_mellon with keycloak as indentity provider.
>
> Steps:
> 1. Install apache and mod_auth_mellon module
> 2. Generate .key, .cert, .xml files with mellon_create_metadata.sh and copy them to /mellon directory
> 3. Download idp_metadata.xml from keycloak/auth/realm/{REALM}/protocol/saml/descriptor and copy it to /mellon directory
> 4. Configure auth_mod_mellon with enclosed file auth_mellon.conf
> 5. Create client in keycloak from xml file generated in step 2 (There must be enabled Sign Documents, Sign Assertions signing and Force POST Binding)
>
> Login works, when I access /auth, mellon redirect me to keycloak and after successful login it redirect me back to protected resource.
>
> Problem:
> I'm not able to logout. When I access localhost/mellon/logout?ReturnTo=/, it doesn't destroy session in keycloak and in apache's error log there is:
> Current identity provider does not support single logout. Destroying local session only.
>
> Only way I was able to log out is change
>
> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="http://localhost:8080/auth/realms/mellon-test/protocol/saml"/>
>
> to
>
> <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="http://localhost:8080/auth/realms/mellon-test/protocol/saml"/>
>
> POST -> Redirect
>
> in idp_metadata.xml and set "Logout Service Redirect Binding URL" to http://localhost/mellon/logout in admin console.
>
> Is it correct or it should work with POST binding too?
>
> Thank you,
> Michal.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Thu Jan 14 09:37:54 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 14 Jan 2016 09:37:54 -0500
Subject: [keycloak-dev] starting on module re-org after Stian's commit
Message-ID: <5697B2C2.9040900@redhat.com>


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


From lkrzyzan at redhat.com  Thu Jan 14 09:38:50 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Thu, 14 Jan 2016 15:38:50 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
In-Reply-To: <CAJgngAcVBC+=AJVRA+cxsHBCdWoQri2UBVz8mL0SkOzwoH9bnw@mail.gmail.com>
References: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
	<16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>
	<CAJgngAcVBC+=AJVRA+cxsHBCdWoQri2UBVz8mL0SkOzwoH9bnw@mail.gmail.com>
Message-ID: <5C18173E-96F8-4AC2-8C2A-ED78FA8B8079@redhat.com>

It?s small feature so I can live without it however 1.9 would not be easy to do because of ugprade to EAP 7 (it?s complicated for us beacuse we depends on other backend java libraries which exists only for eap 6 right now).

in other words it?s not blocker for 1.8.final release for sure but nice to have.

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Jan 14, 2016, at 2:00 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Do you need that for 1.8.Final or is it ok if we add it to 1.9?
> 
> On 14 January 2016 at 13:37, Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
> Appreciated the CR1 !
> 
> here is small improvement for Realm Display Name: https://issues.jboss.org/browse/KEYCLOAK-2313 <https://issues.jboss.org/browse/KEYCLOAK-2313>
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
>> On Jan 13, 2016, at 11:52 AM, Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>> 
>> Realm Display Name - a display name has been added to realms, which makes it possible to set a human readable name to be shown on login screens, emails, etc.
> 
> 

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

From sthorger at redhat.com  Thu Jan 14 09:52:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 15:52:24 +0100
Subject: [keycloak-dev] browser refresh again
In-Reply-To: <5697ADFB.2030204@redhat.com>
References: <5696C302.9010500@redhat.com>
	<CAJgngAeWWsd0sWbehubeM=dD_UeHEKXjBGHgQndXvn-7Xb9T8w@mail.gmail.com>
	<5697ADFB.2030204@redhat.com>
Message-ID: <CAJgngAct5mnvSmymyCmd_O769rePG54WxAhDrE+EP=R6tr6MYw@mail.gmail.com>

We'd probably also need to either use async servlet requests or websockets
as well. Otherwise we could run out of available connections.

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

> To make this work, we would need a way to plug in a REST service that
> could receive input from the mobile device.  It would search through client
> sessions of the user to see which one was waiting for a mobile
> authentication. Then change the state of the client session.  The browser
> session could poll the client session until a flag was set.
>
>
>
> On 1/14/2016 2:53 AM, Stian Thorgersen wrote:
>
> Do we support async authenticators? I'm thinking about something like:
>
> * User logs in on desktop with username/password
> * As two factor auth we send a notification to a mobile phone app
> * When user clicks ok on the mobile phone app the login on the desktop
> continues
>
> This type of authentication is used by banks in Norway, which is very nice
> as you don't need to manually write a code.
>
>
> On 13 January 2016 at 22:34, Bill Burke <bburke at redhat.com> wrote:
>
>> I'm changing browse refresh behavior again.
>>
>> I've removed all the extra redirects, so now, you can end up being on
>> the OTP page, but the URL is the one posted to by password page. Refresh
>> page will repost the password, keycloak will see that the current action
>> is not the same, and just ask the flow to put the browser in the right
>> state.  Similarly with required actions.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/3d662f30/attachment.html 

From sthorger at redhat.com  Thu Jan 14 09:53:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 15:53:12 +0100
Subject: [keycloak-dev] starting on module re-org after Stian's commit
In-Reply-To: <5697B2C2.9040900@redhat.com>
References: <5697B2C2.9040900@redhat.com>
Message-ID: <CAJgngAfjOpJ8JsfNdKE+w_E2SSAOGqdFpgoAgu+4NG=6XCVYVg@mail.gmail.com>

I'm pulling my hair out trying to get this merged.... Testsuite is passing
locally, but fails on Travis.

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

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

From sthorger at redhat.com  Thu Jan 14 09:54:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 14 Jan 2016 15:54:27 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
In-Reply-To: <5C18173E-96F8-4AC2-8C2A-ED78FA8B8079@redhat.com>
References: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
	<16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>
	<CAJgngAcVBC+=AJVRA+cxsHBCdWoQri2UBVz8mL0SkOzwoH9bnw@mail.gmail.com>
	<5C18173E-96F8-4AC2-8C2A-ED78FA8B8079@redhat.com>
Message-ID: <CAJgngAfgdAaaWGw49NCpe=RAE8te5jgjqfo6DCJH1SQO_f_WKg@mail.gmail.com>

As it has a small impact we'll add it to 1.8.0.Final then

On 14 January 2016 at 15:38, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> It?s small feature so I can live without it however 1.9 would not be easy
> to do because of ugprade to EAP 7 (it?s complicated for us beacuse we
> depends on other backend java libraries which exists only for eap 6 right
> now).
>
> in other words it?s not blocker for 1.8.final release for sure but nice to
> have.
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
> On Jan 14, 2016, at 2:00 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
>
> Do you need that for 1.8.Final or is it ok if we add it to 1.9?
>
> On 14 January 2016 at 13:37, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:
>
>> Appreciated the CR1 !
>>
>> here is small improvement for Realm Display Name:
>> https://issues.jboss.org/browse/KEYCLOAK-2313
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> jboss.org Development Team
>>
>> On Jan 13, 2016, at 11:52 AM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>
>>    - *Realm Display Name* - a display name has been added to realms,
>>    which makes it possible to set a human readable name to be shown on login
>>    screens, emails, etc.
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/d9a0e1e7/attachment.html 

From lkrzyzan at redhat.com  Thu Jan 14 09:55:11 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Thu, 14 Jan 2016 15:55:11 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR1 Released
In-Reply-To: <CAJgngAfgdAaaWGw49NCpe=RAE8te5jgjqfo6DCJH1SQO_f_WKg@mail.gmail.com>
References: <CAJgngAc0aKOS-1PtbrQzpu4qgvWzau8s75gY4yyxcdbiHdSXFw@mail.gmail.com>
	<16B84D00-B232-4570-BC3A-6437673929F1@redhat.com>
	<CAJgngAcVBC+=AJVRA+cxsHBCdWoQri2UBVz8mL0SkOzwoH9bnw@mail.gmail.com>
	<5C18173E-96F8-4AC2-8C2A-ED78FA8B8079@redhat.com>
	<CAJgngAfgdAaaWGw49NCpe=RAE8te5jgjqfo6DCJH1SQO_f_WKg@mail.gmail.com>
Message-ID: <2BF3B6EC-CFE4-4C2B-A1B4-7E7541394839@redhat.com>

Yeah it should copy&paste thing :-)

Thank you! Appreciated.

L.

Libor Krzy?anek
jboss.org Development Team

> On Jan 14, 2016, at 3:54 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> As it has a small impact we'll add it to 1.8.0.Final then
> 
> On 14 January 2016 at 15:38, Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
> It?s small feature so I can live without it however 1.9 would not be easy to do because of ugprade to EAP 7 (it?s complicated for us beacuse we depends on other backend java libraries which exists only for eap 6 right now).
> 
> in other words it?s not blocker for 1.8.final release for sure but nice to have.
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
>> On Jan 14, 2016, at 2:00 PM, Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>> 
>> Do you need that for 1.8.Final or is it ok if we add it to 1.9?
>> 
>> On 14 January 2016 at 13:37, Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
>> Appreciated the CR1 !
>> 
>> here is small improvement for Realm Display Name: https://issues.jboss.org/browse/KEYCLOAK-2313 <https://issues.jboss.org/browse/KEYCLOAK-2313>
>> 
>> Thanks,
>> 
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>> 
>>> On Jan 13, 2016, at 11:52 AM, Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>> 
>>> Realm Display Name - a display name has been added to realms, which makes it possible to set a human readable name to be shown on login screens, emails, etc.
>> 
>> 
> 
> 

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

From mhajas at redhat.com  Thu Jan 14 10:21:29 2016
From: mhajas at redhat.com (Michal Hajas)
Date: Thu, 14 Jan 2016 10:21:29 -0500 (EST)
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <5697B094.9030607@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
Message-ID: <1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>

Actually, I am not sure but it looks like not. There is nothing in both keycloak server log and events in admin console. 

Michal.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, January 14, 2016 3:28:36 PM
Subject: Re: [keycloak-dev] mod_auth_mellon

Is mellon actually sending a logout request to Keycloak? 
Do you see any error message on the keycloak server side? We definitely support POST binding for logout. 
On 1/14/2016 8:34 AM, Michal Hajas wrote: 



Hi,

I'm trying to run apache + mod_auth_mellon with keycloak as indentity provider.

Steps:
1. Install apache and mod_auth_mellon module
2. Generate .key, .cert, .xml files with mellon_create_metadata.sh and copy them to /mellon directory
3. Download idp_metadata.xml from keycloak/auth/realm/{REALM}/protocol/saml/descriptor and copy it to /mellon directory
4. Configure auth_mod_mellon with enclosed file auth_mellon.conf
5. Create client in keycloak from xml file generated in step 2 (There must be enabled Sign Documents, Sign Assertions signing and Force POST Binding)

Login works, when I access /auth, mellon redirect me to keycloak and after successful login it redirect me back to protected resource.

Problem:
I'm not able to logout. When I access localhost/mellon/logout?ReturnTo=/, it doesn't destroy session in keycloak and in apache's error log there is:
Current identity provider does not support single logout. Destroying local session only.

Only way I was able to log out is change 

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />

to

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />

POST -> Redirect

in idp_metadata.xml and set "Logout Service Redirect Binding URL" to http://localhost/mellon/logout in admin console. 

Is it correct or it should work with POST binding too?

Thank you,
Michal. 


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

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

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

From bburke at redhat.com  Thu Jan 14 11:01:30 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 14 Jan 2016 11:01:30 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
Message-ID: <5697C65A.2000603@redhat.com>

You can probably see a trace in your browser console?

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

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


From Edgar at info.nl  Thu Jan 14 11:41:24 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 14 Jan 2016 16:41:24 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
	<EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
	<1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
Message-ID: <50F24EC9-4C03-49D1-8910-F561C5ACE613@info.nl>

Regarding the MSAD password history policy not being used when we change the user?s password through Keycloak (using Keycloak?s user account screen where the user is updating his/her own password): is this maybe not caused because in the code the change password request to MSAD is not done ?correctly?? If I look at LDAPIdentityStore#updateADPassword it seems that changing the password involves a replace operation and not a delete + add operation? If I understand the documentation from Microsoft correctly I think you need to do a delete + add operation when the user changes his/her own password and the replace operation only when an admin changes someone else?s password. I think this might explain why the password history policy is not adhered to?

From https://support.microsoft.com/en-us/kb/269190:
"There are two possible ways to modify the unicodePwd attribute. The first is similar to a normal "user change password" operation. In this case, the modify request must contain both a delete and an add operation. The delete operation must contain the current password with quotes around it. The add operation must contain the desired new password with quotes around it.

The second way to modify this attribute is analogous to an administrator resetting a password for a user. In order to do this, the client must bind as a user with sufficient permissions to modify another user's password. This modify request should contain a single replace operation with the new desired password surrounded by quotes. If the client has sufficient permissions, this password become the new password, regardless of what the old password was."



On 14 Jan 2016, at 12:09, Edgar Vonk - Info.nl<http://info.nl> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Ah, sorry about this. I had not added a MSAD User Account Control mapper in our existing AD user federation in Keycloak yet. I thought it might be implicit and that I would not have to define an actual mapper or something. However this fixed the synching of the enabled status between AD and Keycloak. Nice work!




On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl<http://info.nl/> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

On 14 Jan 2016, at 10:28, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

Yeah, the new MSAD mapper added in 1.8 should help you with this. Once the user has in MSAD userAccountControl of 514, he will be marked as disabled in Keycloak. Then when you enable it in Keycloak, it should be propagated to MSAD and user will be put in MSAD to 512. Hope it will work for you.



Thanks but I?m afraid it does not work for us. I am using Keycloak 1.8.0.CR1 now. When I disable the user in MSAD I see the userAccountControl attribute change to 514, however this is not reflected in Keycloak. Not even when I force a resync of all users.

I will see if I can do some debugging and create a JIRA issue for you.

cheers

Edgar


Not sure about password history issue.

Will wait for your feedback. Hope we can sort your issues.

Marek

On 14/01/16 10:01, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi Marek,

Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!

Thanks again for your help.

cheers

Edgar


On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl<http://info.nl/> <Edgar at info.nl<mailto:Edgar at info.nl>> wrote:

Hi Marek,

Thanks very much for your reply. See remarks below.

On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com<mailto:mposolda at redhat.com>> wrote:

On 13/01/16 13:40, Edgar Vonk - Info.nl<http://info.nl/> wrote:
Hi all,

We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.

Our password policies in AD are as follows:
- password complexity (min length + special chars)
- account lock out after 3 attempts
- password history (not allowed to use previous 5 passwords)

Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
- Password complexity policy seems to work fine.
- Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?

Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.


In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.


This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.

We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.

I will create a JIRA issue so that I can send you some more details.


However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.


Ok, will do.


Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
- The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?

Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.

cheers

Edgar


Marek

cheers

Edgar


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






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

From pablo.viciano at borealos.com  Thu Jan 14 14:18:24 2016
From: pablo.viciano at borealos.com (Pablo Viciano)
Date: Thu, 14 Jan 2016 20:18:24 +0100
Subject: [keycloak-dev] Spring Boot with KeyCloak
Message-ID: <etPan.5697f480.4c1b4dd4.10d@MacBook-Pro-de-Pablo.local>

Hello,

I?m integrating an Spring Boot app with KeyCloud and I can?t authenticate with server ?because the web.xml doesn?t read by Spring Boot.

failed verification of token: Token type is incorrect. Expected 'Bearer' but was 'null'

I?ve tested with spring boot adapter (with tomcat 8 adapter) but I can?t specify properties such transport-guarantee (token) and I?ve tested with spring security too (creating extension of?KeycloakWebSecurityConfigurerAdapter)

What?s your solution?

Thanks

--?
Pablo Viciano
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/e1aa2782/attachment.html 

From andipansa at gmail.com  Thu Jan 14 14:34:27 2016
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Thu, 14 Jan 2016 20:34:27 +0100
Subject: [keycloak-dev] Spring Boot with KeyCloak
In-Reply-To: <etPan.5697f480.4c1b4dd4.10d@MacBook-Pro-de-Pablo.local>
References: <etPan.5697f480.4c1b4dd4.10d@MacBook-Pro-de-Pablo.local>
Message-ID: <CAA0ckM4FfYO_qivjB1B_WoCu31VxVAidPx5oGe7-ojP0bqvtzw@mail.gmail.com>

Hi,

take a look at these examples:
https://github.com/agolPL/keycloak-spring-demo

regards,
 Andi

2016-01-14 20:18 GMT+01:00 Pablo Viciano <pablo.viciano at borealos.com>:

> Hello,
>
> I?m integrating an Spring Boot app with KeyCloud and I can?t authenticate
> with server  because the web.xml doesn?t read by Spring Boot.
>
> failed verification of token: Token type is incorrect. Expected 'Bearer'
> but was 'null'
>
> I?ve tested with spring boot adapter (with tomcat 8 adapter) but I can?t
> specify properties such transport-guarantee (token) and I?ve tested with
> spring security too (creating extension of
> KeycloakWebSecurityConfigurerAdapter)
>
> What?s your solution?
>
> Thanks
>
> --
> Pablo Viciano
> Sent with Airmail
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160114/b03200fa/attachment.html 

From mposolda at redhat.com  Thu Jan 14 15:28:47 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 14 Jan 2016 21:28:47 +0100
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
	<EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
	<1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
Message-ID: <569804FF.5080408@redhat.com>

The mapper should be added automatically when you create LDAP Federation 
provider with "Active directory" set as vendor. Also it should be added 
automatically when migrating DB from previous Keycloak version. Strange 
it didn't work for you...

Marek

On 14/01/16 12:09, Edgar Vonk - Info.nl wrote:
> Ah, sorry about this. I had not added a MSAD User Account Control 
> mapper in our existing AD user federation in Keycloak yet. I thought 
> it might be implicit and that I would not have to define an actual 
> mapper or something. However this fixed the synching of the enabled 
> status between AD and Keycloak. Nice work!
>
>
>
>
>> On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl <http://info.nl> 
>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>
>> Hi Marek,
>>
>>> On 14 Jan 2016, at 10:28, Marek Posolda <mposolda at redhat.com 
>>> <mailto:mposolda at redhat.com>> wrote:
>>>
>>> Yeah, the new MSAD mapper added in 1.8 should help you with this. 
>>> Once the user has in MSAD userAccountControl of 514, he will be 
>>> marked as disabled in Keycloak. Then when you enable it in Keycloak, 
>>> it should be propagated to MSAD and user will be put in MSAD to 512. 
>>> Hope it will work for you.
>>>
>>
>>
>> Thanks but I?m afraid it does not work for us. I am using Keycloak 
>> 1.8.0.CR1 now. When I disable the user in MSAD I see 
>> the userAccountControl attribute change to 514, however this is not 
>> reflected in Keycloak. Not even when I force a resync of all users.
>>
>> I will see if I can do some debugging and create a JIRA issue for you.
>>
>> cheers
>>
>> Edgar
>>
>>
>>> Not sure about password history issue.
>>>
>>> Will wait for your feedback. Hope we can sort your issues.
>>>
>>> Marek
>>>
>>> On 14/01/16 10:01, Edgar Vonk - Info.nl <http://info.nl/> wrote:
>>>> Hi Marek,
>>>>
>>>> Sorry, I overlooked you mentioning that you added this in Keycloak 
>>>> 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you 
>>>> know a.s.a.p!
>>>>
>>>> Thanks again for your help.
>>>>
>>>> cheers
>>>>
>>>> Edgar
>>>>
>>>>
>>>>> On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl <http://info.nl/> 
>>>>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>>>>
>>>>> Hi Marek,
>>>>>
>>>>> Thanks very much for your reply. See remarks below.
>>>>>
>>>>>> On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com 
>>>>>> <mailto:mposolda at redhat.com>> wrote:
>>>>>>
>>>>>> On 13/01/16 13:40, Edgar Vonk -Info.nl <http://info.nl/>wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We use Keycloak?s user federation to integrate with a (Windows 
>>>>>>> 2012) Active Directory (AD) server. We want to store all users 
>>>>>>> and groups in AD and also want to manage the password policies 
>>>>>>> from AD so we do not have any password policies in Keycloak set 
>>>>>>> up. We also want to use Keycloak for all user management 
>>>>>>> functionality. We have set up the password policies in AD at the 
>>>>>>> domain level where we connect to from Keycloak.
>>>>>>>
>>>>>>> Our password policies in AD are as follows:
>>>>>>> - password complexity (min length + special chars)
>>>>>>> - account lock out after 3 attempts
>>>>>>> - password history (not allowed to use previous 5 passwords)
>>>>>>>
>>>>>>> Users and admins can set and change passwords in AD from 
>>>>>>> Keycloak fine. However the password policies do not quite do 
>>>>>>> what we want them to:
>>>>>>> - Password complexity policy seems to work fine.
>>>>>>> - Account is indeed locked in AD after three failed attempts. 
>>>>>>> However the ?Unlock users? functionality in Keycloak does not 
>>>>>>> unlock the users in AD. Users can only be unlocked in AD itself 
>>>>>>> it seems. We would like to be able to do this from Keycloak 
>>>>>>> however (and really per user and not for all users in one go). 
>>>>>>> Should this work in Keycloak or is this a new feature request?
>>>>>> Is the fact that user is locked tracked in your MSAD through 
>>>>>> userAccountControl attribute?
>>>>>
>>>>> Yes it is. I see this working when I look at a normal LDAP browser 
>>>>> connected to MSAD. When I disable a user in MSAD I see the 
>>>>> userAccountControl attribute change from 512 to 514.
>>>>>
>>>>>
>>>>>> In the Keycloak 1.8 I've added the MSAD UserAccountControl 
>>>>>> mapper, which allows to integrate the MSAD account state more 
>>>>>> tightly into Keycloak state. For example enable user in Keycloak 
>>>>>> admin console will remove the ACCOUNTDISABLE flag from 
>>>>>> userAccountControl value in MSAD as well and hence enable this 
>>>>>> user in MSAD too.
>>>>>
>>>>>
>>>>> This sounds good, however unfortunately we do not see this 
>>>>> happening.  When I disable the user in Keycloak the 
>>>>> userAccountControl attribute does not change at all so the 
>>>>> propagation to MSAD does not seem to work here.
>>>>>
>>>>> We have indeed configured the user federation in Keycloak to 
>>>>> WRITABLE LDAP and all other user attributes (like user name etc) 
>>>>> are propagated from Keycloak to MSAD just fine.
>>>>>
>>>>> I will create a JIRA issue so that I can send you some more details.
>>>>>
>>>>>>
>>>>>> However support for lock/unlock is not included in the mapper 
>>>>>> though. So feel free to create JIRA.
>>>>>>
>>>>>
>>>>> Ok, will do.
>>>>>
>>>>>
>>>>>> Until it's implemented, you can possibly use adminEvent listener 
>>>>>> (There is admin event triggered when you click "Unlock user" in 
>>>>>> Keycloak UI. So you can listen to this event and propagate the 
>>>>>> call to MSAD once you successfully enable it)
>>>>>>> - The password history policy does not seem to work at all. 
>>>>>>> Users can currently set their password to a previous password 
>>>>>>> without a problem. Does anyone have an idea why this policy in 
>>>>>>> AD does not work from Keycloak?
>>>>>> No idea. Keycloak is just using Directory API for change 
>>>>>> password. It's strange the MSAD allows to change password through 
>>>>>> this API when it breaks password history policy. Are you sure you 
>>>>>> have WRITABLE LDAP and password update from Keycloak is 
>>>>>> propagated to MSAD?
>>>>>
>>>>> Yes, we have writable ldap configured and indeed the password is 
>>>>> propagated to MSAD. Maybe it is related to the issue we see with 
>>>>> the userAccountControl attribute.
>>>>>
>>>>> cheers
>>>>>
>>>>> Edgar
>>>>>
>>>>>>
>>>>>> Marek
>>>>>>>
>>>>>>> cheers
>>>>>>>
>>>>>>> Edgar
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>
>

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

From mposolda at redhat.com  Thu Jan 14 16:01:44 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 14 Jan 2016 22:01:44 +0100
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <50F24EC9-4C03-49D1-8910-F561C5ACE613@info.nl>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
	<EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
	<1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
	<50F24EC9-4C03-49D1-8910-F561C5ACE613@info.nl>
Message-ID: <56980CB8.6010502@redhat.com>

This makes things a bit tricky. Because:
1) Our current model SPI and federation SPI for update credential 
doesn't differ between the case when user is updating his credential or 
when admin is resetting the credential of user.
2) Also in LDAP both operations are executed under "admin" connection 
(user own connection is used just to verify his password).
3) Finally there is no old password available in the 
UserModel.updateCredential operation

Feel free to create JIRA, but hard to promise when we will be able to 
look into it (I am on holiday next week and then we have feature freeze 
and won't be able to add new stuff like this).

So if you really want it, you may need to send PR by yourself. The 
implementation may require more changes. Some pointers how I would do it 
(we may need ACK from other team members to confirm as we are close to 
"feature freeze" phase right now until we start on keycloak 2.x 
development):

1) Change UserCredentialModel and put new fields "oldValue" with the old 
password. Also maybe the boolean field "isAdminCall", which will be true 
if admin is restarting the password (in this case the LDAP operation can 
be same like already and use "replace" operation) or if user himself is 
restarting the password. Maybe the "isAdminCall" field is not necessary 
as with admin call, the "oldValue" simply won't be available (when user 
himself is restarting the password in account management, user is 
required to set password and AccountService knows the old password value)

Other possibility is to introduce the context map ( Map<String, String> 
contextData ) on UserCredentialModel, which is more flexible. At the 
same time the "device" field can be removed from UserCredentialModel IMO 
as it doesn't seem to be used from anywhere right now.

2) Change the LDAPIdentityStore implementation to differ between the two 
cases you described

Marek

On 14/01/16 17:41, Edgar Vonk - Info.nl wrote:
> Regarding the MSAD password history policy not being used when we 
> change the user?s password through Keycloak (using Keycloak?s user 
> account screen where the user is updating his/her own password): is 
> this maybe not caused because in the code the change password request 
> to MSAD is not done ?correctly?? If I look at 
> LDAPIdentityStore#updateADPassword it seems that changing the password 
> involves a replace operation and not a delete + add operation? If I 
> understand the documentation from Microsoft correctly I think you need 
> to do a delete + add operation when the user changes his/her own 
> password and the replace operation only when an admin changes someone 
> else?s password. I think this might explain why the password history 
> policy is not adhered to?
>
> From https://support.microsoft.com/en-us/kb/269190: 
> <https://support.microsoft.com/en-us/kb/269190:>
> "There are two possible ways to modify the unicodePwd attribute. The 
> first is similar to a normal "user change password" operation. In this 
> case, the modify request must contain both a delete and an add 
> operation. The delete operation must contain the current password with 
> quotes around it. The add operation must contain the desired new 
> password with quotes around it.
>
> The second way to modify this attribute is analogous to an 
> administrator resetting a password for a user. In order to do this, 
> the client must bind as a user with sufficient permissions to 
> modify another user's password. This modify request should contain a 
> single replace operation with the new desired password surrounded by 
> quotes. If the client has sufficient permissions, this password become 
> the new password, regardless of what the old password was."
>
>
>
>> On 14 Jan 2016, at 12:09, Edgar Vonk - Info.nl <http://info.nl> 
>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>
>> Ah, sorry about this. I had not added a MSAD User Account Control 
>> mapper in our existing AD user federation in Keycloak yet. I thought 
>> it might be implicit and that I would not have to define an actual 
>> mapper or something. However this fixed the synching of the enabled 
>> status between AD and Keycloak. Nice work!
>>
>>
>>
>>
>>> On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl <http://info.nl/> 
>>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>>
>>> Hi Marek,
>>>
>>>> On 14 Jan 2016, at 10:28, Marek Posolda <mposolda at redhat.com 
>>>> <mailto:mposolda at redhat.com>> wrote:
>>>>
>>>> Yeah, the new MSAD mapper added in 1.8 should help you with this. 
>>>> Once the user has in MSAD userAccountControl of 514, he will be 
>>>> marked as disabled in Keycloak. Then when you enable it in 
>>>> Keycloak, it should be propagated to MSAD and user will be put in 
>>>> MSAD to 512. Hope it will work for you.
>>>>
>>>
>>>
>>> Thanks but I?m afraid it does not work for us. I am using Keycloak 
>>> 1.8.0.CR1 now. When I disable the user in MSAD I see 
>>> the userAccountControl attribute change to 514, however this is not 
>>> reflected in Keycloak. Not even when I force a resync of all users.
>>>
>>> I will see if I can do some debugging and create a JIRA issue for you.
>>>
>>> cheers
>>>
>>> Edgar
>>>
>>>
>>>> Not sure about password history issue.
>>>>
>>>> Will wait for your feedback. Hope we can sort your issues.
>>>>
>>>> Marek
>>>>
>>>> On 14/01/16 10:01, Edgar Vonk - Info.nl <http://info.nl/> wrote:
>>>>> Hi Marek,
>>>>>
>>>>> Sorry, I overlooked you mentioning that you added this in Keycloak 
>>>>> 1.8 while we are still on Keycloak 1.7.. I will upgrade and let 
>>>>> you know a.s.a.p!
>>>>>
>>>>> Thanks again for your help.
>>>>>
>>>>> cheers
>>>>>
>>>>> Edgar
>>>>>
>>>>>
>>>>>> On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl <http://info.nl/> 
>>>>>> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>>>>>
>>>>>> Hi Marek,
>>>>>>
>>>>>> Thanks very much for your reply. See remarks below.
>>>>>>
>>>>>>> On 13 Jan 2016, at 22:53, Marek Posolda <mposolda at redhat.com 
>>>>>>> <mailto:mposolda at redhat.com>> wrote:
>>>>>>>
>>>>>>> On 13/01/16 13:40, Edgar Vonk -Info.nl <http://info.nl/>wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> We use Keycloak?s user federation to integrate with a (Windows 
>>>>>>>> 2012) Active Directory (AD) server. We want to store all users 
>>>>>>>> and groups in AD and also want to manage the password policies 
>>>>>>>> from AD so we do not have any password policies in Keycloak set 
>>>>>>>> up. We also want to use Keycloak for all user management 
>>>>>>>> functionality. We have set up the password policies in AD at 
>>>>>>>> the domain level where we connect to from Keycloak.
>>>>>>>>
>>>>>>>> Our password policies in AD are as follows:
>>>>>>>> - password complexity (min length + special chars)
>>>>>>>> - account lock out after 3 attempts
>>>>>>>> - password history (not allowed to use previous 5 passwords)
>>>>>>>>
>>>>>>>> Users and admins can set and change passwords in AD from 
>>>>>>>> Keycloak fine. However the password policies do not quite do 
>>>>>>>> what we want them to:
>>>>>>>> - Password complexity policy seems to work fine.
>>>>>>>> - Account is indeed locked in AD after three failed attempts. 
>>>>>>>> However the ?Unlock users? functionality in Keycloak does not 
>>>>>>>> unlock the users in AD. Users can only be unlocked in AD itself 
>>>>>>>> it seems. We would like to be able to do this from Keycloak 
>>>>>>>> however (and really per user and not for all users in one go). 
>>>>>>>> Should this work in Keycloak or is this a new feature request?
>>>>>>> Is the fact that user is locked tracked in your MSAD through 
>>>>>>> userAccountControl attribute?
>>>>>>
>>>>>> Yes it is. I see this working when I look at a normal LDAP 
>>>>>> browser connected to MSAD. When I disable a user in MSAD I see 
>>>>>> the userAccountControl attribute change from 512 to 514.
>>>>>>
>>>>>>
>>>>>>> In the Keycloak 1.8 I've added the MSAD UserAccountControl 
>>>>>>> mapper, which allows to integrate the MSAD account state more 
>>>>>>> tightly into Keycloak state. For example enable user in Keycloak 
>>>>>>> admin console will remove the ACCOUNTDISABLE flag from 
>>>>>>> userAccountControl value in MSAD as well and hence enable this 
>>>>>>> user in MSAD too.
>>>>>>
>>>>>>
>>>>>> This sounds good, however unfortunately we do not see this 
>>>>>> happening.  When I disable the user in Keycloak the 
>>>>>> userAccountControl attribute does not change at all so the 
>>>>>> propagation to MSAD does not seem to work here.
>>>>>>
>>>>>> We have indeed configured the user federation in Keycloak to 
>>>>>> WRITABLE LDAP and all other user attributes (like user name etc) 
>>>>>> are propagated from Keycloak to MSAD just fine.
>>>>>>
>>>>>> I will create a JIRA issue so that I can send you some more details.
>>>>>>
>>>>>>>
>>>>>>> However support for lock/unlock is not included in the mapper 
>>>>>>> though. So feel free to create JIRA.
>>>>>>>
>>>>>>
>>>>>> Ok, will do.
>>>>>>
>>>>>>
>>>>>>> Until it's implemented, you can possibly use adminEvent listener 
>>>>>>> (There is admin event triggered when you click "Unlock user" in 
>>>>>>> Keycloak UI. So you can listen to this event and propagate the 
>>>>>>> call to MSAD once you successfully enable it)
>>>>>>>> - The password history policy does not seem to work at all. 
>>>>>>>> Users can currently set their password to a previous password 
>>>>>>>> without a problem. Does anyone have an idea why this policy in 
>>>>>>>> AD does not work from Keycloak?
>>>>>>> No idea. Keycloak is just using Directory API for change 
>>>>>>> password. It's strange the MSAD allows to change password 
>>>>>>> through this API when it breaks password history policy. Are you 
>>>>>>> sure you have WRITABLE LDAP and password update from Keycloak is 
>>>>>>> propagated to MSAD?
>>>>>>
>>>>>> Yes, we have writable ldap configured and indeed the password is 
>>>>>> propagated to MSAD. Maybe it is related to the issue we see with 
>>>>>> the userAccountControl attribute.
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>> Edgar
>>>>>>
>>>>>>>
>>>>>>> Marek
>>>>>>>>
>>>>>>>> cheers
>>>>>>>>
>>>>>>>> Edgar
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>
>>
>

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

From alexander.schwartz at gmx.net  Thu Jan 14 23:27:05 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Fri, 15 Jan 2016 05:27:05 +0100
Subject: [keycloak-dev] Calling JavaScript logout on a URL with a fragment
 redirects to a URL with URL still encoded
Message-ID: <56987519.10002@gmx.net>

Hello,

using the Keycloak JavaScript adapter I found that the logout from a URL 
with a fragment (http://localhost:9090/ajax/index.html#xxxxx) leads to a 
redirect with a rewritten fragment 
(http://localhost:9090/ajax/index.html?redirect_fragment=xxxxx)

As my application JavaScript single-page app is parsing the fragment, 
this is an issue for me.

I created https://issues.jboss.org/browse/KEYCLOAK-2323 together with a 
pull request https://github.com/keycloak/keycloak/pull/2033

This includes a fix that worked for me based on both Keycloak 1.7.0 and 
1.8.CR1.

Please let me know if you would like me to add/change more code, and if 
this is the right code to change.

I'm also missing a place where to put some tests for this. Where would I 
find the test suite for this?

Thanks,
Alexander.

-- 
Alexander Schwartz (alexander.schwartz at gmx.net)
http://www.ahus1.de


From alexander.schwartz at gmx.net  Thu Jan 14 23:35:56 2016
From: alexander.schwartz at gmx.net (Alexander Schwartz)
Date: Fri, 15 Jan 2016 05:35:56 +0100
Subject: [keycloak-dev] Calling JavaScript keycloak.init() with
 token/refresh token leads to broken keycloak.update()
Message-ID: <5698772C.7070505@gmx.net>

Hello developers,

I am pre-initializing JavaScript keycloak with tokens like this:

keycloak.init({
         token: getSetting('token'),
         refreshToken: getSetting('refreshToken'),
         idToken: getSetting('idToken')
     })

I found that the keyclock.update() didn't update any tokens, as the 
property timeSkew was left uninitialized.

I've created https://issues.jboss.org/browse/KEYCLOAK-2322 and a Pull 
Request https://github.com/keycloak/keycloak/pull/2032 that worked for 
me both in 1.7.0 and 1.8.CR1

timeSkew can now also be passed as a parameter to the init options with 
a default of 0.

As timeSkew needs to be set every time setToken is being called, I 
wonder if I should refactor the code to add a timeSkew to the signature 
of setToken(). Should this be done as part of this ticket, in in another 
ticket?

I'm also missing a place where to put some tests for this. Where would I 
find the test suite for this?

Thanks, Alexander.


-- 
Alexander Schwartz (alexander.schwartz at gmx.net)
http://www.ahus1.de


From addam.martin at web-presence-in-china.com  Fri Jan 15 02:35:50 2016
From: addam.martin at web-presence-in-china.com (Addam Martin)
Date: Fri, 15 Jan 2016 07:35:50 +0000
Subject: [keycloak-dev] NodeJS get token directly
Message-ID: <1452843349679.29253@web-presence-in-china.com>

Hi,
I am working on a NodeJS Express application using bearer only authentication with Keycloak. It contains a REST API for use by other applications.


Up until now I have been using the Keycloak Connect middleware to secure my POST method, which is a great solution for basic authentication as is almost completely takes it out of the hands of the developer. However, now I need to be able to get a token directly and keep it for a given duration, say 15 minutes, for use by multiple connecting clients.


This token will be used by multiple applications connecting via this REST API, possibly in very quick succession. It needs to be possible to verify that the token is still valid synchronously on the fly, renewing it if required. Is there anything perhaps in the "keycloak-auth-utils" npm package which can get used to handle this? Or any other existing libraries?


Thanks,

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

From thomas.darimont at googlemail.com  Fri Jan 15 03:45:08 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 15 Jan 2016 09:45:08 +0100
Subject: [keycloak-dev] Add resource type information to events handled by
	EventListenerProvider?
Message-ID: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>

Hi,

currently it is hard to figure out what actually happend when processing
events, since there
is no explicit information about the actual underlying resource in an
event. Currently one has to
parse the resourcePath of an AdminEvent to deduce the involved resource.

E.g. Creating a user yields:

AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472

Assigning a client role to a user yields:

AdminEvent#getOperationType(): CREATE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e

Removing a client role from a user yields:
AdminEvent#getOperationType(): DELETE
AdminEvent#getResourcePath():
users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e

It would be helpful if one had more information about the actual use case.

How about introducing an AdminEvent#getResourceType() method that returns
an enum value for the
resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.

This would make it easier detect what actually happend without having to
parse the resourcePath.

What do you think?

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

From sthorger at redhat.com  Fri Jan 15 03:55:37 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 15 Jan 2016 09:55:37 +0100
Subject: [keycloak-dev] Add resource type information to events handled
	by EventListenerProvider?
In-Reply-To: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
References: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
Message-ID: <CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>

Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
don't have to have the logic spread around.

On 15 January 2016 at 09:45, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hi,
>
> currently it is hard to figure out what actually happend when processing
> events, since there
> is no explicit information about the actual underlying resource in an
> event. Currently one has to
> parse the resourcePath of an AdminEvent to deduce the involved resource.
>
> E.g. Creating a user yields:
>
> AdminEvent#getOperationType(): CREATE
> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>
> Assigning a client role to a user yields:
>
> AdminEvent#getOperationType(): CREATE
> AdminEvent#getResourcePath():
> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
> Removing a client role from a user yields:
> AdminEvent#getOperationType(): DELETE
> AdminEvent#getResourcePath():
> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
> It would be helpful if one had more information about the actual use case.
>
> How about introducing an AdminEvent#getResourceType() method that returns
> an enum value for the
> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>
> This would make it easier detect what actually happend without having to
> parse the resourcePath.
>
> What do you think?
>
> Cheers,
> Thomas
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160115/f108be1c/attachment.html 

From mhajas at redhat.com  Fri Jan 15 03:57:46 2016
From: mhajas at redhat.com (Michal Hajas)
Date: Fri, 15 Jan 2016 03:57:46 -0500 (EST)
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <5697C65A.2000603@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
Message-ID: <1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>

I can't see anything even in console log.

I enclosed whole proccess of login and logout in network tab.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Michal Hajas" <mhajas at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, January 14, 2016 5:01:30 PM
Subject: Re: [keycloak-dev] mod_auth_mellon

You can probably see a trace in your browser console?

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: screenshot.png
Type: image/png
Size: 48059 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160115/b2cb879b/attachment-0001.png 

From thomas.darimont at googlemail.com  Fri Jan 15 04:06:41 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 15 Jan 2016 10:06:41 +0100
Subject: [keycloak-dev] Add resource type information to events handled
	by EventListenerProvider?
In-Reply-To: <CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>
References: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
	<CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>
Message-ID: <CAK-7U1i7+qpwdafHtBfuyUvLNGGUwS9hhYE7K5W0rXfCHas7fA@mail.gmail.com>

Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324

Cheers,
Thomas

2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
> don't have to have the logic spread around.
>
> On 15 January 2016 at 09:45, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hi,
>>
>> currently it is hard to figure out what actually happend when processing
>> events, since there
>> is no explicit information about the actual underlying resource in an
>> event. Currently one has to
>> parse the resourcePath of an AdminEvent to deduce the involved resource.
>>
>> E.g. Creating a user yields:
>>
>> AdminEvent#getOperationType(): CREATE
>> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>>
>> Assigning a client role to a user yields:
>>
>> AdminEvent#getOperationType(): CREATE
>> AdminEvent#getResourcePath():
>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>
>> Removing a client role from a user yields:
>> AdminEvent#getOperationType(): DELETE
>> AdminEvent#getResourcePath():
>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>
>> It would be helpful if one had more information about the actual use case.
>>
>> How about introducing an AdminEvent#getResourceType() method that returns
>> an enum value for the
>> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
>> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>>
>> This would make it easier detect what actually happend without having to
>> parse the resourcePath.
>>
>> What do you think?
>>
>> Cheers,
>> Thomas
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160115/eb3a6c01/attachment.html 

From sthorger at redhat.com  Fri Jan 15 04:47:49 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 15 Jan 2016 10:47:49 +0100
Subject: [keycloak-dev] Add resource type information to events handled
	by EventListenerProvider?
In-Reply-To: <CAK-7U1i7+qpwdafHtBfuyUvLNGGUwS9hhYE7K5W0rXfCHas7fA@mail.gmail.com>
References: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
	<CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>
	<CAK-7U1i7+qpwdafHtBfuyUvLNGGUwS9hhYE7K5W0rXfCHas7fA@mail.gmail.com>
Message-ID: <CAJgngAdBykW6W-PgR9gX0e1x-tUmckRLby4G=h6kPT72_bLzyw@mail.gmail.com>

For the record we can't prioritize it at the moment

On 15 January 2016 at 10:06, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
>
> Cheers,
> Thomas
>
> 2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
>> don't have to have the logic spread around.
>>
>> On 15 January 2016 at 09:45, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> currently it is hard to figure out what actually happend when processing
>>> events, since there
>>> is no explicit information about the actual underlying resource in an
>>> event. Currently one has to
>>> parse the resourcePath of an AdminEvent to deduce the involved resource.
>>>
>>> E.g. Creating a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>>>
>>> Assigning a client role to a user yields:
>>>
>>> AdminEvent#getOperationType(): CREATE
>>> AdminEvent#getResourcePath():
>>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> Removing a client role from a user yields:
>>> AdminEvent#getOperationType(): DELETE
>>> AdminEvent#getResourcePath():
>>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>
>>> It would be helpful if one had more information about the actual use
>>> case.
>>>
>>> How about introducing an AdminEvent#getResourceType() method that
>>> returns an enum value for the
>>> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
>>> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>>>
>>> This would make it easier detect what actually happend without having to
>>> parse the resourcePath.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160115/a2a48c10/attachment.html 

From thomas.darimont at googlemail.com  Fri Jan 15 07:47:25 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 15 Jan 2016 13:47:25 +0100
Subject: [keycloak-dev] Add resource type information to events handled
	by EventListenerProvider?
In-Reply-To: <CAJgngAdBykW6W-PgR9gX0e1x-tUmckRLby4G=h6kPT72_bLzyw@mail.gmail.com>
References: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
	<CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>
	<CAK-7U1i7+qpwdafHtBfuyUvLNGGUwS9hhYE7K5W0rXfCHas7fA@mail.gmail.com>
	<CAJgngAdBykW6W-PgR9gX0e1x-tUmckRLby4G=h6kPT72_bLzyw@mail.gmail.com>
Message-ID: <CAK-7U1jJU4GV6JgGKOTGHWVAhs9L=CzNW65jKdaawewBLEpBYg@mail.gmail.com>

Ok, I can give it a spin this evening

Cheers,
Thomas

2016-01-15 10:47 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> For the record we can't prioritize it at the moment
>
> On 15 January 2016 at 10:06, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
>>
>> Cheers,
>> Thomas
>>
>> 2016-01-15 9:55 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> Sounds good to me. The AdminEventBuilder.resourcePath could set it so we
>>> don't have to have the logic spread around.
>>>
>>> On 15 January 2016 at 09:45, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> currently it is hard to figure out what actually happend when
>>>> processing events, since there
>>>> is no explicit information about the actual underlying resource in an
>>>> event. Currently one has to
>>>> parse the resourcePath of an AdminEvent to deduce the involved resource.
>>>>
>>>> E.g. Creating a user yields:
>>>>
>>>> AdminEvent#getOperationType(): CREATE
>>>> AdminEvent#getResourcePath(): users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>>>>
>>>> Assigning a client role to a user yields:
>>>>
>>>> AdminEvent#getOperationType(): CREATE
>>>> AdminEvent#getResourcePath():
>>>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>>
>>>> Removing a client role from a user yields:
>>>> AdminEvent#getOperationType(): DELETE
>>>> AdminEvent#getResourcePath():
>>>> users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>>>>
>>>> It would be helpful if one had more information about the actual use
>>>> case.
>>>>
>>>> How about introducing an AdminEvent#getResourceType() method that
>>>> returns an enum value for the
>>>> resource in question, e.g. USER, ROLE, CLIENT, REALM, GROUP,
>>>> ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT, GROUP_ASSIGNMENT, etc.
>>>>
>>>> This would make it easier detect what actually happend without having
>>>> to parse the resourcePath.
>>>>
>>>> What do you think?
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160115/3a1f65b2/attachment.html 

From bburke at redhat.com  Fri Jan 15 09:02:17 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 09:02:17 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
	<1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
Message-ID: <5698FBE9.10406@redhat.com>

Looks like its on the auth mellon side as I don't see any request after:
/mellon/logout?ReturnTo=/



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

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

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

From bburke at redhat.com  Fri Jan 15 09:02:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 09:02:49 -0500
Subject: [keycloak-dev] Add resource type information to events handled
 by EventListenerProvider?
In-Reply-To: <CAK-7U1jJU4GV6JgGKOTGHWVAhs9L=CzNW65jKdaawewBLEpBYg@mail.gmail.com>
References: <CAK-7U1g_zEwBDfTwJvyTaSkBKGWPyRy_rubHnk=Jm-XJyDqA5Q@mail.gmail.com>
	<CAJgngAeB3LGETu4s=ajqYSSc1vk0SwGHAqY3_hsSbthuabMs9g@mail.gmail.com>
	<CAK-7U1i7+qpwdafHtBfuyUvLNGGUwS9hhYE7K5W0rXfCHas7fA@mail.gmail.com>
	<CAJgngAdBykW6W-PgR9gX0e1x-tUmckRLby4G=h6kPT72_bLzyw@mail.gmail.com>
	<CAK-7U1jJU4GV6JgGKOTGHWVAhs9L=CzNW65jKdaawewBLEpBYg@mail.gmail.com>
Message-ID: <5698FC09.5070502@redhat.com>

You've done some good work Thomas.  Thanks for your contributions!

On 1/15/2016 7:47 AM, Thomas Darimont wrote:
> Ok, I can give it a spin this evening
>
> Cheers,
> Thomas
>
> 2016-01-15 10:47 GMT+01:00 Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>>:
>
>     For the record we can't prioritize it at the moment
>
>     On 15 January 2016 at 10:06, Thomas Darimont
>     <thomas.darimont at googlemail.com
>     <mailto:thomas.darimont at googlemail.com>> wrote:
>
>         Okay, I filed: https://issues.jboss.org/browse/KEYCLOAK-2324
>
>         Cheers,
>         Thomas
>
>         2016-01-15 9:55 GMT+01:00 Stian Thorgersen
>         <sthorger at redhat.com <mailto:sthorger at redhat.com>>:
>
>             Sounds good to me. The AdminEventBuilder.resourcePath
>             could set it so we don't have to have the logic spread around.
>
>             On 15 January 2016 at 09:45, Thomas Darimont
>             <thomas.darimont at googlemail.com
>             <mailto:thomas.darimont at googlemail.com>> wrote:
>
>                 Hi,
>
>                 currently it is hard to figure out what actually
>                 happend when processing events, since there
>                 is no explicit information about the actual underlying
>                 resource in an event. Currently one has to
>                 parse the resourcePath of an AdminEvent to deduce the
>                 involved resource.
>
>                 E.g. Creating a user yields:
>
>                 AdminEvent#getOperationType(): CREATE
>                 AdminEvent#getResourcePath():
>                 users/edbabe12-528a-42cc-90cc-bbc66ebaa472
>
>                 Assigning a client role to a user yields:
>
>                 AdminEvent#getOperationType(): CREATE
>                 AdminEvent#getResourcePath():
>                 users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
>                 Removing a client role from a user yields:
>                 AdminEvent#getOperationType(): DELETE
>                 AdminEvent#getResourcePath():
>                 users/edbabe12-528a-42cc-90cc-bbc66ebaa472/role-mappings/clients/7f3af5dc-b68b-4bda-b5a3-89b6d827fb1e
>
>                 It would be helpful if one had more information about
>                 the actual use case.
>
>                 How about introducing an AdminEvent#getResourceType()
>                 method that returns an enum value for the
>                 resource in question, e.g. USER, ROLE, CLIENT, REALM,
>                 GROUP, ROLE_ASSIGNMENT, CLIENT_ROLE_ASSIGNMENT,
>                 GROUP_ASSIGNMENT, etc.
>
>                 This would make it easier detect what actually happend
>                 without having to parse the resourcePath.
>
>                 What do you think?
>
>                 Cheers,
>                 Thomas
>
>
>                 _______________________________________________
>                 keycloak-dev mailing list
>                 keycloak-dev at lists.jboss.org
>                 <mailto:keycloak-dev at lists.jboss.org>
>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Fri Jan 15 12:23:01 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 12:23:01 -0500
Subject: [keycloak-dev] WARNING, I'm re-orging modules/src code!
Message-ID: <56992AF5.4090803@redhat.com>

I'll be moving SPIs under a new keycloak-server-spi module.  Beware!

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


From jdennis at redhat.com  Fri Jan 15 12:36:09 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Jan 2016 12:36:09 -0500
Subject: [keycloak-dev] unsupported media type error
Message-ID: <56992E09.6090906@redhat.com>

I'm trying to test Openstack ECP with Keycloak. When Openstack posts the 
SAML AuthnRequest wrapped in SOAP to the 
/auth/realms/master/protocol/saml endpoint keycloak responds with an 
HTTP 415 unsupported media type error. The HTTP Content-Type in the post 
is text/xml. What are you expecting?

This is with the 1.8.0.CR1 version of keycloak.

Thanks!
-- 
John

From psilva at redhat.com  Fri Jan 15 12:52:23 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 15 Jan 2016 12:52:23 -0500 (EST)
Subject: [keycloak-dev] unsupported media type error
In-Reply-To: <56992E09.6090906@redhat.com>
References: <56992E09.6090906@redhat.com>
Message-ID: <1928191283.10412304.1452880343366.JavaMail.zimbra@redhat.com>

Hey John,

    KC expects a POST using the "application/soap+xml" media type. Maybe we should also provide a text/xml for SOAP 1.1 clients.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, January 15, 2016 3:36:09 PM
Subject: [keycloak-dev] unsupported media type error

I'm trying to test Openstack ECP with Keycloak. When Openstack posts the 
SAML AuthnRequest wrapped in SOAP to the 
/auth/realms/master/protocol/saml endpoint keycloak responds with an 
HTTP 415 unsupported media type error. The HTTP Content-Type in the post 
is text/xml. What are you expecting?

This is with the 1.8.0.CR1 version of keycloak.

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

From bburke at redhat.com  Fri Jan 15 14:19:45 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 14:19:45 -0500
Subject: [keycloak-dev] patching effected by module re-org?
Message-ID: <56994651.40508@redhat.com>

Do we need to think about how patching will work in EAP?  If we move to 
a more coarse grain module system, then the modules we patch might be 
quite large.  We fine with that?

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


From ssilvert at redhat.com  Fri Jan 15 16:12:36 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 15 Jan 2016 16:12:36 -0500
Subject: [keycloak-dev] i18n for Logging
Message-ID: <569960C4.4060203@redhat.com>

I've completed a first stab at this using the JBoss logging tools. Once 
merged we will have the ability to do i18n/l10n on our log messages and 
also use message numbers.

Here is the commit to show you how it turns out converting the log 
messages in KeycloakApplication:
https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1

So, now a message coming from the KeycloakApplication class in the 
services module looks like this:

15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread Pool 
-- 50)*KC-SERVICES0001*: Loading config from 
c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json

We need to decide how we want to structure this.  In WildFly, we 
typically have one logger per maven module.  If you want to have one 
logger per package then you would need to create a new interface in each 
package, which gets hairy.

I do suggest that we prefix all of our messages with "KC-" or something 
else that is unique across products.  Also, we should standardize the 
"padding" for the message numbers.

Another possibility is to have all keycloak messages start with 
"KEYCLOAK".  This would mean that we would need for each module to 
reserve a number range.  There are annotations to enforce this if we 
want to go that route.  The downside is that somewhere we need to 
maintain a registry.  I think WildFly did this but eventually abandoned 
it.  Notice that WildFly messages are like "WFLYUT" for Undertow or 
"WFLYJSF" for JSF.

BTW, localization works nicely.  Just add a bundle for a new language.  
The tool even creates a skeleton properties file for you.

If you want more details on the i18n framework, see 
https://developer.jboss.org/wiki/JBossLoggingTooling.

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

From bburke at redhat.com  Fri Jan 15 17:14:33 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 17:14:33 -0500
Subject: [keycloak-dev] direct grant cookies, and SSO
Message-ID: <56996F49.6020208@redhat.com>

I was thinking that using direct grant from Browser Javascript would 
work with SSO if direct grant created and returned an SSO cookie and 
also checked to see if an SSO cookie was set.  This way all the people 
wanting to completely bypass our login screens can do that. Why they 
would want to, I don't know.  We maybe should extend the direct grant 
protocol to tell the client when required actions must be filled out 
before authentication, stuff like that.

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


From jdennis at redhat.com  Fri Jan 15 19:00:31 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 15 Jan 2016 19:00:31 -0500
Subject: [keycloak-dev] unsupported media type error
In-Reply-To: <1928191283.10412304.1452880343366.JavaMail.zimbra@redhat.com>
References: <56992E09.6090906@redhat.com>
	<1928191283.10412304.1452880343366.JavaMail.zimbra@redhat.com>
Message-ID: <5699881F.4060301@redhat.com>

On 01/15/2016 12:52 PM, Pedro Igor Silva wrote:
> Hey John,
>
>      KC expects a POST using the "application/soap+xml" media type. Maybe we should also provide a text/xml for SOAP 1.1 clients.
>
> Regards.
> Pedro Igor

I asked Pedro to wait and not change anything in Keycloak until I 
checked the specs. Based on my reading of the specs the media type (i.e. 
HTTP Content-Type header) should be

   text/xml

The media type 'application/soap+xml' is reserved for SOAP 1.2. RFC 3902 
"The "application/soap+xml" media type" states:

   The "application/soap+xml" media type explicitly identifies SOAP 1.2
   message envelopes that have been serialised with XML 1.0; message
   envelopes with a different SOAP namespace version or using another
   XML serialisation MUST NOT use it.

The "SAML V2.0 Enhanced Client or Proxy Profile Version 2.0" (current as 
of August 2013) states that SAML messages are wrapped in SOAP 1.1.

The "Simple Object Access Protocol (SOAP) 1.1" spec 
(https://www.w3.org/TR/2000/NOTE-SOAP-20000508/) in Section 6 "Using 
SOAP in HTTP" states:

    HTTP applications MUST use the media type "text/xml" according to
    RFC 2376 when including SOAP entity bodies in HTTP messages.

Therefore since ECP requires SOAP 1.1 (not SOAP 1.2) and SOAP 1.1 
requires 'text/xml' and because RFC 3902 reserves 'application/soap+xml' 
for SOAP 1.2 the media type should be 'text/xml' not 'application/soap+xml'.

I am partly to blame for the confusion, Pedro and I used an ECP test 
program I wrote and it erroneously used the incorrect 
'application/soap+xml' media type and I think Pedro adjusted Keycloak to 
match based on that.


> ----- Original Message -----
> From: "John Dennis" <jdennis at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, January 15, 2016 3:36:09 PM
> Subject: [keycloak-dev] unsupported media type error
>
> I'm trying to test Openstack ECP with Keycloak. When Openstack posts the
> SAML AuthnRequest wrapped in SOAP to the
> /auth/realms/master/protocol/saml endpoint keycloak responds with an
> HTTP 415 unsupported media type error. The HTTP Content-Type in the post
> is text/xml. What are you expecting?
>
> This is with the 1.8.0.CR1 version of keycloak.
>
> Thanks!
>


-- 
John

From bburke at redhat.com  Fri Jan 15 20:33:39 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 15 Jan 2016 20:33:39 -0500
Subject: [keycloak-dev] 1st pass module re-org, Brute Force,
	and AuthenticationManager
Message-ID: <56999DF3.5030908@redhat.com>

PR sent, probably will be commited once you read this:

This is a first pass at the module re-org.  Wanted to get most of it 
done on Friday, but I screwed up and lost 3 hours of work cuz I forgot 
to merge Stian's big jackson change and the conflicts were too much :)  
I hope to do more next week.

* top level server-spi module was created

* These modules were removed and rolled into server-spi
- model-api
- events-api
- export-import-api
- timer-api

* These modules were moved into keycloak-services
- exportimport single file and dir
- some utility classes from exportimport api
- timer-basic


* These SPIs were moved to server-spi
- LoginProtocol
- ProtocolMapper
- ClientInstallationProvider


* BruteForceDetector is now a Provider and is looked up via 
KeycloakSession.  Previously we were stuffing it with 
AuthenticationManager and passing that around everywhere.  This cleaned 
up a bit of code.

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


From bburke at redhat.com  Sat Jan 16 09:46:56 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 16 Jan 2016 09:46:56 -0500
Subject: [keycloak-dev] 1st pass module re-org, Brute Force,
 and AuthenticationManager
In-Reply-To: <56999DF3.5030908@redhat.com>
References: <56999DF3.5030908@redhat.com>
Message-ID: <569A57E0.7050506@redhat.com>

Ok, now email, broker, social, forms/login and forms/account apis are 
now moved to server-spi.  Next I'm going to consolidate freemarker stuff 
and separate out the themes (.html, etc.) into their own module so that 
they can be completely replaced

On 1/15/2016 8:33 PM, Bill Burke wrote:
> PR sent, probably will be commited once you read this:
>
> This is a first pass at the module re-org.  Wanted to get most of it
> done on Friday, but I screwed up and lost 3 hours of work cuz I forgot
> to merge Stian's big jackson change and the conflicts were too much :)
> I hope to do more next week.
>
> * top level server-spi module was created
>
> * These modules were removed and rolled into server-spi
> - model-api
> - events-api
> - export-import-api
> - timer-api
>
> * These modules were moved into keycloak-services
> - exportimport single file and dir
> - some utility classes from exportimport api
> - timer-basic
>
>
> * These SPIs were moved to server-spi
> - LoginProtocol
> - ProtocolMapper
> - ClientInstallationProvider
>
>
> * BruteForceDetector is now a Provider and is looked up via
> KeycloakSession.  Previously we were stuffing it with
> AuthenticationManager and passing that around everywhere.  This cleaned
> up a bit of code.
>

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


From Edgar at info.nl  Sun Jan 17 17:14:24 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Sun, 17 Jan 2016 22:14:24 +0000
Subject: [keycloak-dev] User federation to Active Directory/LDAP and
 password policies
In-Reply-To: <56980CB8.6010502@redhat.com>
References: <C9CB71A2-2243-41A1-ABE2-0D833917A660@info.nl>
	<5696C754.2080909@redhat.com>
	<92F4A657-E8BF-49D3-9953-510CE4A0C9FF@info.nl>
	<37112117-4485-474C-A94D-4169B9AEA7BB@info.nl>
	<56976A49.20504@redhat.com>
	<EB0D4192-0AAA-4F77-BA78-7F1D470EE69A@info.nl>
	<1A7F913C-74B5-40D9-AC10-8C76E4552DDC@info.nl>
	<50F24EC9-4C03-49D1-8910-F561C5ACE613@info.nl>
	<56980CB8.6010502@redhat.com>
Message-ID: <A20AC330-EFBE-408B-93BA-84D5F9415B3E@info.nl>

Thanks Marek!

No big hurry for us to get it fixed so enjoy your holiday! :-)

I have created a JIRA issue as you suggested: https://issues.jboss.org/browse/KEYCLOAK-2333 <https://issues.jboss.org/browse/KEYCLOAK-2333>

And I have tried some of the things you mentioned in order to get this working in the Keycloak code but I have not managed to do so just yet. If I do I can probably create a pull request indeed.

cheers

Edgar

> On 14 Jan 2016, at 22:01, Marek Posolda <mposolda at redhat.com> wrote:
> 
> This makes things a bit tricky. Because:
> 1) Our current model SPI and federation SPI for update credential doesn't differ between the case when user is updating his credential or when admin is resetting the credential of user.
> 2) Also in LDAP both operations are executed under "admin" connection (user own connection is used just to verify his password).
> 3) Finally there is no old password available in the UserModel.updateCredential operation
> 
> Feel free to create JIRA, but hard to promise when we will be able to look into it (I am on holiday next week and then we have feature freeze and won't be able to add new stuff like this).
> 
> So if you really want it, you may need to send PR by yourself. The implementation may require more changes. Some pointers how I would do it (we may need ACK from other team members to confirm as we are close to "feature freeze" phase right now until we start on keycloak 2.x development):
> 
> 1) Change UserCredentialModel and put new fields "oldValue" with the old password. Also maybe the boolean field "isAdminCall", which will be true if admin is restarting the password (in this case the LDAP operation can be same like already and use "replace" operation) or if user himself is restarting the password. Maybe the "isAdminCall" field is not necessary as with admin call, the "oldValue" simply won't be available (when user himself is restarting the password in account management, user is required to set password and AccountService knows the old password value)
> 
> Other possibility is to introduce the context map ( Map<String, String> contextData ) on UserCredentialModel, which is more flexible. At the same time the "device" field can be removed from UserCredentialModel IMO as it doesn't seem to be used from anywhere right now.
> 
> 2) Change the LDAPIdentityStore implementation to differ between the two cases you described
> 
> Marek
> 
> On 14/01/16 17:41, Edgar Vonk - Info.nl wrote:
>> Regarding the MSAD password history policy not being used when we change the user?s password through Keycloak (using Keycloak?s user account screen where the user is updating his/her own password): is this maybe not caused because in the code the change password request to MSAD is not done ?correctly?? If I look at LDAPIdentityStore#updateADPassword it seems that changing the password involves a replace operation and not a delete + add operation? If I understand the documentation from Microsoft correctly I think you need to do a delete + add operation when the user changes his/her own password and the replace operation only when an admin changes someone else?s password. I think this might explain why the password history policy is not adhered to?
>> 
>> From https://support.microsoft.com/en-us/kb/269190: <https://support.microsoft.com/en-us/kb/269190:>
>> "There are two possible ways to modify the unicodePwd attribute. The first is similar to a normal "user change password" operation. In this case, the modify request must contain both a delete and an add operation. The delete operation must contain the current password with quotes around it. The add operation must contain the desired new password with quotes around it.
>> 
>> The second way to modify this attribute is analogous to an administrator resetting a password for a user. In order to do this, the client must bind as a user with sufficient permissions to modify another user's password. This modify request should contain a single replace operation with the new desired password surrounded by quotes. If the client has sufficient permissions, this password become the new password, regardless of what the old password was."
>> 
>> 
>> 
>>> On 14 Jan 2016, at 12:09, Edgar Vonk - Info.nl <http://info.nl/> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>> 
>>> Ah, sorry about this. I had not added a MSAD User Account Control mapper in our existing AD user federation in Keycloak yet. I thought it might be implicit and that I would not have to define an actual mapper or something. However this fixed the synching of the enabled status between AD and Keycloak. Nice work!
>>> 
>>> 
>>> 
>>> 
>>>> On 14 Jan 2016, at 11:23, Edgar Vonk - Info.nl <http://info.nl/> <Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>>> 
>>>> Hi Marek,
>>>> 
>>>>> On 14 Jan 2016, at 10:28, Marek Posolda < <mailto:mposolda at redhat.com>mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>>> 
>>>>> Yeah, the new MSAD mapper added in 1.8 should help you with this. Once the user has in MSAD userAccountControl of 514, he will be marked as disabled in Keycloak. Then when you enable it in Keycloak, it should be propagated to MSAD and user will be put in MSAD to 512. Hope it will work for you.
>>>>> 
>>>> 
>>>> 
>>>> Thanks but I?m afraid it does not work for us. I am using Keycloak 1.8.0.CR1 now. When I disable the user in MSAD I see the userAccountControl attribute change to 514, however this is not reflected in Keycloak. Not even when I force a resync of all users.
>>>> 
>>>> I will see if I can do some debugging and create a JIRA issue for you.
>>>> 
>>>> cheers
>>>> 
>>>> Edgar
>>>> 
>>>> 
>>>>> Not sure about password history issue.
>>>>> 
>>>>> Will wait for your feedback. Hope we can sort your issues.
>>>>> 
>>>>> Marek
>>>>> 
>>>>> On 14/01/16 10:01, Edgar Vonk - Info.nl <http://info.nl/> wrote:
>>>>>> Hi Marek,
>>>>>> 
>>>>>> Sorry, I overlooked you mentioning that you added this in Keycloak 1.8 while we are still on Keycloak 1.7.. I will upgrade and let you know a.s.a.p!
>>>>>> 
>>>>>> Thanks again for your help.
>>>>>> 
>>>>>> cheers
>>>>>> 
>>>>>> Edgar
>>>>>> 
>>>>>> 
>>>>>>> On 14 Jan 2016, at 09:54, Edgar Vonk - Info.nl <http://info.nl/> < <mailto:Edgar at info.nl>Edgar at info.nl <mailto:Edgar at info.nl>> wrote:
>>>>>>> 
>>>>>>> Hi Marek,
>>>>>>> 
>>>>>>> Thanks very much for your reply. See remarks below.
>>>>>>> 
>>>>>>>> On 13 Jan 2016, at 22:53, Marek Posolda < <mailto:mposolda at redhat.com>mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>>>>>> 
>>>>>>>> On 13/01/16 13:40, Edgar Vonk - Info.nl <http://info.nl/> wrote:
>>>>>>>>> Hi all,
>>>>>>>>> 
>>>>>>>>> We use Keycloak?s user federation to integrate with a (Windows 2012) Active Directory (AD) server. We want to store all users and groups in AD and also want to manage the password policies from AD so we do not have any password policies in Keycloak set up. We also want to use Keycloak for all user management functionality. We have set up the password policies in AD at the domain level where we connect to from Keycloak.
>>>>>>>>> 
>>>>>>>>> Our password policies in AD are as follows:
>>>>>>>>> - password complexity (min length + special chars)
>>>>>>>>> - account lock out after 3 attempts
>>>>>>>>> - password history (not allowed to use previous 5 passwords)
>>>>>>>>> 
>>>>>>>>> Users and admins can set and change passwords in AD from Keycloak fine. However the password policies do not quite do what we want them to:
>>>>>>>>> - Password complexity policy seems to work fine.
>>>>>>>>> - Account is indeed locked in AD after three failed attempts. However the ?Unlock users? functionality in Keycloak does not unlock the users in AD. Users can only be unlocked in AD itself it seems. We would like to be able to do this from Keycloak however (and really per user and not for all users in one go). Should this work in Keycloak or is this a new feature request?
>>>>>>>> Is the fact that user is locked tracked in your MSAD through userAccountControl attribute?
>>>>>>> 
>>>>>>> Yes it is. I see this working when I look at a normal LDAP browser connected to MSAD. When I disable a user in MSAD I see the userAccountControl attribute change from 512 to 514.
>>>>>>> 
>>>>>>> 
>>>>>>>> In the Keycloak 1.8 I've added the MSAD UserAccountControl mapper, which allows to integrate the MSAD account state more tightly into Keycloak state. For example enable user in Keycloak admin console will remove the ACCOUNTDISABLE flag from userAccountControl value in MSAD as well and hence enable this user in MSAD too.
>>>>>>> 
>>>>>>> 
>>>>>>> This sounds good, however unfortunately we do not see this happening.  When I disable the user in Keycloak the userAccountControl attribute does not change at all so the propagation to MSAD does not seem to work here.
>>>>>>> 
>>>>>>> We have indeed configured the user federation in Keycloak to WRITABLE LDAP and all other user attributes (like user name etc) are propagated from Keycloak to MSAD just fine.
>>>>>>> 
>>>>>>> I will create a JIRA issue so that I can send you some more details.
>>>>>>> 
>>>>>>>> 
>>>>>>>> However support for lock/unlock is not included in the mapper though. So feel free to create JIRA.
>>>>>>>> 
>>>>>>> 
>>>>>>> Ok, will do.
>>>>>>> 
>>>>>>> 
>>>>>>>> Until it's implemented, you can possibly use adminEvent listener (There is admin event triggered when you click "Unlock user" in Keycloak UI. So you can listen to this event and propagate the call to MSAD once you successfully enable it)
>>>>>>>>> - The password history policy does not seem to work at all. Users can currently set their password to a previous password without a problem. Does anyone have an idea why this policy in AD does not work from Keycloak?
>>>>>>>> No idea. Keycloak is just using Directory API for change password. It's strange the MSAD allows to change password through this API when it breaks password history policy. Are you sure you have WRITABLE LDAP and password update from Keycloak is propagated to MSAD?
>>>>>>> 
>>>>>>> Yes, we have writable ldap configured and indeed the password is propagated to MSAD. Maybe it is related to the issue we see with the userAccountControl attribute.
>>>>>>> 
>>>>>>> cheers
>>>>>>> 
>>>>>>> Edgar
>>>>>>> 
>>>>>>>> 
>>>>>>>> Marek
>>>>>>>>> 
>>>>>>>>> cheers
>>>>>>>>> 
>>>>>>>>> Edgar
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>>  <mailto:keycloak-dev at lists.jboss.org>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 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160117/97024cbe/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160117/97024cbe/attachment-0001.bin 

From sthorger at redhat.com  Mon Jan 18 02:49:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 08:49:56 +0100
Subject: [keycloak-dev] patching effected by module re-org?
In-Reply-To: <56994651.40508@redhat.com>
References: <56994651.40508@redhat.com>
Message-ID: <CAJgngAc_=nzDJ_9E6en9b4rx-UgNJ051SLOV9omCdfGfeLu5rw@mail.gmail.com>

We're still probably talking around a MB right? So it's not exactly huge.

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

> Do we need to think about how patching will work in EAP?  If we move to
> a more coarse grain module system, then the modules we patch might be
> quite large.  We fine with that?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/7d60e7b1/attachment.html 

From sthorger at redhat.com  Mon Jan 18 02:51:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 08:51:18 +0100
Subject: [keycloak-dev] unsupported media type error
In-Reply-To: <5699881F.4060301@redhat.com>
References: <56992E09.6090906@redhat.com>
	<1928191283.10412304.1452880343366.JavaMail.zimbra@redhat.com>
	<5699881F.4060301@redhat.com>
Message-ID: <CAJgngAcPpaXxXkhwZBDLF4TBASbtTL7RsMTuavFB-=zKxFnpHQ@mail.gmail.com>

John: Can you create a JIRA issue?
Pedro: I assume you'll fix it?

On 16 January 2016 at 01:00, John Dennis <jdennis at redhat.com> wrote:

> On 01/15/2016 12:52 PM, Pedro Igor Silva wrote:
> > Hey John,
> >
> >      KC expects a POST using the "application/soap+xml" media type.
> Maybe we should also provide a text/xml for SOAP 1.1 clients.
> >
> > Regards.
> > Pedro Igor
>
> I asked Pedro to wait and not change anything in Keycloak until I
> checked the specs. Based on my reading of the specs the media type (i.e.
> HTTP Content-Type header) should be
>
>    text/xml
>
> The media type 'application/soap+xml' is reserved for SOAP 1.2. RFC 3902
> "The "application/soap+xml" media type" states:
>
>    The "application/soap+xml" media type explicitly identifies SOAP 1.2
>    message envelopes that have been serialised with XML 1.0; message
>    envelopes with a different SOAP namespace version or using another
>    XML serialisation MUST NOT use it.
>
> The "SAML V2.0 Enhanced Client or Proxy Profile Version 2.0" (current as
> of August 2013) states that SAML messages are wrapped in SOAP 1.1.
>
> The "Simple Object Access Protocol (SOAP) 1.1" spec
> (https://www.w3.org/TR/2000/NOTE-SOAP-20000508/) in Section 6 "Using
> SOAP in HTTP" states:
>
>     HTTP applications MUST use the media type "text/xml" according to
>     RFC 2376 when including SOAP entity bodies in HTTP messages.
>
> Therefore since ECP requires SOAP 1.1 (not SOAP 1.2) and SOAP 1.1
> requires 'text/xml' and because RFC 3902 reserves 'application/soap+xml'
> for SOAP 1.2 the media type should be 'text/xml' not
> 'application/soap+xml'.
>
> I am partly to blame for the confusion, Pedro and I used an ECP test
> program I wrote and it erroneously used the incorrect
> 'application/soap+xml' media type and I think Pedro adjusted Keycloak to
> match based on that.
>
>
> > ----- Original Message -----
> > From: "John Dennis" <jdennis at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, January 15, 2016 3:36:09 PM
> > Subject: [keycloak-dev] unsupported media type error
> >
> > I'm trying to test Openstack ECP with Keycloak. When Openstack posts the
> > SAML AuthnRequest wrapped in SOAP to the
> > /auth/realms/master/protocol/saml endpoint keycloak responds with an
> > HTTP 415 unsupported media type error. The HTTP Content-Type in the post
> > is text/xml. What are you expecting?
> >
> > This is with the 1.8.0.CR1 version of keycloak.
> >
> > Thanks!
> >
>
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/ba107fd1/attachment.html 

From sthorger at redhat.com  Mon Jan 18 02:55:47 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 08:55:47 +0100
Subject: [keycloak-dev] direct grant cookies, and SSO
In-Reply-To: <56996F49.6020208@redhat.com>
References: <56996F49.6020208@redhat.com>
Message-ID: <CAJgngAf+O0TQhbK4_g+b0gL+N+E8d1P0NG4Z-7AUirSdWd16RQ@mail.gmail.com>

Public clients rely on the redirect uri to prevent malicious clients from
obtaining a token via the SSO session. As there is no redirect uri in
direct grant there would no longer be a mechanism to prevent malicious
clients. I know there's some level of protection in CORS, but IMO that on
its own is not sufficient. A public client should require both redirect uri
and CORS protection if it wants to utilize the SSO session.

It would also be inconsistent with the OIDC spec. There's nothing there
about using SSO with direct grant. SSO is only available via web redirect
flows and there's good reasons for that.

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

> I was thinking that using direct grant from Browser Javascript would
> work with SSO if direct grant created and returned an SSO cookie and
> also checked to see if an SSO cookie was set.  This way all the people
> wanting to completely bypass our login screens can do that. Why they
> would want to, I don't know.  We maybe should extend the direct grant
> protocol to tell the client when required actions must be filled out
> before authentication, stuff like that.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/e5d8f94c/attachment.html 

From sthorger at redhat.com  Mon Jan 18 03:02:35 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 09:02:35 +0100
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <569960C4.4060203@redhat.com>
References: <569960C4.4060203@redhat.com>
Message-ID: <CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>

Looks good how you've done it.

Bill is currently working on re-organizing code, but he's not going to move
anything from services. So can you finish up services and send a PR for it?
Then you can do the other logging once Bill is completed.

On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com> wrote:

> I've completed a first stab at this using the JBoss logging tools.  Once
> merged we will have the ability to do i18n/l10n on our log messages and
> also use message numbers.
>
> Here is the commit to show you how it turns out converting the log
> messages in KeycloakApplication:
>
> https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>
> So, now a message coming from the KeycloakApplication class in the
> services module looks like this:
>
> 15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread Pool
> -- 50)* KC-SERVICES0001*: Loading config from
> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>
> We need to decide how we want to structure this.  In WildFly, we typically
> have one logger per maven module.  If you want to have one logger per
> package then you would need to create a new interface in each package,
> which gets hairy.
>
> I do suggest that we prefix all of our messages with "KC-" or something
> else that is unique across products.  Also, we should standardize the
> "padding" for the message numbers.
>
> Another possibility is to have all keycloak messages start with
> "KEYCLOAK".  This would mean that we would need for each module to reserve
> a number range.  There are annotations to enforce this if we want to go
> that route.  The downside is that somewhere we need to maintain a
> registry.  I think WildFly did this but eventually abandoned it.  Notice
> that WildFly messages are like "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>
> BTW, localization works nicely.  Just add a bundle for a new language.
> The tool even creates a skeleton properties file for you.
>
> If you want more details on the i18n framework, see
> https://developer.jboss.org/wiki/JBossLoggingTooling.
>
> Stan
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/e24c6ed6/attachment.html 

From mhajas at redhat.com  Mon Jan 18 05:58:01 2016
From: mhajas at redhat.com (Michal Hajas)
Date: Mon, 18 Jan 2016 05:58:01 -0500 (EST)
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <5698FBE9.10406@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
	<1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
	<5698FBE9.10406@redhat.com>
Message-ID: <939885315.18350804.1453114681307.JavaMail.zimbra@redhat.com>

Maybe I configured something wrongly. Do you have any ideas what? Mellon somehow thinks that keycloak doesn't support it so he doesn't even try.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, January 15, 2016 3:02:17 PM
Subject: Re: [keycloak-dev] mod_auth_mellon

Looks like its on the auth mellon side as I don't see any request after: 
/mellon/logout?ReturnTo=/ 



On 1/15/2016 3:57 AM, Michal Hajas wrote: 



I can't see anything even in console log.

I enclosed whole proccess of login and logout in network tab.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com> To: "Michal Hajas" <mhajas at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Thursday, January 14, 2016 5:01:30 PM
Subject: Re: [keycloak-dev] mod_auth_mellon

You can probably see a trace in your browser console?

On 1/14/2016 10:21 AM, Michal Hajas wrote: 



Actually, I am not sure but it looks like not. There is nothing in both keycloak server log and events in admin console.

Michal.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com> To: keycloak-dev at lists.jboss.org Sent: Thursday, January 14, 2016 3:28:36 PM
Subject: Re: [keycloak-dev] mod_auth_mellon

Is mellon actually sending a logout request to Keycloak?
Do you see any error message on the keycloak server side? We definitely support POST binding for logout.
On 1/14/2016 8:34 AM, Michal Hajas wrote:



Hi,

I'm trying to run apache + mod_auth_mellon with keycloak as indentity provider.

Steps:
1. Install apache and mod_auth_mellon module
2. Generate .key, .cert, .xml files with mellon_create_metadata.sh and copy them to /mellon directory
3. Download idp_metadata.xml from keycloak/auth/realm/{REALM}/protocol/saml/descriptor and copy it to /mellon directory
4. Configure auth_mod_mellon with enclosed file auth_mellon.conf
5. Create client in keycloak from xml file generated in step 2 (There must be enabled Sign Documents, Sign Assertions signing and Force POST Binding)

Login works, when I access /auth, mellon redirect me to keycloak and after successful login it redirect me back to protected resource.

Problem:
I'm not able to logout. When I access localhost/mellon/logout?ReturnTo=/, it doesn't destroy session in keycloak and in apache's error log there is:
Current identity provider does not support single logout. Destroying local session only.

Only way I was able to log out is change

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />

to

<SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "http://localhost:8080/auth/realms/mellon-test/protocol/saml" />

POST -> Redirect

in idp_metadata.xml and set "Logout Service Redirect Binding URL" to http://localhost/mellon/logout in admin console.

Is it correct or it should work with POST binding too?

Thank you,
Michal.


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


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

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

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

From psilva at redhat.com  Mon Jan 18 07:16:05 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 18 Jan 2016 07:16:05 -0500 (EST)
Subject: [keycloak-dev] unsupported media type error
In-Reply-To: <CAJgngAcPpaXxXkhwZBDLF4TBASbtTL7RsMTuavFB-=zKxFnpHQ@mail.gmail.com>
References: <56992E09.6090906@redhat.com>
	<1928191283.10412304.1452880343366.JavaMail.zimbra@redhat.com>
	<5699881F.4060301@redhat.com>
	<CAJgngAcPpaXxXkhwZBDLF4TBASbtTL7RsMTuavFB-=zKxFnpHQ@mail.gmail.com>
Message-ID: <522476786.10880685.1453119365923.JavaMail.zimbra@redhat.com>

Will create a JIRA and send a fix for SOAP 1.1 clients today.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "John Dennis" <jdennis at redhat.com>
Cc: "Pedro Igor Silva" <psilva at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>, "Nathan Kinder" <nkinder at redhat.com>
Sent: Monday, January 18, 2016 5:51:18 AM
Subject: Re: [keycloak-dev] unsupported media type error

John: Can you create a JIRA issue?
Pedro: I assume you'll fix it?

On 16 January 2016 at 01:00, John Dennis <jdennis at redhat.com> wrote:

> On 01/15/2016 12:52 PM, Pedro Igor Silva wrote:
> > Hey John,
> >
> >      KC expects a POST using the "application/soap+xml" media type.
> Maybe we should also provide a text/xml for SOAP 1.1 clients.
> >
> > Regards.
> > Pedro Igor
>
> I asked Pedro to wait and not change anything in Keycloak until I
> checked the specs. Based on my reading of the specs the media type (i.e.
> HTTP Content-Type header) should be
>
>    text/xml
>
> The media type 'application/soap+xml' is reserved for SOAP 1.2. RFC 3902
> "The "application/soap+xml" media type" states:
>
>    The "application/soap+xml" media type explicitly identifies SOAP 1.2
>    message envelopes that have been serialised with XML 1.0; message
>    envelopes with a different SOAP namespace version or using another
>    XML serialisation MUST NOT use it.
>
> The "SAML V2.0 Enhanced Client or Proxy Profile Version 2.0" (current as
> of August 2013) states that SAML messages are wrapped in SOAP 1.1.
>
> The "Simple Object Access Protocol (SOAP) 1.1" spec
> (https://www.w3.org/TR/2000/NOTE-SOAP-20000508/) in Section 6 "Using
> SOAP in HTTP" states:
>
>     HTTP applications MUST use the media type "text/xml" according to
>     RFC 2376 when including SOAP entity bodies in HTTP messages.
>
> Therefore since ECP requires SOAP 1.1 (not SOAP 1.2) and SOAP 1.1
> requires 'text/xml' and because RFC 3902 reserves 'application/soap+xml'
> for SOAP 1.2 the media type should be 'text/xml' not
> 'application/soap+xml'.
>
> I am partly to blame for the confusion, Pedro and I used an ECP test
> program I wrote and it erroneously used the incorrect
> 'application/soap+xml' media type and I think Pedro adjusted Keycloak to
> match based on that.
>
>
> > ----- Original Message -----
> > From: "John Dennis" <jdennis at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, January 15, 2016 3:36:09 PM
> > Subject: [keycloak-dev] unsupported media type error
> >
> > I'm trying to test Openstack ECP with Keycloak. When Openstack posts the
> > SAML AuthnRequest wrapped in SOAP to the
> > /auth/realms/master/protocol/saml endpoint keycloak responds with an
> > HTTP 415 unsupported media type error. The HTTP Content-Type in the post
> > is text/xml. What are you expecting?
> >
> > This is with the 1.8.0.CR1 version of keycloak.
> >
> > Thanks!
> >
>
>
> --
> John
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From bburke at redhat.com  Mon Jan 18 08:04:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 18 Jan 2016 08:04:25 -0500
Subject: [keycloak-dev] mod_auth_mellon
In-Reply-To: <939885315.18350804.1453114681307.JavaMail.zimbra@redhat.com>
References: <2064286463.15643462.1452778442811.JavaMail.zimbra@redhat.com>
	<5697B094.9030607@redhat.com>
	<1550794174.15800954.1452784889362.JavaMail.zimbra@redhat.com>
	<5697C65A.2000603@redhat.com>
	<1721100913.16752698.1452848266691.JavaMail.zimbra@redhat.com>
	<5698FBE9.10406@redhat.com>
	<939885315.18350804.1453114681307.JavaMail.zimbra@redhat.com>
Message-ID: <569CE2D9.4090507@redhat.com>

Make sure that the SP and IDP metadata files both have a post binding in 
there for single logout service.  That's the only thing I can think of.  
Maybe mellon just doesn't support it.  The example file in the mellon 
doc uses redirect for logout.  *shrug*

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

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


From ssilvert at redhat.com  Mon Jan 18 08:25:01 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 18 Jan 2016 08:25:01 -0500
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
Message-ID: <569CE7AD.2040509@redhat.com>

On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
> Looks good how you've done it.
>
> Bill is currently working on re-organizing code, but he's not going to 
> move anything from services. So can you finish up services and send a 
> PR for it? Then you can do the other logging once Bill is completed.
Assuming nobody has an objection to the proposed format, I'll go ahead 
and finish services.

>
> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     I've completed a first stab at this using the JBoss logging
>     tools.  Once merged we will have the ability to do i18n/l10n on
>     our log messages and also use message numbers.
>
>     Here is the commit to show you how it turns out converting the log
>     messages in KeycloakApplication:
>     https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>
>     So, now a message coming from the KeycloakApplication class in the
>     services module looks like this:
>
>     15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread
>     Pool -- 50)*KC-SERVICES0001*: Loading config from
>     c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>
>     We need to decide how we want to structure this.  In WildFly, we
>     typically have one logger per maven module. If you want to have
>     one logger per package then you would need to create a new
>     interface in each package, which gets hairy.
>
>     I do suggest that we prefix all of our messages with "KC-" or
>     something else that is unique across products.  Also, we should
>     standardize the "padding" for the message numbers.
>
>     Another possibility is to have all keycloak messages start with
>     "KEYCLOAK".  This would mean that we would need for each module to
>     reserve a number range.  There are annotations to enforce this if
>     we want to go that route. The downside is that somewhere we need
>     to maintain a registry.  I think WildFly did this but eventually
>     abandoned it.  Notice that WildFly messages are like "WFLYUT" for
>     Undertow or "WFLYJSF" for JSF.
>
>     BTW, localization works nicely.  Just add a bundle for a new
>     language.  The tool even creates a skeleton properties file for you.
>
>     If you want more details on the i18n framework, see
>     https://developer.jboss.org/wiki/JBossLoggingTooling.
>
>     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
>
>

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

From ssilvert at redhat.com  Mon Jan 18 09:56:25 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 18 Jan 2016 09:56:25 -0500
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <569CE7AD.2040509@redhat.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
	<569CE7AD.2040509@redhat.com>
Message-ID: <569CFD19.7050502@redhat.com>

On 1/18/2016 8:25 AM, Stan Silvert wrote:
> On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>> Looks good how you've done it.
>>
>> Bill is currently working on re-organizing code, but he's not going 
>> to move anything from services. So can you finish up services and 
>> send a PR for it? Then you can do the other logging once Bill is 
>> completed.
> Assuming nobody has an objection to the proposed format, I'll go ahead 
> and finish services.

Another thing to consider is DEBUG logging.  Do we want to localize 
debug messages?


>
>>
>> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com 
>> <mailto:ssilvert at redhat.com>> wrote:
>>
>>     I've completed a first stab at this using the JBoss logging
>>     tools.  Once merged we will have the ability to do i18n/l10n on
>>     our log messages and also use message numbers.
>>
>>     Here is the commit to show you how it turns out converting the
>>     log messages in KeycloakApplication:
>>     https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>
>>     So, now a message coming from the KeycloakApplication class in
>>     the services module looks like this:
>>
>>     15:29:31,515 INFO  [*org.keycloak.services*] (ServerService
>>     Thread Pool -- 50)*KC-SERVICES0001*: Loading config from
>>     c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>
>>     We need to decide how we want to structure this.  In WildFly, we
>>     typically have one logger per maven module. If you want to have
>>     one logger per package then you would need to create a new
>>     interface in each package, which gets hairy.
>>
>>     I do suggest that we prefix all of our messages with "KC-" or
>>     something else that is unique across products. Also, we should
>>     standardize the "padding" for the message numbers.
>>
>>     Another possibility is to have all keycloak messages start with
>>     "KEYCLOAK".  This would mean that we would need for each module
>>     to reserve a number range.  There are annotations to enforce this
>>     if we want to go that route.  The downside is that somewhere we
>>     need to maintain a registry.  I think WildFly did this but
>>     eventually abandoned it.  Notice that WildFly messages are like
>>     "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>
>>     BTW, localization works nicely.  Just add a bundle for a new
>>     language.  The tool even creates a skeleton properties file for you.
>>
>>     If you want more details on the i18n framework, see
>>     https://developer.jboss.org/wiki/JBossLoggingTooling.
>>
>>     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
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From thomas.darimont at googlemail.com  Mon Jan 18 10:06:37 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Mon, 18 Jan 2016 16:06:37 +0100
Subject: [keycloak-dev] Keycloak Docker Image with Postgres HA with 1.8.CR1
	doesn't work.
Message-ID: <CAK-7U1gyppEoO3fnT7wRAYZKV+ggD0FMzM0zcS22KgcjGwNiTg@mail.gmail.com>

Hello,

I just tried the server-ha-postgres Docker image and I wasn't able to run
it.
https://github.com/jboss-dockerfiles/keycloak/tree/master/server-ha-postgres

The other images (server, server-postgres) work.

When I try to run the "server-ha-postgres" example I see:

14:54:35,888 INFO  [org.jboss.modules] (main) JBoss Modules version
1.5.0.Final
WFLYSRV0073: Invalid option '/opt/jboss/keycloak/bin/start.sh'

It seems that this command:
https://github.com/jboss-dockerfiles/keycloak/blob/bfbbde898e4aba3b3ee517052b981f68b7fb6d04/server-ha-postgres/Dockerfile#L9
is not properly passed to the start script.
Building the image locally with that line commented seems to work...

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

From ssilvert at redhat.com  Mon Jan 18 10:45:42 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 18 Jan 2016 10:45:42 -0500
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <569CFD19.7050502@redhat.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
	<569CE7AD.2040509@redhat.com> <569CFD19.7050502@redhat.com>
Message-ID: <569D08A6.5010105@redhat.com>

On 1/18/2016 9:56 AM, Stan Silvert wrote:
> On 1/18/2016 8:25 AM, Stan Silvert wrote:
>> On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>>> Looks good how you've done it.
>>>
>>> Bill is currently working on re-organizing code, but he's not going 
>>> to move anything from services. So can you finish up services and 
>>> send a PR for it? Then you can do the other logging once Bill is 
>>> completed.
>> Assuming nobody has an objection to the proposed format, I'll go 
>> ahead and finish services.
>
> Another thing to consider is DEBUG logging.  Do we want to localize 
> debug messages?
I grepped the WildFly code.  I could only find a handful of examples 
where somebody localized a debug message.  Looks like for the most part, 
their debug messages are not localized.
>
>
>>
>>>
>>> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com 
>>> <mailto:ssilvert at redhat.com>> wrote:
>>>
>>>     I've completed a first stab at this using the JBoss logging
>>>     tools. Once merged we will have the ability to do i18n/l10n on
>>>     our log messages and also use message numbers.
>>>
>>>     Here is the commit to show you how it turns out converting the
>>>     log messages in KeycloakApplication:
>>>     https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>>
>>>     So, now a message coming from the KeycloakApplication class in
>>>     the services module looks like this:
>>>
>>>     15:29:31,515 INFO  [*org.keycloak.services*] (ServerService
>>>     Thread Pool -- 50)*KC-SERVICES0001*: Loading config from
>>>     c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>>
>>>     We need to decide how we want to structure this.  In WildFly, we
>>>     typically have one logger per maven module.  If you want to have
>>>     one logger per package then you would need to create a new
>>>     interface in each package, which gets hairy.
>>>
>>>     I do suggest that we prefix all of our messages with "KC-" or
>>>     something else that is unique across products.  Also, we should
>>>     standardize the "padding" for the message numbers.
>>>
>>>     Another possibility is to have all keycloak messages start with
>>>     "KEYCLOAK".  This would mean that we would need for each module
>>>     to reserve a number range.  There are annotations to enforce
>>>     this if we want to go that route.  The downside is that
>>>     somewhere we need to maintain a registry.  I think WildFly did
>>>     this but eventually abandoned it.  Notice that WildFly messages
>>>     are like "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>>
>>>     BTW, localization works nicely.  Just add a bundle for a new
>>>     language.  The tool even creates a skeleton properties file for you.
>>>
>>>     If you want more details on the i18n framework, see
>>>     https://developer.jboss.org/wiki/JBossLoggingTooling.
>>>
>>>     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
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Jan 18 13:23:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 19:23:57 +0100
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <569D08A6.5010105@redhat.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
	<569CE7AD.2040509@redhat.com> <569CFD19.7050502@redhat.com>
	<569D08A6.5010105@redhat.com>
Message-ID: <CAJgngAfSCjsth8As4Ja+k++NgULjPheLhpPHmXbPvztxvWd_TA@mail.gmail.com>

On 18 January 2016 at 16:45, Stan Silvert <ssilvert at redhat.com> wrote:

> On 1/18/2016 9:56 AM, Stan Silvert wrote:
>
> On 1/18/2016 8:25 AM, Stan Silvert wrote:
>
> On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>
> Looks good how you've done it.
>
> Bill is currently working on re-organizing code, but he's not going to
> move anything from services. So can you finish up services and send a PR
> for it? Then you can do the other logging once Bill is completed.
>
> Assuming nobody has an objection to the proposed format, I'll go ahead and
> finish services.
>
>
> Another thing to consider is DEBUG logging.  Do we want to localize debug
> messages?
>
> I grepped the WildFly code.  I could only find a handful of examples where
> somebody localized a debug message.  Looks like for the most part, their
> debug messages are not localized.
>

We barely have any info logging, neither does WildFly. Seems weird to treat
them differently.

Is it just internationalization or log codes as well they don't have for
debug?


>
>
>
>
>
> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> I've completed a first stab at this using the JBoss logging tools.  Once
>> merged we will have the ability to do i18n/l10n on our log messages and
>> also use message numbers.
>>
>> Here is the commit to show you how it turns out converting the log
>> messages in KeycloakApplication:
>>
>> https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>
>> So, now a message coming from the KeycloakApplication class in the
>> services module looks like this:
>>
>> 15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread Pool
>> -- 50)* KC-SERVICES0001*: Loading config from
>> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>
>> We need to decide how we want to structure this.  In WildFly, we
>> typically have one logger per maven module.  If you want to have one logger
>> per package then you would need to create a new interface in each package,
>> which gets hairy.
>>
>> I do suggest that we prefix all of our messages with "KC-" or something
>> else that is unique across products.  Also, we should standardize the
>> "padding" for the message numbers.
>>
>> Another possibility is to have all keycloak messages start with
>> "KEYCLOAK".  This would mean that we would need for each module to reserve
>> a number range.  There are annotations to enforce this if we want to go
>> that route.  The downside is that somewhere we need to maintain a
>> registry.  I think WildFly did this but eventually abandoned it.  Notice
>> that WildFly messages are like "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>
>> BTW, localization works nicely.  Just add a bundle for a new language.
>> The tool even creates a skeleton properties file for you.
>>
>> If you want more details on the i18n framework, see
>> https://developer.jboss.org/wiki/JBossLoggingTooling.
>>
>> Stan
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/646fd8a5/attachment-0001.html 

From ssilvert at redhat.com  Mon Jan 18 13:52:12 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 18 Jan 2016 13:52:12 -0500
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <CAJgngAfSCjsth8As4Ja+k++NgULjPheLhpPHmXbPvztxvWd_TA@mail.gmail.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
	<569CE7AD.2040509@redhat.com> <569CFD19.7050502@redhat.com>
	<569D08A6.5010105@redhat.com>
	<CAJgngAfSCjsth8As4Ja+k++NgULjPheLhpPHmXbPvztxvWd_TA@mail.gmail.com>
Message-ID: <569D345C.9000008@redhat.com>

On 1/18/2016 1:23 PM, Stian Thorgersen wrote:
>
>
> On 18 January 2016 at 16:45, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     On 1/18/2016 9:56 AM, Stan Silvert wrote:
>>     On 1/18/2016 8:25 AM, Stan Silvert wrote:
>>>     On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>>>>     Looks good how you've done it.
>>>>
>>>>     Bill is currently working on re-organizing code, but he's not
>>>>     going to move anything from services. So can you finish up
>>>>     services and send a PR for it? Then you can do the other
>>>>     logging once Bill is completed.
>>>     Assuming nobody has an objection to the proposed format, I'll go
>>>     ahead and finish services.
>>
>>     Another thing to consider is DEBUG logging.  Do we want to
>>     localize debug messages?
>     I grepped the WildFly code.  I could only find a handful of
>     examples where somebody localized a debug message.  Looks like for
>     the most part, their debug messages are not localized.
>
>
> We barely have any info logging, neither does WildFly. Seems weird to 
> treat them differently.
Yes,  from what I've seen so far, most of our logging is ERROR, WARN, or 
DEBUG.  Very little INFO and a tiny bit of TRACE.
>
> Is it just internationalization or log codes as well they don't have 
> for debug?
Neither.  Except for a couple of places I found, they aren't doing 
anything special with debug messages.

Debug messages can still get logged using the same per-module logger 
that is used for localized logging.  So we can have:
protected static ServicesLogger logger = ServicesLogger.ROOT_LOGGER;
....
logger.debugv("Client {0} authenticated by {1}", client.getClientId(), 
factory.getId());

These would not be localized and would not be given a message number.  
If you want them localized with message number you need:

logger.clientAuthenticated(client.getClientId(), factory.getId());
...
@LogMessage(level = DEBUG)
@Message(id=45, value="Client %s authenticated by %s")
void clientAuthenticated(String clientId, String factoryId);


>
>>
>>
>>>
>>>>
>>>>     On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com
>>>>     <mailto:ssilvert at redhat.com>> wrote:
>>>>
>>>>         I've completed a first stab at this using the JBoss logging
>>>>         tools.  Once merged we will have the ability to do
>>>>         i18n/l10n on our log messages and also use message numbers.
>>>>
>>>>         Here is the commit to show you how it turns out converting
>>>>         the log messages in KeycloakApplication:
>>>>         https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>>>
>>>>         So, now a message coming from the KeycloakApplication class
>>>>         in the services module looks like this:
>>>>
>>>>         15:29:31,515 INFO  [*org.keycloak.services*] (ServerService
>>>>         Thread Pool -- 50)*KC-SERVICES0001*: Loading config from
>>>>         c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>>>
>>>>         We need to decide how we want to structure this.  In
>>>>         WildFly, we typically have one logger per maven module.  If
>>>>         you want to have one logger per package then you would need
>>>>         to create a new interface in each package, which gets hairy.
>>>>
>>>>         I do suggest that we prefix all of our messages with "KC-"
>>>>         or something else that is unique across products.  Also, we
>>>>         should standardize the "padding" for the message numbers.
>>>>
>>>>         Another possibility is to have all keycloak messages start
>>>>         with "KEYCLOAK".  This would mean that we would need for
>>>>         each module to reserve a number range.  There are
>>>>         annotations to enforce this if we want to go that route. 
>>>>         The downside is that somewhere we need to maintain a
>>>>         registry.  I think WildFly did this but eventually
>>>>         abandoned it.  Notice that WildFly messages are like
>>>>         "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>>>
>>>>         BTW, localization works nicely.  Just add a bundle for a
>>>>         new language.  The tool even creates a skeleton properties
>>>>         file for you.
>>>>
>>>>         If you want more details on the i18n framework, see
>>>>         https://developer.jboss.org/wiki/JBossLoggingTooling.
>>>>
>>>>         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
>>>>
>>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Jan 18 14:40:59 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 18 Jan 2016 20:40:59 +0100
Subject: [keycloak-dev] i18n for Logging
In-Reply-To: <569D345C.9000008@redhat.com>
References: <569960C4.4060203@redhat.com>
	<CAJgngAdnaBozJhdtVDFBoq7=QzNdy=fSazT7HNb8GcG1+_9QrA@mail.gmail.com>
	<569CE7AD.2040509@redhat.com> <569CFD19.7050502@redhat.com>
	<569D08A6.5010105@redhat.com>
	<CAJgngAfSCjsth8As4Ja+k++NgULjPheLhpPHmXbPvztxvWd_TA@mail.gmail.com>
	<569D345C.9000008@redhat.com>
Message-ID: <CAJgngAcfw5fh2DTg71c5ixRSq+SVdz2bcKkkdonqG=GAH3YvMQ@mail.gmail.com>

Ok, let's just keep debug and trace statements as is then. If WildFly can
get away without codes and internationalization of those so can we.

On 18 January 2016 at 19:52, Stan Silvert <ssilvert at redhat.com> wrote:

> On 1/18/2016 1:23 PM, Stian Thorgersen wrote:
>
>
>
> On 18 January 2016 at 16:45, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 1/18/2016 9:56 AM, Stan Silvert wrote:
>>
>> On 1/18/2016 8:25 AM, Stan Silvert wrote:
>>
>> On 1/18/2016 3:02 AM, Stian Thorgersen wrote:
>>
>> Looks good how you've done it.
>>
>> Bill is currently working on re-organizing code, but he's not going to
>> move anything from services. So can you finish up services and send a PR
>> for it? Then you can do the other logging once Bill is completed.
>>
>> Assuming nobody has an objection to the proposed format, I'll go ahead
>> and finish services.
>>
>>
>> Another thing to consider is DEBUG logging.  Do we want to localize debug
>> messages?
>>
>> I grepped the WildFly code.  I could only find a handful of examples
>> where somebody localized a debug message.  Looks like for the most part,
>> their debug messages are not localized.
>>
>
> We barely have any info logging, neither does WildFly. Seems weird to
> treat them differently.
>
> Yes,  from what I've seen so far, most of our logging is ERROR, WARN, or
> DEBUG.  Very little INFO and a tiny bit of TRACE.
>
>
> Is it just internationalization or log codes as well they don't have for
> debug?
>
> Neither.  Except for a couple of places I found, they aren't doing
> anything special with debug messages.
>
> Debug messages can still get logged using the same per-module logger that
> is used for localized logging.  So we can have:
> protected static ServicesLogger logger = ServicesLogger.ROOT_LOGGER;
> ....
> logger.debugv("Client {0} authenticated by {1}", client.getClientId(),
> factory.getId());
>
> These would not be localized and would not be given a message number.  If
> you want them localized with message number you need:
>
> logger.clientAuthenticated(client.getClientId(), factory.getId());
> ...
> @LogMessage(level = DEBUG)
> @Message(id=45, value="Client %s authenticated by %s")
> void clientAuthenticated(String clientId, String factoryId);
>
>
>
>
>
>>
>>
>>
>>
>>
>> On 15 January 2016 at 22:12, Stan Silvert <ssilvert at redhat.com> wrote:
>>
>>> I've completed a first stab at this using the JBoss logging tools.  Once
>>> merged we will have the ability to do i18n/l10n on our log messages and
>>> also use message numbers.
>>>
>>> Here is the commit to show you how it turns out converting the log
>>> messages in KeycloakApplication:
>>>
>>> https://github.com/ssilvert/keycloak/commit/54faba37cb4797fc337569899d8ac8eaa7f0ad1a#diff-72ce0a0a72ebd57f8627c059f7f1ea03R1
>>>
>>> So, now a message coming from the KeycloakApplication class in the
>>> services module looks like this:
>>>
>>> 15:29:31,515 INFO  [*org.keycloak.services*] (ServerService Thread Pool
>>> -- 50)* KC-SERVICES0001*: Loading config from
>>> c:\GitHub\keycloak\distribution\server-dist\target\keycloak-1.9.0.CR1-SNAPSHOT\standalone\configuration\keycloak-server.json
>>>
>>> We need to decide how we want to structure this.  In WildFly, we
>>> typically have one logger per maven module.  If you want to have one logger
>>> per package then you would need to create a new interface in each package,
>>> which gets hairy.
>>>
>>> I do suggest that we prefix all of our messages with "KC-" or something
>>> else that is unique across products.  Also, we should standardize the
>>> "padding" for the message numbers.
>>>
>>> Another possibility is to have all keycloak messages start with
>>> "KEYCLOAK".  This would mean that we would need for each module to reserve
>>> a number range.  There are annotations to enforce this if we want to go
>>> that route.  The downside is that somewhere we need to maintain a
>>> registry.  I think WildFly did this but eventually abandoned it.  Notice
>>> that WildFly messages are like "WFLYUT" for Undertow or "WFLYJSF" for JSF.
>>>
>>> BTW, localization works nicely.  Just add a bundle for a new language.
>>> The tool even creates a skeleton properties file for you.
>>>
>>> If you want more details on the i18n framework, see
>>> https://developer.jboss.org/wiki/JBossLoggingTooling.
>>>
>>> Stan
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160118/8836c015/attachment-0001.html 

From srossillo at smartling.com  Mon Jan 18 21:35:11 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 19 Jan 2016 02:35:11 +0000
Subject: [keycloak-dev] Fwd: [keycloak-user] Spring Boot REST Service
	Example(s)
In-Reply-To: <CAPFuFv_RNgs5srO3VQcEHh0Rce6Pj4S1W66f07dKk95eJDEX-A@mail.gmail.com>
References: <CAPFuFv_JUZEEmgn7g6DyoMAMoN9hY3BeAd3zTms_py0NizApjw@mail.gmail.com>
	<569835BE.3070409@redhat.com>
	<CAPFuFv_RNgs5srO3VQcEHh0Rce6Pj4S1W66f07dKk95eJDEX-A@mail.gmail.com>
Message-ID: <CALAqdu9w5uWgPgSw9e5WpWV8vSi8QdB9K9dpzyj58Ho-mo226Q@mail.gmail.com>

Those are a fork of my examples. Before product, I think the Spring Boot
adapter needs an update to be based on the Spring adapter. I can do this if
if you give me an ETA on how long before code is frozen.

---------- Forwarded message ---------
From: Jeremy Simon <jeremy at jeremysimon.com>
Date: Mon, Jan 18, 2016 at 12:11 PM
Subject: Re: [keycloak-user] Spring Boot REST Service Example(s)
To: <keycloak-user at lists.jboss.org>


Thanks!  These make a lot more sense.  Looks Springy. ;)  Based on how
these examples are configured, why would the Keycloak documentation
even mention in section 8.9.2 "You also need to specify the J2EE
security config that would normally go in the web.xml"?  Just trying
to get an understanding.
jeremy
jeremy at jeremysimon.com
www.JeremySimon.com


On Thu, Jan 14, 2016 at 6:56 PM, Bill Burke <bburke at redhat.com> wrote:
> Andrzej already replied to this earlier:
>
> take a look at these examples:
> https://github.com/agolPL/keycloak-spring-demo
>
>
>
> On 1/14/2016 6:44 PM, Jeremy Simon wrote:
>> Hi,
>>
>> Would anyone be willing to point me to some good working examples that
>> are REST services built with Spring Boot but can leverage Keycloak for
>> authentication?  I had no trouble integrating a webapp with the SAML
>> protocol, but this OpenID Connect (/Oauth2?) area of things is really
>> confusing.
>>
>> All I'm trying to do is security the REST endpoints I made and then
>> when I actually hit a controller, also be able to pull some role or
>> attribute information off the Authentication token.
>>
>> I tried to cobble together something using the reference guide and the
>> adaptors sections, but to no avail.  In particular I followed the 8.9
>> Spring Boot Adaptor but I get 302s and a this in the response if i try
>> a rest client...
>>
>> ----
>> 302 Found
>>
>> form
>>
>> HEADERS
>> Content-Length:0 Bytes
>> Date:
>> 2016 Jan 14 18:41:13
>> Location:
http://localhost:11080/auth/realms/jeremy/protocol/openid-connect/auth?response_type=code&client_id=try&redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fadmin&state=1%2F82011a10-3b29-44eb-9801-e723c03c94bf&login=true
>> S
>>
>> ----
>>
>> At any rate, I tried some extra spring security and other mentions
>> down further in the guide, but I'm definitely digging myself into a
>> little hole!  Any help would be greatly appreciated!
>>
>> Possibly uneducated guess with this subject, can Spring Security OAuth
>> be used with this?  Probably can't with the OpenID JWT responses?
>>
>> jeremy
>> jeremy at jeremysimon.com
>> www.JeremySimon.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/97edbd94/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 19 03:58:27 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 09:58:27 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute match.
Message-ID: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>

Hi,

I was looking for a way to query users based on their exact username but it
turned out, that
  org.keycloak.admin.client.resource.UsersResource.search(String, String,
String, String, Integer, Integer)

  @GET
  @Produces(MediaType.APPLICATION_JSON)
  List<UserRepresentation> search(@QueryParam("username") String username,
                                       @QueryParam("firstName") String
firstName,
                                       @QueryParam("lastName") String
lastName,
                                       @QueryParam("email") String email,
                                       @QueryParam("first") Integer
firstResult,
                                       @QueryParam("max") Integer
maxResults);

  ...
  usersResource.search("exactusername",null,null, null, null, email, 0, 10)

generates a like %..% query in
JpaUserProvider.searchForUserByAttributes(...).

Since usernames are unique per realm I think it would make sense to be able
to perform a
query for the exact username (or perhaps the combination of other
attributes as well).

Was this omitted by design, or may I create a JIRA for this?

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

From sthorger at redhat.com  Tue Jan 19 04:07:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 10:07:07 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
Message-ID: <CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>

It was by design, but it wasn't a good design. Would be better to make it
match exact, but allow including a wildcard to make it fuzzy.

On 19 January 2016 at 09:58, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hi,
>
> I was looking for a way to query users based on their exact username but
> it turned out, that
>   org.keycloak.admin.client.resource.UsersResource.search(String, String,
> String, String, Integer, Integer)
>
>   @GET
>   @Produces(MediaType.APPLICATION_JSON)
>   List<UserRepresentation> search(@QueryParam("username") String username,
>                                        @QueryParam("firstName") String
> firstName,
>                                        @QueryParam("lastName") String
> lastName,
>                                        @QueryParam("email") String email,
>                                        @QueryParam("first") Integer
> firstResult,
>                                        @QueryParam("max") Integer
> maxResults);
>
>   ...
>   usersResource.search("exactusername",null,null, null, null, email, 0, 10)
>
> generates a like %..% query in
> JpaUserProvider.searchForUserByAttributes(...).
>
> Since usernames are unique per realm I think it would make sense to be
> able to perform a
> query for the exact username (or perhaps the combination of other
> attributes as well).
>
> Was this omitted by design, or may I create a JIRA for this?
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/e3ef63e5/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 19 04:15:03 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 10:15:03 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
Message-ID: <CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>

Okay, how about offering a new search method that accepts s UserSearch DTO
that would hold the attributes to search by
as well as a "match mode". Could also be used to specify pagination.

This could also be send via a @POST in order to avoid retaining userdata
like usernames, email addresses etc. in
access logs...

Alternatively you could introduce a searchExact(..) method with the same
parameterization as the existing search method.

2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> It was by design, but it wasn't a good design. Would be better to make it
> match exact, but allow including a wildcard to make it fuzzy.
>
> On 19 January 2016 at 09:58, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hi,
>>
>> I was looking for a way to query users based on their exact username but
>> it turned out, that
>>   org.keycloak.admin.client.resource.UsersResource.search(String, String,
>> String, String, Integer, Integer)
>>
>>   @GET
>>   @Produces(MediaType.APPLICATION_JSON)
>>   List<UserRepresentation> search(@QueryParam("username") String username,
>>                                        @QueryParam("firstName") String
>> firstName,
>>                                        @QueryParam("lastName") String
>> lastName,
>>                                        @QueryParam("email") String email,
>>                                        @QueryParam("first") Integer
>> firstResult,
>>                                        @QueryParam("max") Integer
>> maxResults);
>>
>>   ...
>>   usersResource.search("exactusername",null,null, null, null, email, 0,
>> 10)
>>
>> generates a like %..% query in
>> JpaUserProvider.searchForUserByAttributes(...).
>>
>> Since usernames are unique per realm I think it would make sense to be
>> able to perform a
>> query for the exact username (or perhaps the combination of other
>> attributes as well).
>>
>> Was this omitted by design, or may I create a JIRA for this?
>>
>> Cheers,
>> Thomas
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/43f41764/attachment-0001.html 

From thomas.darimont at googlemail.com  Tue Jan 19 04:27:01 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 10:27:01 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
Message-ID: <CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>

Hello,

I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track this.

Cheers,
Thomas

2016-01-19 10:15 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com>:

> Okay, how about offering a new search method that accepts s UserSearch DTO
> that would hold the attributes to search by
> as well as a "match mode". Could also be used to specify pagination.
>
> This could also be send via a @POST in order to avoid retaining userdata
> like usernames, email addresses etc. in
> access logs...
>
> Alternatively you could introduce a searchExact(..) method with the same
> parameterization as the existing search method.
>
> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> It was by design, but it wasn't a good design. Would be better to make it
>> match exact, but allow including a wildcard to make it fuzzy.
>>
>> On 19 January 2016 at 09:58, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> I was looking for a way to query users based on their exact username but
>>> it turned out, that
>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>> String, String, String, Integer, Integer)
>>>
>>>   @GET
>>>   @Produces(MediaType.APPLICATION_JSON)
>>>   List<UserRepresentation> search(@QueryParam("username") String
>>> username,
>>>                                        @QueryParam("firstName") String
>>> firstName,
>>>                                        @QueryParam("lastName") String
>>> lastName,
>>>                                        @QueryParam("email") String email,
>>>                                        @QueryParam("first") Integer
>>> firstResult,
>>>                                        @QueryParam("max") Integer
>>> maxResults);
>>>
>>>   ...
>>>   usersResource.search("exactusername",null,null, null, null, email, 0,
>>> 10)
>>>
>>> generates a like %..% query in
>>> JpaUserProvider.searchForUserByAttributes(...).
>>>
>>> Since usernames are unique per realm I think it would make sense to be
>>> able to perform a
>>> query for the exact username (or perhaps the combination of other
>>> attributes as well).
>>>
>>> Was this omitted by design, or may I create a JIRA for this?
>>>
>>> Cheers,
>>> Thomas
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/330acc1d/attachment.html 

From velias at redhat.com  Tue Jan 19 05:10:45 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 19 Jan 2016 11:10:45 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
Message-ID: <569E0BA5.5030604@redhat.com>

Hi,

I need Social login provider for Microsoft Live account. I can implement
it as I did few other social login providers already.

Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
provider so impl should be easy.

If not in KC 1.8 release, is it possible to add social provider as
customization to my KC instance only? It is common provider factory so
it should be possible I hope, but it also requires some template in
admin theme, so I'm not sure (probably I have to create my customized
admin theme in this case).

I definitely prefer to have it in upstream if possible.

Vlastimil

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team




From sthorger at redhat.com  Tue Jan 19 05:49:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 11:49:41 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
Message-ID: <CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>

-1 To additional search method. URL should be '.../users'.

Simplest is just to change what we have now to not included wildcards. Then
add an extra query param "fuzzy". If fuzzy=true then we'd add %. Default
should be false. Alternatives are:

* Let users add % themselves
* Add separate query params for fuzzy

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

> Hello,
>
> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track this.
>
> Cheers,
> Thomas
>
> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <thomas.darimont at googlemail.com
> >:
>
>> Okay, how about offering a new search method that accepts s UserSearch
>> DTO that would hold the attributes to search by
>> as well as a "match mode". Could also be used to specify pagination.
>>
>> This could also be send via a @POST in order to avoid retaining userdata
>> like usernames, email addresses etc. in
>> access logs...
>>
>> Alternatively you could introduce a searchExact(..) method with the same
>> parameterization as the existing search method.
>>
>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> It was by design, but it wasn't a good design. Would be better to make
>>> it match exact, but allow including a wildcard to make it fuzzy.
>>>
>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I was looking for a way to query users based on their exact username
>>>> but it turned out, that
>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>> String, String, String, Integer, Integer)
>>>>
>>>>   @GET
>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>> username,
>>>>                                        @QueryParam("firstName") String
>>>> firstName,
>>>>                                        @QueryParam("lastName") String
>>>> lastName,
>>>>                                        @QueryParam("email") String
>>>> email,
>>>>                                        @QueryParam("first") Integer
>>>> firstResult,
>>>>                                        @QueryParam("max") Integer
>>>> maxResults);
>>>>
>>>>   ...
>>>>   usersResource.search("exactusername",null,null, null, null, email, 0,
>>>> 10)
>>>>
>>>> generates a like %..% query in
>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>
>>>> Since usernames are unique per realm I think it would make sense to be
>>>> able to perform a
>>>> query for the exact username (or perhaps the combination of other
>>>> attributes as well).
>>>>
>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/480181cb/attachment.html 

From sthorger at redhat.com  Tue Jan 19 05:52:58 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 11:52:58 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <569E0BA5.5030604@redhat.com>
References: <569E0BA5.5030604@redhat.com>
Message-ID: <CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>

If you can get it in today or tomorrow (early) we can add it to 1.8.0.CR2.

You should also be able to use the generic OpenID Connect provider.

Adding it yourself would require also adding templates in admin theme,
shouldn't be a big deal as you only need that one template and the rest
you'd inherit from Keycloak theme.

On 19 January 2016 at 11:10, Vlastimil Elias <velias at redhat.com> wrote:

> Hi,
>
> I need Social login provider for Microsoft Live account. I can implement
> it as I did few other social login providers already.
>
> Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
> if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
> provider so impl should be easy.
>
> If not in KC 1.8 release, is it possible to add social provider as
> customization to my KC instance only? It is common provider factory so
> it should be possible I hope, but it also requires some template in
> admin theme, so I'm not sure (probably I have to create my customized
> admin theme in this case).
>
> I definitely prefer to have it in upstream if possible.
>
> Vlastimil
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/5e04c98c/attachment-0001.html 

From velias at redhat.com  Tue Jan 19 06:06:48 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 19 Jan 2016 12:06:48 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
Message-ID: <569E18C8.5090401@redhat.com>

Hi

On 19.1.2016 11:52, Stian Thorgersen wrote:
> If you can get it in today or tomorrow (early) we can add it to 1.8.0.CR2.

will try to do this, I will provide PR against branche and the another
against master

> You should also be able to use the generic OpenID Connect provider.

I though about it, but if I understand it correctly I will not be able
to get users name, surname and email this way, as it is not provided in
OAuth 2 and it requires another REST call in common social providers.

>
> Adding it yourself would require also adding templates in admin theme,
> shouldn't be a big deal as you only need that one template and the
> rest you'd inherit from Keycloak theme.

I see

Thanks

>
> On 19 January 2016 at 11:10, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>     Hi,
>
>     I need Social login provider for Microsoft Live account. I can
>     implement
>     it as I did few other social login providers already.
>
>     Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
>     if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
>     provider so impl should be easy.
>
>     If not in KC 1.8 release, is it possible to add social provider as
>     customization to my KC instance only? It is common provider factory so
>     it should be possible I hope, but it also requires some template in
>     admin theme, so I'm not sure (probably I have to create my customized
>     admin theme in this case).
>
>     I definitely prefer to have it in upstream if possible.
>
>     Vlastimil
>
>     --
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Tue Jan 19 06:09:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 12:09:48 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <569E18C8.5090401@redhat.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
Message-ID: <CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>

On 19 January 2016 at 12:06, Vlastimil Elias <velias at redhat.com> wrote:

> Hi
>
> On 19.1.2016 11:52, Stian Thorgersen wrote:
>
> If you can get it in today or tomorrow (early) we can add it to 1.8.0.CR2.
>
>
> will try to do this, I will provide PR against branche and the another
> against master
>
> You should also be able to use the generic OpenID Connect provider.
>
>
> I though about it, but if I understand it correctly I will not be able to
> get users name, surname and email this way, as it is not provided in OAuth
> 2 and it requires another REST call in common social providers.
>

Do they not have an userinfo endpoint?


>
>
>
> Adding it yourself would require also adding templates in admin theme,
> shouldn't be a big deal as you only need that one template and the rest
> you'd inherit from Keycloak theme.
>
>
> I see
>
> Thanks
>
>
>
> On 19 January 2016 at 11:10, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> I need Social login provider for Microsoft Live account. I can implement
>> it as I did few other social login providers already.
>>
>> Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
>> if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
>> provider so impl should be easy.
>>
>> If not in KC 1.8 release, is it possible to add social provider as
>> customization to my KC instance only? It is common provider factory so
>> it should be possible I hope, but it also requires some template in
>> admin theme, so I'm not sure (probably I have to create my customized
>> admin theme in this case).
>>
>> I definitely prefer to have it in upstream if possible.
>>
>> Vlastimil
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/7c3f290f/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 19 06:20:09 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 12:20:09 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
	<CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
Message-ID: <CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>

I just wanted to ensure backwards compatibility - an additional parameter
would break (java) API
consumers who are currently using the keycloak-admin-client, since they are
potentially using the
variant without the parameter.
This would of course be no problem for REST API consumers.

What I see as a problem though is the behaviour change of the search
behaviour by default ...
(knowing the current API) I'd rather expect that the search would perform
the same as before
with fuzzy matching /by default/ and support for exact match if explicitly
stated.

However having a search operation that performs an exact search by
default "feels" more natural to me - so I'm fine with your suggestion as a
quick solution :)

Regarding urls:
I'd rather prefer to have some dedicated search sub-resources per entity -
but that is a more general topic...
With this approach one would be more flexible with respect to supported
searches
that could behave completly different.

Entity lookups by id
  /entity/{id}

Dedicated lookup sub-resource for other attribute lookups: (here I'd expect
exactly 0 or 1 results)
  /entity/lookup/byName?name=someName
  /entity/lookup/byEmail?email=someEmail

Dedicated search sub-resources:  (here I'd expect 0 or n results)

  /entity/search/byName?name=someName
  /entity/search/byNameMatching?pattern=someName
  /entity/search/byAttributes?firstname=firstname&lastname=lastname

In addition to that one could also allow @POST requests to these
(sub-)resources
where the actual parameters are extracted from form-parameters in order
to avoid leaking user information like username, email, etc. in access logs.
I think this would be relevant for an application that deals with security
sensitive information
like keycloak does.

Cheers,
Thomas


2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> -1 To additional search method. URL should be '.../users'.
>
> Simplest is just to change what we have now to not included wildcards.
> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
> Default should be false. Alternatives are:
>
> * Let users add % themselves
> * Add separate query params for fuzzy
>
> On 19 January 2016 at 10:27, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Hello,
>>
>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track this.
>>
>> Cheers,
>> Thomas
>>
>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>> thomas.darimont at googlemail.com>:
>>
>>> Okay, how about offering a new search method that accepts s UserSearch
>>> DTO that would hold the attributes to search by
>>> as well as a "match mode". Could also be used to specify pagination.
>>>
>>> This could also be send via a @POST in order to avoid retaining userdata
>>> like usernames, email addresses etc. in
>>> access logs...
>>>
>>> Alternatively you could introduce a searchExact(..) method with the same
>>> parameterization as the existing search method.
>>>
>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>
>>>> It was by design, but it wasn't a good design. Would be better to make
>>>> it match exact, but allow including a wildcard to make it fuzzy.
>>>>
>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>> thomas.darimont at googlemail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I was looking for a way to query users based on their exact username
>>>>> but it turned out, that
>>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>> String, String, String, Integer, Integer)
>>>>>
>>>>>   @GET
>>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>>> username,
>>>>>                                        @QueryParam("firstName") String
>>>>> firstName,
>>>>>                                        @QueryParam("lastName") String
>>>>> lastName,
>>>>>                                        @QueryParam("email") String
>>>>> email,
>>>>>                                        @QueryParam("first") Integer
>>>>> firstResult,
>>>>>                                        @QueryParam("max") Integer
>>>>> maxResults);
>>>>>
>>>>>   ...
>>>>>   usersResource.search("exactusername",null,null, null, null, email,
>>>>> 0, 10)
>>>>>
>>>>> generates a like %..% query in
>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>
>>>>> Since usernames are unique per realm I think it would make sense to be
>>>>> able to perform a
>>>>> query for the exact username (or perhaps the combination of other
>>>>> attributes as well).
>>>>>
>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/7776652f/attachment-0001.html 

From velias at redhat.com  Tue Jan 19 06:22:22 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 19 Jan 2016 12:22:22 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
	<CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
Message-ID: <569E1C6E.602@redhat.com>



On 19.1.2016 12:09, Stian Thorgersen wrote:
>
>
> On 19 January 2016 at 12:06, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>     Hi
>
>     On 19.1.2016 11:52, Stian Thorgersen wrote:
>>     If you can get it in today or tomorrow (early) we can add it to
>>     1.8.0.CR2.
>
>     will try to do this, I will provide PR against branche and the
>     another against master
>
>>     You should also be able to use the generic OpenID Connect provider.
>
>     I though about it, but if I understand it correctly I will not be
>     able to get users name, surname and email this way, as it is not
>     provided in OAuth 2 and it requires another REST call in common
>     social providers.
>
>
> Do they not have an userinfo endpoint?

They have some REST endpoint at /me path, see doc at
https://msdn.microsoft.com/en-us/library/hh826534.aspx
But I'm not sure if it match some standard or rules so generic OpenID
Connect provider can use it. What is format for UserInfo endpoint to be
useful for this provider? Keycloak documentation do not provide any
useful info about requirements for this URL (eg link to some specification).

Vlastimil

>  
>
>
>
>>
>>     Adding it yourself would require also adding templates in admin
>>     theme, shouldn't be a big deal as you only need that one template
>>     and the rest you'd inherit from Keycloak theme.
>
>     I see
>
>     Thanks
>
>
>>
>>     On 19 January 2016 at 11:10, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi,
>>
>>         I need Social login provider for Microsoft Live account. I
>>         can implement
>>         it as I did few other social login providers already.
>>
>>         Problem is that I need it in Keycloak 1.8. Any chance to add
>>         it to 1.8
>>         if I will be quick enough (PR today or tomorrow)? It is
>>         OAuth2 based
>>         provider so impl should be easy.
>>
>>         If not in KC 1.8 release, is it possible to add social
>>         provider as
>>         customization to my KC instance only? It is common provider
>>         factory so
>>         it should be possible I hope, but it also requires some
>>         template in
>>         admin theme, so I'm not sure (probably I have to create my
>>         customized
>>         admin theme in this case).
>>
>>         I definitely prefer to have it in upstream if possible.
>>
>>         Vlastimil
>>
>>         --
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From francoismaturel at dijit.fr  Tue Jan 19 06:28:04 2016
From: francoismaturel at dijit.fr (francois maturel)
Date: Tue, 19 Jan 2016 12:28:04 +0100
Subject: [keycloak-dev] Correcting French translation
Message-ID: <569E1DC4.8080407@dijit.fr>

Hello,

First of all, thanks for your wonderfull work on keycloak!
We are a development team in France using keycloak since v1.2.
There are a number of mistranslations in current French 
messages_fr.properties

Unicode characters like '\u00a9' are used, but they actually are the 
'COPYRIGHT SIGN'
Some other messages are strangely translated ;)

Would you be interested in a PR correcting those messages?

Thanks
-- 
Fran?ois Maturel

Cordialement,

Fran?ois Maturel

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

From sthorger at redhat.com  Tue Jan 19 06:54:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 12:54:56 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <569E1C6E.602@redhat.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
	<CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
	<569E1C6E.602@redhat.com>
Message-ID: <CAJgngAcDzvciEgsH+ymwkAGdbobLPZFzrM_16oLO4LX=Yg72sA@mail.gmail.com>

I wouldn't think it is. OpenID Connect usually is '.../userinfo'. As long
as '/me' returns json you can use mappers to do whatever you'd like though.

On 19 January 2016 at 12:22, Vlastimil Elias <velias at redhat.com> wrote:

>
>
> On 19.1.2016 12:09, Stian Thorgersen wrote:
>
>
>
> On 19 January 2016 at 12:06, Vlastimil Elias < <velias at redhat.com>
> velias at redhat.com> wrote:
>
>> Hi
>>
>> On 19.1.2016 11:52, Stian Thorgersen wrote:
>>
>> If you can get it in today or tomorrow (early) we can add it to 1.8.0.CR2.
>>
>>
>> will try to do this, I will provide PR against branche and the another
>> against master
>>
>> You should also be able to use the generic OpenID Connect provider.
>>
>>
>> I though about it, but if I understand it correctly I will not be able to
>> get users name, surname and email this way, as it is not provided in OAuth
>> 2 and it requires another REST call in common social providers.
>>
>
> Do they not have an userinfo endpoint?
>
>
> They have some REST endpoint at /me path, see doc at
> https://msdn.microsoft.com/en-us/library/hh826534.aspx
> But I'm not sure if it match some standard or rules so generic OpenID
> Connect provider can use it. What is format for UserInfo endpoint to be
> useful for this provider? Keycloak documentation do not provide any useful
> info about requirements for this URL (eg link to some specification).
>
> Vlastimil
>
>
>
>>
>>
>>
>> Adding it yourself would require also adding templates in admin theme,
>> shouldn't be a big deal as you only need that one template and the rest
>> you'd inherit from Keycloak theme.
>>
>>
>> I see
>>
>> Thanks
>>
>>
>>
>> On 19 January 2016 at 11:10, Vlastimil Elias < <velias at redhat.com>
>> velias at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I need Social login provider for Microsoft Live account. I can implement
>>> it as I did few other social login providers already.
>>>
>>> Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
>>> if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
>>> provider so impl should be easy.
>>>
>>> If not in KC 1.8 release, is it possible to add social provider as
>>> customization to my KC instance only? It is common provider factory so
>>> it should be possible I hope, but it also requires some template in
>>> admin theme, so I'm not sure (probably I have to create my customized
>>> admin theme in this case).
>>>
>>> I definitely prefer to have it in upstream if possible.
>>>
>>> Vlastimil
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/3b3fa3d0/attachment-0001.html 

From sthorger at redhat.com  Tue Jan 19 07:33:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 13:33:51 +0100
Subject: [keycloak-dev] Broker login events
Message-ID: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>

It seems like there's a bit of confusion with regards to what events should
be fired when a identity broker login occurs.

Initially it was LOGIN and auth_method was used to differentiate how the
user authenticated.

Then it was changed to IDENTITY_PROVIDER_LOGIN.

Now it seems to be back to LOGIN.

This is rather messy! Why has it been changed so much?

IMO it should as it was initially (LOGIN with auth_method). We also need to
make sure identity provider id and sub is included. The latter is missing
at the moment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/0285d4e3/attachment.html 

From velias at redhat.com  Tue Jan 19 07:36:59 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 19 Jan 2016 13:36:59 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <CAJgngAcDzvciEgsH+ymwkAGdbobLPZFzrM_16oLO4LX=Yg72sA@mail.gmail.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
	<CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
	<569E1C6E.602@redhat.com>
	<CAJgngAcDzvciEgsH+ymwkAGdbobLPZFzrM_16oLO4LX=Yg72sA@mail.gmail.com>
Message-ID: <569E2DEB.3030003@redhat.com>



On 19.1.2016 12:54, Stian Thorgersen wrote:
> I wouldn't think it is. OpenID Connect usually is '.../userinfo'. As
> long as '/me' returns json you can use mappers to do whatever you'd
> like though.

But MS Live API /me operation do not accept Bearer Authorization header,
documentation says access token must be sent as GET param, so it looks
like User Info URL will not work as it sends Bearer header :-(


I tried to use general OIDC connector but I end up with
13:09:25,763 ERROR
[org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] Failed to make
identity provider oauth callback
org.keycloak.broker.provider.IdentityBrokerException: No access_token
from server.
    at
org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:269)
    at
org.keycloak.broker.oidc.OIDCIdentityProvider.getFederatedIdentity(OIDCIdentityProvider.java:206)
    at
org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:229)

It is strange, looks like Token URL doesn't return access_token, it only
returns id_token. Response is like
{"id_token":"eyJ0eXAiOiJKV1Qi....","id_token_expires_in":86400}

Any idea what may be wrong? Should this id_token be used instead of
access token? If yes then I can resolve this problem in custom social
provider.

Vlastimil

>
> On 19 January 2016 at 12:22, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>
>
>     On 19.1.2016 12:09, Stian Thorgersen wrote:
>>
>>
>>     On 19 January 2016 at 12:06, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>         Hi
>>
>>         On 19.1.2016 11:52, Stian Thorgersen wrote:
>>>         If you can get it in today or tomorrow (early) we can add it
>>>         to 1.8.0.CR2.
>>
>>         will try to do this, I will provide PR against branche and
>>         the another against master
>>
>>>         You should also be able to use the generic OpenID Connect
>>>         provider.
>>
>>         I though about it, but if I understand it correctly I will
>>         not be able to get users name, surname and email this way, as
>>         it is not provided in OAuth 2 and it requires another REST
>>         call in common social providers.
>>
>>
>>     Do they not have an userinfo endpoint?
>
>     They have some REST endpoint at /me path, see doc at
>     https://msdn.microsoft.com/en-us/library/hh826534.aspx
>     But I'm not sure if it match some standard or rules so generic
>     OpenID Connect provider can use it. What is format for UserInfo
>     endpoint to be useful for this provider? Keycloak documentation do
>     not provide any useful info about requirements for this URL (eg
>     link to some specification).
>
>     Vlastimil
>
>>      
>>
>>
>>
>>>
>>>         Adding it yourself would require also adding templates in
>>>         admin theme, shouldn't be a big deal as you only need that
>>>         one template and the rest you'd inherit from Keycloak theme.
>>
>>         I see
>>
>>         Thanks
>>
>>
>>>
>>>         On 19 January 2016 at 11:10, Vlastimil Elias
>>>         <velias at redhat.com <mailto:velias at redhat.com>> wrote:
>>>
>>>             Hi,
>>>
>>>             I need Social login provider for Microsoft Live account.
>>>             I can implement
>>>             it as I did few other social login providers already.
>>>
>>>             Problem is that I need it in Keycloak 1.8. Any chance to
>>>             add it to 1.8
>>>             if I will be quick enough (PR today or tomorrow)? It is
>>>             OAuth2 based
>>>             provider so impl should be easy.
>>>
>>>             If not in KC 1.8 release, is it possible to add social
>>>             provider as
>>>             customization to my KC instance only? It is common
>>>             provider factory so
>>>             it should be possible I hope, but it also requires some
>>>             template in
>>>             admin theme, so I'm not sure (probably I have to create
>>>             my customized
>>>             admin theme in this case).
>>>
>>>             I definitely prefer to have it in upstream if possible.
>>>
>>>             Vlastimil
>>>
>>>             --
>>>             Vlastimil Elias
>>>             Principal Software Engineer
>>>             Developer Portal Engineering Team
>>>
>>>
>>>
>>>             _______________________________________________
>>>             keycloak-dev mailing list
>>>             keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>>         -- 
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Tue Jan 19 07:54:02 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 13:54:02 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <569E2DEB.3030003@redhat.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
	<CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
	<569E1C6E.602@redhat.com>
	<CAJgngAcDzvciEgsH+ymwkAGdbobLPZFzrM_16oLO4LX=Yg72sA@mail.gmail.com>
	<569E2DEB.3030003@redhat.com>
Message-ID: <CAJgngAeH+mGAgBt5w16RSZrzRdvGzf4xBBWptPYhzeTK_FLHHg@mail.gmail.com>

According to
https://msdn.microsoft.com/en-us/library/hh243649.aspx#get_access_rest it
should return an access_token. Then there's
https://msdn.microsoft.com/en-us/library/hh243649.aspx#use_access_rest to
get the user info, but you're right it's being included as a query param
(which is stupid btw).

As they are not doing OIDC I guess you'll have to do a social provider for
it.

On 19 January 2016 at 13:36, Vlastimil Elias <velias at redhat.com> wrote:

>
>
> On 19.1.2016 12:54, Stian Thorgersen wrote:
>
> I wouldn't think it is. OpenID Connect usually is '.../userinfo'. As long
> as '/me' returns json you can use mappers to do whatever you'd like though.
>
>
> But MS Live API /me operation do not accept Bearer Authorization header,
> documentation says access token must be sent as GET param, so it looks like
> User Info URL will not work as it sends Bearer header :-(
>
>
> I tried to use general OIDC connector but I end up with
> 13:09:25,763 ERROR
> [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] Failed to make
> identity provider oauth callback
> org.keycloak.broker.provider.IdentityBrokerException: No access_token from
> server.
>     at
> org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:269)
>     at
> org.keycloak.broker.oidc.OIDCIdentityProvider.getFederatedIdentity(OIDCIdentityProvider.java:206)
>     at
> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:229)
>
> It is strange, looks like Token URL doesn't return access_token, it only
> returns id_token. Response is like
> {"id_token":"eyJ0eXAiOiJKV1Qi....","id_token_expires_in":86400}
>
> Any idea what may be wrong? Should this id_token be used instead of access
> token? If yes then I can resolve this problem in custom social provider.
>
> Vlastimil
>
>
>
> On 19 January 2016 at 12:22, Vlastimil Elias <velias at redhat.com> wrote:
>
>>
>>
>> On 19.1.2016 12:09, Stian Thorgersen wrote:
>>
>>
>>
>> On 19 January 2016 at 12:06, Vlastimil Elias < <velias at redhat.com>
>> velias at redhat.com> wrote:
>>
>>> Hi
>>>
>>> On 19.1.2016 11:52, Stian Thorgersen wrote:
>>>
>>> If you can get it in today or tomorrow (early) we can add it to
>>> 1.8.0.CR2.
>>>
>>>
>>> will try to do this, I will provide PR against branche and the another
>>> against master
>>>
>>> You should also be able to use the generic OpenID Connect provider.
>>>
>>>
>>> I though about it, but if I understand it correctly I will not be able
>>> to get users name, surname and email this way, as it is not provided in
>>> OAuth 2 and it requires another REST call in common social providers.
>>>
>>
>> Do they not have an userinfo endpoint?
>>
>>
>> They have some REST endpoint at /me path, see doc at
>> https://msdn.microsoft.com/en-us/library/hh826534.aspx
>> But I'm not sure if it match some standard or rules so generic OpenID
>> Connect provider can use it. What is format for UserInfo endpoint to be
>> useful for this provider? Keycloak documentation do not provide any useful
>> info about requirements for this URL (eg link to some specification).
>>
>> Vlastimil
>>
>>
>>
>>>
>>>
>>>
>>> Adding it yourself would require also adding templates in admin theme,
>>> shouldn't be a big deal as you only need that one template and the rest
>>> you'd inherit from Keycloak theme.
>>>
>>>
>>> I see
>>>
>>> Thanks
>>>
>>>
>>>
>>> On 19 January 2016 at 11:10, Vlastimil Elias < <velias at redhat.com>
>>> velias at redhat.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I need Social login provider for Microsoft Live account. I can implement
>>>> it as I did few other social login providers already.
>>>>
>>>> Problem is that I need it in Keycloak 1.8. Any chance to add it to 1.8
>>>> if I will be quick enough (PR today or tomorrow)? It is OAuth2 based
>>>> provider so impl should be easy.
>>>>
>>>> If not in KC 1.8 release, is it possible to add social provider as
>>>> customization to my KC instance only? It is common provider factory so
>>>> it should be possible I hope, but it also requires some template in
>>>> admin theme, so I'm not sure (probably I have to create my customized
>>>> admin theme in this case).
>>>>
>>>> I definitely prefer to have it in upstream if possible.
>>>>
>>>> Vlastimil
>>>>
>>>> --
>>>> Vlastimil Elias
>>>> Principal Software Engineer
>>>> Developer Portal Engineering Team
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/57fe2801/attachment-0001.html 

From velias at redhat.com  Tue Jan 19 10:49:32 2016
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 19 Jan 2016 16:49:32 +0100
Subject: [keycloak-dev] Social login provider for Microsoft Live
In-Reply-To: <CAJgngAeH+mGAgBt5w16RSZrzRdvGzf4xBBWptPYhzeTK_FLHHg@mail.gmail.com>
References: <569E0BA5.5030604@redhat.com>
	<CAJgngAdBfyD6oxm4xGPTxtSPTBfu1VRkH=fUEU-OTtp7vqm2aw@mail.gmail.com>
	<569E18C8.5090401@redhat.com>
	<CAJgngAdk6UT2sXTu2eWLhm0VZeexP-X3r7Qcqgo3bh-Q3ETjnw@mail.gmail.com>
	<569E1C6E.602@redhat.com>
	<CAJgngAcDzvciEgsH+ymwkAGdbobLPZFzrM_16oLO4LX=Yg72sA@mail.gmail.com>
	<569E2DEB.3030003@redhat.com>
	<CAJgngAeH+mGAgBt5w16RSZrzRdvGzf4xBBWptPYhzeTK_FLHHg@mail.gmail.com>
Message-ID: <569E5B0C.4090808@redhat.com>

Hi

Custom social provider works like a charm, I created PR #2058 for KC 1.8
branch. I'll provide another PR for master branch later once module
re-org will be done.

Vlastimil

On 19.1.2016 13:54, Stian Thorgersen wrote:
> According
> to https://msdn.microsoft.com/en-us/library/hh243649.aspx#get_access_rest
> it should return an access_token. Then
> there's https://msdn.microsoft.com/en-us/library/hh243649.aspx#use_access_rest
> to get the user info, but you're right it's being included as a query
> param (which is stupid btw).

:-D

>
> As they are not doing OIDC I guess you'll have to do a social provider
> for it.
>
> On 19 January 2016 at 13:36, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>
>
>     On 19.1.2016 12:54, Stian Thorgersen wrote:
>>     I wouldn't think it is. OpenID Connect usually is '.../userinfo'.
>>     As long as '/me' returns json you can use mappers to do whatever
>>     you'd like though.
>
>     But MS Live API /me operation do not accept Bearer Authorization
>     header, documentation says access token must be sent as GET param,
>     so it looks like User Info URL will not work as it sends Bearer
>     header :-(
>
>
>     I tried to use general OIDC connector but I end up with
>     13:09:25,763 ERROR
>     [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] Failed
>     to make identity provider oauth callback
>     org.keycloak.broker.provider.IdentityBrokerException: No
>     access_token from server.
>         at
>     org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:269)
>         at
>     org.keycloak.broker.oidc.OIDCIdentityProvider.getFederatedIdentity(OIDCIdentityProvider.java:206)
>         at
>     org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:229)
>
>     It is strange, looks like Token URL doesn't return access_token,
>     it only returns id_token. Response is like
>     {"id_token":"eyJ0eXAiOiJKV1Qi....","id_token_expires_in":86400}
>
>     Any idea what may be wrong? Should this id_token be used instead
>     of access token? If yes then I can resolve this problem in custom
>     social provider.
>
>     Vlastimil
>
>
>>
>>     On 19 January 2016 at 12:22, Vlastimil Elias <velias at redhat.com
>>     <mailto:velias at redhat.com>> wrote:
>>
>>
>>
>>         On 19.1.2016 12:09, Stian Thorgersen wrote:
>>>
>>>
>>>         On 19 January 2016 at 12:06, Vlastimil Elias
>>>         <velias at redhat.com <mailto:velias at redhat.com>> wrote:
>>>
>>>             Hi
>>>
>>>             On 19.1.2016 11:52, Stian Thorgersen wrote:
>>>>             If you can get it in today or tomorrow (early) we can
>>>>             add it to 1.8.0.CR2.
>>>
>>>             will try to do this, I will provide PR against branche
>>>             and the another against master
>>>
>>>>             You should also be able to use the generic OpenID
>>>>             Connect provider.
>>>
>>>             I though about it, but if I understand it correctly I
>>>             will not be able to get users name, surname and email
>>>             this way, as it is not provided in OAuth 2 and it
>>>             requires another REST call in common social providers.
>>>
>>>
>>>         Do they not have an userinfo endpoint?
>>
>>         They have some REST endpoint at /me path, see doc at
>>         https://msdn.microsoft.com/en-us/library/hh826534.aspx
>>         But I'm not sure if it match some standard or rules so
>>         generic OpenID Connect provider can use it. What is format
>>         for UserInfo endpoint to be useful for this provider?
>>         Keycloak documentation do not provide any useful info about
>>         requirements for this URL (eg link to some specification).
>>
>>         Vlastimil
>>
>>>          
>>>
>>>
>>>
>>>>
>>>>             Adding it yourself would require also adding templates
>>>>             in admin theme, shouldn't be a big deal as you only
>>>>             need that one template and the rest you'd inherit from
>>>>             Keycloak theme.
>>>
>>>             I see
>>>
>>>             Thanks
>>>
>>>
>>>>
>>>>             On 19 January 2016 at 11:10, Vlastimil Elias
>>>>             <velias at redhat.com <mailto:velias at redhat.com>> wrote:
>>>>
>>>>                 Hi,
>>>>
>>>>                 I need Social login provider for Microsoft Live
>>>>                 account. I can implement
>>>>                 it as I did few other social login providers already.
>>>>
>>>>                 Problem is that I need it in Keycloak 1.8. Any
>>>>                 chance to add it to 1.8
>>>>                 if I will be quick enough (PR today or tomorrow)?
>>>>                 It is OAuth2 based
>>>>                 provider so impl should be easy.
>>>>
>>>>                 If not in KC 1.8 release, is it possible to add
>>>>                 social provider as
>>>>                 customization to my KC instance only? It is common
>>>>                 provider factory so
>>>>                 it should be possible I hope, but it also requires
>>>>                 some template in
>>>>                 admin theme, so I'm not sure (probably I have to
>>>>                 create my customized
>>>>                 admin theme in this case).
>>>>
>>>>                 I definitely prefer to have it in upstream if possible.
>>>>
>>>>                 Vlastimil
>>>>
>>>>                 --
>>>>                 Vlastimil Elias
>>>>                 Principal Software Engineer
>>>>                 Developer Portal Engineering Team
>>>>
>>>>
>>>>
>>>>                 _______________________________________________
>>>>                 keycloak-dev mailing list
>>>>                 keycloak-dev at lists.jboss.org
>>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>
>>>             -- 
>>>             Vlastimil Elias
>>>             Principal Software Engineer
>>>             Developer Portal Engineering Team
>>>
>>>
>>
>>         -- 
>>         Vlastimil Elias
>>         Principal Software Engineer
>>         Developer Portal Engineering Team
>>
>>
>
>     -- 
>     Vlastimil Elias
>     Principal Software Engineer
>     Developer Portal Engineering Team
>
>

-- 
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team

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

From sthorger at redhat.com  Tue Jan 19 13:52:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 19:52:41 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
	<CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
	<CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>
Message-ID: <CAJgngAe2JiL=AN6owB=mrS8f0bP-7PBtSHNJHW5=6ocRfkb8Jg@mail.gmail.com>

We've decided to leave the admin endpoints as is for 1.x series. In 2.x
series we'll introduce a version 2 of the API which won't be backwards
compatible. This will give us greater flexibility in improving the API, but
still support the older API for some time.

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

> I just wanted to ensure backwards compatibility - an additional parameter
> would break (java) API
> consumers who are currently using the keycloak-admin-client, since they
> are potentially using the
> variant without the parameter.
> This would of course be no problem for REST API consumers.
>
> What I see as a problem though is the behaviour change of the search
> behaviour by default ...
> (knowing the current API) I'd rather expect that the search would perform
> the same as before
> with fuzzy matching /by default/ and support for exact match if explicitly
> stated.
>
> However having a search operation that performs an exact search by
> default "feels" more natural to me - so I'm fine with your suggestion as a
> quick solution :)
>

> Regarding urls:
> I'd rather prefer to have some dedicated search sub-resources per entity -
> but that is a more general topic...
> With this approach one would be more flexible with respect to supported
> searches
> that could behave completly different.
>
> Entity lookups by id
>   /entity/{id}
>
> Dedicated lookup sub-resource for other attribute lookups: (here I'd
> expect exactly 0 or 1 results)
>   /entity/lookup/byName?name=someName
>   /entity/lookup/byEmail?email=someEmail
>
> Dedicated search sub-resources:  (here I'd expect 0 or n results)
>
>   /entity/search/byName?name=someName
>   /entity/search/byNameMatching?pattern=someName
>   /entity/search/byAttributes?firstname=firstname&lastname=lastname
>

-1 A single resource with different query params is much cleaner IMO


>
> In addition to that one could also allow @POST requests to these
> (sub-)resources
> where the actual parameters are extracted from form-parameters in order
> to avoid leaking user information like username, email, etc. in access
> logs.
> I think this would be relevant for an application that deals with security
> sensitive information
> like keycloak does.
>

Agree with the security sensitivity, but it sounds very non-rest


>
> Cheers,
> Thomas
>
>
> 2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> -1 To additional search method. URL should be '.../users'.
>>
>> Simplest is just to change what we have now to not included wildcards.
>> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
>> Default should be false. Alternatives are:
>>
>> * Let users add % themselves
>> * Add separate query params for fuzzy
>>
>> On 19 January 2016 at 10:27, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> Hello,
>>>
>>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track this.
>>>
>>> Cheers,
>>> Thomas
>>>
>>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>>> thomas.darimont at googlemail.com>:
>>>
>>>> Okay, how about offering a new search method that accepts s UserSearch
>>>> DTO that would hold the attributes to search by
>>>> as well as a "match mode". Could also be used to specify pagination.
>>>>
>>>> This could also be send via a @POST in order to avoid retaining
>>>> userdata like usernames, email addresses etc. in
>>>> access logs...
>>>>
>>>> Alternatively you could introduce a searchExact(..) method with the
>>>> same parameterization as the existing search method.
>>>>
>>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>
>>>>> It was by design, but it wasn't a good design. Would be better to make
>>>>> it match exact, but allow including a wildcard to make it fuzzy.
>>>>>
>>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was looking for a way to query users based on their exact username
>>>>>> but it turned out, that
>>>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>>> String, String, String, Integer, Integer)
>>>>>>
>>>>>>   @GET
>>>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>>>> username,
>>>>>>                                        @QueryParam("firstName")
>>>>>> String firstName,
>>>>>>                                        @QueryParam("lastName") String
>>>>>> lastName,
>>>>>>                                        @QueryParam("email") String
>>>>>> email,
>>>>>>                                        @QueryParam("first") Integer
>>>>>> firstResult,
>>>>>>                                        @QueryParam("max") Integer
>>>>>> maxResults);
>>>>>>
>>>>>>   ...
>>>>>>   usersResource.search("exactusername",null,null, null, null, email,
>>>>>> 0, 10)
>>>>>>
>>>>>> generates a like %..% query in
>>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>>
>>>>>> Since usernames are unique per realm I think it would make sense to
>>>>>> be able to perform a
>>>>>> query for the exact username (or perhaps the combination of other
>>>>>> attributes as well).
>>>>>>
>>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/451b7ecd/attachment-0001.html 

From sthorger at redhat.com  Tue Jan 19 14:03:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 20:03:24 +0100
Subject: [keycloak-dev] Keycloak Docker Image with Postgres HA with
 1.8.CR1 doesn't work.
In-Reply-To: <CAK-7U1gyppEoO3fnT7wRAYZKV+ggD0FMzM0zcS22KgcjGwNiTg@mail.gmail.com>
References: <CAK-7U1gyppEoO3fnT7wRAYZKV+ggD0FMzM0zcS22KgcjGwNiTg@mail.gmail.com>
Message-ID: <CAJgngAdkDaarn6moS6qUjwrPdgd+xsVycWYy3T8-8r57+1oz8A@mail.gmail.com>

Fixed in master (rebuilding now) and will be fixed in 1.8.0.CR2 due to be
released soon

On 18 January 2016 at 16:06, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Hello,
>
> I just tried the server-ha-postgres Docker image and I wasn't able to run
> it.
>
> https://github.com/jboss-dockerfiles/keycloak/tree/master/server-ha-postgres
>
> The other images (server, server-postgres) work.
>
> When I try to run the "server-ha-postgres" example I see:
>
> 14:54:35,888 INFO  [org.jboss.modules] (main) JBoss Modules version
> 1.5.0.Final
> WFLYSRV0073: Invalid option '/opt/jboss/keycloak/bin/start.sh'
>
> It seems that this command:
> https://github.com/jboss-dockerfiles/keycloak/blob/bfbbde898e4aba3b3ee517052b981f68b7fb6d04/server-ha-postgres/Dockerfile#L9
> is not properly passed to the start script.
> Building the image locally with that line commented seems to work...
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/16038c23/attachment.html 

From sthorger at redhat.com  Tue Jan 19 14:08:32 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 20:08:32 +0100
Subject: [keycloak-dev] Correcting French translation
In-Reply-To: <569E1DC4.8080407@dijit.fr>
References: <569E1DC4.8080407@dijit.fr>
Message-ID: <CAJgngAdQGhTYF38d2KqqXoG_TQX5_UL1Fd=PnZq266cz5kfBFw@mail.gmail.com>

The property files are iso-8859-1. I've just checked and:

kerberosNotConfigured=Kerberos non configur\u00e9

Outputs:

Kerberos non configur?

So looks like it's correct to me

On 19 January 2016 at 12:28, francois maturel <francoismaturel at dijit.fr>
wrote:

> Hello,
>
> First of all, thanks for your wonderfull work on keycloak!
> We are a development team in France using keycloak since v1.2.
> There are a number of mistranslations in current French
> messages_fr.properties
>
> Unicode characters like '\u00a9' are used, but they actually are the
> 'COPYRIGHT SIGN'
> Some other messages are strangely translated ;)
>
> Would you be interested in a PR correcting those messages?
>
> Thanks
> --
>
> Cordialement,
>
> Fran?ois Maturel
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/4a5b6ece/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 19 14:48:29 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 20:48:29 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAJgngAe2JiL=AN6owB=mrS8f0bP-7PBtSHNJHW5=6ocRfkb8Jg@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
	<CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
	<CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>
	<CAJgngAe2JiL=AN6owB=mrS8f0bP-7PBtSHNJHW5=6ocRfkb8Jg@mail.gmail.com>
Message-ID: <CAK-7U1gtbbimAE_B_9VE6rgbjpOA+DwiRTn13oQLXHFZ-YjuNQ@mail.gmail.com>

Answers inline

2016-01-19 19:52 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

> We've decided to leave the admin endpoints as is for 1.x series. In 2.x
> series we'll introduce a version 2 of the API which won't be backwards
> compatible. This will give us greater flexibility in improving the API, but
> still support the older API for some time.
>
>
Sounds reasonable - will keep that in mind!


> On 19 January 2016 at 12:20, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> I just wanted to ensure backwards compatibility - an additional parameter
>> would break (java) API
>> consumers who are currently using the keycloak-admin-client, since they
>> are potentially using the
>> variant without the parameter.
>> This would of course be no problem for REST API consumers.
>>
>> What I see as a problem though is the behaviour change of the search
>> behaviour by default ...
>> (knowing the current API) I'd rather expect that the search would perform
>> the same as before
>> with fuzzy matching /by default/ and support for exact match if
>> explicitly stated.
>>
>> However having a search operation that performs an exact search by
>> default "feels" more natural to me - so I'm fine with your suggestion as
>> a quick solution :)
>>
>
>> Regarding urls:
>> I'd rather prefer to have some dedicated search sub-resources per entity
>> - but that is a more general topic...
>> With this approach one would be more flexible with respect to supported
>> searches
>> that could behave completly different.
>>
>> Entity lookups by id
>>   /entity/{id}
>>
>> Dedicated lookup sub-resource for other attribute lookups: (here I'd
>> expect exactly 0 or 1 results)
>>   /entity/lookup/byName?name=someName
>>   /entity/lookup/byEmail?email=someEmail
>>
>> Dedicated search sub-resources:  (here I'd expect 0 or n results)
>>
>>   /entity/search/byName?name=someName
>>   /entity/search/byNameMatching?pattern=someName
>>   /entity/search/byAttributes?firstname=firstname&lastname=lastname
>>
>
> -1 A single resource with different query params is much cleaner IMO
>
>
Yes and no, it may look cleaner to some degree in the beginning but once
more sophisticated
user searches / lookups become necessary it can turn into a mess because
one has to deal
with a bunch of different parameters and handle the resulting parameter
combinations in a proper way.
Having dedicated search endpoints makes it easier to provide narrowly
focused search APIs IMHO.


>
>> In addition to that one could also allow @POST requests to these
>> (sub-)resources
>> where the actual parameters are extracted from form-parameters in order
>> to avoid leaking user information like username, email, etc. in access
>> logs.
>> I think this would be relevant for an application that deals with
>> security sensitive information
>> like keycloak does.
>>
>
> Agree with the security sensitivity, but it sounds very non-rest
>
>
Yes indeed, that's one occasion where one has to deviate from traditional
rest teachings for the sake of security ;-)
Although using POST requests don't make the whole app more secure but
helps, as said to not leave unnecessary
traces in proxy / access logs etc.
http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other


>
>> Cheers,
>> Thomas
>>
>>
>> 2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> -1 To additional search method. URL should be '.../users'.
>>>
>>> Simplest is just to change what we have now to not included wildcards.
>>> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
>>> Default should be false. Alternatives are:
>>>
>>> * Let users add % themselves
>>> * Add separate query params for fuzzy
>>>
>>> On 19 January 2016 at 10:27, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track this.
>>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>>>> thomas.darimont at googlemail.com>:
>>>>
>>>>> Okay, how about offering a new search method that accepts s UserSearch
>>>>> DTO that would hold the attributes to search by
>>>>> as well as a "match mode". Could also be used to specify pagination.
>>>>>
>>>>> This could also be send via a @POST in order to avoid retaining
>>>>> userdata like usernames, email addresses etc. in
>>>>> access logs...
>>>>>
>>>>> Alternatively you could introduce a searchExact(..) method with the
>>>>> same parameterization as the existing search method.
>>>>>
>>>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>
>>>>>> It was by design, but it wasn't a good design. Would be better to
>>>>>> make it match exact, but allow including a wildcard to make it fuzzy.
>>>>>>
>>>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was looking for a way to query users based on their exact username
>>>>>>> but it turned out, that
>>>>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>>>> String, String, String, Integer, Integer)
>>>>>>>
>>>>>>>   @GET
>>>>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>>>>> username,
>>>>>>>                                        @QueryParam("firstName")
>>>>>>> String firstName,
>>>>>>>                                        @QueryParam("lastName")
>>>>>>> String lastName,
>>>>>>>                                        @QueryParam("email") String
>>>>>>> email,
>>>>>>>                                        @QueryParam("first") Integer
>>>>>>> firstResult,
>>>>>>>                                        @QueryParam("max") Integer
>>>>>>> maxResults);
>>>>>>>
>>>>>>>   ...
>>>>>>>   usersResource.search("exactusername",null,null, null, null, email,
>>>>>>> 0, 10)
>>>>>>>
>>>>>>> generates a like %..% query in
>>>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>>>
>>>>>>> Since usernames are unique per realm I think it would make sense to
>>>>>>> be able to perform a
>>>>>>> query for the exact username (or perhaps the combination of other
>>>>>>> attributes as well).
>>>>>>>
>>>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Thomas
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/7f606c5b/attachment-0001.html 

From sthorger at redhat.com  Tue Jan 19 14:54:36 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 19 Jan 2016 20:54:36 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAK-7U1gtbbimAE_B_9VE6rgbjpOA+DwiRTn13oQLXHFZ-YjuNQ@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
	<CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
	<CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>
	<CAJgngAe2JiL=AN6owB=mrS8f0bP-7PBtSHNJHW5=6ocRfkb8Jg@mail.gmail.com>
	<CAK-7U1gtbbimAE_B_9VE6rgbjpOA+DwiRTn13oQLXHFZ-YjuNQ@mail.gmail.com>
Message-ID: <CAJgngAfQcz1iLxk4Sgn6hAqnfi8p_jvgRsdZypuRXia8pxzbgA@mail.gmail.com>

On 19 January 2016 at 20:48, Thomas Darimont <thomas.darimont at googlemail.com
> wrote:

> Answers inline
>
> 2016-01-19 19:52 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We've decided to leave the admin endpoints as is for 1.x series. In 2.x
>> series we'll introduce a version 2 of the API which won't be backwards
>> compatible. This will give us greater flexibility in improving the API, but
>> still support the older API for some time.
>>
>>
> Sounds reasonable - will keep that in mind!
>
>
>> On 19 January 2016 at 12:20, Thomas Darimont <
>> thomas.darimont at googlemail.com> wrote:
>>
>>> I just wanted to ensure backwards compatibility - an additional
>>> parameter would break (java) API
>>> consumers who are currently using the keycloak-admin-client, since they
>>> are potentially using the
>>> variant without the parameter.
>>> This would of course be no problem for REST API consumers.
>>>
>>> What I see as a problem though is the behaviour change of the search
>>> behaviour by default ...
>>> (knowing the current API) I'd rather expect that the search would
>>> perform the same as before
>>> with fuzzy matching /by default/ and support for exact match if
>>> explicitly stated.
>>>
>>> However having a search operation that performs an exact search by
>>> default "feels" more natural to me - so I'm fine with your suggestion as
>>> a quick solution :)
>>>
>>
>>> Regarding urls:
>>> I'd rather prefer to have some dedicated search sub-resources per entity
>>> - but that is a more general topic...
>>> With this approach one would be more flexible with respect to supported
>>> searches
>>> that could behave completly different.
>>>
>>> Entity lookups by id
>>>   /entity/{id}
>>>
>>> Dedicated lookup sub-resource for other attribute lookups: (here I'd
>>> expect exactly 0 or 1 results)
>>>   /entity/lookup/byName?name=someName
>>>   /entity/lookup/byEmail?email=someEmail
>>>
>>> Dedicated search sub-resources:  (here I'd expect 0 or n results)
>>>
>>>   /entity/search/byName?name=someName
>>>   /entity/search/byNameMatching?pattern=someName
>>>   /entity/search/byAttributes?firstname=firstname&lastname=lastname
>>>
>>
>> -1 A single resource with different query params is much cleaner IMO
>>
>>
> Yes and no, it may look cleaner to some degree in the beginning but once
> more sophisticated
> user searches / lookups become necessary it can turn into a mess because
> one has to deal
> with a bunch of different parameters and handle the resulting parameter
> combinations in a proper way.
> Having dedicated search endpoints makes it easier to provide narrowly
> focused search APIs IMHO.
>

It always depends. I can't see us providing so many different search
endpoints that having multiple different endpoints will be cleaner. Having
one endpoint with multiple params also provides more flexibility. For even
more flexibility you can use something along what Mongo does to include a
complex json object for the search params.


>
>
>>
>>> In addition to that one could also allow @POST requests to these
>>> (sub-)resources
>>> where the actual parameters are extracted from form-parameters in order
>>> to avoid leaking user information like username, email, etc. in access
>>> logs.
>>> I think this would be relevant for an application that deals with
>>> security sensitive information
>>> like keycloak does.
>>>
>>
>> Agree with the security sensitivity, but it sounds very non-rest
>>
>>
> Yes indeed, that's one occasion where one has to deviate from traditional
> rest teachings for the sake of security ;-)
> Although using POST requests don't make the whole app more secure but
> helps, as said to not leave unnecessary
> traces in proxy / access logs etc.
>
> http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other
>

Assuming HTTPS is used then the only place that query params could be
leaked is in the web server log, so wouldn't it be more sensible to make
sure they are not included in the server logs?


>
>
>>
>>> Cheers,
>>> Thomas
>>>
>>>
>>> 2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>
>>>> -1 To additional search method. URL should be '.../users'.
>>>>
>>>> Simplest is just to change what we have now to not included wildcards.
>>>> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
>>>> Default should be false. Alternatives are:
>>>>
>>>> * Let users add % themselves
>>>> * Add separate query params for fuzzy
>>>>
>>>> On 19 January 2016 at 10:27, Thomas Darimont <
>>>> thomas.darimont at googlemail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track
>>>>> this.
>>>>>
>>>>> Cheers,
>>>>> Thomas
>>>>>
>>>>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>>>>> thomas.darimont at googlemail.com>:
>>>>>
>>>>>> Okay, how about offering a new search method that accepts s
>>>>>> UserSearch DTO that would hold the attributes to search by
>>>>>> as well as a "match mode". Could also be used to specify pagination.
>>>>>>
>>>>>> This could also be send via a @POST in order to avoid retaining
>>>>>> userdata like usernames, email addresses etc. in
>>>>>> access logs...
>>>>>>
>>>>>> Alternatively you could introduce a searchExact(..) method with the
>>>>>> same parameterization as the existing search method.
>>>>>>
>>>>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>>
>>>>>>> It was by design, but it wasn't a good design. Would be better to
>>>>>>> make it match exact, but allow including a wildcard to make it fuzzy.
>>>>>>>
>>>>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was looking for a way to query users based on their exact
>>>>>>>> username but it turned out, that
>>>>>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>>>>> String, String, String, Integer, Integer)
>>>>>>>>
>>>>>>>>   @GET
>>>>>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>>>>>> username,
>>>>>>>>                                        @QueryParam("firstName")
>>>>>>>> String firstName,
>>>>>>>>                                        @QueryParam("lastName")
>>>>>>>> String lastName,
>>>>>>>>                                        @QueryParam("email") String
>>>>>>>> email,
>>>>>>>>                                        @QueryParam("first") Integer
>>>>>>>> firstResult,
>>>>>>>>                                        @QueryParam("max") Integer
>>>>>>>> maxResults);
>>>>>>>>
>>>>>>>>   ...
>>>>>>>>   usersResource.search("exactusername",null,null, null, null,
>>>>>>>> email, 0, 10)
>>>>>>>>
>>>>>>>> generates a like %..% query in
>>>>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>>>>
>>>>>>>> Since usernames are unique per realm I think it would make sense to
>>>>>>>> be able to perform a
>>>>>>>> query for the exact username (or perhaps the combination of other
>>>>>>>> attributes as well).
>>>>>>>>
>>>>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/a3bd599d/attachment.html 

From thomas.darimont at googlemail.com  Tue Jan 19 15:06:50 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Tue, 19 Jan 2016 21:06:50 +0100
Subject: [keycloak-dev] Allow to search for users by exact attribute
	match.
In-Reply-To: <CAJgngAfQcz1iLxk4Sgn6hAqnfi8p_jvgRsdZypuRXia8pxzbgA@mail.gmail.com>
References: <CAK-7U1jhDJBXrF2tOgiMO8rWQuhzOXSksBmxxvpg34igpXV3zw@mail.gmail.com>
	<CAJgngAfP4A88Exv2JybAyrZKHdmJ-=aoDkR2jwZgjwU34zYfpA@mail.gmail.com>
	<CAK-7U1jHDmERcyRh5OuA5m5jxDN3H02ovm1fXZ0VRZ8AQE44nw@mail.gmail.com>
	<CAK-7U1gQ3Tk=-tJiDvFj9NK+zft_f1gyJCm5GDffnsaM8f_Ydg@mail.gmail.com>
	<CAJgngAca9T0JVeBmrgwjLAce2rg1PTB=g7x4V7SenU1FXgf+=A@mail.gmail.com>
	<CAK-7U1jin49P9t5MG_hd679bUb-_sqJXFYDS6Z2v28L=5_qEnA@mail.gmail.com>
	<CAJgngAe2JiL=AN6owB=mrS8f0bP-7PBtSHNJHW5=6ocRfkb8Jg@mail.gmail.com>
	<CAK-7U1gtbbimAE_B_9VE6rgbjpOA+DwiRTn13oQLXHFZ-YjuNQ@mail.gmail.com>
	<CAJgngAfQcz1iLxk4Sgn6hAqnfi8p_jvgRsdZypuRXia8pxzbgA@mail.gmail.com>
Message-ID: <CAK-7U1ifDaeGbkwSmVeaR46F4RnEn8350WRWf8HK8+y7V8mXrw@mail.gmail.com>

2016-01-19 20:54 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:

>
>
> On 19 January 2016 at 20:48, Thomas Darimont <
> thomas.darimont at googlemail.com> wrote:
>
>> Answers inline
>>
>> 2016-01-19 19:52 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>
>>> We've decided to leave the admin endpoints as is for 1.x series. In 2.x
>>> series we'll introduce a version 2 of the API which won't be backwards
>>> compatible. This will give us greater flexibility in improving the API, but
>>> still support the older API for some time.
>>>
>>>
>> Sounds reasonable - will keep that in mind!
>>
>>
>>> On 19 January 2016 at 12:20, Thomas Darimont <
>>> thomas.darimont at googlemail.com> wrote:
>>>
>>>> I just wanted to ensure backwards compatibility - an additional
>>>> parameter would break (java) API
>>>> consumers who are currently using the keycloak-admin-client, since they
>>>> are potentially using the
>>>> variant without the parameter.
>>>> This would of course be no problem for REST API consumers.
>>>>
>>>> What I see as a problem though is the behaviour change of the search
>>>> behaviour by default ...
>>>> (knowing the current API) I'd rather expect that the search would
>>>> perform the same as before
>>>> with fuzzy matching /by default/ and support for exact match if
>>>> explicitly stated.
>>>>
>>>> However having a search operation that performs an exact search by
>>>> default "feels" more natural to me - so I'm fine with your suggestion
>>>> as a quick solution :)
>>>>
>>>
>>>> Regarding urls:
>>>> I'd rather prefer to have some dedicated search sub-resources per
>>>> entity - but that is a more general topic...
>>>> With this approach one would be more flexible with respect to supported
>>>> searches
>>>> that could behave completly different.
>>>>
>>>> Entity lookups by id
>>>>   /entity/{id}
>>>>
>>>> Dedicated lookup sub-resource for other attribute lookups: (here I'd
>>>> expect exactly 0 or 1 results)
>>>>   /entity/lookup/byName?name=someName
>>>>   /entity/lookup/byEmail?email=someEmail
>>>>
>>>> Dedicated search sub-resources:  (here I'd expect 0 or n results)
>>>>
>>>>   /entity/search/byName?name=someName
>>>>   /entity/search/byNameMatching?pattern=someName
>>>>   /entity/search/byAttributes?firstname=firstname&lastname=lastname
>>>>
>>>
>>> -1 A single resource with different query params is much cleaner IMO
>>>
>>>
>> Yes and no, it may look cleaner to some degree in the beginning but once
>> more sophisticated
>> user searches / lookups become necessary it can turn into a mess because
>> one has to deal
>> with a bunch of different parameters and handle the resulting parameter
>> combinations in a proper way.
>> Having dedicated search endpoints makes it easier to provide narrowly
>> focused search APIs IMHO.
>>
>
> It always depends. I can't see us providing so many different search
> endpoints that having multiple different endpoints will be cleaner. Having
> one endpoint with multiple params also provides more flexibility. For even
> more flexibility you can use something along what Mongo does to include a
> complex json object for the search params.
>
>
Yes, generally I agree - but I'm a bit biased since I come from a Spring
Data Rest background:
http://docs.spring.io/spring-data/rest/docs/current/reference/html/#repository-resources.search-resource
having dedicated resources makes it IMHO easier to build self-describing
discoverable hypermedia REST endpoints
since it is easier to represent sub resources via dedicated rels then
refering to a subset or permutation of query parameters.


>>
>>>
>>>> In addition to that one could also allow @POST requests to these
>>>> (sub-)resources
>>>> where the actual parameters are extracted from form-parameters in order
>>>> to avoid leaking user information like username, email, etc. in access
>>>> logs.
>>>> I think this would be relevant for an application that deals with
>>>> security sensitive information
>>>> like keycloak does.
>>>>
>>>
>>> Agree with the security sensitivity, but it sounds very non-rest
>>>
>>>
>> Yes indeed, that's one occasion where one has to deviate from traditional
>> rest teachings for the sake of security ;-)
>> Although using POST requests don't make the whole app more secure but
>> helps, as said to not leave unnecessary
>> traces in proxy / access logs etc.
>>
>> http://stackoverflow.com/questions/198462/is-either-get-or-post-more-secure-than-the-other
>>
>
> Assuming HTTPS is used then the only place that query params could be
> leaked is in the web server log, so wouldn't it be more sensible to make
> sure they are not included in the server logs?
>
>
Yes that's right one has many options here - using POST requests are an
easy way to do so.

>
>>
>>>
>>>> Cheers,
>>>> Thomas
>>>>
>>>>
>>>> 2016-01-19 11:49 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>
>>>>> -1 To additional search method. URL should be '.../users'.
>>>>>
>>>>> Simplest is just to change what we have now to not included wildcards.
>>>>> Then add an extra query param "fuzzy". If fuzzy=true then we'd add %.
>>>>> Default should be false. Alternatives are:
>>>>>
>>>>> * Let users add % themselves
>>>>> * Add separate query params for fuzzy
>>>>>
>>>>> On 19 January 2016 at 10:27, Thomas Darimont <
>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I created: https://issues.jboss.org/browse/KEYCLOAK-2343 to track
>>>>>> this.
>>>>>>
>>>>>> Cheers,
>>>>>> Thomas
>>>>>>
>>>>>> 2016-01-19 10:15 GMT+01:00 Thomas Darimont <
>>>>>> thomas.darimont at googlemail.com>:
>>>>>>
>>>>>>> Okay, how about offering a new search method that accepts s
>>>>>>> UserSearch DTO that would hold the attributes to search by
>>>>>>> as well as a "match mode". Could also be used to specify pagination.
>>>>>>>
>>>>>>> This could also be send via a @POST in order to avoid retaining
>>>>>>> userdata like usernames, email addresses etc. in
>>>>>>> access logs...
>>>>>>>
>>>>>>> Alternatively you could introduce a searchExact(..) method with the
>>>>>>> same parameterization as the existing search method.
>>>>>>>
>>>>>>> 2016-01-19 10:07 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>>>>>>>
>>>>>>>> It was by design, but it wasn't a good design. Would be better to
>>>>>>>> make it match exact, but allow including a wildcard to make it fuzzy.
>>>>>>>>
>>>>>>>> On 19 January 2016 at 09:58, Thomas Darimont <
>>>>>>>> thomas.darimont at googlemail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was looking for a way to query users based on their exact
>>>>>>>>> username but it turned out, that
>>>>>>>>>   org.keycloak.admin.client.resource.UsersResource.search(String,
>>>>>>>>> String, String, String, Integer, Integer)
>>>>>>>>>
>>>>>>>>>   @GET
>>>>>>>>>   @Produces(MediaType.APPLICATION_JSON)
>>>>>>>>>   List<UserRepresentation> search(@QueryParam("username") String
>>>>>>>>> username,
>>>>>>>>>                                        @QueryParam("firstName")
>>>>>>>>> String firstName,
>>>>>>>>>                                        @QueryParam("lastName")
>>>>>>>>> String lastName,
>>>>>>>>>                                        @QueryParam("email") String
>>>>>>>>> email,
>>>>>>>>>                                        @QueryParam("first")
>>>>>>>>> Integer firstResult,
>>>>>>>>>                                        @QueryParam("max") Integer
>>>>>>>>> maxResults);
>>>>>>>>>
>>>>>>>>>   ...
>>>>>>>>>   usersResource.search("exactusername",null,null, null, null,
>>>>>>>>> email, 0, 10)
>>>>>>>>>
>>>>>>>>> generates a like %..% query in
>>>>>>>>> JpaUserProvider.searchForUserByAttributes(...).
>>>>>>>>>
>>>>>>>>> Since usernames are unique per realm I think it would make sense
>>>>>>>>> to be able to perform a
>>>>>>>>> query for the exact username (or perhaps the combination of other
>>>>>>>>> attributes as well).
>>>>>>>>>
>>>>>>>>> Was this omitted by design, or may I create a JIRA for this?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Thomas
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/3a6d7b79/attachment-0001.html 

From jorsol at gmail.com  Tue Jan 19 23:50:03 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Tue, 19 Jan 2016 22:50:03 -0600
Subject: [keycloak-dev] Relation to JSR-375
Message-ID: <CA+cVU8PaZNrJRt7LLDNAgLy6PzEsUU79zYA-iJwQn=e6jxRcCA@mail.gmail.com>

Hi Keycloak developers,

How is related Keycloak to the JSR 375
<https://jcp.org/en/jsr/detail?id=375>: JavaTM EE Security API?

I can see that Darran Lofthouse and Pedro Igor Silva are part of the Expert
Group, and since this JSR overlap with many features of Keycloak (AFAIK) I
wish to know if Keycloak will implement this API or if this API is
unrelated to Keycloak.

What are the plans about it?

Regards,

Jorge Sol?rzano
http://www.jorsol.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160119/50ad1aa5/attachment.html 

From francoismaturel at dijit.fr  Wed Jan 20 03:02:17 2016
From: francoismaturel at dijit.fr (francois maturel)
Date: Wed, 20 Jan 2016 09:02:17 +0100
Subject: [keycloak-dev] Correcting French translation
In-Reply-To: <CAJgngAdQGhTYF38d2KqqXoG_TQX5_UL1Fd=PnZq266cz5kfBFw@mail.gmail.com>
References: <569E1DC4.8080407@dijit.fr>
	<CAJgngAdQGhTYF38d2KqqXoG_TQX5_UL1Fd=PnZq266cz5kfBFw@mail.gmail.com>
Message-ID: <569F3F09.5040506@dijit.fr>

Hi,

Yes they are iso-8859-1, but I'm talking about this file:
forms/common-themes/src/main/resources/theme/keycloak/email/messages/messages_fr.properties

It contains unicode characters like '\u00a9' which actually is 
'COPYRIGHT SIGN' ( ?)

For instance on line 1: V\u00a9rification du courriel
output: V?rification du courriel I sent a PR in github yesterday to 
correct that.

Fran?ois Maturel

Cordialement,

Fran?ois Maturel

Mob: 06.32.10.87.24

dijit <www.dijit.fr>

*www.dijit.fr <http://www.dijit.fr>*

On 01/19/2016 08:08 PM, Stian Thorgersen wrote:
> The property files are iso-8859-1. I've just checked and:
>
> kerberosNotConfigured=Kerberos non configur\u00e9
>
> Outputs:
>
> Kerberos non configur?
>
> So looks like it's correct to me
>
> On 19 January 2016 at 12:28, francois maturel 
> <francoismaturel at dijit.fr <mailto:francoismaturel at dijit.fr>> wrote:
>
>     Hello,
>
>     First of all, thanks for your wonderfull work on keycloak!
>     We are a development team in France using keycloak since v1.2.
>     There are a number of mistranslations in current French
>     messages_fr.properties
>
>     Unicode characters like '\u00a9' are used, but they actually are
>     the 'COPYRIGHT SIGN'
>     Some other messages are strangely translated ;)
>
>     Would you be interested in a PR correcting those messages?
>
>     Thanks
>     -- 
>
>     Cordialement,
>
>     Fran?ois Maturel
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/34b19151/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icon.png
Type: image/png
Size: 3406 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/34b19151/attachment.png 

From sthorger at redhat.com  Wed Jan 20 03:11:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 09:11:15 +0100
Subject: [keycloak-dev] Correcting French translation
In-Reply-To: <569F3F09.5040506@dijit.fr>
References: <569E1DC4.8080407@dijit.fr>
	<CAJgngAdQGhTYF38d2KqqXoG_TQX5_UL1Fd=PnZq266cz5kfBFw@mail.gmail.com>
	<569F3F09.5040506@dijit.fr>
Message-ID: <CAJgngAddwvsDqptm_QuBM4CRLK-hPiubro-Fu6BQztEzqULyhw@mail.gmail.com>

My bad, PR is now merged. Thanks

On 20 January 2016 at 09:02, francois maturel <francoismaturel at dijit.fr>
wrote:

> Hi,
>
> Yes they are iso-8859-1, but I'm talking about this file:
>
> forms/common-themes/src/main/resources/theme/keycloak/email/messages/messages_fr.properties
>
> It contains unicode characters like '\u00a9' which actually is 'COPYRIGHT
> SIGN' ( ?)
>
> For instance on line 1: V\u00a9rification du courriel
> output: V?rification du courriel I sent a PR in github yesterday to
> correct that.
>
> Cordialement,
>
> Fran?ois Maturel
>
> Mob: 06.32.10.87.24
> [image: dijit] <http://www.dijit.fr>
>
> *www.dijit.fr <http://www.dijit.fr>*
> On 01/19/2016 08:08 PM, Stian Thorgersen wrote:
>
> The property files are iso-8859-1. I've just checked and:
>
> kerberosNotConfigured=Kerberos non configur\u00e9
>
> Outputs:
>
> Kerberos non configur?
>
> So looks like it's correct to me
>
> On 19 January 2016 at 12:28, francois maturel <francoismaturel at dijit.fr>
> wrote:
>
>> Hello,
>>
>> First of all, thanks for your wonderfull work on keycloak!
>> We are a development team in France using keycloak since v1.2.
>> There are a number of mistranslations in current French
>> messages_fr.properties
>>
>> Unicode characters like '\u00a9' are used, but they actually are the
>> 'COPYRIGHT SIGN'
>> Some other messages are strangely translated ;)
>>
>> Would you be interested in a PR correcting those messages?
>>
>> Thanks
>> --
>>
>> Cordialement,
>>
>> Fran?ois Maturel
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/58c971ee/attachment-0001.html 

From lkrzyzan at redhat.com  Wed Jan 20 03:31:16 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Wed, 20 Jan 2016 09:31:16 +0100
Subject: [keycloak-dev] Broker login events
In-Reply-To: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>
References: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>
Message-ID: <E9B45CA5-DF36-4243-965A-4F5243947D02@redhat.com>

I?m fine with  ?LOGIN? event for any type of login (form/social etc.) and distinguish the used method in event?s details.

The issue right now is that provider id is not included in login event.
Do you think you can fix that in 1.8.0.CR2? Is it bigger change or just small thing to add?

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Jan 19, 2016, at 1:33 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> It seems like there's a bit of confusion with regards to what events should be fired when a identity broker login occurs.
> 
> Initially it was LOGIN and auth_method was used to differentiate how the user authenticated.
> 
> Then it was changed to IDENTITY_PROVIDER_LOGIN.
> 
> Now it seems to be back to LOGIN.
> 
> This is rather messy! Why has it been changed so much?
> 
> IMO it should as it was initially (LOGIN with auth_method). We also need to make sure identity provider id and sub is included. The latter is missing at the moment.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From sthorger at redhat.com  Wed Jan 20 04:25:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 10:25:21 +0100
Subject: [keycloak-dev] Broker login events
In-Reply-To: <E9B45CA5-DF36-4243-965A-4F5243947D02@redhat.com>
References: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>
	<E9B45CA5-DF36-4243-965A-4F5243947D02@redhat.com>
Message-ID: <CAJgngAeqnO8a7dK--RskmbZZuabKVfed375Gt5C41YqOUhqfng@mail.gmail.com>

Added identity provider and external username to login event when login via
broker

On 20 January 2016 at 09:31, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:

> I?m fine with  ?LOGIN? event for any type of login (form/social etc.) and
> distinguish the used method in event?s details.
>
> The issue right now is that provider id is not included in login event.
> Do you think you can fix that in 1.8.0.CR2? Is it bigger change or just
> small thing to add?
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
> > On Jan 19, 2016, at 1:33 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
> >
> > It seems like there's a bit of confusion with regards to what events
> should be fired when a identity broker login occurs.
> >
> > Initially it was LOGIN and auth_method was used to differentiate how the
> user authenticated.
> >
> > Then it was changed to IDENTITY_PROVIDER_LOGIN.
> >
> > Now it seems to be back to LOGIN.
> >
> > This is rather messy! Why has it been changed so much?
> >
> > IMO it should as it was initially (LOGIN with auth_method). We also need
> to make sure identity provider id and sub is included. The latter is
> missing at the moment.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/e3d17f26/attachment.html 

From sthorger at redhat.com  Wed Jan 20 04:25:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 10:25:33 +0100
Subject: [keycloak-dev] Broker login events
In-Reply-To: <CAJgngAeqnO8a7dK--RskmbZZuabKVfed375Gt5C41YqOUhqfng@mail.gmail.com>
References: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>
	<E9B45CA5-DF36-4243-965A-4F5243947D02@redhat.com>
	<CAJgngAeqnO8a7dK--RskmbZZuabKVfed375Gt5C41YqOUhqfng@mail.gmail.com>
Message-ID: <CAJgngAeCULwv4QMDcwqQ9-sqkURDhQyadXxk6_MyBPdoaPO6Rw@mail.gmail.com>

To 1.8.x as well

On 20 January 2016 at 10:25, Stian Thorgersen <sthorger at redhat.com> wrote:

> Added identity provider and external username to login event when login
> via broker
>
> On 20 January 2016 at 09:31, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:
>
>> I?m fine with  ?LOGIN? event for any type of login (form/social etc.) and
>> distinguish the used method in event?s details.
>>
>> The issue right now is that provider id is not included in login event.
>> Do you think you can fix that in 1.8.0.CR2? Is it bigger change or just
>> small thing to add?
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> jboss.org Development Team
>>
>> > On Jan 19, 2016, at 1:33 PM, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>> >
>> > It seems like there's a bit of confusion with regards to what events
>> should be fired when a identity broker login occurs.
>> >
>> > Initially it was LOGIN and auth_method was used to differentiate how
>> the user authenticated.
>> >
>> > Then it was changed to IDENTITY_PROVIDER_LOGIN.
>> >
>> > Now it seems to be back to LOGIN.
>> >
>> > This is rather messy! Why has it been changed so much?
>> >
>> > IMO it should as it was initially (LOGIN with auth_method). We also
>> need to make sure identity provider id and sub is included. The latter is
>> missing at the moment.
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/90a06082/attachment.html 

From lkrzyzan at redhat.com  Wed Jan 20 04:34:45 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Wed, 20 Jan 2016 10:34:45 +0100
Subject: [keycloak-dev] Broker login events
In-Reply-To: <CAJgngAeqnO8a7dK--RskmbZZuabKVfed375Gt5C41YqOUhqfng@mail.gmail.com>
References: <CAJgngAecn9hVZ8vswj-r0LRQZOHAgL6YP+AqmmcU8V0CuncNgQ@mail.gmail.com>
	<E9B45CA5-DF36-4243-965A-4F5243947D02@redhat.com>
	<CAJgngAeqnO8a7dK--RskmbZZuabKVfed375Gt5C41YqOUhqfng@mail.gmail.com>
Message-ID: <BC25B7B6-FE0B-4FCD-BD1B-449281B56F70@redhat.com>

Cool. Thanks!

Libor Krzy?anek
jboss.org Development Team

> On Jan 20, 2016, at 10:25 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> 
> Added identity provider and external username to login event when login via broker
> 
> On 20 January 2016 at 09:31, Libor Krzyzanek <lkrzyzan at redhat.com <mailto:lkrzyzan at redhat.com>> wrote:
> I?m fine with  ?LOGIN? event for any type of login (form/social etc.) and distinguish the used method in event?s details.
> 
> The issue right now is that provider id is not included in login event.
> Do you think you can fix that in 1.8.0.CR2? Is it bigger change or just small thing to add?
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
> > On Jan 19, 2016, at 1:33 PM, Stian Thorgersen <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
> >
> > It seems like there's a bit of confusion with regards to what events should be fired when a identity broker login occurs.
> >
> > Initially it was LOGIN and auth_method was used to differentiate how the user authenticated.
> >
> > Then it was changed to IDENTITY_PROVIDER_LOGIN.
> >
> > Now it seems to be back to LOGIN.
> >
> > This is rather messy! Why has it been changed so much?
> >
> > IMO it should as it was initially (LOGIN with auth_method). We also need to make sure identity provider id and sub is included. The latter is missing at the moment.
> > _______________________________________________
> > 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>
> 
> 

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

From psilva at redhat.com  Wed Jan 20 07:11:17 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Jan 2016 07:11:17 -0500 (EST)
Subject: [keycloak-dev] Relation to JSR-375
In-Reply-To: <CA+cVU8PaZNrJRt7LLDNAgLy6PzEsUU79zYA-iJwQn=e6jxRcCA@mail.gmail.com>
References: <CA+cVU8PaZNrJRt7LLDNAgLy6PzEsUU79zYA-iJwQn=e6jxRcCA@mail.gmail.com>
Message-ID: <1595056583.12301926.1453291877981.JavaMail.zimbra@redhat.com>

Hi Jorge,

    I don't think JSR-375 is really overlapping with Keycloak. There we are discussing an API whether KC is a OOTB IAM server based on known federation protocols such as OpenID Connect and SAML.

    IMO, the real "overlap" is with PicketLink IdM and JEE Security. 

    Depending on how that spec goes (right now it is pretty quiet), nothing stop us to provide something based on the JSR-375 in the future (maybe for things like user federation SPIs or an integrated and standard API for JEE apps secured by KC).

Regards.
Pedro Igor

----- Original Message -----
From: "Jorge Sol?rzano" <jorsol at gmail.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, January 20, 2016 2:50:03 AM
Subject: [keycloak-dev] Relation to JSR-375

Hi Keycloak developers, 

How is related Keycloak to the JSR 375 : Java TM EE Security API? 

I can see that Darran Lofthouse and Pedro Igor Silva are part of the Expert Group, and since this JSR overlap with many features of Keycloak (AFAIK) I wish to know if Keycloak will implement this API or if this API is unrelated to Keycloak. 

What are the plans about it? 

Regards, 

Jorge Sol?rzano 
http://www.jorsol.com 

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


From jorsol at gmail.com  Wed Jan 20 09:24:54 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Wed, 20 Jan 2016 08:24:54 -0600
Subject: [keycloak-dev] Relation to JSR-375
In-Reply-To: <1595056583.12301926.1453291877981.JavaMail.zimbra@redhat.com>
References: <CA+cVU8PaZNrJRt7LLDNAgLy6PzEsUU79zYA-iJwQn=e6jxRcCA@mail.gmail.com>
	<1595056583.12301926.1453291877981.JavaMail.zimbra@redhat.com>
Message-ID: <CA+cVU8OyvsgfpPbUHfU-eSZOpLRiV3QHGAFuUA6yuD2qM=Vb3g@mail.gmail.com>

Hi Pedro,

Thanks for the clarification, but since PicketLink is "merged" with KC and
it's discontinued, don't that means that KC overlap somehow?

I'm just triying to understand what can be acomplish with PL and what with
KC, I tend to think that PicketLink allows me to do more customization
while KC follows a one-size-fits-all.

Regards,


Jorge Sol?rzano
http://www.jorsol.com

On Wed, Jan 20, 2016 at 6:11 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi Jorge,
>
>     I don't think JSR-375 is really overlapping with Keycloak. There we
> are discussing an API whether KC is a OOTB IAM server based on known
> federation protocols such as OpenID Connect and SAML.
>
>     IMO, the real "overlap" is with PicketLink IdM and JEE Security.
>
>     Depending on how that spec goes (right now it is pretty quiet),
> nothing stop us to provide something based on the JSR-375 in the future
> (maybe for things like user federation SPIs or an integrated and standard
> API for JEE apps secured by KC).
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Jorge Sol?rzano" <jorsol at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, January 20, 2016 2:50:03 AM
> Subject: [keycloak-dev] Relation to JSR-375
>
> Hi Keycloak developers,
>
> How is related Keycloak to the JSR 375 : Java TM EE Security API?
>
> I can see that Darran Lofthouse and Pedro Igor Silva are part of the
> Expert Group, and since this JSR overlap with many features of Keycloak
> (AFAIK) I wish to know if Keycloak will implement this API or if this API
> is unrelated to Keycloak.
>
> What are the plans about it?
>
> Regards,
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/be55e84b/attachment-0001.html 

From psilva at redhat.com  Wed Jan 20 10:12:56 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 20 Jan 2016 10:12:56 -0500 (EST)
Subject: [keycloak-dev] Relation to JSR-375
In-Reply-To: <CA+cVU8OyvsgfpPbUHfU-eSZOpLRiV3QHGAFuUA6yuD2qM=Vb3g@mail.gmail.com>
References: <CA+cVU8PaZNrJRt7LLDNAgLy6PzEsUU79zYA-iJwQn=e6jxRcCA@mail.gmail.com>
	<1595056583.12301926.1453291877981.JavaMail.zimbra@redhat.com>
	<CA+cVU8OyvsgfpPbUHfU-eSZOpLRiV3QHGAFuUA6yuD2qM=Vb3g@mail.gmail.com>
Message-ID: <1228527578.12390936.1453302776036.JavaMail.zimbra@redhat.com>

Yeah, both projects were merged. But the merge was mainly around the federation bits of PicketLink, a.k.a PicketLink Federation, which provides support for SAML.

You are right when you say that PL allows you to do more customization and that is what you get when using a security framework. However, KC also provides great flexibility and let's you customize almost everything: UI, authentication flows, identity management, identity brokering, all based on SPIs that you can implement to better fit your security requirements. KC makes security more easy as you don't need to know any API, how a specific security protocol works or even how to better manage your identities such as users, roles, groups and so forth.

I think I understand your point, where you may not need a separated authentication server (plus infrastructure to support it) in order to support your security requirements. But we had to decide where we should put our efforts and what people are looking most. KC seems to be the perfect answer for that, an easy-to-use and standard-based IAM platform full of very common and useful security capabilities.

Now, from a service provider point of view, when using KC you basically rely on the JEE security standards. It should be possible to still use PL JEE security with KC, where you may use KC tokens (OIDC or SAML) as a source of identity. Unfortunately, due to the PicketLink deprecation, we didn't get that further and we will not spend more time on that any time soon.

So, I would recommend you to give KC a try and see how it can help you to address your security requirements. If you need something that is not provided OOTB, you can take a look at the SPIs or even ask for a specific feature/SPI.

Best regards.
Pedro Igor

----- Original Message -----
From: "Jorge Sol?rzano" <jorsol at gmail.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, January 20, 2016 12:24:54 PM
Subject: Re: [keycloak-dev] Relation to JSR-375

Hi Pedro,

Thanks for the clarification, but since PicketLink is "merged" with KC and
it's discontinued, don't that means that KC overlap somehow?

I'm just triying to understand what can be acomplish with PL and what with
KC, I tend to think that PicketLink allows me to do more customization
while KC follows a one-size-fits-all.

Regards,


Jorge Sol?rzano
http://www.jorsol.com

On Wed, Jan 20, 2016 at 6:11 AM, Pedro Igor Silva <psilva at redhat.com> wrote:

> Hi Jorge,
>
>     I don't think JSR-375 is really overlapping with Keycloak. There we
> are discussing an API whether KC is a OOTB IAM server based on known
> federation protocols such as OpenID Connect and SAML.
>
>     IMO, the real "overlap" is with PicketLink IdM and JEE Security.
>
>     Depending on how that spec goes (right now it is pretty quiet),
> nothing stop us to provide something based on the JSR-375 in the future
> (maybe for things like user federation SPIs or an integrated and standard
> API for JEE apps secured by KC).
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Jorge Sol?rzano" <jorsol at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, January 20, 2016 2:50:03 AM
> Subject: [keycloak-dev] Relation to JSR-375
>
> Hi Keycloak developers,
>
> How is related Keycloak to the JSR 375 : Java TM EE Security API?
>
> I can see that Darran Lofthouse and Pedro Igor Silva are part of the
> Expert Group, and since this JSR overlap with many features of Keycloak
> (AFAIK) I wish to know if Keycloak will implement this API or if this API
> is unrelated to Keycloak.
>
> What are the plans about it?
>
> Regards,
>
> Jorge Sol?rzano
> http://www.jorsol.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From bburke at redhat.com  Wed Jan 20 10:43:02 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 20 Jan 2016 10:43:02 -0500
Subject: [keycloak-dev] browser backbutton
Message-ID: <569FAB06.2030105@redhat.com>

Seems jboss.org guys don't like that the browser backbutton doesn't 
work.   The question is, do we want to rework the auth spi to allow for 
backbutton?  I'm not sure its even feasible or not.
https://issues.jboss.org/browse/KEYCLOAK-2325

REFRESH BUTTON
* Refresh button will repost form data to the URL that is contained in 
the browser url window.
* In Keycloak 1.6, I added redirects after successful actions.  The 
redirect would redirect you off of the last URL.  This helped a lot with 
refresh button as form data wasn't posted to old form URLs.
* In Keycloak 1.8 I removed the redirects because jboss.org complained 
about the performance of the extra redirects.  To allow refresh button 
to work, keycloak would just ignore posts to old form urls and just 
display the current state of the flow.

BACK BUTTON
* Adding support for the back button would require Keycloak to unwind 
actions that have already been successful.  This probably requires a 
callback method on the auth spi to do this.
* Since there are no more redirects, another problem is that keycloak 
would not be able to distinguish between a page refresh button and a 
backbutton/form resubmit.

Is this something we can put off until 2.0?  I currently don't know how 
to solve all three issues with the current design: refresh button, back 
button, and performance.

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


From bburke at redhat.com  Wed Jan 20 12:09:49 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 20 Jan 2016 12:09:49 -0500
Subject: [keycloak-dev] NO MORE import * please!
Message-ID: <569FBF5D.5000104@redhat.com>

Please stop doing

import package.*;

All classes need to be listed.  Nothing hidden by wildcards.  One reason 
for this is when people are browser code on github and they have an idea 
how to find the class they are interested in.

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


From christian.beikov at gmail.com  Wed Jan 20 12:17:08 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Wed, 20 Jan 2016 18:17:08 +0100
Subject: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
In-Reply-To: <569FC0C2.1000809@sweazer.com>
References: <569FC0C2.1000809@sweazer.com>
Message-ID: <569FC114.3050703@gmail.com>

Hello,

we have a problem since Keycloak 1.8.0.CR1 that we didn't have in 
1.1.0.Final.
The problem appears when accessing a secured JSF page that uses 
DeltaSpike. DeltaSpike redirects the initial request to append a query 
param to the path called "dswid". When accesing a secured page, the 
Keycloak adapter also does some redirects and adds the redirect uri, 
this time the one already including the dswid, into the client session, 
but redirects the browser to a URL that includes a redirect uri that 
does not contain the dswid. The authentication process fails here: 
https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231

Since it worked earlier, I guess this is a bug. The actual problem is 
the mismatch between the redirect uri stored in the session and the 
redirect uri returned to the browser. Hope you can fix this for 1.8.0.Final

Regards,
Christian

From bruno at abstractj.org  Wed Jan 20 12:19:19 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 20 Jan 2016 15:19:19 -0200
Subject: [keycloak-dev] auth-server-url as a system variable
Message-ID: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>

Good morning, I've been working on some ideas for AeroGear, in order
to have UPS and Keycloak in a separated infrastructure. The reason why
this is not possible today, is pretty much related with design
decisions in the past for UPS.

Not sure if this makes some sense or was already discussed. But I was
wondering if we could change the adapters to load an environment
variable like ${keycloak.server.url}. The raw idea is pretty simple:

## Configure the system variable on Wildfly

$JBOSS_HOME/bin/jboss-cli.sh -c --controller=localhost:9992
--command="/system-property=keycloak.server.url:add(value=http://localhost:8083)"

Or just configuring it inside standalone.xml like Hawkular already
does (http://www.hawkular.org/docs/user/installation-guide.html#_preparing_the_environments)

## Pass the variable as argument

{
  "realm" : "aerogear",
  "auth-server-url" : "${keycloak.server.url}",
  "ssl-required" : "external",
  "resource" : "unified-push-server",
  "bearer-only" : true,
  "disable-trust-manager" : true
}

I couldn't find any history related to this topic, besides this ticket
(https://issues.jboss.org/browse/KEYCLOAK-1289).

Do you think this is doable to implement? Or am I missing something?


-- 
- abstractj

From jpkroehling at redhat.com  Wed Jan 20 12:35:33 2016
From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 20 Jan 2016 18:35:33 +0100
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
Message-ID: <569FC565.402@redhat.com>

On 20.01.2016 18:19, Bruno Oliveira wrote:
> Or just configuring it inside standalone.xml like Hawkular already
> does (http://www.hawkular.org/docs/user/installation-guide.html#_preparing_the_environments)
>
> ## Pass the variable as argument
>
> {
>    "realm" : "aerogear",
>    "auth-server-url" : "${keycloak.server.url}",
>    "ssl-required" : "external",
>    "resource" : "unified-push-server",
>    "bearer-only" : true,
>    "disable-trust-manager" : true
> }

The Wildfly Adapter already supports this: https://git.io/vzBpU

For the keycloak.json used in our UI, we did it as a Servlet:

Template: https://git.io/vzBAU
keycloak.json as servlet: https://git.io/vRdJi

- Juca.

From ssilvert at redhat.com  Wed Jan 20 12:47:36 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 20 Jan 2016 12:47:36 -0500
Subject: [keycloak-dev] NO MORE import * please!
In-Reply-To: <569FBF5D.5000104@redhat.com>
References: <569FBF5D.5000104@redhat.com>
Message-ID: <569FC838.5010201@redhat.com>

+1  Drives me crazy.

On 1/20/2016 12:09 PM, Bill Burke wrote:
> Please stop doing
>
> import package.*;
>
> All classes need to be listed.  Nothing hidden by wildcards.  One reason
> for this is when people are browser code on github and they have an idea
> how to find the class they are interested in.
>


From qmx at qmx.me  Wed Jan 20 13:02:33 2016
From: qmx at qmx.me (Douglas Campos)
Date: Wed, 20 Jan 2016 16:02:33 -0200
Subject: [keycloak-dev] NO MORE import * please!
In-Reply-To: <569FC838.5010201@redhat.com>
References: <569FBF5D.5000104@redhat.com> <569FC838.5010201@redhat.com>
Message-ID: <CAN-DfD51_6Uxpe0zJg+PwFyMBTxuh_KRnh74yZjOasA3q15L6Q@mail.gmail.com>

The most common culprit is Intellij's IDEA default setting of doing it.

On Wed, Jan 20, 2016 at 3:47 PM, Stan Silvert <ssilvert at redhat.com> wrote:

> +1  Drives me crazy.
>
> On 1/20/2016 12:09 PM, Bill Burke wrote:
> > Please stop doing
> >
> > import package.*;
> >
> > All classes need to be listed.  Nothing hidden by wildcards.  One reason
> > for this is when people are browser code on github and they have an idea
> > how to find the class they are interested in.
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/4db29c77/attachment.html 

From bruno at abstractj.org  Wed Jan 20 13:15:51 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 20 Jan 2016 16:15:51 -0200
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <569FC565.402@redhat.com>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
	<569FC565.402@redhat.com>
Message-ID: <CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>

I noticed that looking at Hawkular, but correct if I'm wrong. Today
that's not supported for the client side configuration, unless you
workaround it like you did with Servlets, right?

On Wed, Jan 20, 2016 at 3:35 PM, Juraci Paix?o Kr?hling
<jpkroehling at redhat.com> wrote:
> On 20.01.2016 18:19, Bruno Oliveira wrote:
>> Or just configuring it inside standalone.xml like Hawkular already
>> does (http://www.hawkular.org/docs/user/installation-guide.html#_preparing_the_environments)
>>
>> ## Pass the variable as argument
>>
>> {
>>    "realm" : "aerogear",
>>    "auth-server-url" : "${keycloak.server.url}",
>>    "ssl-required" : "external",
>>    "resource" : "unified-push-server",
>>    "bearer-only" : true,
>>    "disable-trust-manager" : true
>> }
>
> The Wildfly Adapter already supports this: https://git.io/vzBpU
>
> For the keycloak.json used in our UI, we did it as a Servlet:
>
> Template: https://git.io/vzBAU
> keycloak.json as servlet: https://git.io/vRdJi
>
> - Juca.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj


From srossillo at smartling.com  Wed Jan 20 13:40:11 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Wed, 20 Jan 2016 13:40:11 -0500
Subject: [keycloak-dev] NO MORE import * please!
In-Reply-To: <CAN-DfD51_6Uxpe0zJg+PwFyMBTxuh_KRnh74yZjOasA3q15L6Q@mail.gmail.com>
References: <569FBF5D.5000104@redhat.com> <569FC838.5010201@redhat.com>
	<CAN-DfD51_6Uxpe0zJg+PwFyMBTxuh_KRnh74yZjOasA3q15L6Q@mail.gmail.com>
Message-ID: <C50C2013-DEFB-4728-B0F9-07FC78E0B583@smartling.com>

Here?s a Wildfly code style for IntelliJ[0]. I created this based off the recommendation to use Wildfly code style for Keycloak.

Haven?t had any issues with my PRs using this code style.

[0]: https://gist.github.com/foo4u/179c8098f109dba11180

~ Scott

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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Jan 20, 2016, at 1:02 PM, Douglas Campos <qmx at qmx.me> wrote:
> 
> The most common culprit is Intellij's IDEA default setting of doing it.
> 
> On Wed, Jan 20, 2016 at 3:47 PM, Stan Silvert <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
> +1  Drives me crazy.
> 
> On 1/20/2016 12:09 PM, Bill Burke wrote:
> > Please stop doing
> >
> > import package.*;
> >
> > All classes need to be listed.  Nothing hidden by wildcards.  One reason
> > for this is when people are browser code on github and they have an idea
> > how to find the class they are interested in.
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Wed Jan 20 13:48:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 19:48:12 +0100
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <569FAB06.2030105@redhat.com>
References: <569FAB06.2030105@redhat.com>
Message-ID: <CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>

Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.

Secondly, the back button should not navigate backwards in the flow. Also,
the refresh button should just redisplay the page as it does now (ignoring
the post). A couple ideas to improve things though:

1) Set cache-control to "Cache-Control: no-store, must-revalidate,
max-age=0". This should force a reload of the page when the user clicks the
back button
2) Can we add a back link to some steps in the flow?
3) Can we add a cancel link to some steps in the flow?
4) If a user clicks the back button in the browser depending on where we
are in the flow I think we should either take the user back to the first
step (cancel), go back one step or just reshow the same page

By setting the cache as I suggested in 1 I actually think the browser will
just complain when you navigate back to a page that does a post.

On 20 January 2016 at 16:43, Bill Burke <bburke at redhat.com> wrote:

> Seems jboss.org guys don't like that the browser backbutton doesn't
> work.   The question is, do we want to rework the auth spi to allow for
> backbutton?  I'm not sure its even feasible or not.
> https://issues.jboss.org/browse/KEYCLOAK-2325
>
> REFRESH BUTTON
> * Refresh button will repost form data to the URL that is contained in
> the browser url window.
> * In Keycloak 1.6, I added redirects after successful actions.  The
> redirect would redirect you off of the last URL.  This helped a lot with
> refresh button as form data wasn't posted to old form URLs.
> * In Keycloak 1.8 I removed the redirects because jboss.org complained
> about the performance of the extra redirects.  To allow refresh button
> to work, keycloak would just ignore posts to old form urls and just
> display the current state of the flow.
>
> BACK BUTTON
> * Adding support for the back button would require Keycloak to unwind
> actions that have already been successful.  This probably requires a
> callback method on the auth spi to do this.
> * Since there are no more redirects, another problem is that keycloak
> would not be able to distinguish between a page refresh button and a
> backbutton/form resubmit.
>
> Is this something we can put off until 2.0?  I currently don't know how
> to solve all three issues with the current design: refresh button, back
> button, and performance.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/534fc763/attachment.html 

From juraci at kroehling.de  Wed Jan 20 13:57:07 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 20 Jan 2016 19:57:07 +0100
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
	<569FC565.402@redhat.com>
	<CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>
Message-ID: <569FD883.20109@kroehling.de>

On 20.01.2016 19:15, Bruno Oliveira wrote:
> I noticed that looking at Hawkular, but correct if I'm wrong. Today
> that's not supported for the client side configuration, unless you
> workaround it like you did with Servlets, right?

Right, for the JavaScript Adapter (which loads /keycloak.json by 
default), you'd need a workaround like that.

For the Wildfly adapter, it's already supported on the secure-deployment 
approach. So, instead of using a keycloak.json within your WAR, you can 
protect it via the subsystem.

Not sure about other adapters, though.

- Juca.

From sthorger at redhat.com  Wed Jan 20 13:58:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 19:58:29 +0100
Subject: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
In-Reply-To: <569FC114.3050703@gmail.com>
References: <569FC0C2.1000809@sweazer.com>
	<569FC114.3050703@gmail.com>
Message-ID: <CAJgngAfmNF_MrV=9eTY7zc+PJU6STEfWX4DnDH9P_W1fQRMuMw@mail.gmail.com>

The reason it's failing after upgrading from 1.1 is the check of the
redirect uri was added later. This is not a recent regression so we're not
going to fix it for 1.8. We can look into it for 1.9 though if you create a
JIRA.

My suspicion is that we may not be able to fix it. The problem could be
that DeltaSpike is invoked prior to Keycloak adapter, which results in the
following behavior:

1. DeltaSpike adds "dswid"
2. Keycloak adapter redirects to login page with redirect uri that includes
dswid
3. Keycloak server authenticates users and redirects back to the
application (including dswid)
4. DeltaSpike removes "dswid"
5. Keycloak adapter tries to obtain token using redirect_uri param without
dswid, which is rejected

Step 5 is a step that we can't remove as it's required by the OpenID
Connect specification. It's there to prevent potential attacks.

On 20 January 2016 at 18:17, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hello,
>
> we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
> 1.1.0.Final.
> The problem appears when accessing a secured JSF page that uses
> DeltaSpike. DeltaSpike redirects the initial request to append a query
> param to the path called "dswid". When accesing a secured page, the
> Keycloak adapter also does some redirects and adds the redirect uri,
> this time the one already including the dswid, into the client session,
> but redirects the browser to a URL that includes a redirect uri that
> does not contain the dswid. The authentication process fails here:
>
> https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
>
> Since it worked earlier, I guess this is a bug. The actual problem is
> the mismatch between the redirect uri stored in the session and the
> redirect uri returned to the browser. Hope you can fix this for 1.8.0.Final
>
> Regards,
> Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/ee1b76bc/attachment.html 

From sthorger at redhat.com  Wed Jan 20 13:59:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 19:59:45 +0100
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <569FD883.20109@kroehling.de>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
	<569FC565.402@redhat.com>
	<CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>
	<569FD883.20109@kroehling.de>
Message-ID: <CAJgngAfHf6x_gyzx3T-n2qXtL3mFT-dDJUM9aa-50au7RFSK6w@mail.gmail.com>

keycloak.json already supports system properties, I think it supports
environment variables as well "${env.KEYCLOAK}"

On 20 January 2016 at 19:57, Juraci Paix?o Kr?hling <juraci at kroehling.de>
wrote:

> On 20.01.2016 19:15, Bruno Oliveira wrote:
> > I noticed that looking at Hawkular, but correct if I'm wrong. Today
> > that's not supported for the client side configuration, unless you
> > workaround it like you did with Servlets, right?
>
> Right, for the JavaScript Adapter (which loads /keycloak.json by
> default), you'd need a workaround like that.
>
> For the Wildfly adapter, it's already supported on the secure-deployment
> approach. So, instead of using a keycloak.json within your WAR, you can
> protect it via the subsystem.
>
> Not sure about other adapters, though.
>
> - Juca.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/0e75df01/attachment-0001.html 

From bruno at abstractj.org  Wed Jan 20 14:14:46 2016
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 20 Jan 2016 17:14:46 -0200
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <CAJgngAfHf6x_gyzx3T-n2qXtL3mFT-dDJUM9aa-50au7RFSK6w@mail.gmail.com>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
	<569FC565.402@redhat.com>
	<CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>
	<569FD883.20109@kroehling.de>
	<CAJgngAfHf6x_gyzx3T-n2qXtL3mFT-dDJUM9aa-50au7RFSK6w@mail.gmail.com>
Message-ID: <CAM5SUC5kT6eWiEUEJPka7BSYvk4m0UVJ9NFBKnkK+dqcyoh=xA@mail.gmail.com>

Thank you, will give it another try.

On Wed, Jan 20, 2016 at 4:59 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> keycloak.json already supports system properties, I think it supports
> environment variables as well "${env.KEYCLOAK}"
>
> On 20 January 2016 at 19:57, Juraci Paix?o Kr?hling <juraci at kroehling.de>
> wrote:
>>
>> On 20.01.2016 19:15, Bruno Oliveira wrote:
>> > I noticed that looking at Hawkular, but correct if I'm wrong. Today
>> > that's not supported for the client side configuration, unless you
>> > workaround it like you did with Servlets, right?
>>
>> Right, for the JavaScript Adapter (which loads /keycloak.json by
>> default), you'd need a workaround like that.
>>
>> For the Wildfly adapter, it's already supported on the secure-deployment
>> approach. So, instead of using a keycloak.json within your WAR, you can
>> protect it via the subsystem.
>>
>> Not sure about other adapters, though.
>>
>> - Juca.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
- abstractj


From juraci at kroehling.de  Wed Jan 20 14:19:08 2016
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Wed, 20 Jan 2016 20:19:08 +0100
Subject: [keycloak-dev] auth-server-url as a system variable
In-Reply-To: <CAJgngAfHf6x_gyzx3T-n2qXtL3mFT-dDJUM9aa-50au7RFSK6w@mail.gmail.com>
References: <CAM5SUC7KCT4isFfjvdYYca7qpJHZwWKovE7tj9BXF7vCsvH3RA@mail.gmail.com>
	<569FC565.402@redhat.com>
	<CAM5SUC7eZ6B9+3SJ-U146njwPMXHwkTqXFY9=KsBW-HpNjiYoA@mail.gmail.com>
	<569FD883.20109@kroehling.de>
	<CAJgngAfHf6x_gyzx3T-n2qXtL3mFT-dDJUM9aa-50au7RFSK6w@mail.gmail.com>
Message-ID: <569FDDAC.9080504@kroehling.de>

On 20.01.2016 19:59, Stian Thorgersen wrote:
> keycloak.json already supports system properties, I think it supports
> environment variables as well "${env.KEYCLOAK}"

Cool, I thought it was only for the ones deployed within WEB-INF, to be 
consumed by server adapters. I might even then remove our servlet for that!

Thanks!
- Juca.

From replymenot at gmail.com  Wed Jan 20 15:46:45 2016
From: replymenot at gmail.com (replymenot)
Date: Wed, 20 Jan 2016 21:46:45 +0100
Subject: [keycloak-dev] Keycloak and Angular,
	how to login after angular has been bootstrapped
Message-ID: <DCE33BCC-6964-40F2-833A-011824F4AF30@gmail.com>

Hi all,

Recently I attended a seminar on Keycloak and I was totally blown away. Loved it and it seems to be exactly what I need for my microservices architecture.
I use AngularJS as my front-end and I have this burning question.

How can I use Keycloak as security provider in a SPA after the angular app has already been bootstrapped?

The website I?m creating has anonymous and role based secure parts. So I only want login based on context and not on load.
I can?t seem te be able to find examples.
Right now I get the login from keycloack but after redirect my angular app is re-bootstrapped and I loose my login, because it is not part of my single page app...

Help will be appreciated.

Ivo.

From sthorger at redhat.com  Wed Jan 20 15:49:18 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 20 Jan 2016 21:49:18 +0100
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
Message-ID: <CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>

One additional thought. Maybe we could add a field to autheticators to say
if they support back, cancel or nothing. Then the flow would allow going
back if previous supports back. It would allow cancel if all supports it,
or nothing is one says nothing
On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com> wrote:

> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for
> 1.9.
>
> Secondly, the back button should not navigate backwards in the flow. Also,
> the refresh button should just redisplay the page as it does now (ignoring
> the post). A couple ideas to improve things though:
>
> 1) Set cache-control to "Cache-Control: no-store, must-revalidate,
> max-age=0". This should force a reload of the page when the user clicks the
> back button
> 2) Can we add a back link to some steps in the flow?
> 3) Can we add a cancel link to some steps in the flow?
> 4) If a user clicks the back button in the browser depending on where we
> are in the flow I think we should either take the user back to the first
> step (cancel), go back one step or just reshow the same page
>
> By setting the cache as I suggested in 1 I actually think the browser will
> just complain when you navigate back to a page that does a post.
>
> On 20 January 2016 at 16:43, Bill Burke <bburke at redhat.com> wrote:
>
>> Seems jboss.org guys don't like that the browser backbutton doesn't
>> work.   The question is, do we want to rework the auth spi to allow for
>> backbutton?  I'm not sure its even feasible or not.
>> https://issues.jboss.org/browse/KEYCLOAK-2325
>>
>> REFRESH BUTTON
>> * Refresh button will repost form data to the URL that is contained in
>> the browser url window.
>> * In Keycloak 1.6, I added redirects after successful actions.  The
>> redirect would redirect you off of the last URL.  This helped a lot with
>> refresh button as form data wasn't posted to old form URLs.
>> * In Keycloak 1.8 I removed the redirects because jboss.org complained
>> about the performance of the extra redirects.  To allow refresh button
>> to work, keycloak would just ignore posts to old form urls and just
>> display the current state of the flow.
>>
>> BACK BUTTON
>> * Adding support for the back button would require Keycloak to unwind
>> actions that have already been successful.  This probably requires a
>> callback method on the auth spi to do this.
>> * Since there are no more redirects, another problem is that keycloak
>> would not be able to distinguish between a page refresh button and a
>> backbutton/form resubmit.
>>
>> Is this something we can put off until 2.0?  I currently don't know how
>> to solve all three issues with the current design: refresh button, back
>> button, and performance.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160120/cdb5ac14/attachment.html 

From bburke at redhat.com  Wed Jan 20 17:27:38 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 20 Jan 2016 17:27:38 -0500
Subject: [keycloak-dev] module re-org complete?
Message-ID: <56A009DA.1020608@redhat.com>

"backends" (jpa, mongo, infinispan) were consolidated under 
keycloak-model-(jpa, mongo, infinispan).

Integration module was moved around into:
adapters/
adapters/oidc
adapters/saml
spi/

connections, broker, social, events etc. were consolidated.

Modules I did not consolidate:

federation/*

I kept federation separate as I'm wondering what will happen with 
kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that 
separate too.

events/syslog

Not sure if this is something we was removable or not as it depends on a 
thirdparty library.

client-registration/*
wildfly/*

I don't know much about these modules so I kept them separate. 
Stian/Marko can decide what they want to do here.

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


From bburke at redhat.com  Wed Jan 20 19:22:04 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 20 Jan 2016 19:22:04 -0500
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
Message-ID: <56A024AC.8080101@redhat.com>



On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>
> One additional thought. Maybe we could add a field to autheticators to 
> say if they support back, cancel or nothing. Then the flow would allow 
> going back if previous supports back. It would allow cancel if all 
> supports it, or nothing is one says nothing
>
> On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix
>     it for 1.9.
>
>     Secondly, the back button should not navigate backwards in the
>     flow. Also, the refresh button should just redisplay the page as
>     it does now (ignoring the post). A couple ideas to improve things
>     though:
>
>     1) Set cache-control to "Cache-Control: no-store, must-revalidate,
>     max-age=0". This should force a reload of the page when the user
>     clicks the back button
>

Really?  That's cool then, this will basically "disable" the back button 
:)  I'll try it out.

>     2) Can we add a back link to some steps in the flow?
>     3) Can we add a cancel link to some steps in the flow?
>

You can reset the flow to the beginning, but can't go back one step.

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

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

From srossillo at smartling.com  Wed Jan 20 20:50:12 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 21 Jan 2016 01:50:12 +0000
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <56A024AC.8080101@redhat.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
Message-ID: <CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>

There's s pattern to handle the back button during flows. It's that a post
should never render a view but redirect (HTTP get) to the failure or
success view.

http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>
> One additional thought. Maybe we could add a field to autheticators to say
> if they support back, cancel or nothing. Then the flow would allow going
> back if previous supports back. It would allow cancel if all supports it,
> or nothing is one says nothing
> On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com> wrote:
>
>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for
>> 1.9.
>>
>> Secondly, the back button should not navigate backwards in the flow.
>> Also, the refresh button should just redisplay the page as it does now
>> (ignoring the post). A couple ideas to improve things though:
>>
>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate,
>> max-age=0". This should force a reload of the page when the user clicks the
>> back button
>>
>
> Really?  That's cool then, this will basically "disable" the back button
> :)  I'll try it out.
>
>
> 2) Can we add a back link to some steps in the flow?
>> 3) Can we add a cancel link to some steps in the flow?
>>
>
> You can reset the flow to the beginning, but can't go back one step.
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/a419041b/attachment.html 

From sthorger at redhat.com  Thu Jan 21 02:48:23 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 08:48:23 +0100
Subject: [keycloak-dev] Keycloak and Angular,
 how to login after angular has been bootstrapped
In-Reply-To: <DCE33BCC-6964-40F2-833A-011824F4AF30@gmail.com>
References: <DCE33BCC-6964-40F2-833A-011824F4AF30@gmail.com>
Message-ID: <CAJgngAcWRb7O4dn8H31t+z35rezcF80qcfXznUy9yofDZwZtcw@mail.gmail.com>

We could do with a proper Angular wrapper, but without it you have to let
Keycloak initialize first, then have Keycloak initialize Angular. Take a
look at:
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/angular-product-app/src/main/webapp/js/app.js#L23

Just remove { onLoad: 'login-required' } and it won't automatically login,
instead you run login() to login.

On 20 January 2016 at 21:46, replymenot <replymenot at gmail.com> wrote:

> Hi all,
>
> Recently I attended a seminar on Keycloak and I was totally blown away.
> Loved it and it seems to be exactly what I need for my microservices
> architecture.
> I use AngularJS as my front-end and I have this burning question.
>
> How can I use Keycloak as security provider in a SPA after the angular app
> has already been bootstrapped?
>
> The website I?m creating has anonymous and role based secure parts. So I
> only want login based on context and not on load.
> I can?t seem te be able to find examples.
> Right now I get the login from keycloack but after redirect my angular app
> is re-bootstrapped and I loose my login, because it is not part of my
> single page app...
>
> Help will be appreciated.
>
> Ivo.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/f4f6a2fb/attachment.html 

From sthorger at redhat.com  Thu Jan 21 04:16:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 10:16:24 +0100
Subject: [keycloak-dev] Usability in authentication flows
Message-ID: <CAJgngAeeLEtL87waVGH3i4+qT55QaV-V-P1oV-O4L_scGwo+hQ@mail.gmail.com>

With regards to usability in authentication flows I think we have 3 issues
that can be improved:

Improve error messages
--------------------------------
"Something has gone wrong" is not helpful to an end-user. In general we
need to review error messages, maybe also other messages, to make sure they
are useful in the eyes of an end-user and not a developer.


Escape option
-------------------
There should always be at least one escape option for a user. We should
make sure the client is always known. This can be done by adding the client
uuid to the client session code, which means it will be always be available
even if session has been cleared. As long as the client has set the base
url we can add a link to return the application.

As the logins are redirect based it's important to always be able to return
to the application, especially for consumer facing sites.

I'm not sure "back to application" is the best text though, but can't come
up with anything better ATM.

There's also several times in the flow it could be useful to have a
cancel/restart option to restart the flow. Again, I'm not sure what the
best text for the link is. "cancel" would suggest returning to the
application, not to restart the flow.


Back/refresh buttons
---------------------------
Using cache control it should be possible to always reload the page so when
a user clicks back the current page is just redisplayed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/e2e667a4/attachment.html 

From sthorger at redhat.com  Thu Jan 21 06:00:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 12:00:11 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR2 Released
Message-ID: <CAJgngAfeRtXCUQ9_gohvBm_8AxMHhgje1LT7nejCCqLF8Rej5Q@mail.gmail.com>

We had a few issues reported against 1.8.0.CR1, so we're doing another CR
release with the fixes. If everything is OK, 1.8.0.Final will be released
next week.

There was also a feature that sneaked in. We now support sign-on with
Microsoft Live.

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

From sthorger at redhat.com  Thu Jan 21 07:08:54 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:08:54 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <56A009DA.1020608@redhat.com>
References: <56A009DA.1020608@redhat.com>
Message-ID: <CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>

On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:

> "backends" (jpa, mongo, infinispan) were consolidated under
> keycloak-model-(jpa, mongo, infinispan).
>
> Integration module was moved around into:
> adapters/
> adapters/oidc
> adapters/saml
> spi/
>
> connections, broker, social, events etc. were consolidated.
>
> Modules I did not consolidate:
>
> federation/*
>
> I kept federation separate as I'm wondering what will happen with
> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
> separate too.
>
> events/syslog
>

I'm deleting this. Shouldn't have been added in the first place as syslog
can be done with the syslog appender for regular logging. Besides no one
actually requested it.


>
> Not sure if this is something we was removable or not as it depends on a
> thirdparty library.
>
> client-registration/*
>

Moved to integration. It's client lib for client registration service.


> wildfly/*
>

Needs to stay as is. It's all specifics to WF and they can't be combined.


>
> I don't know much about these modules so I kept them separate.
> Stian/Marko can decide what they want to do here.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/5132c7d7/attachment-0001.html 

From sthorger at redhat.com  Thu Jan 21 07:18:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:18:19 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
Message-ID: <CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>

saml/saml-core I take it that's used by client and server? Should we just
move saml-core to the root? Seems unnecessary to have a parent module with
only one module inside.

On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:
>
>> "backends" (jpa, mongo, infinispan) were consolidated under
>> keycloak-model-(jpa, mongo, infinispan).
>>
>> Integration module was moved around into:
>> adapters/
>> adapters/oidc
>> adapters/saml
>> spi/
>>
>> connections, broker, social, events etc. were consolidated.
>>
>> Modules I did not consolidate:
>>
>> federation/*
>>
>> I kept federation separate as I'm wondering what will happen with
>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>> separate too.
>>
>> events/syslog
>>
>
> I'm deleting this. Shouldn't have been added in the first place as syslog
> can be done with the syslog appender for regular logging. Besides no one
> actually requested it.
>
>
>>
>> Not sure if this is something we was removable or not as it depends on a
>> thirdparty library.
>>
>> client-registration/*
>>
>
> Moved to integration. It's client lib for client registration service.
>
>
>> wildfly/*
>>
>
> Needs to stay as is. It's all specifics to WF and they can't be combined.
>
>
>>
>> I don't know much about these modules so I kept them separate.
>> Stian/Marko can decide what they want to do here.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/e46b05ca/attachment.html 

From sthorger at redhat.com  Thu Jan 21 07:19:29 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:19:29 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
Message-ID: <CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>

util/embedded-ldap can we move this to testsuite?

On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com> wrote:

> saml/saml-core I take it that's used by client and server? Should we just
> move saml-core to the root? Seems unnecessary to have a parent module with
> only one module inside.
>
> On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>>
>>
>> On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:
>>
>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>> keycloak-model-(jpa, mongo, infinispan).
>>>
>>> Integration module was moved around into:
>>> adapters/
>>> adapters/oidc
>>> adapters/saml
>>> spi/
>>>
>>> connections, broker, social, events etc. were consolidated.
>>>
>>> Modules I did not consolidate:
>>>
>>> federation/*
>>>
>>> I kept federation separate as I'm wondering what will happen with
>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>> separate too.
>>>
>>> events/syslog
>>>
>>
>> I'm deleting this. Shouldn't have been added in the first place as syslog
>> can be done with the syslog appender for regular logging. Besides no one
>> actually requested it.
>>
>>
>>>
>>> Not sure if this is something we was removable or not as it depends on a
>>> thirdparty library.
>>>
>>> client-registration/*
>>>
>>
>> Moved to integration. It's client lib for client registration service.
>>
>>
>>> wildfly/*
>>>
>>
>> Needs to stay as is. It's all specifics to WF and they can't be combined.
>>
>>
>>>
>>> I don't know much about these modules so I kept them separate.
>>> Stian/Marko can decide what they want to do here.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/ba3af494/attachment.html 

From sthorger at redhat.com  Thu Jan 21 07:19:56 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:19:56 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
Message-ID: <CAJgngAfN70teFCtjsE4T22YDF+xsVZA9aUbhX0mF+fzeYOLEvQ@mail.gmail.com>

forms/common-themes we should move this to root and rename to themes

On 21 January 2016 at 13:19, Stian Thorgersen <sthorger at redhat.com> wrote:

> util/embedded-ldap can we move this to testsuite?
>
> On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> saml/saml-core I take it that's used by client and server? Should we just
>> move saml-core to the root? Seems unnecessary to have a parent module with
>> only one module inside.
>>
>> On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>
>>>> Integration module was moved around into:
>>>> adapters/
>>>> adapters/oidc
>>>> adapters/saml
>>>> spi/
>>>>
>>>> connections, broker, social, events etc. were consolidated.
>>>>
>>>> Modules I did not consolidate:
>>>>
>>>> federation/*
>>>>
>>>> I kept federation separate as I'm wondering what will happen with
>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>> separate too.
>>>>
>>>> events/syslog
>>>>
>>>
>>> I'm deleting this. Shouldn't have been added in the first place as
>>> syslog can be done with the syslog appender for regular logging. Besides no
>>> one actually requested it.
>>>
>>>
>>>>
>>>> Not sure if this is something we was removable or not as it depends on a
>>>> thirdparty library.
>>>>
>>>> client-registration/*
>>>>
>>>
>>> Moved to integration. It's client lib for client registration service.
>>>
>>>
>>>> wildfly/*
>>>>
>>>
>>> Needs to stay as is. It's all specifics to WF and they can't be combined.
>>>
>>>
>>>>
>>>> I don't know much about these modules so I kept them separate.
>>>> Stian/Marko can decide what they want to do here.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/969ab2c2/attachment.html 

From sthorger at redhat.com  Thu Jan 21 07:32:57 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:32:57 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAfN70teFCtjsE4T22YDF+xsVZA9aUbhX0mF+fzeYOLEvQ@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<CAJgngAfN70teFCtjsE4T22YDF+xsVZA9aUbhX0mF+fzeYOLEvQ@mail.gmail.com>
Message-ID: <CAJgngAcAXSiVWqHe=DSskCZTvQ6hQKTpww0bppTpqugiGEdjmA@mail.gmail.com>

I'm moving forms/common-themes to just themes

On 21 January 2016 at 13:19, Stian Thorgersen <sthorger at redhat.com> wrote:

> forms/common-themes we should move this to root and rename to themes
>
> On 21 January 2016 at 13:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> util/embedded-ldap can we move this to testsuite?
>>
>> On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> saml/saml-core I take it that's used by client and server? Should we
>>> just move saml-core to the root? Seems unnecessary to have a parent module
>>> with only one module inside.
>>>
>>> On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:
>>>>
>>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>>
>>>>> Integration module was moved around into:
>>>>> adapters/
>>>>> adapters/oidc
>>>>> adapters/saml
>>>>> spi/
>>>>>
>>>>> connections, broker, social, events etc. were consolidated.
>>>>>
>>>>> Modules I did not consolidate:
>>>>>
>>>>> federation/*
>>>>>
>>>>> I kept federation separate as I'm wondering what will happen with
>>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>>> separate too.
>>>>>
>>>>> events/syslog
>>>>>
>>>>
>>>> I'm deleting this. Shouldn't have been added in the first place as
>>>> syslog can be done with the syslog appender for regular logging. Besides no
>>>> one actually requested it.
>>>>
>>>>
>>>>>
>>>>> Not sure if this is something we was removable or not as it depends on
>>>>> a
>>>>> thirdparty library.
>>>>>
>>>>> client-registration/*
>>>>>
>>>>
>>>> Moved to integration. It's client lib for client registration service.
>>>>
>>>>
>>>>> wildfly/*
>>>>>
>>>>
>>>> Needs to stay as is. It's all specifics to WF and they can't be
>>>> combined.
>>>>
>>>>
>>>>>
>>>>> I don't know much about these modules so I kept them separate.
>>>>> Stian/Marko can decide what they want to do here.
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/732456b7/attachment-0001.html 

From sthorger at redhat.com  Thu Jan 21 07:37:09 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 13:37:09 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAcAXSiVWqHe=DSskCZTvQ6hQKTpww0bppTpqugiGEdjmA@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<CAJgngAfN70teFCtjsE4T22YDF+xsVZA9aUbhX0mF+fzeYOLEvQ@mail.gmail.com>
	<CAJgngAcAXSiVWqHe=DSskCZTvQ6hQKTpww0bppTpqugiGEdjmA@mail.gmail.com>
Message-ID: <CAJgngAcuECz1Z6wbA62VpPvLeht62vZgUVen5edbQLy05v0ONg@mail.gmail.com>

Should we remove dependencies/server-[min|all] as well? For the testsuite
it'd be better to add a testsuite/embedded-server-dependencies as then it
can include all dependencies and we can re-use it for testsuite/integration
as well as all adapters.

On 21 January 2016 at 13:32, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'm moving forms/common-themes to just themes
>
> On 21 January 2016 at 13:19, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> forms/common-themes we should move this to root and rename to themes
>>
>> On 21 January 2016 at 13:19, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> util/embedded-ldap can we move this to testsuite?
>>>
>>> On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com>
>>> wrote:
>>>
>>>> saml/saml-core I take it that's used by client and server? Should we
>>>> just move saml-core to the root? Seems unnecessary to have a parent module
>>>> with only one module inside.
>>>>
>>>> On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>>>
>>>>>> Integration module was moved around into:
>>>>>> adapters/
>>>>>> adapters/oidc
>>>>>> adapters/saml
>>>>>> spi/
>>>>>>
>>>>>> connections, broker, social, events etc. were consolidated.
>>>>>>
>>>>>> Modules I did not consolidate:
>>>>>>
>>>>>> federation/*
>>>>>>
>>>>>> I kept federation separate as I'm wondering what will happen with
>>>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>>>> separate too.
>>>>>>
>>>>>> events/syslog
>>>>>>
>>>>>
>>>>> I'm deleting this. Shouldn't have been added in the first place as
>>>>> syslog can be done with the syslog appender for regular logging. Besides no
>>>>> one actually requested it.
>>>>>
>>>>>
>>>>>>
>>>>>> Not sure if this is something we was removable or not as it depends
>>>>>> on a
>>>>>> thirdparty library.
>>>>>>
>>>>>> client-registration/*
>>>>>>
>>>>>
>>>>> Moved to integration. It's client lib for client registration service.
>>>>>
>>>>>
>>>>>> wildfly/*
>>>>>>
>>>>>
>>>>> Needs to stay as is. It's all specifics to WF and they can't be
>>>>> combined.
>>>>>
>>>>>
>>>>>>
>>>>>> I don't know much about these modules so I kept them separate.
>>>>>> Stian/Marko can decide what they want to do here.
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> http://bill.burkecentral.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/4cf47482/attachment.html 

From christian.beikov at gmail.com  Thu Jan 21 08:30:50 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 14:30:50 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
Message-ID: <56A0DD8A.7010705@gmail.com>

Hello,

I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but there 
are some problems with that.
You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4 
comes with 1.3.3.Final and there are some binary incompatibilities in 
io.undertow.server.Connectors of which 
org.keycloak.adapters.undertow.SavedRequest is affected.
You are using io.undertow.util.ImmediatePooled instead of the expected 
type io.undertow.connector.PooledByteBuffer which leads to method not 
found exceptions.
I suggest you update the undertow version in the parent pom.xml to make 
sure everything is binary compatible if you are going to support Wildfly 
10 as you announced.

Regards,
Christian

From sthorger at redhat.com  Thu Jan 21 08:43:15 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 14:43:15 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0DD8A.7010705@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
Message-ID: <CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>

How are you deploying the adapter and what adapter are you using? We have
tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
10.0.0.CR5) and it worked fine.

On 21 January 2016 at 14:30, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hello,
>
> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but there
> are some problems with that.
> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
> comes with 1.3.3.Final and there are some binary incompatibilities in
> io.undertow.server.Connectors of which
> org.keycloak.adapters.undertow.SavedRequest is affected.
> You are using io.undertow.util.ImmediatePooled instead of the expected
> type io.undertow.connector.PooledByteBuffer which leads to method not
> found exceptions.
> I suggest you update the undertow version in the parent pom.xml to make
> sure everything is binary compatible if you are going to support Wildfly
> 10 as you announced.
>
> Regards,
> Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/33fb031a/attachment.html 

From sthorger at redhat.com  Thu Jan 21 08:44:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 14:44:04 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
Message-ID: <CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>

BTW we support older versions of WildFly as well as 10, so it's not as
simple as upgrading the undertow version

On 21 January 2016 at 14:43, Stian Thorgersen <sthorger at redhat.com> wrote:

> How are you deploying the adapter and what adapter are you using? We have
> tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
> 10.0.0.CR5) and it worked fine.
>
> On 21 January 2016 at 14:30, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> Hello,
>>
>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but there
>> are some problems with that.
>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>> comes with 1.3.3.Final and there are some binary incompatibilities in
>> io.undertow.server.Connectors of which
>> org.keycloak.adapters.undertow.SavedRequest is affected.
>> You are using io.undertow.util.ImmediatePooled instead of the expected
>> type io.undertow.connector.PooledByteBuffer which leads to method not
>> found exceptions.
>> I suggest you update the undertow version in the parent pom.xml to make
>> sure everything is binary compatible if you are going to support Wildfly
>> 10 as you announced.
>>
>> Regards,
>> Christian
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/64a061c0/attachment.html 

From christian.beikov at gmail.com  Thu Jan 21 08:50:53 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 14:50:53 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
Message-ID: <56A0E23D.3040709@gmail.com>

I deploy the adapter by overlaying/copying the adapter modules into my 
Wildfly.

I understand that you support older Wildfly versions too, but I guess 
you have to create a separate adapter for Wildfly 10 then.
You can easily see that there are incompatibilities between Undertow 
1.2.x and 1.3.x which will result in a failed compilation if you change 
the Undertow version in the parent pom for testing purposes.

Regards,
Christian

Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
> BTW we support older versions of WildFly as well as 10, so it's not as 
> simple as upgrading the undertow version
>
> On 21 January 2016 at 14:43, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     How are you deploying the adapter and what adapter are you using?
>     We have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was
>     tested on 10.0.0.CR5) and it worked fine.
>
>     On 21 January 2016 at 14:30, Christian Beikov
>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>     wrote:
>
>         Hello,
>
>         I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4
>         but there
>         are some problems with that.
>         You are compiling against Undertow 1.1.1.Final but Wildfly
>         10.0.0.CR4
>         comes with 1.3.3.Final and there are some binary
>         incompatibilities in
>         io.undertow.server.Connectors of which
>         org.keycloak.adapters.undertow.SavedRequest is affected.
>         You are using io.undertow.util.ImmediatePooled instead of the
>         expected
>         type io.undertow.connector.PooledByteBuffer which leads to
>         method not
>         found exceptions.
>         I suggest you update the undertow version in the parent
>         pom.xml to make
>         sure everything is binary compatible if you are going to
>         support Wildfly
>         10 as you announced.
>
>         Regards,
>         Christian
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

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

From christian.beikov at gmail.com  Thu Jan 21 08:53:10 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 14:53:10 +0100
Subject: [keycloak-dev] Custom login protocols in 1.8.x
Message-ID: <56A0E2C6.9090407@gmail.com>

You commented out something that makes using custom login protocols 
impossible with the latest Keycloak versions, please remove the static 
array for 1.8.0.Final in: 
https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/resources/js/controllers/clients.js#L741


Regards,
Christian

From bburke at redhat.com  Thu Jan 21 09:22:34 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 09:22:34 -0500
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
Message-ID: <56A0E9AA.6080707@redhat.com>

Yeah, I did that in 1.6....But jboss.org team didn't like it for 
performance reasons.

On 1/20/2016 8:50 PM, Scott Rossillo wrote:
> There's s pattern to handle the back button during flows. It's that a 
> post should never render a view but redirect (HTTP get) to the failure 
> or success view.
>
> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>
>>     One additional thought. Maybe we could add a field to
>>     autheticators to say if they support back, cancel or nothing.
>>     Then the flow would allow going back if previous supports back.
>>     It would allow cancel if all supports it, or nothing is one says
>>     nothing
>>
>>     On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com
>>     <mailto:sthorger at redhat.com>> wrote:
>>
>>         Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can
>>         fix it for 1.9.
>>
>>         Secondly, the back button should not navigate backwards in
>>         the flow. Also, the refresh button should just redisplay the
>>         page as it does now (ignoring the post). A couple ideas to
>>         improve things though:
>>
>>         1) Set cache-control to "Cache-Control: no-store,
>>         must-revalidate, max-age=0". This should force a reload of
>>         the page when the user clicks the back button
>>
>
>     Really?  That's cool then, this will basically "disable" the back
>     button :)  I'll try it out.
>
>
>>         2) Can we add a back link to some steps in the flow?
>>         3) Can we add a cancel link to some steps in the flow?
>>
>
>     You can reset the flow to the beginning, but can't go back one step.
>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

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

From sthorger at redhat.com  Thu Jan 21 10:00:12 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:00:12 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0E23D.3040709@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
Message-ID: <CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>

When we tested it, it worked. So I need more details from you to reproduce
this.

On 21 January 2016 at 14:50, Christian Beikov <christian.beikov at gmail.com>
wrote:

> I deploy the adapter by overlaying/copying the adapter modules into my
> Wildfly.
>
> I understand that you support older Wildfly versions too, but I guess you
> have to create a separate adapter for Wildfly 10 then.
> You can easily see that there are incompatibilities between Undertow 1.2.x
> and 1.3.x which will result in a failed compilation if you change the
> Undertow version in the parent pom for testing purposes.
>
> Regards,
> Christian
>
>
> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>
> BTW we support older versions of WildFly as well as 10, so it's not as
> simple as upgrading the undertow version
>
> On 21 January 2016 at 14:43, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> How are you deploying the adapter and what adapter are you using? We have
>> tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>> 10.0.0.CR5) and it worked fine.
>>
>> On 21 January 2016 at 14:30, Christian Beikov <
>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but there
>>> are some problems with that.
>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>> io.undertow.server.Connectors of which
>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>> You are using io.undertow.util.ImmediatePooled instead of the expected
>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>> found exceptions.
>>> I suggest you update the undertow version in the parent pom.xml to make
>>> sure everything is binary compatible if you are going to support Wildfly
>>> 10 as you announced.
>>>
>>> Regards,
>>> Christian
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/ff4a9541/attachment.html 

From sthorger at redhat.com  Thu Jan 21 10:01:08 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:01:08 +0100
Subject: [keycloak-dev] Custom login protocols in 1.8.x
In-Reply-To: <56A0E2C6.9090407@gmail.com>
References: <56A0E2C6.9090407@gmail.com>
Message-ID: <CAJgngAfZ4hf+3b2iJtg68AKPRu8Ar97h2gCn8=-Rr7robnPeRQ@mail.gmail.com>

Please create a JIRA

On 21 January 2016 at 14:53, Christian Beikov <christian.beikov at gmail.com>
wrote:

> You commented out something that makes using custom login protocols
> impossible with the latest Keycloak versions, please remove the static
> array for 1.8.0.Final in:
>
> https://github.com/keycloak/keycloak/blob/master/themes/src/main/resources/theme/base/admin/resources/js/controllers/clients.js#L741
>
>
> Regards,
> Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/13f0fee7/attachment.html 

From christian.beikov at gmail.com  Thu Jan 21 10:07:50 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 16:07:50 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
Message-ID: <56A0F446.8000809@gmail.com>

As I wrote, when you change the Undertow version in the parent pom, a 
build will generate a compilation error when using the Undertow version 
that is used in Wildfly 10 which would be 1.3.x.

I encountered the following exception in the Undertow adapters because 
of binary incompatibilities between Undertow 1.2.x and 1.3.x:

java.lang.NoSuchMethodError: 
io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
         at 
org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
         at 
org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
         at 
org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
         at 
org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
         at 
org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
         at 
org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)


Regards,
Christian

Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
> When we tested it, it worked. So I need more details from you to 
> reproduce this.
>
> On 21 January 2016 at 14:50, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I deploy the adapter by overlaying/copying the adapter modules
>     into my Wildfly.
>
>     I understand that you support older Wildfly versions too, but I
>     guess you have to create a separate adapter for Wildfly 10 then.
>     You can easily see that there are incompatibilities between
>     Undertow 1.2.x and 1.3.x which will result in a failed compilation
>     if you change the Undertow version in the parent pom for testing
>     purposes.
>
>     Regards,
>     Christian
>
>
>     Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>     BTW we support older versions of WildFly as well as 10, so it's
>>     not as simple as upgrading the undertow version
>>
>>     On 21 January 2016 at 14:43, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>         How are you deploying the adapter and what adapter are you
>>         using? We have tested the adapter with WildFly 10 (Keycloak
>>         1.8.0.CR1 was tested on 10.0.0.CR5) and it worked fine.
>>
>>         On 21 January 2016 at 14:30, Christian Beikov
>>         <christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>> wrote:
>>
>>             Hello,
>>
>>             I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly
>>             10.0.0.CR4 but there
>>             are some problems with that.
>>             You are compiling against Undertow 1.1.1.Final but
>>             Wildfly 10.0.0.CR4
>>             comes with 1.3.3.Final and there are some binary
>>             incompatibilities in
>>             io.undertow.server.Connectors of which
>>             org.keycloak.adapters.undertow.SavedRequest is affected.
>>             You are using io.undertow.util.ImmediatePooled instead of
>>             the expected
>>             type io.undertow.connector.PooledByteBuffer which leads
>>             to method not
>>             found exceptions.
>>             I suggest you update the undertow version in the parent
>>             pom.xml to make
>>             sure everything is binary compatible if you are going to
>>             support Wildfly
>>             10 as you announced.
>>
>>             Regards,
>>             Christian
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>

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

From sthorger at redhat.com  Thu Jan 21 10:09:50 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:09:50 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F446.8000809@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
Message-ID: <CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>

What is your problem when you are actually using the adapter?

As I said we need the adapter to compile against multiple versions, we can
not maintain one per version of WildFly.

On 21 January 2016 at 16:07, Christian Beikov <christian.beikov at gmail.com>
wrote:

> As I wrote, when you change the Undertow version in the parent pom, a
> build will generate a compilation error when using the Undertow version
> that is used in Wildfly 10 which would be 1.3.x.
>
> I encountered the following exception in the Undertow adapters because of
> binary incompatibilities between Undertow 1.2.x and 1.3.x:
>
> java.lang.NoSuchMethodError:
> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>         at
> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>         at
> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>         at
> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>         at
> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>         at
> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>         at
> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>
>
> Regards,
> Christian
>
>
> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>
> When we tested it, it worked. So I need more details from you to reproduce
> this.
>
> On 21 January 2016 at 14:50, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> I deploy the adapter by overlaying/copying the adapter modules into my
>> Wildfly.
>>
>> I understand that you support older Wildfly versions too, but I guess you
>> have to create a separate adapter for Wildfly 10 then.
>> You can easily see that there are incompatibilities between Undertow
>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>> Undertow version in the parent pom for testing purposes.
>>
>> Regards,
>> Christian
>>
>>
>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>
>> BTW we support older versions of WildFly as well as 10, so it's not as
>> simple as upgrading the undertow version
>>
>> On 21 January 2016 at 14:43, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>> How are you deploying the adapter and what adapter are you using? We
>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>> 10.0.0.CR5) and it worked fine.
>>>
>>> On 21 January 2016 at 14:30, Christian Beikov <
>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but there
>>>> are some problems with that.
>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>> io.undertow.server.Connectors of which
>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>> You are using io.undertow.util.ImmediatePooled instead of the expected
>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>> found exceptions.
>>>> I suggest you update the undertow version in the parent pom.xml to make
>>>> sure everything is binary compatible if you are going to support Wildfly
>>>> 10 as you announced.
>>>>
>>>> Regards,
>>>> Christian
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/7535e66f/attachment.html 

From gambol99 at gmail.com  Thu Jan 21 10:13:50 2016
From: gambol99 at gmail.com (gambol)
Date: Thu, 21 Jan 2016 15:13:50 +0000
Subject: [keycloak-dev] User / Realm Management
Message-ID: <CA+AP+fOUBUuKYiWmd4X61hx+2kvwUtn5VZu9FFupcBea1eZRLQ@mail.gmail.com>

Hiya


It's a little confusing how best to use Keycloak and realms; ideally I'd
like to have a realm per application or group of interrelated applications,
i.e. a realm for JIra, one for gitlab for example, but the fact users can't
cross realms would make this difficult, I support you could use a social
provider to mitigate setting up duplicate credentials, but I doubt would
help with OTP. Is there any proposals about separating the permissions of a
user in a realm from their identity, i.e. you could have a global user
(same creds and OTP) but where permissions in a realm can be changes
independent of the user.

Appreciate your thoughts ..

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

From bburke at redhat.com  Thu Jan 21 10:15:39 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 10:15:39 -0500
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
Message-ID: <56A0F61B.2050609@redhat.com>

Log a jira and schedule for 1.9.  I'll either create a new adapter or 
find a workaround that is backward compatible.

On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
> What is your problem when you are actually using the adapter?
>
> As I said we need the adapter to compile against multiple versions, we 
> can not maintain one per version of WildFly.
>
> On 21 January 2016 at 16:07, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     As I wrote, when you change the Undertow version in the parent
>     pom, a build will generate a compilation error when using the
>     Undertow version that is used in Wildfly 10 which would be 1.3.x.
>
>     I encountered the following exception in the Undertow adapters
>     because of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>
>     java.lang.NoSuchMethodError:
>     io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>             at
>     org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>             at
>     org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>             at
>     org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>             at
>     org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>             at
>     org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>             at
>     org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>
>
>     Regards,
>     Christian
>
>
>     Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>     When we tested it, it worked. So I need more details from you to
>>     reproduce this.
>>
>>     On 21 January 2016 at 14:50, Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         I deploy the adapter by overlaying/copying the adapter
>>         modules into my Wildfly.
>>
>>         I understand that you support older Wildfly versions too, but
>>         I guess you have to create a separate adapter for Wildfly 10
>>         then.
>>         You can easily see that there are incompatibilities between
>>         Undertow 1.2.x and 1.3.x which will result in a failed
>>         compilation if you change the Undertow version in the parent
>>         pom for testing purposes.
>>
>>         Regards,
>>         Christian
>>
>>
>>         Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>         BTW we support older versions of WildFly as well as 10, so
>>>         it's not as simple as upgrading the undertow version
>>>
>>>         On 21 January 2016 at 14:43, Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>             How are you deploying the adapter and what adapter are
>>>             you using? We have tested the adapter with WildFly 10
>>>             (Keycloak 1.8.0.CR1 was tested on 10.0.0.CR5) and it
>>>             worked fine.
>>>
>>>             On 21 January 2016 at 14:30, Christian Beikov
>>>             <christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>                 Hello,
>>>
>>>                 I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly
>>>                 10.0.0.CR4 but there
>>>                 are some problems with that.
>>>                 You are compiling against Undertow 1.1.1.Final but
>>>                 Wildfly 10.0.0.CR4
>>>                 comes with 1.3.3.Final and there are some binary
>>>                 incompatibilities in
>>>                 io.undertow.server.Connectors of which
>>>                 org.keycloak.adapters.undertow.SavedRequest is affected.
>>>                 You are using io.undertow.util.ImmediatePooled
>>>                 instead of the expected
>>>                 type io.undertow.connector.PooledByteBuffer which
>>>                 leads to method not
>>>                 found exceptions.
>>>                 I suggest you update the undertow version in the
>>>                 parent pom.xml to make
>>>                 sure everything is binary compatible if you are
>>>                 going to support Wildfly
>>>                 10 as you announced.
>>>
>>>                 Regards,
>>>                 Christian
>>>                 _______________________________________________
>>>                 keycloak-dev mailing list
>>>                 keycloak-dev at lists.jboss.org
>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Thu Jan 21 10:18:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:18:41 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F61B.2050609@redhat.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
Message-ID: <CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>

If the adapter is broken for WF10, we need to fix for 1.8 as well

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

> Log a jira and schedule for 1.9.  I'll either create a new adapter or find
> a workaround that is backward compatible.
>
> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>
> What is your problem when you are actually using the adapter?
>
> As I said we need the adapter to compile against multiple versions, we can
> not maintain one per version of WildFly.
>
> On 21 January 2016 at 16:07, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> As I wrote, when you change the Undertow version in the parent pom, a
>> build will generate a compilation error when using the Undertow version
>> that is used in Wildfly 10 which would be 1.3.x.
>>
>> I encountered the following exception in the Undertow adapters because of
>> binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>
>> java.lang.NoSuchMethodError:
>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>         at
>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>         at
>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>         at
>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>         at
>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>         at
>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>         at
>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>
>>
>> Regards,
>> Christian
>>
>>
>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>
>> When we tested it, it worked. So I need more details from you to
>> reproduce this.
>>
>> On 21 January 2016 at 14:50, Christian Beikov <
>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>
>>> I deploy the adapter by overlaying/copying the adapter modules into my
>>> Wildfly.
>>>
>>> I understand that you support older Wildfly versions too, but I guess
>>> you have to create a separate adapter for Wildfly 10 then.
>>> You can easily see that there are incompatibilities between Undertow
>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>> Undertow version in the parent pom for testing purposes.
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>
>>> BTW we support older versions of WildFly as well as 10, so it's not as
>>> simple as upgrading the undertow version
>>>
>>> On 21 January 2016 at 14:43, Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>> How are you deploying the adapter and what adapter are you using? We
>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>> 10.0.0.CR5) and it worked fine.
>>>>
>>>> On 21 January 2016 at 14:30, Christian Beikov <
>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>> there
>>>>> are some problems with that.
>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>>> io.undertow.server.Connectors of which
>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>> You are using io.undertow.util.ImmediatePooled instead of the expected
>>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>>> found exceptions.
>>>>> I suggest you update the undertow version in the parent pom.xml to make
>>>>> sure everything is binary compatible if you are going to support
>>>>> Wildfly
>>>>> 10 as you announced.
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/067e44e5/attachment.html 

From sthorger at redhat.com  Thu Jan 21 10:19:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:19:20 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
Message-ID: <CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>

It depends on what the actual problem is though, because we have tested it
on WF10 and we didn't discover any issues

On 21 January 2016 at 16:18, Stian Thorgersen <sthorger at redhat.com> wrote:

> If the adapter is broken for WF10, we need to fix for 1.8 as well
>
> On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com> wrote:
>
>> Log a jira and schedule for 1.9.  I'll either create a new adapter or
>> find a workaround that is backward compatible.
>>
>> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>
>> What is your problem when you are actually using the adapter?
>>
>> As I said we need the adapter to compile against multiple versions, we
>> can not maintain one per version of WildFly.
>>
>> On 21 January 2016 at 16:07, Christian Beikov <christian.beikov at gmail.com
>> > wrote:
>>
>>> As I wrote, when you change the Undertow version in the parent pom, a
>>> build will generate a compilation error when using the Undertow version
>>> that is used in Wildfly 10 which would be 1.3.x.
>>>
>>> I encountered the following exception in the Undertow adapters because
>>> of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>>
>>> java.lang.NoSuchMethodError:
>>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>         at
>>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>         at
>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>         at
>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>         at
>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>         at
>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>         at
>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>
>>> When we tested it, it worked. So I need more details from you to
>>> reproduce this.
>>>
>>> On 21 January 2016 at 14:50, Christian Beikov <
>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>
>>>> I deploy the adapter by overlaying/copying the adapter modules into my
>>>> Wildfly.
>>>>
>>>> I understand that you support older Wildfly versions too, but I guess
>>>> you have to create a separate adapter for Wildfly 10 then.
>>>> You can easily see that there are incompatibilities between Undertow
>>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>>> Undertow version in the parent pom for testing purposes.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>
>>>> BTW we support older versions of WildFly as well as 10, so it's not as
>>>> simple as upgrading the undertow version
>>>>
>>>> On 21 January 2016 at 14:43, Stian Thorgersen < <sthorger at redhat.com>
>>>> sthorger at redhat.com> wrote:
>>>>
>>>>> How are you deploying the adapter and what adapter are you using? We
>>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>>> 10.0.0.CR5) and it worked fine.
>>>>>
>>>>> On 21 January 2016 at 14:30, Christian Beikov <
>>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>>> there
>>>>>> are some problems with that.
>>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>>>> io.undertow.server.Connectors of which
>>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>>> You are using io.undertow.util.ImmediatePooled instead of the expected
>>>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>>>> found exceptions.
>>>>>> I suggest you update the undertow version in the parent pom.xml to
>>>>>> make
>>>>>> sure everything is binary compatible if you are going to support
>>>>>> Wildfly
>>>>>> 10 as you announced.
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/43059c05/attachment-0001.html 

From mstrukel at redhat.com  Thu Jan 21 10:20:41 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 21 Jan 2016 16:20:41 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
Message-ID: <CA+1OW+hESFLHSgVObG4ACw89L3NGkQt3gtpmCnuOHnz2QoWwnQ@mail.gmail.com>

I just tried deploying the 1.8.0.CR1 adapter to Wildfly 10.0.0.CR4,
and it works without any issues.

Christian, please provide us with steps to reproduce your problem.

On Thu, Jan 21, 2016 at 4:18 PM, Stian Thorgersen <sthorger at redhat.com> wrote:
> If the adapter is broken for WF10, we need to fix for 1.8 as well
>
> On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com> wrote:
>>
>> Log a jira and schedule for 1.9.  I'll either create a new adapter or find
>> a workaround that is backward compatible.
>>
>> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>
>> What is your problem when you are actually using the adapter?
>>
>> As I said we need the adapter to compile against multiple versions, we can
>> not maintain one per version of WildFly.
>>
>> On 21 January 2016 at 16:07, Christian Beikov <christian.beikov at gmail.com>
>> wrote:
>>>
>>> As I wrote, when you change the Undertow version in the parent pom, a
>>> build will generate a compilation error when using the Undertow version that
>>> is used in Wildfly 10 which would be 1.3.x.
>>>
>>> I encountered the following exception in the Undertow adapters because of
>>> binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>>
>>> java.lang.NoSuchMethodError:
>>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>         at
>>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>         at
>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>         at
>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>         at
>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>         at
>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>         at
>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>
>>> When we tested it, it worked. So I need more details from you to
>>> reproduce this.
>>>
>>> On 21 January 2016 at 14:50, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>>
>>>> I deploy the adapter by overlaying/copying the adapter modules into my
>>>> Wildfly.
>>>>
>>>> I understand that you support older Wildfly versions too, but I guess
>>>> you have to create a separate adapter for Wildfly 10 then.
>>>> You can easily see that there are incompatibilities between Undertow
>>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>>> Undertow version in the parent pom for testing purposes.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>
>>>> BTW we support older versions of WildFly as well as 10, so it's not as
>>>> simple as upgrading the undertow version
>>>>
>>>> On 21 January 2016 at 14:43, Stian Thorgersen <sthorger at redhat.com>
>>>> wrote:
>>>>>
>>>>> How are you deploying the adapter and what adapter are you using? We
>>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>>> 10.0.0.CR5) and it worked fine.
>>>>>
>>>>> On 21 January 2016 at 14:30, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>>> there
>>>>>> are some problems with that.
>>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>>>> io.undertow.server.Connectors of which
>>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>>> You are using io.undertow.util.ImmediatePooled instead of the expected
>>>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>>>> found exceptions.
>>>>>> I suggest you update the undertow version in the parent pom.xml to
>>>>>> make
>>>>>> sure everything is binary compatible if you are going to support
>>>>>> Wildfly
>>>>>> 10 as you announced.
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From christian.beikov at gmail.com  Thu Jan 21 10:20:57 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 16:20:57 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
Message-ID: <56A0F759.4080607@gmail.com>

Because you probably didn't hit the code that is binary incompatible. As 
you can see in the stacktrace, the ungetRequestBytes method has a 
different signature in Undertow 1.3.x

Am 21.01.2016 um 16:19 schrieb Stian Thorgersen:
> It depends on what the actual problem is though, because we have 
> tested it on WF10 and we didn't discover any issues
>
> On 21 January 2016 at 16:18, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     If the adapter is broken for WF10, we need to fix for 1.8 as well
>
>     On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         Log a jira and schedule for 1.9.  I'll either create a new
>         adapter or find a workaround that is backward compatible.
>
>         On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>         What is your problem when you are actually using the adapter?
>>
>>         As I said we need the adapter to compile against multiple
>>         versions, we can not maintain one per version of WildFly.
>>
>>         On 21 January 2016 at 16:07, Christian Beikov
>>         <christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>> wrote:
>>
>>             As I wrote, when you change the Undertow version in the
>>             parent pom, a build will generate a compilation error
>>             when using the Undertow version that is used in Wildfly
>>             10 which would be 1.3.x.
>>
>>             I encountered the following exception in the Undertow
>>             adapters because of binary incompatibilities between
>>             Undertow 1.2.x and 1.3.x:
>>
>>             java.lang.NoSuchMethodError:
>>             io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>                     at
>>             org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>                     at
>>             org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>                     at
>>             org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>                     at
>>             org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>                     at
>>             org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>                     at
>>             org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>
>>
>>             Regards,
>>             Christian
>>
>>
>>             Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>             When we tested it, it worked. So I need more details
>>>             from you to reproduce this.
>>>
>>>             On 21 January 2016 at 14:50, Christian Beikov
>>>             <christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>                 I deploy the adapter by overlaying/copying the
>>>                 adapter modules into my Wildfly.
>>>
>>>                 I understand that you support older Wildfly versions
>>>                 too, but I guess you have to create a separate
>>>                 adapter for Wildfly 10 then.
>>>                 You can easily see that there are incompatibilities
>>>                 between Undertow 1.2.x and 1.3.x which will result
>>>                 in a failed compilation if you change the Undertow
>>>                 version in the parent pom for testing purposes.
>>>
>>>                 Regards,
>>>                 Christian
>>>
>>>
>>>                 Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>                 BTW we support older versions of WildFly as well as
>>>>                 10, so it's not as simple as upgrading the undertow
>>>>                 version
>>>>
>>>>                 On 21 January 2016 at 14:43, Stian Thorgersen
>>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>>                 wrote:
>>>>
>>>>                     How are you deploying the adapter and what
>>>>                     adapter are you using? We have tested the
>>>>                     adapter with WildFly 10 (Keycloak 1.8.0.CR1 was
>>>>                     tested on 10.0.0.CR5) and it worked fine.
>>>>
>>>>                     On 21 January 2016 at 14:30, Christian Beikov
>>>>                     <christian.beikov at gmail.com
>>>>                     <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                         Hello,
>>>>
>>>>                         I am trying to deploy Keycloak 1.8.0.CR1 to
>>>>                         Wildfly 10.0.0.CR4 but there
>>>>                         are some problems with that.
>>>>                         You are compiling against Undertow
>>>>                         1.1.1.Final but Wildfly 10.0.0.CR4
>>>>                         comes with 1.3.3.Final and there are some
>>>>                         binary incompatibilities in
>>>>                         io.undertow.server.Connectors of which
>>>>                         org.keycloak.adapters.undertow.SavedRequest
>>>>                         is affected.
>>>>                         You are using
>>>>                         io.undertow.util.ImmediatePooled instead of
>>>>                         the expected
>>>>                         type io.undertow.connector.PooledByteBuffer
>>>>                         which leads to method not
>>>>                         found exceptions.
>>>>                         I suggest you update the undertow version
>>>>                         in the parent pom.xml to make
>>>>                         sure everything is binary compatible if you
>>>>                         are going to support Wildfly
>>>>                         10 as you announced.
>>>>
>>>>                         Regards,
>>>>                         Christian
>>>>                         _______________________________________________
>>>>                         keycloak-dev mailing list
>>>>                         keycloak-dev at lists.jboss.org
>>>>                         <mailto:keycloak-dev at lists.jboss.org>
>>>>                         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>         -- 
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mstrukel at redhat.com  Thu Jan 21 10:25:33 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Thu, 21 Jan 2016 16:25:33 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F759.4080607@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
	<56A0F759.4080607@gmail.com>
Message-ID: <CA+1OW+iJ+bPS+3_B1u4W6S-4XiyF3rXJ=okwO8RT_8J3ZH0-SA@mail.gmail.com>

What do I have to do to trigger this?

>>> java.lang.NoSuchMethodError: io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>         at org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>         at org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>         at org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>         at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>         at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>         at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)


Our testing procedure is inadequate if we are unable to detect this error.


On Thu, Jan 21, 2016 at 4:20 PM, Christian Beikov
<christian.beikov at gmail.com> wrote:
> Because you probably didn't hit the code that is binary incompatible. As you
> can see in the stacktrace, the ungetRequestBytes method has a different
> signature in Undertow 1.3.x
>
>
> Am 21.01.2016 um 16:19 schrieb Stian Thorgersen:
>
> It depends on what the actual problem is though, because we have tested it
> on WF10 and we didn't discover any issues
>
> On 21 January 2016 at 16:18, Stian Thorgersen <sthorger at redhat.com> wrote:
>>
>> If the adapter is broken for WF10, we need to fix for 1.8 as well
>>
>> On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com> wrote:
>>>
>>> Log a jira and schedule for 1.9.  I'll either create a new adapter or
>>> find a workaround that is backward compatible.
>>>
>>> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>>
>>> What is your problem when you are actually using the adapter?
>>>
>>> As I said we need the adapter to compile against multiple versions, we
>>> can not maintain one per version of WildFly.
>>>
>>> On 21 January 2016 at 16:07, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>>
>>>> As I wrote, when you change the Undertow version in the parent pom, a
>>>> build will generate a compilation error when using the Undertow version that
>>>> is used in Wildfly 10 which would be 1.3.x.
>>>>
>>>> I encountered the following exception in the Undertow adapters because
>>>> of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>>>
>>>> java.lang.NoSuchMethodError:
>>>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>>         at
>>>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>>         at
>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>>         at
>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>>
>>>> When we tested it, it worked. So I need more details from you to
>>>> reproduce this.
>>>>
>>>> On 21 January 2016 at 14:50, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>>
>>>>> I deploy the adapter by overlaying/copying the adapter modules into my
>>>>> Wildfly.
>>>>>
>>>>> I understand that you support older Wildfly versions too, but I guess
>>>>> you have to create a separate adapter for Wildfly 10 then.
>>>>> You can easily see that there are incompatibilities between Undertow
>>>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>>>> Undertow version in the parent pom for testing purposes.
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>>
>>>>> BTW we support older versions of WildFly as well as 10, so it's not as
>>>>> simple as upgrading the undertow version
>>>>>
>>>>> On 21 January 2016 at 14:43, Stian Thorgersen <sthorger at redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> How are you deploying the adapter and what adapter are you using? We
>>>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>>>> 10.0.0.CR5) and it worked fine.
>>>>>>
>>>>>> On 21 January 2016 at 14:30, Christian Beikov
>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>>>> there
>>>>>>> are some problems with that.
>>>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>>>>> io.undertow.server.Connectors of which
>>>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>>>> You are using io.undertow.util.ImmediatePooled instead of the
>>>>>>> expected
>>>>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>>>>> found exceptions.
>>>>>>> I suggest you update the undertow version in the parent pom.xml to
>>>>>>> make
>>>>>>> sure everything is binary compatible if you are going to support
>>>>>>> Wildfly
>>>>>>> 10 as you announced.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Christian
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From sthorger at redhat.com  Thu Jan 21 10:25:52 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:25:52 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F759.4080607@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
	<56A0F759.4080607@gmail.com>
Message-ID: <CAJgngAdejqCj9bXbYigK1bj_2M__Xgi3GitiqQgeXUdg8WNV=w@mail.gmail.com>

When/how do you hit the code that is binary incompatible though?

On 21 January 2016 at 16:20, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Because you probably didn't hit the code that is binary incompatible. As
> you can see in the stacktrace, the ungetRequestBytes method has a different
> signature in Undertow 1.3.x
>
>
> Am 21.01.2016 um 16:19 schrieb Stian Thorgersen:
>
> It depends on what the actual problem is though, because we have tested it
> on WF10 and we didn't discover any issues
>
> On 21 January 2016 at 16:18, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> If the adapter is broken for WF10, we need to fix for 1.8 as well
>>
>> On 21 January 2016 at 16:15, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>> Log a jira and schedule for 1.9.  I'll either create a new adapter or
>>> find a workaround that is backward compatible.
>>>
>>> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>>
>>> What is your problem when you are actually using the adapter?
>>>
>>> As I said we need the adapter to compile against multiple versions, we
>>> can not maintain one per version of WildFly.
>>>
>>> On 21 January 2016 at 16:07, Christian Beikov <
>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>
>>>> As I wrote, when you change the Undertow version in the parent pom, a
>>>> build will generate a compilation error when using the Undertow version
>>>> that is used in Wildfly 10 which would be 1.3.x.
>>>>
>>>> I encountered the following exception in the Undertow adapters because
>>>> of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>>>
>>>> java.lang.NoSuchMethodError:
>>>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>>         at
>>>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>>         at
>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>>         at
>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>         at
>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>>
>>>> When we tested it, it worked. So I need more details from you to
>>>> reproduce this.
>>>>
>>>> On 21 January 2016 at 14:50, Christian Beikov <
>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>
>>>>> I deploy the adapter by overlaying/copying the adapter modules into my
>>>>> Wildfly.
>>>>>
>>>>> I understand that you support older Wildfly versions too, but I guess
>>>>> you have to create a separate adapter for Wildfly 10 then.
>>>>> You can easily see that there are incompatibilities between Undertow
>>>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>>>> Undertow version in the parent pom for testing purposes.
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>>
>>>>> BTW we support older versions of WildFly as well as 10, so it's not as
>>>>> simple as upgrading the undertow version
>>>>>
>>>>> On 21 January 2016 at 14:43, Stian Thorgersen < <sthorger at redhat.com>
>>>>> sthorger at redhat.com> wrote:
>>>>>
>>>>>> How are you deploying the adapter and what adapter are you using? We
>>>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>>>> 10.0.0.CR5) and it worked fine.
>>>>>>
>>>>>> On 21 January 2016 at 14:30, Christian Beikov <
>>>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>>>> there
>>>>>>> are some problems with that.
>>>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly 10.0.0.CR4
>>>>>>> comes with 1.3.3.Final and there are some binary incompatibilities in
>>>>>>> io.undertow.server.Connectors of which
>>>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>>>> You are using io.undertow.util.ImmediatePooled instead of the
>>>>>>> expected
>>>>>>> type io.undertow.connector.PooledByteBuffer which leads to method not
>>>>>>> found exceptions.
>>>>>>> I suggest you update the undertow version in the parent pom.xml to
>>>>>>> make
>>>>>>> sure everything is binary compatible if you are going to support
>>>>>>> Wildfly
>>>>>>> 10 as you announced.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Christian
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/e0da148d/attachment-0001.html 

From christian.beikov at gmail.com  Thu Jan 21 10:28:40 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 16:28:40 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAdejqCj9bXbYigK1bj_2M__Xgi3GitiqQgeXUdg8WNV=w@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
	<56A0F759.4080607@gmail.com>
	<CAJgngAdejqCj9bXbYigK1bj_2M__Xgi3GitiqQgeXUdg8WNV=w@mail.gmail.com>
Message-ID: <56A0F928.6060901@gmail.com>

Trying to write up the JIRA issue for this now, but as far as I can say, 
it happens when I refresh(GET request) a page that is secured.

Regards,
Christian

Am 21.01.2016 um 16:25 schrieb Stian Thorgersen:
> When/how do you hit the code that is binary incompatible though?
>
> On 21 January 2016 at 16:20, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Because you probably didn't hit the code that is binary
>     incompatible. As you can see in the stacktrace, the
>     ungetRequestBytes method has a different signature in Undertow 1.3.x
>
>
>     Am 21.01.2016 um 16:19 schrieb Stian Thorgersen:
>>     It depends on what the actual problem is though, because we have
>>     tested it on WF10 and we didn't discover any issues
>>
>>     On 21 January 2016 at 16:18, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>         If the adapter is broken for WF10, we need to fix for 1.8 as well
>>
>>         On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>> wrote:
>>
>>             Log a jira and schedule for 1.9.  I'll either create a
>>             new adapter or find a workaround that is backward
>>             compatible.
>>
>>             On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>>             What is your problem when you are actually using the
>>>             adapter?
>>>
>>>             As I said we need the adapter to compile against
>>>             multiple versions, we can not maintain one per version
>>>             of WildFly.
>>>
>>>             On 21 January 2016 at 16:07, Christian Beikov
>>>             <christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>                 As I wrote, when you change the Undertow version in
>>>                 the parent pom, a build will generate a compilation
>>>                 error when using the Undertow version that is used
>>>                 in Wildfly 10 which would be 1.3.x.
>>>
>>>                 I encountered the following exception in the
>>>                 Undertow adapters because of binary
>>>                 incompatibilities between Undertow 1.2.x and 1.3.x:
>>>
>>>                 java.lang.NoSuchMethodError:
>>>                 io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>                         at
>>>                 org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>                         at
>>>                 org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>                         at
>>>                 org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>                         at
>>>                 org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>                         at
>>>                 org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>                         at
>>>                 org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>
>>>
>>>                 Regards,
>>>                 Christian
>>>
>>>
>>>                 Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>>                 When we tested it, it worked. So I need more
>>>>                 details from you to reproduce this.
>>>>
>>>>                 On 21 January 2016 at 14:50, Christian Beikov
>>>>                 <christian.beikov at gmail.com
>>>>                 <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                     I deploy the adapter by overlaying/copying the
>>>>                     adapter modules into my Wildfly.
>>>>
>>>>                     I understand that you support older Wildfly
>>>>                     versions too, but I guess you have to create a
>>>>                     separate adapter for Wildfly 10 then.
>>>>                     You can easily see that there are
>>>>                     incompatibilities between Undertow 1.2.x and
>>>>                     1.3.x which will result in a failed compilation
>>>>                     if you change the Undertow version in the
>>>>                     parent pom for testing purposes.
>>>>
>>>>                     Regards,
>>>>                     Christian
>>>>
>>>>
>>>>                     Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>>                     BTW we support older versions of WildFly as
>>>>>                     well as 10, so it's not as simple as upgrading
>>>>>                     the undertow version
>>>>>
>>>>>                     On 21 January 2016 at 14:43, Stian Thorgersen
>>>>>                     <sthorger at redhat.com
>>>>>                     <mailto:sthorger at redhat.com>> wrote:
>>>>>
>>>>>                         How are you deploying the adapter and what
>>>>>                         adapter are you using? We have tested the
>>>>>                         adapter with WildFly 10 (Keycloak
>>>>>                         1.8.0.CR1 was tested on 10.0.0.CR5) and it
>>>>>                         worked fine.
>>>>>
>>>>>                         On 21 January 2016 at 14:30, Christian
>>>>>                         Beikov <christian.beikov at gmail.com
>>>>>                         <mailto:christian.beikov at gmail.com>> wrote:
>>>>>
>>>>>                             Hello,
>>>>>
>>>>>                             I am trying to deploy Keycloak
>>>>>                             1.8.0.CR1 to Wildfly 10.0.0.CR4 but there
>>>>>                             are some problems with that.
>>>>>                             You are compiling against Undertow
>>>>>                             1.1.1.Final but Wildfly 10.0.0.CR4
>>>>>                             comes with 1.3.3.Final and there are
>>>>>                             some binary incompatibilities in
>>>>>                             io.undertow.server.Connectors of which
>>>>>                             org.keycloak.adapters.undertow.SavedRequest
>>>>>                             is affected.
>>>>>                             You are using
>>>>>                             io.undertow.util.ImmediatePooled
>>>>>                             instead of the expected
>>>>>                             type
>>>>>                             io.undertow.connector.PooledByteBuffer
>>>>>                             which leads to method not
>>>>>                             found exceptions.
>>>>>                             I suggest you update the undertow
>>>>>                             version in the parent pom.xml to make
>>>>>                             sure everything is binary compatible
>>>>>                             if you are going to support Wildfly
>>>>>                             10 as you announced.
>>>>>
>>>>>                             Regards,
>>>>>                             Christian
>>>>>                             _______________________________________________
>>>>>                             keycloak-dev mailing list
>>>>>                             keycloak-dev at lists.jboss.org
>>>>>                             <mailto:keycloak-dev at lists.jboss.org>
>>>>>                             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             keycloak-dev mailing list
>>>             keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>             -- 
>>             Bill Burke
>>             JBoss, a division of Red Hat
>>             http://bill.burkecentral.com
>>
>>
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Thu Jan 21 10:32:59 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 16:32:59 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F928.6060901@gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
	<56A0F759.4080607@gmail.com>
	<CAJgngAdejqCj9bXbYigK1bj_2M__Xgi3GitiqQgeXUdg8WNV=w@mail.gmail.com>
	<56A0F928.6060901@gmail.com>
Message-ID: <CAJgngAdqJSERwgirn9sVz2JgegXwEdE=V=Z_d6FX5Mc-4+z6yg@mail.gmail.com>

Thanks, hopefully we can fix it for 1.8.0.Final due next week.

On 21 January 2016 at 16:28, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Trying to write up the JIRA issue for this now, but as far as I can say,
> it happens when I refresh(GET request) a page that is secured.
>
> Regards,
> Christian
>
>
> Am 21.01.2016 um 16:25 schrieb Stian Thorgersen:
>
> When/how do you hit the code that is binary incompatible though?
>
> On 21 January 2016 at 16:20, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> Because you probably didn't hit the code that is binary incompatible. As
>> you can see in the stacktrace, the ungetRequestBytes method has a different
>> signature in Undertow 1.3.x
>>
>>
>> Am 21.01.2016 um 16:19 schrieb Stian Thorgersen:
>>
>> It depends on what the actual problem is though, because we have tested
>> it on WF10 and we didn't discover any issues
>>
>> On 21 January 2016 at 16:18, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>> If the adapter is broken for WF10, we need to fix for 1.8 as well
>>>
>>> On 21 January 2016 at 16:15, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> Log a jira and schedule for 1.9.  I'll either create a new adapter or
>>>> find a workaround that is backward compatible.
>>>>
>>>> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>>>
>>>> What is your problem when you are actually using the adapter?
>>>>
>>>> As I said we need the adapter to compile against multiple versions, we
>>>> can not maintain one per version of WildFly.
>>>>
>>>> On 21 January 2016 at 16:07, Christian Beikov <
>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>
>>>>> As I wrote, when you change the Undertow version in the parent pom, a
>>>>> build will generate a compilation error when using the Undertow version
>>>>> that is used in Wildfly 10 which would be 1.3.x.
>>>>>
>>>>> I encountered the following exception in the Undertow adapters because
>>>>> of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>>>>
>>>>> java.lang.NoSuchMethodError:
>>>>> io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>>>>         at
>>>>> org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>>>>         at
>>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>>>>         at
>>>>> org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>>>>         at
>>>>> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>>>>         at
>>>>> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>>>>         at
>>>>> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>>>>
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>>>
>>>>> When we tested it, it worked. So I need more details from you to
>>>>> reproduce this.
>>>>>
>>>>> On 21 January 2016 at 14:50, Christian Beikov <
>>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>>
>>>>>> I deploy the adapter by overlaying/copying the adapter modules into
>>>>>> my Wildfly.
>>>>>>
>>>>>> I understand that you support older Wildfly versions too, but I guess
>>>>>> you have to create a separate adapter for Wildfly 10 then.
>>>>>> You can easily see that there are incompatibilities between Undertow
>>>>>> 1.2.x and 1.3.x which will result in a failed compilation if you change the
>>>>>> Undertow version in the parent pom for testing purposes.
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>>>
>>>>>> BTW we support older versions of WildFly as well as 10, so it's not
>>>>>> as simple as upgrading the undertow version
>>>>>>
>>>>>> On 21 January 2016 at 14:43, Stian Thorgersen < <sthorger at redhat.com>
>>>>>> sthorger at redhat.com> wrote:
>>>>>>
>>>>>>> How are you deploying the adapter and what adapter are you using? We
>>>>>>> have tested the adapter with WildFly 10 (Keycloak 1.8.0.CR1 was tested on
>>>>>>> 10.0.0.CR5) and it worked fine.
>>>>>>>
>>>>>>> On 21 January 2016 at 14:30, Christian Beikov <
>>>>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly 10.0.0.CR4 but
>>>>>>>> there
>>>>>>>> are some problems with that.
>>>>>>>> You are compiling against Undertow 1.1.1.Final but Wildfly
>>>>>>>> 10.0.0.CR4
>>>>>>>> comes with 1.3.3.Final and there are some binary incompatibilities
>>>>>>>> in
>>>>>>>> io.undertow.server.Connectors of which
>>>>>>>> org.keycloak.adapters.undertow.SavedRequest is affected.
>>>>>>>> You are using io.undertow.util.ImmediatePooled instead of the
>>>>>>>> expected
>>>>>>>> type io.undertow.connector.PooledByteBuffer which leads to method
>>>>>>>> not
>>>>>>>> found exceptions.
>>>>>>>> I suggest you update the undertow version in the parent pom.xml to
>>>>>>>> make
>>>>>>>> sure everything is binary compatible if you are going to support
>>>>>>>> Wildfly
>>>>>>>> 10 as you announced.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Christian
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>>
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/e83ffef4/attachment-0001.html 

From christian.beikov at gmail.com  Thu Jan 21 10:33:15 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Thu, 21 Jan 2016 16:33:15 +0100
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <56A0F61B.2050609@redhat.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
Message-ID: <56A0FA3B.5060108@gmail.com>

Here you go: https://issues.jboss.org/browse/KEYCLOAK-2373

Regards,
Christian

Am 21.01.2016 um 16:15 schrieb Bill Burke:
> Log a jira and schedule for 1.9.  I'll either create a new adapter or 
> find a workaround that is backward compatible.
>
> On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>> What is your problem when you are actually using the adapter?
>>
>> As I said we need the adapter to compile against multiple versions, 
>> we can not maintain one per version of WildFly.
>>
>> On 21 January 2016 at 16:07, Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>     As I wrote, when you change the Undertow version in the parent
>>     pom, a build will generate a compilation error when using the
>>     Undertow version that is used in Wildfly 10 which would be 1.3.x.
>>
>>     I encountered the following exception in the Undertow adapters
>>     because of binary incompatibilities between Undertow 1.2.x and 1.3.x:
>>
>>     java.lang.NoSuchMethodError:
>>     io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>             at
>>     org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>             at
>>     org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>             at
>>     org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>             at
>>     org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>             at
>>     org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>             at
>>     org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>
>>
>>     Regards,
>>     Christian
>>
>>
>>     Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>     When we tested it, it worked. So I need more details from you to
>>>     reproduce this.
>>>
>>>     On 21 January 2016 at 14:50, Christian Beikov
>>>     <christian.beikov at gmail.com> wrote:
>>>
>>>         I deploy the adapter by overlaying/copying the adapter
>>>         modules into my Wildfly.
>>>
>>>         I understand that you support older Wildfly versions too,
>>>         but I guess you have to create a separate adapter for
>>>         Wildfly 10 then.
>>>         You can easily see that there are incompatibilities between
>>>         Undertow 1.2.x and 1.3.x which will result in a failed
>>>         compilation if you change the Undertow version in the parent
>>>         pom for testing purposes.
>>>
>>>         Regards,
>>>         Christian
>>>
>>>
>>>         Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>         BTW we support older versions of WildFly as well as 10, so
>>>>         it's not as simple as upgrading the undertow version
>>>>
>>>>         On 21 January 2016 at 14:43, Stian Thorgersen
>>>>         <sthorger at redhat.com> wrote:
>>>>
>>>>             How are you deploying the adapter and what adapter are
>>>>             you using? We have tested the adapter with WildFly 10
>>>>             (Keycloak 1.8.0.CR1 was tested on 10.0.0.CR5) and it
>>>>             worked fine.
>>>>
>>>>             On 21 January 2016 at 14:30, Christian Beikov
>>>>             <christian.beikov at gmail.com> wrote:
>>>>
>>>>                 Hello,
>>>>
>>>>                 I am trying to deploy Keycloak 1.8.0.CR1 to Wildfly
>>>>                 10.0.0.CR4 but there
>>>>                 are some problems with that.
>>>>                 You are compiling against Undertow 1.1.1.Final but
>>>>                 Wildfly 10.0.0.CR4
>>>>                 comes with 1.3.3.Final and there are some binary
>>>>                 incompatibilities in
>>>>                 io.undertow.server.Connectors of which
>>>>                 org.keycloak.adapters.undertow.SavedRequest is
>>>>                 affected.
>>>>                 You are using io.undertow.util.ImmediatePooled
>>>>                 instead of the expected
>>>>                 type io.undertow.connector.PooledByteBuffer which
>>>>                 leads to method not
>>>>                 found exceptions.
>>>>                 I suggest you update the undertow version in the
>>>>                 parent pom.xml to make
>>>>                 sure everything is binary compatible if you are
>>>>                 going to support Wildfly
>>>>                 10 as you announced.
>>>>
>>>>                 Regards,
>>>>                 Christian
>>>>                 _______________________________________________
>>>>                 keycloak-dev mailing list
>>>>                 keycloak-dev at lists.jboss.org
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Thu Jan 21 11:41:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 11:41:31 -0500
Subject: [keycloak-dev] Keycloak on Wildfly 10
In-Reply-To: <CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
References: <56A0DD8A.7010705@gmail.com>
	<CAJgngAc=FAuGcOdkrzKOtsQN4AOVE5SwtKO-dOnkaH1BprjpmA@mail.gmail.com>
	<CAJgngAfh7pvSaWawdF2JuanWsQ4+iO9a6-MPP8+=+7k2GwUfVw@mail.gmail.com>
	<56A0E23D.3040709@gmail.com>
	<CAJgngAeaWbHxWhhGZbkYGO64tiJa4ApzEtEWF4x=bL=oX17ZOg@mail.gmail.com>
	<56A0F446.8000809@gmail.com>
	<CAJgngAdVyZOi6OCay=-2LEX7fJiaz5enXcAjCyRN4iV5_bXoYg@mail.gmail.com>
	<56A0F61B.2050609@redhat.com>
	<CAJgngAdePzTzYc00AvmXvnDkFt=QnBzjshgaux-e1fZ16PBXpg@mail.gmail.com>
	<CAJgngAft1WkUV-xTg97jLgxY9=4to+wYgTJ+vcfCL0msP2-EXw@mail.gmail.com>
Message-ID: <56A10A3B.7030807@redhat.com>

The issue is that the initial request is a POST, adapter saves request 
and redirects to keycloak, authenticates, redirects back to app, then 
restores request.  The restore of the request is where the 
NoSuchMethodError happens.

On 1/21/2016 10:19 AM, Stian Thorgersen wrote:
> It depends on what the actual problem is though, because we have 
> tested it on WF10 and we didn't discover any issues
>
> On 21 January 2016 at 16:18, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     If the adapter is broken for WF10, we need to fix for 1.8 as well
>
>     On 21 January 2016 at 16:15, Bill Burke <bburke at redhat.com
>     <mailto:bburke at redhat.com>> wrote:
>
>         Log a jira and schedule for 1.9.  I'll either create a new
>         adapter or find a workaround that is backward compatible.
>
>         On 1/21/2016 10:09 AM, Stian Thorgersen wrote:
>>         What is your problem when you are actually using the adapter?
>>
>>         As I said we need the adapter to compile against multiple
>>         versions, we can not maintain one per version of WildFly.
>>
>>         On 21 January 2016 at 16:07, Christian Beikov
>>         <christian.beikov at gmail.com
>>         <mailto:christian.beikov at gmail.com>> wrote:
>>
>>             As I wrote, when you change the Undertow version in the
>>             parent pom, a build will generate a compilation error
>>             when using the Undertow version that is used in Wildfly
>>             10 which would be 1.3.x.
>>
>>             I encountered the following exception in the Undertow
>>             adapters because of binary incompatibilities between
>>             Undertow 1.2.x and 1.3.x:
>>
>>             java.lang.NoSuchMethodError:
>>             io.undertow.server.Connectors.ungetRequestBytes(Lio/undertow/server/HttpServerExchange;[Lorg/xnio/Pooled;)V
>>                     at
>>             org.keycloak.adapters.undertow.SavedRequest.tryRestoreRequest(SavedRequest.java:112)
>>                     at
>>             org.keycloak.adapters.undertow.ServletSessionTokenStore.restoreRequest(ServletSessionTokenStore.java:119)
>>                     at
>>             org.keycloak.adapters.undertow.ServletSessionTokenStore.isCached(ServletSessionTokenStore.java:67)
>>                     at
>>             org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:88)
>>                     at
>>             org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
>>                     at
>>             org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
>>
>>
>>             Regards,
>>             Christian
>>
>>
>>             Am 21.01.2016 um 16:00 schrieb Stian Thorgersen:
>>>             When we tested it, it worked. So I need more details
>>>             from you to reproduce this.
>>>
>>>             On 21 January 2016 at 14:50, Christian Beikov
>>>             <christian.beikov at gmail.com
>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>                 I deploy the adapter by overlaying/copying the
>>>                 adapter modules into my Wildfly.
>>>
>>>                 I understand that you support older Wildfly versions
>>>                 too, but I guess you have to create a separate
>>>                 adapter for Wildfly 10 then.
>>>                 You can easily see that there are incompatibilities
>>>                 between Undertow 1.2.x and 1.3.x which will result
>>>                 in a failed compilation if you change the Undertow
>>>                 version in the parent pom for testing purposes.
>>>
>>>                 Regards,
>>>                 Christian
>>>
>>>
>>>                 Am 21.01.2016 um 14:44 schrieb Stian Thorgersen:
>>>>                 BTW we support older versions of WildFly as well as
>>>>                 10, so it's not as simple as upgrading the undertow
>>>>                 version
>>>>
>>>>                 On 21 January 2016 at 14:43, Stian Thorgersen
>>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>>                 wrote:
>>>>
>>>>                     How are you deploying the adapter and what
>>>>                     adapter are you using? We have tested the
>>>>                     adapter with WildFly 10 (Keycloak 1.8.0.CR1 was
>>>>                     tested on 10.0.0.CR5) and it worked fine.
>>>>
>>>>                     On 21 January 2016 at 14:30, Christian Beikov
>>>>                     <christian.beikov at gmail.com
>>>>                     <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                         Hello,
>>>>
>>>>                         I am trying to deploy Keycloak 1.8.0.CR1 to
>>>>                         Wildfly 10.0.0.CR4 but there
>>>>                         are some problems with that.
>>>>                         You are compiling against Undertow
>>>>                         1.1.1.Final but Wildfly 10.0.0.CR4
>>>>                         comes with 1.3.3.Final and there are some
>>>>                         binary incompatibilities in
>>>>                         io.undertow.server.Connectors of which
>>>>                         org.keycloak.adapters.undertow.SavedRequest
>>>>                         is affected.
>>>>                         You are using
>>>>                         io.undertow.util.ImmediatePooled instead of
>>>>                         the expected
>>>>                         type io.undertow.connector.PooledByteBuffer
>>>>                         which leads to method not
>>>>                         found exceptions.
>>>>                         I suggest you update the undertow version
>>>>                         in the parent pom.xml to make
>>>>                         sure everything is binary compatible if you
>>>>                         are going to support Wildfly
>>>>                         10 as you announced.
>>>>
>>>>                         Regards,
>>>>                         Christian
>>>>                         _______________________________________________
>>>>                         keycloak-dev mailing list
>>>>                         keycloak-dev at lists.jboss.org
>>>>                         <mailto:keycloak-dev at lists.jboss.org>
>>>>                         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>         -- 
>         Bill Burke
>         JBoss, a division of Red Hat
>         http://bill.burkecentral.com
>
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

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

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

From bburke at redhat.com  Thu Jan 21 12:31:27 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 12:31:27 -0500
Subject: [keycloak-dev] need explanation of distribution for adapters
Message-ID: <56A115EF.3020800@redhat.com>

I need to create a separate adapter distro for Wildfly 10 as it is not 
compatible with Wildfly 8 and 9.  To do this, I need an explanation of 
the distribution directory for adapters

distribution/adapters/wildfly-adapter?  What is this for?  Wildfly 9 and 10?
distribution/feature-packs/adapter-feature-pack?  What is this for? 
Wildfly 10 only?  Wildfly 9 and 10?

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


From sthorger at redhat.com  Thu Jan 21 13:43:21 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 19:43:21 +0100
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <56A115EF.3020800@redhat.com>
References: <56A115EF.3020800@redhat.com>
Message-ID: <CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>

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

> I need to create a separate adapter distro for Wildfly 10 as it is not
> compatible with Wildfly 8 and 9.  To do this, I need an explanation of
> the distribution directory for adapters
>

Would it not be cleaner to incorporate something in the adapter that uses
different classes depending on the undertow version?


>
> distribution/adapters/wildfly-adapter?  What is this for?  Wildfly 9 and
> 10?
>

distribution/adapters/wildfly-adapter is for the latests range we support.
Currently it was supposed to be WF9 + 10. The idea was
that distribution/adapters/wildfly-adapter would always be for the latest
version of WildFly. When we have to do something that prevents backwards
compatibility we'd copy it to distribution/adapters/wf-<VERSION> and then
update distribution/adapters/wildfly-adapter to the latest WF version.


> distribution/feature-packs/adapter-feature-pack?  What is this for?
> Wildfly 10 only?  Wildfly 9 and 10?
>

distribution/feature-packs/adapter-feature-pack only has to support latest
version of WF. It's only used by WildFly Swarm guys.


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

From bburke at redhat.com  Thu Jan 21 14:11:59 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 14:11:59 -0500
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
Message-ID: <56A12D7F.2070405@redhat.com>



On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>
>
> On 21 January 2016 at 18:31, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     I need to create a separate adapter distro for Wildfly 10 as it is not
>     compatible with Wildfly 8 and 9.  To do this, I need an explanation of
>     the distribution directory for adapters
>
>
> Would it not be cleaner to incorporate something in the adapter that 
> uses different classes depending on the undertow version?

No idea what  you mean.  The undertow class/method in question has a 
different signature between 8-9 and 10.  The method call has parameters 
whose types don't exist in one or the other's versions. Basically I'll 
be creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that 
each have one class in them.  These modules are included in the 
adapter-spi module.  I just don't see any way around that.

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

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

From sthorger at redhat.com  Thu Jan 21 14:19:04 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 20:19:04 +0100
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <56A12D7F.2070405@redhat.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
Message-ID: <CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>

What I mean is:

if
(TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
{
  return new WildFly9Impl();
} else {
  return new WildFly10Impl();
}

Is that not simpler and easier for users than creating a whole new adapter
dist?

On 21 January 2016 at 20:11, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>
>
>
> On 21 January 2016 at 18:31, Bill Burke <bburke at redhat.com> wrote:
>
>> I need to create a separate adapter distro for Wildfly 10 as it is not
>> compatible with Wildfly 8 and 9.  To do this, I need an explanation of
>> the distribution directory for adapters
>>
>
> Would it not be cleaner to incorporate something in the adapter that uses
> different classes depending on the undertow version?
>
>
> No idea what  you mean.  The undertow class/method in question has a
> different signature between 8-9 and 10.  The method call has parameters
> whose types don't exist in one or the other's versions.  Basically I'll be
> creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
> have one class in them.  These modules are included in the adapter-spi
> module.  I just don't see any way around that.
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/9ea84d4e/attachment.html 

From bburke at redhat.com  Thu Jan 21 14:27:51 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 14:27:51 -0500
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
	<CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
Message-ID: <56A13137.1040703@redhat.com>

You still have to have different jars as how would Wildfly9Impl and 
Wildfly10Impl compile?  Again, the type parameters used in Wildfly9 
don't exist in 10.  The ones used in 10 don't exist in 9.

On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
> What I mean is:
>
> if 
> (TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class)) 
> {
>   return new WildFly9Impl();
> } else {
>   return new WildFly10Impl();
> }
>
> Is that not simpler and easier for users than creating a whole new 
> adapter dist?
>
> On 21 January 2016 at 20:11, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>
>>
>>     On 21 January 2016 at 18:31, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>         I need to create a separate adapter distro for Wildfly 10 as
>>         it is not
>>         compatible with Wildfly 8 and 9.  To do this, I need an
>>         explanation of
>>         the distribution directory for adapters
>>
>>
>>     Would it not be cleaner to incorporate something in the adapter
>>     that uses different classes depending on the undertow version?
>
>     No idea what  you mean.  The undertow class/method in question has
>     a different signature between 8-9 and 10.  The method call has
>     parameters whose types don't exist in one or the other's versions.
>     Basically I'll be creating a wildfly10-adapter-spi and
>     wildfly9-adapter-spi jar that each have one class in them.  These
>     modules are included in the adapter-spi module.  I just don't see
>     any way around that.
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From sthorger at redhat.com  Thu Jan 21 14:28:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 20:28:25 +0100
Subject: [keycloak-dev] Code style
Message-ID: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>

I'm wasn't planing on having a lengthy discussion about code style. It's
usually just a matter of personal preference and folks do get used to most
things.

Questions are:

* Should we have a code style?
* What IDEs are Keycloak devs using (I'm crossing my fingers everyone says
IntelliJ)
* Should we enable the checkstyle plugin?

With regards to the actual style my first thought was to base it on WildFly
code style (we do build on top of it after all). However, they do not have
one for IntelliJ, which makes it a no go IMO. Further I don't particularly
want to craft one (and try to get configs for IntelliJ match Eclipse, which
also passes the checkstyle). So do anyone have suggestions of other
projects we can borrow from?

If we're going to incorporate a code style and re-format the current code
case now is a very good time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/bdbbd51c/attachment.html 

From bburke at redhat.com  Thu Jan 21 14:31:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 14:31:42 -0500
Subject: [keycloak-dev] Code style
In-Reply-To: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
Message-ID: <56A1321E.9050509@redhat.com>

Low priority IMO.

On 1/21/2016 2:28 PM, Stian Thorgersen wrote:
> I'm wasn't planing on having a lengthy discussion about code style. 
> It's usually just a matter of personal preference and folks do get 
> used to most things.
>
> Questions are:
>
> * Should we have a code style?
> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone 
> says IntelliJ)
> * Should we enable the checkstyle plugin?
>
> With regards to the actual style my first thought was to base it on 
> WildFly code style (we do build on top of it after all). However, they 
> do not have one for IntelliJ, which makes it a no go IMO. Further I 
> don't particularly want to craft one (and try to get configs for 
> IntelliJ match Eclipse, which also passes the checkstyle). So do 
> anyone have suggestions of other projects we can borrow from?
>
> If we're going to incorporate a code style and re-format the current 
> code case now is a very good time.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From sthorger at redhat.com  Thu Jan 21 14:37:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 20:37:48 +0100
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <56A13137.1040703@redhat.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
	<CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
	<56A13137.1040703@redhat.com>
Message-ID: <CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>

True, didn't consider that. We could do it with Infinispan because the
methods where actually there, just didn't work on the old version.

I can't see any other option then. Sucks to have to maintain all this
different versions of the adapters.

On 21 January 2016 at 20:27, Bill Burke <bburke at redhat.com> wrote:

> You still have to have different jars as how would Wildfly9Impl and
> Wildfly10Impl compile?  Again, the type parameters used in Wildfly9 don't
> exist in 10.  The ones used in 10 don't exist in 9.
>
>
> On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
>
> What I mean is:
>
> if
> (TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
> {
>   return new WildFly9Impl();
> } else {
>   return new WildFly10Impl();
> }
>
> Is that not simpler and easier for users than creating a whole new adapter
> dist?
>
> On 21 January 2016 at 20:11, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>
>>
>>
>> On 21 January 2016 at 18:31, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>> I need to create a separate adapter distro for Wildfly 10 as it is not
>>> compatible with Wildfly 8 and 9.  To do this, I need an explanation of
>>> the distribution directory for adapters
>>>
>>
>> Would it not be cleaner to incorporate something in the adapter that uses
>> different classes depending on the undertow version?
>>
>>
>> No idea what  you mean.  The undertow class/method in question has a
>> different signature between 8-9 and 10.  The method call has parameters
>> whose types don't exist in one or the other's versions.  Basically I'll be
>> creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
>> have one class in them.  These modules are included in the adapter-spi
>> module.  I just don't see any way around that.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/24b54aa8/attachment.html 

From sthorger at redhat.com  Thu Jan 21 14:45:01 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 21 Jan 2016 20:45:01 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
Message-ID: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>

Do we need to have seconds at all for token timeouts? Removing seconds from
token would make it simpler, but also make sure no one sets timeouts that
are to short (see https://issues.jboss.org/browse/KEYCLOAK-1341)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160121/54a61f05/attachment.html 

From psilva at redhat.com  Thu Jan 21 15:15:55 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 21 Jan 2016 15:15:55 -0500 (EST)
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
	<CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
	<56A13137.1040703@redhat.com>
	<CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>
Message-ID: <1834662806.13472799.1453407355062.JavaMail.zimbra@redhat.com>

I'm working an adapter based on WildFly Elytron's SPI. In theory, you would be able to implement Elytron's SPI once and have it supported in different WildFly versions.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, January 21, 2016 5:37:48 PM
Subject: Re: [keycloak-dev] need explanation of distribution for adapters

True, didn't consider that. We could do it with Infinispan because the methods where actually there, just didn't work on the old version. 

I can't see any other option then. Sucks to have to maintain all this different versions of the adapters. 

On 21 January 2016 at 20:27, Bill Burke < bburke at redhat.com > wrote: 



You still have to have different jars as how would Wildfly9Impl and Wildfly10Impl compile? Again, the type parameters used in Wildfly9 don't exist in 10. The ones used in 10 don't exist in 9. 


On 1/21/2016 2:19 PM, Stian Thorgersen wrote: 



What I mean is: 

if (TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class)) { 
return new WildFly9Impl(); 
} else { 
return new WildFly10Impl(); 
} 

Is that not simpler and easier for users than creating a whole new adapter dist? 

On 21 January 2016 at 20:11, Bill Burke < bburke at redhat.com > wrote: 





On 1/21/2016 1:43 PM, Stian Thorgersen wrote: 





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


I need to create a separate adapter distro for Wildfly 10 as it is not 
compatible with Wildfly 8 and 9. To do this, I need an explanation of 
the distribution directory for adapters 

Would it not be cleaner to incorporate something in the adapter that uses different classes depending on the undertow version? 

No idea what you mean. The undertow class/method in question has a different signature between 8-9 and 10. The method call has parameters whose types don't exist in one or the other's versions. Basically I'll be creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each have one class in them. These modules are included in the adapter-spi module. I just don't see any way around that. 

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


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


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

From ssilvert at redhat.com  Thu Jan 21 15:25:12 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 21 Jan 2016 15:25:12 -0500
Subject: [keycloak-dev] Code style
In-Reply-To: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
Message-ID: <56A13EA8.3050605@redhat.com>

On 1/21/2016 2:28 PM, Stian Thorgersen wrote:
> I'm wasn't planing on having a lengthy discussion about code style. 
> It's usually just a matter of personal preference and folks do get 
> used to most things.
>
> Questions are:
>
> * Should we have a code style?
I've seen too many teams waste time arguing about code style.  I think 
that our team is mature enough that we wouldn't let that happen, but 
having strict enforcement never seems to provide much payoff, imo.

I think a middle ground is to just publish some general guidelines of  
basic standards we can all agree with.  Then if someone strays too far, 
just ask them to fix it.
> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone 
> says IntelliJ)
NetBeans
> * Should we enable the checkstyle plugin?
Something that checks the license and possibly authorship/copyright is 
probably important.  Beyond that, I'm not sure how useful checkstyle 
would be.

In NetBeans, every time I create a new class I use a template that lets 
me choose the license.  Surely other IDE's have a way to do this?
>
> With regards to the actual style my first thought was to base it on 
> WildFly code style (we do build on top of it after all). However, they 
> do not have one for IntelliJ, which makes it a no go IMO. Further I 
> don't particularly want to craft one (and try to get configs for 
> IntelliJ match Eclipse, which also passes the checkstyle). So do 
> anyone have suggestions of other projects we can borrow from?
>
> If we're going to incorporate a code style and re-format the current 
> code case now is a very good time.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From ppalaga at redhat.com  Thu Jan 21 16:08:21 2016
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 21 Jan 2016 22:08:21 +0100
Subject: [keycloak-dev] Code style
In-Reply-To: <56A13EA8.3050605@redhat.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
	<56A13EA8.3050605@redhat.com>
Message-ID: <56A148C5.7090602@redhat.com>

Hi *,

I can serve with some experience gathered in Hawkular:

General:
* Rules that are not enforced by the build process are often ignored
* Having such rules for license headers and code style saves time
   during reviews
* Newcomers are told what to do automatically
* Having such rules reduces the amount of formatting changes that may
   be seen as pollution of the history

The implementation in Hawkular:
* Checkstyle ruleset for Java files [1], taken from WildFly, with minor 
modifications (120 char max line length instead of 100, explicit import 
order, ...) [2]
* Checkstyle rules for all text files (xml, json, ...) for banning tabs 
as indentation characters and for banning trailing whitespace [3]
* Newly, 2-space indentation for XML files checked by xml-maven-plugin [4]
* com.mycila:license-maven-plugin for license headers [5]
* Our UI guys have their own tslint rules


IDEs:
* Maven rules define the standard, IDE configs are derived
* IDE configs [6] consitent with the Maven rules are possible and mostly 
work well.
* We have them only for Eclipse and IJ



[1] 
https://github.com/hawkular/hawkular-build-tools/blob/master/build-tools/src/main/resources/hawkular-checkstyle/checkstyle.xml#L39
[2] https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L844
[3] 
https://github.com/hawkular/hawkular-build-tools/blob/master/build-tools/src/main/resources/hawkular-checkstyle/checkstyle.xml#L29-L37
[4] 
https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L1020
[5] https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L844
[6] https://github.com/hawkular/hawkular-build-tools/tree/master/ide-configs

Best,

Peter

On 2016-01-21 21:25, Stan Silvert wrote:
> On 1/21/2016 2:28 PM, Stian Thorgersen wrote:
>> I'm wasn't planing on having a lengthy discussion about code style.
>> It's usually just a matter of personal preference and folks do get
>> used to most things.
>>
>> Questions are:
>>
>> * Should we have a code style?
> I've seen too many teams waste time arguing about code style.  I think
> that our team is mature enough that we wouldn't let that happen, but
> having strict enforcement never seems to provide much payoff, imo.
>
> I think a middle ground is to just publish some general guidelines of
> basic standards we can all agree with.  Then if someone strays too far,
> just ask them to fix it.
>> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone
>> says IntelliJ)
> NetBeans
>> * Should we enable the checkstyle plugin?
> Something that checks the license and possibly authorship/copyright is
> probably important.  Beyond that, I'm not sure how useful checkstyle
> would be.
>
> In NetBeans, every time I create a new class I use a template that lets
> me choose the license.  Surely other IDE's have a way to do this?
>>
>> With regards to the actual style my first thought was to base it on
>> WildFly code style (we do build on top of it after all). However, they
>> do not have one for IntelliJ, which makes it a no go IMO. Further I
>> don't particularly want to craft one (and try to get configs for
>> IntelliJ match Eclipse, which also passes the checkstyle). So do
>> anyone have suggestions of other projects we can borrow from?
>>
>> If we're going to incorporate a code style and re-format the current
>> code case now is a very good time.
>>
>>
>> _______________________________________________
>> 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 Jan 21 17:17:21 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 17:17:21 -0500
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
	<CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
	<56A13137.1040703@redhat.com>
	<CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>
Message-ID: <56A158F1.7050803@redhat.com>

Of course I find a better solution after whining and complaing...Its 
still a hack, but, it is portable.

On 1/21/2016 2:37 PM, Stian Thorgersen wrote:
> True, didn't consider that. We could do it with Infinispan because the 
> methods where actually there, just didn't work on the old version.
>
> I can't see any other option then. Sucks to have to maintain all this 
> different versions of the adapters.
>
> On 21 January 2016 at 20:27, Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     You still have to have different jars as how would Wildfly9Impl
>     and Wildfly10Impl compile?  Again, the type parameters used in
>     Wildfly9 don't exist in 10.  The ones used in 10 don't exist in 9.
>
>
>     On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
>>     What I mean is:
>>
>>     if
>>     (TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
>>     {
>>     return new WildFly9Impl();
>>     } else {
>>     return new WildFly10Impl();
>>     }
>>
>>     Is that not simpler and easier for users than creating a whole
>>     new adapter dist?
>>
>>     On 21 January 2016 at 20:11, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>         On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>>
>>>
>>>         On 21 January 2016 at 18:31, Bill Burke <bburke at redhat.com
>>>         <mailto:bburke at redhat.com>> wrote:
>>>
>>>             I need to create a separate adapter distro for Wildfly
>>>             10 as it is not
>>>             compatible with Wildfly 8 and 9.  To do this, I need an
>>>             explanation of
>>>             the distribution directory for adapters
>>>
>>>
>>>         Would it not be cleaner to incorporate something in the
>>>         adapter that uses different classes depending on the
>>>         undertow version?
>>
>>         No idea what  you mean.  The undertow class/method in
>>         question has a different signature between 8-9 and 10. The
>>         method call has parameters whose types don't exist in one or
>>         the other's versions.  Basically I'll be creating a
>>         wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
>>         have one class in them.  These modules are included in the
>>         adapter-spi module.  I just don't see any way around that.
>>
>>         -- 
>>         Bill Burke
>>         JBoss, a division of Red Hat
>>         http://bill.burkecentral.com
>>
>>
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>

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

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

From bburke at redhat.com  Thu Jan 21 17:40:45 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 17:40:45 -0500
Subject: [keycloak-dev] logout broken for wildfly10
Message-ID: <56A15E6D.8020307@redhat.com>

UGH! Hopefully a backward compatible fix coming

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


From bburke at redhat.com  Thu Jan 21 21:32:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 21:32:25 -0500
Subject: [keycloak-dev] logout broken for wildfly10
In-Reply-To: <56A15E6D.8020307@redhat.com>
References: <56A15E6D.8020307@redhat.com>
Message-ID: <56A194B9.9070202@redhat.com>

fixed in 1.8 and master.  Wildly10 has a new switch that defaults to 
true that changes session id after initial login.  That of course screws 
up our session management.

On 1/21/2016 5:40 PM, Bill Burke wrote:
> UGH! Hopefully a backward compatible fix coming
>

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


From parul.com at gmail.com  Thu Jan 21 22:48:27 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 22 Jan 2016 09:18:27 +0530
Subject: [keycloak-dev] Does keycloak SP SAML client adapter supports
 keystore credential in encrypt/decrypt way?
Message-ID: <CAFj68vWWB59P-D0TNLUEcpQ0mf6O5ig6eX+W+1+uAD+Th2h3Dg@mail.gmail.com>

Currently, keycloak saml SP, keystore information is read from
keycloak_saml.xml file. but keystore and private key password is written in
plain text which may lead to security vulnerability.

does keycloak supports reading encrypt/decrypt password for this in
keycloak-saml.xml file instead of plain text.

Thanks
Arulkumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/1deaacad/attachment.html 

From bburke at redhat.com  Thu Jan 21 23:24:14 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 21 Jan 2016 23:24:14 -0500
Subject: [keycloak-dev] Does keycloak SP SAML client adapter supports
 keystore credential in encrypt/decrypt way?
In-Reply-To: <CAFj68vWWB59P-D0TNLUEcpQ0mf6O5ig6eX+W+1+uAD+Th2h3Dg@mail.gmail.com>
References: <CAFj68vWWB59P-D0TNLUEcpQ0mf6O5ig6eX+W+1+uAD+Th2h3Dg@mail.gmail.com>
Message-ID: <56A1AEEE.8050303@redhat.com>

Not at this time.

On 1/21/2016 10:48 PM, Arulkumar Ponnusamy wrote:
> Currently, keycloak saml SP, keystore information is read from 
> keycloak_saml.xml file. but keystore and private key password is 
> written in plain text which may lead to security vulnerability.
>
> does keycloak supports reading encrypt/decrypt password for this in 
> keycloak-saml.xml file instead of plain text.
>
> Thanks
> Arulkumar
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From parul.com at gmail.com  Thu Jan 21 23:47:09 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 22 Jan 2016 10:17:09 +0530
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP side?
Message-ID: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>

keycloak 1.8 CR release notes state, it supports SAML ECP profile. want to
know, is it on IDP side or it supports both IDP and SP side?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/a2c68fe4/attachment.html 

From sthorger at redhat.com  Fri Jan 22 03:04:51 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Jan 2016 09:04:51 +0100
Subject: [keycloak-dev] need explanation of distribution for adapters
In-Reply-To: <56A158F1.7050803@redhat.com>
References: <56A115EF.3020800@redhat.com>
	<CAJgngAezsw8kmfPVN5dwkp-a0oAH1s8zGnGtMFLhsrdd4JNeXQ@mail.gmail.com>
	<56A12D7F.2070405@redhat.com>
	<CAJgngAebEDj2iJKqnGRO44uuz0fOH+12-9dBYCFxzS9Tcxu3Tg@mail.gmail.com>
	<56A13137.1040703@redhat.com>
	<CAJgngAfOnxfzW+3waWGc=jtxLeC9g0Kns+r60voN49pcsasnng@mail.gmail.com>
	<56A158F1.7050803@redhat.com>
Message-ID: <CAJgngAeDhKXOoKUepHPY8MWrhRb-uLJaXn5RDx441XX4odd02A@mail.gmail.com>

It's always good to whine and complain a bit :)

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

> Of course I find a better solution after whining and complaing...Its still
> a hack, but, it is portable.
>
>
> On 1/21/2016 2:37 PM, Stian Thorgersen wrote:
>
> True, didn't consider that. We could do it with Infinispan because the
> methods where actually there, just didn't work on the old version.
>
> I can't see any other option then. Sucks to have to maintain all this
> different versions of the adapters.
>
> On 21 January 2016 at 20:27, Bill Burke <bburke at redhat.com> wrote:
>
>> You still have to have different jars as how would Wildfly9Impl and
>> Wildfly10Impl compile?  Again, the type parameters used in Wildfly9 don't
>> exist in 10.  The ones used in 10 don't exist in 9.
>>
>>
>> On 1/21/2016 2:19 PM, Stian Thorgersen wrote:
>>
>> What I mean is:
>>
>> if
>> (TheProblemClass.class.getMethod("..").getParameterTypes()[0].equals(SomeObject.class))
>> {
>>   return new WildFly9Impl();
>> } else {
>>   return new WildFly10Impl();
>> }
>>
>> Is that not simpler and easier for users than creating a whole new
>> adapter dist?
>>
>> On 21 January 2016 at 20:11, Bill Burke < <bburke at redhat.com>
>> bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 1/21/2016 1:43 PM, Stian Thorgersen wrote:
>>>
>>>
>>>
>>> On 21 January 2016 at 18:31, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> I need to create a separate adapter distro for Wildfly 10 as it is not
>>>> compatible with Wildfly 8 and 9.  To do this, I need an explanation of
>>>> the distribution directory for adapters
>>>>
>>>
>>> Would it not be cleaner to incorporate something in the adapter that
>>> uses different classes depending on the undertow version?
>>>
>>>
>>> No idea what  you mean.  The undertow class/method in question has a
>>> different signature between 8-9 and 10.  The method call has parameters
>>> whose types don't exist in one or the other's versions.  Basically I'll be
>>> creating a wildfly10-adapter-spi and wildfly9-adapter-spi jar that each
>>> have one class in them.  These modules are included in the adapter-spi
>>> module.  I just don't see any way around that.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>>
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/8d9f2525/attachment.html 

From sthorger at redhat.com  Fri Jan 22 03:05:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Jan 2016 09:05:48 +0100
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP
	side?
In-Reply-To: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
References: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
Message-ID: <CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>

Only IdP side

On 22 January 2016 at 05:47, Arulkumar Ponnusamy <parul.com at gmail.com>
wrote:

> keycloak 1.8 CR release notes state, it supports SAML ECP profile. want to
> know, is it on IDP side or it supports both IDP and SP side?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/909a4319/attachment.html 

From parul.com at gmail.com  Fri Jan 22 03:34:37 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 22 Jan 2016 14:04:37 +0530
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP
	side?
In-Reply-To: <CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>
References: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
	<CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>
Message-ID: <CAFj68vUuHsOxbAd9QxmHvhUUBtXyB=f+vnK=kYX5kNt0=pLUng@mail.gmail.com>

do you have any plan to implement it on SP side too on 1.9?

On Fri, Jan 22, 2016 at 1:35 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Only IdP side
>
> On 22 January 2016 at 05:47, Arulkumar Ponnusamy <parul.com at gmail.com>
> wrote:
>
>> keycloak 1.8 CR release notes state, it supports SAML ECP profile. want
>> to know, is it on IDP side or it supports both IDP and SP side?
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/6e00dc0c/attachment.html 

From sthorger at redhat.com  Fri Jan 22 03:52:42 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Jan 2016 09:52:42 +0100
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP
	side?
In-Reply-To: <CAFj68vUuHsOxbAd9QxmHvhUUBtXyB=f+vnK=kYX5kNt0=pLUng@mail.gmail.com>
References: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
	<CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>
	<CAFj68vUuHsOxbAd9QxmHvhUUBtXyB=f+vnK=kYX5kNt0=pLUng@mail.gmail.com>
Message-ID: <CAJgngAfC_Cmrkc52GjMrRFuwZNGPtho=XLmJs9+TpGofT1V1Uw@mail.gmail.com>

No, at the moment we don't have any plans to support it at all. You should
be able to find other SP libraries to use though.

On 22 January 2016 at 09:34, Arulkumar Ponnusamy <parul.com at gmail.com>
wrote:

> do you have any plan to implement it on SP side too on 1.9?
>
>
> On Fri, Jan 22, 2016 at 1:35 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Only IdP side
>>
>> On 22 January 2016 at 05:47, Arulkumar Ponnusamy <parul.com at gmail.com>
>> wrote:
>>
>>> keycloak 1.8 CR release notes state, it supports SAML ECP profile. want
>>> to know, is it on IDP side or it supports both IDP and SP side?
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/aae162f9/attachment-0001.html 

From thomas.darimont at googlemail.com  Fri Jan 22 06:10:51 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Fri, 22 Jan 2016 12:10:51 +0100
Subject: [keycloak-dev] Event listener configuration
Message-ID: <CAK-7U1jBPn9ZTUARTc12yP5J9Z=rzacrJPxYEORg3J=WQs0CAg@mail.gmail.com>

It would be great if one could configure concrete event-listener via the
admin-console.
In my case I have an EventListenerProvider that asynchronously forwards
a set of configured event types to a REST endpoint via HTTP POST which has
configurable options like:


- forwardingEndpoint - Address of the rest endpoint
- authHeader - Authroization Basic: ... / Bearer: ...
- includeEventPattern - Regex for matching included event type names
- excludeEventPattern - Regex for exluding event type names (that were
included before)
- postAsync - use background thread for sending (true/false)
- retryStrategy - (max retries, backoff etc.)
- postTimeout - max time for the post request to complete
- queuePath - file backed FIFO queue

Currently I have to configure this listener via keycloak-server.json.

What do you think - shall I create a JIRA for this (allow for event
listener configuration)?

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

From christian.beikov at gmail.com  Fri Jan 22 06:48:04 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Fri, 22 Jan 2016 12:48:04 +0100
Subject: [keycloak-dev] Application Clustering problems
Message-ID: <56A216F4.3010700@gmail.com>

Hello,

I am running some tests with my application cluster being secured by a 
single keycloak server instance and I encountered problems with the adapter.

My application cluster contains 2 nodes and is load balanced by nginx. 
For testing purposes, I enabled round robin load balancing which is 
probably the "cause" for my issues.

When I access a secured page, I get redirected to keycloak and 
everything is fine. When I then login, and keycloak redirects me back to 
the application, I get to a different application cluster node because 
of round robin. On that node, apparently the initial information of the 
client session is not available and I get redirected to keycloak login 
page again. Then keycloak redirects me back to the application, this 
time to the original node, and says that access is forbidden.

I suppose the web session caches are not in sync but I just used the 
default cache containers as they are defined in standalone-ha.xml of my 
Wildlfy 10 CR4. Clustering with jgroups works, as I use other 
distributed caches too which work just fine.

We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4

Regards,
Christian

From sthorger at redhat.com  Fri Jan 22 07:02:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Jan 2016 13:02:11 +0100
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.8.0.CR2 Released
In-Reply-To: <CAMNcrz62VBqchdxRg2tXekWTkTMtQbFjuZQW9XHqTFMPZdtmUA@mail.gmail.com>
References: <CAJgngAfeRtXCUQ9_gohvBm_8AxMHhgje1LT7nejCCqLF8Rej5Q@mail.gmail.com>
	<CAMNcrz62VBqchdxRg2tXekWTkTMtQbFjuZQW9XHqTFMPZdtmUA@mail.gmail.com>
Message-ID: <CAJgngAfteH9KMTau4VLBQ4uAj4OGD8na1DyFgE0tczwaO_5Mpw@mail.gmail.com>

Should be fixed in master now. Apparently I'd temporarily forgotten how to
write SQL statements

On 22 January 2016 at 12:53, Thorsten <thorsten315 at gmx.de> wrote:

> Just ran into an issue starting up a fresh install 1.8.0.CR2 on a new
> mysql db. Got this exception at first startup:
>
> 11:45:47,034 INFO  [org.keycloak.services.resources.KeycloakApplication]
> (ServerService Thread Pool -- 49) Load config from
> /opt/keycloak-1.8.0.CR2/standalone/configuration/keycloak-server.json
> 11:45:50,881 INFO
>  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider]
> (ServerService Thread Pool -- 49) Initializing database schema
> 11:45:55,265 WARN
>  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider]
> (ServerService Thread Pool -- 49) Database does not support drop with
> cascade
> 11:45:55,285 WARN
>  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider]
> (ServerService Thread Pool -- 49) Database does not support drop with
> cascade
> 11:46:00,630 ERROR
> [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider]
> (ServerService Thread Pool -- 49) Change Set
> META-INF/jpa-changelog-1.8.0.xml::1.8.0-2::keycloak failed.  Error: You
> have an error in your SQL syntax; check the manual that corresponds to your
> MySQL server version for the right syntax to use near ''HmacSHA1'' at line
> 1 [Failed SQL: UPDATE keycloak.CREDENTIAL SET ALGORITHM = 'pbkdf2' WHERE
> TYPE in ('password-history', 'password') AND ALGORITHM is 'HmacSHA1']:
> liquibase.exception.DatabaseException: You have an error in your SQL
> syntax; check the manual that corresponds to your MySQL server version for
> the right syntax to use near ''HmacSHA1'' at line 1 [Failed SQL: UPDATE
> keycloak.CREDENTIAL SET ALGORITHM = 'pbkdf2' WHERE TYPE in
> ('password-history', 'password') AND ALGORITHM is 'HmacSHA1']
>         at
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
>         at
> liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
>         at
> liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
>         at
> liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
>         at
> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
>         at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
>         at
> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
>         at
> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
>         at liquibase.Liquibase.update(Liquibase.java:210)
>         at liquibase.Liquibase.update(Liquibase.java:190)
>         at liquibase.Liquibase.update(Liquibase.java:186)
>         at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34)
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16)
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
>         at
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
>         at
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:137)
>         at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:80)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>         at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>         at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>         at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>         at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>         at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>         at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>         at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>         at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You
> have an error in your SQL syntax; check the manual that corresponds to your
> MySQL server version for the right syntax to use near ''HmacSHA1'' at line 1
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>         at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
>         at com.mysql.jdbc.Util.getInstance(Util.java:387)
>         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:939)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3878)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)
>         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2478)
>         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2625)
>         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2547)
>         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2505)
>         at
> com.mysql.jdbc.StatementImpl.executeInternal(StatementImpl.java:840)
>         at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:740)
>         at
> org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
>         at
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
>         ... 47 more
>
> 11:46:00,652 ERROR [org.keycloak.services.resources.KeycloakApplication]
> (ServerService Thread Pool -- 49) Failed to migrate datamodel:
> java.lang.RuntimeException: Failed to update database
>         at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:87)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.lazyInit(DefaultJpaConnectionProviderFactory.java:153)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:42)
>         at
> org.keycloak.connections.jpa.DefaultJpaConnectionProviderFactory.create(DefaultJpaConnectionProviderFactory.java:30)
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:34)
>         at
> org.keycloak.models.jpa.JpaRealmProviderFactory.create(JpaRealmProviderFactory.java:16)
>         at
> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:103)
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getDelegate(DefaultCacheRealmProvider.java:61)
>         at
> org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getMigrationModel(DefaultCacheRealmProvider.java:43)
>         at
> org.keycloak.migration.MigrationModelManager.migrate(MigrationModelManager.java:21)
>         at
> org.keycloak.services.resources.KeycloakApplication.migrateModel(KeycloakApplication.java:137)
>         at
> org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:80)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>         at
> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150)
>         at
> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299)
>         at
> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240)
>         at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113)
>         at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
>         at
> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
>         at
> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
>         at
> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231)
>         at
> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132)
>         at
> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
>         at
> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
>         at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
>         at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: liquibase.exception.MigrationFailedException: Migration failed
> for change set META-INF/jpa-changelog-1.8.0.xml::1.8.0-2::keycloak:
>      Reason: liquibase.exception.DatabaseException: You have an error in
> your SQL syntax; check the manual that corresponds to your MySQL server
> version for the right syntax to use near ''HmacSHA1'' at line 1 [Failed
> SQL: UPDATE keycloak.CREDENTIAL SET ALGORITHM = 'pbkdf2' WHERE TYPE in
> ('password-history', 'password') AND ALGORITHM is 'HmacSHA1']
>         at liquibase.changelog.ChangeSet.execute(ChangeSet.java:584)
>         at
> liquibase.changelog.visitor.UpdateVisitor.visit(UpdateVisitor.java:51)
>         at
> liquibase.changelog.ChangeLogIterator.run(ChangeLogIterator.java:73)
>         at liquibase.Liquibase.update(Liquibase.java:210)
>         at liquibase.Liquibase.update(Liquibase.java:190)
>         at liquibase.Liquibase.update(Liquibase.java:186)
>         at
> org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider.update(LiquibaseJpaUpdaterProvider.java:84)
>         ... 36 more
> Caused by: liquibase.exception.DatabaseException: You have an error in
> your SQL syntax; check the manual that corresponds to your MySQL server
> version for the right syntax to use near ''HmacSHA1'' at line 1 [Failed
> SQL: UPDATE keycloak.CREDENTIAL SET ALGORITHM = 'pbkdf2' WHERE TYPE in
> ('password-history', 'password') AND ALGORITHM is 'HmacSHA1']
>         at
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:316)
>         at
> liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:55)
>         at
> liquibase.executor.jvm.JdbcExecutor.execute(JdbcExecutor.java:122)
>         at
> liquibase.database.AbstractJdbcDatabase.execute(AbstractJdbcDatabase.java:1247)
>         at
> liquibase.database.AbstractJdbcDatabase.executeStatements(AbstractJdbcDatabase.java:1230)
>         at liquibase.changelog.ChangeSet.execute(ChangeSet.java:548)
>         ... 42 more
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: You
> have an error in your SQL syntax; check the manual that corresponds to your
> MySQL server version for the right syntax to use near ''HmacSHA1'' at line 1
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
>         at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
>         at com.mysql.jdbc.Util.getInstance(Util.java:387)
>         at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:939)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3878)
>         at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)
>         at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2478)
>         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2625)
>         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2547)
>         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2505)
>         at
> com.mysql.jdbc.StatementImpl.executeInternal(StatementImpl.java:840)
>         at com.mysql.jdbc.StatementImpl.execute(StatementImpl.java:740)
>         at
> org.jboss.jca.adapters.jdbc.WrappedStatement.execute(WrappedStatement.java:198)
>         at
> liquibase.executor.jvm.JdbcExecutor$ExecuteStatementCallback.doInStatement(JdbcExecutor.java:314)
>         ... 47 more
>
> 11:46:00,774 INFO  [org.hibernate.jpa.internal.util.LogHelper]
> (ServerService Thread Pool -- 49) HHH000204: Processing PersistenceUnitInfo
> [
>         name: keycloak-default
>         ...]
>
> Seems that other tables are being created just fine.
>
> Thanks, Thorsten
>
>
> 2016-01-21 12:00 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
>
>> We had a few issues reported against 1.8.0.CR1, so we're doing another CR
>> release with the fixes. If everything is OK, 1.8.0.Final will be released
>> next week.
>>
>> There was also a feature that sneaked in. We now support sign-on with
>> Microsoft Live.
>>
>> For the full list of issues resolved check out JIRA
>> <https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.8.0.CR2> and
>> to download the release go to the Keycloak homepage
>> <http://keycloak.org/downloads>.
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/1b59087f/attachment-0001.html 

From sthorger at redhat.com  Fri Jan 22 08:19:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 22 Jan 2016 14:19:24 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.CR3 Released
Message-ID: <CAJgngAfvNov2uUzUuE9nHJVr59OK=Kr-TzZuwnHa3U7DavUV4w@mail.gmail.com>

A few more fixes, hopefully this will be the last CR and we can release
Final next week.

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

From lkrzyzan at redhat.com  Fri Jan 22 09:40:28 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Fri, 22 Jan 2016 15:40:28 +0100
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <56A0E9AA.6080707@redhat.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
	<56A0E9AA.6080707@redhat.com>
Message-ID: <CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>

Just read the discussion so let me clarify few things.

Redirects
I?m fine with one redirect after POST. But it needs to be one redirect not 3. I was complaining about 3 additional redirects after hitting ?LOGIN? button.
In apps that I?m author (e.g. planet.jboss.org) I exactly use that pattern - after HTTP POST server returns 302 redirect to another page which helps with a) refresh button problem, b) browser back button problem.

Back button:
From UX perspective the back button must work. Everybody use it. On Mac/iPad users are used to use gesture. I use it everywhere.
Personally when I come to some site which is trying to force me to use back button on page instead of back button in browser I always feels like using website written 5 years ago.

Other comments inline.

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> Yeah, I did that in 1.6....But jboss.org team didn't like it for performance reasons.
> 
> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>> There's s pattern to handle the back button during flows. It's that a post should never render a view but redirect (HTTP get) to the failure or success view. 
>> 
>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get <http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke < <mailto:bburke at redhat.com>bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>> 
>> 
>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>> One additional thought. Maybe we could add a field to autheticators to say if they support back, cancel or nothing. Then the flow would allow going back                 if previous supports back. It would allow cancel if all supports it, or nothing is one says nothing
>>> 
>>> On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.
>>> 
>>> Secondly, the back button should not navigate backwards in the flow. Also, the refresh button should just redisplay the page as it does now (ignoring the post). A couple ideas to improve things though:
>>> 
>>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate, max-age=0". This should force a reload of the page when the user clicks the back button
>> 
>> Really?  That's cool then, this will basically "disable" the back button :)  I'll try it out.

It doesn?t disable the back button. The browser just don?t use internal browser cache when the URL is visited either by refresh button or back button.

>> 
>> 
>>> 2) Can we add a back link to some steps in the flow?
>>> 3) Can we add a cancel link to some steps in the flow?
>> 
>> You can reset the flow to the beginning, but can't go back one step.

From UX perspective back button on webpage needs to behave exactly same as back button in browser.

Cancel is very confusing for me. For example on ?Forgot password? is cancel button - what is purpose of it? what happen when I click on it? Where I would be redirected? I personally removed those cancel buttons from our theme because it?s not clear why they?re there.

>> 
>> 
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Fri Jan 22 09:47:57 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Jan 2016 09:47:57 -0500
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
	<56A0E9AA.6080707@redhat.com>
	<CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>
Message-ID: <56A2411D.3080907@redhat.com>

We just can't support back button at this time and not until sometime in 
2.0.  I'm hoping we can at least "disable" it by turning off the cache.  
The way it will work is back button causes an HTTP request with old URL 
and parameters, Keycloak will just see its old and redirect to the 
current step in the flow.

On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
> Just read the discussion so let me clarify few things.
>
> Redirects
> I?m fine with one redirect after POST. But it needs to be 
> *one* redirect not 3. I was complaining about 3 additional redirects 
> after hitting ?LOGIN? button.
> In apps that I?m author (e.g. planet.jboss.org 
> <http://planet.jboss.org>) I exactly use that pattern - after HTTP 
> POST server returns 302 redirect to another page which helps with a) 
> refresh button problem, b) browser back button problem.
>
> Back button:
> From UX perspective the back button must work. Everybody use it. On 
> Mac/iPad users are used to use gesture. I use it everywhere.
> Personally when I come to some site which is trying to force me to use 
> back button on page instead of back button in browser I always feels 
> like using website written 5 years ago.
>
> Other comments inline.
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org <http://jboss.org> Development Team
>
>> On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke at redhat.com 
>> <mailto:bburke at redhat.com>> wrote:
>>
>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org> team 
>> didn't like it for performance reasons.
>>
>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>> There's s pattern to handle the back button during flows. It's that 
>>> a post should never render a view but redirect (HTTP get) to the 
>>> failure or success view.
>>>
>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com> wrote:
>>>
>>>
>>>
>>>     On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>
>>>>     One additional thought. Maybe we could add a field to
>>>>     autheticators to say if they support back, cancel or nothing.
>>>>     Then the flow would allow going back if previous supports back.
>>>>     It would allow cancel if all supports it, or nothing is one
>>>>     says nothing
>>>>
>>>>     On 20 Jan 2016 19:48, "Stian Thorgersen" <sthorger at redhat.com
>>>>     <mailto:sthorger at redhat.com>> wrote:
>>>>
>>>>         Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we
>>>>         can fix it for 1.9.
>>>>
>>>>         Secondly, the back button should not navigate backwards in
>>>>         the flow. Also, the refresh button should just redisplay
>>>>         the page as it does now (ignoring the post). A couple ideas
>>>>         to improve things though:
>>>>
>>>>         1) Set cache-control to "Cache-Control: no-store,
>>>>         must-revalidate, max-age=0". This should force a reload of
>>>>         the page when the user clicks the back button
>>>>
>>>
>>>     Really?  That's cool then, this will basically "disable" the
>>>     back button :)  I'll try it out.
>>>
>
> It doesn?t disable the back button. The browser just don?t use 
> internal browser cache when the URL is visited either by refresh 
> button or back button.
>
>>>
>>>
>>>>         2) Can we add a back link to some steps in the flow?
>>>>         3) Can we add a cancel link to some steps in the flow?
>>>>
>>>
>>>     You can reset the flow to the beginning, but can't go back one step.
>>>
>
> From UX perspective back button on webpage needs to behave exactly 
> same as back button in browser.
>
> Cancel is very confusing for me. For example on ?Forgot password? is 
> cancel button - what is purpose of it? what happen when I click on it? 
> Where I would be redirected? I personally removed those cancel buttons 
> from our theme because it?s not clear why they?re there.
>
>>>
>>>
>>>     -- 
>>>     Bill Burke
>>>     JBoss, a division of Red Hat
>>>     http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>>
>>>     _______________________________________________
>>>     keycloak-dev mailing list
>>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

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

From lkrzyzan at redhat.com  Fri Jan 22 10:19:08 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Fri, 22 Jan 2016 16:19:08 +0100
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <56A2411D.3080907@redhat.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
	<56A0E9AA.6080707@redhat.com>
	<CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>
	<56A2411D.3080907@redhat.com>
Message-ID: <2B16DB1D-E686-4897-AE68-AFF235F06C73@redhat.com>

I understand that frameworks are usually not ?back/refresh button? friendly.
I was facing this problem in planet.jboss.org with JSF as well and had to fix it with some workaround.

So if you can keep this in mind in 2.0 or later please do it. You simply cannot force people to not use browser back button.

Thanks,

L.

Libor Krzy?anek
jboss.org Development Team

> On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> We just can't support back button at this time and not until sometime in 2.0.  I'm hoping we can at least "disable" it by turning off the cache.  The way it will work is back button causes an HTTP request with old URL and parameters, Keycloak will just see its old and redirect to the current step in the flow.
> 
> On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
>> Just read the discussion so let me clarify few things.
>> 
>> Redirects
>> I?m fine with one redirect after POST. But it needs to be one redirect not 3. I was complaining about 3 additional redirects after hitting ?LOGIN? button.
>> In apps that I?m author (e.g. planet.jboss.org <http://planet.jboss.org/>) I exactly use that pattern - after HTTP POST server returns 302 redirect to another page which helps with a) refresh button problem, b) browser back button problem.
>> 
>> Back button:
>> From UX perspective the back button must work. Everybody use it. On Mac/iPad users are used to use gesture. I use it everywhere.
>> Personally when I come to some site which is trying to force me to use back button on page instead of back button in browser I always feels like using website written 5 years ago.
>> 
>> Other comments inline.
>> 
>> Thanks,
>> 
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>> 
>>> On Jan 21, 2016, at 3:22 PM, Bill Burke < <mailto:bburke at redhat.com>bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>> 
>>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team didn't like it for performance reasons.
>>> 
>>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>>> There's s pattern to handle the back button during flows. It's that a post should never render a view but redirect (HTTP get) to the failure or success view. 
>>>> 
>>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get <http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
>>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>> 
>>>> 
>>>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>> One additional thought. Maybe we could add a field to autheticators to say if they support back, cancel or nothing. Then the flow would allow going back if previous supports back. It would allow cancel if all supports it, or nothing is one says nothing
>>>>> 
>>>>> On 20 Jan 2016 19:48, "Stian Thorgersen" < <mailto:sthorger at redhat.com>sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.
>>>>> 
>>>>> Secondly, the back button should not navigate backwards in the flow. Also, the refresh button should just redisplay the page as it does now (ignoring the post). A couple ideas to improve things though:
>>>>> 
>>>>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate, max-age=0". This should force a reload of the page when the user clicks the back button
>>>> 
>>>> Really?  That's cool then, this will basically "disable" the back button :)  I'll try it out.
>> 
>> It doesn?t disable the back button. The browser just don?t use internal browser cache when the URL is visited either by refresh button or back button.
>> 
>>>> 
>>>> 
>>>>> 2) Can we add a back link to some steps in the flow?
>>>>> 3) Can we add a cancel link to some steps in the flow?
>>>> 
>>>> You can reset the flow to the beginning, but can't go back one step.
>> 
>> From UX perspective back button on webpage needs to behave exactly same as back button in browser.
>> 
>> Cancel is very confusing for me. For example on ?Forgot password? is cancel button - what is purpose of it? what happen when I click on it? Where I would be redirected? I personally removed those cancel buttons from our theme because it?s not clear why they?re there.
>> 
>>>> 
>>>> 
>>>> -- 
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com <http://bill.burkecentral.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160122/0de6e7a1/attachment.html 

From jdennis at redhat.com  Fri Jan 22 10:22:02 2016
From: jdennis at redhat.com (John Dennis)
Date: Fri, 22 Jan 2016 10:22:02 -0500
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP
	side?
In-Reply-To: <CAJgngAfC_Cmrkc52GjMrRFuwZNGPtho=XLmJs9+TpGofT1V1Uw@mail.gmail.com>
References: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
	<CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>
	<CAFj68vUuHsOxbAd9QxmHvhUUBtXyB=f+vnK=kYX5kNt0=pLUng@mail.gmail.com>
	<CAJgngAfC_Cmrkc52GjMrRFuwZNGPtho=XLmJs9+TpGofT1V1Uw@mail.gmail.com>
Message-ID: <56A2491A.6070200@redhat.com>

On 01/22/2016 03:52 AM, Stian Thorgersen wrote:
> No, at the moment we don't have any plans to support it at all. You
> should be able to find other SP libraries to use though.

If your SP is running inside Apache you can use mod_auth_mellon. We just 
finished successfully testing ECP between a mod_auth_mellon SP and 
Keycloak 1.8.0.CR1 (caveat, 1.8.0.CR1 had 1 minor issue with the media 
type which was promptly fixed by the KC team, 1.8.0 final should be fine).

The truth is an IdP such as KC doesn't need to do much to support ECP, 
most of the work for ECP is in the ECP client and the SP. So in addition 
to a working SP you'll need to make sure your ECP client plays well with 
others.

> On 22 January 2016 at 09:34, Arulkumar Ponnusamy <parul.com at gmail.com
> <mailto:parul.com at gmail.com>> wrote:
>
>     do you have any plan to implement it on SP side too on 1.9?
>
>
>     On Fri, Jan 22, 2016 at 1:35 PM, Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         Only IdP side
>
>         On 22 January 2016 at 05:47, Arulkumar Ponnusamy
>         <parul.com at gmail.com <mailto:parul.com at gmail.com>> wrote:
>
>             keycloak 1.8 CR release notes state, it supports SAML ECP
>             profile. want to know, is it on IDP side or it supports both
>             IDP and SP side?


-- 
John

From psilva at redhat.com  Fri Jan 22 10:48:14 2016
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 22 Jan 2016 10:48:14 -0500 (EST)
Subject: [keycloak-dev] does keycloak 1.8 supports ECP profile on
	SP	side?
In-Reply-To: <56A2491A.6070200@redhat.com>
References: <CAFj68vXoHWh+i8QL02z6A4YOVTYgCxJ1=Y1zBvUqienfoLngzw@mail.gmail.com>
	<CAJgngAfAJcu47zjuS7Nm6vWmqbZEHwgF2N6xuAWkkYHgHA7xTw@mail.gmail.com>
	<CAFj68vUuHsOxbAd9QxmHvhUUBtXyB=f+vnK=kYX5kNt0=pLUng@mail.gmail.com>
	<CAJgngAfC_Cmrkc52GjMrRFuwZNGPtho=XLmJs9+TpGofT1V1Uw@mail.gmail.com>
	<56A2491A.6070200@redhat.com>
Message-ID: <65670251.13876288.1453477694146.JavaMail.zimbra@redhat.com>



Pedro Igor Craveiro e Silva
Agree with John. However, we do have some basic ECP profile on SP side, where you can obtain AuthnRequests using PAOS binding.

If you send a request to an SP using both Accept and PAOS headers accordingly with the specs, you should be able to obtain a AuthnRequest.

Regards.
Pedro Igor

----- Original Message -----
From: "John Dennis" <jdennis at redhat.com>
To: stian at redhat.com, "Arulkumar Ponnusamy" <parul.com at gmail.com>
Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
Sent: Friday, January 22, 2016 1:22:02 PM
Subject: Re: [keycloak-dev] does keycloak 1.8 supports ECP profile on SP	side?

On 01/22/2016 03:52 AM, Stian Thorgersen wrote:
> No, at the moment we don't have any plans to support it at all. You
> should be able to find other SP libraries to use though.

If your SP is running inside Apache you can use mod_auth_mellon. We just 
finished successfully testing ECP between a mod_auth_mellon SP and 
Keycloak 1.8.0.CR1 (caveat, 1.8.0.CR1 had 1 minor issue with the media 
type which was promptly fixed by the KC team, 1.8.0 final should be fine).

The truth is an IdP such as KC doesn't need to do much to support ECP, 
most of the work for ECP is in the ECP client and the SP. So in addition 
to a working SP you'll need to make sure your ECP client plays well with 
others.

> On 22 January 2016 at 09:34, Arulkumar Ponnusamy <parul.com at gmail.com
> <mailto:parul.com at gmail.com>> wrote:
>
>     do you have any plan to implement it on SP side too on 1.9?
>
>
>     On Fri, Jan 22, 2016 at 1:35 PM, Stian Thorgersen
>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>
>         Only IdP side
>
>         On 22 January 2016 at 05:47, Arulkumar Ponnusamy
>         <parul.com at gmail.com <mailto:parul.com at gmail.com>> wrote:
>
>             keycloak 1.8 CR release notes state, it supports SAML ECP
>             profile. want to know, is it on IDP side or it supports both
>             IDP and SP side?


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

From ssilvert at redhat.com  Fri Jan 22 12:36:15 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 22 Jan 2016 12:36:15 -0500
Subject: [keycloak-dev] Debug/Trace logging
Message-ID: <56A2688F.1050207@redhat.com>

 From yesterday's discussion, it was clear that as a group, we consider 
debug/trace logging to be fundamentally different from other logging.  
The loggers I've been concerned with will be logged through a limited 
number of keycloak loggers using broad categories such as User, Realm, 
Config, etc.

But for debug/trace logging, we want the category to be based upon the 
class it was logged from.  That way, you can turn logging on for a 
particular class, package, or sub-package to do your trace.

There is no good way to do both kinds of logging using the same logger 
instance.  Therefore, I propose that debug/trace logging be done the 
same way we've always done it.  Declare a debug/trace logger in your 
class and use that.  Other logging will be done through the keycloak logger.

So, to do both kinds of logging in the same class, you declare two loggers:

private static final KeycloakLogger kcLogger = KeycloakLogger.ROOT_LOGGER;
private static final Logger debugLogger = Logger.getLogger(MyClass.class);
.....
kcLogger.CONFIG.localizedMessage("My localized message"); // logged to 
"keycloak-config" category
.....
debugLogger.debug("My debug message");  // logged to 
"org.keycloak.mypackage.MyClass" category

Comments?


From srossillo at smartling.com  Fri Jan 22 16:26:41 2016
From: srossillo at smartling.com (Scott Rossillo)
Date: Fri, 22 Jan 2016 16:26:41 -0500
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <2B16DB1D-E686-4897-AE68-AFF235F06C73@redhat.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
	<56A0E9AA.6080707@redhat.com>
	<CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>
	<56A2411D.3080907@redhat.com>
	<2B16DB1D-E686-4897-AE68-AFF235F06C73@redhat.com>
Message-ID: <2C14D730-2F43-43E6-A057-84FD8E200425@smartling.com>

> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team didn't like it for performance reasons.

The jboss.org team seems misguided here to think this approach creates a performance issue. Many high traffic and large scale sites use this approach to solve back button issues. 

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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Jan 22, 2016, at 10:19 AM, Libor Krzyzanek <lkrzyzan at redhat.com> wrote:
> 
> I understand that frameworks are usually not ?back/refresh button? friendly.
> I was facing this problem in planet.jboss.org <http://planet.jboss.org/> with JSF as well and had to fix it with some workaround.
> 
> So if you can keep this in mind in 2.0 or later please do it. You simply cannot force people to not use browser back button.
> 
> Thanks,
> 
> L.
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
>> On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>> 
>> We just can't support back button at this time and not until sometime in 2.0.  I'm hoping we can at least "disable" it by turning off the cache.  The way it will work is back button causes an HTTP request with old URL and parameters, Keycloak will just see its old and redirect to the current step in the flow.
>> 
>> On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
>>> Just read the discussion so let me clarify few things.
>>> 
>>> Redirects
>>> I?m fine with one redirect after POST. But it needs to be one redirect not 3. I was complaining about 3 additional redirects after hitting ?LOGIN? button.
>>> In apps that I?m author (e.g. planet.jboss.org <http://planet.jboss.org/>) I exactly use that pattern - after HTTP POST server returns 302 redirect to another page which helps with a) refresh button problem, b) browser back button problem.
>>> 
>>> Back button:
>>> From UX perspective the back button must work. Everybody use it. On Mac/iPad users are used to use gesture. I use it everywhere.
>>> Personally when I come to some site which is trying to force me to use back button on page instead of back button in browser I always feels like using website written 5 years ago.
>>> 
>>> Other comments inline.
>>> 
>>> Thanks,
>>> 
>>> Libor Krzy?anek
>>> jboss.org <http://jboss.org/> Development Team
>>> 
>>>> On Jan 21, 2016, at 3:22 PM, Bill Burke < <mailto:bburke at redhat.com>bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>> 
>>>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team didn't like it for performance reasons.
>>>> 
>>>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>>>> There's s pattern to handle the back button during flows. It's that a post should never render a view but redirect (HTTP get) to the failure or success view. 
>>>>> 
>>>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get <http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get>
>>>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>>> 
>>>>> 
>>>>> On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>>> One additional thought. Maybe we could add a field to autheticators to say if they support back, cancel or nothing. Then the flow would allow going back if previous supports back. It would allow cancel if all supports it, or nothing is one says nothing
>>>>>> 
>>>>>> On 20 Jan 2016 19:48, "Stian Thorgersen" < <mailto:sthorger at redhat.com>sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>>>> Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we can fix it for 1.9.
>>>>>> 
>>>>>> Secondly, the back button should not navigate backwards in the flow. Also, the refresh button should just redisplay the page as it does now (ignoring the post). A couple ideas to improve things though:
>>>>>> 
>>>>>> 1) Set cache-control to "Cache-Control: no-store, must-revalidate, max-age=0". This should force a reload of the page when the user clicks the back button
>>>>> 
>>>>> Really?  That's cool then, this will basically "disable" the back button :)  I'll try it out.
>>> 
>>> It doesn?t disable the back button. The browser just don?t use internal browser cache when the URL is visited either by refresh button or back button.
>>> 
>>>>> 
>>>>> 
>>>>>> 2) Can we add a back link to some steps in the flow?
>>>>>> 3) Can we add a cancel link to some steps in the flow?
>>>>> 
>>>>> You can reset the flow to the beginning, but can't go back one step.
>>> 
>>> From UX perspective back button on webpage needs to behave exactly same as back button in browser.
>>> 
>>> Cancel is very confusing for me. For example on ?Forgot password? is cancel button - what is purpose of it? what happen when I click on it? Where I would be redirected? I personally removed those cancel buttons from our theme because it?s not clear why they?re there.
>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>> -- 
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com <http://bill.burkecentral.com/>_______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> 
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com <http://bill.burkecentral.com/>

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

From bburke at redhat.com  Fri Jan 22 17:17:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Jan 2016 17:17:28 -0500
Subject: [keycloak-dev] browser backbutton
In-Reply-To: <2C14D730-2F43-43E6-A057-84FD8E200425@smartling.com>
References: <569FAB06.2030105@redhat.com>
	<CAJgngAcA063HMhH-AOuq5G-pFXG_E0xPv2c5LG6N71R_AX-LLA@mail.gmail.com>
	<CAJgngAfaE01HxyS5O+Nv+AtWAMcJWzD02edTwQ0jXPK+RF0a4Q@mail.gmail.com>
	<56A024AC.8080101@redhat.com>
	<CALAqdu8E7_jboPF6KdDj5b0wM5gkraWWANS2YvJ4KPjwqxRi_g@mail.gmail.com>
	<56A0E9AA.6080707@redhat.com>
	<CFC9ED2D-7C92-4EE2-946F-15979D10E92F@redhat.com>
	<56A2411D.3080907@redhat.com>
	<2B16DB1D-E686-4897-AE68-AFF235F06C73@redhat.com>
	<2C14D730-2F43-43E6-A057-84FD8E200425@smartling.com>
Message-ID: <56A2AA78.9060307@redhat.com>

Talked to them.  They just didn't like that it was possible for 3 
redirects in a row.

On 1/22/2016 4:26 PM, Scott Rossillo wrote:
> > Yeah, I did that in 1.6....But jboss.org <http://jboss.org> team 
> didn't like it for performance reasons.
>
> The jboss.org <http://jboss.org> team seems misguided here to think 
> this approach creates a performance issue. Many high traffic and large 
> scale sites use this approach to solve back button issues.
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
> Latest News + Events <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> Powered by Sigstr <http://www.sigstr.com/>
>
>> On Jan 22, 2016, at 10:19 AM, Libor Krzyzanek <lkrzyzan at redhat.com 
>> <mailto:lkrzyzan at redhat.com>> wrote:
>>
>> I understand that frameworks are usually not ?back/refresh button? 
>> friendly.
>> I was facing this problem in planet.jboss.org 
>> <http://planet.jboss.org/> with JSF as well and had to fix it with 
>> some workaround.
>>
>> So if you can keep this in mind in 2.0 or later please do it. You 
>> simply cannot force people to not use browser back button.
>>
>> Thanks,
>>
>> L.
>>
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>>
>>> On Jan 22, 2016, at 3:47 PM, Bill Burke <bburke at redhat.com 
>>> <mailto:bburke at redhat.com>> wrote:
>>>
>>> We just can't support back button at this time and not until 
>>> sometime in 2.0.  I'm hoping we can at least "disable" it by turning 
>>> off the cache. The way it will work is back button causes an HTTP 
>>> request with old URL and parameters, Keycloak will just see its old 
>>> and redirect to the current step in the flow.
>>>
>>> On 1/22/2016 9:40 AM, Libor Krzyzanek wrote:
>>>> Just read the discussion so let me clarify few things.
>>>>
>>>> Redirects
>>>> I?m fine with one redirect after POST. But it needs to be 
>>>> *one* redirect not 3. I was complaining about 3 additional 
>>>> redirects after hitting ?LOGIN? button.
>>>> In apps that I?m author (e.g. planet.jboss.org 
>>>> <http://planet.jboss.org/>) I exactly use that pattern - after HTTP 
>>>> POST server returns 302 redirect to another page which helps with 
>>>> a) refresh button problem, b) browser back button problem.
>>>>
>>>> Back button:
>>>> From UX perspective the back button must work. Everybody use it. On 
>>>> Mac/iPad users are used to use gesture. I use it everywhere.
>>>> Personally when I come to some site which is trying to force me to 
>>>> use back button on page instead of back button in browser I always 
>>>> feels like using website written 5 years ago.
>>>>
>>>> Other comments inline.
>>>>
>>>> Thanks,
>>>>
>>>> Libor Krzy?anek
>>>> jboss.org <http://jboss.org/> Development Team
>>>>
>>>>> On Jan 21, 2016, at 3:22 PM, Bill Burke <bburke at redhat.com> wrote:
>>>>>
>>>>> Yeah, I did that in 1.6....But jboss.org <http://jboss.org/> team 
>>>>> didn't like it for performance reasons.
>>>>>
>>>>> On 1/20/2016 8:50 PM, Scott Rossillo wrote:
>>>>>> There's s pattern to handle the back button during flows. It's 
>>>>>> that a post should never render a view but redirect (HTTP get) to 
>>>>>> the failure or success view.
>>>>>>
>>>>>> http://www.codeproject.com/Tips/433399/PRG-Pattern-Post-Redirect-Get
>>>>>> On Wed, Jan 20, 2016 at 7:22 PM Bill Burke <bburke at redhat.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On 1/20/2016 3:49 PM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>>     One additional thought. Maybe we could add a field to
>>>>>>>     autheticators to say if they support back, cancel or
>>>>>>>     nothing. Then the flow would allow going back if previous
>>>>>>>     supports back. It would allow cancel if all supports it, or
>>>>>>>     nothing is one says nothing
>>>>>>>
>>>>>>>     On 20 Jan 2016 19:48, "Stian Thorgersen"
>>>>>>>     <sthorger at redhat.com> wrote:
>>>>>>>
>>>>>>>         Firstly, let's drop KEYCLOAK-2325 from 1.8 and see if we
>>>>>>>         can fix it for 1.9.
>>>>>>>
>>>>>>>         Secondly, the back button should not navigate backwards
>>>>>>>         in the flow. Also, the refresh button should just
>>>>>>>         redisplay the page as it does now (ignoring the post). A
>>>>>>>         couple ideas to improve things though:
>>>>>>>
>>>>>>>         1) Set cache-control to "Cache-Control: no-store,
>>>>>>>         must-revalidate, max-age=0". This should force a reload
>>>>>>>         of the page when the user clicks the back button
>>>>>>>
>>>>>>
>>>>>>     Really? That's cool then, this will basically "disable" the
>>>>>>     back button :)  I'll try it out.
>>>>>>
>>>>
>>>> It doesn?t disable the back button. The browser just don?t use 
>>>> internal browser cache when the URL is visited either by refresh 
>>>> button or back button.
>>>>
>>>>>>
>>>>>>
>>>>>>>         2) Can we add a back link to some steps in the flow?
>>>>>>>         3) Can we add a cancel link to some steps in the flow?
>>>>>>>
>>>>>>
>>>>>>     You can reset the flow to the beginning, but can't go back
>>>>>>     one step.
>>>>>>
>>>>
>>>> From UX perspective back button on webpage needs to behave exactly 
>>>> same as back button in browser.
>>>>
>>>> Cancel is very confusing for me. For example on ?Forgot password? 
>>>> is cancel button - what is purpose of it? what happen when I click 
>>>> on it? Where I would be redirected? I personally removed those 
>>>> cancel buttons from our theme because it?s not clear why they?re there.
>>>>
>>>>>>
>>>>>>
>>>>>>     -- 
>>>>>>     Bill Burke
>>>>>>     JBoss, a division of Red Hat
>>>>>>     http://bill.burkecentral.com <http://bill.burkecentral.com/>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     keycloak-dev mailing list
>>>>>>     keycloak-dev at lists.jboss.org
>>>>>>     <mailto:keycloak-dev at lists.jboss.org>
>>>>>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>> -- 
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>

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

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

From bburke at redhat.com  Fri Jan 22 18:33:26 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Jan 2016 18:33:26 -0500
Subject: [keycloak-dev] travis seems to go offline on weekend
Message-ID: <56A2BC46.40609@redhat.com>

So repository connection for travis build seems to go offline Friday 
nights and into the weekend.  Build failed with a timeout. This happened 
to me last weekend/friday too.

FYI

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


From bburke at redhat.com  Fri Jan 22 18:43:28 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 22 Jan 2016 18:43:28 -0500
Subject: [keycloak-dev] flow redirects are back
Message-ID: <56A2BEA0.1060109@redhat.com>

If a required or auth action was successful, the flow redirects to the 
appropriate path (just like in 1.6).  This time though, there should not 
be multiple redirects at once.  I'll work on backbutton soon.

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


From parul.com at gmail.com  Sun Jan 24 23:13:13 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Mon, 25 Jan 2016 09:43:13 +0530
Subject: [keycloak-dev] on Keycloak SAML Client Adapter Reference Guide
Message-ID: <CAFj68vXs5_jqwHn_wDHPEGc0KFynV9pOeV0hkDbPLxh_UjLjTQ@mail.gmail.com>

Keycloak SAML Client Adapter Reference Guide section 2.7 wrongly saying
"IDP SingleSignOnService sub element" instead of "IDP SignleLogoutService"
sub element

is it possible to correct this in 1.8 Release .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/10bf395f/attachment.html 

From sthorger at redhat.com  Mon Jan 25 02:56:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 08:56:41 +0100
Subject: [keycloak-dev] Event listener configuration
In-Reply-To: <CAK-7U1jBPn9ZTUARTc12yP5J9Z=rzacrJPxYEORg3J=WQs0CAg@mail.gmail.com>
References: <CAK-7U1jBPn9ZTUARTc12yP5J9Z=rzacrJPxYEORg3J=WQs0CAg@mail.gmail.com>
Message-ID: <CAJgngAds7Api=P0mUec24tfc8BPRGWcaFTVtrCnJm8OAKeMBWw@mail.gmail.com>

Sounds like a nice to have, so feel free to create a jira

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

> It would be great if one could configure concrete event-listener via the
> admin-console.
> In my case I have an EventListenerProvider that asynchronously forwards
> a set of configured event types to a REST endpoint via HTTP POST which has
> configurable options like:
>
>
> - forwardingEndpoint - Address of the rest endpoint
> - authHeader - Authroization Basic: ... / Bearer: ...
> - includeEventPattern - Regex for matching included event type names
> - excludeEventPattern - Regex for exluding event type names (that were
> included before)
> - postAsync - use background thread for sending (true/false)
> - retryStrategy - (max retries, backoff etc.)
> - postTimeout - max time for the post request to complete
> - queuePath - file backed FIFO queue
>
> Currently I have to configure this listener via keycloak-server.json.
>
> What do you think - shall I create a JIRA for this (allow for event
> listener configuration)?
>
> Cheers,
> Thomas
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/16c9a455/attachment.html 

From sthorger at redhat.com  Mon Jan 25 02:58:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 08:58:34 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A216F4.3010700@gmail.com>
References: <56A216F4.3010700@gmail.com>
Message-ID: <CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>

By default the adapters will require sticky sessions, please refer to
http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
for more information

On 22 January 2016 at 12:48, Christian Beikov <christian.beikov at gmail.com>
wrote:

> Hello,
>
> I am running some tests with my application cluster being secured by a
> single keycloak server instance and I encountered problems with the
> adapter.
>
> My application cluster contains 2 nodes and is load balanced by nginx.
> For testing purposes, I enabled round robin load balancing which is
> probably the "cause" for my issues.
>
> When I access a secured page, I get redirected to keycloak and
> everything is fine. When I then login, and keycloak redirects me back to
> the application, I get to a different application cluster node because
> of round robin. On that node, apparently the initial information of the
> client session is not available and I get redirected to keycloak login
> page again. Then keycloak redirects me back to the application, this
> time to the original node, and says that access is forbidden.
>
> I suppose the web session caches are not in sync but I just used the
> default cache containers as they are defined in standalone-ha.xml of my
> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
> distributed caches too which work just fine.
>
> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>
> Regards,
> Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/29e53db4/attachment.html 

From mposolda at redhat.com  Mon Jan 25 03:54:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 09:54:40 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
Message-ID: <56A5E2D0.40902@redhat.com>

Not sure about that. IMO seconds are good to have more fine grained 
timeout values. For example in some deployment the "Access token 
timeout" value 1 minute might be too short, but 2 minutes are too long, 
so they prefer to use 90 seconds as compromise.

Also seconds are good for development. For example, I am sometimes using 
seconds for testing (IE. setting timeout to 10 seconds to quickly 
enforce refresh etc)

Skip seconds to address KEYCLOAK-1341 looks to me like workaround rather 
than real solution. The question is if we should address KEYCLOAK-1341 
at all? There are probably many possibilities how can admin breaks the 
login to admin console itself or break the keycloak entirely. Few 
examples, which come to my mind (there are likely much more):
- Delete or disable security-admin-console client
- delete or disable himself
- remove roles from himself
- remove scopes from security-admin-console client
- configure authentication flow in some way that it's not possible login 
anymore
- Timeouts

I don't think that we should try to prevent all of these situations. I 
didn't see any real support questions related to this. And for example 
in linux if you do "rm -rf /home" the system is broken as well. Isn't 
this kind of similar? IMO admins should do backup of database, so they 
can revert if they accidentally mis-configure things.

Marek

On 21/01/16 20:45, Stian Thorgersen wrote:
> Do we need to have seconds at all for token timeouts? Removing seconds 
> from token would make it simpler, but also make sure no one sets 
> timeouts that are to short (see 
> https://issues.jboss.org/browse/KEYCLOAK-1341)
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Jan 25 04:05:46 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 10:05:46 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <56A5E2D0.40902@redhat.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
	<56A5E2D0.40902@redhat.com>
Message-ID: <CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>

On 25 January 2016 at 09:54, Marek Posolda <mposolda at redhat.com> wrote:

> Not sure about that. IMO seconds are good to have more fine grained
> timeout values. For example in some deployment the "Access token timeout"
> value 1 minute might be too short, but 2 minutes are too long, so they
> prefer to use 90 seconds as compromise.
>

I disagree, I really don't see anyone needing to set timeouts in second
granularity,


>
> Also seconds are good for development. For example, I am sometimes using
> seconds for testing (IE. setting timeout to 10 seconds to quickly enforce
> refresh etc)
>
> Skip seconds to address KEYCLOAK-1341 looks to me like workaround rather
> than real solution. The question is if we should address KEYCLOAK-1341 at
> all? There are probably many possibilities how can admin breaks the login
> to admin console itself or break the keycloak entirely. Few examples, which
> come to my mind (there are likely much more):
> - Delete or disable security-admin-console client
>

We're going to prevent users from deleting internal clients and roles, so
that won't be a problem anymore


> - delete or disable himself
>

Can be recovered by adding new user using add-user script


> - remove roles from himself
>

Same as above


> - remove scopes from security-admin-console client
>

We haven't covered that one


> - configure authentication flow in some way that it's not possible login
> anymore
>

Not covered either


> - Timeouts
>
> I don't think that we should try to prevent all of these situations. I
> didn't see any real support questions related to this. And for example in
> linux if you do "rm -rf /home" the system is broken as well. Isn't this
> kind of similar? IMO admins should do backup of database, so they can
> revert if they accidentally mis-configure things.
>

What you are saying makes no sense whatsoever. It's like saying validation
in user interfaces is a waste of time.

Validation in user interfaces are there to help people, and to prevent
people doing things that will screw things up. This is an really good
example of where lack of validation on inputs allows users to set stupid
values. 1 second timeouts never makes any sense, so why should we let users
set it. It could also be a mistake as someone wanted to set 1 minute, but
selected second by mistake.

Arguing against preventing people from screwing things up for themselves by
coming with another example where they can screw things up is just not good
argumentation. We should do as much as we can, and in this case it's a very
simple fix that could prevent a rather annoying issue.


>
> Marek
>
> On 21/01/16 20:45, Stian Thorgersen wrote:
>
> Do we need to have seconds at all for token timeouts? Removing seconds
> from token would make it simpler, but also make sure no one sets timeouts
> that are to short (see  <https://issues.jboss.org/browse/KEYCLOAK-1341>
> https://issues.jboss.org/browse/KEYCLOAK-1341)
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/963cc54c/attachment-0001.html 

From mposolda at redhat.com  Mon Jan 25 05:01:30 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 11:01:30 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
	<56A5E2D0.40902@redhat.com>
	<CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>
Message-ID: <56A5F27A.5040805@redhat.com>

On 25/01/16 10:05, Stian Thorgersen wrote:
>
>
> On 25 January 2016 at 09:54, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Not sure about that. IMO seconds are good to have more fine
>     grained timeout values. For example in some deployment the "Access
>     token timeout" value 1 minute might be too short, but 2 minutes
>     are too long, so they prefer to use 90 seconds as compromise.
>
>
> I disagree, I really don't see anyone needing to set timeouts in 
> second granularity,
Hmm... Don't you think the 90 seconds example is not realistic for any 
deployment?

Another thing is "Client login timeout" . This is limited just by 
network performance and doesn't require any action from user. Usually it 
will take around 1-2 seconds to complete. So shouldn't we decrease the 
current default value 1 minute to something lower (10 seconds?). Having 
bigger value theoretically decreases login security as attacker have 
more time to exchange stolen code for token.
>
>
>     Also seconds are good for development. For example, I am sometimes
>     using seconds for testing (IE. setting timeout to 10 seconds to
>     quickly enforce refresh etc)
>
>     Skip seconds to address KEYCLOAK-1341 looks to me like workaround
>     rather than real solution. The question is if we should address
>     KEYCLOAK-1341 at all? There are probably many possibilities how
>     can admin breaks the login to admin console itself or break the
>     keycloak entirely. Few examples, which come to my mind (there are
>     likely much more):
>     - Delete or disable security-admin-console client
>
>
> We're going to prevent users from deleting internal clients and roles, 
> so that won't be a problem anymore
>
>     - delete or disable himself
>
>
> Can be recovered by adding new user using add-user script
>
>     - remove roles from himself
>
>
> Same as above
>
>     - remove scopes from security-admin-console client
>
>
> We haven't covered that one
>
>     - configure authentication flow in some way that it's not possible
>     login anymore
>
>
> Not covered either
>
>     - Timeouts
>
>     I don't think that we should try to prevent all of these
>     situations. I didn't see any real support questions related to
>     this. And for example in linux if you do "rm -rf /home" the system
>     is broken as well. Isn't this kind of similar? IMO admins should
>     do backup of database, so they can revert if they accidentally
>     mis-configure things.
>
>
> What you are saying makes no sense whatsoever. It's like saying 
> validation in user interfaces is a waste of time.
I am not saying validation is lack of time. Agree we should have them. 
But IMO validations are not always sufficient and I don't think that we 
can handle every "bad" situation. So would recommend people to do backup 
of database to prevent mis-configure things.

Also not sure if it's always good approach to restrict functionality 
from admin console just to prevent people from break things. Likely yes 
in some cases (builtin objects), however in some other it may be better 
to use cofirmation warnings (Do you really want to set timeout just to 
10 seconds? Do you really want to re-configure browser authentication 
flow of master realm? etc). I suppose admins are technical people and 
they know what they're doing.
>
> Validation in user interfaces are there to help people, and to prevent 
> people doing things that will screw things up. This is an really good 
> example of where lack of validation on inputs allows users to set 
> stupid values. 1 second timeouts never makes any sense, so why should 
> we let users set it. It could also be a mistake as someone wanted to 
> set 1 minute, but selected second by mistake.
How about use the confirmation dialog if any timeout is set to smaller 
value than 10 seconds as I mentioned above?

There are likely much more things, which we should handle regarding 
timeouts. And likely disallow some of them. For example:
- If someone sets "Session Idle timeout" smaller than "Access token 
timeout", the refreshes will be broken. This config should be probably 
restricted
- Same for "Session max lifespan" . Maybe we should prevent people from 
set "Session max lifespan" to be shorter than any other timeout at all 
(despite "Offline session idle" )

Marek
>
> Arguing against preventing people from screwing things up for 
> themselves by coming with another example where they can screw things 
> up is just not good argumentation. We should do as much as we can, and 
> in this case it's a very simple fix that could prevent a rather 
> annoying issue.
>
>
>     Marek
>
>     On 21/01/16 20:45, Stian Thorgersen wrote:
>>     Do we need to have seconds at all for token timeouts? Removing
>>     seconds from token would make it simpler, but also make sure no
>>     one sets timeouts that are to short (see
>>     https://issues.jboss.org/browse/KEYCLOAK-1341)
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From mposolda at redhat.com  Mon Jan 25 05:33:04 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 11:33:04 +0100
Subject: [keycloak-dev] Code style
In-Reply-To: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
Message-ID: <56A5F9E0.50206@redhat.com>

On 21/01/16 20:28, Stian Thorgersen wrote:
> I'm wasn't planing on having a lengthy discussion about code style. 
> It's usually just a matter of personal preference and folks do get 
> used to most things.
>
> Questions are:
>
> * Should we have a code style?
> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone 
> says IntelliJ)
> * Should we enable the checkstyle plugin?
>
> With regards to the actual style my first thought was to base it on 
> WildFly code style (we do build on top of it after all). However, they 
> do not have one for IntelliJ, which makes it a no go IMO. Further I 
> don't particularly want to craft one (and try to get configs for 
> IntelliJ match Eclipse, which also passes the checkstyle). So do 
> anyone have suggestions of other projects we can borrow from?
I am using the Intellij and have the codestyle file imported from 
liveoak. Among other things, it has "import package.*" prevented 
(related discussion in other thread).

We had netbeans, eclipse and intellij there and I hope there were in 
sync: 
https://github.com/liveoak-io/liveoak/tree/master/support/ide-configs .

Seeing there was also checkstyle as well: 
https://github.com/liveoak-io/liveoak/blob/master/support/build-config/src/main/resources/liveoak-checkstyle/checkstyle.xml

Marek
>
> If we're going to incorporate a code style and re-format the current 
> code case now is a very good time.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Mon Jan 25 06:01:07 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 12:01:07 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <56A5F27A.5040805@redhat.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
	<56A5E2D0.40902@redhat.com>
	<CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>
	<56A5F27A.5040805@redhat.com>
Message-ID: <CAJgngAdw5-jPTwBnWOMpPP=sk_NPx3RCA+1Mxd8kWq4JjSbyww@mail.gmail.com>

On 25 January 2016 at 11:01, Marek Posolda <mposolda at redhat.com> wrote:

> On 25/01/16 10:05, Stian Thorgersen wrote:
>
>
>
> On 25 January 2016 at 09:54, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Not sure about that. IMO seconds are good to have more fine grained
>> timeout values. For example in some deployment the "Access token timeout"
>> value 1 minute might be too short, but 2 minutes are too long, so they
>> prefer to use 90 seconds as compromise.
>>
>
> I disagree, I really don't see anyone needing to set timeouts in second
> granularity,
>
> Hmm... Don't you think the 90 seconds example is not realistic for any
> deployment?
>

To much options and flexibility is usually what makes people hate
something. I'm pretty sure the choice between 1 or 2 min is more than
sufficient.


>
> Another thing is "Client login timeout" . This is limited just by network
> performance and doesn't require any action from user. Usually it will take
> around 1-2 seconds to complete. So shouldn't we decrease the current
> default value 1 minute to something lower (10 seconds?). Having bigger
> value theoretically decreases login security as attacker have more time to
> exchange stolen code for token.
>

Client login timeout could potentially be smaller than one minute. However,
10 seconds is to short as there will be requests that take more than 10
seconds. So it could be reduced to 30 seconds. However, the difference
between 30 seconds and 1 minute has no effect on security. If someone can
intercept the code and use within a minute they can do it within 30 seconds
as well (even 10 seconds). So 1 minute is as good from a security
perspective IMO, but more user friendly than 10 seconds.


>
>
>
>>
>> Also seconds are good for development. For example, I am sometimes using
>> seconds for testing (IE. setting timeout to 10 seconds to quickly enforce
>> refresh etc)
>>
>> Skip seconds to address KEYCLOAK-1341 looks to me like workaround rather
>> than real solution. The question is if we should address KEYCLOAK-1341 at
>> all? There are probably many possibilities how can admin breaks the login
>> to admin console itself or break the keycloak entirely. Few examples, which
>> come to my mind (there are likely much more):
>> - Delete or disable security-admin-console client
>>
>
> We're going to prevent users from deleting internal clients and roles, so
> that won't be a problem anymore
>
>
>> - delete or disable himself
>>
>
> Can be recovered by adding new user using add-user script
>
>
>> - remove roles from himself
>>
>
> Same as above
>
>
>> - remove scopes from security-admin-console client
>>
>
> We haven't covered that one
>
>
>> - configure authentication flow in some way that it's not possible login
>> anymore
>>
>
> Not covered either
>
>
>> - Timeouts
>>
>> I don't think that we should try to prevent all of these situations. I
>> didn't see any real support questions related to this. And for example in
>> linux if you do "rm -rf /home" the system is broken as well. Isn't this
>> kind of similar? IMO admins should do backup of database, so they can
>> revert if they accidentally mis-configure things.
>>
>
> What you are saying makes no sense whatsoever. It's like saying validation
> in user interfaces is a waste of time.
>
> I am not saying validation is lack of time. Agree we should have them. But
> IMO validations are not always sufficient and I don't think that we can
> handle every "bad" situation. So would recommend people to do backup of
> database to prevent mis-configure things.
>

> Also not sure if it's always good approach to restrict functionality from
> admin console just to prevent people from break things. Likely yes in some
> cases (builtin objects), however in some other it may be better to use
> cofirmation warnings (Do you really want to set timeout just to 10 seconds?
> Do you really want to re-configure browser authentication flow of master
> realm? etc). I suppose admins are technical people and they know what
> they're doing.
>
>
> Validation in user interfaces are there to help people, and to prevent
> people doing things that will screw things up. This is an really good
> example of where lack of validation on inputs allows users to set stupid
> values. 1 second timeouts never makes any sense, so why should we let users
> set it. It could also be a mistake as someone wanted to set 1 minute, but
> selected second by mistake.
>
> How about use the confirmation dialog if any timeout is set to smaller
> value than 10 seconds as I mentioned above?
>

-1 There's just no need for less than 10 seconds so why even have the
option. Removing seconds is a really simple fix. Adding validation and
additional notifications boxes is more complex.


>
> There are likely much more things, which we should handle regarding
> timeouts. And likely disallow some of them. For example:
> - If someone sets "Session Idle timeout" smaller than "Access token
> timeout", the refreshes will be broken. This config should be probably
> restricted
> - Same for "Session max lifespan" . Maybe we should prevent people from
> set "Session max lifespan" to be shorter than any other timeout at all
> (despite "Offline session idle" )
>

Yes, but we can't do everything now. We'll need to introduce proper
validation on admin console/endpoints at some stage, but that's for later.

This was a simple proposal to remove one pretty disastrous mistake.


>
>
> Marek
>
>
> Arguing against preventing people from screwing things up for themselves
> by coming with another example where they can screw things up is just not
> good argumentation. We should do as much as we can, and in this case it's a
> very simple fix that could prevent a rather annoying issue.
>
>
>>
>> Marek
>>
>> On 21/01/16 20:45, Stian Thorgersen wrote:
>>
>> Do we need to have seconds at all for token timeouts? Removing seconds
>> from token would make it simpler, but also make sure no one sets timeouts
>> that are to short (see  <https://issues.jboss.org/browse/KEYCLOAK-1341>
>> https://issues.jboss.org/browse/KEYCLOAK-1341)
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/d3d9f796/attachment-0001.html 

From sthorger at redhat.com  Mon Jan 25 06:02:17 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 12:02:17 +0100
Subject: [keycloak-dev] Code style
In-Reply-To: <56A5F9E0.50206@redhat.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
	<56A5F9E0.50206@redhat.com>
Message-ID: <CAJgngAe6Teg+CRiUSs2pJXK97jt3TLBPwkKPSeBzehfAJW6_NA@mail.gmail.com>

I'll take a look at it, but sounds like exactly what we'll need. We can
just copy those to Keycloak, then do a batch format of the code. In the
future we can consider if a checkstyle is required.

On 25 January 2016 at 11:33, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/01/16 20:28, Stian Thorgersen wrote:
>
> I'm wasn't planing on having a lengthy discussion about code style. It's
> usually just a matter of personal preference and folks do get used to most
> things.
>
> Questions are:
>
> * Should we have a code style?
> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone says
> IntelliJ)
> * Should we enable the checkstyle plugin?
>
> With regards to the actual style my first thought was to base it on
> WildFly code style (we do build on top of it after all). However, they do
> not have one for IntelliJ, which makes it a no go IMO. Further I don't
> particularly want to craft one (and try to get configs for IntelliJ match
> Eclipse, which also passes the checkstyle). So do anyone have suggestions
> of other projects we can borrow from?
>
> I am using the Intellij and have the codestyle file imported from liveoak.
> Among other things, it has "import package.*" prevented (related discussion
> in other thread).
>
> We had netbeans, eclipse and intellij there and I hope there were in sync:
> https://github.com/liveoak-io/liveoak/tree/master/support/ide-configs .
>
> Seeing there was also checkstyle as well:
> https://github.com/liveoak-io/liveoak/blob/master/support/build-config/src/main/resources/liveoak-checkstyle/checkstyle.xml
>
> Marek
>
>
> If we're going to incorporate a code style and re-format the current code
> case now is a very good time.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/d4a58358/attachment.html 

From mposolda at redhat.com  Mon Jan 25 06:18:36 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 12:18:36 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <CAJgngAdw5-jPTwBnWOMpPP=sk_NPx3RCA+1Mxd8kWq4JjSbyww@mail.gmail.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
	<56A5E2D0.40902@redhat.com>
	<CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>
	<56A5F27A.5040805@redhat.com>
	<CAJgngAdw5-jPTwBnWOMpPP=sk_NPx3RCA+1Mxd8kWq4JjSbyww@mail.gmail.com>
Message-ID: <56A6048C.7060106@redhat.com>

On 25/01/16 12:01, Stian Thorgersen wrote:
>
>
> On 25 January 2016 at 11:01, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 25/01/16 10:05, Stian Thorgersen wrote:
>>
>>
>>     On 25 January 2016 at 09:54, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Not sure about that. IMO seconds are good to have more fine
>>         grained timeout values. For example in some deployment the
>>         "Access token timeout" value 1 minute might be too short, but
>>         2 minutes are too long, so they prefer to use 90 seconds as
>>         compromise.
>>
>>
>>     I disagree, I really don't see anyone needing to set timeouts in
>>     second granularity,
>     Hmm... Don't you think the 90 seconds example is not realistic for
>     any deployment?
>
>
> To much options and flexibility is usually what makes people hate 
> something. I'm pretty sure the choice between 1 or 2 min is more than 
> sufficient.
>
>
>     Another thing is "Client login timeout" . This is limited just by
>     network performance and doesn't require any action from user.
>     Usually it will take around 1-2 seconds to complete. So shouldn't
>     we decrease the current default value 1 minute to something lower
>     (10 seconds?). Having bigger value theoretically decreases login
>     security as attacker have more time to exchange stolen code for token.
>
>
> Client login timeout could potentially be smaller than one minute. 
> However, 10 seconds is to short as there will be requests that take 
> more than 10 seconds. So it could be reduced to 30 seconds. However, 
> the difference between 30 seconds and 1 minute has no effect on 
> security. If someone can intercept the code and use within a minute 
> they can do it within 30 seconds as well (even 10 seconds). So 1 
> minute is as good from a security perspective IMO, but more user 
> friendly than 10 seconds.
>
>
>>
>>         Also seconds are good for development. For example, I am
>>         sometimes using seconds for testing (IE. setting timeout to
>>         10 seconds to quickly enforce refresh etc)
>>
>>         Skip seconds to address KEYCLOAK-1341 looks to me like
>>         workaround rather than real solution. The question is if we
>>         should address KEYCLOAK-1341 at all? There are probably many
>>         possibilities how can admin breaks the login to admin console
>>         itself or break the keycloak entirely. Few examples, which
>>         come to my mind (there are likely much more):
>>         - Delete or disable security-admin-console client
>>
>>
>>     We're going to prevent users from deleting internal clients and
>>     roles, so that won't be a problem anymore
>>
>>         - delete or disable himself
>>
>>
>>     Can be recovered by adding new user using add-user script
>>
>>         - remove roles from himself
>>
>>
>>     Same as above
>>
>>         - remove scopes from security-admin-console client
>>
>>
>>     We haven't covered that one
>>
>>         - configure authentication flow in some way that it's not
>>         possible login anymore
>>
>>
>>     Not covered either
>>
>>         - Timeouts
>>
>>         I don't think that we should try to prevent all of these
>>         situations. I didn't see any real support questions related
>>         to this. And for example in linux if you do "rm -rf /home"
>>         the system is broken as well. Isn't this kind of similar? IMO
>>         admins should do backup of database, so they can revert if
>>         they accidentally mis-configure things.
>>
>>
>>     What you are saying makes no sense whatsoever. It's like saying
>>     validation in user interfaces is a waste of time.
>     I am not saying validation is lack of time. Agree we should have
>     them. But IMO validations are not always sufficient and I don't
>     think that we can handle every "bad" situation. So would recommend
>     people to do backup of database to prevent mis-configure things.
>
>
>     Also not sure if it's always good approach to restrict
>     functionality from admin console just to prevent people from break
>     things. Likely yes in some cases (builtin objects), however in
>     some other it may be better to use cofirmation warnings (Do you
>     really want to set timeout just to 10 seconds? Do you really want
>     to re-configure browser authentication flow of master realm? etc).
>     I suppose admins are technical people and they know what they're
>     doing.
>>
>>     Validation in user interfaces are there to help people, and to
>>     prevent people doing things that will screw things up. This is an
>>     really good example of where lack of validation on inputs allows
>>     users to set stupid values. 1 second timeouts never makes any
>>     sense, so why should we let users set it. It could also be a
>>     mistake as someone wanted to set 1 minute, but selected second by
>>     mistake.
>     How about use the confirmation dialog if any timeout is set to
>     smaller value than 10 seconds as I mentioned above?
>
>
> -1 There's just no need for less than 10 seconds so why even have the 
> option. Removing seconds is a really simple fix. Adding validation and 
> additional notifications boxes is more complex.
>
>
>     There are likely much more things, which we should handle
>     regarding timeouts. And likely disallow some of them. For example:
>     - If someone sets "Session Idle timeout" smaller than "Access
>     token timeout", the refreshes will be broken. This config should
>     be probably restricted
>     - Same for "Session max lifespan" . Maybe we should prevent people
>     from set "Session max lifespan" to be shorter than any other
>     timeout at all (despite "Offline session idle" )
>
>
> Yes, but we can't do everything now. We'll need to introduce proper 
> validation on admin console/endpoints at some stage, but that's for later.
>
> This was a simple proposal to remove one pretty disastrous mistake.
Ok, I am fine with that if you thing seconds are redundant. We'll see if 
community has feedback and want to return seconds ;-)

Marek
>
>
>
>     Marek
>>
>>     Arguing against preventing people from screwing things up for
>>     themselves by coming with another example where they can screw
>>     things up is just not good argumentation. We should do as much as
>>     we can, and in this case it's a very simple fix that could
>>     prevent a rather annoying issue.
>>
>>
>>         Marek
>>
>>         On 21/01/16 20:45, Stian Thorgersen wrote:
>>>         Do we need to have seconds at all for token timeouts?
>>>         Removing seconds from token would make it simpler, but also
>>>         make sure no one sets timeouts that are to short (see
>>>         https://issues.jboss.org/browse/KEYCLOAK-1341)
>>>
>>>
>>>         _______________________________________________
>>>         keycloak-dev mailing list
>>>         keycloak-dev at lists.jboss.org
>>>         <mailto:keycloak-dev at lists.jboss.org>
>>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

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

From sthorger at redhat.com  Mon Jan 25 06:27:13 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 12:27:13 +0100
Subject: [keycloak-dev] Remove seconds for token timeouts
In-Reply-To: <56A6048C.7060106@redhat.com>
References: <CAJgngAfjh3BS2W8Ry4eQsM6tj97OAHmGXSoubPzmZrdWywbB9g@mail.gmail.com>
	<56A5E2D0.40902@redhat.com>
	<CAJgngAdRrZxQP-vWx-EdAR14wBGiWhrC78+JpGF_bGkHR8-mPw@mail.gmail.com>
	<56A5F27A.5040805@redhat.com>
	<CAJgngAdw5-jPTwBnWOMpPP=sk_NPx3RCA+1Mxd8kWq4JjSbyww@mail.gmail.com>
	<56A6048C.7060106@redhat.com>
Message-ID: <CAJgngAdk2eSYkZGp+O9ZoVnjYVWgQBpfp-u-+-BuLRq62WDNaA@mail.gmail.com>

I'll buy you a beer in Brno if anyone has a valid reason to require seconds
for token timeouts. I won't take "I can't be bothered waiting for a whole
minute for token to timeout during manual testing" as a valid argument
though.

On 25 January 2016 at 12:18, Marek Posolda <mposolda at redhat.com> wrote:

> On 25/01/16 12:01, Stian Thorgersen wrote:
>
>
>
> On 25 January 2016 at 11:01, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 25/01/16 10:05, Stian Thorgersen wrote:
>>
>>
>>
>> On 25 January 2016 at 09:54, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> Not sure about that. IMO seconds are good to have more fine grained
>>> timeout values. For example in some deployment the "Access token timeout"
>>> value 1 minute might be too short, but 2 minutes are too long, so they
>>> prefer to use 90 seconds as compromise.
>>>
>>
>> I disagree, I really don't see anyone needing to set timeouts in second
>> granularity,
>>
>> Hmm... Don't you think the 90 seconds example is not realistic for any
>> deployment?
>>
>
> To much options and flexibility is usually what makes people hate
> something. I'm pretty sure the choice between 1 or 2 min is more than
> sufficient.
>
>
>>
>> Another thing is "Client login timeout" . This is limited just by network
>> performance and doesn't require any action from user. Usually it will take
>> around 1-2 seconds to complete. So shouldn't we decrease the current
>> default value 1 minute to something lower (10 seconds?). Having bigger
>> value theoretically decreases login security as attacker have more time to
>> exchange stolen code for token.
>>
>
> Client login timeout could potentially be smaller than one minute.
> However, 10 seconds is to short as there will be requests that take more
> than 10 seconds. So it could be reduced to 30 seconds. However, the
> difference between 30 seconds and 1 minute has no effect on security. If
> someone can intercept the code and use within a minute they can do it
> within 30 seconds as well (even 10 seconds). So 1 minute is as good from a
> security perspective IMO, but more user friendly than 10 seconds.
>
>
>>
>>
>>
>>>
>>> Also seconds are good for development. For example, I am sometimes using
>>> seconds for testing (IE. setting timeout to 10 seconds to quickly enforce
>>> refresh etc)
>>>
>>> Skip seconds to address KEYCLOAK-1341 looks to me like workaround rather
>>> than real solution. The question is if we should address KEYCLOAK-1341 at
>>> all? There are probably many possibilities how can admin breaks the login
>>> to admin console itself or break the keycloak entirely. Few examples, which
>>> come to my mind (there are likely much more):
>>> - Delete or disable security-admin-console client
>>>
>>
>> We're going to prevent users from deleting internal clients and roles, so
>> that won't be a problem anymore
>>
>>
>>> - delete or disable himself
>>>
>>
>> Can be recovered by adding new user using add-user script
>>
>>
>>> - remove roles from himself
>>>
>>
>> Same as above
>>
>>
>>> - remove scopes from security-admin-console client
>>>
>>
>> We haven't covered that one
>>
>>
>>> - configure authentication flow in some way that it's not possible login
>>> anymore
>>>
>>
>> Not covered either
>>
>>
>>> - Timeouts
>>>
>>> I don't think that we should try to prevent all of these situations. I
>>> didn't see any real support questions related to this. And for example in
>>> linux if you do "rm -rf /home" the system is broken as well. Isn't this
>>> kind of similar? IMO admins should do backup of database, so they can
>>> revert if they accidentally mis-configure things.
>>>
>>
>> What you are saying makes no sense whatsoever. It's like saying
>> validation in user interfaces is a waste of time.
>>
>> I am not saying validation is lack of time. Agree we should have them.
>> But IMO validations are not always sufficient and I don't think that we can
>> handle every "bad" situation. So would recommend people to do backup of
>> database to prevent mis-configure things.
>>
>
>> Also not sure if it's always good approach to restrict functionality from
>> admin console just to prevent people from break things. Likely yes in some
>> cases (builtin objects), however in some other it may be better to use
>> cofirmation warnings (Do you really want to set timeout just to 10 seconds?
>> Do you really want to re-configure browser authentication flow of master
>> realm? etc). I suppose admins are technical people and they know what
>> they're doing.
>>
>>
>> Validation in user interfaces are there to help people, and to prevent
>> people doing things that will screw things up. This is an really good
>> example of where lack of validation on inputs allows users to set stupid
>> values. 1 second timeouts never makes any sense, so why should we let users
>> set it. It could also be a mistake as someone wanted to set 1 minute, but
>> selected second by mistake.
>>
>> How about use the confirmation dialog if any timeout is set to smaller
>> value than 10 seconds as I mentioned above?
>>
>
> -1 There's just no need for less than 10 seconds so why even have the
> option. Removing seconds is a really simple fix. Adding validation and
> additional notifications boxes is more complex.
>
>
>>
>> There are likely much more things, which we should handle regarding
>> timeouts. And likely disallow some of them. For example:
>> - If someone sets "Session Idle timeout" smaller than "Access token
>> timeout", the refreshes will be broken. This config should be probably
>> restricted
>> - Same for "Session max lifespan" . Maybe we should prevent people from
>> set "Session max lifespan" to be shorter than any other timeout at all
>> (despite "Offline session idle" )
>>
>
> Yes, but we can't do everything now. We'll need to introduce proper
> validation on admin console/endpoints at some stage, but that's for later.
>
> This was a simple proposal to remove one pretty disastrous mistake.
>
> Ok, I am fine with that if you thing seconds are redundant. We'll see if
> community has feedback and want to return seconds ;-)
>
> Marek
>
>
>
>>
>>
>> Marek
>>
>>
>> Arguing against preventing people from screwing things up for themselves
>> by coming with another example where they can screw things up is just not
>> good argumentation. We should do as much as we can, and in this case it's a
>> very simple fix that could prevent a rather annoying issue.
>>
>>
>>>
>>> Marek
>>>
>>> On 21/01/16 20:45, Stian Thorgersen wrote:
>>>
>>> Do we need to have seconds at all for token timeouts? Removing seconds
>>> from token would make it simpler, but also make sure no one sets timeouts
>>> that are to short (see https://issues.jboss.org/browse/KEYCLOAK-1341)
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/cca11c6f/attachment.html 

From mposolda at redhat.com  Mon Jan 25 06:36:54 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 12:36:54 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
Message-ID: <56A608D6.10409@redhat.com>

On 21/01/16 13:19, Stian Thorgersen wrote:
> util/embedded-ldap can we move this to testsuite?
It's used by both testsuite and examples ("ldap" and "kerberos" examples).

That was main motivation to move them to separate module, so examples 
are not dependent on testsuite.

Marek
>
> On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     saml/saml-core I take it that's used by client and server? Should
>     we just move saml-core to the root? Seems unnecessary to have a
>     parent module with only one module inside.
>
>     On 21 January 2016 at 13:08, Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>> wrote:
>
>
>
>         On 20 January 2016 at 23:27, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>> wrote:
>
>             "backends" (jpa, mongo, infinispan) were consolidated under
>             keycloak-model-(jpa, mongo, infinispan).
>
>             Integration module was moved around into:
>             adapters/
>             adapters/oidc
>             adapters/saml
>             spi/
>
>             connections, broker, social, events etc. were consolidated.
>
>             Modules I did not consolidate:
>
>             federation/*
>
>             I kept federation separate as I'm wondering what will
>             happen with
>             kerberos and IBM JDK.  LDAP module depends on kerberos, so
>             I kept that
>             separate too.
>
>             events/syslog
>
>
>         I'm deleting this. Shouldn't have been added in the first
>         place as syslog can be done with the syslog appender for
>         regular logging. Besides no one actually requested it.
>
>
>             Not sure if this is something we was removable or not as
>             it depends on a
>             thirdparty library.
>
>             client-registration/*
>
>
>         Moved to integration. It's client lib for client registration
>         service.
>
>             wildfly/*
>
>
>         Needs to stay as is. It's all specifics to WF and they can't
>         be combined.
>
>
>             I don't know much about these modules so I kept them separate.
>             Stian/Marko can decide what they want to do here.
>
>             --
>             Bill Burke
>             JBoss, a division of Red Hat
>             http://bill.burkecentral.com
>
>             _______________________________________________
>             keycloak-dev mailing list
>             keycloak-dev at lists.jboss.org
>             <mailto:keycloak-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>

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

From sthorger at redhat.com  Mon Jan 25 06:47:11 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 12:47:11 +0100
Subject: [keycloak-dev] Code style
In-Reply-To: <CAJgngAe6Teg+CRiUSs2pJXK97jt3TLBPwkKPSeBzehfAJW6_NA@mail.gmail.com>
References: <CAJgngAe4v5CrDV4VfWCgWrYVnGPgoPmmBaqsgN+rRm6cO_SkNg@mail.gmail.com>
	<56A5F9E0.50206@redhat.com>
	<CAJgngAe6Teg+CRiUSs2pJXK97jt3TLBPwkKPSeBzehfAJW6_NA@mail.gmail.com>
Message-ID: <CAJgngAei9Sh4y8WZxkc64-EeiRR=bzwbiRAqUC6nBgtq9nXtGA@mail.gmail.com>

Got a tip about http://editorconfig.org/. Looks interesting, anyone tried
it?

On 25 January 2016 at 12:02, Stian Thorgersen <sthorger at redhat.com> wrote:

> I'll take a look at it, but sounds like exactly what we'll need. We can
> just copy those to Keycloak, then do a batch format of the code. In the
> future we can consider if a checkstyle is required.
>
> On 25 January 2016 at 11:33, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 21/01/16 20:28, Stian Thorgersen wrote:
>>
>> I'm wasn't planing on having a lengthy discussion about code style. It's
>> usually just a matter of personal preference and folks do get used to most
>> things.
>>
>> Questions are:
>>
>> * Should we have a code style?
>> * What IDEs are Keycloak devs using (I'm crossing my fingers everyone
>> says IntelliJ)
>> * Should we enable the checkstyle plugin?
>>
>> With regards to the actual style my first thought was to base it on
>> WildFly code style (we do build on top of it after all). However, they do
>> not have one for IntelliJ, which makes it a no go IMO. Further I don't
>> particularly want to craft one (and try to get configs for IntelliJ match
>> Eclipse, which also passes the checkstyle). So do anyone have suggestions
>> of other projects we can borrow from?
>>
>> I am using the Intellij and have the codestyle file imported from
>> liveoak. Among other things, it has "import package.*" prevented (related
>> discussion in other thread).
>>
>> We had netbeans, eclipse and intellij there and I hope there were in
>> sync:
>> https://github.com/liveoak-io/liveoak/tree/master/support/ide-configs .
>>
>> Seeing there was also checkstyle as well:
>> https://github.com/liveoak-io/liveoak/blob/master/support/build-config/src/main/resources/liveoak-checkstyle/checkstyle.xml
>>
>> Marek
>>
>>
>> If we're going to incorporate a code style and re-format the current code
>> case now is a very good time.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/e6b07b6f/attachment.html 

From sthorger at redhat.com  Mon Jan 25 06:48:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 12:48:45 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <56A608D6.10409@redhat.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
Message-ID: <CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>

Shouldn't the examples be based on a real LDAP server instead? For example
https://directory.apache.org/apacheds/?

On 25 January 2016 at 12:36, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/01/16 13:19, Stian Thorgersen wrote:
>
> util/embedded-ldap can we move this to testsuite?
>
> It's used by both testsuite and examples ("ldap" and "kerberos" examples).
>
> That was main motivation to move them to separate module, so examples are
> not dependent on testsuite.
>
> Marek
>
>
> On 21 January 2016 at 13:18, Stian Thorgersen <sthorger at redhat.com> wrote:
>
>> saml/saml-core I take it that's used by client and server? Should we just
>> move saml-core to the root? Seems unnecessary to have a parent module with
>> only one module inside.
>>
>> On 21 January 2016 at 13:08, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>>
>>>
>>> On 20 January 2016 at 23:27, Bill Burke < <bburke at redhat.com>
>>> bburke at redhat.com> wrote:
>>>
>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>
>>>> Integration module was moved around into:
>>>> adapters/
>>>> adapters/oidc
>>>> adapters/saml
>>>> spi/
>>>>
>>>> connections, broker, social, events etc. were consolidated.
>>>>
>>>> Modules I did not consolidate:
>>>>
>>>> federation/*
>>>>
>>>> I kept federation separate as I'm wondering what will happen with
>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>> separate too.
>>>>
>>>> events/syslog
>>>>
>>>
>>> I'm deleting this. Shouldn't have been added in the first place as
>>> syslog can be done with the syslog appender for regular logging. Besides no
>>> one actually requested it.
>>>
>>>
>>>>
>>>> Not sure if this is something we was removable or not as it depends on a
>>>> thirdparty library.
>>>>
>>>> client-registration/*
>>>>
>>>
>>> Moved to integration. It's client lib for client registration service.
>>>
>>>
>>>> wildfly/*
>>>>
>>>
>>> Needs to stay as is. It's all specifics to WF and they can't be combined.
>>>
>>>
>>>>
>>>> I don't know much about these modules so I kept them separate.
>>>> Stian/Marko can decide what they want to do here.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/31c25bd9/attachment.html 

From mposolda at redhat.com  Mon Jan 25 06:58:12 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 12:58:12 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
	<CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
Message-ID: <56A60DD4.3090606@redhat.com>

Sure, ApacheDS is exactly what we're using in examples and what's used 
by testsuite by default. Module util/embedded-ldap has dependency on 
apache-ds and it's just adding few additional fixes and enhancements.

Marek

On 25/01/16 12:48, Stian Thorgersen wrote:
> Shouldn't the examples be based on a real LDAP server instead? For 
> example https://directory.apache.org/apacheds/?
>
> On 25 January 2016 at 12:36, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 21/01/16 13:19, Stian Thorgersen wrote:
>>     util/embedded-ldap can we move this to testsuite?
>     It's used by both testsuite and examples ("ldap" and "kerberos"
>     examples).
>
>     That was main motivation to move them to separate module, so
>     examples are not dependent on testsuite.
>
>     Marek
>
>>
>>     On 21 January 2016 at 13:18, Stian Thorgersen
>>     <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>         saml/saml-core I take it that's used by client and server?
>>         Should we just move saml-core to the root? Seems unnecessary
>>         to have a parent module with only one module inside.
>>
>>         On 21 January 2016 at 13:08, Stian Thorgersen
>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>
>>
>>
>>             On 20 January 2016 at 23:27, Bill Burke
>>             <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>
>>                 "backends" (jpa, mongo, infinispan) were consolidated
>>                 under
>>                 keycloak-model-(jpa, mongo, infinispan).
>>
>>                 Integration module was moved around into:
>>                 adapters/
>>                 adapters/oidc
>>                 adapters/saml
>>                 spi/
>>
>>                 connections, broker, social, events etc. were
>>                 consolidated.
>>
>>                 Modules I did not consolidate:
>>
>>                 federation/*
>>
>>                 I kept federation separate as I'm wondering what will
>>                 happen with
>>                 kerberos and IBM JDK. LDAP module depends on
>>                 kerberos, so I kept that
>>                 separate too.
>>
>>                 events/syslog
>>
>>
>>             I'm deleting this. Shouldn't have been added in the first
>>             place as syslog can be done with the syslog appender for
>>             regular logging. Besides no one actually requested it.
>>
>>
>>                 Not sure if this is something we was removable or not
>>                 as it depends on a
>>                 thirdparty library.
>>
>>                 client-registration/*
>>
>>
>>             Moved to integration. It's client lib for client
>>             registration service.
>>
>>                 wildfly/*
>>
>>
>>             Needs to stay as is. It's all specifics to WF and they
>>             can't be combined.
>>
>>
>>                 I don't know much about these modules so I kept them
>>                 separate.
>>                 Stian/Marko can decide what they want to do here.
>>
>>                 --
>>                 Bill Burke
>>                 JBoss, a division of Red Hat
>>                 http://bill.burkecentral.com
>>
>>                 _______________________________________________
>>                 keycloak-dev mailing list
>>                 keycloak-dev at lists.jboss.org
>>                 <mailto:keycloak-dev at lists.jboss.org>
>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>
>

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

From sthorger at redhat.com  Mon Jan 25 07:07:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 13:07:19 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <56A60DD4.3090606@redhat.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
	<CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
	<56A60DD4.3090606@redhat.com>
Message-ID: <CAJgngAd8odg2KBcz3O=cTNoncXyfEvThQbPxz-iDNX9dpUKXew@mail.gmail.com>

I know, but the examples should get ApacheDS from
https://directory.apache.org/apacheds/, not a hacked/modified version.

On 25 January 2016 at 12:58, Marek Posolda <mposolda at redhat.com> wrote:

> Sure, ApacheDS is exactly what we're using in examples and what's used by
> testsuite by default. Module util/embedded-ldap has dependency on apache-ds
> and it's just adding few additional fixes and enhancements.
>
> Marek
>
>
> On 25/01/16 12:48, Stian Thorgersen wrote:
>
> Shouldn't the examples be based on a real LDAP server instead? For example
> https://directory.apache.org/apacheds/?
>
> On 25 January 2016 at 12:36, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 21/01/16 13:19, Stian Thorgersen wrote:
>>
>> util/embedded-ldap can we move this to testsuite?
>>
>> It's used by both testsuite and examples ("ldap" and "kerberos"
>> examples).
>>
>> That was main motivation to move them to separate module, so examples are
>> not dependent on testsuite.
>>
>> Marek
>>
>>
>> On 21 January 2016 at 13:18, Stian Thorgersen < <sthorger at redhat.com>
>> sthorger at redhat.com> wrote:
>>
>>> saml/saml-core I take it that's used by client and server? Should we
>>> just move saml-core to the root? Seems unnecessary to have a parent module
>>> with only one module inside.
>>>
>>> On 21 January 2016 at 13:08, Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On 20 January 2016 at 23:27, Bill Burke < <bburke at redhat.com>
>>>> bburke at redhat.com> wrote:
>>>>
>>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>>
>>>>> Integration module was moved around into:
>>>>> adapters/
>>>>> adapters/oidc
>>>>> adapters/saml
>>>>> spi/
>>>>>
>>>>> connections, broker, social, events etc. were consolidated.
>>>>>
>>>>> Modules I did not consolidate:
>>>>>
>>>>> federation/*
>>>>>
>>>>> I kept federation separate as I'm wondering what will happen with
>>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>>> separate too.
>>>>>
>>>>> events/syslog
>>>>>
>>>>
>>>> I'm deleting this. Shouldn't have been added in the first place as
>>>> syslog can be done with the syslog appender for regular logging. Besides no
>>>> one actually requested it.
>>>>
>>>>
>>>>>
>>>>> Not sure if this is something we was removable or not as it depends on
>>>>> a
>>>>> thirdparty library.
>>>>>
>>>>> client-registration/*
>>>>>
>>>>
>>>> Moved to integration. It's client lib for client registration service.
>>>>
>>>>
>>>>> wildfly/*
>>>>>
>>>>
>>>> Needs to stay as is. It's all specifics to WF and they can't be
>>>> combined.
>>>>
>>>>
>>>>>
>>>>> I don't know much about these modules so I kept them separate.
>>>>> Stian/Marko can decide what they want to do here.
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> <http://bill.burkecentral.com>http://bill.burkecentral.com
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/707db856/attachment.html 

From sthorger at redhat.com  Mon Jan 25 07:16:19 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 13:16:19 +0100
Subject: [keycloak-dev] Debug/Trace logging
In-Reply-To: <56A2688F.1050207@redhat.com>
References: <56A2688F.1050207@redhat.com>
Message-ID: <CAJgngAc=5Mb4ijEz707eV1JUmdXRyT7OMg4cL=4BTeVcOUmuUA@mail.gmail.com>

We should not require having two logger fields in a class. Instead we
should create a wrapper logger that gives access to the class logger for
debug, but also the special loggers for other log output. For example:

  final KeycloakLogger logger = KeycloakLogger.getLogger(MyClass.class);

  logger.debug("Hello world!");
  logger.config().serverConfigNotFound();
  logger.realm().realmNameInUse(realmName);

On 22 January 2016 at 18:36, Stan Silvert <ssilvert at redhat.com> wrote:

>  From yesterday's discussion, it was clear that as a group, we consider
> debug/trace logging to be fundamentally different from other logging.
> The loggers I've been concerned with will be logged through a limited
> number of keycloak loggers using broad categories such as User, Realm,
> Config, etc.
>
> But for debug/trace logging, we want the category to be based upon the
> class it was logged from.  That way, you can turn logging on for a
> particular class, package, or sub-package to do your trace.
>
> There is no good way to do both kinds of logging using the same logger
> instance.  Therefore, I propose that debug/trace logging be done the
> same way we've always done it.  Declare a debug/trace logger in your
> class and use that.  Other logging will be done through the keycloak
> logger.
>
> So, to do both kinds of logging in the same class, you declare two loggers:
>
> private static final KeycloakLogger kcLogger = KeycloakLogger.ROOT_LOGGER;
> private static final Logger debugLogger = Logger.getLogger(MyClass.class);
> .....
> kcLogger.CONFIG.localizedMessage("My localized message"); // logged to
> "keycloak-config" category
> .....
> debugLogger.debug("My debug message");  // logged to
> "org.keycloak.mypackage.MyClass" category
>
> Comments?
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/89fe5915/attachment.html 

From lkrzyzan at redhat.com  Mon Jan 25 07:28:54 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Mon, 25 Jan 2016 13:28:54 +0100
Subject: [keycloak-dev] flow redirects are back
In-Reply-To: <56A2BEA0.1060109@redhat.com>
References: <56A2BEA0.1060109@redhat.com>
Message-ID: <D0B6AEC3-FFAB-4383-BA43-055B2EED2EB3@redhat.com>

Just tried fresh build from master and looks good.
After successful login (http post) I see one redirect to login-redirect URL and then GET request on original page.

Thanks,

Libor Krzy?anek
jboss.org Development Team

> On Jan 23, 2016, at 12:43 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> If a required or auth action was successful, the flow redirects to the 
> appropriate path (just like in 1.6).  This time though, there should not 
> be multiple redirects at once.  I'll work on backbutton soon.
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From christian.beikov at gmail.com  Mon Jan 25 08:05:36 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 25 Jan 2016 14:05:36 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
Message-ID: <56A61DA0.1090706@gmail.com>

I don't have a problem with sticky sessions and I will definitively 
configure them, but I am curious. What is the reason for the problems 
with round robin in this test scenario? Are the infinispan caches not 
replicated fast enough or is there an implementation limitation in the 
adapters?

Regards,
Christian

Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
> By default the adapters will require sticky sessions, please refer to 
> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html 
> for more information
>
> On 22 January 2016 at 12:48, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     Hello,
>
>     I am running some tests with my application cluster being secured by a
>     single keycloak server instance and I encountered problems with
>     the adapter.
>
>     My application cluster contains 2 nodes and is load balanced by nginx.
>     For testing purposes, I enabled round robin load balancing which is
>     probably the "cause" for my issues.
>
>     When I access a secured page, I get redirected to keycloak and
>     everything is fine. When I then login, and keycloak redirects me
>     back to
>     the application, I get to a different application cluster node because
>     of round robin. On that node, apparently the initial information
>     of the
>     client session is not available and I get redirected to keycloak login
>     page again. Then keycloak redirects me back to the application, this
>     time to the original node, and says that access is forbidden.
>
>     I suppose the web session caches are not in sync but I just used the
>     default cache containers as they are defined in standalone-ha.xml
>     of my
>     Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>     distributed caches too which work just fine.
>
>     We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>
>     Regards,
>     Christian
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Jan 25 08:20:20 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 14:20:20 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A61DA0.1090706@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
Message-ID: <CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>

Your issue doesn't have anything to do with the Keycloak server side user
sessions, they don't require sticky sessions.

Your issue is down to the http session on the adapter side not being
replicated by default. For the adapter you've got 3 choices: sticky
session, replicated session or stateless. Which is best depends on your
application.


On 25 January 2016 at 14:05, Christian Beikov <christian.beikov at gmail.com>
wrote:

> I don't have a problem with sticky sessions and I will definitively
> configure them, but I am curious. What is the reason for the problems with
> round robin in this test scenario? Are the infinispan caches not replicated
> fast enough or is there an implementation limitation in the adapters?
>

> Regards,
> Christian
>
>
> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>
> By default the adapters will require sticky sessions, please refer to
> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
> for more information
>
> On 22 January 2016 at 12:48, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> Hello,
>>
>> I am running some tests with my application cluster being secured by a
>> single keycloak server instance and I encountered problems with the
>> adapter.
>>
>> My application cluster contains 2 nodes and is load balanced by nginx.
>> For testing purposes, I enabled round robin load balancing which is
>> probably the "cause" for my issues.
>>
>> When I access a secured page, I get redirected to keycloak and
>> everything is fine. When I then login, and keycloak redirects me back to
>> the application, I get to a different application cluster node because
>> of round robin. On that node, apparently the initial information of the
>> client session is not available and I get redirected to keycloak login
>> page again. Then keycloak redirects me back to the application, this
>> time to the original node, and says that access is forbidden.
>>
>> I suppose the web session caches are not in sync but I just used the
>> default cache containers as they are defined in standalone-ha.xml of my
>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>> distributed caches too which work just fine.
>>
>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>
>> Regards,
>> Christian
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/5d25c04b/attachment.html 

From christian.beikov at gmail.com  Mon Jan 25 08:39:10 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 25 Jan 2016 14:39:10 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
Message-ID: <56A6257E.70701@gmail.com>

The documentation states, that the default token-store is "session" and 
as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in 
standalone-ha.xml, so the session should already be replicated.

Regards,
Christian

Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
> Your issue doesn't have anything to do with the Keycloak server side 
> user sessions, they don't require sticky sessions.
>
> Your issue is down to the http session on the adapter side not being 
> replicated by default. For the adapter you've got 3 choices: sticky 
> session, replicated session or stateless. Which is best depends on 
> your application.
>
>
> On 25 January 2016 at 14:05, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I don't have a problem with sticky sessions and I will
>     definitively configure them, but I am curious. What is the reason
>     for the problems with round robin in this test scenario? Are the
>     infinispan caches not replicated fast enough or is there an
>     implementation limitation in the adapters?
>
>
>     Regards,
>     Christian
>
>
>     Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>     By default the adapters will require sticky sessions, please
>>     refer to
>>     http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>     for more information
>>
>>     On 22 January 2016 at 12:48, Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         Hello,
>>
>>         I am running some tests with my application cluster being
>>         secured by a
>>         single keycloak server instance and I encountered problems
>>         with the adapter.
>>
>>         My application cluster contains 2 nodes and is load balanced
>>         by nginx.
>>         For testing purposes, I enabled round robin load balancing
>>         which is
>>         probably the "cause" for my issues.
>>
>>         When I access a secured page, I get redirected to keycloak and
>>         everything is fine. When I then login, and keycloak redirects
>>         me back to
>>         the application, I get to a different application cluster
>>         node because
>>         of round robin. On that node, apparently the initial
>>         information of the
>>         client session is not available and I get redirected to
>>         keycloak login
>>         page again. Then keycloak redirects me back to the
>>         application, this
>>         time to the original node, and says that access is forbidden.
>>
>>         I suppose the web session caches are not in sync but I just
>>         used the
>>         default cache containers as they are defined in
>>         standalone-ha.xml of my
>>         Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>         distributed caches too which work just fine.
>>
>>         We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>
>>         Regards,
>>         Christian
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

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

From ssilvert at redhat.com  Mon Jan 25 09:34:37 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Jan 2016 09:34:37 -0500
Subject: [keycloak-dev] Debug/Trace logging
In-Reply-To: <CAJgngAc=5Mb4ijEz707eV1JUmdXRyT7OMg4cL=4BTeVcOUmuUA@mail.gmail.com>
References: <56A2688F.1050207@redhat.com>
	<CAJgngAc=5Mb4ijEz707eV1JUmdXRyT7OMg4cL=4BTeVcOUmuUA@mail.gmail.com>
Message-ID: <56A6327D.9060706@redhat.com>

Actually, the solution was even simpler than that.  I guess I just 
needed the weekend to clear my head.

On 1/25/2016 7:16 AM, Stian Thorgersen wrote:
> We should not require having two logger fields in a class. Instead we 
> should create a wrapper logger that gives access to the class logger 
> for debug, but also the special loggers for other log output. For 
> example:
>
>   final KeycloakLogger logger = KeycloakLogger.getLogger(MyClass.class);
>
>   logger.debug("Hello world!");
>   logger.config().serverConfigNotFound();
>   logger.realm().realmNameInUse(realmName);
>
> On 22 January 2016 at 18:36, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>      From yesterday's discussion, it was clear that as a group, we
>     consider
>     debug/trace logging to be fundamentally different from other logging.
>     The loggers I've been concerned with will be logged through a limited
>     number of keycloak loggers using broad categories such as User, Realm,
>     Config, etc.
>
>     But for debug/trace logging, we want the category to be based upon the
>     class it was logged from.  That way, you can turn logging on for a
>     particular class, package, or sub-package to do your trace.
>
>     There is no good way to do both kinds of logging using the same logger
>     instance.  Therefore, I propose that debug/trace logging be done the
>     same way we've always done it.  Declare a debug/trace logger in your
>     class and use that.  Other logging will be done through the
>     keycloak logger.
>
>     So, to do both kinds of logging in the same class, you declare two
>     loggers:
>
>     private static final KeycloakLogger kcLogger =
>     KeycloakLogger.ROOT_LOGGER;
>     private static final Logger debugLogger =
>     Logger.getLogger(MyClass.class);
>     .....
>     kcLogger.CONFIG.localizedMessage("My localized message"); // logged to
>     "keycloak-config" category
>     .....
>     debugLogger.debug("My debug message");  // logged to
>     "org.keycloak.mypackage.MyClass" category
>
>     Comments?
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Mon Jan 25 09:45:24 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 15:45:24 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A6257E.70701@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
Message-ID: <CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>

HTTP session replicate is not enabled by default. You need to enable it for
your application.

On 25 January 2016 at 14:39, Christian Beikov <christian.beikov at gmail.com>
wrote:

> The documentation states, that the default token-store is "session" and as
> I wrote before, I have setup clustering on my Wildfly 10 CR4 like in
> standalone-ha.xml, so the session should already be replicated.
>
> Regards,
> Christian
>
>
> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>
> Your issue doesn't have anything to do with the Keycloak server side user
> sessions, they don't require sticky sessions.
>
> Your issue is down to the http session on the adapter side not being
> replicated by default. For the adapter you've got 3 choices: sticky
> session, replicated session or stateless. Which is best depends on your
> application.
>
>
> On 25 January 2016 at 14:05, Christian Beikov <
> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>
>> I don't have a problem with sticky sessions and I will definitively
>> configure them, but I am curious. What is the reason for the problems with
>> round robin in this test scenario? Are the infinispan caches not replicated
>> fast enough or is there an implementation limitation in the adapters?
>>
>
>> Regards,
>> Christian
>>
>>
>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>
>> By default the adapters will require sticky sessions, please refer to
>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html>
>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>> for more information
>>
>> On 22 January 2016 at 12:48, Christian Beikov <
>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I am running some tests with my application cluster being secured by a
>>> single keycloak server instance and I encountered problems with the
>>> adapter.
>>>
>>> My application cluster contains 2 nodes and is load balanced by nginx.
>>> For testing purposes, I enabled round robin load balancing which is
>>> probably the "cause" for my issues.
>>>
>>> When I access a secured page, I get redirected to keycloak and
>>> everything is fine. When I then login, and keycloak redirects me back to
>>> the application, I get to a different application cluster node because
>>> of round robin. On that node, apparently the initial information of the
>>> client session is not available and I get redirected to keycloak login
>>> page again. Then keycloak redirects me back to the application, this
>>> time to the original node, and says that access is forbidden.
>>>
>>> I suppose the web session caches are not in sync but I just used the
>>> default cache containers as they are defined in standalone-ha.xml of my
>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>> distributed caches too which work just fine.
>>>
>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>
>>> Regards,
>>> Christian
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/80387143/attachment.html 

From sthorger at redhat.com  Mon Jan 25 09:46:00 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 15:46:00 +0100
Subject: [keycloak-dev] Debug/Trace logging
In-Reply-To: <56A6327D.9060706@redhat.com>
References: <56A2688F.1050207@redhat.com>
	<CAJgngAc=5Mb4ijEz707eV1JUmdXRyT7OMg4cL=4BTeVcOUmuUA@mail.gmail.com>
	<56A6327D.9060706@redhat.com>
Message-ID: <CAJgngAe7ZuvDp8TFYf-gbTeBMPrDvNsTfKygXsJ+9-8=vxgUPA@mail.gmail.com>

How does it look like from a usage perspective then?

On 25 January 2016 at 15:34, Stan Silvert <ssilvert at redhat.com> wrote:

> Actually, the solution was even simpler than that.  I guess I just needed
> the weekend to clear my head.
>
>
> On 1/25/2016 7:16 AM, Stian Thorgersen wrote:
>
> We should not require having two logger fields in a class. Instead we
> should create a wrapper logger that gives access to the class logger for
> debug, but also the special loggers for other log output. For example:
>
>   final KeycloakLogger logger = KeycloakLogger.getLogger(MyClass.class);
>
>   logger.debug("Hello world!");
>   logger.config().serverConfigNotFound();
>   logger.realm().realmNameInUse(realmName);
>
> On 22 January 2016 at 18:36, Stan Silvert <ssilvert at redhat.com> wrote:
>
>>  From yesterday's discussion, it was clear that as a group, we consider
>> debug/trace logging to be fundamentally different from other logging.
>> The loggers I've been concerned with will be logged through a limited
>> number of keycloak loggers using broad categories such as User, Realm,
>> Config, etc.
>>
>> But for debug/trace logging, we want the category to be based upon the
>> class it was logged from.  That way, you can turn logging on for a
>> particular class, package, or sub-package to do your trace.
>>
>> There is no good way to do both kinds of logging using the same logger
>> instance.  Therefore, I propose that debug/trace logging be done the
>> same way we've always done it.  Declare a debug/trace logger in your
>> class and use that.  Other logging will be done through the keycloak
>> logger.
>>
>> So, to do both kinds of logging in the same class, you declare two
>> loggers:
>>
>> private static final KeycloakLogger kcLogger = KeycloakLogger.ROOT_LOGGER;
>> private static final Logger debugLogger = Logger.getLogger(MyClass.class);
>> .....
>> kcLogger.CONFIG.localizedMessage("My localized message"); // logged to
>> "keycloak-config" category
>> .....
>> debugLogger.debug("My debug message");  // logged to
>> "org.keycloak.mypackage.MyClass" category
>>
>> Comments?
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/4f94968a/attachment.html 

From christian.beikov at gmail.com  Mon Jan 25 09:53:13 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 25 Jan 2016 15:53:13 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
Message-ID: <56A636D9.2060901@gmail.com>

I just wrote that I configured clustering for my application just like 
in the standlone-ha.xml of my Wildfly 10 CR4.
I configured the jgroups subsystem and the distributed caches for web 
sessions as it is done in standalone-ha.xml of Wildfly.
If there is anything else that should be configured, can you please 
point me to that configuration option?

Regards,
Christian

Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
> HTTP session replicate is not enabled by default. You need to enable 
> it for your application.
>
> On 25 January 2016 at 14:39, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     The documentation states, that the default token-store is
>     "session" and as I wrote before, I have setup clustering on my
>     Wildfly 10 CR4 like in standalone-ha.xml, so the session should
>     already be replicated.
>
>     Regards,
>     Christian
>
>
>     Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>     Your issue doesn't have anything to do with the Keycloak server
>>     side user sessions, they don't require sticky sessions.
>>
>>     Your issue is down to the http session on the adapter side not
>>     being replicated by default. For the adapter you've got 3
>>     choices: sticky session, replicated session or stateless. Which
>>     is best depends on your application.
>>
>>
>>     On 25 January 2016 at 14:05, Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         I don't have a problem with sticky sessions and I will
>>         definitively configure them, but I am curious. What is the
>>         reason for the problems with round robin in this test
>>         scenario? Are the infinispan caches not replicated fast
>>         enough or is there an implementation limitation in the adapters?
>>
>>
>>         Regards,
>>         Christian
>>
>>
>>         Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>         By default the adapters will require sticky sessions, please
>>>         refer to
>>>         http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>         for more information
>>>
>>>         On 22 January 2016 at 12:48, Christian Beikov
>>>         <christian.beikov at gmail.com
>>>         <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>             Hello,
>>>
>>>             I am running some tests with my application cluster
>>>             being secured by a
>>>             single keycloak server instance and I encountered
>>>             problems with the adapter.
>>>
>>>             My application cluster contains 2 nodes and is load
>>>             balanced by nginx.
>>>             For testing purposes, I enabled round robin load
>>>             balancing which is
>>>             probably the "cause" for my issues.
>>>
>>>             When I access a secured page, I get redirected to
>>>             keycloak and
>>>             everything is fine. When I then login, and keycloak
>>>             redirects me back to
>>>             the application, I get to a different application
>>>             cluster node because
>>>             of round robin. On that node, apparently the initial
>>>             information of the
>>>             client session is not available and I get redirected to
>>>             keycloak login
>>>             page again. Then keycloak redirects me back to the
>>>             application, this
>>>             time to the original node, and says that access is
>>>             forbidden.
>>>
>>>             I suppose the web session caches are not in sync but I
>>>             just used the
>>>             default cache containers as they are defined in
>>>             standalone-ha.xml of my
>>>             Wildlfy 10 CR4. Clustering with jgroups works, as I use
>>>             other
>>>             distributed caches too which work just fine.
>>>
>>>             We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>
>>>             Regards,
>>>             Christian
>>>             _______________________________________________
>>>             keycloak-dev mailing list
>>>             keycloak-dev at lists.jboss.org
>>>             <mailto:keycloak-dev at lists.jboss.org>
>>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>>
>
>

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

From ssilvert at redhat.com  Mon Jan 25 09:57:09 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 25 Jan 2016 09:57:09 -0500
Subject: [keycloak-dev] Debug/Trace logging
In-Reply-To: <CAJgngAe7ZuvDp8TFYf-gbTeBMPrDvNsTfKygXsJ+9-8=vxgUPA@mail.gmail.com>
References: <56A2688F.1050207@redhat.com>
	<CAJgngAc=5Mb4ijEz707eV1JUmdXRyT7OMg4cL=4BTeVcOUmuUA@mail.gmail.com>
	<56A6327D.9060706@redhat.com>
	<CAJgngAe7ZuvDp8TFYf-gbTeBMPrDvNsTfKygXsJ+9-8=vxgUPA@mail.gmail.com>
Message-ID: <56A637C5.6010806@redhat.com>

On 1/25/2016 9:46 AM, Stian Thorgersen wrote:
> How does it look like from a usage perspective then?
private static final KeycloakLogger logger = 
Logger.getMessageLogger(KeycloakLogger.class, MyClass.class.getName());
.....
logger.CONFIG.localizedMessage("My localized message"); // logged to 
"keycloak-config" category
.....
logger.debug("My debug message");  // logged to 
"org.keycloak.mypackage.MyClass" category
>
> On 25 January 2016 at 15:34, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     Actually, the solution was even simpler than that.  I guess I just
>     needed the weekend to clear my head.
>
>
>     On 1/25/2016 7:16 AM, Stian Thorgersen wrote:
>>     We should not require having two logger fields in a class.
>>     Instead we should create a wrapper logger that gives access to
>>     the class logger for debug, but also the special loggers for
>>     other log output. For example:
>>
>>       final KeycloakLogger logger =
>>     KeycloakLogger.getLogger(MyClass.class);
>>
>>       logger.debug("Hello world!");
>>       logger.config().serverConfigNotFound();
>>       logger.realm().realmNameInUse(realmName);
>>
>>     On 22 January 2016 at 18:36, Stan Silvert <ssilvert at redhat.com
>>     <mailto:ssilvert at redhat.com>> wrote:
>>
>>          From yesterday's discussion, it was clear that as a group,
>>         we consider
>>         debug/trace logging to be fundamentally different from other
>>         logging.
>>         The loggers I've been concerned with will be logged through a
>>         limited
>>         number of keycloak loggers using broad categories such as
>>         User, Realm,
>>         Config, etc.
>>
>>         But for debug/trace logging, we want the category to be based
>>         upon the
>>         class it was logged from.  That way, you can turn logging on
>>         for a
>>         particular class, package, or sub-package to do your trace.
>>
>>         There is no good way to do both kinds of logging using the
>>         same logger
>>         instance.  Therefore, I propose that debug/trace logging be
>>         done the
>>         same way we've always done it.  Declare a debug/trace logger
>>         in your
>>         class and use that.  Other logging will be done through the
>>         keycloak logger.
>>
>>         So, to do both kinds of logging in the same class, you
>>         declare two loggers:
>>
>>         private static final KeycloakLogger kcLogger =
>>         KeycloakLogger.ROOT_LOGGER;
>>         private static final Logger debugLogger =
>>         Logger.getLogger(MyClass.class);
>>         .....
>>         kcLogger.CONFIG.localizedMessage("My localized message"); //
>>         logged to
>>         "keycloak-config" category
>>         .....
>>         debugLogger.debug("My debug message");  // logged to
>>         "org.keycloak.mypackage.MyClass" category
>>
>>         Comments?
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>
>

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

From bburke at redhat.com  Mon Jan 25 10:11:01 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 10:11:01 -0500
Subject: [keycloak-dev] shared emails
Message-ID: <56A63B05.2060408@redhat.com>

Had somebody contact me that they have clients that have multiple 
accounts with the same email.  We don't support that right?

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


From bburke at redhat.com  Mon Jan 25 10:19:15 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 10:19:15 -0500
Subject: [keycloak-dev] on Keycloak SAML Client Adapter Reference Guide
In-Reply-To: <CAFj68vXs5_jqwHn_wDHPEGc0KFynV9pOeV0hkDbPLxh_UjLjTQ@mail.gmail.com>
References: <CAFj68vXs5_jqwHn_wDHPEGc0KFynV9pOeV0hkDbPLxh_UjLjTQ@mail.gmail.com>
Message-ID: <56A63CF3.2040500@redhat.com>

done.

On 1/24/2016 11:13 PM, Arulkumar Ponnusamy wrote:
> Keycloak SAML Client Adapter Reference Guide section 2.7 wrongly 
> saying "IDP SingleSignOnService sub element" instead of "IDP 
> SignleLogoutService" sub element
>
> is it possible to correct this in 1.8 Release .
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From mposolda at redhat.com  Mon Jan 25 11:37:27 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 17:37:27 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAd8odg2KBcz3O=cTNoncXyfEvThQbPxz-iDNX9dpUKXew@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
	<CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
	<56A60DD4.3090606@redhat.com>
	<CAJgngAd8odg2KBcz3O=cTNoncXyfEvThQbPxz-iDNX9dpUKXew@mail.gmail.com>
Message-ID: <56A64F47.8040400@redhat.com>

Just looked at this possibility. It would mean much bigger number of 
steps for people to try out examples.

For classic LDAP they will need to: download from webpage, unzip, run, 
import the LDIF file

However for Kerberos it's much more steps as default ApacheDS setup 
doesn't have kerberos enabled. So additionally they need to download 
Apache Directory studio (more than 100 MB download), enable kerberos 
server through Directory Studio, configure interceptors, sasl principal etc.

Current programmatic configuration used in examples means that people 
can run the embedded ApacheDS server in single step through mvn 
exec:java . Much less pain and much easier setup.

Is the separate util/embedded-ldap module really so big issue? Despite 
manual download and setup, the other possibility to get rid of it may be 
to duplicate some code for ApacheDS setup into the examples itself. It 
would mean some code duplication, however util/embedded-ldap module 
would be removed.

Still I don't like the duplications, my preferred option is to keep as 
it is.

Marek

On 25/01/16 13:07, Stian Thorgersen wrote:
> I know, but the examples should get ApacheDS from 
> https://directory.apache.org/apacheds/, not a hacked/modified version.
>
> On 25 January 2016 at 12:58, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Sure, ApacheDS is exactly what we're using in examples and what's
>     used by testsuite by default. Module util/embedded-ldap has
>     dependency on apache-ds and it's just adding few additional fixes
>     and enhancements.
>
>     Marek
>
>
>     On 25/01/16 12:48, Stian Thorgersen wrote:
>>     Shouldn't the examples be based on a real LDAP server instead?
>>     For example https://directory.apache.org/apacheds/?
>>
>>     On 25 January 2016 at 12:36, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 21/01/16 13:19, Stian Thorgersen wrote:
>>>         util/embedded-ldap can we move this to testsuite?
>>         It's used by both testsuite and examples ("ldap" and
>>         "kerberos" examples).
>>
>>         That was main motivation to move them to separate module, so
>>         examples are not dependent on testsuite.
>>
>>         Marek
>>
>>>
>>>         On 21 January 2016 at 13:18, Stian Thorgersen
>>>         <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>             saml/saml-core I take it that's used by client and
>>>             server? Should we just move saml-core to the root? Seems
>>>             unnecessary to have a parent module with only one module
>>>             inside.
>>>
>>>             On 21 January 2016 at 13:08, Stian Thorgersen
>>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>
>>>
>>>
>>>                 On 20 January 2016 at 23:27, Bill Burke
>>>                 <bburke at redhat.com <mailto:bburke at redhat.com>> wrote:
>>>
>>>                     "backends" (jpa, mongo, infinispan) were
>>>                     consolidated under
>>>                     keycloak-model-(jpa, mongo, infinispan).
>>>
>>>                     Integration module was moved around into:
>>>                     adapters/
>>>                     adapters/oidc
>>>                     adapters/saml
>>>                     spi/
>>>
>>>                     connections, broker, social, events etc. were
>>>                     consolidated.
>>>
>>>                     Modules I did not consolidate:
>>>
>>>                     federation/*
>>>
>>>                     I kept federation separate as I'm wondering what
>>>                     will happen with
>>>                     kerberos and IBM JDK.  LDAP module depends on
>>>                     kerberos, so I kept that
>>>                     separate too.
>>>
>>>                     events/syslog
>>>
>>>
>>>                 I'm deleting this. Shouldn't have been added in the
>>>                 first place as syslog can be done with the syslog
>>>                 appender for regular logging. Besides no one
>>>                 actually requested it.
>>>
>>>
>>>                     Not sure if this is something we was removable
>>>                     or not as it depends on a
>>>                     thirdparty library.
>>>
>>>                     client-registration/*
>>>
>>>
>>>                 Moved to integration. It's client lib for client
>>>                 registration service.
>>>
>>>                     wildfly/*
>>>
>>>
>>>                 Needs to stay as is. It's all specifics to WF and
>>>                 they can't be combined.
>>>
>>>
>>>                     I don't know much about these modules so I kept
>>>                     them separate.
>>>                     Stian/Marko can decide what they want to do here.
>>>
>>>                     --
>>>                     Bill Burke
>>>                     JBoss, a division of Red Hat
>>>                     http://bill.burkecentral.com
>>>
>>>                     _______________________________________________
>>>                     keycloak-dev mailing list
>>>                     keycloak-dev at lists.jboss.org
>>>                     <mailto:keycloak-dev at lists.jboss.org>
>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>
>>
>
>

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

From mposolda at redhat.com  Mon Jan 25 11:43:37 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 17:43:37 +0100
Subject: [keycloak-dev] shared emails
In-Reply-To: <56A63B05.2060408@redhat.com>
References: <56A63B05.2060408@redhat.com>
Message-ID: <56A650B9.2080403@redhat.com>

Yes, we don't support it.

Remember it was requested and discussed on ML some time ago to add 
support for that. I am personally seeing bunch of corner cases and 
potential bugs, so I would rather not support it (unless necessary)

Marek

On 25/01/16 16:11, Bill Burke wrote:
> Had somebody contact me that they have clients that have multiple
> accounts with the same email.  We don't support that right?
>


From sthorger at redhat.com  Mon Jan 25 12:58:33 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 18:58:33 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <56A64F47.8040400@redhat.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
	<CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
	<56A60DD4.3090606@redhat.com>
	<CAJgngAd8odg2KBcz3O=cTNoncXyfEvThQbPxz-iDNX9dpUKXew@mail.gmail.com>
	<56A64F47.8040400@redhat.com>
Message-ID: <CAJgngAfAULg_HiFWZiyJoM1ahRa4mAQQB0jTw8bO7QAqdd23dw@mail.gmail.com>

We will keep it as is for now that's for sure, we have other things to
focus on right now.

Personally at least I don't see much value in an example that doesn't use a
real LDAP server. I wonder if anyone actually uses that example at all.

On 25 January 2016 at 17:37, Marek Posolda <mposolda at redhat.com> wrote:

> Just looked at this possibility. It would mean much bigger number of steps
> for people to try out examples.
>
> For classic LDAP they will need to: download from webpage, unzip, run,
> import the LDIF file
>
> However for Kerberos it's much more steps as default ApacheDS setup
> doesn't have kerberos enabled. So additionally they need to download Apache
> Directory studio (more than 100 MB download), enable kerberos server
> through Directory Studio, configure interceptors, sasl principal etc.
>
> Current programmatic configuration used in examples means that people can
> run the embedded ApacheDS server in single step through mvn exec:java .
> Much less pain and much easier setup.
>
> Is the separate util/embedded-ldap module really so big issue? Despite
> manual download and setup, the other possibility to get rid of it may be to
> duplicate some code for ApacheDS setup into the examples itself. It would
> mean some code duplication, however util/embedded-ldap module would be
> removed.
>
> Still I don't like the duplications, my preferred option is to keep as it
> is.
>
> Marek
>
>
> On 25/01/16 13:07, Stian Thorgersen wrote:
>
> I know, but the examples should get ApacheDS from
> <https://directory.apache.org/apacheds/>
> https://directory.apache.org/apacheds/, not a hacked/modified version.
>
> On 25 January 2016 at 12:58, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Sure, ApacheDS is exactly what we're using in examples and what's used by
>> testsuite by default. Module util/embedded-ldap has dependency on apache-ds
>> and it's just adding few additional fixes and enhancements.
>>
>> Marek
>>
>>
>> On 25/01/16 12:48, Stian Thorgersen wrote:
>>
>> Shouldn't the examples be based on a real LDAP server instead? For
>> example  <https://directory.apache.org/apacheds/>
>> https://directory.apache.org/apacheds/?
>>
>> On 25 January 2016 at 12:36, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> On 21/01/16 13:19, Stian Thorgersen wrote:
>>>
>>> util/embedded-ldap can we move this to testsuite?
>>>
>>> It's used by both testsuite and examples ("ldap" and "kerberos"
>>> examples).
>>>
>>> That was main motivation to move them to separate module, so examples
>>> are not dependent on testsuite.
>>>
>>> Marek
>>>
>>>
>>> On 21 January 2016 at 13:18, Stian Thorgersen < <sthorger at redhat.com>
>>> sthorger at redhat.com> wrote:
>>>
>>>> saml/saml-core I take it that's used by client and server? Should we
>>>> just move saml-core to the root? Seems unnecessary to have a parent module
>>>> with only one module inside.
>>>>
>>>> On 21 January 2016 at 13:08, Stian Thorgersen < <sthorger at redhat.com>
>>>> sthorger at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 20 January 2016 at 23:27, Bill Burke < <bburke at redhat.com>
>>>>> bburke at redhat.com> wrote:
>>>>>
>>>>>> "backends" (jpa, mongo, infinispan) were consolidated under
>>>>>> keycloak-model-(jpa, mongo, infinispan).
>>>>>>
>>>>>> Integration module was moved around into:
>>>>>> adapters/
>>>>>> adapters/oidc
>>>>>> adapters/saml
>>>>>> spi/
>>>>>>
>>>>>> connections, broker, social, events etc. were consolidated.
>>>>>>
>>>>>> Modules I did not consolidate:
>>>>>>
>>>>>> federation/*
>>>>>>
>>>>>> I kept federation separate as I'm wondering what will happen with
>>>>>> kerberos and IBM JDK.  LDAP module depends on kerberos, so I kept that
>>>>>> separate too.
>>>>>>
>>>>>> events/syslog
>>>>>>
>>>>>
>>>>> I'm deleting this. Shouldn't have been added in the first place as
>>>>> syslog can be done with the syslog appender for regular logging. Besides no
>>>>> one actually requested it.
>>>>>
>>>>>
>>>>>>
>>>>>> Not sure if this is something we was removable or not as it depends
>>>>>> on a
>>>>>> thirdparty library.
>>>>>>
>>>>>> client-registration/*
>>>>>>
>>>>>
>>>>> Moved to integration. It's client lib for client registration service.
>>>>>
>>>>>
>>>>>> wildfly/*
>>>>>>
>>>>>
>>>>> Needs to stay as is. It's all specifics to WF and they can't be
>>>>> combined.
>>>>>
>>>>>
>>>>>>
>>>>>> I don't know much about these modules so I kept them separate.
>>>>>> Stian/Marko can decide what they want to do here.
>>>>>>
>>>>>> --
>>>>>> Bill Burke
>>>>>> JBoss, a division of Red Hat
>>>>>> <http://bill.burkecentral.com>http://bill.burkecentral.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/ac27031a/attachment.html 

From sthorger at redhat.com  Mon Jan 25 13:04:34 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 25 Jan 2016 19:04:34 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A636D9.2060901@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
Message-ID: <CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>

Try google for wildfly replicate http sessions

On 25 January 2016 at 15:53, Christian Beikov <christian.beikov at gmail.com>
wrote:

> I just wrote that I configured clustering for my application just like in
> the standlone-ha.xml of my Wildfly 10 CR4.
> I configured the jgroups subsystem and the distributed caches for web
> sessions as it is done in standalone-ha.xml of Wildfly.
> If there is anything else that should be configured, can you please point
> me to that configuration option?
>
> Regards,
> Christian
>
>
> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>
> HTTP session replicate is not enabled by default. You need to enable it
> for your application.
>
> On 25 January 2016 at 14:39, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> The documentation states, that the default token-store is "session" and
>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in
>> standalone-ha.xml, so the session should already be replicated.
>>
>> Regards,
>> Christian
>>
>>
>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>
>> Your issue doesn't have anything to do with the Keycloak server side user
>> sessions, they don't require sticky sessions.
>>
>> Your issue is down to the http session on the adapter side not being
>> replicated by default. For the adapter you've got 3 choices: sticky
>> session, replicated session or stateless. Which is best depends on your
>> application.
>>
>>
>> On 25 January 2016 at 14:05, Christian Beikov <
>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>
>>> I don't have a problem with sticky sessions and I will definitively
>>> configure them, but I am curious. What is the reason for the problems with
>>> round robin in this test scenario? Are the infinispan caches not replicated
>>> fast enough or is there an implementation limitation in the adapters?
>>>
>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>
>>> By default the adapters will require sticky sessions, please refer to
>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html>
>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>> for more information
>>>
>>> On 22 January 2016 at 12:48, Christian Beikov <
>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am running some tests with my application cluster being secured by a
>>>> single keycloak server instance and I encountered problems with the
>>>> adapter.
>>>>
>>>> My application cluster contains 2 nodes and is load balanced by nginx.
>>>> For testing purposes, I enabled round robin load balancing which is
>>>> probably the "cause" for my issues.
>>>>
>>>> When I access a secured page, I get redirected to keycloak and
>>>> everything is fine. When I then login, and keycloak redirects me back to
>>>> the application, I get to a different application cluster node because
>>>> of round robin. On that node, apparently the initial information of the
>>>> client session is not available and I get redirected to keycloak login
>>>> page again. Then keycloak redirects me back to the application, this
>>>> time to the original node, and says that access is forbidden.
>>>>
>>>> I suppose the web session caches are not in sync but I just used the
>>>> default cache containers as they are defined in standalone-ha.xml of my
>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>>> distributed caches too which work just fine.
>>>>
>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>
>>>> Regards,
>>>> Christian
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160125/796e806e/attachment-0001.html 

From christian.beikov at gmail.com  Mon Jan 25 14:33:34 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 25 Jan 2016 20:33:34 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
Message-ID: <56A6788E.5030408@gmail.com>

I don't want to be rude but you aren't helping me at all so I'd like to 
ask someone else from the team about this. I tried to explain multiple 
times that I already configured clustering in my Wildfly server, thus I 
configured session replication.
Either I don't understand something about session replication or I 
require a configuration that you don't mention anywhere.
I copied over the cache container from the standalone-ha configurations 
and configured the JGroups Subsystem which is what is described in the 
official documentation: 
https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide

I think I gave you enough information about my situation which you 
seemed to ignore completely. I would very much appreciate if I got a 
clear answer to my question especially since I am not asking for general 
configuration help, but for this special case which to me seems like a 
problem/limitation that should be explicitly documented.

I am pretty sure clustering/session replication is configured correctly 
since I am using a custom cache container with a similar configuration 
like the web cache container which I know replicates correctly. So here 
comes my question once again, is it possible that the replication just 
lags behind which makes the usage of round robin completely impossible 
in the login flow? Or is there some kind of special configuration I have 
to do which differs from the standard cluster configuration as provided 
by the wildfly distribution? Or is this maybe even an implementation 
limiation of the server adapter?

Regards,
Christian

Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
> Try google for wildfly replicate http sessions
>
> On 25 January 2016 at 15:53, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I just wrote that I configured clustering for my application just
>     like in the standlone-ha.xml of my Wildfly 10 CR4.
>     I configured the jgroups subsystem and the distributed caches for
>     web sessions as it is done in standalone-ha.xml of Wildfly.
>     If there is anything else that should be configured, can you
>     please point me to that configuration option?
>
>     Regards,
>     Christian
>
>
>     Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>     HTTP session replicate is not enabled by default. You need to
>>     enable it for your application.
>>
>>     On 25 January 2016 at 14:39, Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         The documentation states, that the default token-store is
>>         "session" and as I wrote before, I have setup clustering on
>>         my Wildfly 10 CR4 like in standalone-ha.xml, so the session
>>         should already be replicated.
>>
>>         Regards,
>>         Christian
>>
>>
>>         Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>         Your issue doesn't have anything to do with the Keycloak
>>>         server side user sessions, they don't require sticky sessions.
>>>
>>>         Your issue is down to the http session on the adapter side
>>>         not being replicated by default. For the adapter you've got
>>>         3 choices: sticky session, replicated session or stateless.
>>>         Which is best depends on your application.
>>>
>>>
>>>         On 25 January 2016 at 14:05, Christian Beikov
>>>         <christian.beikov at gmail.com
>>>         <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>             I don't have a problem with sticky sessions and I will
>>>             definitively configure them, but I am curious. What is
>>>             the reason for the problems with round robin in this
>>>             test scenario? Are the infinispan caches not replicated
>>>             fast enough or is there an implementation limitation in
>>>             the adapters?
>>>
>>>
>>>             Regards,
>>>             Christian
>>>
>>>
>>>             Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>             By default the adapters will require sticky sessions,
>>>>             please refer to
>>>>             http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>             for more information
>>>>
>>>>             On 22 January 2016 at 12:48, Christian Beikov
>>>>             <christian.beikov at gmail.com
>>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                 Hello,
>>>>
>>>>                 I am running some tests with my application cluster
>>>>                 being secured by a
>>>>                 single keycloak server instance and I encountered
>>>>                 problems with the adapter.
>>>>
>>>>                 My application cluster contains 2 nodes and is load
>>>>                 balanced by nginx.
>>>>                 For testing purposes, I enabled round robin load
>>>>                 balancing which is
>>>>                 probably the "cause" for my issues.
>>>>
>>>>                 When I access a secured page, I get redirected to
>>>>                 keycloak and
>>>>                 everything is fine. When I then login, and keycloak
>>>>                 redirects me back to
>>>>                 the application, I get to a different application
>>>>                 cluster node because
>>>>                 of round robin. On that node, apparently the
>>>>                 initial information of the
>>>>                 client session is not available and I get
>>>>                 redirected to keycloak login
>>>>                 page again. Then keycloak redirects me back to the
>>>>                 application, this
>>>>                 time to the original node, and says that access is
>>>>                 forbidden.
>>>>
>>>>                 I suppose the web session caches are not in sync
>>>>                 but I just used the
>>>>                 default cache containers as they are defined in
>>>>                 standalone-ha.xml of my
>>>>                 Wildlfy 10 CR4. Clustering with jgroups works, as I
>>>>                 use other
>>>>                 distributed caches too which work just fine.
>>>>
>>>>                 We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>
>>>>                 Regards,
>>>>                 Christian
>>>>                 _______________________________________________
>>>>                 keycloak-dev mailing list
>>>>                 keycloak-dev at lists.jboss.org
>>>>                 <mailto:keycloak-dev at lists.jboss.org>
>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

From tkyjovsk at redhat.com  Mon Jan 25 15:07:55 2016
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Mon, 25 Jan 2016 15:07:55 -0500 (EST)
Subject: [keycloak-dev] Maven Surefire plugin - memory settings for JDK 8
In-Reply-To: <560500624.17403431.1453751252804.JavaMail.zimbra@redhat.com>
Message-ID: <1379731134.17420388.1453752475393.JavaMail.zimbra@redhat.com>

Hello,

Looking at global settings for Surefire plugin in keycloak/pom.xml:

  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <forkMode>once</forkMode>
    <argLine>-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m</argLine>
  </configuration>


1) The heap space settings seems quite high. Is there some reason for 2g heap? If not, can we lower it say to 1g?

2) In JDK 8 permspace was replaced by metaspace which we might want to limit instead.


Tomas

From tkyjovsk at redhat.com  Mon Jan 25 15:15:42 2016
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Mon, 25 Jan 2016 15:15:42 -0500 (EST)
Subject: [keycloak-dev] Maven Surefire plugin - memory settings for JDK 8
In-Reply-To: <1379731134.17420388.1453752475393.JavaMail.zimbra@redhat.com>
References: <1379731134.17420388.1453752475393.JavaMail.zimbra@redhat.com>
Message-ID: <789306919.17423801.1453752942218.JavaMail.zimbra@redhat.com>



----- Original Message -----
> Hello,
> 
> Looking at global settings for Surefire plugin in keycloak/pom.xml:
> 
>   <artifactId>maven-surefire-plugin</artifactId>
>   <configuration>
>     <forkMode>once</forkMode>
>     <argLine>-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m</argLine>

Sorry, I pasted my local surefire test config by mistake. The original configuration in master is:

     <argLine>-Xms512m -Xmx2048m -XX:MaxPermSize=1024m</argLine>


>   </configuration>
> 
> 
> 1) The heap space settings seems quite high. Is there some reason for 2g
> heap? If not, can we lower it say to 1g?
> 
> 2) In JDK 8 permspace was replaced by metaspace which we might want to limit
> instead.
> 
> 
> Tomas
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Mon Jan 25 15:41:25 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 15:41:25 -0500
Subject: [keycloak-dev] Maven Surefire plugin - memory settings for JDK 8
In-Reply-To: <789306919.17423801.1453752942218.JavaMail.zimbra@redhat.com>
References: <1379731134.17420388.1453752475393.JavaMail.zimbra@redhat.com>
	<789306919.17423801.1453752942218.JavaMail.zimbra@redhat.com>
Message-ID: <56A68875.40602@redhat.com>

We tear down and bring up the server a lot and I have noticed the JVM 
thrashing and slowing down the farther you get into the testrun.  
Expanding the heap solved the problem.

On 1/25/2016 3:15 PM, Tomas Kyjovsky wrote:
>
> ----- Original Message -----
>> Hello,
>>
>> Looking at global settings for Surefire plugin in keycloak/pom.xml:
>>
>>    <artifactId>maven-surefire-plugin</artifactId>
>>    <configuration>
>>      <forkMode>once</forkMode>
>>      <argLine>-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m</argLine>
> Sorry, I pasted my local surefire test config by mistake. The original configuration in master is:
>
>       <argLine>-Xms512m -Xmx2048m -XX:MaxPermSize=1024m</argLine>
>
>
>>    </configuration>
>>
>>
>> 1) The heap space settings seems quite high. Is there some reason for 2g
>> heap? If not, can we lower it say to 1g?
>>
>> 2) In JDK 8 permspace was replaced by metaspace which we might want to limit
>> instead.
>>
>>
>> Tomas
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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


From mposolda at redhat.com  Mon Jan 25 15:42:51 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 21:42:51 +0100
Subject: [keycloak-dev] module re-org complete?
In-Reply-To: <CAJgngAfAULg_HiFWZiyJoM1ahRa4mAQQB0jTw8bO7QAqdd23dw@mail.gmail.com>
References: <56A009DA.1020608@redhat.com>
	<CAJgngAcuCNOMmjL42xU78Pp7=OZGvfX8xnwhW==rLaosPq-2wg@mail.gmail.com>
	<CAJgngAfVnTrBU-qpkeNONdEttE7RiaNyQhGSytCO768AHjta7A@mail.gmail.com>
	<CAJgngAdwLi+=s4knu0cT_g8+r_nUt-R3KG-uR0_zGPZdjPxrOg@mail.gmail.com>
	<56A608D6.10409@redhat.com>
	<CAJgngAdUQB-U=GaUBL6scyeqvVaWoV=5d5dZCVLsgyZqp3hssg@mail.gmail.com>
	<56A60DD4.3090606@redhat.com>
	<CAJgngAd8odg2KBcz3O=cTNoncXyfEvThQbPxz-iDNX9dpUKXew@mail.gmail.com>
	<56A64F47.8040400@redhat.com>
	<CAJgngAfAULg_HiFWZiyJoM1ahRa4mAQQB0jTw8bO7QAqdd23dw@mail.gmail.com>
Message-ID: <56A688CB.1030804@redhat.com>

The point of the examples is to show Keycloak features. For LDAP, it's 
about showing how to configure LDAP Federation provider and mappers. For 
Kerberos it's SPNEGO authentication with credential delegation used in 
the app.

IMO for examples it doesn't matter if you use "real" production ready 
LDAP server or not. The mappers etc should work with any LDAP server 
vendor. The only reason for ApacheDS is that it's Java based and easy to 
run for "hello-worldish" scenario.

Same like Wildfly is using H2 by default due it's java based without any 
setup required, however in production you will switch to some different 
"real" database.

Marek

On 25/01/16 18:58, Stian Thorgersen wrote:
> We will keep it as is for now that's for sure, we have other things to 
> focus on right now.
>
> Personally at least I don't see much value in an example that doesn't 
> use a real LDAP server. I wonder if anyone actually uses that example 
> at all.
>
> On 25 January 2016 at 17:37, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Just looked at this possibility. It would mean much bigger number
>     of steps for people to try out examples.
>
>     For classic LDAP they will need to: download from webpage, unzip,
>     run, import the LDIF file
>
>     However for Kerberos it's much more steps as default ApacheDS
>     setup doesn't have kerberos enabled. So additionally they need to
>     download Apache Directory studio (more than 100 MB download),
>     enable kerberos server through Directory Studio, configure
>     interceptors, sasl principal etc.
>
>     Current programmatic configuration used in examples means that
>     people can run the embedded ApacheDS server in single step through
>     mvn exec:java . Much less pain and much easier setup.
>
>     Is the separate util/embedded-ldap module really so big issue?
>     Despite manual download and setup, the other possibility to get
>     rid of it may be to duplicate some code for ApacheDS setup into
>     the examples itself. It would mean some code duplication, however
>     util/embedded-ldap module would be removed.
>
>     Still I don't like the duplications, my preferred option is to
>     keep as it is.
>
>     Marek
>
>
>     On 25/01/16 13:07, Stian Thorgersen wrote:
>>     I know, but the examples should get ApacheDS from
>>     https://directory.apache.org/apacheds/, not a hacked/modified
>>     version.
>>
>>     On 25 January 2016 at 12:58, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Sure, ApacheDS is exactly what we're using in examples and
>>         what's used by testsuite by default. Module
>>         util/embedded-ldap has dependency on apache-ds and it's just
>>         adding few additional fixes and enhancements.
>>
>>         Marek
>>
>>
>>         On 25/01/16 12:48, Stian Thorgersen wrote:
>>>         Shouldn't the examples be based on a real LDAP server
>>>         instead? For example https://directory.apache.org/apacheds/?
>>>
>>>         On 25 January 2016 at 12:36, Marek Posolda
>>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>             On 21/01/16 13:19, Stian Thorgersen wrote:
>>>>             util/embedded-ldap can we move this to testsuite?
>>>             It's used by both testsuite and examples ("ldap" and
>>>             "kerberos" examples).
>>>
>>>             That was main motivation to move them to separate
>>>             module, so examples are not dependent on testsuite.
>>>
>>>             Marek
>>>
>>>>
>>>>             On 21 January 2016 at 13:18, Stian Thorgersen
>>>>             <sthorger at redhat.com <mailto:sthorger at redhat.com>> wrote:
>>>>
>>>>                 saml/saml-core I take it that's used by client and
>>>>                 server? Should we just move saml-core to the root?
>>>>                 Seems unnecessary to have a parent module with only
>>>>                 one module inside.
>>>>
>>>>                 On 21 January 2016 at 13:08, Stian Thorgersen
>>>>                 <sthorger at redhat.com <mailto:sthorger at redhat.com>>
>>>>                 wrote:
>>>>
>>>>
>>>>
>>>>                     On 20 January 2016 at 23:27, Bill Burke
>>>>                     <bburke at redhat.com <mailto:bburke at redhat.com>>
>>>>                     wrote:
>>>>
>>>>                         "backends" (jpa, mongo, infinispan) were
>>>>                         consolidated under
>>>>                         keycloak-model-(jpa, mongo, infinispan).
>>>>
>>>>                         Integration module was moved around into:
>>>>                         adapters/
>>>>                         adapters/oidc
>>>>                         adapters/saml
>>>>                         spi/
>>>>
>>>>                         connections, broker, social, events etc.
>>>>                         were consolidated.
>>>>
>>>>                         Modules I did not consolidate:
>>>>
>>>>                         federation/*
>>>>
>>>>                         I kept federation separate as I'm wondering
>>>>                         what will happen with
>>>>                         kerberos and IBM JDK.  LDAP module depends
>>>>                         on kerberos, so I kept that
>>>>                         separate too.
>>>>
>>>>                         events/syslog
>>>>
>>>>
>>>>                     I'm deleting this. Shouldn't have been added in
>>>>                     the first place as syslog can be done with the
>>>>                     syslog appender for regular logging. Besides no
>>>>                     one actually requested it.
>>>>
>>>>
>>>>                         Not sure if this is something we was
>>>>                         removable or not as it depends on a
>>>>                         thirdparty library.
>>>>
>>>>                         client-registration/*
>>>>
>>>>
>>>>                     Moved to integration. It's client lib for
>>>>                     client registration service.
>>>>
>>>>                         wildfly/*
>>>>
>>>>
>>>>                     Needs to stay as is. It's all specifics to WF
>>>>                     and they can't be combined.
>>>>
>>>>
>>>>                         I don't know much about these modules so I
>>>>                         kept them separate.
>>>>                         Stian/Marko can decide what they want to do
>>>>                         here.
>>>>
>>>>                         --
>>>>                         Bill Burke
>>>>                         JBoss, a division of Red Hat
>>>>                         http://bill.burkecentral.com
>>>>
>>>>                         _______________________________________________
>>>>                         keycloak-dev mailing list
>>>>                         keycloak-dev at lists.jboss.org
>>>>                         <mailto:keycloak-dev at lists.jboss.org>
>>>>                         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

From mposolda at redhat.com  Mon Jan 25 15:54:03 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 25 Jan 2016 21:54:03 +0100
Subject: [keycloak-dev] Should we allow response_type=token ?
Message-ID: <56A68B6B.3010002@redhat.com>

Question about https://issues.jboss.org/browse/KEYCLOAK-2351 . Should we 
allow response_type=token ?

Basically OAuth2 allows that [1] but OpenID Connect doesn't for implicit 
nor hybrid flow to use response_type=token alone without "id_token" or 
"code" [2] [3] .

I am fine with support response_type=token, however doesn't we break 
OpenID Connect specs then? Or should we have option (either on/off flag 
or list of valid response_type combinations) in configuration to specify 
whether it's allowed or not?

[1] https://tools.ietf.org/html/rfc6749#section-4.2.1
[2] http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
[3] http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest

Marek



From bburke at redhat.com  Mon Jan 25 15:58:38 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 15:58:38 -0500
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A6788E.5030408@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
Message-ID: <56A68C7E.4080508@redhat.com>

What do you mean by you're "pretty sure clustering/session replication 
is configured correctly".  Either its working or it isn't.   Have you 
tested a simple application WITHOUT keycloak and with Round Robin to 
determine if replication is set?    Because from what you are describing 
and what Stian said to you over and over again is that it does not look 
like HTTP session replication is working for you.  Keycloak client 
adapter stores that you are authenticated within the HttpSession.  It is 
possible that session replication is lagging I think...only if you have 
async replication turned on.  I don't know what the default is in 
Wildfly 10.

Also, a forbidden exception might mean that your web.xml requires a role 
set for the user for the URL you are accessing and the user does not 
have that role assigned to them.

On 1/25/2016 2:33 PM, Christian Beikov wrote:
> I don't want to be rude but you aren't helping me at all so I'd like 
> to ask someone else from the team about this. I tried to explain 
> multiple times that I already configured clustering in my Wildfly 
> server, thus I configured session replication.
> Either I don't understand something about session replication or I 
> require a configuration that you don't mention anywhere.
> I copied over the cache container from the standalone-ha 
> configurations and configured the JGroups Subsystem which is what is 
> described in the official documentation: 
> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>
> I think I gave you enough information about my situation which you 
> seemed to ignore completely. I would very much appreciate if I got a 
> clear answer to my question especially since I am not asking for 
> general configuration help, but for this special case which to me 
> seems like a problem/limitation that should be explicitly documented.
>
> I am pretty sure clustering/session replication is configured 
> correctly since I am using a custom cache container with a similar 
> configuration like the web cache container which I know replicates 
> correctly. So here comes my question once again, is it possible that 
> the replication just lags behind which makes the usage of round robin 
> completely impossible in the login flow? Or is there some kind of 
> special configuration I have to do which differs from the standard 
> cluster configuration as provided by the wildfly distribution? Or is 
> this maybe even an implementation limiation of the server adapter?
>
> Regards,
> Christian
>
> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>> Try google for wildfly replicate http sessions
>>
>> On 25 January 2016 at 15:53, Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>     I just wrote that I configured clustering for my application just
>>     like in the standlone-ha.xml of my Wildfly 10 CR4.
>>     I configured the jgroups subsystem and the distributed caches for
>>     web sessions as it is done in standalone-ha.xml of Wildfly.
>>     If there is anything else that should be configured, can you
>>     please point me to that configuration option?
>>
>>     Regards,
>>     Christian
>>
>>
>>     Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>     HTTP session replicate is not enabled by default. You need to
>>>     enable it for your application.
>>>
>>>     On 25 January 2016 at 14:39, Christian Beikov
>>>     <christian.beikov at gmail.com> wrote:
>>>
>>>         The documentation states, that the default token-store is
>>>         "session" and as I wrote before, I have setup clustering on
>>>         my Wildfly 10 CR4 like in standalone-ha.xml, so the session
>>>         should already be replicated.
>>>
>>>         Regards,
>>>         Christian
>>>
>>>
>>>         Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>         Your issue doesn't have anything to do with the Keycloak
>>>>         server side user sessions, they don't require sticky sessions.
>>>>
>>>>         Your issue is down to the http session on the adapter side
>>>>         not being replicated by default. For the adapter you've got
>>>>         3 choices: sticky session, replicated session or stateless.
>>>>         Which is best depends on your application.
>>>>
>>>>
>>>>         On 25 January 2016 at 14:05, Christian Beikov
>>>>         <christian.beikov at gmail.com> wrote:
>>>>
>>>>             I don't have a problem with sticky sessions and I will
>>>>             definitively configure them, but I am curious. What is
>>>>             the reason for the problems with round robin in this
>>>>             test scenario? Are the infinispan caches not replicated
>>>>             fast enough or is there an implementation limitation in
>>>>             the adapters?
>>>>
>>>>
>>>>             Regards,
>>>>             Christian
>>>>
>>>>
>>>>             Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>             By default the adapters will require sticky sessions,
>>>>>             please refer to
>>>>>             http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>             for more information
>>>>>
>>>>>             On 22 January 2016 at 12:48, Christian Beikov
>>>>>             <christian.beikov at gmail.com> wrote:
>>>>>
>>>>>                 Hello,
>>>>>
>>>>>                 I am running some tests with my application
>>>>>                 cluster being secured by a
>>>>>                 single keycloak server instance and I encountered
>>>>>                 problems with the adapter.
>>>>>
>>>>>                 My application cluster contains 2 nodes and is
>>>>>                 load balanced by nginx.
>>>>>                 For testing purposes, I enabled round robin load
>>>>>                 balancing which is
>>>>>                 probably the "cause" for my issues.
>>>>>
>>>>>                 When I access a secured page, I get redirected to
>>>>>                 keycloak and
>>>>>                 everything is fine. When I then login, and
>>>>>                 keycloak redirects me back to
>>>>>                 the application, I get to a different application
>>>>>                 cluster node because
>>>>>                 of round robin. On that node, apparently the
>>>>>                 initial information of the
>>>>>                 client session is not available and I get
>>>>>                 redirected to keycloak login
>>>>>                 page again. Then keycloak redirects me back to the
>>>>>                 application, this
>>>>>                 time to the original node, and says that access is
>>>>>                 forbidden.
>>>>>
>>>>>                 I suppose the web session caches are not in sync
>>>>>                 but I just used the
>>>>>                 default cache containers as they are defined in
>>>>>                 standalone-ha.xml of my
>>>>>                 Wildlfy 10 CR4. Clustering with jgroups works, as
>>>>>                 I use other
>>>>>                 distributed caches too which work just fine.
>>>>>
>>>>>                 We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>
>>>>>                 Regards,
>>>>>                 Christian
>>>>>                 _______________________________________________
>>>>>                 keycloak-dev mailing list
>>>>>                 keycloak-dev at lists.jboss.org
>>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From bburke at redhat.com  Mon Jan 25 16:17:19 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 16:17:19 -0500
Subject: [keycloak-dev] tests no longer run within Intellij
Message-ID: <56A690DF.2030106@redhat.com>

Can anybody think of why the tests no longer run within Intellij?

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


From christian.beikov at gmail.com  Mon Jan 25 16:25:44 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Mon, 25 Jan 2016 22:25:44 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A68C7E.4080508@redhat.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com> <56A68C7E.4080508@redhat.com>
Message-ID: <56A692D8.5000107@gmail.com>

By "pretty sure" I mean that replication is working perfectly fine for 
similar cache containers.
The default configuration for the session replication mode in Wildfly 
10  is asynchronous so I guess the reason for my problems is the 
replication lag then.

I will try it out then and let you know for sure, but as far as I 
understand the problem, the only possible solutions are to either 
configure synchronous session replication or asynchronous session 
replication in combination with sticky sessions. Hopefully you can add a 
warning to the user manual so that other users don't run into the same 
problems.


Am 25.01.2016 um 21:58 schrieb Bill Burke:
> What do you mean by you're "pretty sure clustering/session replication 
> is configured correctly".  Either its working or it isn't.   Have you 
> tested a simple application WITHOUT keycloak and with Round Robin to 
> determine if replication is set?    Because from what you are 
> describing and what Stian said to you over and over again is that it 
> does not look like HTTP session replication is working for you.  
> Keycloak client adapter stores that you are authenticated within the 
> HttpSession.  It is possible that session replication is lagging I 
> think...only if you have async replication turned on.  I don't know 
> what the default is in Wildfly 10.
>
> Also, a forbidden exception might mean that your web.xml requires a 
> role set for the user for the URL you are accessing and the user does 
> not have that role assigned to them.
>
> On 1/25/2016 2:33 PM, Christian Beikov wrote:
>> I don't want to be rude but you aren't helping me at all so I'd like 
>> to ask someone else from the team about this. I tried to explain 
>> multiple times that I already configured clustering in my Wildfly 
>> server, thus I configured session replication.
>> Either I don't understand something about session replication or I 
>> require a configuration that you don't mention anywhere.
>> I copied over the cache container from the standalone-ha 
>> configurations and configured the JGroups Subsystem which is what is 
>> described in the official documentation: 
>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>
>> I think I gave you enough information about my situation which you 
>> seemed to ignore completely. I would very much appreciate if I got a 
>> clear answer to my question especially since I am not asking for 
>> general configuration help, but for this special case which to me 
>> seems like a problem/limitation that should be explicitly documented.
>>
>> I am pretty sure clustering/session replication is configured 
>> correctly since I am using a custom cache container with a similar 
>> configuration like the web cache container which I know replicates 
>> correctly. So here comes my question once again, is it possible that 
>> the replication just lags behind which makes the usage of round robin 
>> completely impossible in the login flow? Or is there some kind of 
>> special configuration I have to do which differs from the standard 
>> cluster configuration as provided by the wildfly distribution? Or is 
>> this maybe even an implementation limiation of the server adapter?
>>
>> Regards,
>> Christian
>>
>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>> Try google for wildfly replicate http sessions
>>>
>>> On 25 January 2016 at 15:53, Christian Beikov 
>>> <christian.beikov at gmail.com> wrote:
>>>
>>>     I just wrote that I configured clustering for my application
>>>     just like in the standlone-ha.xml of my Wildfly 10 CR4.
>>>     I configured the jgroups subsystem and the distributed caches
>>>     for web sessions as it is done in standalone-ha.xml of Wildfly.
>>>     If there is anything else that should be configured, can you
>>>     please point me to that configuration option?
>>>
>>>     Regards,
>>>     Christian
>>>
>>>
>>>     Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>>     HTTP session replicate is not enabled by default. You need to
>>>>     enable it for your application.
>>>>
>>>>     On 25 January 2016 at 14:39, Christian Beikov
>>>>     <christian.beikov at gmail.com> wrote:
>>>>
>>>>         The documentation states, that the default token-store is
>>>>         "session" and as I wrote before, I have setup clustering on
>>>>         my Wildfly 10 CR4 like in standalone-ha.xml, so the session
>>>>         should already be replicated.
>>>>
>>>>         Regards,
>>>>         Christian
>>>>
>>>>
>>>>         Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>>         Your issue doesn't have anything to do with the Keycloak
>>>>>         server side user sessions, they don't require sticky
>>>>>         sessions.
>>>>>
>>>>>         Your issue is down to the http session on the adapter side
>>>>>         not being replicated by default. For the adapter you've
>>>>>         got 3 choices: sticky session, replicated session or
>>>>>         stateless. Which is best depends on your application.
>>>>>
>>>>>
>>>>>         On 25 January 2016 at 14:05, Christian Beikov
>>>>>         <christian.beikov at gmail.com> wrote:
>>>>>
>>>>>             I don't have a problem with sticky sessions and I will
>>>>>             definitively configure them, but I am curious. What is
>>>>>             the reason for the problems with round robin in this
>>>>>             test scenario? Are the infinispan caches not
>>>>>             replicated fast enough or is there an implementation
>>>>>             limitation in the adapters?
>>>>>
>>>>>
>>>>>             Regards,
>>>>>             Christian
>>>>>
>>>>>
>>>>>             Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>>             By default the adapters will require sticky sessions,
>>>>>>             please refer to
>>>>>>             http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>>             for more information
>>>>>>
>>>>>>             On 22 January 2016 at 12:48, Christian Beikov
>>>>>>             <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>>                 Hello,
>>>>>>
>>>>>>                 I am running some tests with my application
>>>>>>                 cluster being secured by a
>>>>>>                 single keycloak server instance and I encountered
>>>>>>                 problems with the adapter.
>>>>>>
>>>>>>                 My application cluster contains 2 nodes and is
>>>>>>                 load balanced by nginx.
>>>>>>                 For testing purposes, I enabled round robin load
>>>>>>                 balancing which is
>>>>>>                 probably the "cause" for my issues.
>>>>>>
>>>>>>                 When I access a secured page, I get redirected to
>>>>>>                 keycloak and
>>>>>>                 everything is fine. When I then login, and
>>>>>>                 keycloak redirects me back to
>>>>>>                 the application, I get to a different application
>>>>>>                 cluster node because
>>>>>>                 of round robin. On that node, apparently the
>>>>>>                 initial information of the
>>>>>>                 client session is not available and I get
>>>>>>                 redirected to keycloak login
>>>>>>                 page again. Then keycloak redirects me back to
>>>>>>                 the application, this
>>>>>>                 time to the original node, and says that access
>>>>>>                 is forbidden.
>>>>>>
>>>>>>                 I suppose the web session caches are not in sync
>>>>>>                 but I just used the
>>>>>>                 default cache containers as they are defined in
>>>>>>                 standalone-ha.xml of my
>>>>>>                 Wildlfy 10 CR4. Clustering with jgroups works, as
>>>>>>                 I use other
>>>>>>                 distributed caches too which work just fine.
>>>>>>
>>>>>>                 We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>>
>>>>>>                 Regards,
>>>>>>                 Christian
>>>>>>                 _______________________________________________
>>>>>>                 keycloak-dev mailing list
>>>>>>                 keycloak-dev at lists.jboss.org
>>>>>>                 https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Mon Jan 25 16:51:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 16:51:11 -0500
Subject: [keycloak-dev] tests no longer run within Intellij
In-Reply-To: <56A690DF.2030106@redhat.com>
References: <56A690DF.2030106@redhat.com>
Message-ID: <56A698CF.5060301@redhat.com>

This is messed up...

DefaultKeycloakSessionFactory is only loading SPIs defined in services 
module.  WTF!?

On 1/25/2016 4:17 PM, Bill Burke wrote:
> Can anybody think of why the tests no longer run within Intellij?
>

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


From bburke at redhat.com  Mon Jan 25 16:52:14 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 16:52:14 -0500
Subject: [keycloak-dev] tests no longer run within Intellij
In-Reply-To: <56A698CF.5060301@redhat.com>
References: <56A690DF.2030106@redhat.com> <56A698CF.5060301@redhat.com>
Message-ID: <56A6990E.8090108@redhat.com>

services module and jpa module.  It is ignoring server-spi module. WTF!?

On 1/25/2016 4:51 PM, Bill Burke wrote:
> This is messed up...
>
> DefaultKeycloakSessionFactory is only loading SPIs defined in services
> module.  WTF!?
>
> On 1/25/2016 4:17 PM, Bill Burke wrote:
>> Can anybody think of why the tests no longer run within Intellij?
>>

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


From bburke at redhat.com  Mon Jan 25 16:59:42 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 16:59:42 -0500
Subject: [keycloak-dev] tests no longer run within Intellij
In-Reply-To: <56A6990E.8090108@redhat.com>
References: <56A690DF.2030106@redhat.com> <56A698CF.5060301@redhat.com>
	<56A6990E.8090108@redhat.com>
Message-ID: <56A69ACE.5030508@redhat.com>

Ok, I figured it out, but don't know how to fix it  All 
classes/resources are compiled and copied to <src-root>/target.  
org.keycloak.provider.SPI file is being overwritten.

On 1/25/2016 4:52 PM, Bill Burke wrote:
> services module and jpa module.  It is ignoring server-spi module. WTF!?
>
> On 1/25/2016 4:51 PM, Bill Burke wrote:
>> This is messed up...
>>
>> DefaultKeycloakSessionFactory is only loading SPIs defined in services
>> module.  WTF!?
>>
>> On 1/25/2016 4:17 PM, Bill Burke wrote:
>>> Can anybody think of why the tests no longer run within Intellij?
>>>

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


From bburke at redhat.com  Mon Jan 25 17:14:03 2016
From: bburke at redhat.com (Bill Burke)
Date: Mon, 25 Jan 2016 17:14:03 -0500
Subject: [keycloak-dev] tests no longer run within Intellij
In-Reply-To: <56A69ACE.5030508@redhat.com>
References: <56A690DF.2030106@redhat.com> <56A698CF.5060301@redhat.com>
	<56A6990E.8090108@redhat.com> <56A69ACE.5030508@redhat.com>
Message-ID: <56A69E2B.8000601@redhat.com>

clearing out all .idea and .iml files and reimporting project seemed to 
get it working again.

On 1/25/2016 4:59 PM, Bill Burke wrote:
> Ok, I figured it out, but don't know how to fix it  All
> classes/resources are compiled and copied to <src-root>/target.
> org.keycloak.provider.SPI file is being overwritten.
>
> On 1/25/2016 4:52 PM, Bill Burke wrote:
>> services module and jpa module.  It is ignoring server-spi module. WTF!?
>>
>> On 1/25/2016 4:51 PM, Bill Burke wrote:
>>> This is messed up...
>>>
>>> DefaultKeycloakSessionFactory is only loading SPIs defined in services
>>> module.  WTF!?
>>>
>>> On 1/25/2016 4:17 PM, Bill Burke wrote:
>>>> Can anybody think of why the tests no longer run within Intellij?
>>>>

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


From sthorger at redhat.com  Mon Jan 25 22:41:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Jan 2016 04:41:28 +0100
Subject: [keycloak-dev] Maven Surefire plugin - memory settings for JDK 8
In-Reply-To: <56A68875.40602@redhat.com>
References: <1379731134.17420388.1453752475393.JavaMail.zimbra@redhat.com>
	<789306919.17423801.1453752942218.JavaMail.zimbra@redhat.com>
	<56A68875.40602@redhat.com>
Message-ID: <CAJgngAf_dZ7RLcBVHkqydOqisvpNHXccYhr5udpeY1bhoWn74g@mail.gmail.com>

Memory leak :(
On 25 Jan 2016 21:41, "Bill Burke" <bburke at redhat.com> wrote:

> We tear down and bring up the server a lot and I have noticed the JVM
> thrashing and slowing down the farther you get into the testrun.
> Expanding the heap solved the problem.
>
> On 1/25/2016 3:15 PM, Tomas Kyjovsky wrote:
> >
> > ----- Original Message -----
> >> Hello,
> >>
> >> Looking at global settings for Surefire plugin in keycloak/pom.xml:
> >>
> >>    <artifactId>maven-surefire-plugin</artifactId>
> >>    <configuration>
> >>      <forkMode>once</forkMode>
> >>      <argLine>-Xms512m -Xmx2048m -XX:MaxMetaspaceSize=512m</argLine>
> > Sorry, I pasted my local surefire test config by mistake. The original
> configuration in master is:
> >
> >       <argLine>-Xms512m -Xmx2048m -XX:MaxPermSize=1024m</argLine>
> >
> >
> >>    </configuration>
> >>
> >>
> >> 1) The heap space settings seems quite high. Is there some reason for 2g
> >> heap? If not, can we lower it say to 1g?
> >>
> >> 2) In JDK 8 permspace was replaced by metaspace which we might want to
> limit
> >> instead.
> >>
> >>
> >> Tomas
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/852d2e7b/attachment.html 

From sthorger at redhat.com  Tue Jan 26 02:44:25 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Jan 2016 08:44:25 +0100
Subject: [keycloak-dev] Should we allow response_type=token ?
In-Reply-To: <56A68B6B.3010002@redhat.com>
References: <56A68B6B.3010002@redhat.com>
Message-ID: <CAJgngAeYQ8nF0M+DKFr0_=-HsQKit1Fc-UZLKOw7tWgBNaMNZw@mail.gmail.com>

If OpenID Connect prevents response_type=token, then no. We should be
OpenID Connect compliant.

Just add this to the issue and close it as rejected.

On 25 January 2016 at 21:54, Marek Posolda <mposolda at redhat.com> wrote:

> Question about https://issues.jboss.org/browse/KEYCLOAK-2351 . Should we
> allow response_type=token ?
>
> Basically OAuth2 allows that [1] but OpenID Connect doesn't for implicit
> nor hybrid flow to use response_type=token alone without "id_token" or
> "code" [2] [3] .
>
> I am fine with support response_type=token, however doesn't we break
> OpenID Connect specs then? Or should we have option (either on/off flag
> or list of valid response_type combinations) in configuration to specify
> whether it's allowed or not?
>
> [1] https://tools.ietf.org/html/rfc6749#section-4.2.1
> [2]
> http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
> [3] http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest
>
> Marek
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/f2977598/attachment.html 

From sthorger at redhat.com  Tue Jan 26 02:49:28 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Jan 2016 08:49:28 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A6788E.5030408@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
Message-ID: <CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>

I don't see the need for this mail. I was actually trying to help you. I
doubt you've even looked at what I've suggested though.

As Bill points out get your HTTP session replication working first. It has
nothing to do with Keycloak. If you want non-sticky sessions and not using
the stateless option then you need that working. The reason why I told you
to google it is that you do actually have to enable HTTP session
replication on a per-war basis. It's not just a container config. The
standalone-ha.xml config in WildFly should be fine by default, so you don't
need to do anything there.

On 25 January 2016 at 20:33, Christian Beikov <christian.beikov at gmail.com>
wrote:

> I don't want to be rude but you aren't helping me at all so I'd like to
> ask someone else from the team about this. I tried to explain multiple
> times that I already configured clustering in my Wildfly server, thus I
> configured session replication.
> Either I don't understand something about session replication or I require
> a configuration that you don't mention anywhere.
> I copied over the cache container from the standalone-ha configurations
> and configured the JGroups Subsystem which is what is described in the
> official documentation:
> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>
> I think I gave you enough information about my situation which you seemed
> to ignore completely. I would very much appreciate if I got a clear answer
> to my question especially since I am not asking for general configuration
> help, but for this special case which to me seems like a problem/limitation
> that should be explicitly documented.
>
> I am pretty sure clustering/session replication is configured correctly
> since I am using a custom cache container with a similar configuration like
> the web cache container which I know replicates correctly. So here comes my
> question once again, is it possible that the replication just lags behind
> which makes the usage of round robin completely impossible in the login
> flow? Or is there some kind of special configuration I have to do which
> differs from the standard cluster configuration as provided by the wildfly
> distribution? Or is this maybe even an implementation limiation of the
> server adapter?
>
> Regards,
> Christian
>
>
> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>
> Try google for wildfly replicate http sessions
>
> On 25 January 2016 at 15:53, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>
>> I just wrote that I configured clustering for my application just like in
>> the standlone-ha.xml of my Wildfly 10 CR4.
>> I configured the jgroups subsystem and the distributed caches for web
>> sessions as it is done in standalone-ha.xml of Wildfly.
>> If there is anything else that should be configured, can you please point
>> me to that configuration option?
>>
>> Regards,
>> Christian
>>
>>
>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>
>> HTTP session replicate is not enabled by default. You need to enable it
>> for your application.
>>
>> On 25 January 2016 at 14:39, Christian Beikov <
>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>
>>> The documentation states, that the default token-store is "session" and
>>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in
>>> standalone-ha.xml, so the session should already be replicated.
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>
>>> Your issue doesn't have anything to do with the Keycloak server side
>>> user sessions, they don't require sticky sessions.
>>>
>>> Your issue is down to the http session on the adapter side not being
>>> replicated by default. For the adapter you've got 3 choices: sticky
>>> session, replicated session or stateless. Which is best depends on your
>>> application.
>>>
>>>
>>> On 25 January 2016 at 14:05, Christian Beikov <
>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>
>>>> I don't have a problem with sticky sessions and I will definitively
>>>> configure them, but I am curious. What is the reason for the problems with
>>>> round robin in this test scenario? Are the infinispan caches not replicated
>>>> fast enough or is there an implementation limitation in the adapters?
>>>>
>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>
>>>> By default the adapters will require sticky sessions, please refer to
>>>> <http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html>
>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>> for more information
>>>>
>>>> On 22 January 2016 at 12:48, Christian Beikov <
>>>> <christian.beikov at gmail.com>christian.beikov at gmail.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I am running some tests with my application cluster being secured by a
>>>>> single keycloak server instance and I encountered problems with the
>>>>> adapter.
>>>>>
>>>>> My application cluster contains 2 nodes and is load balanced by nginx.
>>>>> For testing purposes, I enabled round robin load balancing which is
>>>>> probably the "cause" for my issues.
>>>>>
>>>>> When I access a secured page, I get redirected to keycloak and
>>>>> everything is fine. When I then login, and keycloak redirects me back
>>>>> to
>>>>> the application, I get to a different application cluster node because
>>>>> of round robin. On that node, apparently the initial information of the
>>>>> client session is not available and I get redirected to keycloak login
>>>>> page again. Then keycloak redirects me back to the application, this
>>>>> time to the original node, and says that access is forbidden.
>>>>>
>>>>> I suppose the web session caches are not in sync but I just used the
>>>>> default cache containers as they are defined in standalone-ha.xml of my
>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>>>> distributed caches too which work just fine.
>>>>>
>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> <keycloak-dev at lists.jboss.org>keycloak-dev at lists.jboss.org
>>>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/c36f1f03/attachment-0001.html 

From christian.beikov at gmail.com  Tue Jan 26 06:55:23 2016
From: christian.beikov at gmail.com (Christian Beikov)
Date: Tue, 26 Jan 2016 12:55:23 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
	<CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
Message-ID: <56A75EAB.8090401@gmail.com>

I am really sorry about the last mail, I just felt that my suggestions 
about a possible problem were ignored, especially since you just 
suggested to google it.

In the end I found out that I was missing the <distributable/> tag in my 
web.xml to enable session replication properly. So you(Stian) were right 
after all. I didn't quite get the hint that "need to enable it for your 
application" actually meant that I had to change the web.xml.

Could you maybe put a warning into the documentation?

Sorry for the noise again.

Regards,
Christian

Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
> I don't see the need for this mail. I was actually trying to help you. 
> I doubt you've even looked at what I've suggested though.
>
> As Bill points out get your HTTP session replication working first. It 
> has nothing to do with Keycloak. If you want non-sticky sessions and 
> not using the stateless option then you need that working. The reason 
> why I told you to google it is that you do actually have to enable 
> HTTP session replication on a per-war basis. It's not just a container 
> config. The standalone-ha.xml config in WildFly should be fine by 
> default, so you don't need to do anything there.
>
> On 25 January 2016 at 20:33, Christian Beikov 
> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>
>     I don't want to be rude but you aren't helping me at all so I'd
>     like to ask someone else from the team about this. I tried to
>     explain multiple times that I already configured clustering in my
>     Wildfly server, thus I configured session replication.
>     Either I don't understand something about session replication or I
>     require a configuration that you don't mention anywhere.
>     I copied over the cache container from the standalone-ha
>     configurations and configured the JGroups Subsystem which is what
>     is described in the official documentation:
>     https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>
>     I think I gave you enough information about my situation which you
>     seemed to ignore completely. I would very much appreciate if I got
>     a clear answer to my question especially since I am not asking for
>     general configuration help, but for this special case which to me
>     seems like a problem/limitation that should be explicitly documented.
>
>     I am pretty sure clustering/session replication is configured
>     correctly since I am using a custom cache container with a similar
>     configuration like the web cache container which I know replicates
>     correctly. So here comes my question once again, is it possible
>     that the replication just lags behind which makes the usage of
>     round robin completely impossible in the login flow? Or is there
>     some kind of special configuration I have to do which differs from
>     the standard cluster configuration as provided by the wildfly
>     distribution? Or is this maybe even an implementation limiation of
>     the server adapter?
>
>     Regards,
>     Christian
>
>
>     Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>     Try google for wildfly replicate http sessions
>>
>>     On 25 January 2016 at 15:53, Christian Beikov
>>     <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>>
>>     wrote:
>>
>>         I just wrote that I configured clustering for my application
>>         just like in the standlone-ha.xml of my Wildfly 10 CR4.
>>         I configured the jgroups subsystem and the distributed caches
>>         for web sessions as it is done in standalone-ha.xml of Wildfly.
>>         If there is anything else that should be configured, can you
>>         please point me to that configuration option?
>>
>>         Regards,
>>         Christian
>>
>>
>>         Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>         HTTP session replicate is not enabled by default. You need
>>>         to enable it for your application.
>>>
>>>         On 25 January 2016 at 14:39, Christian Beikov
>>>         <christian.beikov at gmail.com
>>>         <mailto:christian.beikov at gmail.com>> wrote:
>>>
>>>             The documentation states, that the default token-store
>>>             is "session" and as I wrote before, I have setup
>>>             clustering on my Wildfly 10 CR4 like in
>>>             standalone-ha.xml, so the session should already be
>>>             replicated.
>>>
>>>             Regards,
>>>             Christian
>>>
>>>
>>>             Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>             Your issue doesn't have anything to do with the
>>>>             Keycloak server side user sessions, they don't require
>>>>             sticky sessions.
>>>>
>>>>             Your issue is down to the http session on the adapter
>>>>             side not being replicated by default. For the adapter
>>>>             you've got 3 choices: sticky session, replicated
>>>>             session or stateless. Which is best depends on your
>>>>             application.
>>>>
>>>>
>>>>             On 25 January 2016 at 14:05, Christian Beikov
>>>>             <christian.beikov at gmail.com
>>>>             <mailto:christian.beikov at gmail.com>> wrote:
>>>>
>>>>                 I don't have a problem with sticky sessions and I
>>>>                 will definitively configure them, but I am curious.
>>>>                 What is the reason for the problems with round
>>>>                 robin in this test scenario? Are the infinispan
>>>>                 caches not replicated fast enough or is there an
>>>>                 implementation limitation in the adapters?
>>>>
>>>>
>>>>                 Regards,
>>>>                 Christian
>>>>
>>>>
>>>>                 Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>                 By default the adapters will require sticky
>>>>>                 sessions, please refer to
>>>>>                 http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>                 for more information
>>>>>
>>>>>                 On 22 January 2016 at 12:48, Christian Beikov
>>>>>                 <christian.beikov at gmail.com
>>>>>                 <mailto:christian.beikov at gmail.com>> wrote:
>>>>>
>>>>>                     Hello,
>>>>>
>>>>>                     I am running some tests with my application
>>>>>                     cluster being secured by a
>>>>>                     single keycloak server instance and I
>>>>>                     encountered problems with the adapter.
>>>>>
>>>>>                     My application cluster contains 2 nodes and is
>>>>>                     load balanced by nginx.
>>>>>                     For testing purposes, I enabled round robin
>>>>>                     load balancing which is
>>>>>                     probably the "cause" for my issues.
>>>>>
>>>>>                     When I access a secured page, I get redirected
>>>>>                     to keycloak and
>>>>>                     everything is fine. When I then login, and
>>>>>                     keycloak redirects me back to
>>>>>                     the application, I get to a different
>>>>>                     application cluster node because
>>>>>                     of round robin. On that node, apparently the
>>>>>                     initial information of the
>>>>>                     client session is not available and I get
>>>>>                     redirected to keycloak login
>>>>>                     page again. Then keycloak redirects me back to
>>>>>                     the application, this
>>>>>                     time to the original node, and says that
>>>>>                     access is forbidden.
>>>>>
>>>>>                     I suppose the web session caches are not in
>>>>>                     sync but I just used the
>>>>>                     default cache containers as they are defined
>>>>>                     in standalone-ha.xml of my
>>>>>                     Wildlfy 10 CR4. Clustering with jgroups works,
>>>>>                     as I use other
>>>>>                     distributed caches too which work just fine.
>>>>>
>>>>>                     We are using Keycloak 1.8.0.CR2 on a Wildfly
>>>>>                     10 CR4
>>>>>
>>>>>                     Regards,
>>>>>                     Christian
>>>>>                     _______________________________________________
>>>>>                     keycloak-dev mailing list
>>>>>                     keycloak-dev at lists.jboss.org
>>>>>                     <mailto:keycloak-dev at lists.jboss.org>
>>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

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

From mposolda at redhat.com  Tue Jan 26 07:16:17 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Jan 2016 13:16:17 +0100
Subject: [keycloak-dev] Should we allow response_type=token ?
In-Reply-To: <CAJgngAeYQ8nF0M+DKFr0_=-HsQKit1Fc-UZLKOw7tWgBNaMNZw@mail.gmail.com>
References: <56A68B6B.3010002@redhat.com>
	<CAJgngAeYQ8nF0M+DKFr0_=-HsQKit1Fc-UZLKOw7tWgBNaMNZw@mail.gmail.com>
Message-ID: <56A76391.8040104@redhat.com>

I did a bit more research regarding this. OpenID Connect doesn't 
explicitly prevent that "response_type=token" must not be used. There is 
just this sentence in the specs:
NOTE: While OAuth 2.0 also defines the token Response Type value for the 
Implicit Flow, OpenID Connect does not use this Response Type, since no 
ID Token would be returned.

So to be compliant with pure OAuth 2 clients (like swagger.ui) , which 
don't know about "id_token" response_type, I actually suggest to support 
response_type=token for clients with enabled implicit flow. I've sent PR 
for this https://github.com/keycloak/keycloak/pull/2110 . Let me know if 
you think that we shouldn't merge it.

Marek

On 26/01/16 08:44, Stian Thorgersen wrote:
> If OpenID Connect prevents response_type=token, then no. We should be 
> OpenID Connect compliant.
>
> Just add this to the issue and close it as rejected.
>
> On 25 January 2016 at 21:54, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Question about https://issues.jboss.org/browse/KEYCLOAK-2351 .
>     Should we
>     allow response_type=token ?
>
>     Basically OAuth2 allows that [1] but OpenID Connect doesn't for
>     implicit
>     nor hybrid flow to use response_type=token alone without "id_token" or
>     "code" [2] [3] .
>
>     I am fine with support response_type=token, however doesn't we break
>     OpenID Connect specs then? Or should we have option (either on/off
>     flag
>     or list of valid response_type combinations) in configuration to
>     specify
>     whether it's allowed or not?
>
>     [1] https://tools.ietf.org/html/rfc6749#section-4.2.1
>     [2]
>     http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
>     [3]
>     http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest
>
>     Marek
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From sthorger at redhat.com  Tue Jan 26 07:25:27 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 26 Jan 2016 13:25:27 +0100
Subject: [keycloak-dev] Should we allow response_type=token ?
In-Reply-To: <56A76391.8040104@redhat.com>
References: <56A68B6B.3010002@redhat.com>
	<CAJgngAeYQ8nF0M+DKFr0_=-HsQKit1Fc-UZLKOw7tWgBNaMNZw@mail.gmail.com>
	<56A76391.8040104@redhat.com>
Message-ID: <CAJgngAcTbANu0n6-O2qOVVFTJGi=a=2kJRg5DbmVV30E8S4h7Q@mail.gmail.com>

I'm happy with that, let's merge it

On 26 January 2016 at 13:16, Marek Posolda <mposolda at redhat.com> wrote:

> I did a bit more research regarding this. OpenID Connect doesn't
> explicitly prevent that "response_type=token" must not be used. There is
> just this sentence in the specs:
> NOTE: While OAuth 2.0 also defines the token Response Type value for the
> Implicit Flow, OpenID Connect does not use this Response Type, since no ID
> Token would be returned.
>
> So to be compliant with pure OAuth 2 clients (like swagger.ui) , which
> don't know about "id_token" response_type, I actually suggest to support
> response_type=token for clients with enabled implicit flow. I've sent PR
> for this https://github.com/keycloak/keycloak/pull/2110 . Let me know if
> you think that we shouldn't merge it.
>
> Marek
>
>
> On 26/01/16 08:44, Stian Thorgersen wrote:
>
> If OpenID Connect prevents response_type=token, then no. We should be
> OpenID Connect compliant.
>
> Just add this to the issue and close it as rejected.
>
> On 25 January 2016 at 21:54, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Question about https://issues.jboss.org/browse/KEYCLOAK-2351 . Should we
>> allow response_type=token ?
>>
>> Basically OAuth2 allows that [1] but OpenID Connect doesn't for implicit
>> nor hybrid flow to use response_type=token alone without "id_token" or
>> "code" [2] [3] .
>>
>> I am fine with support response_type=token, however doesn't we break
>> OpenID Connect specs then? Or should we have option (either on/off flag
>> or list of valid response_type combinations) in configuration to specify
>> whether it's allowed or not?
>>
>> [1] https://tools.ietf.org/html/rfc6749#section-4.2.1
>> [2]
>> http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest
>> [3]
>> http://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest
>>
>> Marek
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/f0e406d5/attachment.html 

From mposolda at redhat.com  Tue Jan 26 11:36:29 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Jan 2016 17:36:29 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A75EAB.8090401@gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
	<CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
	<56A75EAB.8090401@gmail.com>
Message-ID: <56A7A08D.3030005@redhat.com>

Hi,

I've put some small note at the first paragraph of "Application 
clustering" chapter. Just a small note really, as setup of 
"distributable" in web.xml or configuration of infinispan are app. 
server specific steps and they are general to HttpSession replication 
and clustering, it's not Keycloak specific stuff.

Marek

On 26/01/16 12:55, Christian Beikov wrote:
> I am really sorry about the last mail, I just felt that my suggestions 
> about a possible problem were ignored, especially since you just 
> suggested to google it.
>
> In the end I found out that I was missing the <distributable/> tag in 
> my web.xml to enable session replication properly. So you(Stian) were 
> right after all. I didn't quite get the hint that "need to enable it 
> for your application" actually meant that I had to change the web.xml.
>
> Could you maybe put a warning into the documentation?
>
> Sorry for the noise again.
>
> Regards,
> Christian
>
> Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
>> I don't see the need for this mail. I was actually trying to help 
>> you. I doubt you've even looked at what I've suggested though.
>>
>> As Bill points out get your HTTP session replication working first. 
>> It has nothing to do with Keycloak. If you want non-sticky sessions 
>> and not using the stateless option then you need that working. The 
>> reason why I told you to google it is that you do actually have to 
>> enable HTTP session replication on a per-war basis. It's not just a 
>> container config. The standalone-ha.xml config in WildFly should be 
>> fine by default, so you don't need to do anything there.
>>
>> On 25 January 2016 at 20:33, Christian Beikov 
>> <christian.beikov at gmail.com <mailto:christian.beikov at gmail.com>> wrote:
>>
>>     I don't want to be rude but you aren't helping me at all so I'd
>>     like to ask someone else from the team about this. I tried to
>>     explain multiple times that I already configured clustering in my
>>     Wildfly server, thus I configured session replication.
>>     Either I don't understand something about session replication or
>>     I require a configuration that you don't mention anywhere.
>>     I copied over the cache container from the standalone-ha
>>     configurations and configured the JGroups Subsystem which is what
>>     is described in the official documentation:
>>     https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>
>>     I think I gave you enough information about my situation which
>>     you seemed to ignore completely. I would very much appreciate if
>>     I got a clear answer to my question especially since I am not
>>     asking for general configuration help, but for this special case
>>     which to me seems like a problem/limitation that should be
>>     explicitly documented.
>>
>>     I am pretty sure clustering/session replication is configured
>>     correctly since I am using a custom cache container with a
>>     similar configuration like the web cache container which I know
>>     replicates correctly. So here comes my question once again, is it
>>     possible that the replication just lags behind which makes the
>>     usage of round robin completely impossible in the login flow? Or
>>     is there some kind of special configuration I have to do which
>>     differs from the standard cluster configuration as provided by
>>     the wildfly distribution? Or is this maybe even an implementation
>>     limiation of the server adapter?
>>
>>     Regards,
>>     Christian
>>
>>
>>     Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>>     Try google for wildfly replicate http sessions
>>>
>>>     On 25 January 2016 at 15:53, Christian Beikov
>>>     <christian.beikov at gmail.com> wrote:
>>>
>>>         I just wrote that I configured clustering for my application
>>>         just like in the standlone-ha.xml of my Wildfly 10 CR4.
>>>         I configured the jgroups subsystem and the distributed
>>>         caches for web sessions as it is done in standalone-ha.xml
>>>         of Wildfly.
>>>         If there is anything else that should be configured, can you
>>>         please point me to that configuration option?
>>>
>>>         Regards,
>>>         Christian
>>>
>>>
>>>         Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>>         HTTP session replicate is not enabled by default. You need
>>>>         to enable it for your application.
>>>>
>>>>         On 25 January 2016 at 14:39, Christian Beikov
>>>>         <christian.beikov at gmail.com> wrote:
>>>>
>>>>             The documentation states, that the default token-store
>>>>             is "session" and as I wrote before, I have setup
>>>>             clustering on my Wildfly 10 CR4 like in
>>>>             standalone-ha.xml, so the session should already be
>>>>             replicated.
>>>>
>>>>             Regards,
>>>>             Christian
>>>>
>>>>
>>>>             Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>>             Your issue doesn't have anything to do with the
>>>>>             Keycloak server side user sessions, they don't require
>>>>>             sticky sessions.
>>>>>
>>>>>             Your issue is down to the http session on the adapter
>>>>>             side not being replicated by default. For the adapter
>>>>>             you've got 3 choices: sticky session, replicated
>>>>>             session or stateless. Which is best depends on your
>>>>>             application.
>>>>>
>>>>>
>>>>>             On 25 January 2016 at 14:05, Christian Beikov
>>>>>             <christian.beikov at gmail.com> wrote:
>>>>>
>>>>>                 I don't have a problem with sticky sessions and I
>>>>>                 will definitively configure them, but I am
>>>>>                 curious. What is the reason for the problems with
>>>>>                 round robin in this test scenario? Are the
>>>>>                 infinispan caches not replicated fast enough or is
>>>>>                 there an implementation limitation in the adapters?
>>>>>
>>>>>
>>>>>                 Regards,
>>>>>                 Christian
>>>>>
>>>>>
>>>>>                 Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>>                 By default the adapters will require sticky
>>>>>>                 sessions, please refer to
>>>>>>                 http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>>                 for more information
>>>>>>
>>>>>>                 On 22 January 2016 at 12:48, Christian Beikov
>>>>>>                 <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>>                     Hello,
>>>>>>
>>>>>>                     I am running some tests with my application
>>>>>>                     cluster being secured by a
>>>>>>                     single keycloak server instance and I
>>>>>>                     encountered problems with the adapter.
>>>>>>
>>>>>>                     My application cluster contains 2 nodes and
>>>>>>                     is load balanced by nginx.
>>>>>>                     For testing purposes, I enabled round robin
>>>>>>                     load balancing which is
>>>>>>                     probably the "cause" for my issues.
>>>>>>
>>>>>>                     When I access a secured page, I get
>>>>>>                     redirected to keycloak and
>>>>>>                     everything is fine. When I then login, and
>>>>>>                     keycloak redirects me back to
>>>>>>                     the application, I get to a different
>>>>>>                     application cluster node because
>>>>>>                     of round robin. On that node, apparently the
>>>>>>                     initial information of the
>>>>>>                     client session is not available and I get
>>>>>>                     redirected to keycloak login
>>>>>>                     page again. Then keycloak redirects me back
>>>>>>                     to the application, this
>>>>>>                     time to the original node, and says that
>>>>>>                     access is forbidden.
>>>>>>
>>>>>>                     I suppose the web session caches are not in
>>>>>>                     sync but I just used the
>>>>>>                     default cache containers as they are defined
>>>>>>                     in standalone-ha.xml of my
>>>>>>                     Wildlfy 10 CR4. Clustering with jgroups
>>>>>>                     works, as I use other
>>>>>>                     distributed caches too which work just fine.
>>>>>>
>>>>>>                     We are using Keycloak 1.8.0.CR2 on a Wildfly
>>>>>>                     10 CR4
>>>>>>
>>>>>>                     Regards,
>>>>>>                     Christian
>>>>>>                     _______________________________________________
>>>>>>                     keycloak-dev mailing list
>>>>>>                     keycloak-dev at lists.jboss.org
>>>>>>                     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From mstrukel at redhat.com  Tue Jan 26 12:10:17 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 26 Jan 2016 18:10:17 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A7A08D.3030005@redhat.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
	<CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
	<56A75EAB.8090401@gmail.com> <56A7A08D.3030005@redhat.com>
Message-ID: <CA+1OW+jqMHztxOFAopD3-LtbOSZkwRsBrGNtWAmne3AQw2NnPA@mail.gmail.com>

Maybe we should assume that people forget that stuff, and some don't
know it in the first place, and simply try to give all the info
necessary even for novice java developer to be successful setting it
all up.

On Tue, Jan 26, 2016 at 5:36 PM, Marek Posolda <mposolda at redhat.com> wrote:
> Hi,
>
> I've put some small note at the first paragraph of "Application clustering"
> chapter. Just a small note really, as setup of "distributable" in web.xml or
> configuration of infinispan are app. server specific steps and they are
> general to HttpSession replication and clustering, it's not Keycloak
> specific stuff.
>
> Marek
>
>
> On 26/01/16 12:55, Christian Beikov wrote:
>
> I am really sorry about the last mail, I just felt that my suggestions about
> a possible problem were ignored, especially since you just suggested to
> google it.
>
> In the end I found out that I was missing the  <distributable/> tag in my
> web.xml to enable session replication properly. So you(Stian) were right
> after all. I didn't quite get the hint that "need to enable it for your
> application" actually meant that I had to change the web.xml.
>
> Could you maybe put a warning into the documentation?
>
> Sorry for the noise again.
>
> Regards,
> Christian
>
> Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
>
> I don't see the need for this mail. I was actually trying to help you. I
> doubt you've even looked at what I've suggested though.
>
> As Bill points out get your HTTP session replication working first. It has
> nothing to do with Keycloak. If you want non-sticky sessions and not using
> the stateless option then you need that working. The reason why I told you
> to google it is that you do actually have to enable HTTP session replication
> on a per-war basis. It's not just a container config. The standalone-ha.xml
> config in WildFly should be fine by default, so you don't need to do
> anything there.
>
> On 25 January 2016 at 20:33, Christian Beikov <christian.beikov at gmail.com>
> wrote:
>>
>> I don't want to be rude but you aren't helping me at all so I'd like to
>> ask someone else from the team about this. I tried to explain multiple times
>> that I already configured clustering in my Wildfly server, thus I configured
>> session replication.
>> Either I don't understand something about session replication or I require
>> a configuration that you don't mention anywhere.
>> I copied over the cache container from the standalone-ha configurations
>> and configured the JGroups Subsystem which is what is described in the
>> official documentation:
>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>
>> I think I gave you enough information about my situation which you seemed
>> to ignore completely. I would very much appreciate if I got a clear answer
>> to my question especially since I am not asking for general configuration
>> help, but for this special case which to me seems like a problem/limitation
>> that should be explicitly documented.
>>
>> I am pretty sure clustering/session replication is configured correctly
>> since I am using a custom cache container with a similar configuration like
>> the web cache container which I know replicates correctly. So here comes my
>> question once again, is it possible that the replication just lags behind
>> which makes the usage of round robin completely impossible in the login
>> flow? Or is there some kind of special configuration I have to do which
>> differs from the standard cluster configuration as provided by the wildfly
>> distribution? Or is this maybe even an implementation limiation of the
>> server adapter?
>>
>> Regards,
>> Christian
>>
>>
>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>
>> Try google for wildfly replicate http sessions
>>
>> On 25 January 2016 at 15:53, Christian Beikov <christian.beikov at gmail.com>
>> wrote:
>>>
>>> I just wrote that I configured clustering for my application just like in
>>> the standlone-ha.xml of my Wildfly 10 CR4.
>>> I configured the jgroups subsystem and the distributed caches for web
>>> sessions as it is done in standalone-ha.xml of Wildfly.
>>> If there is anything else that should be configured, can you please point
>>> me to that configuration option?
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>
>>> HTTP session replicate is not enabled by default. You need to enable it
>>> for your application.
>>>
>>> On 25 January 2016 at 14:39, Christian Beikov
>>> <christian.beikov at gmail.com> wrote:
>>>>
>>>> The documentation states, that the default token-store is "session" and
>>>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in
>>>> standalone-ha.xml, so the session should already be replicated.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>
>>>> Your issue doesn't have anything to do with the Keycloak server side
>>>> user sessions, they don't require sticky sessions.
>>>>
>>>> Your issue is down to the http session on the adapter side not being
>>>> replicated by default. For the adapter you've got 3 choices: sticky session,
>>>> replicated session or stateless. Which is best depends on your application.
>>>>
>>>>
>>>> On 25 January 2016 at 14:05, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>>
>>>>> I don't have a problem with sticky sessions and I will definitively
>>>>> configure them, but I am curious. What is the reason for the problems with
>>>>> round robin in this test scenario? Are the infinispan caches not replicated
>>>>> fast enough or is there an implementation limitation in the adapters?
>>>>>
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>
>>>>> By default the adapters will require sticky sessions, please refer to
>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>> for more information
>>>>>
>>>>> On 22 January 2016 at 12:48, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I am running some tests with my application cluster being secured by a
>>>>>> single keycloak server instance and I encountered problems with the
>>>>>> adapter.
>>>>>>
>>>>>> My application cluster contains 2 nodes and is load balanced by nginx.
>>>>>> For testing purposes, I enabled round robin load balancing which is
>>>>>> probably the "cause" for my issues.
>>>>>>
>>>>>> When I access a secured page, I get redirected to keycloak and
>>>>>> everything is fine. When I then login, and keycloak redirects me back
>>>>>> to
>>>>>> the application, I get to a different application cluster node because
>>>>>> of round robin. On that node, apparently the initial information of
>>>>>> the
>>>>>> client session is not available and I get redirected to keycloak login
>>>>>> page again. Then keycloak redirects me back to the application, this
>>>>>> time to the original node, and says that access is forbidden.
>>>>>>
>>>>>> I suppose the web session caches are not in sync but I just used the
>>>>>> default cache containers as they are defined in standalone-ha.xml of
>>>>>> my
>>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>>>>> distributed caches too which work just fine.
>>>>>>
>>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>> _______________________________________________
>>>>>> 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 alexgv99 at gmail.com  Tue Jan 26 14:16:11 2016
From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=)
Date: Tue, 26 Jan 2016 17:16:11 -0200
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
Message-ID: <CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>

Hi guys. I'm running into some trouble here...

I have a very simple application which should authenticate against keycloak
and return to the main page. This is triggered through the web.xml in my
application.

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

<module-name>teste</module-name>

<filter>
<filter-name>CORSFilter</filter-name>
<filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CORSFilter</filter-name>
<url-pattern>/rest/*</url-pattern>
</filter-mapping>

<distributable />

<security-constraint>
<web-resource-collection>
<web-resource-name>teste</web-resource-name>
<url-pattern>/rest/exemploService/secure/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>realmtest</realm-name>
</login-config>
<security-role>
<role-name>user</role-name>
</security-role>
<security-role>
<role-name>admin</role-name>
</security-role>

</web-app>


The server side has a REST API and the client side is an angular
application. Everything very simple to just try the development
environment. What happens is that, after filling the login page and return
to the index.html (actually it's not returning), I receive a 400 BAD
REQUEST for the uri:

http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1


It seems to me, that the malformed URI is because of the ?code=... If I
reload the page with the same URL, it just return the same 400... if I
remove the ? portion, it reloads the page and again redirects to and from
the keycloak server, and recovers the ? portion, repeating the same 400.

I'm running everything in the same application under wildfly 10. Both the
server and client sides in the same deployed WAR.

I'd appreciate any help.

Best regards.

Alex Gouvea Vasconcelos







[image: Imagem inline 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/52dfedb1/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak.png
Type: image/png
Size: 248184 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160126/52dfedb1/attachment-0001.png 

From bburke at redhat.com  Tue Jan 26 14:45:31 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 26 Jan 2016 14:45:31 -0500
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
Message-ID: <56A7CCDB.7000801@redhat.com>

Do you can an exception stacktrace on app or auth server?

On 1/26/2016 2:16 PM, Alex Gouv?a Vasconcelos wrote:
> Hi guys. I'm running into some trouble here...
>
> I have a very simple application which should authenticate against 
> keycloak and return to the main page. This is triggered through the 
> web.xml in my application.
>
>     <web-app xmlns="http://java.sun.com/xml/ns/javaee"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
>     http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
>     version="3.0">
>
>     <module-name>teste</module-name>
>
>     <filter>
>     <filter-name>CORSFilter</filter-name>
>     <filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
>     </filter>
>     <filter-mapping>
>     <filter-name>CORSFilter</filter-name>
>     <url-pattern>/rest/*</url-pattern>
>     </filter-mapping>
>
>     <distributable />
>
>     <security-constraint>
>     <web-resource-collection>
>     <web-resource-name>teste</web-resource-name>
>     <url-pattern>/rest/exemploService/secure/*</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>     <role-name>*</role-name>
>     </auth-constraint>
>     <user-data-constraint>
>     <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>     </user-data-constraint>
>     </security-constraint>
>
>     <login-config>
>     <auth-method>KEYCLOAK</auth-method>
>     <realm-name>realmtest</realm-name>
>     </login-config>
>     <security-role>
>     <role-name>user</role-name>
>     </security-role>
>     <security-role>
>     <role-name>admin</role-name>
>     </security-role>
>
>     </web-app>
>
>
> The server side has a REST API and the client side is an angular 
> application. Everything very simple to just try the development 
> environment. What happens is that, after filling the login page and 
> return to the index.html (actually it's not returning), I receive a 
> 400 BAD REQUEST for the uri:
>
>     http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1
>
>
> It seems to me, that the malformed URI is because of the ?code=... If 
> I reload the page with the same URL, it just return the same 400... if 
> I remove the ? portion, it reloads the page and again redirects to and 
> from the keycloak server, and recovers the ? portion, repeating the 
> same 400.
>
> I'm running everything in the same application under wildfly 10. Both 
> the server and client sides in the same deployed WAR.
>
> I'd appreciate any help.
>
> Best regards.
>
> Alex Gouvea Vasconcelos
>
>
>
>
>
>
>
> Imagem inline 1
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From mposolda at redhat.com  Tue Jan 26 16:05:09 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 26 Jan 2016 22:05:09 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <CA+1OW+jqMHztxOFAopD3-LtbOSZkwRsBrGNtWAmne3AQw2NnPA@mail.gmail.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
	<CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
	<56A75EAB.8090401@gmail.com> <56A7A08D.3030005@redhat.com>
	<CA+1OW+jqMHztxOFAopD3-LtbOSZkwRsBrGNtWAmne3AQw2NnPA@mail.gmail.com>
Message-ID: <56A7DF85.50506@redhat.com>

Yeah. The question is where is the exactly is the "border" to provide 
some hints, but not duplicate the info, which is not directly related to 
Keycloak.

For application clustering, it's tricky as we support bunch of servers 
for adapter clustering. And each of them has some differences for 
cluster setup (and different infinispan version). So I've just added the 
note about <distributable /> in web.xml and the obligatory sentence "For 
more details look at your app server documentation" :-)

Hope this will be sufficient for most of the cases.

Marek

On 26/01/16 18:10, Marko Strukelj wrote:
> Maybe we should assume that people forget that stuff, and some don't
> know it in the first place, and simply try to give all the info
> necessary even for novice java developer to be successful setting it
> all up.
>
> On Tue, Jan 26, 2016 at 5:36 PM, Marek Posolda <mposolda at redhat.com> wrote:
>> Hi,
>>
>> I've put some small note at the first paragraph of "Application clustering"
>> chapter. Just a small note really, as setup of "distributable" in web.xml or
>> configuration of infinispan are app. server specific steps and they are
>> general to HttpSession replication and clustering, it's not Keycloak
>> specific stuff.
>>
>> Marek
>>
>>
>> On 26/01/16 12:55, Christian Beikov wrote:
>>
>> I am really sorry about the last mail, I just felt that my suggestions about
>> a possible problem were ignored, especially since you just suggested to
>> google it.
>>
>> In the end I found out that I was missing the  <distributable/> tag in my
>> web.xml to enable session replication properly. So you(Stian) were right
>> after all. I didn't quite get the hint that "need to enable it for your
>> application" actually meant that I had to change the web.xml.
>>
>> Could you maybe put a warning into the documentation?
>>
>> Sorry for the noise again.
>>
>> Regards,
>> Christian
>>
>> Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
>>
>> I don't see the need for this mail. I was actually trying to help you. I
>> doubt you've even looked at what I've suggested though.
>>
>> As Bill points out get your HTTP session replication working first. It has
>> nothing to do with Keycloak. If you want non-sticky sessions and not using
>> the stateless option then you need that working. The reason why I told you
>> to google it is that you do actually have to enable HTTP session replication
>> on a per-war basis. It's not just a container config. The standalone-ha.xml
>> config in WildFly should be fine by default, so you don't need to do
>> anything there.
>>
>> On 25 January 2016 at 20:33, Christian Beikov <christian.beikov at gmail.com>
>> wrote:
>>> I don't want to be rude but you aren't helping me at all so I'd like to
>>> ask someone else from the team about this. I tried to explain multiple times
>>> that I already configured clustering in my Wildfly server, thus I configured
>>> session replication.
>>> Either I don't understand something about session replication or I require
>>> a configuration that you don't mention anywhere.
>>> I copied over the cache container from the standalone-ha configurations
>>> and configured the JGroups Subsystem which is what is described in the
>>> official documentation:
>>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>>
>>> I think I gave you enough information about my situation which you seemed
>>> to ignore completely. I would very much appreciate if I got a clear answer
>>> to my question especially since I am not asking for general configuration
>>> help, but for this special case which to me seems like a problem/limitation
>>> that should be explicitly documented.
>>>
>>> I am pretty sure clustering/session replication is configured correctly
>>> since I am using a custom cache container with a similar configuration like
>>> the web cache container which I know replicates correctly. So here comes my
>>> question once again, is it possible that the replication just lags behind
>>> which makes the usage of round robin completely impossible in the login
>>> flow? Or is there some kind of special configuration I have to do which
>>> differs from the standard cluster configuration as provided by the wildfly
>>> distribution? Or is this maybe even an implementation limiation of the
>>> server adapter?
>>>
>>> Regards,
>>> Christian
>>>
>>>
>>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>>
>>> Try google for wildfly replicate http sessions
>>>
>>> On 25 January 2016 at 15:53, Christian Beikov <christian.beikov at gmail.com>
>>> wrote:
>>>> I just wrote that I configured clustering for my application just like in
>>>> the standlone-ha.xml of my Wildfly 10 CR4.
>>>> I configured the jgroups subsystem and the distributed caches for web
>>>> sessions as it is done in standalone-ha.xml of Wildfly.
>>>> If there is anything else that should be configured, can you please point
>>>> me to that configuration option?
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>>
>>>> HTTP session replicate is not enabled by default. You need to enable it
>>>> for your application.
>>>>
>>>> On 25 January 2016 at 14:39, Christian Beikov
>>>> <christian.beikov at gmail.com> wrote:
>>>>> The documentation states, that the default token-store is "session" and
>>>>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like in
>>>>> standalone-ha.xml, so the session should already be replicated.
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>>
>>>>> Your issue doesn't have anything to do with the Keycloak server side
>>>>> user sessions, they don't require sticky sessions.
>>>>>
>>>>> Your issue is down to the http session on the adapter side not being
>>>>> replicated by default. For the adapter you've got 3 choices: sticky session,
>>>>> replicated session or stateless. Which is best depends on your application.
>>>>>
>>>>>
>>>>> On 25 January 2016 at 14:05, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>> I don't have a problem with sticky sessions and I will definitively
>>>>>> configure them, but I am curious. What is the reason for the problems with
>>>>>> round robin in this test scenario? Are the infinispan caches not replicated
>>>>>> fast enough or is there an implementation limitation in the adapters?
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>>
>>>>>> By default the adapters will require sticky sessions, please refer to
>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>> for more information
>>>>>>
>>>>>> On 22 January 2016 at 12:48, Christian Beikov
>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I am running some tests with my application cluster being secured by a
>>>>>>> single keycloak server instance and I encountered problems with the
>>>>>>> adapter.
>>>>>>>
>>>>>>> My application cluster contains 2 nodes and is load balanced by nginx.
>>>>>>> For testing purposes, I enabled round robin load balancing which is
>>>>>>> probably the "cause" for my issues.
>>>>>>>
>>>>>>> When I access a secured page, I get redirected to keycloak and
>>>>>>> everything is fine. When I then login, and keycloak redirects me back
>>>>>>> to
>>>>>>> the application, I get to a different application cluster node because
>>>>>>> of round robin. On that node, apparently the initial information of
>>>>>>> the
>>>>>>> client session is not available and I get redirected to keycloak login
>>>>>>> page again. Then keycloak redirects me back to the application, this
>>>>>>> time to the original node, and says that access is forbidden.
>>>>>>>
>>>>>>> I suppose the web session caches are not in sync but I just used the
>>>>>>> default cache containers as they are defined in standalone-ha.xml of
>>>>>>> my
>>>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>>>>>> distributed caches too which work just fine.
>>>>>>>
>>>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>>>
>>>>>>> Regards,
>>>>>>> Christian
>>>>>>> _______________________________________________
>>>>>>> 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 Jan 26 17:36:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Tue, 26 Jan 2016 17:36:08 -0500
Subject: [keycloak-dev] advice on back button
Message-ID: <56A7F4D8.2050009@redhat.com>

The current thinking for browser back button is to set:

Cache-Control: no-store, must-revalidate, max-age=0

There are possible security issues with this that I don't know if we 
should do this or not.  Don't know if you remember how ClientSessionCode 
works, it uses a hash of the client session id and the action key 
currently stored in the.  When you switch from authentication to 
required actions, the action key changes.  Now, if you hit the back 
button on a required action page, it would take you back to an 
authentication screen.  The code check would fail because the action 
keys don't match.

Do we actually need this action key stuff?  Can we just let the flow 
manager put the browser in the correct state?  So if an "authenticate" 
url is hit and the flow is on required actions, just redirect to the 
required actions URL.   I just worry that this is some sort of security 
hole somehow.  Maybe we're better off just reseting and restarting the 
flow entirely.

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


From alexgv99 at gmail.com  Tue Jan 26 22:07:54 2016
From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=)
Date: Wed, 27 Jan 2016 01:07:54 -0200
Subject: [keycloak-dev] keycloak-dev Digest, Vol 31, Issue 100
In-Reply-To: <mailman.84287.1453837534.3339.keycloak-dev@lists.jboss.org>
References: <mailman.84287.1453837534.3339.keycloak-dev@lists.jboss.org>
Message-ID: <CAGGeCYO6BC5-OXA7VoU=Bq9fA7atsdQw9jB50qxi06AtyskRow@mail.gmail.com>

2016-01-26 17:45 GMT-02:00 <keycloak-dev-request at lists.jboss.org>:

> Do you can an exception stacktrace on app or auth server?


?There is nothing in any log... neither Wildfly 10 (where my app is
deployed) or Keycloak Server (actually is a cluster with two instances... I
look into the two server.log files)?. The only line is written in Wildfly
10:
16:10:23,145 WARN  [org.keycloak.adapters.OAuthRequestAuthenticator]
(default task-66) No state cookie

?Best Regards.
Alex Gouvea Vasconcelos?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/d632de52/attachment.html 

From mposolda at redhat.com  Wed Jan 27 02:11:59 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 27 Jan 2016 08:11:59 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56A7F4D8.2050009@redhat.com>
References: <56A7F4D8.2050009@redhat.com>
Message-ID: <56A86DBF.6040802@redhat.com>

+1 to restart the flow entirely when back button is pressed in any stage 
(either authenticator or required actions screen). Or maybe even drop 
the ClientSession entirely and redirect back to the application?

Once we use this "must-revalidate" header, I hope we can detect that 
request was triggered by back button. Maybe we will need to maintain all 
previously used action keys on ClientSessionModel, so we are clearly 
able to detect that request was triggered by back button?

Note that I am not usability expert and I am not sure what is best 
practice regarding back button and usability. But redirect back to the 
application looks like most clear way to me.

Marek

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


From sthorger at redhat.com  Wed Jan 27 03:50:48 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Jan 2016 09:50:48 +0100
Subject: [keycloak-dev] Application Clustering problems
In-Reply-To: <56A7DF85.50506@redhat.com>
References: <56A216F4.3010700@gmail.com>
	<CAJgngAe7WpofD=MZvhf2RH=JarEm++jtaczcnwfUtAccHFnqNg@mail.gmail.com>
	<56A61DA0.1090706@gmail.com>
	<CAJgngAdzqGzwQOE92-Y=gXAEBSv9_SmvjL-VuViN7JxbVjZbGg@mail.gmail.com>
	<56A6257E.70701@gmail.com>
	<CAJgngAcwbmxgz=Dke0f-hKLW1BzJ2HG1AtJf+FJY0fn=KqiR_Q@mail.gmail.com>
	<56A636D9.2060901@gmail.com>
	<CAJgngAc3HkmS86V+cgrXzpFPfjw2T507uVzui0iemJGHnXNRmw@mail.gmail.com>
	<56A6788E.5030408@gmail.com>
	<CAJgngAf1BpMtjWz8YrCU2LNjo4g=91+BV+=eAPMcYC6oHQYQMA@mail.gmail.com>
	<56A75EAB.8090401@gmail.com> <56A7A08D.3030005@redhat.com>
	<CA+1OW+jqMHztxOFAopD3-LtbOSZkwRsBrGNtWAmne3AQw2NnPA@mail.gmail.com>
	<56A7DF85.50506@redhat.com>
Message-ID: <CAJgngAd-upV6myAH7QNZMn+9Vgu67LSZ+4z6mboWoy4Zf-cR7Q@mail.gmail.com>

A note is sufficient IMO. We shouldn't go over board with documenting
things that should be covered elsewhere. It's not our responsibility to
document how to cluster a WAR.

On 26 January 2016 at 22:05, Marek Posolda <mposolda at redhat.com> wrote:

> Yeah. The question is where is the exactly is the "border" to provide some
> hints, but not duplicate the info, which is not directly related to
> Keycloak.
>
> For application clustering, it's tricky as we support bunch of servers for
> adapter clustering. And each of them has some differences for cluster setup
> (and different infinispan version). So I've just added the note about
> <distributable /> in web.xml and the obligatory sentence "For more details
> look at your app server documentation" :-)
>
> Hope this will be sufficient for most of the cases.
>
> Marek
>
>
> On 26/01/16 18:10, Marko Strukelj wrote:
>
>> Maybe we should assume that people forget that stuff, and some don't
>> know it in the first place, and simply try to give all the info
>> necessary even for novice java developer to be successful setting it
>> all up.
>>
>> On Tue, Jan 26, 2016 at 5:36 PM, Marek Posolda <mposolda at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I've put some small note at the first paragraph of "Application
>>> clustering"
>>> chapter. Just a small note really, as setup of "distributable" in
>>> web.xml or
>>> configuration of infinispan are app. server specific steps and they are
>>> general to HttpSession replication and clustering, it's not Keycloak
>>> specific stuff.
>>>
>>> Marek
>>>
>>>
>>> On 26/01/16 12:55, Christian Beikov wrote:
>>>
>>> I am really sorry about the last mail, I just felt that my suggestions
>>> about
>>> a possible problem were ignored, especially since you just suggested to
>>> google it.
>>>
>>> In the end I found out that I was missing the  <distributable/> tag in my
>>> web.xml to enable session replication properly. So you(Stian) were right
>>> after all. I didn't quite get the hint that "need to enable it for your
>>> application" actually meant that I had to change the web.xml.
>>>
>>> Could you maybe put a warning into the documentation?
>>>
>>> Sorry for the noise again.
>>>
>>> Regards,
>>> Christian
>>>
>>> Am 26.01.2016 um 08:49 schrieb Stian Thorgersen:
>>>
>>> I don't see the need for this mail. I was actually trying to help you. I
>>> doubt you've even looked at what I've suggested though.
>>>
>>> As Bill points out get your HTTP session replication working first. It
>>> has
>>> nothing to do with Keycloak. If you want non-sticky sessions and not
>>> using
>>> the stateless option then you need that working. The reason why I told
>>> you
>>> to google it is that you do actually have to enable HTTP session
>>> replication
>>> on a per-war basis. It's not just a container config. The
>>> standalone-ha.xml
>>> config in WildFly should be fine by default, so you don't need to do
>>> anything there.
>>>
>>> On 25 January 2016 at 20:33, Christian Beikov <
>>> christian.beikov at gmail.com>
>>> wrote:
>>>
>>>> I don't want to be rude but you aren't helping me at all so I'd like to
>>>> ask someone else from the team about this. I tried to explain multiple
>>>> times
>>>> that I already configured clustering in my Wildfly server, thus I
>>>> configured
>>>> session replication.
>>>> Either I don't understand something about session replication or I
>>>> require
>>>> a configuration that you don't mention anywhere.
>>>> I copied over the cache container from the standalone-ha configurations
>>>> and configured the JGroups Subsystem which is what is described in the
>>>> official documentation:
>>>> https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
>>>>
>>>> I think I gave you enough information about my situation which you
>>>> seemed
>>>> to ignore completely. I would very much appreciate if I got a clear
>>>> answer
>>>> to my question especially since I am not asking for general
>>>> configuration
>>>> help, but for this special case which to me seems like a
>>>> problem/limitation
>>>> that should be explicitly documented.
>>>>
>>>> I am pretty sure clustering/session replication is configured correctly
>>>> since I am using a custom cache container with a similar configuration
>>>> like
>>>> the web cache container which I know replicates correctly. So here
>>>> comes my
>>>> question once again, is it possible that the replication just lags
>>>> behind
>>>> which makes the usage of round robin completely impossible in the login
>>>> flow? Or is there some kind of special configuration I have to do which
>>>> differs from the standard cluster configuration as provided by the
>>>> wildfly
>>>> distribution? Or is this maybe even an implementation limiation of the
>>>> server adapter?
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>>
>>>> Am 25.01.2016 um 19:04 schrieb Stian Thorgersen:
>>>>
>>>> Try google for wildfly replicate http sessions
>>>>
>>>> On 25 January 2016 at 15:53, Christian Beikov <
>>>> christian.beikov at gmail.com>
>>>> wrote:
>>>>
>>>>> I just wrote that I configured clustering for my application just like
>>>>> in
>>>>> the standlone-ha.xml of my Wildfly 10 CR4.
>>>>> I configured the jgroups subsystem and the distributed caches for web
>>>>> sessions as it is done in standalone-ha.xml of Wildfly.
>>>>> If there is anything else that should be configured, can you please
>>>>> point
>>>>> me to that configuration option?
>>>>>
>>>>> Regards,
>>>>> Christian
>>>>>
>>>>>
>>>>> Am 25.01.2016 um 15:45 schrieb Stian Thorgersen:
>>>>>
>>>>> HTTP session replicate is not enabled by default. You need to enable it
>>>>> for your application.
>>>>>
>>>>> On 25 January 2016 at 14:39, Christian Beikov
>>>>> <christian.beikov at gmail.com> wrote:
>>>>>
>>>>>> The documentation states, that the default token-store is "session"
>>>>>> and
>>>>>> as I wrote before, I have setup clustering on my Wildfly 10 CR4 like
>>>>>> in
>>>>>> standalone-ha.xml, so the session should already be replicated.
>>>>>>
>>>>>> Regards,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> Am 25.01.2016 um 14:20 schrieb Stian Thorgersen:
>>>>>>
>>>>>> Your issue doesn't have anything to do with the Keycloak server side
>>>>>> user sessions, they don't require sticky sessions.
>>>>>>
>>>>>> Your issue is down to the http session on the adapter side not being
>>>>>> replicated by default. For the adapter you've got 3 choices: sticky
>>>>>> session,
>>>>>> replicated session or stateless. Which is best depends on your
>>>>>> application.
>>>>>>
>>>>>>
>>>>>> On 25 January 2016 at 14:05, Christian Beikov
>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>
>>>>>>> I don't have a problem with sticky sessions and I will definitively
>>>>>>> configure them, but I am curious. What is the reason for the
>>>>>>> problems with
>>>>>>> round robin in this test scenario? Are the infinispan caches not
>>>>>>> replicated
>>>>>>> fast enough or is there an implementation limitation in the adapters?
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Christian
>>>>>>>
>>>>>>>
>>>>>>> Am 25.01.2016 um 08:58 schrieb Stian Thorgersen:
>>>>>>>
>>>>>>> By default the adapters will require sticky sessions, please refer to
>>>>>>>
>>>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/applicationClustering.html
>>>>>>> for more information
>>>>>>>
>>>>>>> On 22 January 2016 at 12:48, Christian Beikov
>>>>>>> <christian.beikov at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am running some tests with my application cluster being secured
>>>>>>>> by a
>>>>>>>> single keycloak server instance and I encountered problems with the
>>>>>>>> adapter.
>>>>>>>>
>>>>>>>> My application cluster contains 2 nodes and is load balanced by
>>>>>>>> nginx.
>>>>>>>> For testing purposes, I enabled round robin load balancing which is
>>>>>>>> probably the "cause" for my issues.
>>>>>>>>
>>>>>>>> When I access a secured page, I get redirected to keycloak and
>>>>>>>> everything is fine. When I then login, and keycloak redirects me
>>>>>>>> back
>>>>>>>> to
>>>>>>>> the application, I get to a different application cluster node
>>>>>>>> because
>>>>>>>> of round robin. On that node, apparently the initial information of
>>>>>>>> the
>>>>>>>> client session is not available and I get redirected to keycloak
>>>>>>>> login
>>>>>>>> page again. Then keycloak redirects me back to the application, this
>>>>>>>> time to the original node, and says that access is forbidden.
>>>>>>>>
>>>>>>>> I suppose the web session caches are not in sync but I just used the
>>>>>>>> default cache containers as they are defined in standalone-ha.xml of
>>>>>>>> my
>>>>>>>> Wildlfy 10 CR4. Clustering with jgroups works, as I use other
>>>>>>>> distributed caches too which work just fine.
>>>>>>>>
>>>>>>>> We are using Keycloak 1.8.0.CR2 on a Wildfly 10 CR4
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Christian
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/9cde5f4a/attachment-0001.html 

From mstrukel at redhat.com  Wed Jan 27 03:52:56 2016
From: mstrukel at redhat.com (Marko Strukelj)
Date: Wed, 27 Jan 2016 09:52:56 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56A86DBF.6040802@redhat.com>
References: <56A7F4D8.2050009@redhat.com>
	<56A86DBF.6040802@redhat.com>
Message-ID: <CA+1OW+hynHS52F9tny6247TVRoH0q4YSik4rr8OO18sSH8MP8w@mail.gmail.com>

I personally am very used to expecting web sites to just work if I do a
back button followed by a forward button. If content of my forms disappears
during back-forward combo, or consequent action fails with strange error
I'm always annoyed by it. I know that there is a technical reason behind it
not working but some sites do this right. So in principle I'm against
backbutton automatically forgetting the session, and making me start from
scratch.
On Jan 27, 2016 8:12 AM, "Marek Posolda" <mposolda at redhat.com> wrote:

> +1 to restart the flow entirely when back button is pressed in any stage
> (either authenticator or required actions screen). Or maybe even drop
> the ClientSession entirely and redirect back to the application?
>
> Once we use this "must-revalidate" header, I hope we can detect that
> request was triggered by back button. Maybe we will need to maintain all
> previously used action keys on ClientSessionModel, so we are clearly
> able to detect that request was triggered by back button?
>
> Note that I am not usability expert and I am not sure what is best
> practice regarding back button and usability. But redirect back to the
> application looks like most clear way to me.
>
> Marek
>
> On 26/01/16 23:36, Bill Burke wrote:
> > The current thinking for browser back button is to set:
> >
> > Cache-Control: no-store, must-revalidate, max-age=0
> >
> > There are possible security issues with this that I don't know if we
> > should do this or not.  Don't know if you remember how ClientSessionCode
> > works, it uses a hash of the client session id and the action key
> > currently stored in the.  When you switch from authentication to
> > required actions, the action key changes.  Now, if you hit the back
> > button on a required action page, it would take you back to an
> > authentication screen.  The code check would fail because the action
> > keys don't match.
> >
> > Do we actually need this action key stuff?  Can we just let the flow
> > manager put the browser in the correct state?  So if an "authenticate"
> > url is hit and the flow is on required actions, just redirect to the
> > required actions URL.   I just worry that this is some sort of security
> > hole somehow.  Maybe we're better off just reseting and restarting the
> > flow entirely.
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/ad99b772/attachment.html 

From sthorger at redhat.com  Wed Jan 27 03:55:03 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Jan 2016 09:55:03 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56A86DBF.6040802@redhat.com>
References: <56A7F4D8.2050009@redhat.com>
	<56A86DBF.6040802@redhat.com>
Message-ID: <CAJgngAfjyV+=YZuVXe7V+Fv3G0dwOZGUutWAdkckA=uHzx6Lvw@mail.gmail.com>

The action key was introduced in the whole days when we didn't have any
state on the server that was aware where the flow was. Now that we have a
clear state on the server that is fully aware of where in a flow a user is
it shouldn't be required any more, and as long as the flow manager puts it
in the correct state there's nothing that a user can do to try to jump
back/forward in the flow.

On 27 January 2016 at 08:11, Marek Posolda <mposolda at redhat.com> wrote:

> +1 to restart the flow entirely when back button is pressed in any stage
> (either authenticator or required actions screen). Or maybe even drop
> the ClientSession entirely and redirect back to the application?
>
> Once we use this "must-revalidate" header, I hope we can detect that
> request was triggered by back button. Maybe we will need to maintain all
> previously used action keys on ClientSessionModel, so we are clearly
> able to detect that request was triggered by back button?
>
> Note that I am not usability expert and I am not sure what is best
> practice regarding back button and usability. But redirect back to the
> application looks like most clear way to me.
>
> Marek
>
> On 26/01/16 23:36, Bill Burke wrote:
> > The current thinking for browser back button is to set:
> >
> > Cache-Control: no-store, must-revalidate, max-age=0
> >
> > There are possible security issues with this that I don't know if we
> > should do this or not.  Don't know if you remember how ClientSessionCode
> > works, it uses a hash of the client session id and the action key
> > currently stored in the.  When you switch from authentication to
> > required actions, the action key changes.  Now, if you hit the back
> > button on a required action page, it would take you back to an
> > authentication screen.  The code check would fail because the action
> > keys don't match.
> >
> > Do we actually need this action key stuff?  Can we just let the flow
> > manager put the browser in the correct state?  So if an "authenticate"
> > url is hit and the flow is on required actions, just redirect to the
> > required actions URL.   I just worry that this is some sort of security
> > hole somehow.  Maybe we're better off just reseting and restarting the
> > flow entirely.
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/552931d7/attachment.html 

From sthorger at redhat.com  Wed Jan 27 03:58:10 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 27 Jan 2016 09:58:10 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <CAJgngAfjyV+=YZuVXe7V+Fv3G0dwOZGUutWAdkckA=uHzx6Lvw@mail.gmail.com>
References: <56A7F4D8.2050009@redhat.com> <56A86DBF.6040802@redhat.com>
	<CAJgngAfjyV+=YZuVXe7V+Fv3G0dwOZGUutWAdkckA=uHzx6Lvw@mail.gmail.com>
Message-ID: <CAJgngAcKYKcbC3J16EJzYZMs-nyFuYhgi-sDjor2ns-Mb5+0eg@mail.gmail.com>

The back button should just re-display the current page. Then there should
be separate link/button on the page to go back to the application (as long
as base url is set on client this should always be available, even if
client session has timed out). I think we should also consider having a
button/link to restart the flow.

On 27 January 2016 at 09:55, Stian Thorgersen <sthorger at redhat.com> wrote:

> The action key was introduced in the whole days when we didn't have any
> state on the server that was aware where the flow was. Now that we have a
> clear state on the server that is fully aware of where in a flow a user is
> it shouldn't be required any more, and as long as the flow manager puts it
> in the correct state there's nothing that a user can do to try to jump
> back/forward in the flow.
>
> On 27 January 2016 at 08:11, Marek Posolda <mposolda at redhat.com> wrote:
>
>> +1 to restart the flow entirely when back button is pressed in any stage
>> (either authenticator or required actions screen). Or maybe even drop
>> the ClientSession entirely and redirect back to the application?
>>
>> Once we use this "must-revalidate" header, I hope we can detect that
>> request was triggered by back button. Maybe we will need to maintain all
>> previously used action keys on ClientSessionModel, so we are clearly
>> able to detect that request was triggered by back button?
>>
>> Note that I am not usability expert and I am not sure what is best
>> practice regarding back button and usability. But redirect back to the
>> application looks like most clear way to me.
>>
>> Marek
>>
>> On 26/01/16 23:36, Bill Burke wrote:
>> > The current thinking for browser back button is to set:
>> >
>> > Cache-Control: no-store, must-revalidate, max-age=0
>> >
>> > There are possible security issues with this that I don't know if we
>> > should do this or not.  Don't know if you remember how ClientSessionCode
>> > works, it uses a hash of the client session id and the action key
>> > currently stored in the.  When you switch from authentication to
>> > required actions, the action key changes.  Now, if you hit the back
>> > button on a required action page, it would take you back to an
>> > authentication screen.  The code check would fail because the action
>> > keys don't match.
>> >
>> > Do we actually need this action key stuff?  Can we just let the flow
>> > manager put the browser in the correct state?  So if an "authenticate"
>> > url is hit and the flow is on required actions, just redirect to the
>> > required actions URL.   I just worry that this is some sort of security
>> > hole somehow.  Maybe we're better off just reseting and restarting the
>> > flow entirely.
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/b031c39e/attachment.html 

From lkrzyzan at redhat.com  Wed Jan 27 07:55:42 2016
From: lkrzyzan at redhat.com (Libor Krzyzanek)
Date: Wed, 27 Jan 2016 13:55:42 +0100
Subject: [keycloak-dev] 1.8.0.Final release date
Message-ID: <160ED702-0658-4141-907F-A9F806AC98C4@redhat.com>

hi,
when are you going to release 1.8.0.Final please?

Thanks,

Libor Krzy?anek
jboss.org Development Team



From bburke at redhat.com  Wed Jan 27 09:20:33 2016
From: bburke at redhat.com (Bill Burke)
Date: Wed, 27 Jan 2016 09:20:33 -0500
Subject: [keycloak-dev] advice on back button
In-Reply-To: <CAJgngAcKYKcbC3J16EJzYZMs-nyFuYhgi-sDjor2ns-Mb5+0eg@mail.gmail.com>
References: <56A7F4D8.2050009@redhat.com> <56A86DBF.6040802@redhat.com>
	<CAJgngAfjyV+=YZuVXe7V+Fv3G0dwOZGUutWAdkckA=uHzx6Lvw@mail.gmail.com>
	<CAJgngAcKYKcbC3J16EJzYZMs-nyFuYhgi-sDjor2ns-Mb5+0eg@mail.gmail.com>
Message-ID: <56A8D231.1000002@redhat.com>

Lol, we used to have "back to app" button, removed it.  we still have a 
cancel button on OTP page, this just restarts the flow.  IMO, if users 
want a "back to app" button, they should just add it themselves.

On 1/27/2016 3:58 AM, Stian Thorgersen wrote:
> The back button should just re-display the current page. Then there 
> should be separate link/button on the page to go back to the 
> application (as long as base url is set on client this should always 
> be available, even if client session has timed out). I think we should 
> also consider having a button/link to restart the flow.
>
> On 27 January 2016 at 09:55, Stian Thorgersen <sthorger at redhat.com 
> <mailto:sthorger at redhat.com>> wrote:
>
>     The action key was introduced in the whole days when we didn't
>     have any state on the server that was aware where the flow was.
>     Now that we have a clear state on the server that is fully aware
>     of where in a flow a user is it shouldn't be required any more,
>     and as long as the flow manager puts it in the correct state
>     there's nothing that a user can do to try to jump back/forward in
>     the flow.
>
>     On 27 January 2016 at 08:11, Marek Posolda <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>> wrote:
>
>         +1 to restart the flow entirely when back button is pressed in
>         any stage
>         (either authenticator or required actions screen). Or maybe
>         even drop
>         the ClientSession entirely and redirect back to the application?
>
>         Once we use this "must-revalidate" header, I hope we can
>         detect that
>         request was triggered by back button. Maybe we will need to
>         maintain all
>         previously used action keys on ClientSessionModel, so we are
>         clearly
>         able to detect that request was triggered by back button?
>
>         Note that I am not usability expert and I am not sure what is best
>         practice regarding back button and usability. But redirect
>         back to the
>         application looks like most clear way to me.
>
>         Marek
>
>         On 26/01/16 23:36, Bill Burke wrote:
>         > The current thinking for browser back button is to set:
>         >
>         > Cache-Control: no-store, must-revalidate, max-age=0
>         >
>         > There are possible security issues with this that I don't
>         know if we
>         > should do this or not.  Don't know if you remember how
>         ClientSessionCode
>         > works, it uses a hash of the client session id and the
>         action key
>         > currently stored in the.  When you switch from authentication to
>         > required actions, the action key changes. Now, if you hit
>         the back
>         > button on a required action page, it would take you back to an
>         > authentication screen.  The code check would fail because
>         the action
>         > keys don't match.
>         >
>         > Do we actually need this action key stuff? Can we just let
>         the flow
>         > manager put the browser in the correct state?  So if an
>         "authenticate"
>         > url is hit and the flow is on required actions, just
>         redirect to the
>         > required actions URL.   I just worry that this is some sort
>         of security
>         > hole somehow.  Maybe we're better off just reseting and
>         restarting the
>         > flow entirely.
>         >
>
>         _______________________________________________
>         keycloak-dev mailing list
>         keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>

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

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

From mposolda at redhat.com  Wed Jan 27 09:44:20 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 27 Jan 2016 15:44:20 +0100
Subject: [keycloak-dev] advice on back button
In-Reply-To: <56A8D231.1000002@redhat.com>
References: <56A7F4D8.2050009@redhat.com> <56A86DBF.6040802@redhat.com>
	<CAJgngAfjyV+=YZuVXe7V+Fv3G0dwOZGUutWAdkckA=uHzx6Lvw@mail.gmail.com>
	<CAJgngAcKYKcbC3J16EJzYZMs-nyFuYhgi-sDjor2ns-Mb5+0eg@mail.gmail.com>
	<56A8D231.1000002@redhat.com>
Message-ID: <56A8D7C4.8030203@redhat.com>

Just checked how Facebook works. If you login and then press "back" 
button on consent screen, they also just redisplay this screen. The 
thing is, that with this behaviour when you press "back" button 10 
times, you're still on the same page. Doesn't seem to be a way to go 
through browser history back to the application or even earlier.

Not sure if this is a problem or not. I am personally almost don't use 
back-button (especially on stateful sites where I am logged) as many 
sites are broken and I never know what the back button will do ;-)

Marek

On 27/01/16 15:20, Bill Burke wrote:
> Lol, we used to have "back to app" button, removed it.  we still have 
> a cancel button on OTP page, this just restarts the flow. IMO, if 
> users want a "back to app" button, they should just add it themselves.
>
> On 1/27/2016 3:58 AM, Stian Thorgersen wrote:
>> The back button should just re-display the current page. Then there 
>> should be separate link/button on the page to go back to the 
>> application (as long as base url is set on client this should always 
>> be available, even if client session has timed out). I think we 
>> should also consider having a button/link to restart the flow.
>>
>> On 27 January 2016 at 09:55, Stian Thorgersen <sthorger at redhat.com 
>> <mailto:sthorger at redhat.com>> wrote:
>>
>>     The action key was introduced in the whole days when we didn't
>>     have any state on the server that was aware where the flow was.
>>     Now that we have a clear state on the server that is fully aware
>>     of where in a flow a user is it shouldn't be required any more,
>>     and as long as the flow manager puts it in the correct state
>>     there's nothing that a user can do to try to jump back/forward in
>>     the flow.
>>
>>     On 27 January 2016 at 08:11, Marek Posolda <mposolda at redhat.com>
>>     wrote:
>>
>>         +1 to restart the flow entirely when back button is pressed
>>         in any stage
>>         (either authenticator or required actions screen). Or maybe
>>         even drop
>>         the ClientSession entirely and redirect back to the application?
>>
>>         Once we use this "must-revalidate" header, I hope we can
>>         detect that
>>         request was triggered by back button. Maybe we will need to
>>         maintain all
>>         previously used action keys on ClientSessionModel, so we are
>>         clearly
>>         able to detect that request was triggered by back button?
>>
>>         Note that I am not usability expert and I am not sure what is
>>         best
>>         practice regarding back button and usability. But redirect
>>         back to the
>>         application looks like most clear way to me.
>>
>>         Marek
>>
>>         On 26/01/16 23:36, Bill Burke wrote:
>>         > The current thinking for browser back button is to set:
>>         >
>>         > Cache-Control: no-store, must-revalidate, max-age=0
>>         >
>>         > There are possible security issues with this that I don't
>>         know if we
>>         > should do this or not.  Don't know if you remember how
>>         ClientSessionCode
>>         > works, it uses a hash of the client session id and the
>>         action key
>>         > currently stored in the.  When you switch from
>>         authentication to
>>         > required actions, the action key changes.  Now, if you hit
>>         the back
>>         > button on a required action page, it would take you back to an
>>         > authentication screen.  The code check would fail because
>>         the action
>>         > keys don't match.
>>         >
>>         > Do we actually need this action key stuff?  Can we just let
>>         the flow
>>         > manager put the browser in the correct state?  So if an
>>         "authenticate"
>>         > url is hit and the flow is on required actions, just
>>         redirect to the
>>         > required actions URL.   I just worry that this is some sort
>>         of security
>>         > hole somehow.  Maybe we're better off just reseting and
>>         restarting the
>>         > flow entirely.
>>         >
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

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

From carljmosca at gmail.com  Wed Jan 27 12:37:04 2016
From: carljmosca at gmail.com (Carl Mosca)
Date: Wed, 27 Jan 2016 12:37:04 -0500
Subject: [keycloak-dev] logging configuration for Spring-Boot
Message-ID: <CAOEBAJBC4rfM4xeCWYp9yujw_G2HqR0b1s69rBTDLTY29auBJw@mail.gmail.com>

I have read a couple of posts on (JBoss) logging configuration for Spring
Boot but so far nothing is giving me DEBUG level output.

I am trying to track down a keycloak Spring Boot issue.

Does anyone have an example they can point me to?

TIA,
Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160127/c3a1a031/attachment.html 

From sthorger at redhat.com  Thu Jan 28 02:52:41 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 28 Jan 2016 08:52:41 +0100
Subject: [keycloak-dev] 1.8.0.Final release date
In-Reply-To: <160ED702-0658-4141-907F-A9F806AC98C4@redhat.com>
References: <160ED702-0658-4141-907F-A9F806AC98C4@redhat.com>
Message-ID: <CAJgngAf0UfVDSvS5CGtofGFaP31HxvYhX84mQcuc5n3o4YN7Ew@mail.gmail.com>

Tomorrow at the earliest. We still have one outstanding issue to fix.
On 27 Jan 2016 13:56, "Libor Krzyzanek" <lkrzyzan at redhat.com> wrote:

> hi,
> when are you going to release 1.8.0.Final please?
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/b6315e9f/attachment.html 

From gambol99 at gmail.com  Thu Jan 28 04:03:28 2016
From: gambol99 at gmail.com (gambol)
Date: Thu, 28 Jan 2016 09:03:28 +0000
Subject: [keycloak-dev] Office 365
In-Reply-To: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
Message-ID: <CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>

Was wondering if anyone has or knows if Keycloak supports adding office 365
as a identity provider?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/a055ea0a/attachment.html 

From parul.com at gmail.com  Thu Jan 28 05:31:08 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Thu, 28 Jan 2016 16:01:08 +0530
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
	always validated.
Message-ID: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>

As per OASIS/SAML spec recommendation, If the message is signed, the
Destination XML attribute in the root SAML element of the protocol message
MUST contain the URL to which the sender has instructed the user agent to
deliver the message. The recipient MUST then verify that the value matches
the location at which the message has been received.

However, in keycloak, always validate the 'Destination'  on saml response.
irrespective of response is signed or not.

is not a defect?

Thanks,
Arul kumar P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/78be02a9/attachment-0001.html 

From mposolda at redhat.com  Thu Jan 28 06:33:38 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 28 Jan 2016 12:33:38 +0100
Subject: [keycloak-dev] Office 365
In-Reply-To: <CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
	<CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
Message-ID: <56A9FC92.4060801@redhat.com>

Seems that office365 supports OpenID Connect. In this case, you can try 
to configure generic "OpenID Connect v1.0" provider in our admin console.

Marek

On 28/01/16 10:03, gambol wrote:
>
> Was wondering if anyone has or knows if Keycloak supports adding 
> office 365 as a identity provider?
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From jorsol at gmail.com  Thu Jan 28 08:58:09 2016
From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=)
Date: Thu, 28 Jan 2016 07:58:09 -0600
Subject: [keycloak-dev] Office 365
In-Reply-To: <56A9FC92.4060801@redhat.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
	<CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
	<56A9FC92.4060801@redhat.com>
Message-ID: <CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>

Is Office 365 using something diferent to Microsoft Live?

Keycloak adds support to Microsoft Live in 1.8 CR2, It should work with
Office 365.


Jorge Sol?rzano
http://www.jorsol.com

On Thu, Jan 28, 2016 at 5:33 AM, Marek Posolda <mposolda at redhat.com> wrote:

> Seems that office365 supports OpenID Connect. In this case, you can try to
> configure generic "OpenID Connect v1.0" provider in our admin console.
>
> Marek
>
> On 28/01/16 10:03, gambol wrote:
>
> Was wondering if anyone has or knows if Keycloak supports adding office
> 365 as a identity provider?
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/a919507e/attachment.html 

From bburke at redhat.com  Thu Jan 28 09:33:01 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 09:33:01 -0500
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
 always validated.
In-Reply-To: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
References: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
Message-ID: <56AA269D.1070204@redhat.com>

Yes, we validate it.  Is this a problem with some third party saml 
integration?

On 1/28/2016 5:31 AM, Arulkumar Ponnusamy wrote:
> As per OASIS/SAML spec recommendation, If the message is signed, the 
> Destination XML attribute in the root SAML element of the protocol 
> message MUST contain the URL to which the sender has instructed the 
> user agent to deliver the message. The recipient MUST then verify that 
> the value matches the location at which the message has been received.
>
> However, in keycloak, always validate the 'Destination'  on saml 
> response. irrespective of response is signed or not.
>
> is not a defect?
>
> Thanks,
> Arul kumar P.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From mposolda at redhat.com  Thu Jan 28 09:36:17 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 28 Jan 2016 15:36:17 +0100
Subject: [keycloak-dev] Office 365
In-Reply-To: <CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>
References: <CA+AP+fM_=uBaaPkQk4WDokOs6meRR1KpAAR9aixA+y5p6G1aVw@mail.gmail.com>
	<CA+AP+fMpZC3ibfJQKJNNWdm0KW_hzc_SqVPKK1esydNbg+358A@mail.gmail.com>
	<56A9FC92.4060801@redhat.com>
	<CA+cVU8MCKquw=DaGQ3xuswEvEEoYr_8mauMm-z2cFpqt4Rquew@mail.gmail.com>
Message-ID: <56AA2761.3050707@redhat.com>

Not sure at 100% . However from quick googling it seems to be 2 
different things. See 
https://msdn.microsoft.com/en-us/library/hh243647.aspx vs. 
https://docs.moodle.org/27/en/Office365#Enable_the_OpenID_Connect_Authentication_Plugin

Marek

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

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

From bburke at redhat.com  Thu Jan 28 09:47:11 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 09:47:11 -0500
Subject: [keycloak-dev] new browser back button behavior
Message-ID: <56AA29EF.5030402@redhat.com>

PR is building...

Browser back button will now either restart the flow (and create a new 
client session) or not allow you off your current page depending on the 
protocol and where you are in the flow.

* If your protocol is initiated by a GET request and the back button 
brings you to the 1st rendered page (username/password) this starts a 
new flow
* If your protocol is initiated by a POST request (SAML Post binding) 
things work a bit differently.  This initial post request will redirect 
you to the "authenticate" URL.  Then if your back button brings you to 
the username/password page, you will not see it and just stay on your 
current page.
* If your back button click brings you to the 2nd page in the flow, you 
will just be stuck on your current page.

Try it out.  Hopefully all these refresh and back button issues are done 
now.

Some changes to make this happen:
* The "code" in the URL o the flow used to be generated by hashing the 
current action key, the current action (AUTHENTICATE, REQUIRE_ACTION), 
and the realm secret key.  The action key changed whenever you changed 
the current action...NOW the action key does NOT change for the whole 
flow.  The action key is automatically generated once when you create 
the ClientSession and never changed again.
* Consent page no longer changes the current action to OAUTH_GRANT. 
Consent page is now considered a REQUIRED_ACTION action and treated as 
such.  This was to support back button here too.
* Cache-Control: no-store, must-revalidate, max-age=0  is now set in the 
response for every endpoint on LoginActionsService and any protocol 
entry point.

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


From Edgar at info.nl  Thu Jan 28 10:10:30 2016
From: Edgar at info.nl (Edgar Vonk - Info.nl)
Date: Thu, 28 Jan 2016 15:10:30 +0000
Subject: [keycloak-dev] Missing client roles to view and manage groups?
Message-ID: <A0D12E26-C9BD-4E9F-89C5-450433592F5D@info.nl>

Hi,

It seems there are no client roles to view and manage groups in Keycloak? I expected to see view-groups and manage-groups roles just like view-users and view-groups.

Our case is that we want to have ?functional admin? users that are allowed to manage users and groups within their realm (and nothing else).

I have now created such a functional admin user with the following client roles in this particular realm:
- view-events
- manage-users
- view-users
- impersonation

When I log in as this functional admin user I can manage users fine, however I cannot manage groups. I do see the ?Manage Groups? menu item in the admin console but when I click on it I get a ?Forbidden. You don't have access to the requested resource.? and in the logs we see:

4:59:19,950 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) RESTEASY002005: Failed executing GET /admin/realms/graydon-customers/groups: org.keycloak.services.ForbiddenException
	at org.keycloak.services.resources.admin.RealmAuth.requireView(RealmAuth.java:53)
	at org.keycloak.services.resources.admin.GroupsResource.getGroups(GroupsResource.java:72)
	at sun.reflect.GeneratedMethodAccessor664.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133)
	at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)


Is the absence of roles for viewing and managing groups a shortcoming in Keycloak? If so, shall I create a JIRA ticket for it?

cheers

Edgar


From parul.com at gmail.com  Thu Jan 28 10:21:43 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Thu, 28 Jan 2016 20:51:43 +0530
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
 always validated.
In-Reply-To: <56AA269D.1070204@redhat.com>
References: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
	<56AA269D.1070204@redhat.com>
Message-ID: <CAFj68vXjKjoYH_2WHFcD0zjXE_4nLyURYFDSOOebchoNFYjJig@mail.gmail.com>

Yep.. We are trying to integrate with Ping Federate IDP and it causing the
authentication failure. But, Ping federate does not give Destination
element  for signed xml too which we need to follow up with Ping federate.
On 28-Jan-2016 8:03 PM, "Bill Burke" <bburke at redhat.com> wrote:

> Yes, we validate it.  Is this a problem with some third party saml
> integration?
>
> On 1/28/2016 5:31 AM, Arulkumar Ponnusamy wrote:
>
> As per OASIS/SAML spec recommendation, If the message is signed, the
> Destination XML attribute in the root SAML element of the protocol message
> MUST contain the URL to which the sender has instructed the user agent to
> deliver the message. The recipient MUST then verify that the value matches
> the location at which the message has been received.
>
> However, in keycloak, always validate the 'Destination'  on saml response.
> irrespective of response is signed or not.
>
> is not a defect?
>
> Thanks,
> Arul kumar P.
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/dd3a2fb9/attachment.html 

From bburke at redhat.com  Thu Jan 28 10:38:55 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 10:38:55 -0500
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
 always validated.
In-Reply-To: <CAFj68vXjKjoYH_2WHFcD0zjXE_4nLyURYFDSOOebchoNFYjJig@mail.gmail.com>
References: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
	<56AA269D.1070204@redhat.com>
	<CAFj68vXjKjoYH_2WHFcD0zjXE_4nLyURYFDSOOebchoNFYjJig@mail.gmail.com>
Message-ID: <56AA360F.9050801@redhat.com>

IMO, they should provide it irregardless.

On 1/28/2016 10:21 AM, Arulkumar Ponnusamy wrote:
>
> Yep.. We are trying to integrate with Ping Federate IDP and it causing 
> the authentication failure. But, Ping federate does not give 
> Destination element  for signed xml too which we need to follow up 
> with Ping federate.
>
> On 28-Jan-2016 8:03 PM, "Bill Burke" <bburke at redhat.com 
> <mailto:bburke at redhat.com>> wrote:
>
>     Yes, we validate it. Is this a problem with some third party saml
>     integration?
>
>     On 1/28/2016 5:31 AM, Arulkumar Ponnusamy wrote:
>>     As per OASIS/SAML spec recommendation, If the message is signed,
>>     the Destination XML attribute in the root SAML element of the
>>     protocol message MUST contain the URL to which the sender has
>>     instructed the user agent to deliver the message. The recipient
>>     MUST then verify that the value matches the location at which the
>>     message has been received.
>>
>>     However, in keycloak, always validate the 'Destination'  on saml
>>     response. irrespective of response is signed or not.
>>
>>     is not a defect?
>>
>>     Thanks,
>>     Arul kumar P.
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     -- 
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

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

From alexgv99 at gmail.com  Thu Jan 28 11:03:03 2016
From: alexgv99 at gmail.com (=?UTF-8?Q?Alex_Gouv=C3=AAa_Vasconcelos?=)
Date: Thu, 28 Jan 2016 14:03:03 -0200
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
Message-ID: <CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>

Sorry guys, I'm not sure weather the group receive the answer to Mr. Burke
question about logs or not...

> ?
> Do you can an exception stacktrace on app or auth server??

Anyway, there's no log to share, here... the server.log file (in Keycloak
cluster - 2 instances) doesn't emit any line in the process... and the
Wildfly (where the app is deployed) just say:

> ?
> 16:10:23,145 WARN [org.keycloak.adapters.OAuthRequestAuthenticator]
> ? ?
> (default task-66) No state cookie?


?So, I hope someone could help me here...

Thanks.?


---------- Forwarded message ----------
From: Alex Gouv?a Vasconcelos <alexgv99 at gmail.com>
Date: 2016-01-26 17:16 GMT-02:00
Subject: Fwd: Bad Request
To: keycloak-dev at lists.jboss.org


Hi guys. I'm running into some trouble here...

I have a very simple application which should authenticate against keycloak
and return to the main page. This is triggered through the web.xml in my
application.

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

<module-name>teste</module-name>

<filter>
<filter-name>CORSFilter</filter-name>
<filter-class>br.com.test.tms.teste.util.CORSFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CORSFilter</filter-name>
<url-pattern>/rest/*</url-pattern>
</filter-mapping>

<distributable />

<security-constraint>
<web-resource-collection>
<web-resource-name>teste</web-resource-name>
<url-pattern>/rest/exemploService/secure/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

<login-config>
<auth-method>KEYCLOAK</auth-method>
<realm-name>realmtest</realm-name>
</login-config>
<security-role>
<role-name>user</role-name>
</security-role>
<security-role>
<role-name>admin</role-name>
</security-role>

</web-app>


The server side has a REST API and the client side is an angular
application. Everything very simple to just try the development
environment. What happens is that, after filling the login page and return
to the index.html (actually it's not returning), I receive a 400 BAD
REQUEST for the uri:

http://localhost:8080/teste/?code=X8VlnUNxYzofJDHzkx1ZmMgO2BP0ZDJ-e2l7uB091Dk.bd5edab3-359b-4616-a403-34fffb427af9&state=67b87fd5-7cc0-4415-9b8b-fc16675229a1


It seems to me, that the malformed URI is because of the ?code=... If I
reload the page with the same URL, it just return the same 400... if I
remove the ? portion, it reloads the page and again redirects to and from
the keycloak server, and recovers the ? portion, repeating the same 400.

I'm running everything in the same application under wildfly 10. Both the
server and client sides in the same deployed WAR.

I'd appreciate any help.

Best regards.

Alex Gouvea Vasconcelos







[image: Imagem inline 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/5e120364/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keycloak.png
Type: image/png
Size: 248184 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/5e120364/attachment-0001.png 

From bburke at redhat.com  Thu Jan 28 11:12:58 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 11:12:58 -0500
Subject: [keycloak-dev] Fwd: Bad Request
In-Reply-To: <CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
References: <CAGGeCYN3JWP4iw3rrh+8GbR8_PfdSr75nYL_hLCvKgyrZEVQiQ@mail.gmail.com>
	<CAGGeCYOEMPOQM7=ZSZ2+JzNP6SbTsHS4BpHsTDAAsMYYTyqVMA@mail.gmail.com>
	<CAGGeCYMXYYeN7HyuXtERvyQst9ZT1o21tVH2uBdLFPoT+Tw+UQ@mail.gmail.com>
Message-ID: <56AA3E0A.4030208@redhat.com>

Then you probably haven't set u the roles correctly for the user that is 
logging in.

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

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

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

From Shankar_Bhaskaran at infosys.com  Thu Jan 28 13:31:43 2016
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Thu, 28 Jan 2016 18:31:43 +0000
Subject: [keycloak-dev] Pentaho with Keycloak (SSO)
Message-ID: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>

Hi ,

I am trying to set up keycloak with pentaho 6 which uses spring 2.5 security. The application server on which pentaho war runs is Tomcat 8.  For that I will need the spring adapter with the dependencies . Could you direct  me the download link for  the same .  Pentaho now supports CAS. Do we have any documentation for implementing keycloak with pentaho 6. I have attached the spring security xml of pentaho and also the cas xml for SSO .

On checking with Pentaho on integration with keycloak they replied as given below

"If Keycloak can authenticate a visitor via a webservice, you can write the Spring Security based Pentaho extensions to authenticate using Keycloak. Again, we don't directly support Keycloak, but I can give you information about how to switch to a web services based authentication and authorization system. "

Regards,
Shankar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/185a7131/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: applicationContext-spring-security.xml
Type: text/xml
Size: 16448 bytes
Desc: applicationContext-spring-security.xml
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/185a7131/attachment-0002.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: applicationContext-spring-security-cas.xml
Type: text/xml
Size: 10535 bytes
Desc: applicationContext-spring-security-cas.xml
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/185a7131/attachment-0003.xml 

From bburke at redhat.com  Thu Jan 28 13:46:08 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 13:46:08 -0500
Subject: [keycloak-dev] Pentaho with Keycloak (SSO)
In-Reply-To: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>
References: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>
Message-ID: <56AA61F0.1040006@redhat.com>

They don't have SAML integration?  You could authenticate via a web 
service, but then you lose 90% of Keycloaks features.

On 1/28/2016 1:31 PM, Shankar_Bhaskaran wrote:
>
> Hi ,
>
> I am trying to set up keycloak with pentaho 6 which uses spring 2.5 
> security. The application server on which pentaho war runs is Tomcat 
> 8.  For that I will need the spring adapter with the dependencies . 
> Could you direct  me the download link for  the same .  Pentaho now 
> supports CAS. Do we have any documentation for implementing keycloak 
> with pentaho 6. I have attached the spring security xml of pentaho and 
> also the cas xml for SSO .
>
> On checking with Pentaho on integration with keycloak they replied as 
> given below
>
> ?If Keycloak can authenticate a visitor via a webservice, you can 
> write the Spring Security based Pentaho extensions to authenticate 
> using Keycloak. Again, we don't directly support Keycloak, but I can 
> give you information about how to switch to a web services based 
> authentication and authorization system. ?
>
> Regards,
>
> Shankar
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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

From Shankar_Bhaskaran at infosys.com  Thu Jan 28 14:18:41 2016
From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran)
Date: Thu, 28 Jan 2016 19:18:41 +0000
Subject: [keycloak-dev] Pentaho with Keycloak (SSO)
In-Reply-To: <56AA61F0.1040006@redhat.com>
References: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>
	<56AA61F0.1040006@redhat.com>
Message-ID: <1b114d6e8ae14fca8bd619c5912500b8@CHNSHLMBX33.ad.infosys.com>

But will not the spring adapter work ? Also do you have a link where I can download the spring adapter and its dependencies ?
Also is it enough to add spring adapter and its dependencies to the pentaho.war web-inf/lib?

Regards,
Shankar

From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Bill Burke
Sent: Friday, January 29, 2016 12:16 AM
To: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Pentaho with Keycloak (SSO)

They don't have SAML integration?  You could authenticate via a web service, but then you lose 90% of Keycloaks features.
On 1/28/2016 1:31 PM, Shankar_Bhaskaran wrote:
Hi ,

I am trying to set up keycloak with pentaho 6 which uses spring 2.5 security. The application server on which pentaho war runs is Tomcat 8.  For that I will need the spring adapter with the dependencies . Could you direct  me the download link for  the same .  Pentaho now supports CAS. Do we have any documentation for implementing keycloak with pentaho 6. I have attached the spring security xml of pentaho and also the cas xml for SSO .

On checking with Pentaho on integration with keycloak they replied as given below

"If Keycloak can authenticate a visitor via a webservice, you can write the Spring Security based Pentaho extensions to authenticate using Keycloak. Again, we don't directly support Keycloak, but I can give you information about how to switch to a web services based authentication and authorization system. "

Regards,
Shankar




_______________________________________________

keycloak-dev mailing list

keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-dev



--

Bill Burke

JBoss, a division of Red Hat

http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160128/03f16963/attachment.html 

From bburke at redhat.com  Thu Jan 28 15:29:17 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 15:29:17 -0500
Subject: [keycloak-dev] Pentaho with Keycloak (SSO)
In-Reply-To: <1b114d6e8ae14fca8bd619c5912500b8@CHNSHLMBX33.ad.infosys.com>
References: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>
	<56AA61F0.1040006@redhat.com>
	<1b114d6e8ae14fca8bd619c5912500b8@CHNSHLMBX33.ad.infosys.com>
Message-ID: <56AA7A1D.1080404@redhat.com>

We don't have a download for spring adapter.  Create empty WAR in maven:

http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-security-adapter

Then you'll know the dependencies.

On 1/28/2016 2:18 PM, Shankar_Bhaskaran wrote:
>
> But will not the spring adapter work ? Also do you have a link where I 
> can download the spring adapter and its dependencies ?
>
> Also is it enough to add spring adapter and its dependencies to the 
> pentaho.war web-inf/lib?
>
> Regards,
>
> Shankar
>
> *From:*keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Bill Burke
> *Sent:* Friday, January 29, 2016 12:16 AM
> *To:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Pentaho with Keycloak (SSO)
>
> They don't have SAML integration?  You could authenticate via a web 
> service, but then you lose 90% of Keycloaks features.
>
> On 1/28/2016 1:31 PM, Shankar_Bhaskaran wrote:
>
>     Hi ,
>
>     I am trying to set up keycloak with pentaho 6 which uses spring
>     2.5 security. The application server on which pentaho war runs is
>     Tomcat 8.  For that I will need the spring adapter with the
>     dependencies . Could you direct  me the download link for  the
>     same .  Pentaho now supports CAS. Do we have any documentation for
>     implementing keycloak with pentaho 6. I have attached the spring
>     security xml of pentaho and also the cas xml for SSO .
>
>     On checking with Pentaho on integration with keycloak they replied
>     as given below
>
>     ?If Keycloak can authenticate a visitor via a webservice, you can
>     write the Spring Security based Pentaho extensions to authenticate
>     using Keycloak. Again, we don't directly support Keycloak, but I
>     can give you information about how to switch to a web services
>     based authentication and authorization system. ?
>
>     Regards,
>
>     Shankar
>
>
>
>
>     _______________________________________________
>
>     keycloak-dev mailing list
>
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

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

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

From bburke at redhat.com  Thu Jan 28 15:29:53 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 15:29:53 -0500
Subject: [keycloak-dev] Pentaho with Keycloak (SSO)
In-Reply-To: <1b114d6e8ae14fca8bd619c5912500b8@CHNSHLMBX33.ad.infosys.com>
References: <72bf8ec21ab745cb82c15e938500c81c@CHNSHLMBX33.ad.infosys.com>
	<56AA61F0.1040006@redhat.com>
	<1b114d6e8ae14fca8bd619c5912500b8@CHNSHLMBX33.ad.infosys.com>
Message-ID: <56AA7A41.7030003@redhat.com>

One more thing, doesn't Spring Security have a SAML adapter?  You could 
probably use that.

On 1/28/2016 2:18 PM, Shankar_Bhaskaran wrote:
>
> But will not the spring adapter work ? Also do you have a link where I 
> can download the spring adapter and its dependencies ?
>
> Also is it enough to add spring adapter and its dependencies to the 
> pentaho.war web-inf/lib?
>
> Regards,
>
> Shankar
>
> *From:*keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] *On Behalf Of *Bill Burke
> *Sent:* Friday, January 29, 2016 12:16 AM
> *To:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Pentaho with Keycloak (SSO)
>
> They don't have SAML integration?  You could authenticate via a web 
> service, but then you lose 90% of Keycloaks features.
>
> On 1/28/2016 1:31 PM, Shankar_Bhaskaran wrote:
>
>     Hi ,
>
>     I am trying to set up keycloak with pentaho 6 which uses spring
>     2.5 security. The application server on which pentaho war runs is
>     Tomcat 8.  For that I will need the spring adapter with the
>     dependencies . Could you direct  me the download link for  the
>     same .  Pentaho now supports CAS. Do we have any documentation for
>     implementing keycloak with pentaho 6. I have attached the spring
>     security xml of pentaho and also the cas xml for SSO .
>
>     On checking with Pentaho on integration with keycloak they replied
>     as given below
>
>     ?If Keycloak can authenticate a visitor via a webservice, you can
>     write the Spring Security based Pentaho extensions to authenticate
>     using Keycloak. Again, we don't directly support Keycloak, but I
>     can give you information about how to switch to a web services
>     based authentication and authorization system. ?
>
>     Regards,
>
>     Shankar
>
>
>
>
>     _______________________________________________
>
>     keycloak-dev mailing list
>
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

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

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

From bburke at redhat.com  Thu Jan 28 23:34:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Thu, 28 Jan 2016 23:34:07 -0500
Subject: [keycloak-dev] saml client adapter changes incoming in 1.9
Message-ID: <56AAEBBF.6040903@redhat.com>

FYI, heads up:

A major change to our Keycloak saml client adapter is coming (PR 
buildling right now).  Basically you'll need to register a specific 
endpoint with your IDPs.  Before it was really any secure URL.  You must 
now register /saml.

i.e.

https://example.com/<context-root>/saml

The reason for this is that SAML POST binding would eat the HttpRequest 
input stream for any secured URL.  This can be bad if you are uploading 
to a secure URL :)

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


From sthorger at redhat.com  Fri Jan 29 07:25:45 2016
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 29 Jan 2016 13:25:45 +0100
Subject: [keycloak-dev] Keycloak 1.8.0.Final release
Message-ID: <CAJgngAesekKth_+5_XAEQZR-se96494Z0CzdCY0ts+o3q9D-yw@mail.gmail.com>

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

From bburke at redhat.com  Fri Jan 29 13:49:07 2016
From: bburke at redhat.com (Bill Burke)
Date: Fri, 29 Jan 2016 13:49:07 -0500
Subject: [keycloak-dev] =?utf-8?q?Fwd=3A_=5Bkeycloak=5D_KEYCLOAK-2292_Brok?=
 =?utf-8?q?er_login=3A_remove_identity_provider_prefix_from_auto=E2=80=A6_?=
 =?utf-8?b?KCMyMTQxKQ==?=
In-Reply-To: <keycloak/keycloak/pull/2141@github.com>
References: <keycloak/keycloak/pull/2141@github.com>
Message-ID: <56ABB423.9070509@redhat.com>

Can I ask why we did this?  There will be name clashes.  User has the 
power to change the name mapping already, don't they?


-------- Forwarded Message --------
Subject: 	[keycloak] KEYCLOAK-2292 Broker login: remove identity 
provider prefix from auto? (#2141)
Date: 	Fri, 29 Jan 2016 09:43:47 -0800
From: 	Marek Posolda <notifications at github.com>
Reply-To: 	keycloak/keycloak 
<reply+000abeef51cc88b4da9732edfddbd34fa49c6a261b2d314092cf0000000112c366d392a169ce07bd2342 at reply.github.com> 

To: 	keycloak/keycloak <keycloak at noreply.github.com>



?generated username

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


        You can view, comment on, or merge this pull request online at:

https://github.com/keycloak/keycloak/pull/2141


        Commit Summary

  * KEYCLOAK-2292 Broker login: remove identity provider prefix from
    autogenerated username


        File Changes

  * *M*
    services/src/main/java/org/keycloak/services/resources/IdentityBrokerService.java
    <https://github.com/keycloak/keycloak/pull/2141/files#diff-0> (2)
  * *M*
    testsuite/integration/src/test/java/org/keycloak/testsuite/broker/AbstractIdentityProviderTest.java
    <https://github.com/keycloak/keycloak/pull/2141/files#diff-1> (2)
  * *M*
    testsuite/integration/src/test/java/org/keycloak/testsuite/broker/AbstractKeycloakIdentityProviderTest.java
    <https://github.com/keycloak/keycloak/pull/2141/files#diff-2> (4)
  * *M*
    testsuite/integration/src/test/java/org/keycloak/testsuite/broker/PostBrokerFlowTest.java
    <https://github.com/keycloak/keycloak/pull/2141/files#diff-3> (10)


        Patch Links:

  * https://github.com/keycloak/keycloak/pull/2141.patch
  * https://github.com/keycloak/keycloak/pull/2141.diff

?
Reply to this email directly or view it on GitHub 
<https://github.com/keycloak/keycloak/pull/2141>.


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



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

From mposolda at redhat.com  Fri Jan 29 16:30:40 2016
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 29 Jan 2016 22:30:40 +0100
Subject: [keycloak-dev]
 =?utf-8?q?Fwd=3A_=5Bkeycloak=5D_KEYCLOAK-2292_Brok?=
 =?utf-8?q?er_login=3A_remove_identity_provider_prefix_from_auto=E2=80=A6_?=
 =?utf-8?b?KCMyMTQxKQ==?=
In-Reply-To: <56ABB423.9070509@redhat.com>
References: <keycloak/keycloak/pull/2141@github.com>
	<56ABB423.9070509@redhat.com>
Message-ID: <56ABDA00.9030602@redhat.com>

We agreed on this in some other thread: 
http://lists.jboss.org/pipermail/keycloak-dev/2016-January/006243.html

By default, firstBrokerLogin flow addresses conflicts in both email and 
username. So conflict in username can now be easily resolved and 
accounts can be linked at login time. So there is not much need to use 
tricky usernames like "brokerID.brokerUsername" anymore.

This PR addresses just default behaviour. If username mapper is used, it 
has always precedence. So there is still possibility to go back to 
previous behaviour or configure username template however you want.

Marek

On 29/01/16 19:49, Bill Burke wrote:
> Can I ask why we did this?  There will be name clashes.  User has the 
> power to change the name mapping already, don't they?
>
>
> -------- Forwarded Message --------
> Subject: 	[keycloak] KEYCLOAK-2292 Broker login: remove identity 
> provider prefix from auto? (#2141)
> Date: 	Fri, 29 Jan 2016 09:43:47 -0800
> From: 	Marek Posolda <notifications at github.com>
> Reply-To: 	keycloak/keycloak 
> <reply+000abeef51cc88b4da9732edfddbd34fa49c6a261b2d314092cf0000000112c366d392a169ce07bd2342 at reply.github.com> 
>
> To: 	keycloak/keycloak <keycloak at noreply.github.com>
>
>
>
> ?generated username
>
> ------------------------------------------------------------------------
>
>
>         You can view, comment on, or merge this pull request online at:
>
> https://github.com/keycloak/keycloak/pull/2141
>
>
>         Commit Summary
>
>   * KEYCLOAK-2292 Broker login: remove identity provider prefix from
>     autogenerated username
>
>
>         File Changes
>
>   * *M*
>     services/src/main/java/org/keycloak/services/resources/IdentityBrokerService.java
>     <https://github.com/keycloak/keycloak/pull/2141/files#diff-0> (2)
>   * *M*
>     testsuite/integration/src/test/java/org/keycloak/testsuite/broker/AbstractIdentityProviderTest.java
>     <https://github.com/keycloak/keycloak/pull/2141/files#diff-1> (2)
>   * *M*
>     testsuite/integration/src/test/java/org/keycloak/testsuite/broker/AbstractKeycloakIdentityProviderTest.java
>     <https://github.com/keycloak/keycloak/pull/2141/files#diff-2> (4)
>   * *M*
>     testsuite/integration/src/test/java/org/keycloak/testsuite/broker/PostBrokerFlowTest.java
>     <https://github.com/keycloak/keycloak/pull/2141/files#diff-3> (10)
>
>
>         Patch Links:
>
>   * https://github.com/keycloak/keycloak/pull/2141.patch
>   * https://github.com/keycloak/keycloak/pull/2141.diff
>
> ?
> Reply to this email directly or view it on GitHub 
> <https://github.com/keycloak/keycloak/pull/2141>.
>
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Sat Jan 30 09:18:10 2016
From: bburke at redhat.com (Bill Burke)
Date: Sat, 30 Jan 2016 09:18:10 -0500
Subject: [keycloak-dev] client export import?
Message-ID: <56ACC622.4050505@redhat.com>

Can we export/import an individual client to and from the 
ClientRepresentation format?  This will be crucial for debugging 
problems in support cases.

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


From ssilvert at redhat.com  Sun Jan 31 13:59:48 2016
From: ssilvert at redhat.com (Stan Silvert)
Date: Sun, 31 Jan 2016 13:59:48 -0500
Subject: [keycloak-dev] client export import?
In-Reply-To: <56ACC622.4050505@redhat.com>
References: <56ACC622.4050505@redhat.com>
Message-ID: <56AE59A4.302@redhat.com>

On 1/30/2016 9:18 AM, Bill Burke wrote:
> Can we export/import an individual client to and from the
> ClientRepresentation format?  This will be crucial for debugging
> problems in support cases.
>
We have partial import for that.  However, the partial export 
implementation has been put aside for other things.  Today the customer 
would need to do a full export of the realm.

Stan

From thomas.darimont at googlemail.com  Sun Jan 31 17:47:10 2016
From: thomas.darimont at googlemail.com (Thomas Darimont)
Date: Sun, 31 Jan 2016 23:47:10 +0100
Subject: [keycloak-dev] Keycloak vs. midPoint vs. Apache Syncope
Message-ID: <CAK-7U1htm=X8izA8ZV9kmfDcCt+iNDZnvJQ_suM2MURkRB2H8A@mail.gmail.com>

Hello group,

whilst browsing the security talks of this weeks FOSDEM 2016 [0],
I stumbled upon two open source Identity Management solutions
in that presentation [0.1] which I was totally unaware of:
midpoint [1] [1.1] by evolveum and the Syncope [2] Apache project.

Since I think that those could serve (at least) as an inspiration
for Keycloak I wanted to share this with you.

Midpoint seems to be a pretty mature product with good documentation and
a wide feature palette as one can see here: [1.2].
Some of of those features might also be worth to be added to keycloak, e.g.:
- Detailed information about user attribute / configuration changes via
Deltas [1.3], [1.5]
- Parametric Roles as part of their Hybrid RBAC support [1.4]
- Support for Segregation of Duties by Role Exclusions [1.6]

SSO support in midPoint is provided by a Spring Security integration
as well as support for CAS, but I could not find an implementation for
OAuth 2.0, Open ID Connect nor SAML - only a Google Summer of Code 2015
OAuth / Open Id Connect integration proposal.

Midpoint seems to be a fully fledged IAM solution already but, IMHO with a
much broader scope (enterprise IdM, IAM) than Keycloak (IdM for cloud
products).

Syncope [2.1] on the other hand seems to an effort to reimplement an
IdM (provisioning) solution from scratch.

Has anybody here heared of or investigated those projects?

[0] https://fosdem.org/2016/schedule/track/security/
[0.1] https://fosdem.org/2016/schedule/event/midpointidm/
[1] https://evolveum.com/midpoint/
[1.1] https://github.com/Evolveum/midpoint
[1.2] https://wiki.evolveum.com/display/midPoint/Features
[1.3] https://wiki.evolveum.com/display/midPoint/Deltas
[1.4] https://wiki.evolveum.com/display/midPoint/Advanced+Hybrid+RBAC
[1.5] https://wiki.evolveum.com/display/midPoint/Relativity
[1.6] https://wiki.evolveum.com/display/midPoint/Segregation+of+Duties
[2] https://syncope.apache.org/
[2.1] https://github.com/apache/syncope

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

From parul.com at gmail.com  Sun Jan 31 23:11:29 2016
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Mon, 1 Feb 2016 09:41:29 +0530
Subject: [keycloak-dev] Keycloak SAML response 'Destination' Element is
 always validated.
In-Reply-To: <56AA360F.9050801@redhat.com>
References: <CAFj68vV0w88S7Z1HZyry3nUxvqdkr7DAfVALOKuOkce4LFOBmQ@mail.gmail.com>
	<56AA269D.1070204@redhat.com>
	<CAFj68vXjKjoYH_2WHFcD0zjXE_4nLyURYFDSOOebchoNFYjJig@mail.gmail.com>
	<56AA360F.9050801@redhat.com>
Message-ID: <CAFj68vUtyBqyDYf5ot1ncZqiASy9RcY39U+Z-xVk=4_zYsKToA@mail.gmail.com>

Hi Bill,
As per SAML spec, this Destination element is optional. does not this
validation is optional.

SAML Spec says,

Destination [Optional]

A URI reference indicating the address to which this request has been sent.
This is useful to prevent

malicious forwarding of requests to unintended recipients, a protection
that is required by some

protocol bindings. If it is present, the actual recipient MUST check that
the URI reference identifies the

location at which the message was received. If it does not, the request
MUST be discarded. Some

protocol bindings may require the use of this attribute (see [SAMLBind]).


On Thu, Jan 28, 2016 at 9:08 PM, Bill Burke <bburke at redhat.com> wrote:

> IMO, they should provide it irregardless.
>
>
> On 1/28/2016 10:21 AM, Arulkumar Ponnusamy wrote:
>
> Yep.. We are trying to integrate with Ping Federate IDP and it causing the
> authentication failure. But, Ping federate does not give Destination
> element  for signed xml too which we need to follow up with Ping federate.
> On 28-Jan-2016 8:03 PM, "Bill Burke" <bburke at redhat.com> wrote:
>
>> Yes, we validate it.  Is this a problem with some third party saml
>> integration?
>>
>> On 1/28/2016 5:31 AM, Arulkumar Ponnusamy wrote:
>>
>> As per OASIS/SAML spec recommendation, If the message is signed, the
>> Destination XML attribute in the root SAML element of the protocol message
>> MUST contain the URL to which the sender has instructed the user agent to
>> deliver the message. The recipient MUST then verify that the value matches
>> the location at which the message has been received.
>>
>> However, in keycloak, always validate the 'Destination'  on saml
>> response. irrespective of response is signed or not.
>>
>> is not a defect?
>>
>> Thanks,
>> Arul kumar P.
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hathttp://bill.burkecentral.com
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160201/ce2c6179/attachment.html