From stian at redhat.com  Tue Sep  1 02:04:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 1 Sep 2015 02:04:08 -0400 (EDT)
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <55E46032.3040101@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
	<55E46032.3040101@redhat.com>
Message-ID: <1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 31 August, 2015 4:09:54 PM
> Subject: Re: [keycloak-dev] refactored admin reset email and required actions
> 
> 
> 
> On 8/31/2015 7:06 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Saturday, 22 August, 2015 3:31:56 AM
> >> Subject: [keycloak-dev] refactored admin reset email and required actions
> >>
> >> Admin console can send a reset password email to the user.  Originally
> >> it just executed update password.  I changed this so that it sets an
> >> Update Password required action on the User.  The email link click runs
> >> all required actions set for the user, then displays a message that the
> >> Account has been updated.
> >
> > The admin console could do either - set a password (and choose if it was
> > temporary or not) as well as send a reset password link
> >
> 
> Admin console can still manually set the password (temporary or not).
> 
> 
> >>
> >> When I get back, I'm also going to change the admin console behavior and
> >> look too.  Instead of a "Reset Password Email" button on Credentials
> >> tab, there will be a button next to the Required Actions selection box
> >> on user detail, something like "Email Required Actions"  (I need a
> >> better name).  Clicking on this button will send an email to user
> >
> > This isn't the correct approach IMO. What we used to have was the ability
> > for an admin to send an email to a user to allow the user to recover the
> > password. It wasn't a required action, just something the user could do if
> > they needed to. I think how it worked before was much clearer to end
> > users, also credentials tab is the correct place for "recovering
> > password".
> >
> 
> 
> I'll repeat myself.  There may be more than one credential the
> admin/user needs/wants to reset.  These credentials may also be custom
> ones written by an system integrator.  I don't want to introduce yet
> another SPI for credential recovery when it would work exactly the same
> way as required actions.  Now, there is one place the admin can email
> the user to perform any specific action.

Recovering credentials is not a required action. It's an optional action the user may do, but the user should also be allowed to not do it. Also, it belongs on the credentials tab. I'm fairly sure no one is going to find it otherwise.

It doesn't have to be yet another SPI, but maybe we could add a type enum or something to the current SPI. Also, we could add support for optional actions?

> 
> If you want to create a separate SPI and way of doing this to support
> reset of more than just password, feel free to create that SPI, extend
> the Model API, write the tests, update the docs and create new examples
> and make sure the flow is configurable. I think this approach is fine.

I know we have a lot of work to do, but usability has to always be considered. One of the main reasons I was interested in Keycloak was to create something that would make security easier for users, admins and developers. I feel that if we continue adding and changing things without considering usability we could just end up with being yet another hard to use product with all sorts of features.

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

From andipansa at gmail.com  Tue Sep  1 05:31:36 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Tue, 1 Sep 2015 11:31:36 +0200
Subject: [keycloak-dev] AD Role Mapping
Message-ID: <CAA0ckM4uUOpkzrAwX1ML=qP8hrsr4aySiV5iT7JAG9d543DOSg@mail.gmail.com>

Hi,

I'm trying to deploy keycloak in my company as primary SSO solution with AD
underneath.

In our company AD groups contain other groups as members.

e.g.:
Let assume that we have Group1, Group1.1. and TestUser.

Group1 has Group1.1 as a member and Group 1.1 contains user TestUser.
In that configuration after importing AD users to Keycloak, TestUser should
have two roles: Group1 has Group1.1. But unfortunately it has only Group1.1.

I'm not an AD expert but I hope I've managed to explain the problem well
enough.

This is very important feature for my company and I wonder to know if you
are to solve this problem in the nearest feature?

Best Regards,
 Andrzej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150901/069edefd/attachment.html 

From stian at redhat.com  Tue Sep  1 10:22:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 1 Sep 2015 10:22:27 -0400 (EDT)
Subject: [keycloak-dev] Planning to merge upgrade to AngularJS 1.4 tomorrow
In-Reply-To: <492786613.23705435.1441117292840.JavaMail.zimbra@redhat.com>
Message-ID: <669788455.23705981.1441117347078.JavaMail.zimbra@redhat.com>

I'm planning to merge the PR to upgrade to AngularJS 1.4 tomorrow. If anyone has large uncommitted changes to the console or for some other reason wants this to be held back a day let me know asap.

From mikhail.kuznetsov at hpe.com  Tue Sep  1 13:18:16 2015
From: mikhail.kuznetsov at hpe.com (Kuznetsov, Mike)
Date: Tue, 1 Sep 2015 17:18:16 +0000
Subject: [keycloak-dev] Implementation of SCIM with Keycloak
Message-ID: <66122567ABACCC42B5B568EC7E90551A1A193EF8@G1W3651.americas.hpqcorp.net>

Hello,

My team is currently investigating Keycloak. We also have an interest in using System for Cross-domain Identity Management (SCIM) for provisioning (http://www.simplecloud.info ).

I did not see any documentation about SCIM support in Keycloak, and I have not seen any references to SCIM in the code.

Could you please tell me if there are any plans to add SCIM support to Keycloak?

Thank You,

Mikhail Kuznetsov
Software Engineer
Hewlett Packard Enterprise

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

From bburke at redhat.com  Tue Sep  1 16:42:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 1 Sep 2015 16:42:03 -0400
Subject: [keycloak-dev] Implementation of SCIM with Keycloak
In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1A193EF8@G1W3651.americas.hpqcorp.net>
References: <66122567ABACCC42B5B568EC7E90551A1A193EF8@G1W3651.americas.hpqcorp.net>
Message-ID: <55E60D9B.6000207@redhat.com>

We don't have any SCIM support.  It might be on the roadmap somewhere as 
we've talked about it in the past, but you're the first to ask for it. 
We would definitely welcome contributions around SCIM.

On 9/1/2015 1:18 PM, Kuznetsov, Mike wrote:
> Hello,
>
> My team is currently investigating Keycloak. We also have an interest in
> using System for Cross-domain Identity Management (SCIM) for
> provisioning (http://www.simplecloud.info ).
>
> I did not see any documentation about SCIM support in Keycloak, and I
> have not seen any references to SCIM in the code.
>
> Could you please tell me if there are any plans to add SCIM support to
> Keycloak?
>
> Thank You,
>
>
> *Mikhail Kuznetsov*
>
> Software Engineer
>
> Hewlett Packard Enterprise
>
>
>
> _______________________________________________
> 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 Sep  2 01:22:12 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 2 Sep 2015 07:22:12 +0200
Subject: [keycloak-dev] AD Role Mapping
In-Reply-To: <CAA0ckM4uUOpkzrAwX1ML=qP8hrsr4aySiV5iT7JAG9d543DOSg@mail.gmail.com>
References: <CAA0ckM4uUOpkzrAwX1ML=qP8hrsr4aySiV5iT7JAG9d543DOSg@mail.gmail.com>
Message-ID: <55E68784.8080108@redhat.com>

I agree that supporting this will be good. Could you please create JIRA 
for it? I likely won't be able to look at it before 1.5 release, but 
hopefully it should be possible for 1.6 release (which is around end of 
September or begin of October or so).

Question: are your Group1 and Group1.1 in same branch of LDAP tree (in 
other words, you are using same Role mapper for both)?

I am actually thinking about 2 possible approaches for implement it. 
Both have some pros and cons:
1) Recursively search LDAP during each search of user memberships
2) Use Keycloak composite roles

In both cases, it will be some option on RoleMapper, so it's possible to 
enable/disable this behaviour on demand.

Thanks,
Marek

On 01/09/15 11:31, Andrzej Go?awski wrote:
> Hi,
>
> I'm trying to deploy keycloak in my company as primary SSO solution 
> with AD underneath.
>
> In our company AD groups contain other groups as members.
>
> e.g.:
> Let assume that we have Group1, Group1.1. and TestUser.
>
> Group1 has Group1.1 as a member and Group 1.1 contains user TestUser.
> In that configuration after importing AD users to Keycloak, TestUser 
> should have two roles: Group1 has Group1.1. But unfortunately it has 
> only Group1.1.
>
> I'm not an AD expert but I hope I've managed to explain the problem 
> well enough.
>
> This is very important feature for my company and I wonder to know if 
> you are to solve this problem in the nearest feature?
>
> Best Regards,
>  Andrzej
>
>
> _______________________________________________
> 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/20150902/9897d1ba/attachment.html 

From hermann.hill at optile.net  Wed Sep  2 03:42:20 2015
From: hermann.hill at optile.net (Hermann Hill)
Date: Wed, 2 Sep 2015 07:42:20 +0000
Subject: [keycloak-dev] UserSession creation/removal notification/event?
Message-ID: <DB3PR05MB378B7BA4F70869C53DE06D4FC690@DB3PR05MB378.eurprd05.prod.outlook.com>

Hi all,

as a follow-up to my previous question: Is there an event or a notification interface for the creation and removal of sessions? I already found LOGIN and LOGOUT, but if a user session expires or the user is forcibly logged out by an admin it seems there is no LOGOUT event.

Best regards,

Hermann Josef Hill
Software Architect

optile GmbH
Ganghoferstra?e 39 | 80339 M?nchen
Mobil +49 (151) 5385 0784

hermann.hill at optile.net | www.optile.net

USt.Id.-Nr. DE268847980
Gesch?ftsf?hrer: Daniel Smeds, Stefan Reinhardt
Handelsregister M?nchen HRB 183178

+++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle 7.1 Stand F013 +++

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

From stian at redhat.com  Wed Sep  2 03:45:36 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 2 Sep 2015 03:45:36 -0400 (EDT)
Subject: [keycloak-dev] UserSession creation/removal notification/event?
In-Reply-To: <DB3PR05MB378B7BA4F70869C53DE06D4FC690@DB3PR05MB378.eurprd05.prod.outlook.com>
References: <DB3PR05MB378B7BA4F70869C53DE06D4FC690@DB3PR05MB378.eurprd05.prod.outlook.com>
Message-ID: <160685204.24255573.1441179936230.JavaMail.zimbra@redhat.com>

Please use user mailing list for support questions

----- Original Message -----
> From: "Hermann Hill" <hermann.hill at optile.net>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 2 September, 2015 9:42:20 AM
> Subject: [keycloak-dev] UserSession creation/removal notification/event?
> 
> 
> 
> Hi all,
> 
> 
> 
> as a follow-up to my previous question: Is there an event or a notification
> interface for the creation and removal of sessions? I already found LOGIN
> and LOGOUT, but if a user session expires or the user is forcibly logged out
> by an admin it seems there is no LOGOUT event.
> 
> 
> 
> Best regards,
> 
> 
> 
> Hermann Josef Hill
> Software Architect
> 
> optile GmbH
> Ganghoferstra?e 39 | 80339 M?nchen
> Mobil +49 (151) 5385 0784
> 
> hermann.hill at optile.net | www.optile.net
> 
> USt.Id.-Nr. DE268847980
> Gesch?ftsf?hrer: Daniel Smeds, Stefan Reinhardt
> Handelsregister M?nchen HRB 183178
> 
> +++ Besuchen Sie uns auf der dmexco 2015 am 16. & 17. September, K?ln, Halle
> 7.1 Stand F013 +++
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Sep  2 06:26:38 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 2 Sep 2015 06:26:38 -0400 (EDT)
Subject: [keycloak-dev] 1.5 release
In-Reply-To: <1141051218.24406409.1441189443015.JavaMail.zimbra@redhat.com>
Message-ID: <681911591.24409121.1441189598736.JavaMail.zimbra@redhat.com>

I'd like to have all JIRA issues completed by end of Tomorrow. Then we'll start testing on Friday and aim to release on Tuesday next week.

Are there any outstanding work that's not in JIRA (https://issues.jboss.org/issues/?filter=12322375)?

From stian at redhat.com  Wed Sep  2 08:44:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 2 Sep 2015 08:44:08 -0400 (EDT)
Subject: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
In-Reply-To: <1872219830.24500367.1441197792366.JavaMail.zimbra@redhat.com>
Message-ID: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>

I recently removed the memory user session provider and replaced it with Infinispan local caches. There's an issue with that on EAP though. Infinispan didn't support map reduce tasks on local caches until 5.3 and EAP 6.4 is on 5.2.

As a work around the Infinispan user session provider will fallback to the old deprecated memory user session provider if Infinispan is older than 5.3 and the cache is a local cache. The memory user session provider is not available as a standalone provider, just used internally by the Infinispan user session provider in this particular case.

Once we move to EAP 7 we can remove this work around.

From bburke at redhat.com  Wed Sep  2 09:06:24 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Sep 2015 09:06:24 -0400
Subject: [keycloak-dev] 1.5 release
In-Reply-To: <681911591.24409121.1441189598736.JavaMail.zimbra@redhat.com>
References: <681911591.24409121.1441189598736.JavaMail.zimbra@redhat.com>
Message-ID: <55E6F450.8050107@redhat.com>

I might want some extra time pending some discussion on the reset 
credential issue I'm about to respond to.

On 9/2/2015 6:26 AM, Stian Thorgersen wrote:
> I'd like to have all JIRA issues completed by end of Tomorrow. Then we'll start testing on Friday and aim to release on Tuesday next week.
>
> Are there any outstanding work that's not in JIRA (https://issues.jboss.org/issues/?filter=12322375)?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Wed Sep  2 09:12:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Sep 2015 09:12:07 -0400
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
	<55E46032.3040101@redhat.com>
	<1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>
Message-ID: <55E6F5A7.60002@redhat.com>



On 9/1/2015 2:04 AM, Stian Thorgersen wrote:
>> I'll repeat myself.  There may be more than one credential the
>> admin/user needs/wants to reset.  These credentials may also be custom
>> ones written by an system integrator.  I don't want to introduce yet
>> another SPI for credential recovery when it would work exactly the same
>> way as required actions.  Now, there is one place the admin can email
>> the user to perform any specific action.
>
> Recovering credentials is not a required action. It's an optional action the user may do, but the user should also be allowed to not do it. Also, it belongs on the credentials tab. I'm fairly sure no one is going to find it otherwise.
>
> It doesn't have to be yet another SPI, but maybe we could add a type enum or something to the current SPI. Also, we could add support for optional actions?
>
>>
>> If you want to create a separate SPI and way of doing this to support
>> reset of more than just password, feel free to create that SPI, extend
>> the Model API, write the tests, update the docs and create new examples
>> and make sure the flow is configurable. I think this approach is fine.
>
> I know we have a lot of work to do, but usability has to always be considered. One of the main reasons I was interested in Keycloak was to create something that would make security easier for users, admins and developers. I feel that if we continue adding and changing things without considering usability we could just end up with being yet another hard to use product with all sorts of features.
>

I was thinking about this a little more and I thought about the ability 
to add required actions to the ClientSession.  Those required actions 
would only have to be executed within that client session login and 
could be aborted.  Then user forgot password and admin reset would only 
set required actions for the clientsession and the actions become temporary.


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

From bburke at redhat.com  Wed Sep  2 09:13:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Sep 2015 09:13:05 -0400
Subject: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
In-Reply-To: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
References: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
Message-ID: <55E6F5E1.5050305@redhat.com>

Ugh, nasty...

On 9/2/2015 8:44 AM, Stian Thorgersen wrote:
> I recently removed the memory user session provider and replaced it with Infinispan local caches. There's an issue with that on EAP though. Infinispan didn't support map reduce tasks on local caches until 5.3 and EAP 6.4 is on 5.2.
>
> As a work around the Infinispan user session provider will fallback to the old deprecated memory user session provider if Infinispan is older than 5.3 and the cache is a local cache. The memory user session provider is not available as a standalone provider, just used internally by the Infinispan user session provider in this particular case.
>
> Once we move to EAP 7 we can remove this work around.
> _______________________________________________
> 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 stian at redhat.com  Wed Sep  2 09:20:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 2 Sep 2015 09:20:18 -0400 (EDT)
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <55E6F5A7.60002@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
	<55E46032.3040101@redhat.com>
	<1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>
	<55E6F5A7.60002@redhat.com>
Message-ID: <247447968.24531748.1441200018686.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 2 September, 2015 3:12:07 PM
> Subject: Re: [keycloak-dev] refactored admin reset email and required actions
> 
> 
> 
> On 9/1/2015 2:04 AM, Stian Thorgersen wrote:
> >> I'll repeat myself.  There may be more than one credential the
> >> admin/user needs/wants to reset.  These credentials may also be custom
> >> ones written by an system integrator.  I don't want to introduce yet
> >> another SPI for credential recovery when it would work exactly the same
> >> way as required actions.  Now, there is one place the admin can email
> >> the user to perform any specific action.
> >
> > Recovering credentials is not a required action. It's an optional action
> > the user may do, but the user should also be allowed to not do it. Also,
> > it belongs on the credentials tab. I'm fairly sure no one is going to find
> > it otherwise.
> >
> > It doesn't have to be yet another SPI, but maybe we could add a type enum
> > or something to the current SPI. Also, we could add support for optional
> > actions?
> >
> >>
> >> If you want to create a separate SPI and way of doing this to support
> >> reset of more than just password, feel free to create that SPI, extend
> >> the Model API, write the tests, update the docs and create new examples
> >> and make sure the flow is configurable. I think this approach is fine.
> >
> > I know we have a lot of work to do, but usability has to always be
> > considered. One of the main reasons I was interested in Keycloak was to
> > create something that would make security easier for users, admins and
> > developers. I feel that if we continue adding and changing things without
> > considering usability we could just end up with being yet another hard to
> > use product with all sorts of features.
> >
> 
> I was thinking about this a little more and I thought about the ability
> to add required actions to the ClientSession.  Those required actions
> would only have to be executed within that client session login and
> could be aborted.  Then user forgot password and admin reset would only
> set required actions for the clientsession and the actions become temporary.

How would that work for admin reset? Do we create a user/client session for those? I guess we do

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

From bburke at redhat.com  Wed Sep  2 09:34:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Sep 2015 09:34:48 -0400
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <247447968.24531748.1441200018686.JavaMail.zimbra@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
	<55E46032.3040101@redhat.com>
	<1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>
	<55E6F5A7.60002@redhat.com>
	<247447968.24531748.1441200018686.JavaMail.zimbra@redhat.com>
Message-ID: <55E6FAF8.80301@redhat.com>



On 9/2/2015 9:20 AM, Stian Thorgersen wrote:
>> I was thinking about this a little more and I thought about the ability
>> to add required actions to the ClientSession.  Those required actions
>> would only have to be executed within that client session login and
>> could be aborted.  Then user forgot password and admin reset would only
>> set required actions for the clientsession and the actions become temporary.
>
> How would that work for admin reset? Do we create a user/client session for those? I guess we do
>

We did before and we still do create a client/user session for admin reset.


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

From lkrzyzan at redhat.com  Wed Sep  2 10:05:44 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Wed, 2 Sep 2015 16:05:44 +0200
Subject: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
In-Reply-To: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
References: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
Message-ID: <1CA56047-9DEF-47F3-87E2-8C63266B1BB0@redhat.com>

Ouch ? question:

We have 2 nodes cluster to provide failover with user session replication.

Is this workaround needed? If yes, will user session be replicated to second node if first dies?

Thanks,

Libor Krzy?anek
jboss.org <http://jboss.org/> Development Team

> On 02 Sep 2015, at 14:44, Stian Thorgersen <stian at redhat.com> wrote:
> 
> I recently removed the memory user session provider and replaced it with Infinispan local caches. There's an issue with that on EAP though. Infinispan didn't support map reduce tasks on local caches until 5.3 and EAP 6.4 is on 5.2.
> 
> As a work around the Infinispan user session provider will fallback to the old deprecated memory user session provider if Infinispan is older than 5.3 and the cache is a local cache. The memory user session provider is not available as a standalone provider, just used internally by the Infinispan user session provider in this particular case.
> 
> Once we move to EAP 7 we can remove this work around.
> _______________________________________________
> 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/20150902/b487d5d1/attachment.html 

From bburke at redhat.com  Wed Sep  2 16:45:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 2 Sep 2015 16:45:31 -0400
Subject: [keycloak-dev] refactored admin reset email and required actions
In-Reply-To: <55E6FAF8.80301@redhat.com>
References: <55D7D10C.6030401@redhat.com>
	<1838995732.21980975.1441019175370.JavaMail.zimbra@redhat.com>
	<55E46032.3040101@redhat.com>
	<1094828981.22848601.1441087448745.JavaMail.zimbra@redhat.com>
	<55E6F5A7.60002@redhat.com>
	<247447968.24531748.1441200018686.JavaMail.zimbra@redhat.com>
	<55E6FAF8.80301@redhat.com>
Message-ID: <55E75FEB.3050807@redhat.com>

Ok, this stuff is all set.

On 9/2/2015 9:34 AM, Bill Burke wrote:
>
>
> On 9/2/2015 9:20 AM, Stian Thorgersen wrote:
>>> I was thinking about this a little more and I thought about the ability
>>> to add required actions to the ClientSession.  Those required actions
>>> would only have to be executed within that client session login and
>>> could be aborted.  Then user forgot password and admin reset would only
>>> set required actions for the clientsession and the actions become temporary.
>>
>> How would that work for admin reset? Do we create a user/client session for those? I guess we do
>>
>
> We did before and we still do create a client/user session for admin reset.
>
>

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

From stian at redhat.com  Thu Sep  3 02:13:02 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 02:13:02 -0400 (EDT)
Subject: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
In-Reply-To: <1CA56047-9DEF-47F3-87E2-8C63266B1BB0@redhat.com>
References: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
	<1CA56047-9DEF-47F3-87E2-8C63266B1BB0@redhat.com>
Message-ID: <1410367860.25101742.1441260782415.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Libor Krzy?anek" <lkrzyzan at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 2 September, 2015 4:05:44 PM
> Subject: Re: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
> 
> Ouch ? question:
> 
> We have 2 nodes cluster to provide failover with user session replication.
> 
> Is this workaround needed? If yes, will user session be replicated to second
> node if first dies?

In your case the workaround is not activated as you're using clustering. It's only activated for local cache (no clustering).

The reason we need the workaround is that we dropped our old mem user session provider in favor of always using Infinispan. In non-clustered mode it uses a local cache, but that didn't work on EAP 6.4, so we had to put in this temporary workaround.

> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
> > On 02 Sep 2015, at 14:44, Stian Thorgersen <stian at redhat.com> wrote:
> > 
> > I recently removed the memory user session provider and replaced it with
> > Infinispan local caches. There's an issue with that on EAP though.
> > Infinispan didn't support map reduce tasks on local caches until 5.3 and
> > EAP 6.4 is on 5.2.
> > 
> > As a work around the Infinispan user session provider will fallback to the
> > old deprecated memory user session provider if Infinispan is older than
> > 5.3 and the cache is a local cache. The memory user session provider is
> > not available as a standalone provider, just used internally by the
> > Infinispan user session provider in this particular case.
> > 
> > Once we move to EAP 7 we can remove this work around.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 


From stian at redhat.com  Thu Sep  3 03:04:25 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 03:04:25 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <269488042.25115385.1441263506884.JavaMail.zimbra@redhat.com>
Message-ID: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>

Currently the cancel button always redirects to the redirect_uri with error=access_denied. This is fine if the application wants to handle the rejected login. However, it does require the application to add logic/error handling to display a suitable error message to the user instead of just a generic 400 error page.

I propose we add a configuration option to clients for how the cancel button is handled. Options would be:

* None - don't display cancel button, this is useful when login is mandatory (for example our admin console)
* Error redirect - redirect to redirect_uri with error=access_denied
* Return to app - redirect to base_url of client (if this is set base_url would be required)

From lkrzyzan at redhat.com  Thu Sep  3 03:50:12 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Thu, 3 Sep 2015 09:50:12 +0200
Subject: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
In-Reply-To: <1410367860.25101742.1441260782415.JavaMail.zimbra@redhat.com>
References: <165552575.24500645.1441197848863.JavaMail.zimbra@redhat.com>
	<1CA56047-9DEF-47F3-87E2-8C63266B1BB0@redhat.com>
	<1410367860.25101742.1441260782415.JavaMail.zimbra@redhat.com>
Message-ID: <76E6539B-DE66-44B7-A007-A1E847CC64F7@redhat.com>

I see. Thanks for clarification.

Thanks,

Libor Krzy?anek
jboss.org <http://jboss.org/> Development Team

> On 03 Sep 2015, at 08:13, Stian Thorgersen <stian at redhat.com> wrote:
> 
> 
> 
> ----- Original Message -----
>> From: "Libor Krzy?anek" <lkrzyzan at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, 2 September, 2015 4:05:44 PM
>> Subject: Re: [keycloak-dev] Issues with Infinispan local cache on EAP 6.4
>> 
>> Ouch ? question:
>> 
>> We have 2 nodes cluster to provide failover with user session replication.
>> 
>> Is this workaround needed? If yes, will user session be replicated to second
>> node if first dies?
> 
> In your case the workaround is not activated as you're using clustering. It's only activated for local cache (no clustering).
> 
> The reason we need the workaround is that we dropped our old mem user session provider in favor of always using Infinispan. In non-clustered mode it uses a local cache, but that didn't work on EAP 6.4, so we had to put in this temporary workaround.
> 
>> 
>> Thanks,
>> 
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>> 
>>> On 02 Sep 2015, at 14:44, Stian Thorgersen <stian at redhat.com> wrote:
>>> 
>>> I recently removed the memory user session provider and replaced it with
>>> Infinispan local caches. There's an issue with that on EAP though.
>>> Infinispan didn't support map reduce tasks on local caches until 5.3 and
>>> EAP 6.4 is on 5.2.
>>> 
>>> As a work around the Infinispan user session provider will fallback to the
>>> old deprecated memory user session provider if Infinispan is older than
>>> 5.3 and the cache is a local cache. The memory user session provider is
>>> not available as a standalone provider, just used internally by the
>>> Infinispan user session provider in this particular case.
>>> 
>>> Once we move to EAP 7 we can remove this work around.
>>> _______________________________________________
>>> 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/20150903/7539c37a/attachment-0001.html 

From mposolda at redhat.com  Thu Sep  3 04:49:11 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 3 Sep 2015 10:49:11 +0200
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
Message-ID: <55E80987.5050005@redhat.com>

+1

I wonder that we can also improve one of the demo examples (eg. 
customer-portal ) to show the custom error page?

Marek

On 03/09/15 09:04, Stian Thorgersen wrote:
> Currently the cancel button always redirects to the redirect_uri with error=access_denied. This is fine if the application wants to handle the rejected login. However, it does require the application to add logic/error handling to display a suitable error message to the user instead of just a generic 400 error page.
>
> I propose we add a configuration option to clients for how the cancel button is handled. Options would be:
>
> * None - don't display cancel button, this is useful when login is mandatory (for example our admin console)
> * Error redirect - redirect to redirect_uri with error=access_denied
> * Return to app - redirect to base_url of client (if this is set base_url would be required)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Sep  3 05:22:39 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 05:22:39 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <55E80987.5050005@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E80987.5050005@redhat.com>
Message-ID: <318154360.25553048.1441272159022.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 3 September, 2015 10:49:11 AM
> Subject: Re: [keycloak-dev] Cancel button options for clients
> 
> +1
> 
> I wonder that we can also improve one of the demo examples (eg.
> customer-portal ) to show the custom error page?

That'd be good

> 
> Marek
> 
> On 03/09/15 09:04, Stian Thorgersen wrote:
> > Currently the cancel button always redirects to the redirect_uri with
> > error=access_denied. This is fine if the application wants to handle the
> > rejected login. However, it does require the application to add
> > logic/error handling to display a suitable error message to the user
> > instead of just a generic 400 error page.
> >
> > I propose we add a configuration option to clients for how the cancel
> > button is handled. Options would be:
> >
> > * None - don't display cancel button, this is useful when login is
> > mandatory (for example our admin console)
> > * Error redirect - redirect to redirect_uri with error=access_denied
> > * Return to app - redirect to base_url of client (if this is set base_url
> > would be required)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Thu Sep  3 08:36:18 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Sep 2015 08:36:18 -0400
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
Message-ID: <55E83EC2.3020909@redhat.com>

Maybe just remove cancel entirely for username/password page?  Keep the 
cancel button for OTP and other screens that are deeper in the flow.  If 
cancel is selected there, then just reset the flow and start login over. 
  Developers can decide to put in their own "back to application" 
buttons or menus by changing the template file.


On 9/3/2015 3:04 AM, Stian Thorgersen wrote:
> Currently the cancel button always redirects to the redirect_uri with error=access_denied. This is fine if the application wants to handle the rejected login. However, it does require the application to add logic/error handling to display a suitable error message to the user instead of just a generic 400 error page.
>
> I propose we add a configuration option to clients for how the cancel button is handled. Options would be:
>
> * None - don't display cancel button, this is useful when login is mandatory (for example our admin console)
> * Error redirect - redirect to redirect_uri with error=access_denied
> * Return to app - redirect to base_url of client (if this is set base_url would be required)
> _______________________________________________
> 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  Thu Sep  3 08:44:51 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 03 Sep 2015 08:44:51 -0400
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <55E80987.5050005@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E80987.5050005@redhat.com>
Message-ID: <55E840C3.2010609@redhat.com>

+1 from me too.  Ugly behavior right now.

On 9/3/2015 4:49 AM, Marek Posolda wrote:
> +1
>
> I wonder that we can also improve one of the demo examples (eg.
> customer-portal ) to show the custom error page?
>
> Marek
>
> On 03/09/15 09:04, Stian Thorgersen wrote:
>> Currently the cancel button always redirects to the redirect_uri with error=access_denied. This is fine if the application wants to handle the rejected login. However, it does require the application to add logic/error handling to display a suitable error message to the user instead of just a generic 400 error page.
>>
>> I propose we add a configuration option to clients for how the cancel button is handled. Options would be:
>>
>> * None - don't display cancel button, this is useful when login is mandatory (for example our admin console)
>> * Error redirect - redirect to redirect_uri with error=access_denied
>> * Return to app - redirect to base_url of client (if this is set base_url would be required)
>> _______________________________________________
>> 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 stian at redhat.com  Thu Sep  3 08:52:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 08:52:27 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <55E83EC2.3020909@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
Message-ID: <1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>

+1 That's simpler and cleaner. If anyone complains it's gone we'll just tell them how to add a back to app link to the template. If we get a lot of people demanding it then we can introduce the option I proposed.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 2:36:18 PM
> Subject: Re: [keycloak-dev] Cancel button options for clients
> 
> Maybe just remove cancel entirely for username/password page?  Keep the
> cancel button for OTP and other screens that are deeper in the flow.  If
> cancel is selected there, then just reset the flow and start login over.
>   Developers can decide to put in their own "back to application"
> buttons or menus by changing the template file.
> 
> 
> On 9/3/2015 3:04 AM, Stian Thorgersen wrote:
> > Currently the cancel button always redirects to the redirect_uri with
> > error=access_denied. This is fine if the application wants to handle the
> > rejected login. However, it does require the application to add
> > logic/error handling to display a suitable error message to the user
> > instead of just a generic 400 error page.
> >
> > I propose we add a configuration option to clients for how the cancel
> > button is handled. Options would be:
> >
> > * None - don't display cancel button, this is useful when login is
> > mandatory (for example our admin console)
> > * Error redirect - redirect to redirect_uri with error=access_denied
> > * Return to app - redirect to base_url of client (if this is set base_url
> > would be required)
> > _______________________________________________
> > 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 Sep  3 09:55:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Sep 2015 09:55:32 -0400
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
	<1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
Message-ID: <55E85154.70904@redhat.com>

Should cancel on the required action to the same thing?  What do other 
sites do when cancel is executed?

On 9/3/2015 8:52 AM, Stian Thorgersen wrote:
> +1 That's simpler and cleaner. If anyone complains it's gone we'll just tell them how to add a back to app link to the template. If we get a lot of people demanding it then we can introduce the option I proposed.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 3 September, 2015 2:36:18 PM
>> Subject: Re: [keycloak-dev] Cancel button options for clients
>>
>> Maybe just remove cancel entirely for username/password page?  Keep the
>> cancel button for OTP and other screens that are deeper in the flow.  If
>> cancel is selected there, then just reset the flow and start login over.
>>    Developers can decide to put in their own "back to application"
>> buttons or menus by changing the template file.
>>
>>
>> On 9/3/2015 3:04 AM, Stian Thorgersen wrote:
>>> Currently the cancel button always redirects to the redirect_uri with
>>> error=access_denied. This is fine if the application wants to handle the
>>> rejected login. However, it does require the application to add
>>> logic/error handling to display a suitable error message to the user
>>> instead of just a generic 400 error page.
>>>
>>> I propose we add a configuration option to clients for how the cancel
>>> button is handled. Options would be:
>>>
>>> * None - don't display cancel button, this is useful when login is
>>> mandatory (for example our admin console)
>>> * Error redirect - redirect to redirect_uri with error=access_denied
>>> * Return to app - redirect to base_url of client (if this is set base_url
>>> would be required)
>>> _______________________________________________
>>> 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

From stian at redhat.com  Thu Sep  3 09:57:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 09:57:04 -0400 (EDT)
Subject: [keycloak-dev] Loading message bundles from themes
In-Reply-To: <703906478.25949347.1441288329020.JavaMail.zimbra@redhat.com>
Message-ID: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>

You should load message bundles from themes not directly from the file system. That's how login pages and account management loads messages bundles so it should be consistent, but more importantly doing it through themes gives the following:

* Support for loading from file or classpath - we also have an SPI for theme loaders so they can in the future load resources from other sources as well, for example the database
* Supports overriding messages from themes - users can define custom themes that are used on a per-realm basis that can override messages. Themes even inherit messages from the theme it extends, so can choose to override only some messages

Themes expects the message bundle to be named "messages_<locale>.properties". I'd prefer it to be consistent between the 3 different things we have internationalized and such admin messages should be loaded from themes and the message bundles should have the same names.

We can then discuss with the translation team if they are happy with 3 separate message bundles or if they'd like a single message bundle for everything. We can also query about whether or not we can divide the message bundles up further. Dividing message bundles up would require adding support for that to themes as well. With classloaders and such it would be hard to implement a list available bundles so that's another reason for going with a single message bundle for now. 

From stian at redhat.com  Thu Sep  3 10:00:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 10:00:00 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <55E85154.70904@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
	<1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
	<55E85154.70904@redhat.com>
Message-ID: <113463715.25957769.1441288800080.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 3:55:32 PM
> Subject: Re: [keycloak-dev] Cancel button options for clients
> 
> Should cancel on the required action to the same thing?  What do other
> sites do when cancel is executed?

Had a look around and actually I had a hard time finding a site that had a cancel or back to application at all.

I don't think we should have a cancel on required action. A required action is something that the user has to perform to continue, so it makes no sense to let them cancel it.

However, the admin initiated actions (admin sends email with reset password) should ideally have a "Back to login" or something like that

> 
> On 9/3/2015 8:52 AM, Stian Thorgersen wrote:
> > +1 That's simpler and cleaner. If anyone complains it's gone we'll just
> > tell them how to add a back to app link to the template. If we get a lot
> > of people demanding it then we can introduce the option I proposed.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 3 September, 2015 2:36:18 PM
> >> Subject: Re: [keycloak-dev] Cancel button options for clients
> >>
> >> Maybe just remove cancel entirely for username/password page?  Keep the
> >> cancel button for OTP and other screens that are deeper in the flow.  If
> >> cancel is selected there, then just reset the flow and start login over.
> >>    Developers can decide to put in their own "back to application"
> >> buttons or menus by changing the template file.
> >>
> >>
> >> On 9/3/2015 3:04 AM, Stian Thorgersen wrote:
> >>> Currently the cancel button always redirects to the redirect_uri with
> >>> error=access_denied. This is fine if the application wants to handle the
> >>> rejected login. However, it does require the application to add
> >>> logic/error handling to display a suitable error message to the user
> >>> instead of just a generic 400 error page.
> >>>
> >>> I propose we add a configuration option to clients for how the cancel
> >>> button is handled. Options would be:
> >>>
> >>> * None - don't display cancel button, this is useful when login is
> >>> mandatory (for example our admin console)
> >>> * Error redirect - redirect to redirect_uri with error=access_denied
> >>> * Return to app - redirect to base_url of client (if this is set base_url
> >>> would be required)
> >>> _______________________________________________
> >>> 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
> 

From psilva at redhat.com  Thu Sep  3 12:11:12 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 3 Sep 2015 12:11:12 -0400 (EDT)
Subject: [keycloak-dev] Keycloak Realm Admin Services SPI
In-Reply-To: <340434249.23259830.1441292783506.JavaMail.zimbra@redhat.com>
Message-ID: <1463448694.23309752.1441296672350.JavaMail.zimbra@redhat.com>

Hi,

    Based on the discussion from our last meeting, we would need to provide SPIs for these two major areas:

        - Admin Services
        - Admin UI

    I would like to start discussing about the first area, in other words, how to provide custom services to Keycloak Admin RESTFul API.

    My initial requirements is all about providing a new API based on the following path:

        * /admin/realms/{realm}/authz

    I was thinking about using something like following method on RealmAdminResource:

     @Path("{custom_resource}")
     public Object getCustomResource(@PathParam("custom_resource") String customResource) {
        return // load resource from SPI
     }

    So here we could obtain some user-defined resource using a SPI based on a path param. That would allow us to support custom admin services for realms or even for a specific realm only.

    Any thoughts ?

Regards.
Pedro Igor


    

From ssilvert at redhat.com  Thu Sep  3 12:30:26 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 03 Sep 2015 12:30:26 -0400
Subject: [keycloak-dev] Loading message bundles from themes
In-Reply-To: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>
References: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>
Message-ID: <55E875A2.8000804@redhat.com>

I'm not sure exactly what you mean by "load message bundles from 
themes".  Show me where this lives and I'll take a look.

Just remember that we can't mix bundles intended for Java and bundles 
intended for Angular.  Not sure if that's what you are saying.

On 9/3/2015 9:57 AM, Stian Thorgersen wrote:
> You should load message bundles from themes not directly from the file system. That's how login pages and account management loads messages bundles so it should be consistent, but more importantly doing it through themes gives the following:
>
> * Support for loading from file or classpath - we also have an SPI for theme loaders so they can in the future load resources from other sources as well, for example the database
> * Supports overriding messages from themes - users can define custom themes that are used on a per-realm basis that can override messages. Themes even inherit messages from the theme it extends, so can choose to override only some messages
>
> Themes expects the message bundle to be named "messages_<locale>.properties". I'd prefer it to be consistent between the 3 different things we have internationalized and such admin messages should be loaded from themes and the message bundles should have the same names.
>
> We can then discuss with the translation team if they are happy with 3 separate message bundles or if they'd like a single message bundle for everything. We can also query about whether or not we can divide the message bundles up further. Dividing message bundles up would require adding support for that to themes as well. With classloaders and such it would be hard to implement a list available bundles so that's another reason for going with a single message bundle for now.


From stian at redhat.com  Thu Sep  3 13:08:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 13:08:33 -0400 (EDT)
Subject: [keycloak-dev] Loading message bundles from themes
In-Reply-To: <55E875A2.8000804@redhat.com>
References: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>
	<55E875A2.8000804@redhat.com>
Message-ID: <1955900838.26240597.1441300113176.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 3 September, 2015 6:30:26 PM
> Subject: Re: Loading message bundles from themes
> 
> I'm not sure exactly what you mean by "load message bundles from
> themes".  Show me where this lives and I'll take a look.

Theme.getMessages

> 
> Just remember that we can't mix bundles intended for Java and bundles
> intended for Angular.  Not sure if that's what you are saying.
> 
> On 9/3/2015 9:57 AM, Stian Thorgersen wrote:
> > You should load message bundles from themes not directly from the file
> > system. That's how login pages and account management loads messages
> > bundles so it should be consistent, but more importantly doing it through
> > themes gives the following:
> >
> > * Support for loading from file or classpath - we also have an SPI for
> > theme loaders so they can in the future load resources from other sources
> > as well, for example the database
> > * Supports overriding messages from themes - users can define custom themes
> > that are used on a per-realm basis that can override messages. Themes even
> > inherit messages from the theme it extends, so can choose to override only
> > some messages
> >
> > Themes expects the message bundle to be named
> > "messages_<locale>.properties". I'd prefer it to be consistent between the
> > 3 different things we have internationalized and such admin messages
> > should be loaded from themes and the message bundles should have the same
> > names.
> >
> > We can then discuss with the translation team if they are happy with 3
> > separate message bundles or if they'd like a single message bundle for
> > everything. We can also query about whether or not we can divide the
> > message bundles up further. Dividing message bundles up would require
> > adding support for that to themes as well. With classloaders and such it
> > would be hard to implement a list available bundles so that's another
> > reason for going with a single message bundle for now.
> 
> 

From bburke at redhat.com  Thu Sep  3 13:09:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Sep 2015 13:09:51 -0400
Subject: [keycloak-dev] Keycloak Realm Admin Services SPI
In-Reply-To: <1463448694.23309752.1441296672350.JavaMail.zimbra@redhat.com>
References: <1463448694.23309752.1441296672350.JavaMail.zimbra@redhat.com>
Message-ID: <55E87EDF.7030601@redhat.com>

That would be easy to do.  You just need to extend RealmAdminResource 
like you said and add something like:

@Path("spi/{spi})
public Object getSPI(@PathParam("spi") String spi) {
}

we could do the same for RealmsResource too for non-admin stuff.

AdminRestSPIProvider
AuthRestSPIProvider


On 9/3/2015 12:11 PM, Pedro Igor Silva wrote:
> Hi,
>
>      Based on the discussion from our last meeting, we would need to provide SPIs for these two major areas:
>
>          - Admin Services
>          - Admin UI
>
>      I would like to start discussing about the first area, in other words, how to provide custom services to Keycloak Admin RESTFul API.
>
>      My initial requirements is all about providing a new API based on the following path:
>
>          * /admin/realms/{realm}/authz
>
>      I was thinking about using something like following method on RealmAdminResource:
>
>       @Path("{custom_resource}")
>       public Object getCustomResource(@PathParam("custom_resource") String customResource) {
>          return // load resource from SPI
>       }
>
>      So here we could obtain some user-defined resource using a SPI based on a path param. That would allow us to support custom admin services for realms or even for a specific realm only.
>
>      Any thoughts ?
>
> Regards.
> Pedro Igor
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Sep  3 13:13:45 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Sep 2015 13:13:45 -0400
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <113463715.25957769.1441288800080.JavaMail.zimbra@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
	<1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
	<55E85154.70904@redhat.com>
	<113463715.25957769.1441288800080.JavaMail.zimbra@redhat.com>
Message-ID: <55E87FC9.40509@redhat.com>



On 9/3/2015 10:00 AM, Stian Thorgersen wrote:
>
> However, the admin initiated actions (admin sends email with reset password) should ideally have a "Back to login" or something like that
>
The only thing to "go back to" is the account service.   The account 
service might not even be enabled.  IMO, developers can add a link to 
the account service if they want to by editing the .ftl files.


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

From stian at redhat.com  Thu Sep  3 13:15:25 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 13:15:25 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <55E87FC9.40509@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
	<1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
	<55E85154.70904@redhat.com>
	<113463715.25957769.1441288800080.JavaMail.zimbra@redhat.com>
	<55E87FC9.40509@redhat.com>
Message-ID: <82977780.26272682.1441300525943.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 7:13:45 PM
> Subject: Re: [keycloak-dev] Cancel button options for clients
> 
> 
> 
> On 9/3/2015 10:00 AM, Stian Thorgersen wrote:
> >
> > However, the admin initiated actions (admin sends email with reset
> > password) should ideally have a "Back to login" or something like that
> >
> The only thing to "go back to" is the account service.   The account
> service might not even be enabled.  IMO, developers can add a link to
> the account service if they want to by editing the .ftl files.

No I was more thinking about if a user clicks the link to reset password, but then realize that they remember the password and wants to just login. But, that doesn't work in either case as there's no app to login to. So just forget about it.

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

From psilva at redhat.com  Thu Sep  3 13:32:13 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 3 Sep 2015 13:32:13 -0400 (EDT)
Subject: [keycloak-dev] Keycloak Realm Admin Services SPI
In-Reply-To: <55E87EDF.7030601@redhat.com>
References: <1463448694.23309752.1441296672350.JavaMail.zimbra@redhat.com>
	<55E87EDF.7030601@redhat.com>
Message-ID: <1135190337.23348334.1441301533288.JavaMail.zimbra@redhat.com>

Ok. Going to to follow this path. As soon as I have something integrated with KC, using this stuff, I'll send a PR.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, September 3, 2015 2:09:51 PM
Subject: Re: [keycloak-dev] Keycloak Realm Admin Services SPI

That would be easy to do.  You just need to extend RealmAdminResource 
like you said and add something like:

@Path("spi/{spi})
public Object getSPI(@PathParam("spi") String spi) {
}

we could do the same for RealmsResource too for non-admin stuff.

AdminRestSPIProvider
AuthRestSPIProvider


On 9/3/2015 12:11 PM, Pedro Igor Silva wrote:
> Hi,
>
>      Based on the discussion from our last meeting, we would need to provide SPIs for these two major areas:
>
>          - Admin Services
>          - Admin UI
>
>      I would like to start discussing about the first area, in other words, how to provide custom services to Keycloak Admin RESTFul API.
>
>      My initial requirements is all about providing a new API based on the following path:
>
>          * /admin/realms/{realm}/authz
>
>      I was thinking about using something like following method on RealmAdminResource:
>
>       @Path("{custom_resource}")
>       public Object getCustomResource(@PathParam("custom_resource") String customResource) {
>          return // load resource from SPI
>       }
>
>      So here we could obtain some user-defined resource using a SPI based on a path param. That would allow us to support custom admin services for realms or even for a specific realm only.
>
>      Any thoughts ?
>
> Regards.
> Pedro Igor
>
>
>
> _______________________________________________
> 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 stian at redhat.com  Thu Sep  3 13:48:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 3 Sep 2015 13:48:54 -0400 (EDT)
Subject: [keycloak-dev] Cancel button options for clients
In-Reply-To: <82977780.26272682.1441300525943.JavaMail.zimbra@redhat.com>
References: <1784221682.25116978.1441263865521.JavaMail.zimbra@redhat.com>
	<55E83EC2.3020909@redhat.com>
	<1819988159.25820811.1441284747201.JavaMail.zimbra@redhat.com>
	<55E85154.70904@redhat.com>
	<113463715.25957769.1441288800080.JavaMail.zimbra@redhat.com>
	<55E87FC9.40509@redhat.com>
	<82977780.26272682.1441300525943.JavaMail.zimbra@redhat.com>
Message-ID: <1345154173.26432140.1441302534827.JavaMail.zimbra@redhat.com>

I removed the cancel button from login and login-totp. It was actually not working on login-totp as it just behaved as the login button.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 7:15:25 PM
> Subject: Re: [keycloak-dev] Cancel button options for clients
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 3 September, 2015 7:13:45 PM
> > Subject: Re: [keycloak-dev] Cancel button options for clients
> > 
> > 
> > 
> > On 9/3/2015 10:00 AM, Stian Thorgersen wrote:
> > >
> > > However, the admin initiated actions (admin sends email with reset
> > > password) should ideally have a "Back to login" or something like that
> > >
> > The only thing to "go back to" is the account service.   The account
> > service might not even be enabled.  IMO, developers can add a link to
> > the account service if they want to by editing the .ftl files.
> 
> No I was more thinking about if a user clicks the link to reset password, but
> then realize that they remember the password and wants to just login. But,
> that doesn't work in either case as there's no app to login to. So just
> forget about it.
> 
> > 
> > 
> > --
> > 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 Sep  3 15:47:40 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 03 Sep 2015 15:47:40 -0400
Subject: [keycloak-dev] Loading message bundles from themes
In-Reply-To: <1955900838.26240597.1441300113176.JavaMail.zimbra@redhat.com>
References: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>
	<55E875A2.8000804@redhat.com>
	<1955900838.26240597.1441300113176.JavaMail.zimbra@redhat.com>
Message-ID: <55E8A3DC.1060802@redhat.com>

On 9/3/2015 1:08 PM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 3 September, 2015 6:30:26 PM
>> Subject: Re: Loading message bundles from themes
>>
>> I'm not sure exactly what you mean by "load message bundles from
>> themes".  Show me where this lives and I'll take a look.
> Theme.getMessages
I'll ping you in the morning about this.  It looks like the Theme API 
probably needs a separate method for Angular bundles. Otherwise, we'll 
have Java messages  mixed with Angular messages.

>
>> Just remember that we can't mix bundles intended for Java and bundles
>> intended for Angular.  Not sure if that's what you are saying.
>>
>> On 9/3/2015 9:57 AM, Stian Thorgersen wrote:
>>> You should load message bundles from themes not directly from the file
>>> system. That's how login pages and account management loads messages
>>> bundles so it should be consistent, but more importantly doing it through
>>> themes gives the following:
>>>
>>> * Support for loading from file or classpath - we also have an SPI for
>>> theme loaders so they can in the future load resources from other sources
>>> as well, for example the database
>>> * Supports overriding messages from themes - users can define custom themes
>>> that are used on a per-realm basis that can override messages. Themes even
>>> inherit messages from the theme it extends, so can choose to override only
>>> some messages
>>>
>>> Themes expects the message bundle to be named
>>> "messages_<locale>.properties". I'd prefer it to be consistent between the
>>> 3 different things we have internationalized and such admin messages
>>> should be loaded from themes and the message bundles should have the same
>>> names.
>>>
>>> We can then discuss with the translation team if they are happy with 3
>>> separate message bundles or if they'd like a single message bundle for
>>> everything. We can also query about whether or not we can divide the
>>> message bundles up further. Dividing message bundles up would require
>>> adding support for that to themes as well. With classloaders and such it
>>> would be hard to implement a list available bundles so that's another
>>> reason for going with a single message bundle for now.
>>


From bburke at redhat.com  Thu Sep  3 16:39:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 3 Sep 2015 16:39:26 -0400
Subject: [keycloak-dev] KEYCLOAK-1794
Message-ID: <55E8AFFE.4000509@redhat.com>

Angular people take a look at this:

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

I swear this used to work.  It looks like the scope within the ng-repeat 
inherits from the parent scope instead of the isolated scope of the 
directive.  I've tried a ton of stuff to no avail...Any ideas?

I'm thinking of pulling out the ng-repeat from the template and doing it 
within the actual page.  This is the only thing I can think to do at 
this time.  I'm nervous that the role dialog will now no longer work too.


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

From satyajit.das at spire2grow.com  Fri Sep  4 00:53:34 2015
From: satyajit.das at spire2grow.com (Satyajit Das)
Date: Fri, 4 Sep 2015 10:23:34 +0530
Subject: [keycloak-dev] Keycloak Authentication Switch off
Message-ID: <CA+oCsRp-EGagO_qoFgyWooNsYpbKE1GFaZC9hcQ4dPWCj5JTRQ@mail.gmail.com>

Hi Team,

I am using keycloak with tomcat integration along with multi tenancy. I use
Keycloak to secure rest services.

Is there any way to switch off the authentication when not required I dont
want to make any changes to web.xml or the context.xml, which contains the
adapter

<Context path="/talent-entity-layer">
 <Valve
className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>
</Context>

I also have pathresolver to resolve the multitenancy.

Is there anyway to switch off authentication.

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

From stian at redhat.com  Fri Sep  4 02:10:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Sep 2015 02:10:45 -0400 (EDT)
Subject: [keycloak-dev] Loading message bundles from themes
In-Reply-To: <55E8A3DC.1060802@redhat.com>
References: <634695317.25954071.1441288624163.JavaMail.zimbra@redhat.com>
	<55E875A2.8000804@redhat.com>
	<1955900838.26240597.1441300113176.JavaMail.zimbra@redhat.com>
	<55E8A3DC.1060802@redhat.com>
Message-ID: <233684574.26667959.1441347045141.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 3 September, 2015 9:47:40 PM
> Subject: Re: Loading message bundles from themes
> 
> On 9/3/2015 1:08 PM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, 3 September, 2015 6:30:26 PM
> >> Subject: Re: Loading message bundles from themes
> >>
> >> I'm not sure exactly what you mean by "load message bundles from
> >> themes".  Show me where this lives and I'll take a look.
> > Theme.getMessages
> I'll ping you in the morning about this.  It looks like the Theme API
> probably needs a separate method for Angular bundles. Otherwise, we'll
> have Java messages  mixed with Angular messages.

No it doesn't because there's separate themes for admin console.

> 
> >
> >> Just remember that we can't mix bundles intended for Java and bundles
> >> intended for Angular.  Not sure if that's what you are saying.
> >>
> >> On 9/3/2015 9:57 AM, Stian Thorgersen wrote:
> >>> You should load message bundles from themes not directly from the file
> >>> system. That's how login pages and account management loads messages
> >>> bundles so it should be consistent, but more importantly doing it through
> >>> themes gives the following:
> >>>
> >>> * Support for loading from file or classpath - we also have an SPI for
> >>> theme loaders so they can in the future load resources from other sources
> >>> as well, for example the database
> >>> * Supports overriding messages from themes - users can define custom
> >>> themes
> >>> that are used on a per-realm basis that can override messages. Themes
> >>> even
> >>> inherit messages from the theme it extends, so can choose to override
> >>> only
> >>> some messages
> >>>
> >>> Themes expects the message bundle to be named
> >>> "messages_<locale>.properties". I'd prefer it to be consistent between
> >>> the
> >>> 3 different things we have internationalized and such admin messages
> >>> should be loaded from themes and the message bundles should have the same
> >>> names.
> >>>
> >>> We can then discuss with the translation team if they are happy with 3
> >>> separate message bundles or if they'd like a single message bundle for
> >>> everything. We can also query about whether or not we can divide the
> >>> message bundles up further. Dividing message bundles up would require
> >>> adding support for that to themes as well. With classloaders and such it
> >>> would be hard to implement a list available bundles so that's another
> >>> reason for going with a single message bundle for now.
> >>
> 
> 

From stian at redhat.com  Fri Sep  4 04:20:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Sep 2015 04:20:19 -0400 (EDT)
Subject: [keycloak-dev] KEYCLOAK-1794
In-Reply-To: <55E8AFFE.4000509@redhat.com>
References: <55E8AFFE.4000509@redhat.com>
Message-ID: <1324826390.26715026.1441354819933.JavaMail.zimbra@redhat.com>

Sorted - not 100% sure how, but I fixed it ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 10:39:26 PM
> Subject: [keycloak-dev] KEYCLOAK-1794
> 
> Angular people take a look at this:
> 
> https://issues.jboss.org/browse/KEYCLOAK-1794
> 
> I swear this used to work.  It looks like the scope within the ng-repeat
> inherits from the parent scope instead of the isolated scope of the
> directive.  I've tried a ton of stuff to no avail...Any ideas?
> 
> I'm thinking of pulling out the ng-repeat from the template and doing it
> within the actual page.  This is the only thing I can think to do at
> this time.  I'm nervous that the role dialog will now no longer work too.
> 
> 
> --
> 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 stian at redhat.com  Fri Sep  4 04:20:41 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Sep 2015 04:20:41 -0400 (EDT)
Subject: [keycloak-dev] KEYCLOAK-1794
In-Reply-To: <55E8AFFE.4000509@redhat.com>
References: <55E8AFFE.4000509@redhat.com>
Message-ID: <2115563842.26715107.1441354841176.JavaMail.zimbra@redhat.com>

Also tested the role selector and that works as well

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 3 September, 2015 10:39:26 PM
> Subject: [keycloak-dev] KEYCLOAK-1794
> 
> Angular people take a look at this:
> 
> https://issues.jboss.org/browse/KEYCLOAK-1794
> 
> I swear this used to work.  It looks like the scope within the ng-repeat
> inherits from the parent scope instead of the isolated scope of the
> directive.  I've tried a ton of stuff to no avail...Any ideas?
> 
> I'm thinking of pulling out the ng-repeat from the template and doing it
> within the actual page.  This is the only thing I can think to do at
> this time.  I'm nervous that the role dialog will now no longer work too.
> 
> 
> --
> 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 mstrukel at redhat.com  Fri Sep  4 05:25:41 2015
From: mstrukel at redhat.com (Marko Strukelj)
Date: Fri, 4 Sep 2015 11:25:41 +0200
Subject: [keycloak-dev] ARQ testsuite error
Message-ID: <CA+1OW+iWSWK=mpq=dqH+fp22d=2-GkY4ueZ4R1zPXfE_Q+K6_g@mail.gmail.com>

Using latest master I'm getting a test failure in arquillian testsuite. Is
that expected?



Tests run: 5, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 56.349 sec
<<< FAILURE! - in org.keycloak.testsuite.admin.test.user.AddNewUserTest
addDuplicatedUser(org.keycloak.testsuite.admin.test.user.AddNewUserTest)
 Time elapsed: 15.204 sec  <<< FAILURE!
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertNotNull(Assert.java:712)
at org.junit.Assert.assertNotNull(Assert.java:722)
at
org.keycloak.testsuite.admin.test.user.AddNewUserTest.addDuplicatedUser(AddNewUserTest.java:88)

...

Results :

Failed tests:
  AddNewUserTest.addDuplicatedUser:88 null

Tests run: 26, Failures: 1, Errors: 0, Skipped: 4


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

From bburke at redhat.com  Fri Sep  4 09:22:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 4 Sep 2015 09:22:26 -0400
Subject: [keycloak-dev] [keycloak-user] Keycloak Authentication Switch
	off
In-Reply-To: <CA+oCsRp-EGagO_qoFgyWooNsYpbKE1GFaZC9hcQ4dPWCj5JTRQ@mail.gmail.com>
References: <CA+oCsRp-EGagO_qoFgyWooNsYpbKE1GFaZC9hcQ4dPWCj5JTRQ@mail.gmail.com>
Message-ID: <55E99B12.2000607@redhat.com>

Use web.xml security contraints.

On 9/4/2015 12:53 AM, Satyajit Das wrote:
> Hi Team,
>
> I am using keycloak with tomcat integration along with multi tenancy. I
> use Keycloak to secure rest services.
>
> Is there any way to switch off the authentication when not required I
> dont want to make any changes to web.xml or the context.xml, which
> contains the adapter
>
> <Context path="/talent-entity-layer">
>   <Valve
> className="org.keycloak.adapters.tomcat.KeycloakAuthenticatorValve"/>
> </Context>
>
> I also have pathresolver to resolve the multitenancy.
>
> Is there anyway to switch off authentication.
>
> Regards,
> Satya.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Sep  4 09:34:27 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 4 Sep 2015 09:34:27 -0400
Subject: [keycloak-dev] KEYCLOAK-1794
In-Reply-To: <1324826390.26715026.1441354819933.JavaMail.zimbra@redhat.com>
References: <55E8AFFE.4000509@redhat.com>
	<1324826390.26715026.1441354819933.JavaMail.zimbra@redhat.com>
Message-ID: <55E99DE3.1040402@redhat.com>

Bizarre!  Sometimes Angular is really weird...All you did was add a 
controller and the scopes magically behaved as you would expect...  I 
just don't get it...

On 9/4/2015 4:20 AM, Stian Thorgersen wrote:
> Sorted - not 100% sure how, but I fixed it ;)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 3 September, 2015 10:39:26 PM
>> Subject: [keycloak-dev] KEYCLOAK-1794
>>
>> Angular people take a look at this:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-1794
>>
>> I swear this used to work.  It looks like the scope within the ng-repeat
>> inherits from the parent scope instead of the isolated scope of the
>> directive.  I've tried a ton of stuff to no avail...Any ideas?
>>
>> I'm thinking of pulling out the ng-repeat from the template and doing it
>> within the actual page.  This is the only thing I can think to do at
>> this time.  I'm nervous that the role dialog will now no longer work too.
>>
>>
>> --
>> 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

From stian at redhat.com  Fri Sep  4 09:58:05 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Sep 2015 09:58:05 -0400 (EDT)
Subject: [keycloak-dev] KEYCLOAK-1794
In-Reply-To: <55E99DE3.1040402@redhat.com>
References: <55E8AFFE.4000509@redhat.com>
	<1324826390.26715026.1441354819933.JavaMail.zimbra@redhat.com>
	<55E99DE3.1040402@redhat.com>
Message-ID: <871259889.26877533.1441375085223.JavaMail.zimbra@redhat.com>

Me neither, I found some post saying that it wasn't a good idea to define functions within a directive, which is why I tried to pull it out into a controller.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 4 September, 2015 3:34:27 PM
> Subject: Re: [keycloak-dev] KEYCLOAK-1794
> 
> Bizarre!  Sometimes Angular is really weird...All you did was add a
> controller and the scopes magically behaved as you would expect...  I
> just don't get it...
> 
> On 9/4/2015 4:20 AM, Stian Thorgersen wrote:
> > Sorted - not 100% sure how, but I fixed it ;)
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 3 September, 2015 10:39:26 PM
> >> Subject: [keycloak-dev] KEYCLOAK-1794
> >>
> >> Angular people take a look at this:
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-1794
> >>
> >> I swear this used to work.  It looks like the scope within the ng-repeat
> >> inherits from the parent scope instead of the isolated scope of the
> >> directive.  I've tried a ton of stuff to no avail...Any ideas?
> >>
> >> I'm thinking of pulling out the ng-repeat from the template and doing it
> >> within the actual page.  This is the only thing I can think to do at
> >> this time.  I'm nervous that the role dialog will now no longer work too.
> >>
> >>
> >> --
> >> 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
> 

From alex_orl1079 at yahoo.it  Mon Sep  7 12:14:38 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 7 Sep 2015 16:14:38 +0000 (UTC)
Subject: [keycloak-dev] User Federation Provider with JPA
Message-ID: <1272769913.3908112.1441642478767.JavaMail.yahoo@mail.yahoo.com>

I'm developing a keycloak user-federation-provider and i need to integrate it with the JPA persistence system in order to write on my legacy db and on the keycloak db.I read that Jboss WildFly already uses Hiberante 4.3 JPA, so i choose to follow this line for my project.Another requirement is to decouple the provider and the JPA model-mapping-project, so ?my JPA model-mapping-project has to be deployed a separated jar file.Following the keycloak userguide i deploy the provider simply coping ?the built jar project into the .../standalone/configuration/providers directory.The JPA model-mapping-project jar file is deployed into the Wildfly using the management console deployment section.Now i'm facing up to 2 problems:1) the user-federation-provider doesn't see the model-mapping-project ?classes (throwing the ClassNotFoundException)2) if i simply copy the model-mapping-project.jar into the /standalone/configuration/providers directory, the fereration provider sees the classes but the EntityManager dependency injection does not work (NullPointerException)
What the way i can solve this problem?Is there another way to deploy providers? and what about the jar and the depecency injection?ThanksRegards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150907/5bafca2b/attachment-0001.html 

From srossillo at smartling.com  Mon Sep  7 13:29:02 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 07 Sep 2015 17:29:02 +0000
Subject: [keycloak-dev] User Federation Provider with JPA
In-Reply-To: <1272769913.3908112.1441642478767.JavaMail.yahoo@mail.yahoo.com>
References: <1272769913.3908112.1441642478767.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CALAqdu8artXfcsLRi6HE3j1+LvC_gfR31P==wUzo1mK561E2XA@mail.gmail.com>

We'll publish an example of how to do this soon, but I'd recommend writing
an API based provider on your legacy system instead of using a direct
database connection from Keycloak. Sorry, doesn't exactly answer your
question but it's a more elegant solution.
On Mon, Sep 7, 2015 at 12:18 PM alex orl <alex_orl1079 at yahoo.it> wrote:

> I'm developing a keycloak user-federation-provider and i need to integrate
> it with the JPA persistence system in order to write on my legacy db and on
> the keycloak db.
> I read that Jboss WildFly already uses Hiberante 4.3 JPA, so i choose to
> follow this line for my project.
> Another requirement is to decouple the provider and the JPA
> model-mapping-project, so  my JPA model-mapping-project has to be deployed
> a separated jar file.
> Following the keycloak userguide i deploy the provider simply coping  the
> built jar project into the .../standalone/configuration/providers directory.
> The JPA model-mapping-project jar file is deployed into the Wildfly using
> the management console deployment section.
> Now i'm facing up to 2 problems:
> 1) the user-federation-provider doesn't see the model-mapping-project
>  classes (throwing the ClassNotFoundException)
> 2) if i simply copy the model-mapping-project.jar into the
> /standalone/configuration/providers directory, the fereration provider sees
> the classes but the EntityManager dependency injection does not work
> (NullPointerException)
>
> What the way i can solve this problem?
> Is there another way to deploy providers? and what about the jar and the
> depecency injection?
> Thanks
> Regards.
> _______________________________________________
> 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/20150907/56e41a4d/attachment.html 

From alex_orl1079 at yahoo.it  Mon Sep  7 13:39:12 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 7 Sep 2015 17:39:12 +0000 (UTC)
Subject: [keycloak-dev] User Federation Provider with JPA
In-Reply-To: <CALAqdu8artXfcsLRi6HE3j1+LvC_gfR31P==wUzo1mK561E2XA@mail.gmail.com>
References: <CALAqdu8artXfcsLRi6HE3j1+LvC_gfR31P==wUzo1mK561E2XA@mail.gmail.com>
Message-ID: <303605925.3952781.1441647552356.JavaMail.yahoo@mail.yahoo.com>

shouldn't be the same having a separated JPA project in charge of talking with our legacy database? Eventually what about ?entitymanager null pointer exception? do you have an idea? should the jpa project be part of an ejb project?thanks 


     Il Luned? 7 Settembre 2015 19:29, Scott Rossillo <srossillo at smartling.com> ha scritto:
   

 We'll publish an example of how to do this soon, but I'd recommend writing an API based provider on your legacy system instead of using a direct database connection from Keycloak. Sorry, doesn't exactly answer your question but it's a more elegant solution.
On Mon, Sep 7, 2015 at 12:18 PM alex orl <alex_orl1079 at yahoo.it> wrote:

I'm developing a keycloak user-federation-provider and i need to integrate it with the JPA persistence system in order to write on my legacy db and on the keycloak db.I read that Jboss WildFly already uses Hiberante 4.3 JPA, so i choose to follow this line for my project.Another requirement is to decouple the provider and the JPA model-mapping-project, so ?my JPA model-mapping-project has to be deployed a separated jar file.Following the keycloak userguide i deploy the provider simply coping ?the built jar project into the .../standalone/configuration/providers directory.The JPA model-mapping-project jar file is deployed into the Wildfly using the management console deployment section.Now i'm facing up to 2 problems:1) the user-federation-provider doesn't see the model-mapping-project ?classes (throwing the ClassNotFoundException)2) if i simply copy the model-mapping-project.jar into the /standalone/configuration/providers directory, the fereration provider sees the classes but the EntityManager dependency injection does not work (NullPointerException)
What the way i can solve this problem?Is there another way to deploy providers? and what about the jar and the depecency injection?ThanksRegards._______________________________________________
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/20150907/01b3762f/attachment.html 

From stian at redhat.com  Tue Sep  8 02:50:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Sep 2015 02:50:43 -0400 (EDT)
Subject: [keycloak-dev] User Federation Provider with JPA
In-Reply-To: <1272769913.3908112.1441642478767.JavaMail.yahoo@mail.yahoo.com>
References: <1272769913.3908112.1441642478767.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <545850904.27863604.1441695043233.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "alex orl" <alex_orl1079 at yahoo.it>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 7 September, 2015 6:14:38 PM
> Subject: [keycloak-dev] User Federation Provider with JPA
> 
> I'm developing a keycloak user-federation-provider and i need to integrate it
> with the JPA persistence system in order to write on my legacy db and on the
> keycloak db.
> I read that Jboss WildFly already uses Hiberante 4.3 JPA, so i choose to
> follow this line for my project.
> Another requirement is to decouple the provider and the JPA
> model-mapping-project, so my JPA model-mapping-project has to be deployed a
> separated jar file.

You can use JBoss Modules and deploy your mapping as one model and the Keycloak provider as another.

> Following the keycloak userguide i deploy the provider simply coping the
> built jar project into the .../standalone/configuration/providers directory.
> The JPA model-mapping-project jar file is deployed into the Wildfly using the
> management console deployment section.
> Now i'm facing up to 2 problems:
> 1) the user-federation-provider doesn't see the model-mapping-project classes
> (throwing the ClassNotFoundException)
> 2) if i simply copy the model-mapping-project.jar into the
> /standalone/configuration/providers directory, the fereration provider sees
> the classes but the EntityManager dependency injection does not work
> (NullPointerException)
> 
> What the way i can solve this problem?
> Is there another way to deploy providers? and what about the jar and the
> depecency injection?
> Thanks
> Regards.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Tue Sep  8 02:55:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Sep 2015 02:55:59 -0400 (EDT)
Subject: [keycloak-dev] Remove cache on/off options in admin console
Message-ID: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>

I propose we remove the cache on/off options in the admin console for realm and users.

From stian at redhat.com  Tue Sep  8 03:17:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Sep 2015 03:17:16 -0400 (EDT)
Subject: [keycloak-dev] Remove cache on/off options in admin console
In-Reply-To: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
References: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
Message-ID: <2074998312.27876670.1441696636438.JavaMail.zimbra@redhat.com>

Enable/disable cache doesn't work with Infinispan provider, not sure if it worked with the old mem provider. It's not a realm specific setting either as it sets enable/disable directly on the provider itself. Nor is it persisted to the database.

My vote goes to remove the option, but if we still want it we'd need to persist it as a realm setting. 

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 8 September, 2015 8:55:59 AM
> Subject: [keycloak-dev] Remove cache on/off options in admin console
> 
> I propose we remove the cache on/off options in the admin console for realm
> and users.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mr.graf at gmx.net  Tue Sep  8 03:18:09 2015
From: mr.graf at gmx.net (Mr. Graf)
Date: Tue, 8 Sep 2015 09:18:09 +0200
Subject: [keycloak-dev] refresh_token request should trigger update of
	access token payload
Message-ID: <EA3AEF3F-20E2-40C4-9079-469466D8E830@gmx.net>

Hey all,
we are evaluating keycloak and run into an issue.
We implemented a UserFederationProvider. This Provider authenticates let?s say old users and new users.
?old? users should receive an LTPA token within the payload of the access token. We used user attributes to achieve it. Fine so far.
Our current issue is, that this LTPA token needs to be updated when a refresh_token request comes in and should be put into the ?new? access token too.
Initially we tried to achieve it using the refresh_token event until we noticed that this is fired after the ?new? access token has been created, so too late.

Does someone has a smart approach or an example how to add custom payload, to be retrieved from a legacy system, to the access token when refreshing it?

Thanks in advance
Thomas

From bburke at redhat.com  Tue Sep  8 08:15:20 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 8 Sep 2015 08:15:20 -0400
Subject: [keycloak-dev] Remove cache on/off options in admin console
In-Reply-To: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
References: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
Message-ID: <55EED158.3080509@redhat.com>

Only if you have an option to clear the cache.  It is really important 
to be able to clear the cache.  Right now the cache is cleared by 
turning the cache off, then on.  IMO, its a great option to have just in 
case we've made a mistake in the caching layer.  In that case, the user 
can just turn off the cache until we patch the bug.

On 9/8/2015 2:55 AM, Stian Thorgersen wrote:
> I propose we remove the cache on/off options in the admin console for realm and users.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Sep  8 08:18:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 8 Sep 2015 08:18:41 -0400
Subject: [keycloak-dev] refresh_token request should trigger update of
 access token payload
In-Reply-To: <EA3AEF3F-20E2-40C4-9079-469466D8E830@gmx.net>
References: <EA3AEF3F-20E2-40C4-9079-469466D8E830@gmx.net>
Message-ID: <55EED221.8070406@redhat.com>

You can write a ProtocolMapper.  We haven't made the SPI public yet and 
weren't sure if we should.

On 9/8/2015 3:18 AM, Mr. Graf wrote:
> Hey all,
> we are evaluating keycloak and run into an issue.
> We implemented a UserFederationProvider. This Provider authenticates let?s say old users and new users.
> ?old? users should receive an LTPA token within the payload of the access token. We used user attributes to achieve it. Fine so far.
> Our current issue is, that this LTPA token needs to be updated when a refresh_token request comes in and should be put into the ?new? access token too.
> Initially we tried to achieve it using the refresh_token event until we noticed that this is fired after the ?new? access token has been created, so too late.
>
> Does someone has a smart approach or an example how to add custom payload, to be retrieved from a legacy system, to the access token when refreshing it?
>
> Thanks in advance
> 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

From stian at redhat.com  Tue Sep  8 09:04:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Sep 2015 09:04:31 -0400 (EDT)
Subject: [keycloak-dev] Remove cache on/off options in admin console
In-Reply-To: <55EED158.3080509@redhat.com>
References: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
	<55EED158.3080509@redhat.com>
Message-ID: <774615634.28092887.1441717471963.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 September, 2015 2:15:20 PM
> Subject: Re: [keycloak-dev] Remove cache on/off options in admin console
> 
> Only if you have an option to clear the cache.  It is really important
> to be able to clear the cache.  Right now the cache is cleared by

Why is it important to be able to clear the cache?

> turning the cache off, then on.  IMO, its a great option to have just in
> case we've made a mistake in the caching layer.  In that case, the user
> can just turn off the cache until we patch the bug.

A better solution is just make sure it works ;)

> 
> On 9/8/2015 2:55 AM, Stian Thorgersen wrote:
> > I propose we remove the cache on/off options in the admin console for realm
> > and users.
> > _______________________________________________
> > 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  Tue Sep  8 09:25:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 8 Sep 2015 09:25:50 -0400
Subject: [keycloak-dev] Remove cache on/off options in admin console
In-Reply-To: <774615634.28092887.1441717471963.JavaMail.zimbra@redhat.com>
References: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
	<55EED158.3080509@redhat.com>
	<774615634.28092887.1441717471963.JavaMail.zimbra@redhat.com>
Message-ID: <55EEE1DE.2090009@redhat.com>



On 9/8/2015 9:04 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 September, 2015 2:15:20 PM
>> Subject: Re: [keycloak-dev] Remove cache on/off options in admin console
>>
>> Only if you have an option to clear the cache.  It is really important
>> to be able to clear the cache.  Right now the cache is cleared by
>
> Why is it important to be able to clear the cache?
>

Somebody does offline DB maintenance.  Nodes get separated and rejoin 
the group, etc.

>> turning the cache off, then on.  IMO, its a great option to have just in
>> case we've made a mistake in the caching layer.  In that case, the user
>> can just turn off the cache until we patch the bug.
>
> A better solution is just make sure it works ;)
>

Its good to have a fallback option.


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

From mposolda at redhat.com  Tue Sep  8 10:53:59 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 8 Sep 2015 16:53:59 +0200
Subject: [keycloak-dev] Remove cache on/off options in admin console
In-Reply-To: <55EEE1DE.2090009@redhat.com>
References: <911676203.27865761.1441695359342.JavaMail.zimbra@redhat.com>
	<55EED158.3080509@redhat.com>
	<774615634.28092887.1441717471963.JavaMail.zimbra@redhat.com>
	<55EEE1DE.2090009@redhat.com>
Message-ID: <55EEF687.1030106@redhat.com>

On 08/09/15 15:25, Bill Burke wrote:
>
> On 9/8/2015 9:04 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 8 September, 2015 2:15:20 PM
>>> Subject: Re: [keycloak-dev] Remove cache on/off options in admin console
>>>
>>> Only if you have an option to clear the cache.  It is really important
>>> to be able to clear the cache.  Right now the cache is cleared by
>> Why is it important to be able to clear the cache?
>>
> Somebody does offline DB maintenance.  Nodes get separated and rejoin
> the group, etc.
>
>>> turning the cache off, then on.  IMO, its a great option to have just in
>>> case we've made a mistake in the caching layer.  In that case, the user
>>> can just turn off the cache until we patch the bug.
>> A better solution is just make sure it works ;)
>>
> Its good to have a fallback option.
>
>
+1 to have fallback option and possibility to clear the cache. Some 
caching related bugs could be hidden for the longer time and found by 
someone later at production (for example something not properly 
invalidated during realm update etc). If we have the option, we can ask 
people to try clear the cache to verify if there is really caching 
related issue or not.

Marek


From mr.graf at gmx.net  Tue Sep  8 11:34:10 2015
From: mr.graf at gmx.net (Mr. Graf)
Date: Tue, 8 Sep 2015 17:34:10 +0200
Subject: [keycloak-dev] refresh_token request should trigger update of
	access token payload
In-Reply-To: <55EED221.8070406@redhat.com>
References: <EA3AEF3F-20E2-40C4-9079-469466D8E830@gmx.net>
	<55EED221.8070406@redhat.com>
Message-ID: <41A4F06C-EC0D-456D-8B86-FC1FD044C8D3@gmx.net>

Thank you.
What does it mean for the moment? It?s not possible now?
If so, are you sure now and is it already in the backlog? ;) No, seriously, will it get public and when?



> Am 08.09.2015 um 14:18 schrieb Bill Burke <bburke at redhat.com>:
> 
> You can write a ProtocolMapper.  We haven't made the SPI public yet and 
> weren't sure if we should.
> 
> On 9/8/2015 3:18 AM, Mr. Graf wrote:
>> Hey all,
>> we are evaluating keycloak and run into an issue.
>> We implemented a UserFederationProvider. This Provider authenticates let?s say old users and new users.
>> ?old? users should receive an LTPA token within the payload of the access token. We used user attributes to achieve it. Fine so far.
>> Our current issue is, that this LTPA token needs to be updated when a refresh_token request comes in and should be put into the ?new? access token too.
>> Initially we tried to achieve it using the refresh_token event until we noticed that this is fired after the ?new? access token has been created, so too late.
>> 
>> Does someone has a smart approach or an example how to add custom payload, to be retrieved from a legacy system, to the access token when refreshing it?
>> 
>> Thanks in advance
>> 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



From bburke at redhat.com  Tue Sep  8 13:37:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 8 Sep 2015 13:37:32 -0400
Subject: [keycloak-dev] refresh_token request should trigger update of
 access token payload
In-Reply-To: <41A4F06C-EC0D-456D-8B86-FC1FD044C8D3@gmx.net>
References: <EA3AEF3F-20E2-40C4-9079-469466D8E830@gmx.net>
	<55EED221.8070406@redhat.com>
	<41A4F06C-EC0D-456D-8B86-FC1FD044C8D3@gmx.net>
Message-ID: <55EF1CDC.50203@redhat.com>

You can do it now, its just that we don't have any documentation for it. 
  Here's a bunch of examples:

https://github.com/keycloak/keycloak/tree/master/services/src/main/java/org/keycloak/protocol/oidc/mappers

I'm not sure how you obtain or refresh an LTPA  token.  But these 
mappers are executed whenever a token is created.  You would define the 
mapper then configure it within the admin console.  In talking to you 
and others, we may need some callback on the UserFederationProvider too.





On 9/8/2015 11:34 AM, Mr. Graf wrote:
> Thank you.
> What does it mean for the moment? It?s not possible now?
> If so, are you sure now and is it already in the backlog? ;) No, seriously, will it get public and when?
>
>
>
>> Am 08.09.2015 um 14:18 schrieb Bill Burke <bburke at redhat.com>:
>>
>> You can write a ProtocolMapper.  We haven't made the SPI public yet and
>> weren't sure if we should.
>>
>> On 9/8/2015 3:18 AM, Mr. Graf wrote:
>>> Hey all,
>>> we are evaluating keycloak and run into an issue.
>>> We implemented a UserFederationProvider. This Provider authenticates let?s say old users and new users.
>>> ?old? users should receive an LTPA token within the payload of the access token. We used user attributes to achieve it. Fine so far.
>>> Our current issue is, that this LTPA token needs to be updated when a refresh_token request comes in and should be put into the ?new? access token too.
>>> Initially we tried to achieve it using the refresh_token event until we noticed that this is fired after the ?new? access token has been created, so too late.
>>>
>>> Does someone has a smart approach or an example how to add custom payload, to be retrieved from a legacy system, to the access token when refreshing it?
>>>
>>> Thanks in advance
>>> 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
>
>
> _______________________________________________
> 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 thomas.raehalme at aitiofinland.com  Thu Sep 10 03:15:24 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Thu, 10 Sep 2015 10:15:24 +0300
Subject: [keycloak-dev] Email verification and redirect_uri
Message-ID: <CAPyAMoa3mMy2b0qnBg7P0w-b61VtSrrQgMb0Cw88BygKdxr1ow@mail.gmail.com>

Hi,

We are doing some testing regarding email verifications.

Everything seems to work great as long as the user keeps using the same
browser for every request (try to access a protected resource, register a
new account and click the email verification link).

If the user, however, registers with Firefox and the verification link in
email is opened to a different browser, say, Chrome, the user is shown a
message regarding successful verification and a link "Back to application".
The user is not redirected to the original protected resource.

If you read your email with a browser this is probably not going to happen.
But if your email client opens a different browser for any reason, then it
will break the process.

What do you think would it make sense to include the original redirect_uri
in the verification link to ensure that the user is redirected back to the
original protected resource? Or maybe you could store the redirect_uri on
the server next to the verification token?

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

From bburke at redhat.com  Thu Sep 10 09:02:23 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 10 Sep 2015 09:02:23 -0400
Subject: [keycloak-dev] Email verification and redirect_uri
In-Reply-To: <CAPyAMoa3mMy2b0qnBg7P0w-b61VtSrrQgMb0Cw88BygKdxr1ow@mail.gmail.com>
References: <CAPyAMoa3mMy2b0qnBg7P0w-b61VtSrrQgMb0Cw88BygKdxr1ow@mail.gmail.com>
Message-ID: <55F17F5F.1010206@redhat.com>

The quandry I have with verify email (and forgot password) is that if 
the email click happens in the same browser it is in another tab.  This 
leaves the previous tab in an inconsistent state.

In master, I've just refactored Forgot Password to reset the main 
browser to the login page, and clicking the email link allows you to 
proceed with login.  I'm wondering if we should do the same with Verify 
Email?  The main browser is reset to the login page (you have to enter 
in your credentials again) and clicking on the email link allows you to 
proceed with login irregardless of browser.


On 9/10/2015 3:15 AM, Thomas Raehalme wrote:
> Hi,
>
> We are doing some testing regarding email verifications.
>
> Everything seems to work great as long as the user keeps using the same
> browser for every request (try to access a protected resource, register
> a new account and click the email verification link).
>
> If the user, however, registers with Firefox and the verification link
> in email is opened to a different browser, say, Chrome, the user is
> shown a message regarding successful verification and a link "Back to
> application". The user is not redirected to the original protected resource.
>
> If you read your email with a browser this is probably not going to
> happen. But if your email client opens a different browser for any
> reason, then it will break the process.
>
> What do you think would it make sense to include the original
> redirect_uri in the verification link to ensure that the user is
> redirected back to the original protected resource? Or maybe you could
> store the redirect_uri on the server next to the verification token?
>
> Best regards,
> 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

From bburke at redhat.com  Thu Sep 10 09:21:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 10 Sep 2015 09:21:54 -0400
Subject: [keycloak-dev] Need your help! Need Keycloak references!
Message-ID: <55F183F2.7090704@redhat.com>

Hey all,

If you are using or are planning to use Keycloak in product, please 
email me offline.  I want to know if I can include you in a "customer 
testimonial" page.


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

From ssilvert at redhat.com  Fri Sep 11 10:48:20 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 11 Sep 2015 10:48:20 -0400
Subject: [keycloak-dev] Getting UserModel from inside
	AdminConsole.getMainPage() ?
Message-ID: <55F2E9B4.3090304@redhat.com>

I need to get the current logged-in UserModel from inside this method:
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266

I tried the same approach as the whoAmI() method, but 
authManager.authenticateBearerToken() returns null.   I guess the token 
is not set up yet?

Any ideas on an alternate way to get UserModel?

Stan

From stian at redhat.com  Fri Sep 11 10:51:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Sep 2015 10:51:56 -0400 (EDT)
Subject: [keycloak-dev] Getting UserModel from
	inside	AdminConsole.getMainPage() ?
In-Reply-To: <55F2E9B4.3090304@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
Message-ID: <985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>

There's no user when getting the index.html page - it's a html5 app so the token is retrieved by the js adapter, which is after index.html is loaded.

Why do you need a user there? Seems like you're doing something not right.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 11 September, 2015 4:48:20 PM
> Subject: [keycloak-dev] Getting UserModel from inside	AdminConsole.getMainPage() ?
> 
> I need to get the current logged-in UserModel from inside this method:
> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
> 
> I tried the same approach as the whoAmI() method, but
> authManager.authenticateBearerToken() returns null.   I guess the token
> is not set up yet?
> 
> Any ideas on an alternate way to get UserModel?
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Fri Sep 11 11:12:11 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 11 Sep 2015 11:12:11 -0400
Subject: [keycloak-dev] Getting UserModel from inside
 AdminConsole.getMainPage() ?
In-Reply-To: <985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
	<985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
Message-ID: <55F2EF4B.4070100@redhat.com>

On 9/11/2015 10:51 AM, Stian Thorgersen wrote:
> There's no user when getting the index.html page - it's a html5 app so the token is retrieved by the js adapter, which is after index.html is loaded.
>
> Why do you need a user there? Seems like you're doing something not right.
I'm trying to add the locale swticher to the main page.  The locale 
switcher is generated via Freemarker and it needs a LocaleBean.  For 
that, I need to call LocaleHelper.getLocale(), which requires UserInfo.

>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, 11 September, 2015 4:48:20 PM
>> Subject: [keycloak-dev] Getting UserModel from inside	AdminConsole.getMainPage() ?
>>
>> I need to get the current logged-in UserModel from inside this method:
>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
>>
>> I tried the same approach as the whoAmI() method, but
>> authManager.authenticateBearerToken() returns null.   I guess the token
>> is not set up yet?
>>
>> Any ideas on an alternate way to get UserModel?
>>
>> Stan
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Fri Sep 11 11:12:12 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Sep 2015 11:12:12 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.5.0.Final released
In-Reply-To: <1860800646.30766081.1441984253168.JavaMail.zimbra@redhat.com>
Message-ID: <1897857333.30767241.1441984332815.JavaMail.zimbra@redhat.com>

For details check http://blog.keycloak.org/2015/09/keycloak-150final-released.html

It's in JBoss Nexus and downloads from keycloak.org right now, but it may take a few hours until it's synced to Maven Central.

From stian at redhat.com  Fri Sep 11 11:13:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Sep 2015 11:13:59 -0400 (EDT)
Subject: [keycloak-dev] Getting UserModel from inside
 AdminConsole.getMainPage() ?
In-Reply-To: <55F2EF4B.4070100@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
	<985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
	<55F2EF4B.4070100@redhat.com>
Message-ID: <1911941457.30768545.1441984439002.JavaMail.zimbra@redhat.com>

Maybe you could add a get/set locale endpoint alongside the whoAmI endpoint? Then invoke it using Angular, which would include the access token.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 11 September, 2015 5:12:11 PM
> Subject: Re: [keycloak-dev] Getting UserModel from inside AdminConsole.getMainPage() ?
> 
> On 9/11/2015 10:51 AM, Stian Thorgersen wrote:
> > There's no user when getting the index.html page - it's a html5 app so the
> > token is retrieved by the js adapter, which is after index.html is loaded.
> >
> > Why do you need a user there? Seems like you're doing something not right.
> I'm trying to add the locale swticher to the main page.  The locale
> switcher is generated via Freemarker and it needs a LocaleBean.  For
> that, I need to call LocaleHelper.getLocale(), which requires UserInfo.
> 
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Friday, 11 September, 2015 4:48:20 PM
> >> Subject: [keycloak-dev] Getting UserModel from inside
> >> 	AdminConsole.getMainPage() ?
> >>
> >> I need to get the current logged-in UserModel from inside this method:
> >> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
> >>
> >> I tried the same approach as the whoAmI() method, but
> >> authManager.authenticateBearerToken() returns null.   I guess the token
> >> is not set up yet?
> >>
> >> Any ideas on an alternate way to get UserModel?
> >>
> >> Stan
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From ssilvert at redhat.com  Fri Sep 11 11:14:22 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 11 Sep 2015 11:14:22 -0400
Subject: [keycloak-dev] Getting UserModel from inside
 AdminConsole.getMainPage() ?
In-Reply-To: <55F2EF4B.4070100@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
	<985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
	<55F2EF4B.4070100@redhat.com>
Message-ID: <55F2EFCE.2070300@redhat.com>

On 9/11/2015 11:12 AM, Stan Silvert wrote:
> On 9/11/2015 10:51 AM, Stian Thorgersen wrote:
>> There's no user when getting the index.html page - it's a html5 app so the token is retrieved by the js adapter, which is after index.html is loaded.
>>
>> Why do you need a user there? Seems like you're doing something not right.
> I'm trying to add the locale swticher to the main page.  The locale
> switcher is generated via Freemarker and it needs a LocaleBean.  For
> that, I need to call LocaleHelper.getLocale(), which requires UserInfo.
I mean UserModel, not UserInfo.
>
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 11 September, 2015 4:48:20 PM
>>> Subject: [keycloak-dev] Getting UserModel from inside	AdminConsole.getMainPage() ?
>>>
>>> I need to get the current logged-in UserModel from inside this method:
>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
>>>
>>> I tried the same approach as the whoAmI() method, but
>>> authManager.authenticateBearerToken() returns null.   I guess the token
>>> is not set up yet?
>>>
>>> Any ideas on an alternate way to get UserModel?
>>>
>>> Stan
>>> _______________________________________________
>>> 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 ssilvert at redhat.com  Fri Sep 11 11:22:09 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 11 Sep 2015 11:22:09 -0400
Subject: [keycloak-dev] Getting UserModel from inside
 AdminConsole.getMainPage() ?
In-Reply-To: <1911941457.30768545.1441984439002.JavaMail.zimbra@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
	<985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
	<55F2EF4B.4070100@redhat.com>
	<1911941457.30768545.1441984439002.JavaMail.zimbra@redhat.com>
Message-ID: <55F2F1A1.9070904@redhat.com>

On 9/11/2015 11:13 AM, Stian Thorgersen wrote:
> Maybe you could add a get/set locale endpoint alongside the whoAmI endpoint? Then invoke it using Angular, which would include the access token.
Wouldn't that require changing the way the locale switcher works? You 
are talking about invoking the new endpoint after index.html is already 
rendered by Freemarker?  If so, it's too late for the locale switcher to 
be set up.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, 11 September, 2015 5:12:11 PM
>> Subject: Re: [keycloak-dev] Getting UserModel from inside AdminConsole.getMainPage() ?
>>
>> On 9/11/2015 10:51 AM, Stian Thorgersen wrote:
>>> There's no user when getting the index.html page - it's a html5 app so the
>>> token is retrieved by the js adapter, which is after index.html is loaded.
>>>
>>> Why do you need a user there? Seems like you're doing something not right.
>> I'm trying to add the locale swticher to the main page.  The locale
>> switcher is generated via Freemarker and it needs a LocaleBean.  For
>> that, I need to call LocaleHelper.getLocale(), which requires UserInfo.
>>
>>> ----- Original Message -----
>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Friday, 11 September, 2015 4:48:20 PM
>>>> Subject: [keycloak-dev] Getting UserModel from inside
>>>> 	AdminConsole.getMainPage() ?
>>>>
>>>> I need to get the current logged-in UserModel from inside this method:
>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
>>>>
>>>> I tried the same approach as the whoAmI() method, but
>>>> authManager.authenticateBearerToken() returns null.   I guess the token
>>>> is not set up yet?
>>>>
>>>> Any ideas on an alternate way to get UserModel?
>>>>
>>>> Stan
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From ssilvert at redhat.com  Fri Sep 11 11:30:26 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 11 Sep 2015 11:30:26 -0400
Subject: [keycloak-dev] Getting UserModel from inside
 AdminConsole.getMainPage() ?
In-Reply-To: <55F2F1A1.9070904@redhat.com>
References: <55F2E9B4.3090304@redhat.com>
	<985792375.30752929.1441983116300.JavaMail.zimbra@redhat.com>
	<55F2EF4B.4070100@redhat.com>
	<1911941457.30768545.1441984439002.JavaMail.zimbra@redhat.com>
	<55F2F1A1.9070904@redhat.com>
Message-ID: <55F2F392.3040408@redhat.com>

BTW, if adding the locale switcher to the main page is too disruptive, 
I'm OK with putting it off until later.


On 9/11/2015 11:22 AM, Stan Silvert wrote:
> On 9/11/2015 11:13 AM, Stian Thorgersen wrote:
>> Maybe you could add a get/set locale endpoint alongside the whoAmI endpoint? Then invoke it using Angular, which would include the access token.
> Wouldn't that require changing the way the locale switcher works? You
> are talking about invoking the new endpoint after index.html is already
> rendered by Freemarker?  If so, it's too late for the locale switcher to
> be set up.
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 11 September, 2015 5:12:11 PM
>>> Subject: Re: [keycloak-dev] Getting UserModel from inside AdminConsole.getMainPage() ?
>>>
>>> On 9/11/2015 10:51 AM, Stian Thorgersen wrote:
>>>> There's no user when getting the index.html page - it's a html5 app so the
>>>> token is retrieved by the js adapter, which is after index.html is loaded.
>>>>
>>>> Why do you need a user there? Seems like you're doing something not right.
>>> I'm trying to add the locale swticher to the main page.  The locale
>>> switcher is generated via Freemarker and it needs a LocaleBean.  For
>>> that, I need to call LocaleHelper.getLocale(), which requires UserInfo.
>>>
>>>> ----- Original Message -----
>>>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Friday, 11 September, 2015 4:48:20 PM
>>>>> Subject: [keycloak-dev] Getting UserModel from inside
>>>>> 	AdminConsole.getMainPage() ?
>>>>>
>>>>> I need to get the current logged-in UserModel from inside this method:
>>>>> https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/admin/AdminConsole.java#L266
>>>>>
>>>>> I tried the same approach as the whoAmI() method, but
>>>>> authManager.authenticateBearerToken() returns null.   I guess the token
>>>>> is not set up yet?
>>>>>
>>>>> Any ideas on an alternate way to get UserModel?
>>>>>
>>>>> Stan
>>>>> _______________________________________________
>>>>> 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 vvessia at katamail.com  Sat Sep 12 10:30:07 2015
From: vvessia at katamail.com (Vito Vessia)
Date: Sat, 12 Sep 2015 16:30:07 +0200
Subject: [keycloak-dev] Is it possible to combine Kerberos
 authentication with an User Federation Provider?
In-Reply-To: <CAMHPs277CHqoe3LJX=O__BqVE2MpuZA9h65n6dQ_aBoc5eTsgA@mail.gmail.com>
References: <CAMHPs26P0EZGoKmcxDtYjrHoyu1BwtAUrgNg-atEKTwuxACzLg@mail.gmail.com>
	<CAMHPs277CHqoe3LJX=O__BqVE2MpuZA9h65n6dQ_aBoc5eTsgA@mail.gmail.com>
Message-ID: <CAMHPs27aUXB3xFj7Su-GOm6+DcGqzLEHxZGfvvJjPYSxu53EbA@mail.gmail.com>

Hi all,
I've a legacy solution that uses its own users (included the password) and
roles database, so due to the migration to Keycloack I've written a User
Federation Provider. Optionally some users may use their Active Directory
credentials to log in on the realm and my User Federation Provider is able
to manage both cases. So I don't use the official LDAP User Federation
Provider provided by Keycloack. I'd like to offer to users mapped on LDAP
the Kerberos authentication. Is it possible to create a similar login
pipeline:
1) The User Kerberos token is valid, so Keycloack grabs it and then calls
my User Federation Provider passing it the username that comes from
Kerberos;
2) OR, the User Kerberos token is NOT valid, so Keycloack shows the login
page to the user and then passes the credentials to my User Federation
Provider.
Thank you in advance,

--Vito
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150912/3e1e828d/attachment-0001.html 

From bburke at redhat.com  Sat Sep 12 15:23:46 2015
From: bburke at redhat.com (Bill Burke)
Date: Sat, 12 Sep 2015 15:23:46 -0400
Subject: [keycloak-dev] Is it possible to combine Kerberos
 authentication with an User Federation Provider?
In-Reply-To: <CAMHPs27aUXB3xFj7Su-GOm6+DcGqzLEHxZGfvvJjPYSxu53EbA@mail.gmail.com>
References: <CAMHPs26P0EZGoKmcxDtYjrHoyu1BwtAUrgNg-atEKTwuxACzLg@mail.gmail.com>
	<CAMHPs277CHqoe3LJX=O__BqVE2MpuZA9h65n6dQ_aBoc5eTsgA@mail.gmail.com>
	<CAMHPs27aUXB3xFj7Su-GOm6+DcGqzLEHxZGfvvJjPYSxu53EbA@mail.gmail.com>
Message-ID: <55F47BC2.70302@redhat.com>

Yes, its possible.  We do this same with our OpenIPA integration.

On 9/12/2015 10:30 AM, Vito Vessia wrote:
> Hi all,
> I've a legacy solution that uses its own users (included the password)
> and roles database, so due to the migration to Keycloack I've written a
> User Federation Provider. Optionally some users may use their Active
> Directory credentials to log in on the realm and my User Federation
> Provider is able to manage both cases. So I don't use the official LDAP
> User Federation Provider provided by Keycloack. I'd like to offer to
> users mapped on LDAP the Kerberos authentication. Is it possible to
> create a similar login pipeline:
> 1) The User Kerberos token is valid, so Keycloack grabs it and then
> calls my User Federation Provider passing it the username that comes
> from Kerberos;
> 2) OR, the User Kerberos token is NOT valid, so Keycloack shows the
> login page to the user and then passes the credentials to my User
> Federation Provider.
> Thank you in advance,
>
> --Vito
>
>
>
> _______________________________________________
> 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 csnyder at iland.com  Mon Sep 14 10:05:12 2015
From: csnyder at iland.com (Cory Snyder)
Date: Mon, 14 Sep 2015 14:05:12 +0000
Subject: [keycloak-dev] Require password change on login when AD is the
 federation provider and pwdLastSet equals 0
Message-ID: <2DD07A49-4DDF-4563-AC4D-DC8874D811A9@iland.com>

With Active Directory, a user is required to change their password on next login if the pwdLastSet attribute on their account is set to zero. It would be nice to redirect the user to a form where they can change their password if they try to login under this scenario. On Keycloak 1.4 it seems that the application currently just displays a login error when this is the case. Any thoughts on this or can I go ahead and create an issue and try to implement this change?

Thanks,

Cory Snyder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150914/957fc7db/attachment.html 

From bburke at redhat.com  Mon Sep 14 11:16:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 11:16:41 -0400
Subject: [keycloak-dev] Require password change on login when AD is the
 federation provider and pwdLastSet equals 0
In-Reply-To: <2DD07A49-4DDF-4563-AC4D-DC8874D811A9@iland.com>
References: <2DD07A49-4DDF-4563-AC4D-DC8874D811A9@iland.com>
Message-ID: <55F6E4D9.3060808@redhat.com>

You should be able to do this in 1.5.  You'd write an authenticator that 
checks this attribute, if 0, then set the update password required action.

On 9/14/2015 10:05 AM, Cory Snyder wrote:
> With Active Directory, a user is required to change their password on
> next login if the pwdLastSet attribute on their account is set to zero.
> It would be nice to redirect the user to a form where they can change
> their password if they try to login under this scenario. On Keycloak 1.4
> it seems that the application currently just displays a login error when
> this is the case. Any thoughts on this or can I go ahead and create an
> issue and try to implement this change?
>
> Thanks,
>
> Cory Snyder
>
>
> _______________________________________________
> 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 Sep 14 11:40:15 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 14 Sep 2015 11:40:15 -0400
Subject: [keycloak-dev] i18n for examples
Message-ID: <55F6EA5F.7060705@redhat.com>

Wondering...

Will we need to do i18n/l10n for the examples?

Do we want to upgrade angular for the examples that us it?  Right now, 
they are still using AngularJS 1.2 while the admin console uses 1.4.



From bburke at redhat.com  Mon Sep 14 11:52:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 11:52:32 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
Message-ID: <55F6ED40.2010609@redhat.com>

I'm running into a problem implementing backchannel logout for our new 
SAML SP.  SAML has no way of transmitting client specific session 
information that I can tell.  So, I need some way of associating an 
auth-server specific session index and the Principal so that I can look 
up an Http Session and invalidate it based on one of those parameters.

We're gonna have the same exact problems when we implement the OIDC 
equivalent specifics (these are new BTW).

I'm thinking of writing a simple Infinispan cache that associates 
principals/session-indexes to http session ids and have it reusable 
between SAML and OIDC adapters.




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

From mposolda at redhat.com  Mon Sep 14 15:16:15 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Sep 2015 21:16:15 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F6ED40.2010609@redhat.com>
References: <55F6ED40.2010609@redhat.com>
Message-ID: <55F71CFF.4070507@redhat.com>

Is it about maintaining infinispan cache on adapter side? I would rather 
avoid this if possible. It's another needed step for setup and IMO 
possible source of troubles (especially in cluster environments).

Isn't it better to start HttpSession on adapter even before SAML 
authentication and transmit HttpSessionID to auth-server in SAMLRequest 
for login? Then auth-server will receive SAMLRequest and save 
HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly 
like done for OIDC). Then server knows HttpSessionId and backchannel 
logout isn't an issue.

Marek

On 14/09/15 17:52, Bill Burke wrote:
> I'm running into a problem implementing backchannel logout for our new
> SAML SP.  SAML has no way of transmitting client specific session
> information that I can tell.  So, I need some way of associating an
> auth-server specific session index and the Principal so that I can look
> up an Http Session and invalidate it based on one of those parameters.
>
> We're gonna have the same exact problems when we implement the OIDC
> equivalent specifics (these are new BTW).
>
> I'm thinking of writing a simple Infinispan cache that associates
> principals/session-indexes to http session ids and have it reusable
> between SAML and OIDC adapters.
>
>
>
>


From mposolda at redhat.com  Mon Sep 14 15:26:37 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Sep 2015 21:26:37 +0200
Subject: [keycloak-dev] Require password change on login when AD is the
 federation provider and pwdLastSet equals 0
In-Reply-To: <55F6E4D9.3060808@redhat.com>
References: <2DD07A49-4DDF-4563-AC4D-DC8874D811A9@iland.com>
	<55F6E4D9.3060808@redhat.com>
Message-ID: <55F71F6D.6000702@redhat.com>

The JIRA for almost the same issue already exists 
https://issues.jboss.org/browse/KEYCLOAK-1744 . Theoretically we can 
parse the error code sent from Active Directory and set the update 
password required action based on that. But I don't know if we should go 
this way as error codes are Active Directory specific. On the other 
hand, majority of people likely use Active Directory as LDAP 
implementation...

Maybe we should look into it if more people ask for this to be available 
OOTB?

Marek

On 14/09/15 17:16, Bill Burke wrote:
> You should be able to do this in 1.5.  You'd write an authenticator that
> checks this attribute, if 0, then set the update password required action.
>
> On 9/14/2015 10:05 AM, Cory Snyder wrote:
>> With Active Directory, a user is required to change their password on
>> next login if the pwdLastSet attribute on their account is set to zero.
>> It would be nice to redirect the user to a form where they can change
>> their password if they try to login under this scenario. On Keycloak 1.4
>> it seems that the application currently just displays a login error when
>> this is the case. Any thoughts on this or can I go ahead and create an
>> issue and try to implement this change?
>>
>> Thanks,
>>
>> Cory Snyder
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Mon Sep 14 15:28:06 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 15:28:06 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F71CFF.4070507@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
Message-ID: <55F71FC6.6080909@redhat.com>

I agree with you 100% Marek, but what you did for the Keycloak adapter 
Marek was an proprietary extension to OIDC.  There is no standard way to 
do this in SAML that I know of.  We will have the same problem in the 
new Logout OpenID Connection specification too.

We need something that will work with non-Keycloak IDPs.



On 9/14/2015 3:16 PM, Marek Posolda wrote:
> Is it about maintaining infinispan cache on adapter side? I would rather
> avoid this if possible. It's another needed step for setup and IMO
> possible source of troubles (especially in cluster environments).
>
> Isn't it better to start HttpSession on adapter even before SAML
> authentication and transmit HttpSessionID to auth-server in SAMLRequest
> for login? Then auth-server will receive SAMLRequest and save
> HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly
> like done for OIDC). Then server knows HttpSessionId and backchannel
> logout isn't an issue.
>
> Marek
>
> On 14/09/15 17:52, Bill Burke wrote:
>> I'm running into a problem implementing backchannel logout for our new
>> SAML SP.  SAML has no way of transmitting client specific session
>> information that I can tell.  So, I need some way of associating an
>> auth-server specific session index and the Principal so that I can look
>> up an Http Session and invalidate it based on one of those parameters.
>>
>> We're gonna have the same exact problems when we implement the OIDC
>> equivalent specifics (these are new BTW).
>>
>> I'm thinking of writing a simple Infinispan cache that associates
>> principals/session-indexes to http session ids and have it reusable
>> between SAML and OIDC adapters.
>>
>>
>>
>>
>

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

From mposolda at redhat.com  Mon Sep 14 15:42:55 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Sep 2015 21:42:55 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F71FC6.6080909@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com>
Message-ID: <55F7233F.3030706@redhat.com>

Hmm... I don't know much yet about new Logout OIDC specification :/

But for SAML, I am not seeing a problem as long as we start HttpSession 
before authentication. We can possibly transmit HttpSessionID in ID 
attribute of SAMLRequest, which can be compound of random UUID and 
HttpSessionID divided by dot. Something like:

<samlp:AuthnRequest ID="some-random-uuid.HttpSessionId" ...>

It is bit cumbersome though, but IMO better than additional state on 
adapters?

Marek

On 14/09/15 21:28, Bill Burke wrote:
> I agree with you 100% Marek, but what you did for the Keycloak adapter 
> Marek was an proprietary extension to OIDC.  There is no standard way 
> to do this in SAML that I know of.  We will have the same problem in 
> the new Logout OpenID Connection specification too.
>
> We need something that will work with non-Keycloak IDPs.
>
>
>
> On 9/14/2015 3:16 PM, Marek Posolda wrote:
>> Is it about maintaining infinispan cache on adapter side? I would rather
>> avoid this if possible. It's another needed step for setup and IMO
>> possible source of troubles (especially in cluster environments).
>>
>> Isn't it better to start HttpSession on adapter even before SAML
>> authentication and transmit HttpSessionID to auth-server in SAMLRequest
>> for login? Then auth-server will receive SAMLRequest and save
>> HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly
>> like done for OIDC). Then server knows HttpSessionId and backchannel
>> logout isn't an issue.
>>
>> Marek
>>
>> On 14/09/15 17:52, Bill Burke wrote:
>>> I'm running into a problem implementing backchannel logout for our new
>>> SAML SP.  SAML has no way of transmitting client specific session
>>> information that I can tell.  So, I need some way of associating an
>>> auth-server specific session index and the Principal so that I can look
>>> up an Http Session and invalidate it based on one of those parameters.
>>>
>>> We're gonna have the same exact problems when we implement the OIDC
>>> equivalent specifics (these are new BTW).
>>>
>>> I'm thinking of writing a simple Infinispan cache that associates
>>> principals/session-indexes to http session ids and have it reusable
>>> between SAML and OIDC adapters.
>>>
>>>
>>>
>>>
>>
>


From bburke at redhat.com  Mon Sep 14 15:46:43 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 15:46:43 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F7233F.3030706@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
Message-ID: <55F72423.9000706@redhat.com>

The SAML IdP is not required to send back that id.  That ID is just the 
ID of the request.

A hack I'm thinking of is to create an HttpSession that is shared by 
everybody and store this SSO id/username -> to -> HttpSession id map there.

On 9/14/2015 3:42 PM, Marek Posolda wrote:
> Hmm... I don't know much yet about new Logout OIDC specification :/
>
> But for SAML, I am not seeing a problem as long as we start HttpSession
> before authentication. We can possibly transmit HttpSessionID in ID
> attribute of SAMLRequest, which can be compound of random UUID and
> HttpSessionID divided by dot. Something like:
>
> <samlp:AuthnRequest ID="some-random-uuid.HttpSessionId" ...>
>
> It is bit cumbersome though, but IMO better than additional state on
> adapters?
>
> Marek
>
> On 14/09/15 21:28, Bill Burke wrote:
>> I agree with you 100% Marek, but what you did for the Keycloak adapter
>> Marek was an proprietary extension to OIDC.  There is no standard way
>> to do this in SAML that I know of.  We will have the same problem in
>> the new Logout OpenID Connection specification too.
>>
>> We need something that will work with non-Keycloak IDPs.
>>
>>
>>
>> On 9/14/2015 3:16 PM, Marek Posolda wrote:
>>> Is it about maintaining infinispan cache on adapter side? I would rather
>>> avoid this if possible. It's another needed step for setup and IMO
>>> possible source of troubles (especially in cluster environments).
>>>
>>> Isn't it better to start HttpSession on adapter even before SAML
>>> authentication and transmit HttpSessionID to auth-server in SAMLRequest
>>> for login? Then auth-server will receive SAMLRequest and save
>>> HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly
>>> like done for OIDC). Then server knows HttpSessionId and backchannel
>>> logout isn't an issue.
>>>
>>> Marek
>>>
>>> On 14/09/15 17:52, Bill Burke wrote:
>>>> I'm running into a problem implementing backchannel logout for our new
>>>> SAML SP.  SAML has no way of transmitting client specific session
>>>> information that I can tell.  So, I need some way of associating an
>>>> auth-server specific session index and the Principal so that I can look
>>>> up an Http Session and invalidate it based on one of those parameters.
>>>>
>>>> We're gonna have the same exact problems when we implement the OIDC
>>>> equivalent specifics (these are new BTW).
>>>>
>>>> I'm thinking of writing a simple Infinispan cache that associates
>>>> principals/session-indexes to http session ids and have it reusable
>>>> between SAML and OIDC adapters.
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

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

From mposolda at redhat.com  Mon Sep 14 16:20:58 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Sep 2015 22:20:58 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F72423.9000706@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com>
Message-ID: <55F72C2A.8060108@redhat.com>

On 14/09/15 21:46, Bill Burke wrote:
> The SAML IdP is not required to send back that id.  That ID is just 
> the ID of the request.
The SAML IdP doesn't need to send anything back. I meant that 
HttpSessionID will be send in the ID of SAMLRequest from SAML SP to 
auth-server . I don't know if there is any better attribute/element of 
AuthnRequest, which can be used to transmit such "custom" data.

>
> A hack I'm thinking of is to create an HttpSession that is shared by 
> everybody and store this SSO id/username -> to -> HttpSession id map 
> there.
That's good, we can avoid dependency on infinispan. But still, we will 
need the stuff like periodic cleaner thread, which will remove expired 
items from this HttpSession map. And this solution requires HttpSession 
replication if I understand correctly?

As of now, we don't require HttpSession replication for OIDC. Qe support 
the deployments when the application is deployed on more "cluster" nodes 
behind loadbalancer, but application cluster nodes don't communicate 
with each other. In other words, there is no "distributable" in web.xml 
. For this case, we have CLIENT_SESSION_HOST note, so the OIDC 
backchannel request is sent to same cluster node from which was 
code-to-token request sent earlier.

Marek


>
> On 9/14/2015 3:42 PM, Marek Posolda wrote:
>> Hmm... I don't know much yet about new Logout OIDC specification :/
>>
>> But for SAML, I am not seeing a problem as long as we start HttpSession
>> before authentication. We can possibly transmit HttpSessionID in ID
>> attribute of SAMLRequest, which can be compound of random UUID and
>> HttpSessionID divided by dot. Something like:
>>
>> <samlp:AuthnRequest ID="some-random-uuid.HttpSessionId" ...>
>>
>> It is bit cumbersome though, but IMO better than additional state on
>> adapters?
>>
>> Marek
>>
>> On 14/09/15 21:28, Bill Burke wrote:
>>> I agree with you 100% Marek, but what you did for the Keycloak adapter
>>> Marek was an proprietary extension to OIDC.  There is no standard way
>>> to do this in SAML that I know of.  We will have the same problem in
>>> the new Logout OpenID Connection specification too.
>>>
>>> We need something that will work with non-Keycloak IDPs.
>>>
>>>
>>>
>>> On 9/14/2015 3:16 PM, Marek Posolda wrote:
>>>> Is it about maintaining infinispan cache on adapter side? I would 
>>>> rather
>>>> avoid this if possible. It's another needed step for setup and IMO
>>>> possible source of troubles (especially in cluster environments).
>>>>
>>>> Isn't it better to start HttpSession on adapter even before SAML
>>>> authentication and transmit HttpSessionID to auth-server in 
>>>> SAMLRequest
>>>> for login? Then auth-server will receive SAMLRequest and save
>>>> HttpSessionID to CLIENT_SESSION_STATE note on ClientSession (similarly
>>>> like done for OIDC). Then server knows HttpSessionId and backchannel
>>>> logout isn't an issue.
>>>>
>>>> Marek
>>>>
>>>> On 14/09/15 17:52, Bill Burke wrote:
>>>>> I'm running into a problem implementing backchannel logout for our 
>>>>> new
>>>>> SAML SP.  SAML has no way of transmitting client specific session
>>>>> information that I can tell.  So, I need some way of associating an
>>>>> auth-server specific session index and the Principal so that I can 
>>>>> look
>>>>> up an Http Session and invalidate it based on one of those 
>>>>> parameters.
>>>>>
>>>>> We're gonna have the same exact problems when we implement the OIDC
>>>>> equivalent specifics (these are new BTW).
>>>>>
>>>>> I'm thinking of writing a simple Infinispan cache that associates
>>>>> principals/session-indexes to http session ids and have it reusable
>>>>> between SAML and OIDC adapters.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>


From bburke at redhat.com  Mon Sep 14 16:41:01 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Sep 2015 16:41:01 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F72C2A.8060108@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
Message-ID: <55F730DD.2040200@redhat.com>



On 9/14/2015 4:20 PM, Marek Posolda wrote:
> On 14/09/15 21:46, Bill Burke wrote:
>> The SAML IdP is not required to send back that id.  That ID is just
>> the ID of the request.
> The SAML IdP doesn't need to send anything back. I meant that
> HttpSessionID will be send in the ID of SAMLRequest from SAML SP to
> auth-server . I don't know if there is any better attribute/element of
> AuthnRequest, which can be used to transmit such "custom" data.
>

SAML logout requests to the SP client contain the principal name and/or 
possibly one *or more* SSO IDs (session indexes).  New OIDC spec will 
work similarly.

>>
>> A hack I'm thinking of is to create an HttpSession that is shared by
>> everybody and store this SSO id/username -> to -> HttpSession id map
>> there.
> That's good, we can avoid dependency on infinispan.

Ugh, unfortunately, you can't provide our own session id with Undertow's 
or Jetty's sessionmanager interface. :(  So no way to hack this except 
for Tomcat and JbossWeb.

> But still, we will
> need the stuff like periodic cleaner thread, which will remove expired
> items from this HttpSession map. And this solution requires HttpSession
> replication if I understand correctly?
>

Replication would be required, but all these servlet containers contain 
session lifecycle listener SPIs, so there is no need for reaper threads. 
  But, can't do it anyways...

> As of now, we don't require HttpSession replication for OIDC. Qe support
> the deployments when the application is deployed on more "cluster" nodes
> behind loadbalancer, but application cluster nodes don't communicate
> with each other. In other words, there is no "distributable" in web.xml
> . For this case, we have CLIENT_SESSION_HOST note, so the OIDC
> backchannel request is sent to same cluster node from which was
> code-to-token request sent earlier.
>

Again, not something we can implement in a standard/portable way.

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

From alex_orl1079 at yahoo.it  Mon Sep 14 19:48:17 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 14 Sep 2015 23:48:17 +0000 (UTC)
Subject: [keycloak-dev] EntityManager not injected into Jboss Module
Message-ID: <2105886452.3446195.1442274497500.JavaMail.yahoo@mail.yahoo.com>

I'm working with jboss wildfly 9. I have a provider deployed as module into the :
? ? wildfly > modules > com > mycompany > myprovider
folder. Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.
Now face the real problem: it seems i cannot use the @PersistenceContext annotation to inject the entity managare into my EntityManager varible:
? ? @PersistenceContext(unitName = "KAS-Mapping") ?private EntityManager entityManager;
this is my persistence.xml

? ??? ? <persistence version="2.1" ...>? ? ? ? <persistence-unit name="KAS-Mapping">? ? ? ? ? ? <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>?? ? ? ? ? ? ? ? <class>my.class.persistence.model.MapGroup</class>? ? ? ? ? ? ? ? <clas>my.class.persistence.model.MapUser</class>? ? ? ? ? ? ? ? <properties>? ? ? ? ? ? ? ? ? ? <property name="javax.persistence.provider" value="org.hibernate.ejb.HibernatePersistence" />? ? ? ? ? ? ? ? ? ? <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle10gDialect"/>? ? ? ? ? ? ? ? ? ? <property name="javax.persistence.provider" value="org.hibernate.jpa.HibernatePersistenceProvider"/>? ? ? ? ? ? ? ? ? ? <property name="javax.persistence.transactionType" value="JTA"/>? ? ? ? ? ? ? ? ? ? <property name="javax.persistence.jtaDataSource" value="java:jboss/datasources/MyDS"/>
? ? ? ? ? ? </properties>? ? ? ? </persistence-unit>? ? </persistence>?
Why i cannot inject the a context into a jar modules? What am i wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150914/e9373ce9/attachment.html 

From alex_orl1079 at yahoo.it  Mon Sep 14 19:52:04 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 14 Sep 2015 23:52:04 +0000 (UTC)
Subject: [keycloak-dev] EntityManager not injected into Jboss Module
In-Reply-To: <2105886452.3446195.1442274497500.JavaMail.yahoo@mail.yahoo.com>
References: <2105886452.3446195.1442274497500.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <865126429.3513526.1442274724719.JavaMail.yahoo@mail.yahoo.com>

I'm working with jboss wildfly 9. I have a provider deployed as module into the ? modules ?directory.Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.


Now i m facing ?the real problem: it seems i cannot use the PersistenceContext annotation to inject the entity managare into my EntityManager variable wich is always null.

Why i cannot inject the a context into a jar modules? What am i wrong?


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

From alex_orl1079 at yahoo.it  Mon Sep 14 19:53:43 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 14 Sep 2015 23:53:43 +0000 (UTC)
Subject: [keycloak-dev] EntityManager not injected into Jboss Module
Message-ID: <147334982.3506378.1442274823063.JavaMail.yahoo@mail.yahoo.com>

I'm working with jboss wildfly 9. I have a provider deployed as module into the ? modules ?directory.Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.Now i m facing ?the real problem: it seems i cannot use the PersistenceContext annotation to inject the entity manager into my EntityManager variable wich is always null. Why i cannot inject the a context into a jar modules? What am i wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150914/42742beb/attachment-0001.html 

From bdawidow at redhat.com  Tue Sep 15 04:02:57 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 15 Sep 2015 10:02:57 +0200
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <55F6EA5F.7060705@redhat.com>
References: <55F6EA5F.7060705@redhat.com>
Message-ID: <CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>

I would rather keep them simple.

We would consider a single bigger and more complex one - then it would fit.

On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> Wondering...
>
> Will we need to do i18n/l10n for the examples?
>
> Do we want to upgrade angular for the examples that us it?  Right now,
> they are still using AngularJS 1.2 while the admin console uses 1.4.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



-- 
Boles?aw Dawidowicz


From sthorger at redhat.com  Tue Sep 15 07:29:30 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 13:29:30 +0200
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
References: <55F6EA5F.7060705@redhat.com>
	<CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
Message-ID: <CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>

Why would we need i18n/l10n for examples? We don't provide
internationalization of applications themselves.

On 15 September 2015 at 10:02, Boleslaw Dawidowicz <bdawidow at redhat.com>
wrote:

> I would rather keep them simple.
>
> We would consider a single bigger and more complex one - then it would fit.
>
> On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> > Wondering...
> >
> > Will we need to do i18n/l10n for the examples?
> >
> > Do we want to upgrade angular for the examples that us it?  Right now,
> > they are still using AngularJS 1.2 while the admin console uses 1.4.
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> --
> Boles?aw Dawidowicz
>
> _______________________________________________
> 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/20150915/1b3b01a2/attachment.html 

From sthorger at redhat.com  Tue Sep 15 07:30:50 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 13:30:50 +0200
Subject: [keycloak-dev] EntityManager not injected into Jboss Module
In-Reply-To: <147334982.3506378.1442274823063.JavaMail.yahoo@mail.yahoo.com>
References: <147334982.3506378.1442274823063.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAJgngAeqU35dGWXwnqmL2oT-nW3Gra8XLGONDo2Gqmmz9HifLw@mail.gmail.com>

Providers should be written as POJO's. There's no support for EJBs, CDI or
any other JavaEE features. You need to retrieve the EntityManager yourself
using the good old Persistence class.

On 15 September 2015 at 01:53, alex orl <alex_orl1079 at yahoo.it> wrote:

> I'm working with jboss wildfly 9. I have a provider deployed as module
> into the   modules  directory.
> Then i have a jpa project with DAO pattern writing and reading inside my
> database. I want to handle the DAO transaction using JTA but in order to
> make the DAO class visibile to myprovider i need to put the DAO JPA project
> inside the modules directory too.
> Now i m facing  the real problem: it seems i cannot use the
> PersistenceContext annotation to inject the entity manager into my
> EntityManager variable wich is always null. Why i cannot inject the a
> context into a jar modules? What am i wrong?
>
> _______________________________________________
> 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/20150915/c8ba82ff/attachment.html 

From lennart.jorelid at gmail.com  Tue Sep 15 07:35:35 2015
From: lennart.jorelid at gmail.com (=?utf-8?Q?Lennart_J=C3=B6relid?=)
Date: Tue, 15 Sep 2015 13:35:35 +0200
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>
References: <55F6EA5F.7060705@redhat.com>
	<CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
	<CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>
Message-ID: <DAB66758-E5D3-4A39-97F9-017F517DD77B@gmail.com>

That is - in itself - a problem for an application with works-out-of-the-Box aspirations, yes?

// v?nlig h?lsning,
// [sw: "best regards"],
//
// Lennart J?relid

> 15 sep 2015 kl. 13:29 skrev Stian Thorgersen <sthorger at redhat.com>:
> 
> Why would we need i18n/l10n for examples? We don't provide internationalization of applications themselves.
> 
>> On 15 September 2015 at 10:02, Boleslaw Dawidowicz <bdawidow at redhat.com> wrote:
>> I would rather keep them simple.
>> 
>> We would consider a single bigger and more complex one - then it would fit.
>> 
>> On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert at redhat.com> wrote:
>> > Wondering...
>> >
>> > Will we need to do i18n/l10n for the examples?
>> >
>> > Do we want to upgrade angular for the examples that us it?  Right now,
>> > they are still using AngularJS 1.2 while the admin console uses 1.4.
>> >
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> 
>> 
>> --
>> Boles?aw Dawidowicz
>> 
>> _______________________________________________
>> 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/20150915/bf7d711f/attachment.html 

From sthorger at redhat.com  Tue Sep 15 07:40:50 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 13:40:50 +0200
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <DAB66758-E5D3-4A39-97F9-017F517DD77B@gmail.com>
References: <55F6EA5F.7060705@redhat.com>
	<CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
	<CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>
	<DAB66758-E5D3-4A39-97F9-017F517DD77B@gmail.com>
Message-ID: <CAJgngAdjdx37bpfxtcPVYusb6KT=XsRAWq87hOECX3bUuEbfeg@mail.gmail.com>

Got no clue what you're saying

On 15 September 2015 at 13:35, Lennart J?relid <lennart.jorelid at gmail.com>
wrote:

> That is - in itself - a problem for an application with
> works-out-of-the-Box aspirations, yes?
>
> // v?nlig h?lsning,
> // [sw: "best regards"],
> //
> // Lennart J?relid
>
> 15 sep 2015 kl. 13:29 skrev Stian Thorgersen <sthorger at redhat.com>:
>
> Why would we need i18n/l10n for examples? We don't provide
> internationalization of applications themselves.
>
> On 15 September 2015 at 10:02, Boleslaw Dawidowicz <bdawidow at redhat.com>
> wrote:
>
>> I would rather keep them simple.
>>
>> We would consider a single bigger and more complex one - then it would
>> fit.
>>
>> On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert at redhat.com>
>> wrote:
>> > Wondering...
>> >
>> > Will we need to do i18n/l10n for the examples?
>> >
>> > Do we want to upgrade angular for the examples that us it?  Right now,
>> > they are still using AngularJS 1.2 while the admin console uses 1.4.
>> >
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> --
>> Boles?aw Dawidowicz
>>
>> _______________________________________________
>> 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/20150915/8d598be0/attachment.html 

From ssilvert at redhat.com  Tue Sep 15 07:50:46 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 15 Sep 2015 07:50:46 -0400
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <CAJgngAdjdx37bpfxtcPVYusb6KT=XsRAWq87hOECX3bUuEbfeg@mail.gmail.com>
References: <55F6EA5F.7060705@redhat.com>
	<CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
	<CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>
	<DAB66758-E5D3-4A39-97F9-017F517DD77B@gmail.com>
	<CAJgngAdjdx37bpfxtcPVYusb6KT=XsRAWq87hOECX3bUuEbfeg@mail.gmail.com>
Message-ID: <55F80616.5080700@redhat.com>

On 9/15/2015 7:40 AM, Stian Thorgersen wrote:
> Got no clue what you're saying
I think he is perhaps saying that developers who don't speak English 
should be able to learn and use Keycloak out of the box.

I was asking if it is a productization requirement.

>
> On 15 September 2015 at 13:35, Lennart J?relid 
> <lennart.jorelid at gmail.com <mailto:lennart.jorelid at gmail.com>> wrote:
>
>     That is - in itself - a problem for an application with
>     works-out-of-the-Box aspirations, yes?
>
>     // v?nlig h?lsning,
>     // [sw: "best regards"],
>     //
>     // Lennart J?relid
>
>     15 sep 2015 kl. 13:29 skrev Stian Thorgersen <sthorger at redhat.com
>     <mailto:sthorger at redhat.com>>:
>
>>     Why would we need i18n/l10n for examples? We don't provide
>>     internationalization of applications themselves.
>>
>>     On 15 September 2015 at 10:02, Boleslaw Dawidowicz
>>     <bdawidow at redhat.com <mailto:bdawidow at redhat.com>> wrote:
>>
>>         I would rather keep them simple.
>>
>>         We would consider a single bigger and more complex one - then
>>         it would fit.
>>
>>         On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert
>>         <ssilvert at redhat.com <mailto:ssilvert at redhat.com>> wrote:
>>         > Wondering...
>>         >
>>         > Will we need to do i18n/l10n for the examples?
>>         >
>>         > Do we want to upgrade angular for the examples that us it? 
>>         Right now,
>>         > they are still using AngularJS 1.2 while the admin console
>>         uses 1.4.
>>         >
>>         >
>>         > _______________________________________________
>>         > 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
>>
>>
>>
>>         --
>>         Boles?aw Dawidowicz
>>
>>         _______________________________________________
>>         keycloak-dev mailing list
>>         keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From sthorger at redhat.com  Tue Sep 15 07:54:13 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 13:54:13 +0200
Subject: [keycloak-dev] i18n for examples
In-Reply-To: <CAGHMyQ1nB3+bqJJq69QVCqQiBCiGridXAHLAF6gp1kAZM-5G_Q@mail.gmail.com>
References: <55F6EA5F.7060705@redhat.com>
	<CABbwURHY6Cb+fuTwHvVknQLUjUj7W9HgpevuewouHZsMk4998g@mail.gmail.com>
	<CAJgngAfz-6akPk_G6NKon__PQrQnRuNeo3bU3YPrDwc6tJgH3Q@mail.gmail.com>
	<DAB66758-E5D3-4A39-97F9-017F517DD77B@gmail.com>
	<CAGHMyQ1nB3+bqJJq69QVCqQiBCiGridXAHLAF6gp1kAZM-5G_Q@mail.gmail.com>
Message-ID: <CAJgngAdmZGRyoKKF4=_hkk7hspn_edDvmn+5hDuQUuJAKQW2qA@mail.gmail.com>

There's two things you can do:

1. You can pass the users locale to Keycloak with the ui_locales param when
the user logs in
2. Add the locale to the token with a mapper so your application can read
what locale the user has selected in Keycloak

On 15 September 2015 at 13:46, Tair Sabirgaliev <tair.sabirgaliev at bee.kz>
wrote:

> Is it possible to reuse the user account language settings across sso
> domain? That is an important use case for my project?
> On ??, 15 ????. 2015 ?. at 17:36 Lennart J?relid <
> lennart.jorelid at gmail.com> wrote:
>
>> That is - in itself - a problem for an application with
>> works-out-of-the-Box aspirations, yes?
>>
>> // v?nlig h?lsning,
>> // [sw: "best regards"],
>> //
>> // Lennart J?relid
>>
>> 15 sep 2015 kl. 13:29 skrev Stian Thorgersen <sthorger at redhat.com>:
>>
>> Why would we need i18n/l10n for examples? We don't provide
>> internationalization of applications themselves.
>>
>> On 15 September 2015 at 10:02, Boleslaw Dawidowicz <bdawidow at redhat.com>
>> wrote:
>>
>>> I would rather keep them simple.
>>>
>>> We would consider a single bigger and more complex one - then it would
>>> fit.
>>>
>>> On Mon, Sep 14, 2015 at 5:40 PM, Stan Silvert <ssilvert at redhat.com>
>>> wrote:
>>> > Wondering...
>>> >
>>> > Will we need to do i18n/l10n for the examples?
>>> >
>>> > Do we want to upgrade angular for the examples that us it?  Right now,
>>> > they are still using AngularJS 1.2 while the admin console uses 1.4.
>>> >
>>> >
>>> > _______________________________________________
>>> > keycloak-dev mailing list
>>> > keycloak-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> --
>>> Boles?aw Dawidowicz
>>>
>>> _______________________________________________
>>> 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/20150915/a0e4b6c6/attachment.html 

From bburke at redhat.com  Tue Sep 15 08:58:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Sep 2015 08:58:50 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
Message-ID: <55F8160A.5020200@redhat.com>

We can do anything we want on the server side, the problem is that our 
client adapters, SAML and OIDC, should be able to work with non-Keycloak 
IdPs.

On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
> Could we store the mapping on the Keycloak side? client-id + http
> session id --> KC session id?
>
> On 14 September 2015 at 22:41, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>
>
>     On 9/14/2015 4:20 PM, Marek Posolda wrote:
>     > On 14/09/15 21:46, Bill Burke wrote:
>     >> The SAML IdP is not required to send back that id.  That ID is just
>     >> the ID of the request.
>     > The SAML IdP doesn't need to send anything back. I meant that
>     > HttpSessionID will be send in the ID of SAMLRequest from SAML SP to
>     > auth-server . I don't know if there is any better attribute/element of
>     > AuthnRequest, which can be used to transmit such "custom" data.
>     >
>
>     SAML logout requests to the SP client contain the principal name and/or
>     possibly one *or more* SSO IDs (session indexes).  New OIDC spec will
>     work similarly.
>
>     >>
>     >> A hack I'm thinking of is to create an HttpSession that is shared by
>     >> everybody and store this SSO id/username -> to -> HttpSession id map
>     >> there.
>     > That's good, we can avoid dependency on infinispan.
>
>     Ugh, unfortunately, you can't provide our own session id with Undertow's
>     or Jetty's sessionmanager interface. :(  So no way to hack this except
>     for Tomcat and JbossWeb.
>
>     > But still, we will
>     > need the stuff like periodic cleaner thread, which will remove expired
>     > items from this HttpSession map. And this solution requires HttpSession
>     > replication if I understand correctly?
>     >
>
>     Replication would be required, but all these servlet containers contain
>     session lifecycle listener SPIs, so there is no need for reaper threads.
>        But, can't do it anyways...
>
>     > As of now, we don't require HttpSession replication for OIDC. Qe support
>     > the deployments when the application is deployed on more "cluster" nodes
>     > behind loadbalancer, but application cluster nodes don't communicate
>     > with each other. In other words, there is no "distributable" in web.xml
>     > . For this case, we have CLIENT_SESSION_HOST note, so the OIDC
>     > backchannel request is sent to same cluster node from which was
>     > code-to-token request sent earlier.
>     >
>
>     Again, not something we can implement in a standard/portable way.
>
>     --
>     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

From sthorger at redhat.com  Tue Sep 15 09:04:25 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 15:04:25 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F8160A.5020200@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
	<55F8160A.5020200@redhat.com>
Message-ID: <CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>

Isn't the http session id part of the standard backchannel log out?

On 15 September 2015 at 14:58, Bill Burke <bburke at redhat.com> wrote:

> We can do anything we want on the server side, the problem is that our
> client adapters, SAML and OIDC, should be able to work with non-Keycloak
> IdPs.
>
> On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
>
>> Could we store the mapping on the Keycloak side? client-id + http
>> session id --> KC session id?
>>
>> On 14 September 2015 at 22:41, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>     On 9/14/2015 4:20 PM, Marek Posolda wrote:
>>     > On 14/09/15 21:46, Bill Burke wrote:
>>     >> The SAML IdP is not required to send back that id.  That ID is just
>>     >> the ID of the request.
>>     > The SAML IdP doesn't need to send anything back. I meant that
>>     > HttpSessionID will be send in the ID of SAMLRequest from SAML SP to
>>     > auth-server . I don't know if there is any better attribute/element
>> of
>>     > AuthnRequest, which can be used to transmit such "custom" data.
>>     >
>>
>>     SAML logout requests to the SP client contain the principal name
>> and/or
>>     possibly one *or more* SSO IDs (session indexes).  New OIDC spec will
>>     work similarly.
>>
>>     >>
>>     >> A hack I'm thinking of is to create an HttpSession that is shared
>> by
>>     >> everybody and store this SSO id/username -> to -> HttpSession id
>> map
>>     >> there.
>>     > That's good, we can avoid dependency on infinispan.
>>
>>     Ugh, unfortunately, you can't provide our own session id with
>> Undertow's
>>     or Jetty's sessionmanager interface. :(  So no way to hack this except
>>     for Tomcat and JbossWeb.
>>
>>     > But still, we will
>>     > need the stuff like periodic cleaner thread, which will remove
>> expired
>>     > items from this HttpSession map. And this solution requires
>> HttpSession
>>     > replication if I understand correctly?
>>     >
>>
>>     Replication would be required, but all these servlet containers
>> contain
>>     session lifecycle listener SPIs, so there is no need for reaper
>> threads.
>>        But, can't do it anyways...
>>
>>     > As of now, we don't require HttpSession replication for OIDC. Qe
>> support
>>     > the deployments when the application is deployed on more "cluster"
>> nodes
>>     > behind loadbalancer, but application cluster nodes don't communicate
>>     > with each other. In other words, there is no "distributable" in
>> web.xml
>>     > . For this case, we have CLIENT_SESSION_HOST note, so the OIDC
>>     > backchannel request is sent to same cluster node from which was
>>     > code-to-token request sent earlier.
>>     >
>>
>>     Again, not something we can implement in a standard/portable way.
>>
>>     --
>>     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/20150915/0ce4635d/attachment.html 

From bburke at redhat.com  Tue Sep 15 09:14:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Sep 2015 09:14:21 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
	<55F8160A.5020200@redhat.com>
	<CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>
Message-ID: <55F819AD.2010005@redhat.com>

no.  The session id sent with the logout request is the SSO session id. 
  The client does not transmit its session id to the IdP.

On 9/15/2015 9:04 AM, Stian Thorgersen wrote:
> Isn't the http session id part of the standard backchannel log out?
>
> On 15 September 2015 at 14:58, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     We can do anything we want on the server side, the problem is that
>     our client adapters, SAML and OIDC, should be able to work with
>     non-Keycloak IdPs.
>
>     On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
>
>         Could we store the mapping on the Keycloak side? client-id + http
>         session id --> KC session id?
>
>         On 14 September 2015 at 22:41, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>
>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>
>
>
>              On 9/14/2015 4:20 PM, Marek Posolda wrote:
>              > On 14/09/15 21:46, Bill Burke wrote:
>              >> The SAML IdP is not required to send back that id.  That
>         ID is just
>              >> the ID of the request.
>              > The SAML IdP doesn't need to send anything back. I meant that
>              > HttpSessionID will be send in the ID of SAMLRequest from
>         SAML SP to
>              > auth-server . I don't know if there is any better
>         attribute/element of
>              > AuthnRequest, which can be used to transmit such "custom"
>         data.
>              >
>
>              SAML logout requests to the SP client contain the principal
>         name and/or
>              possibly one *or more* SSO IDs (session indexes).  New OIDC
>         spec will
>              work similarly.
>
>              >>
>              >> A hack I'm thinking of is to create an HttpSession that
>         is shared by
>              >> everybody and store this SSO id/username -> to ->
>         HttpSession id map
>              >> there.
>              > That's good, we can avoid dependency on infinispan.
>
>              Ugh, unfortunately, you can't provide our own session id
>         with Undertow's
>              or Jetty's sessionmanager interface. :(  So no way to hack
>         this except
>              for Tomcat and JbossWeb.
>
>              > But still, we will
>              > need the stuff like periodic cleaner thread, which will
>         remove expired
>              > items from this HttpSession map. And this solution
>         requires HttpSession
>              > replication if I understand correctly?
>              >
>
>              Replication would be required, but all these servlet
>         containers contain
>              session lifecycle listener SPIs, so there is no need for
>         reaper threads.
>                 But, can't do it anyways...
>
>              > As of now, we don't require HttpSession replication for
>         OIDC. Qe support
>              > the deployments when the application is deployed on more
>         "cluster" nodes
>              > behind loadbalancer, but application cluster nodes don't
>         communicate
>              > with each other. In other words, there is no
>         "distributable" in web.xml
>              > . For this case, we have CLIENT_SESSION_HOST note, so the
>         OIDC
>              > backchannel request is sent to same cluster node from
>         which was
>              > code-to-token request sent earlier.
>              >
>
>              Again, not something we can implement in a
>         standard/portable way.
>
>              --
>              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>
>         <mailto: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

From sthorger at redhat.com  Tue Sep 15 09:23:44 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 15:23:44 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F819AD.2010005@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
	<55F8160A.5020200@redhat.com>
	<CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>
	<55F819AD.2010005@redhat.com>
Message-ID: <CAJgngAcNJSj44U_k=hALZ3xPmCicSXat6pfoZuYkwuD1JEftJw@mail.gmail.com>

Oh, I turned things around - I thought it was the SSO session id that was
missing, not the http session id. Ignore everything I've said up until now
;)

Maybe we could make the SSO Session ID --> HTTP Session ID map pluggable
then? By default it would use the mechanism Marek implemented, but then we
can support other means as well?

On 15 September 2015 at 15:14, Bill Burke <bburke at redhat.com> wrote:

> no.  The session id sent with the logout request is the SSO session id.
> The client does not transmit its session id to the IdP.
>
> On 9/15/2015 9:04 AM, Stian Thorgersen wrote:
>
>> Isn't the http session id part of the standard backchannel log out?
>>
>> On 15 September 2015 at 14:58, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     We can do anything we want on the server side, the problem is that
>>     our client adapters, SAML and OIDC, should be able to work with
>>     non-Keycloak IdPs.
>>
>>     On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
>>
>>         Could we store the mapping on the Keycloak side? client-id + http
>>         session id --> KC session id?
>>
>>         On 14 September 2015 at 22:41, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>
>>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>>
>>
>>
>>              On 9/14/2015 4:20 PM, Marek Posolda wrote:
>>              > On 14/09/15 21:46, Bill Burke wrote:
>>              >> The SAML IdP is not required to send back that id.  That
>>         ID is just
>>              >> the ID of the request.
>>              > The SAML IdP doesn't need to send anything back. I meant
>> that
>>              > HttpSessionID will be send in the ID of SAMLRequest from
>>         SAML SP to
>>              > auth-server . I don't know if there is any better
>>         attribute/element of
>>              > AuthnRequest, which can be used to transmit such "custom"
>>         data.
>>              >
>>
>>              SAML logout requests to the SP client contain the principal
>>         name and/or
>>              possibly one *or more* SSO IDs (session indexes).  New OIDC
>>         spec will
>>              work similarly.
>>
>>              >>
>>              >> A hack I'm thinking of is to create an HttpSession that
>>         is shared by
>>              >> everybody and store this SSO id/username -> to ->
>>         HttpSession id map
>>              >> there.
>>              > That's good, we can avoid dependency on infinispan.
>>
>>              Ugh, unfortunately, you can't provide our own session id
>>         with Undertow's
>>              or Jetty's sessionmanager interface. :(  So no way to hack
>>         this except
>>              for Tomcat and JbossWeb.
>>
>>              > But still, we will
>>              > need the stuff like periodic cleaner thread, which will
>>         remove expired
>>              > items from this HttpSession map. And this solution
>>         requires HttpSession
>>              > replication if I understand correctly?
>>              >
>>
>>              Replication would be required, but all these servlet
>>         containers contain
>>              session lifecycle listener SPIs, so there is no need for
>>         reaper threads.
>>                 But, can't do it anyways...
>>
>>              > As of now, we don't require HttpSession replication for
>>         OIDC. Qe support
>>              > the deployments when the application is deployed on more
>>         "cluster" nodes
>>              > behind loadbalancer, but application cluster nodes don't
>>         communicate
>>              > with each other. In other words, there is no
>>         "distributable" in web.xml
>>              > . For this case, we have CLIENT_SESSION_HOST note, so the
>>         OIDC
>>              > backchannel request is sent to same cluster node from
>>         which was
>>              > code-to-token request sent earlier.
>>              >
>>
>>              Again, not something we can implement in a
>>         standard/portable way.
>>
>>              --
>>              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>
>>         <mailto: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/20150915/bd60c77c/attachment.html 

From bburke at redhat.com  Tue Sep 15 09:39:15 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Sep 2015 09:39:15 -0400
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <CAJgngAcNJSj44U_k=hALZ3xPmCicSXat6pfoZuYkwuD1JEftJw@mail.gmail.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
	<55F8160A.5020200@redhat.com>
	<CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>
	<55F819AD.2010005@redhat.com>
	<CAJgngAcNJSj44U_k=hALZ3xPmCicSXat6pfoZuYkwuD1JEftJw@mail.gmail.com>
Message-ID: <55F81F83.2000708@redhat.com>

Yeah, of course it would be pluggable.  I don't want to force people to 
use a distributed cache. :)

Another idea, if we don't want to ship infinispan with our SAML/OIDC SP 
is to provide a list of nodes in the adapter config.  When a SSO session 
is started, store the information in memory.  When logout, query other 
machines until you find who stores the SSO sesion->local sessionid mapping.

On 9/15/2015 9:23 AM, Stian Thorgersen wrote:
> Oh, I turned things around - I thought it was the SSO session id that
> was missing, not the http session id. Ignore everything I've said up
> until now ;)
>
> Maybe we could make the SSO Session ID --> HTTP Session ID map pluggable
> then? By default it would use the mechanism Marek implemented, but then
> we can support other means as well?
>
> On 15 September 2015 at 15:14, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     no.  The session id sent with the logout request is the SSO session
>     id.  The client does not transmit its session id to the IdP.
>
>     On 9/15/2015 9:04 AM, Stian Thorgersen wrote:
>
>         Isn't the http session id part of the standard backchannel log out?
>
>         On 15 September 2015 at 14:58, Bill Burke <bburke at redhat.com
>         <mailto:bburke at redhat.com>
>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>
>              We can do anything we want on the server side, the problem
>         is that
>              our client adapters, SAML and OIDC, should be able to work with
>              non-Keycloak IdPs.
>
>              On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
>
>                  Could we store the mapping on the Keycloak side?
>         client-id + http
>                  session id --> KC session id?
>
>                  On 14 September 2015 at 22:41, Bill Burke
>         <bburke at redhat.com <mailto:bburke at redhat.com>
>                  <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>
>                  <mailto:bburke at redhat.com <mailto:bburke at redhat.com>
>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>> wrote:
>
>
>
>                       On 9/14/2015 4:20 PM, Marek Posolda wrote:
>                       > On 14/09/15 21:46, Bill Burke wrote:
>                       >> The SAML IdP is not required to send back that
>         id.  That
>                  ID is just
>                       >> the ID of the request.
>                       > The SAML IdP doesn't need to send anything back.
>         I meant that
>                       > HttpSessionID will be send in the ID of
>         SAMLRequest from
>                  SAML SP to
>                       > auth-server . I don't know if there is any better
>                  attribute/element of
>                       > AuthnRequest, which can be used to transmit such
>         "custom"
>                  data.
>                       >
>
>                       SAML logout requests to the SP client contain the
>         principal
>                  name and/or
>                       possibly one *or more* SSO IDs (session indexes).
>         New OIDC
>                  spec will
>                       work similarly.
>
>                       >>
>                       >> A hack I'm thinking of is to create an
>         HttpSession that
>                  is shared by
>                       >> everybody and store this SSO id/username -> to ->
>                  HttpSession id map
>                       >> there.
>                       > That's good, we can avoid dependency on infinispan.
>
>                       Ugh, unfortunately, you can't provide our own
>         session id
>                  with Undertow's
>                       or Jetty's sessionmanager interface. :(  So no way
>         to hack
>                  this except
>                       for Tomcat and JbossWeb.
>
>                       > But still, we will
>                       > need the stuff like periodic cleaner thread,
>         which will
>                  remove expired
>                       > items from this HttpSession map. And this solution
>                  requires HttpSession
>                       > replication if I understand correctly?
>                       >
>
>                       Replication would be required, but all these servlet
>                  containers contain
>                       session lifecycle listener SPIs, so there is no
>         need for
>                  reaper threads.
>                          But, can't do it anyways...
>
>                       > As of now, we don't require HttpSession
>         replication for
>                  OIDC. Qe support
>                       > the deployments when the application is deployed
>         on more
>                  "cluster" nodes
>                       > behind loadbalancer, but application cluster
>         nodes don't
>                  communicate
>                       > with each other. In other words, there is no
>                  "distributable" in web.xml
>                       > . For this case, we have CLIENT_SESSION_HOST
>         note, so the
>                  OIDC
>                       > backchannel request is sent to same cluster node
>         from
>                  which was
>                       > code-to-token request sent earlier.
>                       >
>
>                       Again, not something we can implement in a
>                  standard/portable way.
>
>                       --
>                       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>
>                  <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>>
>                  <mailto:keycloak-dev at lists.jboss.org
>         <mailto:keycloak-dev at lists.jboss.org>
>                  <mailto: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
>
>

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

From sthorger at redhat.com  Tue Sep 15 09:51:25 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 15 Sep 2015 15:51:25 +0200
Subject: [keycloak-dev] backchannel logout for SAML SP
In-Reply-To: <55F81F83.2000708@redhat.com>
References: <55F6ED40.2010609@redhat.com> <55F71CFF.4070507@redhat.com>
	<55F71FC6.6080909@redhat.com> <55F7233F.3030706@redhat.com>
	<55F72423.9000706@redhat.com> <55F72C2A.8060108@redhat.com>
	<55F730DD.2040200@redhat.com>
	<CAJgngAf6YeqJ_Ab_uSm_afOZbqJ5kf_j428H-2tz0yuwRjFTRQ@mail.gmail.com>
	<55F8160A.5020200@redhat.com>
	<CAJgngAd3vDtZiwN511YyR37G4TZC+zFYqYAbgJt1A-Y3V=Zi_g@mail.gmail.com>
	<55F819AD.2010005@redhat.com>
	<CAJgngAcNJSj44U_k=hALZ3xPmCicSXat6pfoZuYkwuD1JEftJw@mail.gmail.com>
	<55F81F83.2000708@redhat.com>
Message-ID: <CAJgngAcGfTDvwFB6+obWV-NesAqNZq5cF7pwEErh3BBGpzruCQ@mail.gmail.com>

If we make it pluggable do we even need to support non-KC IDPs? End of the
day we're focusing on KC right and users can implement their own for other
IDPs.

On 15 September 2015 at 15:39, Bill Burke <bburke at redhat.com> wrote:

> Yeah, of course it would be pluggable.  I don't want to force people to
> use a distributed cache. :)
>
> Another idea, if we don't want to ship infinispan with our SAML/OIDC SP is
> to provide a list of nodes in the adapter config.  When a SSO session is
> started, store the information in memory.  When logout, query other
> machines until you find who stores the SSO sesion->local sessionid mapping.
>
> On 9/15/2015 9:23 AM, Stian Thorgersen wrote:
>
>> Oh, I turned things around - I thought it was the SSO session id that
>> was missing, not the http session id. Ignore everything I've said up
>> until now ;)
>>
>> Maybe we could make the SSO Session ID --> HTTP Session ID map pluggable
>> then? By default it would use the mechanism Marek implemented, but then
>> we can support other means as well?
>>
>> On 15 September 2015 at 15:14, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>     no.  The session id sent with the logout request is the SSO session
>>     id.  The client does not transmit its session id to the IdP.
>>
>>     On 9/15/2015 9:04 AM, Stian Thorgersen wrote:
>>
>>         Isn't the http session id part of the standard backchannel log
>> out?
>>
>>         On 15 September 2015 at 14:58, Bill Burke <bburke at redhat.com
>>         <mailto:bburke at redhat.com>
>>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>>
>>              We can do anything we want on the server side, the problem
>>         is that
>>              our client adapters, SAML and OIDC, should be able to work
>> with
>>              non-Keycloak IdPs.
>>
>>              On 9/15/2015 7:25 AM, Stian Thorgersen wrote:
>>
>>                  Could we store the mapping on the Keycloak side?
>>         client-id + http
>>                  session id --> KC session id?
>>
>>                  On 14 September 2015 at 22:41, Bill Burke
>>         <bburke at redhat.com <mailto:bburke at redhat.com>
>>                  <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>
>>                  <mailto:bburke at redhat.com <mailto:bburke at redhat.com>
>>         <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>>> wrote:
>>
>>
>>
>>                       On 9/14/2015 4:20 PM, Marek Posolda wrote:
>>                       > On 14/09/15 21:46, Bill Burke wrote:
>>                       >> The SAML IdP is not required to send back that
>>         id.  That
>>                  ID is just
>>                       >> the ID of the request.
>>                       > The SAML IdP doesn't need to send anything back.
>>         I meant that
>>                       > HttpSessionID will be send in the ID of
>>         SAMLRequest from
>>                  SAML SP to
>>                       > auth-server . I don't know if there is any better
>>                  attribute/element of
>>                       > AuthnRequest, which can be used to transmit such
>>         "custom"
>>                  data.
>>                       >
>>
>>                       SAML logout requests to the SP client contain the
>>         principal
>>                  name and/or
>>                       possibly one *or more* SSO IDs (session indexes).
>>         New OIDC
>>                  spec will
>>                       work similarly.
>>
>>                       >>
>>                       >> A hack I'm thinking of is to create an
>>         HttpSession that
>>                  is shared by
>>                       >> everybody and store this SSO id/username -> to ->
>>                  HttpSession id map
>>                       >> there.
>>                       > That's good, we can avoid dependency on
>> infinispan.
>>
>>                       Ugh, unfortunately, you can't provide our own
>>         session id
>>                  with Undertow's
>>                       or Jetty's sessionmanager interface. :(  So no way
>>         to hack
>>                  this except
>>                       for Tomcat and JbossWeb.
>>
>>                       > But still, we will
>>                       > need the stuff like periodic cleaner thread,
>>         which will
>>                  remove expired
>>                       > items from this HttpSession map. And this solution
>>                  requires HttpSession
>>                       > replication if I understand correctly?
>>                       >
>>
>>                       Replication would be required, but all these servlet
>>                  containers contain
>>                       session lifecycle listener SPIs, so there is no
>>         need for
>>                  reaper threads.
>>                          But, can't do it anyways...
>>
>>                       > As of now, we don't require HttpSession
>>         replication for
>>                  OIDC. Qe support
>>                       > the deployments when the application is deployed
>>         on more
>>                  "cluster" nodes
>>                       > behind loadbalancer, but application cluster
>>         nodes don't
>>                  communicate
>>                       > with each other. In other words, there is no
>>                  "distributable" in web.xml
>>                       > . For this case, we have CLIENT_SESSION_HOST
>>         note, so the
>>                  OIDC
>>                       > backchannel request is sent to same cluster node
>>         from
>>                  which was
>>                       > code-to-token request sent earlier.
>>                       >
>>
>>                       Again, not something we can implement in a
>>                  standard/portable way.
>>
>>                       --
>>                       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
>> >
>>                  <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>>
>>                  <mailto:keycloak-dev at lists.jboss.org
>>         <mailto:keycloak-dev at lists.jboss.org>
>>                  <mailto: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
>>
>>
>>
> --
> 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/20150915/d15287c5/attachment-0001.html 

From psilva at redhat.com  Wed Sep 16 07:36:04 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 16 Sep 2015 07:36:04 -0400 (EDT)
Subject: [keycloak-dev] OpenID Connect HybridIDToken
In-Reply-To: <24467500.29152482.1442403040891.JavaMail.zimbra@redhat.com>
Message-ID: <651456370.29153932.1442403364846.JavaMail.zimbra@redhat.com>

Hi,

   Is Keycloak IDToken considering the "at_hash" claim ?

Regards.
Pedro Igor

From sthorger at redhat.com  Wed Sep 16 08:23:04 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 16 Sep 2015 14:23:04 +0200
Subject: [keycloak-dev] Keycloak OpenShift Cartridge updated to 1.5.0.Final
Message-ID: <CAJgngAeES_Oi5G4cfxGzpMicG5iaBo_6KKkdYPQO9ZDs9OyWqQ@mail.gmail.com>

Keycloak OpenShift Cartridge updated to 1.5.0.Final
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150916/83f7b9cf/attachment.html 

From sthorger at redhat.com  Wed Sep 16 09:39:13 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 16 Sep 2015 15:39:13 +0200
Subject: [keycloak-dev] Keycloak Docker images updated to 1.5.0.Final
Message-ID: <CAJgngAdG53kE2-DxKe3xPL47J4W1AFV+Lorptm3mZFpoAuqR2g@mail.gmail.com>

Keycloak Docker images updated to 1.5.0.Final
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150916/b75cf639/attachment.html 

From sthorger at redhat.com  Thu Sep 17 10:16:20 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 17 Sep 2015 16:16:20 +0200
Subject: [keycloak-dev] [keycloak-user] Keycloak OpenShift Cartridge
	updated to 1.5.0.Final
In-Reply-To: <CAMOUzMC=4-r99HcmonKfJqF9kpH_6sKqpG1df=Hcb6P_0CAw2A@mail.gmail.com>
References: <CAJgngAeES_Oi5G4cfxGzpMicG5iaBo_6KKkdYPQO9ZDs9OyWqQ@mail.gmail.com>
	<CAMOUzMC=4-r99HcmonKfJqF9kpH_6sKqpG1df=Hcb6P_0CAw2A@mail.gmail.com>
Message-ID: <CAJgngAfdJ+tmMMKrSf=_epKV4VMnRuTxQq0=zKkKSwWSVJtFzg@mail.gmail.com>

http://keycloak.github.io/docs/userguide/html/openshift.html

On 17 September 2015 at 16:13, Anton Hughes <ah at tradeworks.io> wrote:

> Thanks. Is it possible to get some documentation for this - such as how to
> login to the keycloak web console?
>
> On 16 September 2015 at 14:23, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Keycloak OpenShift Cartridge updated to 1.5.0.Final
>>
>> _______________________________________________
>> 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/20150917/5fac3297/attachment.html 

From parul.com at gmail.com  Fri Sep 18 00:30:54 2015
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 18 Sep 2015 10:00:54 +0530
Subject: [keycloak-dev] Picketlink Service provider
Message-ID: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>

Hi all,
Currently we are using picketlink service provider for SAML authentication.
After keycloak merge, can we still use the picketlink lib for SP or we have
to consume the keycloak. our current use case is make our application as
SAML service provider which interact with external IDP for authentication.

Thanks,
Arulkumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150918/cf7f6f92/attachment.html 

From sthorger at redhat.com  Fri Sep 18 02:21:40 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Sep 2015 08:21:40 +0200
Subject: [keycloak-dev] Picketlink Service provider
In-Reply-To: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>
References: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>
Message-ID: <CAJgngAcXvpwPQKgcHjv7ko4r=Hrf7QaXOhc0iX6_MTU6gk320w@mail.gmail.com>

You can continue using PicketLink SAML SP libs, but bear in mind that there
will be no active development on them. We are planning to introduce
Keycloak SAML SP libraries in the near future.

On 18 September 2015 at 06:30, Arulkumar Ponnusamy <parul.com at gmail.com>
wrote:

> Hi all,
> Currently we are using picketlink service provider for SAML
> authentication. After keycloak merge, can we still use the picketlink lib
> for SP or we have to consume the keycloak. our current use case is make our
> application as SAML service provider which interact with external IDP for
> authentication.
>
> Thanks,
> Arulkumar
>
> _______________________________________________
> 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/20150918/fed3c5ae/attachment.html 

From parul.com at gmail.com  Fri Sep 18 02:56:13 2015
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 18 Sep 2015 12:26:13 +0530
Subject: [keycloak-dev] Picketlink Service provider
In-Reply-To: <CAJgngAcXvpwPQKgcHjv7ko4r=Hrf7QaXOhc0iX6_MTU6gk320w@mail.gmail.com>
References: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>
	<CAJgngAcXvpwPQKgcHjv7ko4r=Hrf7QaXOhc0iX6_MTU6gk320w@mail.gmail.com>
Message-ID: <CAFj68vWn4unyXj5Ai9x3oc7NCpPvHKTWGox4k2S1OJ5iu8OGzw@mail.gmail.com>

Thanks... Do we have roadmap/plan on when will we have keycloak SAML sp
libs.. ?
You can continue using PicketLink SAML SP libs, but bear in mind that there
will be no active development on them. We are planning to introduce
Keycloak SAML SP libraries in the near future.

On 18 September 2015 at 06:30, Arulkumar Ponnusamy <parul.com at gmail.com>
wrote:

> Hi all,
> Currently we are using picketlink service provider for SAML
> authentication. After keycloak merge, can we still use the picketlink lib
> for SP or we have to consume the keycloak. our current use case is make our
> application as SAML service provider which interact with external IDP for
> authentication.
>
> Thanks,
> Arulkumar
>
> _______________________________________________
> 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/20150918/f7a8d50c/attachment.html 

From sthorger at redhat.com  Fri Sep 18 02:58:47 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 18 Sep 2015 08:58:47 +0200
Subject: [keycloak-dev] Picketlink Service provider
In-Reply-To: <CAFj68vWn4unyXj5Ai9x3oc7NCpPvHKTWGox4k2S1OJ5iu8OGzw@mail.gmail.com>
References: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>
	<CAJgngAcXvpwPQKgcHjv7ko4r=Hrf7QaXOhc0iX6_MTU6gk320w@mail.gmail.com>
	<CAFj68vWn4unyXj5Ai9x3oc7NCpPvHKTWGox4k2S1OJ5iu8OGzw@mail.gmail.com>
Message-ID: <CAJgngAeQBhjP7iBGWCVyjm8A9zf=D_zCcVyvh9Yy=hZYt-4SUw@mail.gmail.com>

It's a work in progress and should be included in 1.6 (October) or 1.7
(November)

On 18 September 2015 at 08:56, Arulkumar Ponnusamy <parul.com at gmail.com>
wrote:

> Thanks... Do we have roadmap/plan on when will we have keycloak SAML sp
> libs.. ?
> You can continue using PicketLink SAML SP libs, but bear in mind that
> there will be no active development on them. We are planning to introduce
> Keycloak SAML SP libraries in the near future.
>
> On 18 September 2015 at 06:30, Arulkumar Ponnusamy <parul.com at gmail.com>
> wrote:
>
>> Hi all,
>> Currently we are using picketlink service provider for SAML
>> authentication. After keycloak merge, can we still use the picketlink lib
>> for SP or we have to consume the keycloak. our current use case is make our
>> application as SAML service provider which interact with external IDP for
>> authentication.
>>
>> Thanks,
>> Arulkumar
>>
>> _______________________________________________
>> 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/20150918/6f8a177b/attachment-0001.html 

From parul.com at gmail.com  Fri Sep 18 03:02:33 2015
From: parul.com at gmail.com (Arulkumar Ponnusamy)
Date: Fri, 18 Sep 2015 12:32:33 +0530
Subject: [keycloak-dev] Picketlink Service provider
In-Reply-To: <CAJgngAeQBhjP7iBGWCVyjm8A9zf=D_zCcVyvh9Yy=hZYt-4SUw@mail.gmail.com>
References: <CAFj68vUgjPnzPoAqiZ2V_hmiv0uD_8uWYGaX2Q_uHkbX+jZ6kg@mail.gmail.com>
	<CAJgngAcXvpwPQKgcHjv7ko4r=Hrf7QaXOhc0iX6_MTU6gk320w@mail.gmail.com>
	<CAFj68vWn4unyXj5Ai9x3oc7NCpPvHKTWGox4k2S1OJ5iu8OGzw@mail.gmail.com>
	<CAJgngAeQBhjP7iBGWCVyjm8A9zf=D_zCcVyvh9Yy=hZYt-4SUw@mail.gmail.com>
Message-ID: <CAFj68vXQ6iEsPkoH42yAyPWwjhhi6PhED3_9cUyNESeDk8sOdw@mail.gmail.com>

Thanks.

On Fri, Sep 18, 2015 at 12:28 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> It's a work in progress and should be included in 1.6 (October) or 1.7
> (November)
>
> On 18 September 2015 at 08:56, Arulkumar Ponnusamy <parul.com at gmail.com>
> wrote:
>
>> Thanks... Do we have roadmap/plan on when will we have keycloak SAML sp
>> libs.. ?
>> You can continue using PicketLink SAML SP libs, but bear in mind that
>> there will be no active development on them. We are planning to introduce
>> Keycloak SAML SP libraries in the near future.
>>
>> On 18 September 2015 at 06:30, Arulkumar Ponnusamy <parul.com at gmail.com>
>> wrote:
>>
>>> Hi all,
>>> Currently we are using picketlink service provider for SAML
>>> authentication. After keycloak merge, can we still use the picketlink lib
>>> for SP or we have to consume the keycloak. our current use case is make our
>>> application as SAML service provider which interact with external IDP for
>>> authentication.
>>>
>>> Thanks,
>>> Arulkumar
>>>
>>> _______________________________________________
>>> 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/20150918/0d0ce54e/attachment.html 

From alex_orl1079 at yahoo.it  Fri Sep 18 18:54:05 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Fri, 18 Sep 2015 23:54:05 +0100
Subject: [keycloak-dev] extend keycloak principal
Message-ID: <1442616845.9054.YahooMailAndroidMobile@web172304.mail.ir2.yahoo.com>

I'm working on SSO using jboss keycloak.

I m developing a user federation provider working with my custom user database and ldap authentication.

i m able to do the authentication process but now i need to retrieve to my webapplications a Principal extending the keycloak one.

I mean that my rest service could have to access a principal object holding other information besides those covered by keycloakPrincipal (i.e. company group, company and others).

i was planning to write my own MyProjectPrincipal extending keycloakPrincipal but then...?

is it the right way?

how can i retrieve this principal to my custom webapplication? (i.e. REST service)?


Best regards and thanks a lot for your attention.

AlessioInviato da Yahoo Mail su Android

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

From alex_orl1079 at yahoo.it  Sat Sep 19 20:31:57 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Sun, 20 Sep 2015 00:31:57 +0000 (UTC)
Subject: [keycloak-dev] Customize KeycloakPrincipal
Message-ID: <1139402781.390448.1442709117937.JavaMail.yahoo@mail.yahoo.com>

In my rest service i can obtain the principal information after authentication using?KeycloakPrincipal kcPrincipal = (KeycloakPrincipal) servletRequest.getUserPrincipal() statement.Keycloak principal does'nt cotain all the information i need about the authenticated user.Is it possibile to customize my own principal type?On the keycloak end i ve developed a user federation provider. Is it possibile to insert my custom principal in that code? What is the way?Thanks to all and regards.Alessio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150920/82eda8ba/attachment.html 

From sthorger at redhat.com  Mon Sep 21 02:26:21 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Sep 2015 08:26:21 +0200
Subject: [keycloak-dev] extend keycloak principal
In-Reply-To: <1442616845.9054.YahooMailAndroidMobile@web172304.mail.ir2.yahoo.com>
References: <1442616845.9054.YahooMailAndroidMobile@web172304.mail.ir2.yahoo.com>
Message-ID: <CAJgngAfRc_zzVFcDOnMxh2-FGbGYh95AdcSmf=TsQZT7z8GAcQ@mail.gmail.com>

Please use user mailing list - this list is to discuss development of
Keycloak itself

On 19 September 2015 at 00:54, alex orl <alex_orl1079 at yahoo.it> wrote:

> I'm working on SSO using jboss keycloak.
> I m developing a user federation provider working with my custom user
> database and ldap authentication.
> i m able to do the authentication process but now i need to retrieve to my
> webapplications a Principal extending the keycloak one.
> I mean that my rest service could have to access a principal object
> holding other information besides those covered by keycloakPrincipal (i.e.
> company group, company and others).
> i was planning to write my own MyProjectPrincipal extending
> keycloakPrincipal but then...
> is it the right way?
> how can i retrieve this principal to my custom webapplication? (i.e. REST
> service)?
>
> Best regards and thanks a lot for your attention.
>
> AlessioInviato da Yahoo Mail su Android
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> _______________________________________________
> 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/20150921/5e3cd921/attachment.html 

From sthorger at redhat.com  Mon Sep 21 02:26:29 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Sep 2015 08:26:29 +0200
Subject: [keycloak-dev] Customize KeycloakPrincipal
In-Reply-To: <1139402781.390448.1442709117937.JavaMail.yahoo@mail.yahoo.com>
References: <1139402781.390448.1442709117937.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAJgngAeVEQNUmczAgKBm9xaWEYBkeTVSqPV7Fjs_N4qpbn9tGA@mail.gmail.com>

Please use user mailing list - this list is to discuss development of
Keycloak itself

On 20 September 2015 at 02:31, alex orl <alex_orl1079 at yahoo.it> wrote:

> In my rest service i can obtain the principal information after
> authentication using KeycloakPrincipal kcPrincipal = (KeycloakPrincipal)
> servletRequest.getUserPrincipal() statement.
> Keycloak principal does'nt cotain all the information i need about the
> authenticated user.
> Is it possibile to customize my own principal type?
> On the keycloak end i ve developed a user federation provider. Is it
> possibile to insert my custom principal in that code? What is the way?
> Thanks to all and regards.
> Alessio
>
> _______________________________________________
> 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/20150921/6c7be4aa/attachment-0001.html 

From mposolda at redhat.com  Mon Sep 21 06:06:16 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 12:06:16 +0200
Subject: [keycloak-dev] Offline tokens - step 1
Message-ID: <55FFD698.7040100@redhat.com>

I've sent the PR . Right now it works like this:

- ClientModel has flag "offlineTokensEnabled" . It's possible to 
retrieve offline tokens just if flag is enabled

- Offline token is classic refresh token with 2 differences. It has type 
"OFFLINE" when normal refresh token has type "REFRESH" . And for offline 
token, the expiration value is 0, so it never expires.

- Offline token is generated by auth-server when client sends 
"scope=offline_access" . It's supported for classic browser flow, but 
also for Direct Grant flow or Service account flow.

- I've added OfflineClientSessionModel and OfflineUserSessionModel with 
CRUD methods on UserModel. So when new offline token is generated by 
Keycloak, some info about current UserSession and ClientSession is 
persisted on UserModel. This means that offline token can be used to 
create new access token even if "normal" UserSession and ClientSession 
are already invalid or logged out.

- When refreshing access token with offline token, the auth-server won't 
send back another refresh token. It will send just accessToken + 
IDToken. This is to avoid writes to user database for each token refresh.

- In account management applications tab, there is new table column 
"Additional grants" where is shown if client has offline token for user. 
The click on "Revoke" button will remove offline tokens and granted 
consents as well - no separate actions for revoke consents and offline 
tokens.


Still TODO:
- Properly handle consents (see "Questions" below)

- More tests, example, export/import , docs

- More things/refactoring based on your feedback


Questions:
- The specs mentions that consent should be displayed when offline token 
is requested. See 
http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess . 
Right now, I am not doing that. So when Client has "isConsentRequired" 
as false, the consent screen is not displayed. Now we also don't have 
support for "prompt=consent" (not sure if we need this) . Is it ok to 
keep it like this?

- I am thinking about adding new builtin client role "offline_access", 
which will be created for client when admin enables "offline tokens" 
switch. It will be used also as default role. This will allow that just 
some users are allowed to obtain offline-token (those which have this 
role). The role will be also displayed on consent screen for the 
clients, which needs consent.
But that raises another question. IMO it will be good if role is 
requested and displayed on consent screen just if offline token is 
requested, but not when classic refresh token is requested.

Hence I was thinking about adding the flag "scopeParamMode" to 
RoleModel. The value true means that role will be requested and used in 
accessToken/refreshToken just if scope parameter contains it's value. 
This will be the setup for "offline_access" role, so it's used just for 
the offline token requests. Another thing is format of scope parameter 
with respect to realm roles and application roles. We can use "//" as 
delimiter, so realm role will have just "my-role" but client role will 
have "my-client//my-role" . The disadvantage is that for requesting 
offline_access you will then need to use scope like: 
"scope=customer-portal//offline_access" as it's client role.

WDYT? Any better idea?

Marek

From juraci at kroehling.de  Mon Sep 21 06:27:15 2015
From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=)
Date: Mon, 21 Sep 2015 12:27:15 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFD698.7040100@redhat.com>
References: <55FFD698.7040100@redhat.com>
Message-ID: <55FFDB83.1050202@kroehling.de>

Thanks Marek! I'll resume my work on a feature that depends on Offline 
Tokens and will let you know. Based on your description, though, it 
looks very good.

- Juca.

On 09/21/2015 12:06 PM, Marek Posolda wrote:
> I've sent the PR . Right now it works like this:
>
> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> retrieve offline tokens just if flag is enabled
>
> - Offline token is classic refresh token with 2 differences. It has type
> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
> token, the expiration value is 0, so it never expires.
>
> - Offline token is generated by auth-server when client sends
> "scope=offline_access" . It's supported for classic browser flow, but
> also for Direct Grant flow or Service account flow.
>
> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
> CRUD methods on UserModel. So when new offline token is generated by
> Keycloak, some info about current UserSession and ClientSession is
> persisted on UserModel. This means that offline token can be used to
> create new access token even if "normal" UserSession and ClientSession
> are already invalid or logged out.
>
> - When refreshing access token with offline token, the auth-server won't
> send back another refresh token. It will send just accessToken +
> IDToken. This is to avoid writes to user database for each token refresh.
>
> - In account management applications tab, there is new table column
> "Additional grants" where is shown if client has offline token for user.
> The click on "Revoke" button will remove offline tokens and granted
> consents as well - no separate actions for revoke consents and offline
> tokens.
>
>
> Still TODO:
> - Properly handle consents (see "Questions" below)
>
> - More tests, example, export/import , docs
>
> - More things/refactoring based on your feedback
>
>
> Questions:
> - The specs mentions that consent should be displayed when offline token
> is requested. See
> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
> Right now, I am not doing that. So when Client has "isConsentRequired"
> as false, the consent screen is not displayed. Now we also don't have
> support for "prompt=consent" (not sure if we need this) . Is it ok to
> keep it like this?
>
> - I am thinking about adding new builtin client role "offline_access",
> which will be created for client when admin enables "offline tokens"
> switch. It will be used also as default role. This will allow that just
> some users are allowed to obtain offline-token (those which have this
> role). The role will be also displayed on consent screen for the
> clients, which needs consent.
> But that raises another question. IMO it will be good if role is
> requested and displayed on consent screen just if offline token is
> requested, but not when classic refresh token is requested.
>
> Hence I was thinking about adding the flag "scopeParamMode" to
> RoleModel. The value true means that role will be requested and used in
> accessToken/refreshToken just if scope parameter contains it's value.
> This will be the setup for "offline_access" role, so it's used just for
> the offline token requests. Another thing is format of scope parameter
> with respect to realm roles and application roles. We can use "//" as
> delimiter, so realm role will have just "my-role" but client role will
> have "my-client//my-role" . The disadvantage is that for requesting
> offline_access you will then need to use scope like:
> "scope=customer-portal//offline_access" as it's client role.
>
> WDYT? Any better idea?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

From pslegr at redhat.com  Mon Sep 21 06:28:30 2015
From: pslegr at redhat.com (pslegr)
Date: Mon, 21 Sep 2015 12:28:30 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFD698.7040100@redhat.com>
References: <55FFD698.7040100@redhat.com>
Message-ID: <55FFDBCE.4070201@redhat.com>



On 21.9.2015 12:06, Marek Posolda wrote:
> I've sent the PR . Right now it works like this:
>
> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> retrieve offline tokens just if flag is enabled
>
> - Offline token is classic refresh token with 2 differences. It has type
> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
> token, the expiration value is 0, so it never expires.
Just an idea.
Have you ever thought, in terms of expiration, not only
about refresh vs. never expires
BUT also about defining the exact time of expiration ?
for example validity for 1 Month, 1 year, 3 years ... etc.
This would offer the possibility on the fly generate the so called; 
"offline license tokens", which are
then used for different lifetime periods.
IMHO this might extend the usage for Keycloak into the license providers 
field ;)
>
> - Offline token is generated by auth-server when client sends
> "scope=offline_access" . It's supported for classic browser flow, but
> also for Direct Grant flow or Service account flow.
>
> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
> CRUD methods on UserModel. So when new offline token is generated by
> Keycloak, some info about current UserSession and ClientSession is
> persisted on UserModel. This means that offline token can be used to
> create new access token even if "normal" UserSession and ClientSession
> are already invalid or logged out.
>
> - When refreshing access token with offline token, the auth-server won't
> send back another refresh token. It will send just accessToken +
> IDToken. This is to avoid writes to user database for each token refresh.
>
> - In account management applications tab, there is new table column
> "Additional grants" where is shown if client has offline token for user.
> The click on "Revoke" button will remove offline tokens and granted
> consents as well - no separate actions for revoke consents and offline
> tokens.
>
>
> Still TODO:
> - Properly handle consents (see "Questions" below)
>
> - More tests, example, export/import , docs
>
> - More things/refactoring based on your feedback
>
>
> Questions:
> - The specs mentions that consent should be displayed when offline token
> is requested. See
> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
> Right now, I am not doing that. So when Client has "isConsentRequired"
> as false, the consent screen is not displayed. Now we also don't have
> support for "prompt=consent" (not sure if we need this) . Is it ok to
> keep it like this?
>
> - I am thinking about adding new builtin client role "offline_access",
> which will be created for client when admin enables "offline tokens"
> switch. It will be used also as default role. This will allow that just
> some users are allowed to obtain offline-token (those which have this
> role). The role will be also displayed on consent screen for the
> clients, which needs consent.
> But that raises another question. IMO it will be good if role is
> requested and displayed on consent screen just if offline token is
> requested, but not when classic refresh token is requested.
>
> Hence I was thinking about adding the flag "scopeParamMode" to
> RoleModel. The value true means that role will be requested and used in
> accessToken/refreshToken just if scope parameter contains it's value.
> This will be the setup for "offline_access" role, so it's used just for
> the offline token requests. Another thing is format of scope parameter
> with respect to realm roles and application roles. We can use "//" as
> delimiter, so realm role will have just "my-role" but client role will
> have "my-client//my-role" . The disadvantage is that for requesting
> offline_access you will then need to use scope like:
> "scope=customer-portal//offline_access" as it's client role.
>
> WDYT? Any better idea?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From sthorger at redhat.com  Mon Sep 21 06:33:21 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Sep 2015 12:33:21 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFD698.7040100@redhat.com>
References: <55FFD698.7040100@redhat.com>
Message-ID: <CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>

On 21 September 2015 at 12:06, Marek Posolda <mposolda at redhat.com> wrote:

> I've sent the PR . Right now it works like this:
>
> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> retrieve offline tokens just if flag is enabled
>
> - Offline token is classic refresh token with 2 differences. It has type
> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
> token, the expiration value is 0, so it never expires.
>
> - Offline token is generated by auth-server when client sends
> "scope=offline_access" . It's supported for classic browser flow, but
> also for Direct Grant flow or Service account flow.
>
> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
> CRUD methods on UserModel. So when new offline token is generated by
> Keycloak, some info about current UserSession and ClientSession is
> persisted on UserModel. This means that offline token can be used to
> create new access token even if "normal" UserSession and ClientSession
> are already invalid or logged out.
>
> - When refreshing access token with offline token, the auth-server won't
> send back another refresh token. It will send just accessToken +
> IDToken. This is to avoid writes to user database for each token refresh.
>
> - In account management applications tab, there is new table column
> "Additional grants" where is shown if client has offline token for user.
> The click on "Revoke" button will remove offline tokens and granted
> consents as well - no separate actions for revoke consents and offline
> tokens.
>
>
> Still TODO:
> - Properly handle consents (see "Questions" below)
>
> - More tests, example, export/import , docs
>
> - More things/refactoring based on your feedback
>
>
> Questions:
> - The specs mentions that consent should be displayed when offline token
> is requested. See
> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
> Right now, I am not doing that. So when Client has "isConsentRequired"
> as false, the consent screen is not displayed. Now we also don't have
> support for "prompt=consent" (not sure if we need this) . Is it ok to
> keep it like this?
>

Wording is "MUST explicitly receive or have consent" - as the client does
not require consent (isConsentRequired=false) that implies the client
already has been given consent by the admin.


>
> - I am thinking about adding new builtin client role "offline_access",
> which will be created for client when admin enables "offline tokens"
> switch. It will be used also as default role. This will allow that just
> some users are allowed to obtain offline-token (those which have this
> role). The role will be also displayed on consent screen for the
> clients, which needs consent.
> But that raises another question. IMO it will be good if role is
> requested and displayed on consent screen just if offline token is
> requested, but not when classic refresh token is requested.


> Hence I was thinking about adding the flag "scopeParamMode" to
> RoleModel. The value true means that role will be requested and used in
> accessToken/refreshToken just if scope parameter contains it's value.
> This will be the setup for "offline_access" role, so it's used just for
> the offline token requests. Another thing is format of scope parameter
> with respect to realm roles and application roles. We can use "//" as
> delimiter, so realm role will have just "my-role" but client role will
> have "my-client//my-role" . The disadvantage is that for requesting
> offline_access you will then need to use scope like:
> "scope=customer-portal//offline_access" as it's client role.
>

Spec says scope should be "offline_access", so if we use a different name
for it won't comply with the spec.

Shouldn't the offline_access role be a realm role rather than a role
per-client?

Another thing to consider is that we'll be moving to role namespaces
instead of realm/client roles soon. In that case we might want a OpenID
Connect namespace that can hold these scopes. So role could be
"openid/offline_access".


>
> WDYT? Any better idea?
>
> 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/20150921/af62f48d/attachment.html 

From mposolda at redhat.com  Mon Sep 21 08:06:34 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 14:06:34 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
References: <55FFD698.7040100@redhat.com>
	<CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
Message-ID: <55FFF2CA.8000204@redhat.com>

On 21/09/15 12:33, Stian Thorgersen wrote:
>
>
> On 21 September 2015 at 12:06, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     I've sent the PR . Right now it works like this:
>
>     - ClientModel has flag "offlineTokensEnabled" . It's possible to
>     retrieve offline tokens just if flag is enabled
>
>     - Offline token is classic refresh token with 2 differences. It
>     has type
>     "OFFLINE" when normal refresh token has type "REFRESH" . And for
>     offline
>     token, the expiration value is 0, so it never expires.
>
>     - Offline token is generated by auth-server when client sends
>     "scope=offline_access" . It's supported for classic browser flow, but
>     also for Direct Grant flow or Service account flow.
>
>     - I've added OfflineClientSessionModel and OfflineUserSessionModel
>     with
>     CRUD methods on UserModel. So when new offline token is generated by
>     Keycloak, some info about current UserSession and ClientSession is
>     persisted on UserModel. This means that offline token can be used to
>     create new access token even if "normal" UserSession and ClientSession
>     are already invalid or logged out.
>
>     - When refreshing access token with offline token, the auth-server
>     won't
>     send back another refresh token. It will send just accessToken +
>     IDToken. This is to avoid writes to user database for each token
>     refresh.
>
>     - In account management applications tab, there is new table column
>     "Additional grants" where is shown if client has offline token for
>     user.
>     The click on "Revoke" button will remove offline tokens and granted
>     consents as well - no separate actions for revoke consents and offline
>     tokens.
>
>
>     Still TODO:
>     - Properly handle consents (see "Questions" below)
>
>     - More tests, example, export/import , docs
>
>     - More things/refactoring based on your feedback
>
>
>     Questions:
>     - The specs mentions that consent should be displayed when offline
>     token
>     is requested. See
>     http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>     Right now, I am not doing that. So when Client has "isConsentRequired"
>     as false, the consent screen is not displayed. Now we also don't have
>     support for "prompt=consent" (not sure if we need this) . Is it ok to
>     keep it like this?
>
>
> Wording is "MUST explicitly receive or have consent" - as the client 
> does not require consent (isConsentRequired=false) that implies the 
> client already has been given consent by the admin.
>
>
>     - I am thinking about adding new builtin client role "offline_access",
>     which will be created for client when admin enables "offline tokens"
>     switch. It will be used also as default role. This will allow that
>     just
>     some users are allowed to obtain offline-token (those which have this
>     role). The role will be also displayed on consent screen for the
>     clients, which needs consent.
>     But that raises another question. IMO it will be good if role is
>     requested and displayed on consent screen just if offline token is
>     requested, but not when classic refresh token is requested.
>
>
>     Hence I was thinking about adding the flag "scopeParamMode" to
>     RoleModel. The value true means that role will be requested and
>     used in
>     accessToken/refreshToken just if scope parameter contains it's value.
>     This will be the setup for "offline_access" role, so it's used
>     just for
>     the offline token requests. Another thing is format of scope parameter
>     with respect to realm roles and application roles. We can use "//" as
>     delimiter, so realm role will have just "my-role" but client role will
>     have "my-client//my-role" . The disadvantage is that for requesting
>     offline_access you will then need to use scope like:
>     "scope=customer-portal//offline_access" as it's client role.
>
>
> Spec says scope should be "offline_access", so if we use a different 
> name for it won't comply with the spec.
>
> Shouldn't the offline_access role be a realm role rather than a role 
> per-client?
The issue with realm role is, that user needs to confirm offline_access 
consent just once per all clients, which doesn't look correct to me.

For example there would be 2 clients "foo" and "bar":
- User john wants offline_access for client "foo"
- Consent screen is displayed with "offline_access" role and he confirms it
- Then user john wants offline_access for client "bar"
- There is no "offline_access" anymore on consent screen because john 
already has consent for realm role "offline_access" .


IMO it should be "offline_access" displayed again as it's different 
client. Also logically offline_access is granted per client, so the text 
on the grant screen is:

"has Offline Access in foo"

or

"has Offline Access in bar"

which will be with client roles.

>
> Another thing to consider is that we'll be moving to role namespaces 
> instead of realm/client roles soon. In that case we might want a 
> OpenID Connect namespace that can hold these scopes. So role could be 
> "openid/offline_access".
Ok. Maybe for now I won't do anything tricky but just limit the scope 
param support to client roles of current client. So scope 
"offline_access" is "offline_access" role of current client. We can 
improve it later once we add role namespaces support. WDYT?

Marek
>
>
>     WDYT? Any better idea?
>
>     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/20150921/5c5796ab/attachment-0001.html 

From sthorger at redhat.com  Mon Sep 21 08:25:49 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Sep 2015 14:25:49 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFF2CA.8000204@redhat.com>
References: <55FFD698.7040100@redhat.com>
	<CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
	<55FFF2CA.8000204@redhat.com>
Message-ID: <CAJgngAdi7Nk40z471=hEP3amy=Fpn8x618y_Kn6RV9rS51Lr4A@mail.gmail.com>

What you've listed there doesn't sound correct to me. Each client that
requires consent (consentRequired=true) has to prompt the user for all
roles including realm roles. So each client requiring consent would need to
ask user for consent.

How I think it would work is:

* Add a 'offline_access' realm role - in the future we can move this to a
OpenID Connect specific namespace
* If a client has 'full access' on the scope tab it can obtain an offline
token - no need for a separate offline enable toggle for this
* The user has a role mapping for this (should be added by default as you
said)

A client that doesn't require consent (consentRequired=false) will
automatically be provided with an offline token as long as the client
either has full access or a scope on the realm offline_access role. For a
client that requires consent the consent screen will first be shown,
including all requested roles/scopes which includes the realm level
'offline_access' role. One given the consent is saved for that specific
client. When another client that requires consent asks for offline token
the consent screen is yet again shown.

On 21 September 2015 at 14:06, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/09/15 12:33, Stian Thorgersen wrote:
>
>
>
> On 21 September 2015 at 12:06, Marek Posolda <mposolda at redhat.com> wrote:
>
>> I've sent the PR . Right now it works like this:
>>
>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>> retrieve offline tokens just if flag is enabled
>>
>> - Offline token is classic refresh token with 2 differences. It has type
>> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
>> token, the expiration value is 0, so it never expires.
>>
>> - Offline token is generated by auth-server when client sends
>> "scope=offline_access" . It's supported for classic browser flow, but
>> also for Direct Grant flow or Service account flow.
>>
>> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
>> CRUD methods on UserModel. So when new offline token is generated by
>> Keycloak, some info about current UserSession and ClientSession is
>> persisted on UserModel. This means that offline token can be used to
>> create new access token even if "normal" UserSession and ClientSession
>> are already invalid or logged out.
>>
>> - When refreshing access token with offline token, the auth-server won't
>> send back another refresh token. It will send just accessToken +
>> IDToken. This is to avoid writes to user database for each token refresh.
>>
>> - In account management applications tab, there is new table column
>> "Additional grants" where is shown if client has offline token for user.
>> The click on "Revoke" button will remove offline tokens and granted
>> consents as well - no separate actions for revoke consents and offline
>> tokens.
>>
>>
>> Still TODO:
>> - Properly handle consents (see "Questions" below)
>>
>> - More tests, example, export/import , docs
>>
>> - More things/refactoring based on your feedback
>>
>>
>> Questions:
>> - The specs mentions that consent should be displayed when offline token
>> is requested. See
>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>> Right now, I am not doing that. So when Client has "isConsentRequired"
>> as false, the consent screen is not displayed. Now we also don't have
>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>> keep it like this?
>>
>
> Wording is "MUST explicitly receive or have consent" - as the client does
> not require consent (isConsentRequired=false) that implies the client
> already has been given consent by the admin.
>
>
>>
>> - I am thinking about adding new builtin client role "offline_access",
>> which will be created for client when admin enables "offline tokens"
>> switch. It will be used also as default role. This will allow that just
>> some users are allowed to obtain offline-token (those which have this
>> role). The role will be also displayed on consent screen for the
>> clients, which needs consent.
>> But that raises another question. IMO it will be good if role is
>> requested and displayed on consent screen just if offline token is
>> requested, but not when classic refresh token is requested.
>
>
>> Hence I was thinking about adding the flag "scopeParamMode" to
>> RoleModel. The value true means that role will be requested and used in
>> accessToken/refreshToken just if scope parameter contains it's value.
>> This will be the setup for "offline_access" role, so it's used just for
>> the offline token requests. Another thing is format of scope parameter
>> with respect to realm roles and application roles. We can use "//" as
>> delimiter, so realm role will have just "my-role" but client role will
>> have "my-client//my-role" . The disadvantage is that for requesting
>> offline_access you will then need to use scope like:
>> "scope=customer-portal//offline_access" as it's client role.
>>
>
> Spec says scope should be "offline_access", so if we use a different name
> for it won't comply with the spec.
>
> Shouldn't the offline_access role be a realm role rather than a role
> per-client?
>
> The issue with realm role is, that user needs to confirm offline_access
> consent just once per all clients, which doesn't look correct to me.
>
> For example there would be 2 clients "foo" and "bar":
> - User john wants offline_access for client "foo"
> - Consent screen is displayed with "offline_access" role and he confirms it
> - Then user john wants offline_access for client "bar"
> - There is no "offline_access" anymore on consent screen because john
> already has consent for realm role "offline_access" .
>
>
> IMO it should be "offline_access" displayed again as it's different
> client. Also logically offline_access is granted per client, so the text on
> the grant screen is:
>
> "has Offline Access in foo"
>
> or
>
> "has Offline Access in bar"
>
> which will be with client roles.
>
>
> Another thing to consider is that we'll be moving to role namespaces
> instead of realm/client roles soon. In that case we might want a OpenID
> Connect namespace that can hold these scopes. So role could be
> "openid/offline_access".
>
> Ok. Maybe for now I won't do anything tricky but just limit the scope
> param support to client roles of current client. So scope "offline_access"
> is "offline_access" role of current client. We can improve it later once we
> add role namespaces support. WDYT?
>
> Marek
>
>
>
>>
>> WDYT? Any better idea?
>>
>> 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/20150921/0240ca4f/attachment.html 

From mposolda at redhat.com  Mon Sep 21 08:27:47 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 14:27:47 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFDBCE.4070201@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFDBCE.4070201@redhat.com>
Message-ID: <55FFF7C3.70806@redhat.com>

On 21/09/15 12:28, pslegr wrote:
>
>
> On 21.9.2015 12:06, Marek Posolda wrote:
>> I've sent the PR . Right now it works like this:
>>
>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>> retrieve offline tokens just if flag is enabled
>>
>> - Offline token is classic refresh token with 2 differences. It has type
>> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
>> token, the expiration value is 0, so it never expires.
> Just an idea.
> Have you ever thought, in terms of expiration, not only
> about refresh vs. never expires
> BUT also about defining the exact time of expiration ?
> for example validity for 1 Month, 1 year, 3 years ... etc.
> This would offer the possibility on the fly generate the so called; 
> "offline license tokens", which are
> then used for different lifetime periods.
> IMHO this might extend the usage for Keycloak into the license 
> providers field ;)
We have already some support for required action "Terms & Condition" at 
the keycloak server level. AFAIK user needs to confirm "Terms & 
Conditions" page when he has that required action set on him. You have 
also possibility to customize the content of the page.

  I wonder if this required action can be used for time based licences 
as well? Like for example you will have possibility to configure that 
validity of licence is 1 year, so after 1 year will be required action 
added to user automatically and he will need to confirm it again during 
login?

The possibility you mentioned is about handling licence agreement at the 
client level by the application itself if I understand correctly? So 
application will save offline token and the token is valid for 3 years, 
so application will display the licence screen when it notifies that 
offline token is expired. Am I understand correctly?

IMO extend the current Terms & Conditions action for expiration after 
some time looks better to me, as you won't need to do any more coding in 
your application. Just set the timeout for Terms&Conditions (or licence 
) action at keycloak admin console.

Marek
>>
>> - Offline token is generated by auth-server when client sends
>> "scope=offline_access" . It's supported for classic browser flow, but
>> also for Direct Grant flow or Service account flow.
>>
>> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
>> CRUD methods on UserModel. So when new offline token is generated by
>> Keycloak, some info about current UserSession and ClientSession is
>> persisted on UserModel. This means that offline token can be used to
>> create new access token even if "normal" UserSession and ClientSession
>> are already invalid or logged out.
>>
>> - When refreshing access token with offline token, the auth-server won't
>> send back another refresh token. It will send just accessToken +
>> IDToken. This is to avoid writes to user database for each token 
>> refresh.
>>
>> - In account management applications tab, there is new table column
>> "Additional grants" where is shown if client has offline token for user.
>> The click on "Revoke" button will remove offline tokens and granted
>> consents as well - no separate actions for revoke consents and offline
>> tokens.
>>
>>
>> Still TODO:
>> - Properly handle consents (see "Questions" below)
>>
>> - More tests, example, export/import , docs
>>
>> - More things/refactoring based on your feedback
>>
>>
>> Questions:
>> - The specs mentions that consent should be displayed when offline token
>> is requested. See
>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>> Right now, I am not doing that. So when Client has "isConsentRequired"
>> as false, the consent screen is not displayed. Now we also don't have
>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>> keep it like this?
>>
>> - I am thinking about adding new builtin client role "offline_access",
>> which will be created for client when admin enables "offline tokens"
>> switch. It will be used also as default role. This will allow that just
>> some users are allowed to obtain offline-token (those which have this
>> role). The role will be also displayed on consent screen for the
>> clients, which needs consent.
>> But that raises another question. IMO it will be good if role is
>> requested and displayed on consent screen just if offline token is
>> requested, but not when classic refresh token is requested.
>>
>> Hence I was thinking about adding the flag "scopeParamMode" to
>> RoleModel. The value true means that role will be requested and used in
>> accessToken/refreshToken just if scope parameter contains it's value.
>> This will be the setup for "offline_access" role, so it's used just for
>> the offline token requests. Another thing is format of scope parameter
>> with respect to realm roles and application roles. We can use "//" as
>> delimiter, so realm role will have just "my-role" but client role will
>> have "my-client//my-role" . The disadvantage is that for requesting
>> offline_access you will then need to use scope like:
>> "scope=customer-portal//offline_access" as it's client role.
>>
>> WDYT? Any better idea?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From bburke at redhat.com  Mon Sep 21 08:43:59 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Sep 2015 08:43:59 -0400
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFD698.7040100@redhat.com>
References: <55FFD698.7040100@redhat.com>
Message-ID: <55FFFB8F.5020506@redhat.com>



On 9/21/2015 6:06 AM, Marek Posolda wrote:
> I've sent the PR . Right now it works like this:
>
> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> retrieve offline tokens just if flag is enabled
>
> - Offline token is classic refresh token with 2 differences. It has type
> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
> token, the expiration value is 0, so it never expires.
>
> - Offline token is generated by auth-server when client sends
> "scope=offline_access" . It's supported for classic browser flow, but
> also for Direct Grant flow or Service account flow.
>
> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
> CRUD methods on UserModel. So when new offline token is generated by
> Keycloak, some info about current UserSession and ClientSession is
> persisted on UserModel. This means that offline token can be used to
> create new access token even if "normal" UserSession and ClientSession
> are already invalid or logged out.
>

You have to move this out of UserModel.  UserModel may be backed 99% by 
a UserFederationProvider.  In the near future, UserFederationProvider 
users may all sit in memory for only the lifetime of the session.


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

From mposolda at redhat.com  Mon Sep 21 08:58:38 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 14:58:38 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <CAJgngAdi7Nk40z471=hEP3amy=Fpn8x618y_Kn6RV9rS51Lr4A@mail.gmail.com>
References: <55FFD698.7040100@redhat.com>
	<CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
	<55FFF2CA.8000204@redhat.com>
	<CAJgngAdi7Nk40z471=hEP3amy=Fpn8x618y_Kn6RV9rS51Lr4A@mail.gmail.com>
Message-ID: <55FFFEFE.4060905@redhat.com>

On 21/09/15 14:25, Stian Thorgersen wrote:
> What you've listed there doesn't sound correct to me. Each client that 
> requires consent (consentRequired=true) has to prompt the user for all 
> roles including realm roles. So each client requiring consent would 
> need to ask user for consent.
Indeed you're right :-)
>
> How I think it would work is:
>
> * Add a 'offline_access' realm role - in the future we can move this 
> to a OpenID Connect specific namespace
> * If a client has 'full access' on the scope tab it can obtain an 
> offline token - no need for a separate offline enable toggle for this
> * The user has a role mapping for this (should be added by default as 
> you said)
>
> A client that doesn't require consent (consentRequired=false) will 
> automatically be provided with an offline token as long as the client 
> either has full access or a scope on the realm offline_access role. 
> For a client that requires consent the consent screen will first be 
> shown, including all requested roles/scopes which includes the realm 
> level 'offline_access' role. One given the consent is saved for that 
> specific client. When another client that requires consent asks for 
> offline token the consent screen is yet again shown.
There is one thing, that if client has scope and requires consent, the 
consent screen with "Has Offline Access" will be displayed even if 
offline token wasn't requested . The offline_access role will be also 
always available in access token even with "classic" login without 
offline token. Is this acceptable? Or should we add the flag on 
RoleModel that role will be included just if available in scope parameter?

Marek

>
> On 21 September 2015 at 14:06, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 21/09/15 12:33, Stian Thorgersen wrote:
>>
>>
>>     On 21 September 2015 at 12:06, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         I've sent the PR . Right now it works like this:
>>
>>         - ClientModel has flag "offlineTokensEnabled" . It's possible to
>>         retrieve offline tokens just if flag is enabled
>>
>>         - Offline token is classic refresh token with 2 differences.
>>         It has type
>>         "OFFLINE" when normal refresh token has type "REFRESH" . And
>>         for offline
>>         token, the expiration value is 0, so it never expires.
>>
>>         - Offline token is generated by auth-server when client sends
>>         "scope=offline_access" . It's supported for classic browser
>>         flow, but
>>         also for Direct Grant flow or Service account flow.
>>
>>         - I've added OfflineClientSessionModel and
>>         OfflineUserSessionModel with
>>         CRUD methods on UserModel. So when new offline token is
>>         generated by
>>         Keycloak, some info about current UserSession and
>>         ClientSession is
>>         persisted on UserModel. This means that offline token can be
>>         used to
>>         create new access token even if "normal" UserSession and
>>         ClientSession
>>         are already invalid or logged out.
>>
>>         - When refreshing access token with offline token, the
>>         auth-server won't
>>         send back another refresh token. It will send just accessToken +
>>         IDToken. This is to avoid writes to user database for each
>>         token refresh.
>>
>>         - In account management applications tab, there is new table
>>         column
>>         "Additional grants" where is shown if client has offline
>>         token for user.
>>         The click on "Revoke" button will remove offline tokens and
>>         granted
>>         consents as well - no separate actions for revoke consents
>>         and offline
>>         tokens.
>>
>>
>>         Still TODO:
>>         - Properly handle consents (see "Questions" below)
>>
>>         - More tests, example, export/import , docs
>>
>>         - More things/refactoring based on your feedback
>>
>>
>>         Questions:
>>         - The specs mentions that consent should be displayed when
>>         offline token
>>         is requested. See
>>         http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
>>         .
>>         Right now, I am not doing that. So when Client has
>>         "isConsentRequired"
>>         as false, the consent screen is not displayed. Now we also
>>         don't have
>>         support for "prompt=consent" (not sure if we need this) . Is
>>         it ok to
>>         keep it like this?
>>
>>
>>     Wording is "MUST explicitly receive or have consent" - as the
>>     client does not require consent (isConsentRequired=false) that
>>     implies the client already has been given consent by the admin.
>>
>>
>>         - I am thinking about adding new builtin client role
>>         "offline_access",
>>         which will be created for client when admin enables "offline
>>         tokens"
>>         switch. It will be used also as default role. This will allow
>>         that just
>>         some users are allowed to obtain offline-token (those which
>>         have this
>>         role). The role will be also displayed on consent screen for the
>>         clients, which needs consent.
>>         But that raises another question. IMO it will be good if role is
>>         requested and displayed on consent screen just if offline
>>         token is
>>         requested, but not when classic refresh token is requested.
>>
>>
>>         Hence I was thinking about adding the flag "scopeParamMode" to
>>         RoleModel. The value true means that role will be requested
>>         and used in
>>         accessToken/refreshToken just if scope parameter contains
>>         it's value.
>>         This will be the setup for "offline_access" role, so it's
>>         used just for
>>         the offline token requests. Another thing is format of scope
>>         parameter
>>         with respect to realm roles and application roles. We can use
>>         "//" as
>>         delimiter, so realm role will have just "my-role" but client
>>         role will
>>         have "my-client//my-role" . The disadvantage is that for
>>         requesting
>>         offline_access you will then need to use scope like:
>>         "scope=customer-portal//offline_access" as it's client role.
>>
>>
>>     Spec says scope should be "offline_access", so if we use a
>>     different name for it won't comply with the spec.
>>
>>     Shouldn't the offline_access role be a realm role rather than a
>>     role per-client?
>     The issue with realm role is, that user needs to confirm
>     offline_access consent just once per all clients, which doesn't
>     look correct to me.
>
>     For example there would be 2 clients "foo" and "bar":
>     - User john wants offline_access for client "foo"
>     - Consent screen is displayed with "offline_access" role and he
>     confirms it
>     - Then user john wants offline_access for client "bar"
>     - There is no "offline_access" anymore on consent screen because
>     john already has consent for realm role "offline_access" .
>
>
>     IMO it should be "offline_access" displayed again as it's
>     different client. Also logically offline_access is granted per
>     client, so the text on the grant screen is:
>
>     "has Offline Access in foo"
>
>     or
>
>     "has Offline Access in bar"
>
>     which will be with client roles.
>
>>
>>     Another thing to consider is that we'll be moving to role
>>     namespaces instead of realm/client roles soon. In that case we
>>     might want a OpenID Connect namespace that can hold these scopes.
>>     So role could be "openid/offline_access".
>     Ok. Maybe for now I won't do anything tricky but just limit the
>     scope param support to client roles of current client. So scope
>     "offline_access" is "offline_access" role of current client. We
>     can improve it later once we add role namespaces support. WDYT?
>
>     Marek
>>
>>
>>         WDYT? Any better idea?
>>
>>         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/20150921/6567567c/attachment.html 

From mposolda at redhat.com  Mon Sep 21 09:04:30 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 15:04:30 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFFB8F.5020506@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
Message-ID: <5600005E.1020306@redhat.com>

On 21/09/15 14:43, Bill Burke wrote:
>
> On 9/21/2015 6:06 AM, Marek Posolda wrote:
>> I've sent the PR . Right now it works like this:
>>
>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>> retrieve offline tokens just if flag is enabled
>>
>> - Offline token is classic refresh token with 2 differences. It has type
>> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
>> token, the expiration value is 0, so it never expires.
>>
>> - Offline token is generated by auth-server when client sends
>> "scope=offline_access" . It's supported for classic browser flow, but
>> also for Direct Grant flow or Service account flow.
>>
>> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
>> CRUD methods on UserModel. So when new offline token is generated by
>> Keycloak, some info about current UserSession and ClientSession is
>> persisted on UserModel. This means that offline token can be used to
>> create new access token even if "normal" UserSession and ClientSession
>> are already invalid or logged out.
>>
> You have to move this out of UserModel.  UserModel may be backed 99% by
> a UserFederationProvider.  In the near future, UserFederationProvider
> users may all sit in memory for only the lifetime of the session.
>
>
Does it makes sense to issue offline token for the users, which are 
valid just for the lifetime of the session?

Marek

From pslegr at redhat.com  Mon Sep 21 09:15:40 2015
From: pslegr at redhat.com (pslegr)
Date: Mon, 21 Sep 2015 15:15:40 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFF7C3.70806@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFDBCE.4070201@redhat.com>
	<55FFF7C3.70806@redhat.com>
Message-ID: <560002FC.2040503@redhat.com>



On 21.9.2015 14:27, Marek Posolda wrote:
> On 21/09/15 12:28, pslegr wrote:
>>
>>
>> On 21.9.2015 12:06, Marek Posolda wrote:
>>> I've sent the PR . Right now it works like this:
>>>
>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>>> retrieve offline tokens just if flag is enabled
>>>
>>> - Offline token is classic refresh token with 2 differences. It has 
>>> type
>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for 
>>> offline
>>> token, the expiration value is 0, so it never expires.
>> Just an idea.
>> Have you ever thought, in terms of expiration, not only
>> about refresh vs. never expires
>> BUT also about defining the exact time of expiration ?
>> for example validity for 1 Month, 1 year, 3 years ... etc.
>> This would offer the possibility on the fly generate the so called; 
>> "offline license tokens", which are
>> then used for different lifetime periods.
>> IMHO this might extend the usage for Keycloak into the license 
>> providers field ;)
> We have already some support for required action "Terms & Condition" 
> at the keycloak server level. AFAIK user needs to confirm "Terms & 
> Conditions" page when he has that required action set on him. You have 
> also possibility to customize the content of the page.
>
>  I wonder if this required action can be used for time based licences 
> as well? Like for example you will have possibility to configure that 
> validity of licence is 1 year, so after 1 year will be required action 
> added to user automatically and he will need to confirm it again 
> during login?
Well, I had more the offline licensing on my mind. In such situation you 
would not ever communicate with the server from client.
>
> The possibility you mentioned is about handling licence agreement at 
> the client level by the application itself if I understand correctly? 
> So application will save offline token and the token is valid for 3 
> years, so application will display the licence screen when it notifies 
> that offline token is expired. Am I understand correctly?
Yes, I think you pretty much got it
The thing is, once you imagine the offline license generation, then this 
is a once time action, at the beginning. The license provider who owns 
private keys makes that once and provide to the clients.
The token is then verified for offline actions and once expired must be 
replaced by license provide again.
>
> IMO extend the current Terms & Conditions action for expiration after 
> some time looks better to me, as you won't need to do any more coding 
> in your application. Just set the timeout for Terms&Conditions (or 
> licence ) action at keycloak admin console.

Is the "Terms & Conditions action" something which works offline  ?

Pavel
>
> Marek
>>>
>>> - Offline token is generated by auth-server when client sends
>>> "scope=offline_access" . It's supported for classic browser flow, but
>>> also for Direct Grant flow or Service account flow.
>>>
>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
>>> CRUD methods on UserModel. So when new offline token is generated by
>>> Keycloak, some info about current UserSession and ClientSession is
>>> persisted on UserModel. This means that offline token can be used to
>>> create new access token even if "normal" UserSession and ClientSession
>>> are already invalid or logged out.
>>>
>>> - When refreshing access token with offline token, the auth-server 
>>> won't
>>> send back another refresh token. It will send just accessToken +
>>> IDToken. This is to avoid writes to user database for each token 
>>> refresh.
>>>
>>> - In account management applications tab, there is new table column
>>> "Additional grants" where is shown if client has offline token for 
>>> user.
>>> The click on "Revoke" button will remove offline tokens and granted
>>> consents as well - no separate actions for revoke consents and offline
>>> tokens.
>>>
>>>
>>> Still TODO:
>>> - Properly handle consents (see "Questions" below)
>>>
>>> - More tests, example, export/import , docs
>>>
>>> - More things/refactoring based on your feedback
>>>
>>>
>>> Questions:
>>> - The specs mentions that consent should be displayed when offline 
>>> token
>>> is requested. See
>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>>> Right now, I am not doing that. So when Client has "isConsentRequired"
>>> as false, the consent screen is not displayed. Now we also don't have
>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>>> keep it like this?
>>>
>>> - I am thinking about adding new builtin client role "offline_access",
>>> which will be created for client when admin enables "offline tokens"
>>> switch. It will be used also as default role. This will allow that just
>>> some users are allowed to obtain offline-token (those which have this
>>> role). The role will be also displayed on consent screen for the
>>> clients, which needs consent.
>>> But that raises another question. IMO it will be good if role is
>>> requested and displayed on consent screen just if offline token is
>>> requested, but not when classic refresh token is requested.
>>>
>>> Hence I was thinking about adding the flag "scopeParamMode" to
>>> RoleModel. The value true means that role will be requested and used in
>>> accessToken/refreshToken just if scope parameter contains it's value.
>>> This will be the setup for "offline_access" role, so it's used just for
>>> the offline token requests. Another thing is format of scope parameter
>>> with respect to realm roles and application roles. We can use "//" as
>>> delimiter, so realm role will have just "my-role" but client role will
>>> have "my-client//my-role" . The disadvantage is that for requesting
>>> offline_access you will then need to use scope like:
>>> "scope=customer-portal//offline_access" as it's client role.
>>>
>>> WDYT? Any better idea?
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>


From sthorger at redhat.com  Mon Sep 21 09:46:37 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 21 Sep 2015 15:46:37 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <55FFFEFE.4060905@redhat.com>
References: <55FFD698.7040100@redhat.com>
	<CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
	<55FFF2CA.8000204@redhat.com>
	<CAJgngAdi7Nk40z471=hEP3amy=Fpn8x618y_Kn6RV9rS51Lr4A@mail.gmail.com>
	<55FFFEFE.4060905@redhat.com>
Message-ID: <CAJgngAf_nJmB2kO98BHu6L431O+rfv_qyNX29mb=HPhMwKBmSg@mail.gmail.com>

On 21 September 2015 at 14:58, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/09/15 14:25, Stian Thorgersen wrote:
>
> What you've listed there doesn't sound correct to me. Each client that
> requires consent (consentRequired=true) has to prompt the user for all
> roles including realm roles. So each client requiring consent would need to
> ask user for consent.
>
> Indeed you're right :-)
>
>
> How I think it would work is:
>
> * Add a 'offline_access' realm role - in the future we can move this to a
> OpenID Connect specific namespace
> * If a client has 'full access' on the scope tab it can obtain an offline
> token - no need for a separate offline enable toggle for this
> * The user has a role mapping for this (should be added by default as you
> said)
>
> A client that doesn't require consent (consentRequired=false) will
> automatically be provided with an offline token as long as the client
> either has full access or a scope on the realm offline_access role. For a
> client that requires consent the consent screen will first be shown,
> including all requested roles/scopes which includes the realm level
> 'offline_access' role. One given the consent is saved for that specific
> client. When another client that requires consent asks for offline token
> the consent screen is yet again shown.
>
> There is one thing, that if client has scope and requires consent, the
> consent screen with "Has Offline Access" will be displayed even if offline
> token wasn't requested . The offline_access role will be also always
> available in access token even with "classic" login without offline token.
> Is this acceptable? Or should we add the flag on RoleModel that role will
> be included just if available in scope parameter?
>

I don't think that's acceptable - sounds like the flag would be useful in
either case at it lets us have roles the client has to actively ask for in
the scope param


>
>
> Marek
>
>
>
> On 21 September 2015 at 14:06, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 21/09/15 12:33, Stian Thorgersen wrote:
>>
>>
>>
>> On 21 September 2015 at 12:06, Marek Posolda < <mposolda at redhat.com>
>> mposolda at redhat.com> wrote:
>>
>>> I've sent the PR . Right now it works like this:
>>>
>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>>> retrieve offline tokens just if flag is enabled
>>>
>>> - Offline token is classic refresh token with 2 differences. It has type
>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for offline
>>> token, the expiration value is 0, so it never expires.
>>>
>>> - Offline token is generated by auth-server when client sends
>>> "scope=offline_access" . It's supported for classic browser flow, but
>>> also for Direct Grant flow or Service account flow.
>>>
>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel with
>>> CRUD methods on UserModel. So when new offline token is generated by
>>> Keycloak, some info about current UserSession and ClientSession is
>>> persisted on UserModel. This means that offline token can be used to
>>> create new access token even if "normal" UserSession and ClientSession
>>> are already invalid or logged out.
>>>
>>> - When refreshing access token with offline token, the auth-server won't
>>> send back another refresh token. It will send just accessToken +
>>> IDToken. This is to avoid writes to user database for each token refresh.
>>>
>>> - In account management applications tab, there is new table column
>>> "Additional grants" where is shown if client has offline token for user.
>>> The click on "Revoke" button will remove offline tokens and granted
>>> consents as well - no separate actions for revoke consents and offline
>>> tokens.
>>>
>>>
>>> Still TODO:
>>> - Properly handle consents (see "Questions" below)
>>>
>>> - More tests, example, export/import , docs
>>>
>>> - More things/refactoring based on your feedback
>>>
>>>
>>> Questions:
>>> - The specs mentions that consent should be displayed when offline token
>>> is requested. See
>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>>> Right now, I am not doing that. So when Client has "isConsentRequired"
>>> as false, the consent screen is not displayed. Now we also don't have
>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>>> keep it like this?
>>>
>>
>> Wording is "MUST explicitly receive or have consent" - as the client
>> does not require consent (isConsentRequired=false) that implies the
>> client already has been given consent by the admin.
>>
>>
>>>
>>> - I am thinking about adding new builtin client role "offline_access",
>>> which will be created for client when admin enables "offline tokens"
>>> switch. It will be used also as default role. This will allow that just
>>> some users are allowed to obtain offline-token (those which have this
>>> role). The role will be also displayed on consent screen for the
>>> clients, which needs consent.
>>> But that raises another question. IMO it will be good if role is
>>> requested and displayed on consent screen just if offline token is
>>> requested, but not when classic refresh token is requested.
>>
>>
>>> Hence I was thinking about adding the flag "scopeParamMode" to
>>> RoleModel. The value true means that role will be requested and used in
>>> accessToken/refreshToken just if scope parameter contains it's value.
>>> This will be the setup for "offline_access" role, so it's used just for
>>> the offline token requests. Another thing is format of scope parameter
>>> with respect to realm roles and application roles. We can use "//" as
>>> delimiter, so realm role will have just "my-role" but client role will
>>> have "my-client//my-role" . The disadvantage is that for requesting
>>> offline_access you will then need to use scope like:
>>> "scope=customer-portal//offline_access" as it's client role.
>>>
>>
>> Spec says scope should be "offline_access", so if we use a different name
>> for it won't comply with the spec.
>>
>> Shouldn't the offline_access role be a realm role rather than a role
>> per-client?
>>
>> The issue with realm role is, that user needs to confirm offline_access
>> consent just once per all clients, which doesn't look correct to me.
>>
>> For example there would be 2 clients "foo" and "bar":
>> - User john wants offline_access for client "foo"
>> - Consent screen is displayed with "offline_access" role and he confirms
>> it
>> - Then user john wants offline_access for client "bar"
>> - There is no "offline_access" anymore on consent screen because john
>> already has consent for realm role "offline_access" .
>>
>>
>> IMO it should be "offline_access" displayed again as it's different
>> client. Also logically offline_access is granted per client, so the text on
>> the grant screen is:
>>
>> "has Offline Access in foo"
>>
>> or
>>
>> "has Offline Access in bar"
>>
>> which will be with client roles.
>>
>>
>> Another thing to consider is that we'll be moving to role namespaces
>> instead of realm/client roles soon. In that case we might want a OpenID
>> Connect namespace that can hold these scopes. So role could be
>> "openid/offline_access".
>>
>> Ok. Maybe for now I won't do anything tricky but just limit the scope
>> param support to client roles of current client. So scope "offline_access"
>> is "offline_access" role of current client. We can improve it later once we
>> add role namespaces support. WDYT?
>>
>> Marek
>>
>>
>>
>>>
>>> WDYT? Any better idea?
>>>
>>> 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/20150921/fd7da985/attachment-0001.html 

From mposolda at redhat.com  Mon Sep 21 10:07:17 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Sep 2015 16:07:17 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <CAJgngAf_nJmB2kO98BHu6L431O+rfv_qyNX29mb=HPhMwKBmSg@mail.gmail.com>
References: <55FFD698.7040100@redhat.com>
	<CAJgngAd+J8Q6C=Wi3Kz9JUvRnzfjeqtZUR5+ogbeOZTOsfQ38g@mail.gmail.com>
	<55FFF2CA.8000204@redhat.com>
	<CAJgngAdi7Nk40z471=hEP3amy=Fpn8x618y_Kn6RV9rS51Lr4A@mail.gmail.com>
	<55FFFEFE.4060905@redhat.com>
	<CAJgngAf_nJmB2kO98BHu6L431O+rfv_qyNX29mb=HPhMwKBmSg@mail.gmail.com>
Message-ID: <56000F15.7090509@redhat.com>

On 21/09/15 15:46, Stian Thorgersen wrote:
>
>
> On 21 September 2015 at 14:58, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 21/09/15 14:25, Stian Thorgersen wrote:
>>     What you've listed there doesn't sound correct to me. Each client
>>     that requires consent (consentRequired=true) has to prompt the
>>     user for all roles including realm roles. So each client
>>     requiring consent would need to ask user for consent.
>     Indeed you're right :-)
>>
>>     How I think it would work is:
>>
>>     * Add a 'offline_access' realm role - in the future we can move
>>     this to a OpenID Connect specific namespace
>>     * If a client has 'full access' on the scope tab it can obtain an
>>     offline token - no need for a separate offline enable toggle for this
>>     * The user has a role mapping for this (should be added by
>>     default as you said)
>>
>>     A client that doesn't require consent (consentRequired=false)
>>     will automatically be provided with an offline token as long as
>>     the client either has full access or a scope on the realm
>>     offline_access role. For a client that requires consent the
>>     consent screen will first be shown, including all requested
>>     roles/scopes which includes the realm level 'offline_access'
>>     role. One given the consent is saved for that specific client.
>>     When another client that requires consent asks for offline token
>>     the consent screen is yet again shown.
>     There is one thing, that if client has scope and requires consent,
>     the consent screen with "Has Offline Access" will be displayed
>     even if offline token wasn't requested . The offline_access role
>     will be also always available in access token even with "classic"
>     login without offline token. Is this acceptable? Or should we add
>     the flag on RoleModel that role will be included just if available
>     in scope parameter?
>
>
> I don't think that's acceptable - sounds like the flag would be useful 
> in either case at it lets us have roles the client has to actively ask 
> for in the scope param
Thanks, I will go for it then.

Marek
>
>
>
>     Marek
>
>
>>
>>     On 21 September 2015 at 14:06, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         On 21/09/15 12:33, Stian Thorgersen wrote:
>>>
>>>
>>>         On 21 September 2015 at 12:06, Marek Posolda
>>>         <mposolda at redhat.com <mailto:mposolda at redhat.com>> wrote:
>>>
>>>             I've sent the PR . Right now it works like this:
>>>
>>>             - ClientModel has flag "offlineTokensEnabled" . It's
>>>             possible to
>>>             retrieve offline tokens just if flag is enabled
>>>
>>>             - Offline token is classic refresh token with 2
>>>             differences. It has type
>>>             "OFFLINE" when normal refresh token has type "REFRESH" .
>>>             And for offline
>>>             token, the expiration value is 0, so it never expires.
>>>
>>>             - Offline token is generated by auth-server when client
>>>             sends
>>>             "scope=offline_access" . It's supported for classic
>>>             browser flow, but
>>>             also for Direct Grant flow or Service account flow.
>>>
>>>             - I've added OfflineClientSessionModel and
>>>             OfflineUserSessionModel with
>>>             CRUD methods on UserModel. So when new offline token is
>>>             generated by
>>>             Keycloak, some info about current UserSession and
>>>             ClientSession is
>>>             persisted on UserModel. This means that offline token
>>>             can be used to
>>>             create new access token even if "normal" UserSession and
>>>             ClientSession
>>>             are already invalid or logged out.
>>>
>>>             - When refreshing access token with offline token, the
>>>             auth-server won't
>>>             send back another refresh token. It will send just
>>>             accessToken +
>>>             IDToken. This is to avoid writes to user database for
>>>             each token refresh.
>>>
>>>             - In account management applications tab, there is new
>>>             table column
>>>             "Additional grants" where is shown if client has offline
>>>             token for user.
>>>             The click on "Revoke" button will remove offline tokens
>>>             and granted
>>>             consents as well - no separate actions for revoke
>>>             consents and offline
>>>             tokens.
>>>
>>>
>>>             Still TODO:
>>>             - Properly handle consents (see "Questions" below)
>>>
>>>             - More tests, example, export/import , docs
>>>
>>>             - More things/refactoring based on your feedback
>>>
>>>
>>>             Questions:
>>>             - The specs mentions that consent should be displayed
>>>             when offline token
>>>             is requested. See
>>>             http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
>>>             .
>>>             Right now, I am not doing that. So when Client has
>>>             "isConsentRequired"
>>>             as false, the consent screen is not displayed. Now we
>>>             also don't have
>>>             support for "prompt=consent" (not sure if we need this)
>>>             . Is it ok to
>>>             keep it like this?
>>>
>>>
>>>         Wording is "MUST explicitly receive or have consent" - as
>>>         the client does not require consent
>>>         (isConsentRequired=false) that implies the client already
>>>         has been given consent by the admin.
>>>
>>>
>>>             - I am thinking about adding new builtin client role
>>>             "offline_access",
>>>             which will be created for client when admin enables
>>>             "offline tokens"
>>>             switch. It will be used also as default role. This will
>>>             allow that just
>>>             some users are allowed to obtain offline-token (those
>>>             which have this
>>>             role). The role will be also displayed on consent screen
>>>             for the
>>>             clients, which needs consent.
>>>             But that raises another question. IMO it will be good if
>>>             role is
>>>             requested and displayed on consent screen just if
>>>             offline token is
>>>             requested, but not when classic refresh token is requested.
>>>
>>>
>>>             Hence I was thinking about adding the flag
>>>             "scopeParamMode" to
>>>             RoleModel. The value true means that role will be
>>>             requested and used in
>>>             accessToken/refreshToken just if scope parameter
>>>             contains it's value.
>>>             This will be the setup for "offline_access" role, so
>>>             it's used just for
>>>             the offline token requests. Another thing is format of
>>>             scope parameter
>>>             with respect to realm roles and application roles. We
>>>             can use "//" as
>>>             delimiter, so realm role will have just "my-role" but
>>>             client role will
>>>             have "my-client//my-role" . The disadvantage is that for
>>>             requesting
>>>             offline_access you will then need to use scope like:
>>>             "scope=customer-portal//offline_access" as it's client role.
>>>
>>>
>>>         Spec says scope should be "offline_access", so if we use a
>>>         different name for it won't comply with the spec.
>>>
>>>         Shouldn't the offline_access role be a realm role rather
>>>         than a role per-client?
>>         The issue with realm role is, that user needs to confirm
>>         offline_access consent just once per all clients, which
>>         doesn't look correct to me.
>>
>>         For example there would be 2 clients "foo" and "bar":
>>         - User john wants offline_access for client "foo"
>>         - Consent screen is displayed with "offline_access" role and
>>         he confirms it
>>         - Then user john wants offline_access for client "bar"
>>         - There is no "offline_access" anymore on consent screen
>>         because john already has consent for realm role
>>         "offline_access" .
>>
>>
>>         IMO it should be "offline_access" displayed again as it's
>>         different client. Also logically offline_access is granted
>>         per client, so the text on the grant screen is:
>>
>>         "has Offline Access in foo"
>>
>>         or
>>
>>         "has Offline Access in bar"
>>
>>         which will be with client roles.
>>
>>>
>>>         Another thing to consider is that we'll be moving to role
>>>         namespaces instead of realm/client roles soon. In that case
>>>         we might want a OpenID Connect namespace that can hold these
>>>         scopes. So role could be "openid/offline_access".
>>         Ok. Maybe for now I won't do anything tricky but just limit
>>         the scope param support to client roles of current client. So
>>         scope "offline_access" is "offline_access" role of current
>>         client. We can improve it later once we add role namespaces
>>         support. WDYT?
>>
>>         Marek
>>>
>>>
>>>             WDYT? Any better idea?
>>>
>>>             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/20150921/07f52b56/attachment-0001.html 

From bburke at redhat.com  Mon Sep 21 11:55:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Sep 2015 11:55:05 -0400
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <5600005E.1020306@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com>
Message-ID: <56002859.2010601@redhat.com>



On 9/21/2015 9:04 AM, Marek Posolda wrote:
>> You have to move this out of UserModel.  UserModel may be backed 99% by
>> a UserFederationProvider.  In the near future, UserFederationProvider
>> users may all sit in memory for only the lifetime of the session.
>>
>>
> Does it makes sense to issue offline token for the users, which are
> valid just for the lifetime of the session?
>

The users aren't temporary, they are just stored in LDAP or something. 
So yes, it does make sense to issue offline tokens.  The offline token 
storage will just need to store a reference to the user so it can 
rebuild it through our SPIs if needed.

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

From mposolda at redhat.com  Tue Sep 22 02:44:39 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Sep 2015 08:44:39 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <56002859.2010601@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
Message-ID: <5600F8D7.4040902@redhat.com>

Ok, I can add the methods to UserProvider instead of UserModel and add 
the UserModel as argument to CRUD methods. So it will use same pattern 
like we have for FederatedIdentityModel .

Still, I would like to use references to token storage by User ID, not 
by username. I wonder that when we later use in-memory UserModels backed 
fully by UserFederationProvider, we will need to ensure that User ID 
will be always same for same federated user "john" .  Like for example 
instead of random UUID, the user ID will be generated from hash of 
FederationProviderId+LDAPId . This will ensure that references to other 
places by User ID will still work.

Marek

On 21/09/15 17:55, Bill Burke wrote:
>
>
> On 9/21/2015 9:04 AM, Marek Posolda wrote:
>>> You have to move this out of UserModel. UserModel may be backed 99% by
>>> a UserFederationProvider.  In the near future, UserFederationProvider
>>> users may all sit in memory for only the lifetime of the session.
>>>
>>>
>> Does it makes sense to issue offline token for the users, which are
>> valid just for the lifetime of the session?
>>
>
> The users aren't temporary, they are just stored in LDAP or something. 
> So yes, it does make sense to issue offline tokens. The offline token 
> storage will just need to store a reference to the user so it can 
> rebuild it through our SPIs if needed.
>


From mposolda at redhat.com  Tue Sep 22 03:08:12 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Sep 2015 09:08:12 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <560002FC.2040503@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFDBCE.4070201@redhat.com>
	<55FFF7C3.70806@redhat.com> <560002FC.2040503@redhat.com>
Message-ID: <5600FE5C.8030800@redhat.com>

On 21/09/15 15:15, pslegr wrote:
>
>
> On 21.9.2015 14:27, Marek Posolda wrote:
>> On 21/09/15 12:28, pslegr wrote:
>>>
>>>
>>> On 21.9.2015 12:06, Marek Posolda wrote:
>>>> I've sent the PR . Right now it works like this:
>>>>
>>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>>>> retrieve offline tokens just if flag is enabled
>>>>
>>>> - Offline token is classic refresh token with 2 differences. It has 
>>>> type
>>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for 
>>>> offline
>>>> token, the expiration value is 0, so it never expires.
>>> Just an idea.
>>> Have you ever thought, in terms of expiration, not only
>>> about refresh vs. never expires
>>> BUT also about defining the exact time of expiration ?
>>> for example validity for 1 Month, 1 year, 3 years ... etc.
>>> This would offer the possibility on the fly generate the so called; 
>>> "offline license tokens", which are
>>> then used for different lifetime periods.
>>> IMHO this might extend the usage for Keycloak into the license 
>>> providers field ;)
>> We have already some support for required action "Terms & Condition" 
>> at the keycloak server level. AFAIK user needs to confirm "Terms & 
>> Conditions" page when he has that required action set on him. You 
>> have also possibility to customize the content of the page.
>>
>>  I wonder if this required action can be used for time based licences 
>> as well? Like for example you will have possibility to configure that 
>> validity of licence is 1 year, so after 1 year will be required 
>> action added to user automatically and he will need to confirm it 
>> again during login?
> Well, I had more the offline licensing on my mind. In such situation 
> you would not ever communicate with the server from client.
>>
>> The possibility you mentioned is about handling licence agreement at 
>> the client level by the application itself if I understand correctly? 
>> So application will save offline token and the token is valid for 3 
>> years, so application will display the licence screen when it 
>> notifies that offline token is expired. Am I understand correctly?
> Yes, I think you pretty much got it
> The thing is, once you imagine the offline license generation, then 
> this is a once time action, at the beginning. The license provider who 
> owns private keys makes that once and provide to the clients.
> The token is then verified for offline actions and once expired must 
> be replaced by license provide again.
Interesting usecase. Looks there are more possibilities how to support this.

1) We can add timeout for offline tokens (will be NEVER by default, so 
it will never expire).
2) We can add the protocol mappers extension points for refresh tokens 
as well (currently we use protocol mappers just for generation of access 
tokens and ID tokens). This will allow even more flexibility in 
generating refresh/offline tokens and use different timeouts for 
different clients etc.
3) Don't do anything directly in Keycloak, but let application handle 
this. When you receive offline token from Keycloak, you will save the 
offline token to your DB together with the time when offline token was 
received (you will handle the time by yourself, not from expiration 
field of offline token). Then your DB contains the time, so you can 
handle it in your application that after 3 years is token not valid 
anymore and the licence needs to be confirmed again.

>>
>> IMO extend the current Terms & Conditions action for expiration after 
>> some time looks better to me, as you won't need to do any more coding 
>> in your application. Just set the timeout for Terms&Conditions (or 
>> licence ) action at keycloak admin console.
>
> Is the "Terms & Conditions action" something which works offline  ?
No. It's displayed by Keycloak server, so it requires Keycloak server to 
be up and running.

Marek
>
> Pavel
>>
>> Marek
>>>>
>>>> - Offline token is generated by auth-server when client sends
>>>> "scope=offline_access" . It's supported for classic browser flow, but
>>>> also for Direct Grant flow or Service account flow.
>>>>
>>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel 
>>>> with
>>>> CRUD methods on UserModel. So when new offline token is generated by
>>>> Keycloak, some info about current UserSession and ClientSession is
>>>> persisted on UserModel. This means that offline token can be used to
>>>> create new access token even if "normal" UserSession and ClientSession
>>>> are already invalid or logged out.
>>>>
>>>> - When refreshing access token with offline token, the auth-server 
>>>> won't
>>>> send back another refresh token. It will send just accessToken +
>>>> IDToken. This is to avoid writes to user database for each token 
>>>> refresh.
>>>>
>>>> - In account management applications tab, there is new table column
>>>> "Additional grants" where is shown if client has offline token for 
>>>> user.
>>>> The click on "Revoke" button will remove offline tokens and granted
>>>> consents as well - no separate actions for revoke consents and offline
>>>> tokens.
>>>>
>>>>
>>>> Still TODO:
>>>> - Properly handle consents (see "Questions" below)
>>>>
>>>> - More tests, example, export/import , docs
>>>>
>>>> - More things/refactoring based on your feedback
>>>>
>>>>
>>>> Questions:
>>>> - The specs mentions that consent should be displayed when offline 
>>>> token
>>>> is requested. See
>>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>>>> Right now, I am not doing that. So when Client has "isConsentRequired"
>>>> as false, the consent screen is not displayed. Now we also don't have
>>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>>>> keep it like this?
>>>>
>>>> - I am thinking about adding new builtin client role "offline_access",
>>>> which will be created for client when admin enables "offline tokens"
>>>> switch. It will be used also as default role. This will allow that 
>>>> just
>>>> some users are allowed to obtain offline-token (those which have this
>>>> role). The role will be also displayed on consent screen for the
>>>> clients, which needs consent.
>>>> But that raises another question. IMO it will be good if role is
>>>> requested and displayed on consent screen just if offline token is
>>>> requested, but not when classic refresh token is requested.
>>>>
>>>> Hence I was thinking about adding the flag "scopeParamMode" to
>>>> RoleModel. The value true means that role will be requested and 
>>>> used in
>>>> accessToken/refreshToken just if scope parameter contains it's value.
>>>> This will be the setup for "offline_access" role, so it's used just 
>>>> for
>>>> the offline token requests. Another thing is format of scope parameter
>>>> with respect to realm roles and application roles. We can use "//" as
>>>> delimiter, so realm role will have just "my-role" but client role will
>>>> have "my-client//my-role" . The disadvantage is that for requesting
>>>> offline_access you will then need to use scope like:
>>>> "scope=customer-portal//offline_access" as it's client role.
>>>>
>>>> WDYT? Any better idea?
>>>>
>>>> Marek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>


From sthorger at redhat.com  Tue Sep 22 03:09:27 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Sep 2015 09:09:27 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <5600F8D7.4040902@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
	<5600F8D7.4040902@redhat.com>
Message-ID: <CAJgngAc-QWTSOSwxpPzVY_QUbDQrExH-6aYHe9ZHPRdLxfj6mw@mail.gmail.com>

On 22 September 2015 at 08:44, Marek Posolda <mposolda at redhat.com> wrote:

> Ok, I can add the methods to UserProvider instead of UserModel and add
> the UserModel as argument to CRUD methods. So it will use same pattern
> like we have for FederatedIdentityModel .
>
> Still, I would like to use references to token storage by User ID, not
> by username. I wonder that when we later use in-memory UserModels backed
> fully by UserFederationProvider, we will need to ensure that User ID
> will be always same for same federated user "john" .  Like for example
> instead of random UUID, the user ID will be generated from hash of
> FederationProviderId+LDAPId . This will ensure that references to other
> places by User ID will still work.
>

+1


>
> Marek
>
> On 21/09/15 17:55, Bill Burke wrote:
> >
> >
> > On 9/21/2015 9:04 AM, Marek Posolda wrote:
> >>> You have to move this out of UserModel. UserModel may be backed 99% by
> >>> a UserFederationProvider.  In the near future, UserFederationProvider
> >>> users may all sit in memory for only the lifetime of the session.
> >>>
> >>>
> >> Does it makes sense to issue offline token for the users, which are
> >> valid just for the lifetime of the session?
> >>
> >
> > The users aren't temporary, they are just stored in LDAP or something.
> > So yes, it does make sense to issue offline tokens. The offline token
> > storage will just need to store a reference to the user so it can
> > rebuild it through our SPIs if needed.
> >
>
> _______________________________________________
> 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/20150922/2987f540/attachment.html 

From sthorger at redhat.com  Tue Sep 22 03:16:45 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Sep 2015 09:16:45 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <5600FE5C.8030800@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFDBCE.4070201@redhat.com>
	<55FFF7C3.70806@redhat.com> <560002FC.2040503@redhat.com>
	<5600FE5C.8030800@redhat.com>
Message-ID: <CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com>

On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com> wrote:

> On 21/09/15 15:15, pslegr wrote:
> >
> >
> > On 21.9.2015 14:27, Marek Posolda wrote:
> >> On 21/09/15 12:28, pslegr wrote:
> >>>
> >>>
> >>> On 21.9.2015 12:06, Marek Posolda wrote:
> >>>> I've sent the PR . Right now it works like this:
> >>>>
> >>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
> >>>> retrieve offline tokens just if flag is enabled
> >>>>
> >>>> - Offline token is classic refresh token with 2 differences. It has
> >>>> type
> >>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for
> >>>> offline
> >>>> token, the expiration value is 0, so it never expires.
> >>> Just an idea.
> >>> Have you ever thought, in terms of expiration, not only
> >>> about refresh vs. never expires
> >>> BUT also about defining the exact time of expiration ?
> >>> for example validity for 1 Month, 1 year, 3 years ... etc.
> >>> This would offer the possibility on the fly generate the so called;
> >>> "offline license tokens", which are
> >>> then used for different lifetime periods.
> >>> IMHO this might extend the usage for Keycloak into the license
> >>> providers field ;)
> >> We have already some support for required action "Terms & Condition"
> >> at the keycloak server level. AFAIK user needs to confirm "Terms &
> >> Conditions" page when he has that required action set on him. You
> >> have also possibility to customize the content of the page.
> >>
> >>  I wonder if this required action can be used for time based licences
> >> as well? Like for example you will have possibility to configure that
> >> validity of licence is 1 year, so after 1 year will be required
> >> action added to user automatically and he will need to confirm it
> >> again during login?
> > Well, I had more the offline licensing on my mind. In such situation
> > you would not ever communicate with the server from client.
> >>
> >> The possibility you mentioned is about handling licence agreement at
> >> the client level by the application itself if I understand correctly?
> >> So application will save offline token and the token is valid for 3
> >> years, so application will display the licence screen when it
> >> notifies that offline token is expired. Am I understand correctly?
> > Yes, I think you pretty much got it
> > The thing is, once you imagine the offline license generation, then
> > this is a once time action, at the beginning. The license provider who
> > owns private keys makes that once and provide to the clients.
> > The token is then verified for offline actions and once expired must
> > be replaced by license provide again.
> Interesting usecase. Looks there are more possibilities how to support
> this.
>
> 1) We can add timeout for offline tokens (will be NEVER by default, so
> it will never expire).
> 2) We can add the protocol mappers extension points for refresh tokens
> as well (currently we use protocol mappers just for generation of access
> tokens and ID tokens). This will allow even more flexibility in
> generating refresh/offline tokens and use different timeouts for
> different clients etc.
> 3) Don't do anything directly in Keycloak, but let application handle
> this. When you receive offline token from Keycloak, you will save the
> offline token to your DB together with the time when offline token was
> received (you will handle the time by yourself, not from expiration
> field of offline token). Then your DB contains the time, so you can
> handle it in your application that after 3 years is token not valid
> anymore and the licence needs to be confirmed again.
>

Not sure I fully understand what the use-case is around this, but it seems
like what's being proposed is a complete misuse of offline tokens.

I'm assuming by licensing you mean something along the lines of a software
license where a user has paid for a 1 year license for a particular
application? If so offline tokens are not the solution as something like
that should work with regular tokens as well. There's also a lot of other
things to consider with regards to a license. You need a mechanism to add
the license in the first place (a signed token perhaps associated with the
users account), a way to renew the license (pay mechanism), etc.. It's not
something we've had any demand for, nor do I really think it's something an
authentication server should do.


>
> >>
> >> IMO extend the current Terms & Conditions action for expiration after
> >> some time looks better to me, as you won't need to do any more coding
> >> in your application. Just set the timeout for Terms&Conditions (or
> >> licence ) action at keycloak admin console.
> >
> > Is the "Terms & Conditions action" something which works offline  ?
> No. It's displayed by Keycloak server, so it requires Keycloak server to
> be up and running.
>
> Marek
> >
> > Pavel
> >>
> >> Marek
> >>>>
> >>>> - Offline token is generated by auth-server when client sends
> >>>> "scope=offline_access" . It's supported for classic browser flow, but
> >>>> also for Direct Grant flow or Service account flow.
> >>>>
> >>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel
> >>>> with
> >>>> CRUD methods on UserModel. So when new offline token is generated by
> >>>> Keycloak, some info about current UserSession and ClientSession is
> >>>> persisted on UserModel. This means that offline token can be used to
> >>>> create new access token even if "normal" UserSession and ClientSession
> >>>> are already invalid or logged out.
> >>>>
> >>>> - When refreshing access token with offline token, the auth-server
> >>>> won't
> >>>> send back another refresh token. It will send just accessToken +
> >>>> IDToken. This is to avoid writes to user database for each token
> >>>> refresh.
> >>>>
> >>>> - In account management applications tab, there is new table column
> >>>> "Additional grants" where is shown if client has offline token for
> >>>> user.
> >>>> The click on "Revoke" button will remove offline tokens and granted
> >>>> consents as well - no separate actions for revoke consents and offline
> >>>> tokens.
> >>>>
> >>>>
> >>>> Still TODO:
> >>>> - Properly handle consents (see "Questions" below)
> >>>>
> >>>> - More tests, example, export/import , docs
> >>>>
> >>>> - More things/refactoring based on your feedback
> >>>>
> >>>>
> >>>> Questions:
> >>>> - The specs mentions that consent should be displayed when offline
> >>>> token
> >>>> is requested. See
> >>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
> >>>> Right now, I am not doing that. So when Client has "isConsentRequired"
> >>>> as false, the consent screen is not displayed. Now we also don't have
> >>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
> >>>> keep it like this?
> >>>>
> >>>> - I am thinking about adding new builtin client role "offline_access",
> >>>> which will be created for client when admin enables "offline tokens"
> >>>> switch. It will be used also as default role. This will allow that
> >>>> just
> >>>> some users are allowed to obtain offline-token (those which have this
> >>>> role). The role will be also displayed on consent screen for the
> >>>> clients, which needs consent.
> >>>> But that raises another question. IMO it will be good if role is
> >>>> requested and displayed on consent screen just if offline token is
> >>>> requested, but not when classic refresh token is requested.
> >>>>
> >>>> Hence I was thinking about adding the flag "scopeParamMode" to
> >>>> RoleModel. The value true means that role will be requested and
> >>>> used in
> >>>> accessToken/refreshToken just if scope parameter contains it's value.
> >>>> This will be the setup for "offline_access" role, so it's used just
> >>>> for
> >>>> the offline token requests. Another thing is format of scope parameter
> >>>> with respect to realm roles and application roles. We can use "//" as
> >>>> delimiter, so realm role will have just "my-role" but client role will
> >>>> have "my-client//my-role" . The disadvantage is that for requesting
> >>>> offline_access you will then need to use scope like:
> >>>> "scope=customer-portal//offline_access" as it's client role.
> >>>>
> >>>> WDYT? Any better idea?
> >>>>
> >>>> Marek
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >>
> >
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150922/1054909c/attachment-0001.html 

From bburke at redhat.com  Tue Sep 22 08:45:39 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Sep 2015 08:45:39 -0400
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <5600F8D7.4040902@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
	<5600F8D7.4040902@redhat.com>
Message-ID: <56014D73.8060304@redhat.com>

I've wanted to switch to a URI for userId:  {id}@{provider} or 
{provider}:{id}.  {id} would be something unique and that makes sense 
for the fed provider.  Old user ids would just assume that they are in 
local storage.

I still think this should be a separate datastore from users.

On 9/22/2015 2:44 AM, Marek Posolda wrote:
> Ok, I can add the methods to UserProvider instead of UserModel and add
> the UserModel as argument to CRUD methods. So it will use same pattern
> like we have for FederatedIdentityModel .
>
> Still, I would like to use references to token storage by User ID, not
> by username. I wonder that when we later use in-memory UserModels backed
> fully by UserFederationProvider, we will need to ensure that User ID
> will be always same for same federated user "john" .  Like for example
> instead of random UUID, the user ID will be generated from hash of
> FederationProviderId+LDAPId . This will ensure that references to other
> places by User ID will still work.
>
> Marek
>
> On 21/09/15 17:55, Bill Burke wrote:
>>
>>
>> On 9/21/2015 9:04 AM, Marek Posolda wrote:
>>>> You have to move this out of UserModel. UserModel may be backed 99% by
>>>> a UserFederationProvider.  In the near future, UserFederationProvider
>>>> users may all sit in memory for only the lifetime of the session.
>>>>
>>>>
>>> Does it makes sense to issue offline token for the users, which are
>>> valid just for the lifetime of the session?
>>>
>>
>> The users aren't temporary, they are just stored in LDAP or something.
>> So yes, it does make sense to issue offline tokens. The offline token
>> storage will just need to store a reference to the user so it can
>> rebuild it through our SPIs if needed.
>>
>

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

From pslegr at redhat.com  Tue Sep 22 08:59:39 2015
From: pslegr at redhat.com (pslegr)
Date: Tue, 22 Sep 2015 14:59:39 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com>
References: <55FFD698.7040100@redhat.com>	<55FFDBCE.4070201@redhat.com>	<55FFF7C3.70806@redhat.com>	<560002FC.2040503@redhat.com>	<5600FE5C.8030800@redhat.com>
	<CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com>
Message-ID: <560150BB.7030004@redhat.com>



On 22.9.2015 09:16, Stian Thorgersen wrote:
>
>
> On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 21/09/15 15:15, pslegr wrote:
>     >
>     >
>     > On 21.9.2015 14:27, Marek Posolda wrote:
>     >> On 21/09/15 12:28, pslegr wrote:
>     >>>
>     >>>
>     >>> On 21.9.2015 12:06, Marek Posolda wrote:
>     >>>> I've sent the PR . Right now it works like this:
>     >>>>
>     >>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>     >>>> retrieve offline tokens just if flag is enabled
>     >>>>
>     >>>> - Offline token is classic refresh token with 2 differences.
>     It has
>     >>>> type
>     >>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for
>     >>>> offline
>     >>>> token, the expiration value is 0, so it never expires.
>     >>> Just an idea.
>     >>> Have you ever thought, in terms of expiration, not only
>     >>> about refresh vs. never expires
>     >>> BUT also about defining the exact time of expiration ?
>     >>> for example validity for 1 Month, 1 year, 3 years ... etc.
>     >>> This would offer the possibility on the fly generate the so
>     called;
>     >>> "offline license tokens", which are
>     >>> then used for different lifetime periods.
>     >>> IMHO this might extend the usage for Keycloak into the license
>     >>> providers field ;)
>     >> We have already some support for required action "Terms &
>     Condition"
>     >> at the keycloak server level. AFAIK user needs to confirm "Terms &
>     >> Conditions" page when he has that required action set on him. You
>     >> have also possibility to customize the content of the page.
>     >>
>     >>  I wonder if this required action can be used for time based
>     licences
>     >> as well? Like for example you will have possibility to
>     configure that
>     >> validity of licence is 1 year, so after 1 year will be required
>     >> action added to user automatically and he will need to confirm it
>     >> again during login?
>     > Well, I had more the offline licensing on my mind. In such situation
>     > you would not ever communicate with the server from client.
>     >>
>     >> The possibility you mentioned is about handling licence
>     agreement at
>     >> the client level by the application itself if I understand
>     correctly?
>     >> So application will save offline token and the token is valid for 3
>     >> years, so application will display the licence screen when it
>     >> notifies that offline token is expired. Am I understand correctly?
>     > Yes, I think you pretty much got it
>     > The thing is, once you imagine the offline license generation, then
>     > this is a once time action, at the beginning. The license
>     provider who
>     > owns private keys makes that once and provide to the clients.
>     > The token is then verified for offline actions and once expired must
>     > be replaced by license provide again.
>     Interesting usecase. Looks there are more possibilities how to
>     support this.
>
>     1) We can add timeout for offline tokens (will be NEVER by default, so
>     it will never expire).
>     2) We can add the protocol mappers extension points for refresh tokens
>     as well (currently we use protocol mappers just for generation of
>     access
>     tokens and ID tokens). This will allow even more flexibility in
>     generating refresh/offline tokens and use different timeouts for
>     different clients etc.
>     3) Don't do anything directly in Keycloak, but let application handle
>     this. When you receive offline token from Keycloak, you will save the
>     offline token to your DB together with the time when offline token was
>     received (you will handle the time by yourself, not from expiration
>     field of offline token). Then your DB contains the time, so you can
>     handle it in your application that after 3 years is token not valid
>     anymore and the licence needs to be confirmed again.
>
>
> Not sure I fully understand what the use-case is around this, but it 
> seems like what's being proposed is a complete misuse of offline tokens.
>
> I'm assuming by licensing you mean something along the lines of a 
> software license where a user has paid for a 1 year license for a 
> particular application? If so offline tokens are not the solution as 
> something like that should work with regular tokens as well. There's 
> also a lot of other things to consider with regards to a license. You 
> need a mechanism to add the license in the first place (a signed token 
> perhaps associated with the users account), a way to renew the license 
> (pay mechanism), etc.. It's not something we've had any demand for, 
> nor do I really think it's something an authentication server should do.
Yes you are correct, this is a SW license related thing.
I must admit that AAA servers normally don't have such things and the 
questions is if they really should.
I can't remember seeing out there something offering complex solutions 
for online & offline licensing. (I mean unpaid, being opensource)
Once providing an offline "permanent" tokens, this smells more the SW 
license way and that was the reasoning behind my questions ;)
I don't say this is a use-case for Keycloak directly, but you do have 
already lot's of code there, which can be reused or bent to work for SW 
licenses as well :)
cheers
Pavel

>
>     >>
>     >> IMO extend the current Terms & Conditions action for expiration
>     after
>     >> some time looks better to me, as you won't need to do any more
>     coding
>     >> in your application. Just set the timeout for Terms&Conditions (or
>     >> licence ) action at keycloak admin console.
>     >
>     > Is the "Terms & Conditions action" something which works offline  ?
>     No. It's displayed by Keycloak server, so it requires Keycloak
>     server to
>     be up and running.
>
>     Marek
>     >
>     > Pavel
>     >>
>     >> Marek
>     >>>>
>     >>>> - Offline token is generated by auth-server when client sends
>     >>>> "scope=offline_access" . It's supported for classic browser
>     flow, but
>     >>>> also for Direct Grant flow or Service account flow.
>     >>>>
>     >>>> - I've added OfflineClientSessionModel and
>     OfflineUserSessionModel
>     >>>> with
>     >>>> CRUD methods on UserModel. So when new offline token is
>     generated by
>     >>>> Keycloak, some info about current UserSession and
>     ClientSession is
>     >>>> persisted on UserModel. This means that offline token can be
>     used to
>     >>>> create new access token even if "normal" UserSession and
>     ClientSession
>     >>>> are already invalid or logged out.
>     >>>>
>     >>>> - When refreshing access token with offline token, the
>     auth-server
>     >>>> won't
>     >>>> send back another refresh token. It will send just accessToken +
>     >>>> IDToken. This is to avoid writes to user database for each token
>     >>>> refresh.
>     >>>>
>     >>>> - In account management applications tab, there is new table
>     column
>     >>>> "Additional grants" where is shown if client has offline
>     token for
>     >>>> user.
>     >>>> The click on "Revoke" button will remove offline tokens and
>     granted
>     >>>> consents as well - no separate actions for revoke consents
>     and offline
>     >>>> tokens.
>     >>>>
>     >>>>
>     >>>> Still TODO:
>     >>>> - Properly handle consents (see "Questions" below)
>     >>>>
>     >>>> - More tests, example, export/import , docs
>     >>>>
>     >>>> - More things/refactoring based on your feedback
>     >>>>
>     >>>>
>     >>>> Questions:
>     >>>> - The specs mentions that consent should be displayed when
>     offline
>     >>>> token
>     >>>> is requested. See
>     >>>>
>     http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>     >>>> Right now, I am not doing that. So when Client has
>     "isConsentRequired"
>     >>>> as false, the consent screen is not displayed. Now we also
>     don't have
>     >>>> support for "prompt=consent" (not sure if we need this) . Is
>     it ok to
>     >>>> keep it like this?
>     >>>>
>     >>>> - I am thinking about adding new builtin client role
>     "offline_access",
>     >>>> which will be created for client when admin enables "offline
>     tokens"
>     >>>> switch. It will be used also as default role. This will allow
>     that
>     >>>> just
>     >>>> some users are allowed to obtain offline-token (those which
>     have this
>     >>>> role). The role will be also displayed on consent screen for the
>     >>>> clients, which needs consent.
>     >>>> But that raises another question. IMO it will be good if role is
>     >>>> requested and displayed on consent screen just if offline
>     token is
>     >>>> requested, but not when classic refresh token is requested.
>     >>>>
>     >>>> Hence I was thinking about adding the flag "scopeParamMode" to
>     >>>> RoleModel. The value true means that role will be requested and
>     >>>> used in
>     >>>> accessToken/refreshToken just if scope parameter contains
>     it's value.
>     >>>> This will be the setup for "offline_access" role, so it's
>     used just
>     >>>> for
>     >>>> the offline token requests. Another thing is format of scope
>     parameter
>     >>>> with respect to realm roles and application roles. We can use
>     "//" as
>     >>>> delimiter, so realm role will have just "my-role" but client
>     role will
>     >>>> have "my-client//my-role" . The disadvantage is that for
>     requesting
>     >>>> offline_access you will then need to use scope like:
>     >>>> "scope=customer-portal//offline_access" as it's client role.
>     >>>>
>     >>>> WDYT? Any better idea?
>     >>>>
>     >>>> 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
>     >>>
>     >>
>     >
>
>     _______________________________________________
>     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/20150922/e8e91259/attachment-0001.html 

From sthorger at redhat.com  Tue Sep 22 09:03:42 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Tue, 22 Sep 2015 15:03:42 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <560150BB.7030004@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFDBCE.4070201@redhat.com>
	<55FFF7C3.70806@redhat.com> <560002FC.2040503@redhat.com>
	<5600FE5C.8030800@redhat.com>
	<CAJgngAdQXU96-VKEGLi50uM8GX=h1PE_FoTsZSzcWf7uteGB_Q@mail.gmail.com>
	<560150BB.7030004@redhat.com>
Message-ID: <CAJgngAeC9BQ8OHnTNi1cbHZJoNWggT+FV1FXdhXXjk_y53EtHA@mail.gmail.com>

I would say in this case it's more about bending than reusing ;)

On 22 September 2015 at 14:59, pslegr <pslegr at redhat.com> wrote:

>
>
> On 22.9.2015 09:16, Stian Thorgersen wrote:
>
>
>
> On 22 September 2015 at 09:08, Marek Posolda <mposolda at redhat.com> wrote:
>
>> On 21/09/15 15:15, pslegr wrote:
>> >
>> >
>> > On 21.9.2015 14:27, Marek Posolda wrote:
>> >> On 21/09/15 12:28, pslegr wrote:
>> >>>
>> >>>
>> >>> On 21.9.2015 12:06, Marek Posolda wrote:
>> >>>> I've sent the PR . Right now it works like this:
>> >>>>
>> >>>> - ClientModel has flag "offlineTokensEnabled" . It's possible to
>> >>>> retrieve offline tokens just if flag is enabled
>> >>>>
>> >>>> - Offline token is classic refresh token with 2 differences. It has
>> >>>> type
>> >>>> "OFFLINE" when normal refresh token has type "REFRESH" . And for
>> >>>> offline
>> >>>> token, the expiration value is 0, so it never expires.
>> >>> Just an idea.
>> >>> Have you ever thought, in terms of expiration, not only
>> >>> about refresh vs. never expires
>> >>> BUT also about defining the exact time of expiration ?
>> >>> for example validity for 1 Month, 1 year, 3 years ... etc.
>> >>> This would offer the possibility on the fly generate the so called;
>> >>> "offline license tokens", which are
>> >>> then used for different lifetime periods.
>> >>> IMHO this might extend the usage for Keycloak into the license
>> >>> providers field ;)
>> >> We have already some support for required action "Terms & Condition"
>> >> at the keycloak server level. AFAIK user needs to confirm "Terms &
>> >> Conditions" page when he has that required action set on him. You
>> >> have also possibility to customize the content of the page.
>> >>
>> >>  I wonder if this required action can be used for time based licences
>> >> as well? Like for example you will have possibility to configure that
>> >> validity of licence is 1 year, so after 1 year will be required
>> >> action added to user automatically and he will need to confirm it
>> >> again during login?
>> > Well, I had more the offline licensing on my mind. In such situation
>> > you would not ever communicate with the server from client.
>> >>
>> >> The possibility you mentioned is about handling licence agreement at
>> >> the client level by the application itself if I understand correctly?
>> >> So application will save offline token and the token is valid for 3
>> >> years, so application will display the licence screen when it
>> >> notifies that offline token is expired. Am I understand correctly?
>> > Yes, I think you pretty much got it
>> > The thing is, once you imagine the offline license generation, then
>> > this is a once time action, at the beginning. The license provider who
>> > owns private keys makes that once and provide to the clients.
>> > The token is then verified for offline actions and once expired must
>> > be replaced by license provide again.
>> Interesting usecase. Looks there are more possibilities how to support
>> this.
>>
>> 1) We can add timeout for offline tokens (will be NEVER by default, so
>> it will never expire).
>> 2) We can add the protocol mappers extension points for refresh tokens
>> as well (currently we use protocol mappers just for generation of access
>> tokens and ID tokens). This will allow even more flexibility in
>> generating refresh/offline tokens and use different timeouts for
>> different clients etc.
>> 3) Don't do anything directly in Keycloak, but let application handle
>> this. When you receive offline token from Keycloak, you will save the
>> offline token to your DB together with the time when offline token was
>> received (you will handle the time by yourself, not from expiration
>> field of offline token). Then your DB contains the time, so you can
>> handle it in your application that after 3 years is token not valid
>> anymore and the licence needs to be confirmed again.
>>
>
> Not sure I fully understand what the use-case is around this, but it seems
> like what's being proposed is a complete misuse of offline tokens.
>
> I'm assuming by licensing you mean something along the lines of a software
> license where a user has paid for a 1 year license for a particular
> application? If so offline tokens are not the solution as something like
> that should work with regular tokens as well. There's also a lot of other
> things to consider with regards to a license. You need a mechanism to add
> the license in the first place (a signed token perhaps associated with the
> users account), a way to renew the license (pay mechanism), etc.. It's not
> something we've had any demand for, nor do I really think it's something an
> authentication server should do.
>
> Yes you are correct, this is a SW license related thing.
> I must admit that AAA servers normally don't have such things and the
> questions is if they really should.
> I can't remember seeing out there something offering complex solutions for
> online & offline licensing. (I mean unpaid, being opensource)
> Once providing an offline "permanent" tokens, this smells more the SW
> license way and that was the reasoning behind my questions ;)
> I don't say this is a use-case for Keycloak directly, but you do have
> already lot's of code there, which can be reused or bent to work for SW
> licenses as well :)
> cheers
> Pavel
>
>
>
>
>>
>> >>
>> >> IMO extend the current Terms & Conditions action for expiration after
>> >> some time looks better to me, as you won't need to do any more coding
>> >> in your application. Just set the timeout for Terms&Conditions (or
>> >> licence ) action at keycloak admin console.
>> >
>> > Is the "Terms & Conditions action" something which works offline  ?
>> No. It's displayed by Keycloak server, so it requires Keycloak server to
>> be up and running.
>>
>> Marek
>> >
>> > Pavel
>> >>
>> >> Marek
>> >>>>
>> >>>> - Offline token is generated by auth-server when client sends
>> >>>> "scope=offline_access" . It's supported for classic browser flow, but
>> >>>> also for Direct Grant flow or Service account flow.
>> >>>>
>> >>>> - I've added OfflineClientSessionModel and OfflineUserSessionModel
>> >>>> with
>> >>>> CRUD methods on UserModel. So when new offline token is generated by
>> >>>> Keycloak, some info about current UserSession and ClientSession is
>> >>>> persisted on UserModel. This means that offline token can be used to
>> >>>> create new access token even if "normal" UserSession and
>> ClientSession
>> >>>> are already invalid or logged out.
>> >>>>
>> >>>> - When refreshing access token with offline token, the auth-server
>> >>>> won't
>> >>>> send back another refresh token. It will send just accessToken +
>> >>>> IDToken. This is to avoid writes to user database for each token
>> >>>> refresh.
>> >>>>
>> >>>> - In account management applications tab, there is new table column
>> >>>> "Additional grants" where is shown if client has offline token for
>> >>>> user.
>> >>>> The click on "Revoke" button will remove offline tokens and granted
>> >>>> consents as well - no separate actions for revoke consents and
>> offline
>> >>>> tokens.
>> >>>>
>> >>>>
>> >>>> Still TODO:
>> >>>> - Properly handle consents (see "Questions" below)
>> >>>>
>> >>>> - More tests, example, export/import , docs
>> >>>>
>> >>>> - More things/refactoring based on your feedback
>> >>>>
>> >>>>
>> >>>> Questions:
>> >>>> - The specs mentions that consent should be displayed when offline
>> >>>> token
>> >>>> is requested. See
>> >>>> http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess .
>> >>>> Right now, I am not doing that. So when Client has
>> "isConsentRequired"
>> >>>> as false, the consent screen is not displayed. Now we also don't have
>> >>>> support for "prompt=consent" (not sure if we need this) . Is it ok to
>> >>>> keep it like this?
>> >>>>
>> >>>> - I am thinking about adding new builtin client role
>> "offline_access",
>> >>>> which will be created for client when admin enables "offline tokens"
>> >>>> switch. It will be used also as default role. This will allow that
>> >>>> just
>> >>>> some users are allowed to obtain offline-token (those which have this
>> >>>> role). The role will be also displayed on consent screen for the
>> >>>> clients, which needs consent.
>> >>>> But that raises another question. IMO it will be good if role is
>> >>>> requested and displayed on consent screen just if offline token is
>> >>>> requested, but not when classic refresh token is requested.
>> >>>>
>> >>>> Hence I was thinking about adding the flag "scopeParamMode" to
>> >>>> RoleModel. The value true means that role will be requested and
>> >>>> used in
>> >>>> accessToken/refreshToken just if scope parameter contains it's value.
>> >>>> This will be the setup for "offline_access" role, so it's used just
>> >>>> for
>> >>>> the offline token requests. Another thing is format of scope
>> parameter
>> >>>> with respect to realm roles and application roles. We can use "//" as
>> >>>> delimiter, so realm role will have just "my-role" but client role
>> will
>> >>>> have "my-client//my-role" . The disadvantage is that for requesting
>> >>>> offline_access you will then need to use scope like:
>> >>>> "scope=customer-portal//offline_access" as it's client role.
>> >>>>
>> >>>> WDYT? Any better idea?
>> >>>>
>> >>>> Marek
>> >>>> _______________________________________________
>> >>>> keycloak-dev mailing list
>> >>>> keycloak-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >>>
>> >>
>> >
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150922/ecdfb640/attachment-0001.html 

From mposolda at redhat.com  Tue Sep 22 09:46:27 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Sep 2015 15:46:27 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <56014D73.8060304@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
	<5600F8D7.4040902@redhat.com> <56014D73.8060304@redhat.com>
Message-ID: <56015BB3.9000809@redhat.com>

Not sure when to save it then? Also I am not sure why offline sessions 
should be more "special" then other UserModel stuff like 
IdentityProvider/Social links, consents or even role mappings?


I personally think that we need more flexibility in chaining of 
UserProvider implementations. That way, the UserFederationProvider will 
delegate to "next" provider in the chain . And the next storage can be 
either:

- persistent - in this case you have chaining like: federation -> JPA

- inMemory - in this case you have chaining like: federation -> inMemory 
-> JPA

The inMemory storage will have flexibility to specify which stuff 
exactly is saved in memory and which stuff should be delegated to "next" 
storage (JPA). In that way, people can specify that for example whole 
UserModel can be saved in memory despite offlineSessions and consents. 
Those are only things, which will be delegated to last "persistent" 
storage in the bottom of the chain.


We should also have possibility to put CacheUserProvider on the top of 
the chain - currently the top provider is always hardcoded to 
UserFederationManager. This is not very performant for the 
UserFederationProviders with "constant" data. For example if you have 
LDAP when data wasn't changed at all during last year, you don't need to 
always call LDAPFederationProvider.validate and constantly ask LDAP if 
user still exists there. So instead you will put cache provider on top 
and UserFederationManager under it.

Marek


On 22/09/15 14:45, Bill Burke wrote:
> I've wanted to switch to a URI for userId:  {id}@{provider} or 
> {provider}:{id}.  {id} would be something unique and that makes sense 
> for the fed provider.  Old user ids would just assume that they are in 
> local storage.
>
> I still think this should be a separate datastore from users.
>
> On 9/22/2015 2:44 AM, Marek Posolda wrote:
>> Ok, I can add the methods to UserProvider instead of UserModel and add
>> the UserModel as argument to CRUD methods. So it will use same pattern
>> like we have for FederatedIdentityModel .
>>
>> Still, I would like to use references to token storage by User ID, not
>> by username. I wonder that when we later use in-memory UserModels backed
>> fully by UserFederationProvider, we will need to ensure that User ID
>> will be always same for same federated user "john" .  Like for example
>> instead of random UUID, the user ID will be generated from hash of
>> FederationProviderId+LDAPId . This will ensure that references to other
>> places by User ID will still work.
>>
>> Marek
>>
>> On 21/09/15 17:55, Bill Burke wrote:
>>>
>>>
>>> On 9/21/2015 9:04 AM, Marek Posolda wrote:
>>>>> You have to move this out of UserModel. UserModel may be backed 
>>>>> 99% by
>>>>> a UserFederationProvider.  In the near future, UserFederationProvider
>>>>> users may all sit in memory for only the lifetime of the session. 
>>>>> getFederated
>>>>>
>>>>>
>>>> Does it makes sense to issue offline token for the users, which are
>>>> valid just for the lifetime of the session?
>>>>
>>>
>>> The users aren't temporary, they are just stored in LDAP or something.
>>> So yes, it does make sense to issue offline tokens. The offline token
>>> storage will just need to store a reference to the user so it can
>>> rebuild it through our SPIs if needed.
>>>
>>
>


From bburke at redhat.com  Wed Sep 23 09:01:11 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Sep 2015 09:01:11 -0400
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <56015BB3.9000809@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
	<5600F8D7.4040902@redhat.com> <56014D73.8060304@redhat.com>
	<56015BB3.9000809@redhat.com>
Message-ID: <5602A297.4010104@redhat.com>

On 9/22/2015 9:46 AM, Marek Posolda wrote:
> Not sure when to save it then? Also I am not sure why offline sessions
> should be more "special" then other UserModel stuff like
> IdentityProvider/Social links, consents or even role mappings?
>
>
> I personally think that we need more flexibility in chaining of
> UserProvider implementations. That way, the UserFederationProvider will
> delegate to "next" provider in the chain . And the next storage can be
> either:
>
> - persistent - in this case you have chaining like: federation -> JPA
>
> - inMemory - in this case you have chaining like: federation -> inMemory
> -> JPA
>

I like the chaining idea.  It should be explored.

> The inMemory storage will have flexibility to specify which stuff
> exactly is saved in memory and which stuff should be delegated to "next"
> storage (JPA). In that way, people can specify that for example whole
> UserModel can be saved in memory despite offlineSessions and consents.
> Those are only things, which will be delegated to last "persistent"
> storage in the bottom of the chain.
>
>
> We should also have possibility to put CacheUserProvider on the top of
> the chain - currently the top provider is always hardcoded to
> UserFederationManager.

UserFederationManager is useful because it can handle common logic.

> This is not very performant for the
> UserFederationProviders with "constant" data. For example if you have
> LDAP when data wasn't changed at all during last year, you don't need to
> always call LDAPFederationProvider.validate and constantly ask LDAP if
> user still exists there. So instead you will put cache provider on top
> and UserFederationManager under it.
>

That's not how it works.  Cache is always queried first, isn't it?

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

From mposolda at redhat.com  Wed Sep 23 09:44:46 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 23 Sep 2015 15:44:46 +0200
Subject: [keycloak-dev] Offline tokens - step 1
In-Reply-To: <5602A297.4010104@redhat.com>
References: <55FFD698.7040100@redhat.com> <55FFFB8F.5020506@redhat.com>
	<5600005E.1020306@redhat.com> <56002859.2010601@redhat.com>
	<5600F8D7.4040902@redhat.com> <56014D73.8060304@redhat.com>
	<56015BB3.9000809@redhat.com> <5602A297.4010104@redhat.com>
Message-ID: <5602ACCE.3010104@redhat.com>

On 23/09/15 15:01, Bill Burke wrote:
>> This is not very performant for the
>> UserFederationProviders with "constant" data. For example if you have
>> LDAP when data wasn't changed at all during last year, you don't need to
>> always call LDAPFederationProvider.validate and constantly ask LDAP if
>> user still exists there. So instead you will put cache provider on top
>> and UserFederationManager under it.
>>
>
> That's not how it works.  Cache is always queried first, isn't it? 
Nope. Now session.users() always returns UserFederationManager and this 
one delegates to cache. So when you have LDAP user john, the invocation 
of session.users().getUserByUsername("john") invokes 
federationProvider.validate and queries LDAP . Not really ideal when 
people have "constant" data in their LDAP or their own federation 
providers based on legacy database with constant data.

I've added per-request cache to UserFederationManager, so you don't have 
15 federationProvider invocations per request, but just 2 or 3. However 
the possibility to chain cache on top will be even better option for 
some environments.

Marek


From gerbermichi at me.com  Thu Sep 24 09:38:48 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 24 Sep 2015 13:38:48 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_KEYCLOAK-1727=28LDAP_with_Kerberos=2C_l?=
 =?utf-8?q?ogin_with_different_user=29_-_PR?=
Message-ID: <217b3280-b486-45b8-8a00-33c050b14ee7@me.com>

Hi all,

I've created a commit for the jira task "LDAP with Kerberos, login with different user"?KEYCLOAK-1727.

https://github.com/gerbermichi/keycloak/commit/c0a4b5ccb8277ffda08846d36c65458dbb1c8bfc

Is this commit ok and can I create a PR for that?

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

From sthorger at redhat.com  Thu Sep 24 09:42:44 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Thu, 24 Sep 2015 15:42:44 +0200
Subject: [keycloak-dev] KEYCLOAK-1727(LDAP with Kerberos,
 login with different user) - PR
In-Reply-To: <217b3280-b486-45b8-8a00-33c050b14ee7@me.com>
References: <217b3280-b486-45b8-8a00-33c050b14ee7@me.com>
Message-ID: <CAJgngAemC971O30P-5LW+8xDa_2wshzy1u+0Zps24O3uqhtcng@mail.gmail.com>

Does that not basically let an app skip all authenticators to login a user
without authentication?

On 24 September 2015 at 15:38, Michael Gerber <gerbermichi at me.com> wrote:

> Hi all,
>
> I've created a commit for the jira task "LDAP with Kerberos, login with
> different user" KEYCLOAK-1727.
>
>
> https://github.com/gerbermichi/keycloak/commit/c0a4b5ccb8277ffda08846d36c65458dbb1c8bfc
>
> Is this commit ok and can I create a PR for that?
>
> Michael
>
> _______________________________________________
> 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/20150924/fa25d610/attachment.html 

From gerbermichi at me.com  Thu Sep 24 10:42:09 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 24 Sep 2015 14:42:09 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__KEYCLOAK-1727=28LDAP_with_Kerber?=
 =?utf-8?q?os=2C_login_with_different_user=29_-_PR?=
Message-ID: <83b04684-e4fd-4dd1-9410-c741cba672d6@me.com>

I changed the behaviour, so you can not skip required authenticators.?
https://github.com/gerbermichi/keycloak/commit/b666ddcb0009305b074ca8c6c1408cd0d33479ce

But I am not sure about the?getCategoryRequirementFromCurrentFlow method in the AuthenticationProcessor class, because I can not find any usages of this method.

Am 24. September 2015 um 15:42 schrieb Stian Thorgersen <sthorger at redhat.com>:

Does that not basically let an app skip all authenticators to login a user without authentication?

On 24 September 2015 at 15:38, Michael Gerber <gerbermichi at me.com> wrote:
Hi all,

I've created a commit for the jira task "LDAP with Kerberos, login with different user"?KEYCLOAK-1727.

https://github.com/gerbermichi/keycloak/commit/c0a4b5ccb8277ffda08846d36c65458dbb1c8bfc

Is this commit ok and can I create a PR for that?

Michael

_______________________________________________
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/20150924/c7c38e06/attachment.html 

From bburke at redhat.com  Thu Sep 24 14:22:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Sep 2015 14:22:55 -0400
Subject: [keycloak-dev] travis build failing
Message-ID: <56043F7F.4000600@redhat.com>

Travis build is failing in the QE arquillian tests as there is a new 
adapter module.  The base tests pass.  So, I merged.  QE can figure out 
what's up.


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

From bburke at redhat.com  Thu Sep 24 15:06:24 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Sep 2015 15:06:24 -0400
Subject: [keycloak-dev] dba's will hate liquibase?
In-Reply-To: <CAFdq00HB1b7AYytSJ4VKJcFm6SL-NzhRDVX1E8rs8Qa5Cmeg2A@mail.gmail.com>
References: <CAFdq00HB1b7AYytSJ4VKJcFm6SL-NzhRDVX1E8rs8Qa5Cmeg2A@mail.gmail.com>
Message-ID: <560449B0.8060800@redhat.com>

An interesting suggestion from a user

On 9/24/2015 2:58 PM, Walker, Charles wrote:
> * move away from liquibase to manage the database schema.  it's a nice
> tool but i haven't ran into many dba's that allow an application to
> "alter" the database.  that meant i just had to go figure out another
> technology just to tease the sql out of it

I'm not sure how we could move away from liquibase.  We would have to 
provide a set of SQL scripts (cross-platform too) that would have to be 
run on your database to upgrade keycloak.  Then there is the Java-based 
migrators that run after this to message the data with any new 
transformations.



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

From srossillo at smartling.com  Thu Sep 24 15:35:20 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 24 Sep 2015 15:35:20 -0400
Subject: [keycloak-dev] dba's will hate liquibase?
In-Reply-To: <560449B0.8060800@redhat.com>
References: <CAFdq00HB1b7AYytSJ4VKJcFm6SL-NzhRDVX1E8rs8Qa5Cmeg2A@mail.gmail.com>
	<560449B0.8060800@redhat.com>
Message-ID: <53A1A145-FC2E-49E3-A99A-AAF74ACC2BA6@smartling.com>

DBAs don?t like applications modifying the database schema on startup. They want scripts they can review. It?s a bit silly in some ways and I do not think it?s cause for alarm or to move off Liquibase though. Liquibase really simplifies things a lot and it can generate a SQL script to be applied before application startup: http://www.liquibase.org/documentation/sql_output.html

As long as Keycloak will run the Java migration code if the DB is updated offline, it should be fine.

There should be some documentation on upgrading in the user guide. It would be worth documenting the correct way to upgrade, especially if you?re running a cluster or multiple standalone servers sharing a database. I am pretty sure you can?t do a rolling upgrade but someone may try it. ;)

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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Sep 24, 2015, at 3:06 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> An interesting suggestion from a user
> 
> On 9/24/2015 2:58 PM, Walker, Charles wrote:
>> * move away from liquibase to manage the database schema.  it's a nice
>> tool but i haven't ran into many dba's that allow an application to
>> "alter" the database.  that meant i just had to go figure out another
>> technology just to tease the sql out of it
> 
> I'm not sure how we could move away from liquibase.  We would have to 
> provide a set of SQL scripts (cross-platform too) that would have to be 
> run on your database to upgrade keycloak.  Then there is the Java-based 
> migrators that run after this to message the data with any new 
> transformations.
> 
> 
> 
> -- 
> 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/20150924/7736ec1d/attachment.html 

From tkyjovsk at redhat.com  Thu Sep 24 16:02:29 2015
From: tkyjovsk at redhat.com (Tomas Kyjovsky)
Date: Thu, 24 Sep 2015 16:02:29 -0400 (EDT)
Subject: [keycloak-dev] travis build failing
In-Reply-To: <56043F7F.4000600@redhat.com>
References: <56043F7F.4000600@redhat.com>
Message-ID: <1025200354.33471502.1443124949656.JavaMail.zimbra@redhat.com>

Looks like a missing dependency caused by the adapters refactoring.
Should be fixed by https://github.com/keycloak/keycloak/pull/1642

Thanks for the heads up!
Tomas

----- Original Message -----
> Travis build is failing in the QE arquillian tests as there is a new
> adapter module.  The base tests pass.  So, I merged.  QE can figure out
> what's up.
> 
> 
> --
> 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 cwalker at sumglobal.com  Thu Sep 24 16:04:42 2015
From: cwalker at sumglobal.com (Walker, Charles)
Date: Thu, 24 Sep 2015 16:04:42 -0400
Subject: [keycloak-dev] dba's will hate liquibase?
In-Reply-To: <53A1A145-FC2E-49E3-A99A-AAF74ACC2BA6@smartling.com>
References: <CAFdq00HB1b7AYytSJ4VKJcFm6SL-NzhRDVX1E8rs8Qa5Cmeg2A@mail.gmail.com>
	<560449B0.8060800@redhat.com>
	<53A1A145-FC2E-49E3-A99A-AAF74ACC2BA6@smartling.com>
Message-ID: <CAFdq00GDwq6h7pd6fqP71KQf3avjeomKUciCBDLcUyww7MEiow@mail.gmail.com>

It's not really all that silly and from a security standpoint granting a
user that normally only does CRUD requests the ability to alter the
structure of you database is probably not a good idea.

But you're right, there's probably no reason to migrate away from
liquibase.  If update sql code could be provided or scripts to generate the
changes, that would be fine.

And I currently use the sql_output functionality to generate the sql
changelogs but it's a hassle, you have to:

   - download the right version of the source code (or clone the master and
   checkout the proper tag)
   - modify the pom file in the jpa liquibase code to add the dependencies
   for your database (cause i know you're not using h2)
   - figure out why the "updateSql" task isn't working and update the pom
   file again with the fix

I used it to upgrade from 1.3 -> 1.4 but 1.4 -> 1.5 is broke.

On Thu, Sep 24, 2015 at 3:35 PM, Scott Rossillo <srossillo at smartling.com>
wrote:

> DBAs don?t like applications modifying the database schema on startup.
> They want scripts they can review. It?s a bit silly in some ways and I do
> not think it?s cause for alarm or to move off Liquibase though. Liquibase
> really simplifies things a lot and it can generate a SQL script to be
> applied before application startup:
> http://www.liquibase.org/documentation/sql_output.html
>
> As long as Keycloak will run the Java migration code if the DB is updated
> offline, it should be fine.
>
> There should be some documentation on upgrading in the user guide. It
> would be worth documenting the correct way to upgrade, especially if you?re
> running a cluster or multiple standalone servers sharing a database. I am
> pretty sure you can?t do a rolling upgrade but someone may try it. ;)
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <http://www.sigstr.com/>
>
> On Sep 24, 2015, at 3:06 PM, Bill Burke <bburke at redhat.com> wrote:
>
> An interesting suggestion from a user
>
> On 9/24/2015 2:58 PM, Walker, Charles wrote:
>
> * move away from liquibase to manage the database schema.  it's a nice
> tool but i haven't ran into many dba's that allow an application to
> "alter" the database.  that meant i just had to go figure out another
> technology just to tease the sql out of it
>
>
> I'm not sure how we could move away from liquibase.  We would have to
> provide a set of SQL scripts (cross-platform too) that would have to be
> run on your database to upgrade keycloak.  Then there is the Java-based
> migrators that run after this to message the data with any new
> transformations.
>
>
>
> --
> 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/20150924/77cfe7df/attachment.html 

From sthorger at redhat.com  Fri Sep 25 00:09:57 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 25 Sep 2015 06:09:57 +0200
Subject: [keycloak-dev] dba's will hate liquibase?
In-Reply-To: <CAFdq00GDwq6h7pd6fqP71KQf3avjeomKUciCBDLcUyww7MEiow@mail.gmail.com>
References: <CAFdq00HB1b7AYytSJ4VKJcFm6SL-NzhRDVX1E8rs8Qa5Cmeg2A@mail.gmail.com>
	<560449B0.8060800@redhat.com>
	<53A1A145-FC2E-49E3-A99A-AAF74ACC2BA6@smartling.com>
	<CAFdq00GDwq6h7pd6fqP71KQf3avjeomKUciCBDLcUyww7MEiow@mail.gmail.com>
Message-ID: <CAJgngAdv=cEyWMxLtwPn9sfr8zvpH8WeMv__pfPAe7vMnqrSLg@mail.gmail.com>

We're definitively not removing Liquibase. Alternative is to manually write
SQL migration scripts for all supported databases. That's not happening as
the process is error prone and time consuming enough as it is.

I'd like to drastically change the schema so it doesn't need to change as
frequently. Either by:
* Store a whole realm as a json blob in a binary column
* Use generic tables with types and attributes (realm has attributes for
config options not individual columns)

Finally when schema changes we can make it simpler to use Liquibase to
create the upgrade script. We could add an 'manual' option to
'databaseSchema'. If set to this and the schema has changed Keycloak would
write the migration sql file (using Liquibase), then stop.

Rolling upgrades (and even live upgrades) are probably never going to
happen when the database schema changes. Changing the schema so it doesn't
change as frequently would at least make it possible to add that in the
future.

On 24 September 2015 at 22:04, Walker, Charles <cwalker at sumglobal.com>
wrote:

> It's not really all that silly and from a security standpoint granting a
> user that normally only does CRUD requests the ability to alter the
> structure of you database is probably not a good idea.
>
> But you're right, there's probably no reason to migrate away from
> liquibase.  If update sql code could be provided or scripts to generate the
> changes, that would be fine.
>
> And I currently use the sql_output functionality to generate the sql
> changelogs but it's a hassle, you have to:
>
>    - download the right version of the source code (or clone the master
>    and checkout the proper tag)
>    - modify the pom file in the jpa liquibase code to add the
>    dependencies for your database (cause i know you're not using h2)
>    - figure out why the "updateSql" task isn't working and update the pom
>    file again with the fix
>
> I used it to upgrade from 1.3 -> 1.4 but 1.4 -> 1.5 is broke.
>
> On Thu, Sep 24, 2015 at 3:35 PM, Scott Rossillo <srossillo at smartling.com>
> wrote:
>
>> DBAs don?t like applications modifying the database schema on startup.
>> They want scripts they can review. It?s a bit silly in some ways and I do
>> not think it?s cause for alarm or to move off Liquibase though. Liquibase
>> really simplifies things a lot and it can generate a SQL script to be
>> applied before application startup:
>> http://www.liquibase.org/documentation/sql_output.html
>>
>> As long as Keycloak will run the Java migration code if the DB is updated
>> offline, it should be fine.
>>
>> There should be some documentation on upgrading in the user guide. It
>> would be worth documenting the correct way to upgrade, especially if you?re
>> running a cluster or multiple standalone servers sharing a database. I am
>> pretty sure you can?t do a rolling upgrade but someone may try it. ;)
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com
>>
>> [image: Latest News + Events]
>> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>
>> On Sep 24, 2015, at 3:06 PM, Bill Burke <bburke at redhat.com> wrote:
>>
>> An interesting suggestion from a user
>>
>> On 9/24/2015 2:58 PM, Walker, Charles wrote:
>>
>> * move away from liquibase to manage the database schema.  it's a nice
>> tool but i haven't ran into many dba's that allow an application to
>> "alter" the database.  that meant i just had to go figure out another
>> technology just to tease the sql out of it
>>
>>
>> I'm not sure how we could move away from liquibase.  We would have to
>> provide a set of SQL scripts (cross-platform too) that would have to be
>> run on your database to upgrade keycloak.  Then there is the Java-based
>> migrators that run after this to message the data with any new
>> transformations.
>>
>>
>>
>> --
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/7cc027ca/attachment-0001.html 

From gerbermichi at me.com  Fri Sep 25 05:00:44 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 25 Sep 2015 09:00:44 +0000 (GMT)
Subject: [keycloak-dev] travis fail
Message-ID: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>

Hi all,

travis fails at my PR but it passes on my branch.
Is there a way to restart travis on a PR or do you have to create a new PR?

best
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/abff26a9/attachment.html 

From giriraj.sharma27 at gmail.com  Fri Sep 25 05:11:36 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Fri, 25 Sep 2015 14:41:36 +0530
Subject: [keycloak-dev] travis fail
In-Reply-To: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
Message-ID: <CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>

Hi,

I too faced such issues. In order to re run travis-ci, I used to make two
additional commits on top of the main commit. The first commit involved a
minor change and the second commit involved revert of first commit. I used
to then squash the last 3 commits into one i.e., restore the repository to
original state. In case, if you try to push again to the upstream after
squashing, travis-ci build will be triggered automatically.

Although this might not be the best possible way, but it's at least a
workaround.

Cheers,



On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com> wrote:

> Hi all,
>
> travis fails at my PR but it passes on my branch.
> Is there a way to restart travis on a PR or do you have to create a new PR?
>
> best
> Michael
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/70a379ad/attachment.html 

From sthorger at redhat.com  Fri Sep 25 05:18:22 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 25 Sep 2015 11:18:22 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
Message-ID: <CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>

We're currently experiencing some unstability in the tests that we are
working on. Don't worry about restarting the tests for failed PRs as I can
take care of that.

On 25 September 2015 at 11:11, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi,
>
> I too faced such issues. In order to re run travis-ci, I used to make two
> additional commits on top of the main commit. The first commit involved a
> minor change and the second commit involved revert of first commit. I used
> to then squash the last 3 commits into one i.e., restore the repository to
> original state. In case, if you try to push again to the upstream after
> squashing, travis-ci build will be triggered automatically.
>
> Although this might not be the best possible way, but it's at least a
> workaround.
>
> Cheers,
>
>
>
> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
> wrote:
>
>> Hi all,
>>
>> travis fails at my PR but it passes on my branch.
>> Is there a way to restart travis on a PR or do you have to create a new
>> PR?
>>
>> best
>> Michael
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
> _______________________________________________
> 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/20150925/67269ac7/attachment.html 

From sthorger at redhat.com  Fri Sep 25 05:19:49 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 25 Sep 2015 11:19:49 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
Message-ID: <CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>

Doing what Giriraj suggest is an uggly hack, so please don't do that. Just
leave the PR and I'll re-start the tests.

On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com> wrote:

> We're currently experiencing some unstability in the tests that we are
> working on. Don't worry about restarting the tests for failed PRs as I can
> take care of that.
>
> On 25 September 2015 at 11:11, Giriraj Sharma <giriraj.sharma27 at gmail.com>
> wrote:
>
>> Hi,
>>
>> I too faced such issues. In order to re run travis-ci, I used to make two
>> additional commits on top of the main commit. The first commit involved a
>> minor change and the second commit involved revert of first commit. I used
>> to then squash the last 3 commits into one i.e., restore the repository to
>> original state. In case, if you try to push again to the upstream after
>> squashing, travis-ci build will be triggered automatically.
>>
>> Although this might not be the best possible way, but it's at least a
>> workaround.
>>
>> Cheers,
>>
>>
>>
>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> travis fails at my PR but it passes on my branch.
>>> Is there a way to restart travis on a PR or do you have to create a new
>>> PR?
>>>
>>> best
>>> Michael
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>> --
>>
>> Giriraj Sharma
>> about.me/girirajsharma
>> <http://about.me/girirajsharma?promo=email_sig>
>>  Giriraj Sharma,
>> Department of Computer Science
>> National Institute of Technology Hamirpur
>> Himachal Pradesh, India 177005
>>
>> _______________________________________________
>> 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/20150925/b2b3989d/attachment-0001.html 

From giriraj.sharma27 at gmail.com  Fri Sep 25 05:22:30 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Fri, 25 Sep 2015 14:52:30 +0530
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
Message-ID: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>

Hi Stian,

Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
behavior with travis-ci. For some simple commits, travis-ci used to fail
for some random test which might have no association with the PR and a
squashed push soon after 4-5 minutes used to result in success.



On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
wrote:

> Doing what Giriraj suggest is an uggly hack, so please don't do that. Just
> leave the PR and I'll re-start the tests.
>
> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> We're currently experiencing some unstability in the tests that we are
>> working on. Don't worry about restarting the tests for failed PRs as I can
>> take care of that.
>>
>> On 25 September 2015 at 11:11, Giriraj Sharma <giriraj.sharma27 at gmail.com
>> > wrote:
>>
>>> Hi,
>>>
>>> I too faced such issues. In order to re run travis-ci, I used to make
>>> two additional commits on top of the main commit. The first commit involved
>>> a minor change and the second commit involved revert of first commit. I
>>> used to then squash the last 3 commits into one i.e., restore the
>>> repository to original state. In case, if you try to push again to the
>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>
>>> Although this might not be the best possible way, but it's at least a
>>> workaround.
>>>
>>> Cheers,
>>>
>>>
>>>
>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> travis fails at my PR but it passes on my branch.
>>>> Is there a way to restart travis on a PR or do you have to create a new
>>>> PR?
>>>>
>>>> best
>>>> Michael
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Giriraj Sharma
>>> about.me/girirajsharma
>>> <http://about.me/girirajsharma?promo=email_sig>
>>>  Giriraj Sharma,
>>> Department of Computer Science
>>> National Institute of Technology Hamirpur
>>> Himachal Pradesh, India 177005
>>>
>>> _______________________________________________
>>> 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
>



-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/d0b786c6/attachment.html 

From mhajas at redhat.com  Fri Sep 25 06:14:58 2015
From: mhajas at redhat.com (Michal Hajas)
Date: Fri, 25 Sep 2015 06:14:58 -0400 (EDT)
Subject: [keycloak-dev] Run keycloak client with annotations
In-Reply-To: <1155628220.21708942.1443175184315.JavaMail.zimbra@redhat.com>
Message-ID: <1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>

Hi,

I tried to run keycloak client with annotations $SecurityDomain, @RolesAllowed etc. ( https://github.com/mhajas/keycloak_annotations )

Maybe It is just my mistake, I am not an expert in RestFul services and EJB, but I tried lot of configurations and always ends up with some error, mostly with:

failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
	at org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.java:45)

I have configured my keycloak adapter correctly according to http://keycloak.github.io/docs/userguide/html/ch08.html#jboss-adapter but I don't know how to configure web.xml. What can be replaced with annotations and what should be preserved.

I tried both relative and un-relative scenario.

So question is what is wrong with my client?

P.S. I think there might be an example with annotation.

From sthorger at redhat.com  Fri Sep 25 07:08:28 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 25 Sep 2015 13:08:28 +0200
Subject: [keycloak-dev] Run keycloak client with annotations
In-Reply-To: <1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>
References: <1155628220.21708942.1443175184315.JavaMail.zimbra@redhat.com>
	<1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>
Message-ID: <CAJgngAcjSdggEJkaOc-YCAqJ0tdGV1S-Na2dDBWUhJwrQvfRBQ@mail.gmail.com>

Did you add the keycloak security domain as described in docs?

On 25 September 2015 at 12:14, Michal Hajas <mhajas at redhat.com> wrote:

> Hi,
>
> I tried to run keycloak client with annotations $SecurityDomain,
> @RolesAllowed etc. ( https://github.com/mhajas/keycloak_annotations )
>
> Maybe It is just my mistake, I am not an expert in RestFul services and
> EJB, but I tried lot of configurations and always ends up with some error,
> mostly with:
>
> failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
>         at
> org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.java:45)
>
> I have configured my keycloak adapter correctly according to
> http://keycloak.github.io/docs/userguide/html/ch08.html#jboss-adapter but
> I don't know how to configure web.xml. What can be replaced with
> annotations and what should be preserved.
>
> I tried both relative and un-relative scenario.
>
> So question is what is wrong with my client?
>
> P.S. I think there might be an example with annotation.
> _______________________________________________
> 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/20150925/cb32a05c/attachment.html 

From mhajas at redhat.com  Fri Sep 25 07:51:17 2015
From: mhajas at redhat.com (Michal Hajas)
Date: Fri, 25 Sep 2015 07:51:17 -0400 (EDT)
Subject: [keycloak-dev] Run keycloak client with annotations
In-Reply-To: <CAJgngAfkor3kzURpLmxSy3-9OJmwtc0yN70r5AYDOTXoD3u+tg@mail.gmail.com>
References: <1155628220.21708942.1443175184315.JavaMail.zimbra@redhat.com>
	<1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>
	<CAJgngAcjSdggEJkaOc-YCAqJ0tdGV1S-Na2dDBWUhJwrQvfRBQ@mail.gmail.com>
	<1628059989.21746289.1443180178894.JavaMail.zimbra@redhat.com>
	<CAJgngAfkor3kzURpLmxSy3-9OJmwtc0yN70r5AYDOTXoD3u+tg@mail.gmail.com>
Message-ID: <1933782213.21755806.1443181877295.JavaMail.zimbra@redhat.com>

Sorry I forgot to write it in first email, yes without annotations It works correctly.

----- Original Message -----
From: "Stian Thorgersen" <sthorger at redhat.com>
To: "Michal Hajas" <mhajas at redhat.com>
Sent: Friday, September 25, 2015 1:45:47 PM
Subject: Re: [keycloak-dev] Run keycloak client with annotations

Can you try without the @RolesAllowed and instead with a security
constraint in web.xml? Just to confirm that the user has the correct roles,
client has correct scope, etc.

On 25 September 2015 at 13:22, Michal Hajas <mhajas at redhat.com> wrote:

> If you mean the configuration in standalone.xml then yes, It's the same
> with demo-dist that have keycloak adapter preconfigured.
>
> I enclosed my standalone.xml from wildfly 9 container.
>
> Michal.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Michal Hajas" <mhajas at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, September 25, 2015 1:08:28 PM
> Subject: Re: [keycloak-dev] Run keycloak client with annotations
>
> Did you add the keycloak security domain as described in docs?
>
> On 25 September 2015 at 12:14, Michal Hajas <mhajas at redhat.com> wrote:
>
> > Hi,
> >
> > I tried to run keycloak client with annotations $SecurityDomain,
> > @RolesAllowed etc. ( https://github.com/mhajas/keycloak_annotations )
> >
> > Maybe It is just my mistake, I am not an expert in RestFul services and
> > EJB, but I tried lot of configurations and always ends up with some
> error,
> > mostly with:
> >
> > failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
> >         at
> >
> org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.java:45)
> >
> > I have configured my keycloak adapter correctly according to
> > http://keycloak.github.io/docs/userguide/html/ch08.html#jboss-adapter
> but
> > I don't know how to configure web.xml. What can be replaced with
> > annotations and what should be preserved.
> >
> > I tried both relative and un-relative scenario.
> >
> > So question is what is wrong with my client?
> >
> > P.S. I think there might be an example with annotation.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>

From bburke at redhat.com  Fri Sep 25 08:39:15 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Sep 2015 08:39:15 -0400
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
Message-ID: <56054073.9090506@redhat.com>

I looked at the log when  checked in.  I think it is because I changed 
some dependencies (added a new adapter jar).  I didn't realize the 
arquillian tests are in master?

On 9/25/2015 5:19 AM, Stian Thorgersen wrote:
> Doing what Giriraj suggest is an uggly hack, so please don't do that.
> Just leave the PR and I'll re-start the tests.
>
> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com
> <mailto:sthorger at redhat.com>> wrote:
>
>     We're currently experiencing some unstability in the tests that we
>     are working on. Don't worry about restarting the tests for failed
>     PRs as I can take care of that.
>
>     On 25 September 2015 at 11:11, Giriraj Sharma
>     <giriraj.sharma27 at gmail.com <mailto:giriraj.sharma27 at gmail.com>> wrote:
>
>         Hi,
>
>         I too faced such issues. In order to re run travis-ci, I used to
>         make two additional commits on top of the main commit. The first
>         commit involved a minor change and the second commit involved
>         revert of first commit. I used to then squash the last 3 commits
>         into one i.e., restore the repository to original state. In
>         case, if you try to push again to the upstream after squashing,
>         travis-ci build will be triggered automatically.
>
>         Although this might not be the best possible way, but it's at
>         least a workaround.
>
>         Cheers,
>
>
>
>         On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber
>         <gerbermichi at me.com <mailto:gerbermichi at me.com>> wrote:
>
>             Hi all,
>
>             travis fails at my PR but it passes on my branch.
>             Is there a way to restart travis on a PR or do you have to
>             create a new PR?
>
>             best
>             Michael
>
>             _______________________________________________
>             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
>
>
>
>
>         --
>         Giriraj Sharma
>         about.me/girirajsharma
>
>         <http://about.me/girirajsharma?promo=email_sig>
>
>         Giriraj Sharma,
>         Department of Computer Science
>         National Institute of Technology Hamirpur
>         Himachal Pradesh, India 177005
>
>         _______________________________________________
>         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 bburke at redhat.com  Fri Sep 25 08:43:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Sep 2015 08:43:07 -0400
Subject: [keycloak-dev] Run keycloak client with annotations
In-Reply-To: <1933782213.21755806.1443181877295.JavaMail.zimbra@redhat.com>
References: <1155628220.21708942.1443175184315.JavaMail.zimbra@redhat.com>
	<1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>
	<CAJgngAcjSdggEJkaOc-YCAqJ0tdGV1S-Na2dDBWUhJwrQvfRBQ@mail.gmail.com>
	<1628059989.21746289.1443180178894.JavaMail.zimbra@redhat.com>
	<CAJgngAfkor3kzURpLmxSy3-9OJmwtc0yN70r5AYDOTXoD3u+tg@mail.gmail.com>
	<1933782213.21755806.1443181877295.JavaMail.zimbra@redhat.com>
Message-ID: <5605415B.9030702@redhat.com>

You have to

1) Define a security constraint in web.xml.  If you don't do this, then 
the keycloak adapter won't be triggered.  (Its the same for regular 
servlet security + Resteasy)

2) Configure the EJB security domain:
<security-domain name="keycloak">
          <authentication>
            <login-module 
code="org.keycloak.adapters.jboss.KeycloakLoginModule"
                          flag="required"/>
           </authentication>
       </security-domain>


On 9/25/2015 7:51 AM, Michal Hajas wrote:
> Sorry I forgot to write it in first email, yes without annotations It works correctly.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Michal Hajas" <mhajas at redhat.com>
> Sent: Friday, September 25, 2015 1:45:47 PM
> Subject: Re: [keycloak-dev] Run keycloak client with annotations
>
> Can you try without the @RolesAllowed and instead with a security
> constraint in web.xml? Just to confirm that the user has the correct roles,
> client has correct scope, etc.
>
> On 25 September 2015 at 13:22, Michal Hajas <mhajas at redhat.com> wrote:
>
>> If you mean the configuration in standalone.xml then yes, It's the same
>> with demo-dist that have keycloak adapter preconfigured.
>>
>> I enclosed my standalone.xml from wildfly 9 container.
>>
>> Michal.
>>
>> ----- Original Message -----
>> From: "Stian Thorgersen" <sthorger at redhat.com>
>> To: "Michal Hajas" <mhajas at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, September 25, 2015 1:08:28 PM
>> Subject: Re: [keycloak-dev] Run keycloak client with annotations
>>
>> Did you add the keycloak security domain as described in docs?
>>
>> On 25 September 2015 at 12:14, Michal Hajas <mhajas at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I tried to run keycloak client with annotations $SecurityDomain,
>>> @RolesAllowed etc. ( https://github.com/mhajas/keycloak_annotations )
>>>
>>> Maybe It is just my mistake, I am not an expert in RestFul services and
>>> EJB, but I tried lot of configurations and always ends up with some
>> error,
>>> mostly with:
>>>
>>> failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
>>>          at
>>>
>> org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.java:45)
>>>
>>> I have configured my keycloak adapter correctly according to
>>> http://keycloak.github.io/docs/userguide/html/ch08.html#jboss-adapter
>> but
>>> I don't know how to configure web.xml. What can be replaced with
>>> annotations and what should be preserved.
>>>
>>> I tried both relative and un-relative scenario.
>>>
>>> So question is what is wrong with my client?
>>>
>>> P.S. I think there might be an example with annotation.
>>> _______________________________________________
>>> 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 mhajas at redhat.com  Fri Sep 25 09:09:36 2015
From: mhajas at redhat.com (Michal Hajas)
Date: Fri, 25 Sep 2015 09:09:36 -0400 (EDT)
Subject: [keycloak-dev] Run keycloak client with annotations
In-Reply-To: <5605415B.9030702@redhat.com>
References: <1155628220.21708942.1443175184315.JavaMail.zimbra@redhat.com>
	<1809322832.21712907.1443176098261.JavaMail.zimbra@redhat.com>
	<CAJgngAcjSdggEJkaOc-YCAqJ0tdGV1S-Na2dDBWUhJwrQvfRBQ@mail.gmail.com>
	<1628059989.21746289.1443180178894.JavaMail.zimbra@redhat.com>
	<CAJgngAfkor3kzURpLmxSy3-9OJmwtc0yN70r5AYDOTXoD3u+tg@mail.gmail.com>
	<1933782213.21755806.1443181877295.JavaMail.zimbra@redhat.com>
	<5605415B.9030702@redhat.com>
Message-ID: <544001009.21805877.1443186576280.JavaMail.zimbra@redhat.com>

Ok now It is working https://github.com/mhajas/keycloak_annotations/commit/a3916bdf5eaeb8a7ae62124b882ad3e0ec6ee200 , but isn't there possibility to use annotation without security constraint and login-config/auth-method in web.xml? 

I thought that annotation @SecurityDomain("keycloak") triggers keycloak adapter. Now It is working without @SecurityDomain and even without declaring roles, and works correctly because I have to have keycloak_admin role to access page, is it correct?
 
----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, September 25, 2015 2:43:07 PM
Subject: Re: [keycloak-dev] Run keycloak client with annotations

You have to

1) Define a security constraint in web.xml.  If you don't do this, then 
the keycloak adapter won't be triggered.  (Its the same for regular 
servlet security + Resteasy)

2) Configure the EJB security domain:
<security-domain name="keycloak">
          <authentication>
            <login-module 
code="org.keycloak.adapters.jboss.KeycloakLoginModule"
                          flag="required"/>
           </authentication>
       </security-domain>


On 9/25/2015 7:51 AM, Michal Hajas wrote:
> Sorry I forgot to write it in first email, yes without annotations It works correctly.
>
> ----- Original Message -----
> From: "Stian Thorgersen" <sthorger at redhat.com>
> To: "Michal Hajas" <mhajas at redhat.com>
> Sent: Friday, September 25, 2015 1:45:47 PM
> Subject: Re: [keycloak-dev] Run keycloak client with annotations
>
> Can you try without the @RolesAllowed and instead with a security
> constraint in web.xml? Just to confirm that the user has the correct roles,
> client has correct scope, etc.
>
> On 25 September 2015 at 13:22, Michal Hajas <mhajas at redhat.com> wrote:
>
>> If you mean the configuration in standalone.xml then yes, It's the same
>> with demo-dist that have keycloak adapter preconfigured.
>>
>> I enclosed my standalone.xml from wildfly 9 container.
>>
>> Michal.
>>
>> ----- Original Message -----
>> From: "Stian Thorgersen" <sthorger at redhat.com>
>> To: "Michal Hajas" <mhajas at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, September 25, 2015 1:08:28 PM
>> Subject: Re: [keycloak-dev] Run keycloak client with annotations
>>
>> Did you add the keycloak security domain as described in docs?
>>
>> On 25 September 2015 at 12:14, Michal Hajas <mhajas at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> I tried to run keycloak client with annotations $SecurityDomain,
>>> @RolesAllowed etc. ( https://github.com/mhajas/keycloak_annotations )
>>>
>>> Maybe It is just my mistake, I am not an expert in RestFul services and
>>> EJB, but I tried lot of configurations and always ends up with some
>> error,
>>> mostly with:
>>>
>>> failed to execute: javax.ws.rs.ForbiddenException: HTTP 403 Forbidden
>>>          at
>>>
>> org.jboss.resteasy.plugins.interceptors.RoleBasedSecurityFilter.filter(RoleBasedSecurityFilter.java:45)
>>>
>>> I have configured my keycloak adapter correctly according to
>>> http://keycloak.github.io/docs/userguide/html/ch08.html#jboss-adapter
>> but
>>> I don't know how to configure web.xml. What can be replaced with
>>> annotations and what should be preserved.
>>>
>>> I tried both relative and un-relative scenario.
>>>
>>> So question is what is wrong with my client?
>>>
>>> P.S. I think there might be an example with annotation.
>>> _______________________________________________
>>> 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 thomas.raehalme at aitiofinland.com  Fri Sep 25 09:21:51 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Fri, 25 Sep 2015 16:21:51 +0300
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
Message-ID: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>

Hi!

We have written a custom subclass of
org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable
custom location for keycloak.json. The use of custom location is optional
and defaults to the standard /WEB-INF/keycloak.json.

Our use case is that for developers we have a default keycloak.json
included in the application. In production, however, we override the
default by using a file that is external to the application. The location
of the file is specified in JNDI settings and injected to our subclass with
the help of Spring.

What do you think would such an extension to AdapterDeploymentContextBean
be of general use? I'd be happy to merge our subclass to
AdapterDeploymentContextBean and submit a pull request.

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

From sthorger at redhat.com  Fri Sep 25 09:23:03 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Fri, 25 Sep 2015 15:23:03 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <56054073.9090506@redhat.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<56054073.9090506@redhat.com>
Message-ID: <CAJgngAfHhOM4=u2jNwq9n+i1jfBKXrYmHFYeY98EYq6XHieiYA@mail.gmail.com>

Arquillian tests have been in master for some time now. There was also
recently a big amount of changes pushed, which made them less stable.

On 25 September 2015 at 14:39, Bill Burke <bburke at redhat.com> wrote:

> I looked at the log when  checked in.  I think it is because I changed
> some dependencies (added a new adapter jar).  I didn't realize the
> arquillian tests are in master?
>
> On 9/25/2015 5:19 AM, Stian Thorgersen wrote:
> > Doing what Giriraj suggest is an uggly hack, so please don't do that.
> > Just leave the PR and I'll re-start the tests.
> >
> > On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com
> > <mailto:sthorger at redhat.com>> wrote:
> >
> >     We're currently experiencing some unstability in the tests that we
> >     are working on. Don't worry about restarting the tests for failed
> >     PRs as I can take care of that.
> >
> >     On 25 September 2015 at 11:11, Giriraj Sharma
> >     <giriraj.sharma27 at gmail.com <mailto:giriraj.sharma27 at gmail.com>>
> wrote:
> >
> >         Hi,
> >
> >         I too faced such issues. In order to re run travis-ci, I used to
> >         make two additional commits on top of the main commit. The first
> >         commit involved a minor change and the second commit involved
> >         revert of first commit. I used to then squash the last 3 commits
> >         into one i.e., restore the repository to original state. In
> >         case, if you try to push again to the upstream after squashing,
> >         travis-ci build will be triggered automatically.
> >
> >         Although this might not be the best possible way, but it's at
> >         least a workaround.
> >
> >         Cheers,
> >
> >
> >
> >         On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber
> >         <gerbermichi at me.com <mailto:gerbermichi at me.com>> wrote:
> >
> >             Hi all,
> >
> >             travis fails at my PR but it passes on my branch.
> >             Is there a way to restart travis on a PR or do you have to
> >             create a new PR?
> >
> >             best
> >             Michael
> >
> >             _______________________________________________
> >             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
> >
> >
> >
> >
> >         --
> >         Giriraj Sharma
> >         about.me/girirajsharma
> >
> >         <http://about.me/girirajsharma?promo=email_sig>
> >
> >         Giriraj Sharma,
> >         Department of Computer Science
> >         National Institute of Technology Hamirpur
> >         Himachal Pradesh, India 177005
> >
> >         _______________________________________________
> >         keycloak-dev mailing list
> >         keycloak-dev at lists.jboss.org <mailto:
> keycloak-dev at lists.jboss.org>
> >         https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/32a8da0f/attachment-0001.html 

From arthurshakal at gmail.com  Fri Sep 25 09:46:07 2015
From: arthurshakal at gmail.com (=?UTF-8?Q?Arthur_Greg=C3=B3rio?=)
Date: Fri, 25 Sep 2015 10:46:07 -0300
Subject: [keycloak-dev] From Picketlink to Keycloak
Message-ID: <CA+UvXk+x7TAEz+tQaPN1gLYpADuVQN41P+LOf05Qp=G4Hp-Wtw@mail.gmail.com>

Hi!

I already have a system running with picketlink, everything works normally.

However, with the merge of the two projects, I wonder if I can ever move to
keycloak, if already have a migration guide, or how to proceed?

at.,

*Arthur P. Greg?rio*
*+55 45 9958-0302*
@gregorioarthur
www.arthurgregorio.eti.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150925/d5723804/attachment.html 

From bburke at redhat.com  Fri Sep 25 17:35:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Sep 2015 17:35:32 -0400
Subject: [keycloak-dev] From Picketlink to Keycloak
In-Reply-To: <CA+UvXk+x7TAEz+tQaPN1gLYpADuVQN41P+LOf05Qp=G4Hp-Wtw@mail.gmail.com>
References: <CA+UvXk+x7TAEz+tQaPN1gLYpADuVQN41P+LOf05Qp=G4Hp-Wtw@mail.gmail.com>
Message-ID: <5605BE24.8070008@redhat.com>

Depends what features you use in Picketlink.  Keycloak, right now is an 
IDP auth server that supports SAML 2.0 and OpenID Connect.  We also have 
client adapters that use a small extension to OpenID Connect as our 
protocol.  What's in the works?

* A SAML 2.0 client adapter if you are connecting to IDPs other than 
Keycloak

This should be in 1.6.

On 9/25/2015 9:46 AM, Arthur Greg?rio wrote:
> Hi!
>
> I already have a system running with picketlink, everything works normally.
>
> However, with the merge of the two projects, I wonder if I can ever move
> to keycloak, if already have a migration guide, or how to proceed?
>
> at.,
>
> *Arthur P. Greg?rio*
> /+55 45 9958-0302/
> @gregorioarthur
> www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
>
>
> _______________________________________________
> 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 arthurshakal at gmail.com  Sat Sep 26 18:13:21 2015
From: arthurshakal at gmail.com (=?UTF-8?Q?Arthur_Greg=C3=B3rio?=)
Date: Sat, 26 Sep 2015 19:13:21 -0300
Subject: [keycloak-dev] From Picketlink to Keycloak
In-Reply-To: <5605BE24.8070008@redhat.com>
References: <CA+UvXk+x7TAEz+tQaPN1gLYpADuVQN41P+LOf05Qp=G4Hp-Wtw@mail.gmail.com>
	<5605BE24.8070008@redhat.com>
Message-ID: <CA+UvXkJEG066nvQY7HRY6EywwQyvBcPWt=BZ-31_ZiHLxHJczQ@mail.gmail.com>

i'm using JPA IDM mixed with LDAP authentication, but keyclok seems very
different from what picktlink is...

Any idea when docs will be updated to guide users who want migrate from PL
do KC, since both will become one and PL is abandoned since 2.7.x release.

Something that will be annoying is having to use an structure as the KC
uses to do things that the PL does .. That is, from what little I've seen
so far, things will become more complex for applications who just want a
identity manager and authorizations.

Like my opensource project, webBudget (github.com/arthurgregorio/web-budget)
that uses PL

*Arthur P. Greg?rio*
*+55 45 9958-0302*
@gregorioarthur
www.arthurgregorio.eti.br

2015-09-25 18:35 GMT-03:00 Bill Burke <bburke at redhat.com>:

> Depends what features you use in Picketlink.  Keycloak, right now is an
> IDP auth server that supports SAML 2.0 and OpenID Connect.  We also have
> client adapters that use a small extension to OpenID Connect as our
> protocol.  What's in the works?
>
> * A SAML 2.0 client adapter if you are connecting to IDPs other than
> Keycloak
>
> This should be in 1.6.
>
> On 9/25/2015 9:46 AM, Arthur Greg?rio wrote:
> > Hi!
> >
> > I already have a system running with picketlink, everything works
> normally.
> >
> > However, with the merge of the two projects, I wonder if I can ever move
> > to keycloak, if already have a migration guide, or how to proceed?
> >
> > at.,
> >
> > *Arthur P. Greg?rio*
> > /+55 45 9958-0302/
> > @gregorioarthur
> > www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
> >
> >
> > _______________________________________________
> > 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/20150926/d75bbb16/attachment.html 

From sthorger at redhat.com  Mon Sep 28 03:09:25 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 28 Sep 2015 09:09:25 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
Message-ID: <CAJgngAcpkGeqgKFV2v6gii_SaANUDd_OOe+6QOEkJwUqhGRvSA@mail.gmail.com>

Yes, as I said before we have stability issues with the tests at the
moment. In the mean time I will restart tests that fail.

On 25 September 2015 at 11:22, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi Stian,
>
> Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
> behavior with travis-ci. For some simple commits, travis-ci used to fail
> for some random test which might have no association with the PR and a
> squashed push soon after 4-5 minutes used to result in success.
>
>
>
> On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Doing what Giriraj suggest is an uggly hack, so please don't do that.
>> Just leave the PR and I'll re-start the tests.
>>
>> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We're currently experiencing some unstability in the tests that we are
>>> working on. Don't worry about restarting the tests for failed PRs as I can
>>> take care of that.
>>>
>>> On 25 September 2015 at 11:11, Giriraj Sharma <
>>> giriraj.sharma27 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I too faced such issues. In order to re run travis-ci, I used to make
>>>> two additional commits on top of the main commit. The first commit involved
>>>> a minor change and the second commit involved revert of first commit. I
>>>> used to then squash the last 3 commits into one i.e., restore the
>>>> repository to original state. In case, if you try to push again to the
>>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>>
>>>> Although this might not be the best possible way, but it's at least a
>>>> workaround.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> travis fails at my PR but it passes on my branch.
>>>>> Is there a way to restart travis on a PR or do you have to create a
>>>>> new PR?
>>>>>
>>>>> best
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Giriraj Sharma
>>>> about.me/girirajsharma
>>>> <http://about.me/girirajsharma?promo=email_sig>
>>>>  Giriraj Sharma,
>>>> Department of Computer Science
>>>> National Institute of Technology Hamirpur
>>>> Himachal Pradesh, India 177005
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/09770263/attachment-0001.html 

From sthorger at redhat.com  Mon Sep 28 03:09:54 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 28 Sep 2015 09:09:54 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
Message-ID: <CAJgngAdC1B28csL2JTNt3T6XjR2Mp3rzkRUd4aSHfGSEqwBsjg@mail.gmail.com>

Yes, as I said before we have stability issues with the tests at the
moment. In the mean time I will restart tests that fail.

On 25 September 2015 at 11:22, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi Stian,
>
> Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
> behavior with travis-ci. For some simple commits, travis-ci used to fail
> for some random test which might have no association with the PR and a
> squashed push soon after 4-5 minutes used to result in success.
>
>
>
> On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Doing what Giriraj suggest is an uggly hack, so please don't do that.
>> Just leave the PR and I'll re-start the tests.
>>
>> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We're currently experiencing some unstability in the tests that we are
>>> working on. Don't worry about restarting the tests for failed PRs as I can
>>> take care of that.
>>>
>>> On 25 September 2015 at 11:11, Giriraj Sharma <
>>> giriraj.sharma27 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I too faced such issues. In order to re run travis-ci, I used to make
>>>> two additional commits on top of the main commit. The first commit involved
>>>> a minor change and the second commit involved revert of first commit. I
>>>> used to then squash the last 3 commits into one i.e., restore the
>>>> repository to original state. In case, if you try to push again to the
>>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>>
>>>> Although this might not be the best possible way, but it's at least a
>>>> workaround.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> travis fails at my PR but it passes on my branch.
>>>>> Is there a way to restart travis on a PR or do you have to create a
>>>>> new PR?
>>>>>
>>>>> best
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Giriraj Sharma
>>>> about.me/girirajsharma
>>>> <http://about.me/girirajsharma?promo=email_sig>
>>>>  Giriraj Sharma,
>>>> Department of Computer Science
>>>> National Institute of Technology Hamirpur
>>>> Himachal Pradesh, India 177005
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/56cd9248/attachment.html 

From sthorger at redhat.com  Mon Sep 28 03:10:29 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 28 Sep 2015 09:10:29 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
Message-ID: <CAJgngAfAM33LF_nv7JkVNacGT1jzSKuGJsCDGFa2wW7s_=dvSA@mail.gmail.com>

Yes, as I said before we have stability issues with the tests at the
moment. In the mean time I will restart tests that fail.

On 25 September 2015 at 11:22, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi Stian,
>
> Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
> behavior with travis-ci. For some simple commits, travis-ci used to fail
> for some random test which might have no association with the PR and a
> squashed push soon after 4-5 minutes used to result in success.
>
>
>
> On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Doing what Giriraj suggest is an uggly hack, so please don't do that.
>> Just leave the PR and I'll re-start the tests.
>>
>> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We're currently experiencing some unstability in the tests that we are
>>> working on. Don't worry about restarting the tests for failed PRs as I can
>>> take care of that.
>>>
>>> On 25 September 2015 at 11:11, Giriraj Sharma <
>>> giriraj.sharma27 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I too faced such issues. In order to re run travis-ci, I used to make
>>>> two additional commits on top of the main commit. The first commit involved
>>>> a minor change and the second commit involved revert of first commit. I
>>>> used to then squash the last 3 commits into one i.e., restore the
>>>> repository to original state. In case, if you try to push again to the
>>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>>
>>>> Although this might not be the best possible way, but it's at least a
>>>> workaround.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> travis fails at my PR but it passes on my branch.
>>>>> Is there a way to restart travis on a PR or do you have to create a
>>>>> new PR?
>>>>>
>>>>> best
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Giriraj Sharma
>>>> about.me/girirajsharma
>>>> <http://about.me/girirajsharma?promo=email_sig>
>>>>  Giriraj Sharma,
>>>> Department of Computer Science
>>>> National Institute of Technology Hamirpur
>>>> Himachal Pradesh, India 177005
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/4619bd59/attachment-0001.html 

From sthorger at redhat.com  Mon Sep 28 03:11:05 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 28 Sep 2015 09:11:05 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
Message-ID: <CAJgngAcKLsLmVfyGhY+yGXMfwYYgAjt8GESh8O_5Sx7aFJmQ+A@mail.gmail.com>

Yes, as I said before we have stability issues with the tests at the
moment. In the mean time I will restart tests that fail.

On 25 September 2015 at 11:22, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi Stian,
>
> Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
> behavior with travis-ci. For some simple commits, travis-ci used to fail
> for some random test which might have no association with the PR and a
> squashed push soon after 4-5 minutes used to result in success.
>
>
>
> On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Doing what Giriraj suggest is an uggly hack, so please don't do that.
>> Just leave the PR and I'll re-start the tests.
>>
>> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We're currently experiencing some unstability in the tests that we are
>>> working on. Don't worry about restarting the tests for failed PRs as I can
>>> take care of that.
>>>
>>> On 25 September 2015 at 11:11, Giriraj Sharma <
>>> giriraj.sharma27 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I too faced such issues. In order to re run travis-ci, I used to make
>>>> two additional commits on top of the main commit. The first commit involved
>>>> a minor change and the second commit involved revert of first commit. I
>>>> used to then squash the last 3 commits into one i.e., restore the
>>>> repository to original state. In case, if you try to push again to the
>>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>>
>>>> Although this might not be the best possible way, but it's at least a
>>>> workaround.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> travis fails at my PR but it passes on my branch.
>>>>> Is there a way to restart travis on a PR or do you have to create a
>>>>> new PR?
>>>>>
>>>>> best
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Giriraj Sharma
>>>> about.me/girirajsharma
>>>> <http://about.me/girirajsharma?promo=email_sig>
>>>>  Giriraj Sharma,
>>>> Department of Computer Science
>>>> National Institute of Technology Hamirpur
>>>> Himachal Pradesh, India 177005
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/a03cdb39/attachment.html 

From sthorger at redhat.com  Mon Sep 28 03:11:34 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Mon, 28 Sep 2015 09:11:34 +0200
Subject: [keycloak-dev] travis fail
In-Reply-To: <CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
References: <367dca58-0bbd-4b16-9a78-0fc89437327c@me.com>
	<CAB5vuUxTBdy+Z_m3zmHB_dSJ6hu5TXSNQXhj7u=siUQ_WN7BmA@mail.gmail.com>
	<CAJgngAfJ0eUfYXaKpfBgVJ=zYFwWspvB01moa3xXbr_3PLfqtQ@mail.gmail.com>
	<CAJgngAeQcUp3cTcJ3321a8bt5Do8cKBQ-ejahyiG9teOT1AaLQ@mail.gmail.com>
	<CAB5vuUxMioEAbNGsAH1u92rGgM+xEOauPik0e9XZLB3duFNh5w@mail.gmail.com>
Message-ID: <CAJgngAdYbioqJJBocCFAVhdR8g8V3M2_80HBq1cr3MwR+ccAfw@mail.gmail.com>

Yes, as I said before we have stability issues with the tests at the
moment. In the mean time I will restart tests that fail.

On 25 September 2015 at 11:22, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Hi Stian,
>
> Yeah, agreed, it's an ugly hack. But, I have observed a little surprising
> behavior with travis-ci. For some simple commits, travis-ci used to fail
> for some random test which might have no association with the PR and a
> squashed push soon after 4-5 minutes used to result in success.
>
>
>
> On Fri, Sep 25, 2015 at 2:49 PM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> Doing what Giriraj suggest is an uggly hack, so please don't do that.
>> Just leave the PR and I'll re-start the tests.
>>
>> On 25 September 2015 at 11:18, Stian Thorgersen <sthorger at redhat.com>
>> wrote:
>>
>>> We're currently experiencing some unstability in the tests that we are
>>> working on. Don't worry about restarting the tests for failed PRs as I can
>>> take care of that.
>>>
>>> On 25 September 2015 at 11:11, Giriraj Sharma <
>>> giriraj.sharma27 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I too faced such issues. In order to re run travis-ci, I used to make
>>>> two additional commits on top of the main commit. The first commit involved
>>>> a minor change and the second commit involved revert of first commit. I
>>>> used to then squash the last 3 commits into one i.e., restore the
>>>> repository to original state. In case, if you try to push again to the
>>>> upstream after squashing, travis-ci build will be triggered automatically.
>>>>
>>>> Although this might not be the best possible way, but it's at least a
>>>> workaround.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 2:30 PM, Michael Gerber <gerbermichi at me.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> travis fails at my PR but it passes on my branch.
>>>>> Is there a way to restart travis on a PR or do you have to create a
>>>>> new PR?
>>>>>
>>>>> best
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Giriraj Sharma
>>>> about.me/girirajsharma
>>>> <http://about.me/girirajsharma?promo=email_sig>
>>>>  Giriraj Sharma,
>>>> Department of Computer Science
>>>> National Institute of Technology Hamirpur
>>>> Himachal Pradesh, India 177005
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> --
>
> Giriraj Sharma
> about.me/girirajsharma
> <http://about.me/girirajsharma?promo=email_sig>
>  Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/623eef5c/attachment-0001.html 

From andipansa at gmail.com  Mon Sep 28 16:22:21 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Mon, 28 Sep 2015 22:22:21 +0200
Subject: [keycloak-dev] (no subject)
Message-ID: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>

Hi,

I've started to use keycloak with spring security and found that the name
and location of keycloak.json file was hardcoded. IMO it would be better to
allow injection of the configuration file name via constructor in
AdapterDeploymentContextBean by developer. Thus, I would be able to use
different keycloak configurations with different spring profiles. What do
you think about it?

Best Regards,
 Andrzej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150928/a2599761/attachment.html 

From bburke at redhat.com  Mon Sep 28 16:25:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 28 Sep 2015 16:25:07 -0400
Subject: [keycloak-dev] (no subject)
In-Reply-To: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>
References: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>
Message-ID: <5609A223.5010105@redhat.com>

This isn't true of our non-Spring adapters.  So, if you have a PR we 
welcome it!

On 9/28/2015 4:22 PM, Andrzej Go?awski wrote:
> Hi,
>
> I've started to use keycloak with spring security and found that the
> name and location of keycloak.json file was hardcoded. IMO it would be
> better to allow injection of the configuration file name via constructor
> in AdapterDeploymentContextBean by developer. Thus, I would be able to
> use different keycloak configurations with different spring profiles.
> What do you think about it?
>
> Best Regards,
>   Andrzej
>
>
> _______________________________________________
> 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 thomas.raehalme at aitiofinland.com  Mon Sep 28 16:27:28 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Mon, 28 Sep 2015 23:27:28 +0300
Subject: [keycloak-dev] (no subject)
In-Reply-To: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>
References: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>
Message-ID: <CAPyAMoYTwUePhy-vmDih9SH-Hhv_FsH22EGicJmLePP30t=zxg@mail.gmail.com>

Hi!

I had the same problem and ended up creating a subclass which first tries a
custom location and falls back to the original implementation. Spring
obtains the value from JNDI to enable external configuration.

I actually wrote about this a while ago. I'm happy to add the same
functionality to the adapter as it could be useful to others as well.

Best regards,
Thomas
On Sep 28, 2015 23:23, "Andrzej Go?awski" <andipansa at gmail.com> wrote:

> Hi,
>
> I've started to use keycloak with spring security and found that the name
> and location of keycloak.json file was hardcoded. IMO it would be better to
> allow injection of the configuration file name via constructor in
> AdapterDeploymentContextBean by developer. Thus, I would be able to use
> different keycloak configurations with different spring profiles. What do
> you think about it?
>
> Best Regards,
>  Andrzej
>
> _______________________________________________
> 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/20150928/57b8cbcd/attachment.html 

From andipansa at gmail.com  Mon Sep 28 16:30:56 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Mon, 28 Sep 2015 22:30:56 +0200
Subject: [keycloak-dev] (no subject)
In-Reply-To: <5609A223.5010105@redhat.com>
References: <CAA0ckM5n7+xJxZKMZqvWts3nLpcKcMjhf1Qcprr1a5rj2JWfKQ@mail.gmail.com>
	<5609A223.5010105@redhat.com>
Message-ID: <CAA0ckM6Fh9GcOH6kQ0ADnvj_jHYGqd9Wy8=b+m59uixkCbfpag@mail.gmail.com>

"So, if you have a PR we welcome it!"
Will do :)

Best Regards,
 Andrzej

2015-09-28 22:25 GMT+02:00 Bill Burke <bburke at redhat.com>:

> This isn't true of our non-Spring adapters.  So, if you have a PR we
> welcome it!
>
> On 9/28/2015 4:22 PM, Andrzej Go?awski wrote:
> > Hi,
> >
> > I've started to use keycloak with spring security and found that the
> > name and location of keycloak.json file was hardcoded. IMO it would be
> > better to allow injection of the configuration file name via constructor
> > in AdapterDeploymentContextBean by developer. Thus, I would be able to
> > use different keycloak configurations with different spring profiles.
> > What do you think about it?
> >
> > Best Regards,
> >   Andrzej
> >
> >
> > _______________________________________________
> > 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/20150928/5087d0b3/attachment.html 

From srossillo at smartling.com  Mon Sep 28 16:51:30 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 28 Sep 2015 16:51:30 -0400
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
Message-ID: <9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>


Based on the other feedback and the Spring way of providing as many configuration options as possible, I think we should refactor AdapterDeploymentContextBean.

However, I rather like the way Spring that divides behavior up into an interface and multiple implementations. I think we should:

1. Refactor the current AdapterDeploymentContextBean to be an interface and maybe rename it AdapterDeploymentContextFactory.
2. Split the current implementation into:
   a.  ClasspathAdapterDeploymentContextFactory > loads from class path
   b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
   c. JndiAdapterDeploymentContextFactory > load from JNDI
3. The above implementations should extend AbtractAdapterDeploymentContextFactory with something like:


protected loadKeycloakDeployment(Resource resource) {
        return KeycloakDeploymentBuilder.build(resource.getInputStream());
}

That would allow anyone to provide a custom AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."

What do you think? Since we?re refactoring, I?d also like to take into account design multi-tentant support. I think this approach is flexible enough to add that in the future.

If we agree this is a good approach you want to take a stab at it Thomas or should I?

Best,
Scott


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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com> wrote:
> 
> Hi!
> 
> We have written a custom subclass of org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable custom location for keycloak.json. The use of custom location is optional and defaults to the standard /WEB-INF/keycloak.json.
> 
> Our use case is that for developers we have a default keycloak.json included in the application. In production, however, we override the default by using a file that is external to the application. The location of the file is specified in JNDI settings and injected to our subclass with the help of Spring.
> 
> What do you think would such an extension to AdapterDeploymentContextBean be of general use? I'd be happy to merge our subclass to AdapterDeploymentContextBean and submit a pull request.
> 
> 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/20150928/fee4fe78/attachment.html 

From andipansa at gmail.com  Mon Sep 28 17:04:20 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Mon, 28 Sep 2015 23:04:20 +0200
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
Message-ID: <CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>

Hi

Why not do it via contructor:

public AdapterDeploymentContextBean(String configFile){
  .....
}

and in BasicKeycloakWebSecurityConfigurationAdapter add:

@Value("${keycloak.configFile:WEB-INF/keycloak.json}")
private String keycloakConfigFile;

@Bean
protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
    return new AdapterDeploymentContextBean(keycloakConfigFile);
}

Best Regards,
 Andrzej



2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:

>
> Based on the other feedback and the Spring way of providing as many
> configuration options as possible, I think we should refactor
> AdapterDeploymentContextBean.
>
> However, I rather like the way Spring that divides behavior up into an
> interface and multiple implementations. I think we should:
>
> 1. Refactor the current AdapterDeploymentContextBean to be an interface
> and maybe rename it AdapterDeploymentContextFactory.
> 2. Split the current implementation into:
>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>    c. JndiAdapterDeploymentContextFactory > load from JNDI
> 3. The above implementations should extend
> AbtractAdapterDeploymentContextFactory with something like:
>
>
> protected loadKeycloakDeployment(Resource resource) {
>         return KeycloakDeploymentBuilder.build(resource.getInputStream());
> }
>
> That would allow anyone to provide a custom
> AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
>
> What do you think? Since we?re refactoring, I?d also like to take into
> account design multi-tentant support. I think this approach is flexible
> enough to add that in the future.
>
> If we agree this is a good approach you want to take a stab at it Thomas
> or should I?
>
> Best,
> Scott
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <http://www.sigstr.com/>
>
> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <
> thomas.raehalme at aitiofinland.com> wrote:
>
> Hi!
>
> We have written a custom subclass of
> org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable
> custom location for keycloak.json. The use of custom location is optional
> and defaults to the standard /WEB-INF/keycloak.json.
>
> Our use case is that for developers we have a default keycloak.json
> included in the application. In production, however, we override the
> default by using a file that is external to the application. The location
> of the file is specified in JNDI settings and injected to our subclass with
> the help of Spring.
>
> What do you think would such an extension to AdapterDeploymentContextBean
> be of general use? I'd be happy to merge our subclass to
> AdapterDeploymentContextBean and submit a pull request.
>
> Best regards,
> Thomas
> _______________________________________________
> 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/20150928/fc98d725/attachment-0001.html 

From srossillo at smartling.com  Mon Sep 28 17:56:14 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 28 Sep 2015 17:56:14 -0400
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
	<CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
Message-ID: <08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>

This could be done if the constructor argument is a Spring Resource[0] instead of a string. It doesn?t help with multi-tenant support but it?s still an improvement.


[0] http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html <http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html>



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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Sep 28, 2015, at 5:04 PM, Andrzej Go?awski <andipansa at gmail.com> wrote:
> 
> Hi
> 
> Why not do it via contructor:
> 
> public AdapterDeploymentContextBean(String configFile){
>   .....
> }
> 
> and in BasicKeycloakWebSecurityConfigurationAdapter add:
> 
> @Value("${keycloak.configFile:WEB-INF/keycloak.json}")
> private String keycloakConfigFile;
> 
> @Bean
> protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
>     return new AdapterDeploymentContextBean(keycloakConfigFile);
> }
> 
> Best Regards,
>  Andrzej
> 
> 
> 
> 2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com <mailto:srossillo at smartling.com>>:
> 
> Based on the other feedback and the Spring way of providing as many configuration options as possible, I think we should refactor AdapterDeploymentContextBean.
> 
> However, I rather like the way Spring that divides behavior up into an interface and multiple implementations. I think we should:
> 
> 1. Refactor the current AdapterDeploymentContextBean to be an interface and maybe rename it AdapterDeploymentContextFactory.
> 2. Split the current implementation into:
>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>    c. JndiAdapterDeploymentContextFactory > load from JNDI
> 3. The above implementations should extend AbtractAdapterDeploymentContextFactory with something like:
> 
> 
> protected loadKeycloakDeployment(Resource resource) {
>         return KeycloakDeploymentBuilder.build(resource.getInputStream());
> }
> 
> That would allow anyone to provide a custom AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
> 
> What do you think? Since we?re refactoring, I?d also like to take into account design multi-tentant support. I think this approach is flexible enough to add that in the future.
> 
> If we agree this is a good approach you want to take a stab at it Thomas or should I?
> 
> Best,
> Scott
> 
> 
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
> 
>  <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>  <http://www.sigstr.com/>
>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>> 
>> Hi!
>> 
>> We have written a custom subclass of org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable custom location for keycloak.json. The use of custom location is optional and defaults to the standard /WEB-INF/keycloak.json.
>> 
>> Our use case is that for developers we have a default keycloak.json included in the application. In production, however, we override the default by using a file that is external to the application. The location of the file is specified in JNDI settings and injected to our subclass with the help of Spring.
>> 
>> What do you think would such an extension to AdapterDeploymentContextBean be of general use? I'd be happy to merge our subclass to AdapterDeploymentContextBean and submit a pull request.
>> 
>> 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 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 

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

From andipansa at gmail.com  Mon Sep 28 18:10:28 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Tue, 29 Sep 2015 00:10:28 +0200
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
	<CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
	<08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
Message-ID: <CAA0ckM54Q2eqyBWuBFYx30pWB1CyfF+1uvaDe=LQ8t03C13U6Q@mail.gmail.com>

Sorry if it is a stupid question, but what do you mean by multi-tenant in
this case?



2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:

> This could be done if the constructor argument is a Spring Resource[0]
> instead of a string. It doesn?t help with multi-tenant support but it?s
> still an improvement.
>
>
> [0]
> http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html
>
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <http://www.sigstr.com/>
>
> On Sep 28, 2015, at 5:04 PM, Andrzej Go?awski <andipansa at gmail.com> wrote:
>
> Hi
>
> Why not do it via contructor:
>
> public AdapterDeploymentContextBean(String configFile){
>   .....
> }
>
> and in BasicKeycloakWebSecurityConfigurationAdapter add:
>
> @Value("${keycloak.configFile:WEB-INF/keycloak.json}")
> private String keycloakConfigFile;
>
> @Bean
> protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
>     return new AdapterDeploymentContextBean(keycloakConfigFile);
> }
>
> Best Regards,
>  Andrzej
>
>
>
> 2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:
>
>>
>> Based on the other feedback and the Spring way of providing as many
>> configuration options as possible, I think we should refactor
>> AdapterDeploymentContextBean.
>>
>> However, I rather like the way Spring that divides behavior up into an
>> interface and multiple implementations. I think we should:
>>
>> 1. Refactor the current AdapterDeploymentContextBean to be an interface
>> and maybe rename it AdapterDeploymentContextFactory.
>> 2. Split the current implementation into:
>>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>>    c. JndiAdapterDeploymentContextFactory > load from JNDI
>> 3. The above implementations should extend
>> AbtractAdapterDeploymentContextFactory with something like:
>>
>>
>> protected loadKeycloakDeployment(Resource resource) {
>>         return KeycloakDeploymentBuilder.build(resource.getInputStream());
>> }
>>
>> That would allow anyone to provide a custom
>> AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
>>
>> What do you think? Since we?re refactoring, I?d also like to take into
>> account design multi-tentant support. I think this approach is flexible
>> enough to add that in the future.
>>
>> If we agree this is a good approach you want to take a stab at it Thomas
>> or should I?
>>
>> Best,
>> Scott
>>
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com
>>
>> [image: Latest News + Events]
>> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>
>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>> Hi!
>>
>> We have written a custom subclass of
>> org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable
>> custom location for keycloak.json. The use of custom location is optional
>> and defaults to the standard /WEB-INF/keycloak.json.
>>
>> Our use case is that for developers we have a default keycloak.json
>> included in the application. In production, however, we override the
>> default by using a file that is external to the application. The location
>> of the file is specified in JNDI settings and injected to our subclass with
>> the help of Spring.
>>
>> What do you think would such an extension to AdapterDeploymentContextBean
>> be of general use? I'd be happy to merge our subclass to
>> AdapterDeploymentContextBean and submit a pull request.
>>
>> Best regards,
>> Thomas
>> _______________________________________________
>> 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/20150929/d46b8a2f/attachment-0001.html 

From andipansa at gmail.com  Mon Sep 28 18:33:07 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Tue, 29 Sep 2015 00:33:07 +0200
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
	<CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
	<08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
Message-ID: <CAA0ckM7OGJMzA1vLxThE1=5xuYXJO7968PkZPdOjWj+OEOTFOA@mail.gmail.com>

And yes of course you are right :) You can replace String with the Resource
and be able to get keycloak.json from classpath, file or http via spring
properties file (or yml)

Best Regards,
 Andrzej

2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:

> This could be done if the constructor argument is a Spring Resource[0]
> instead of a string. It doesn?t help with multi-tenant support but it?s
> still an improvement.
>
>
> [0]
> http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html
>
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <http://www.sigstr.com/>
>
> On Sep 28, 2015, at 5:04 PM, Andrzej Go?awski <andipansa at gmail.com> wrote:
>
> Hi
>
> Why not do it via contructor:
>
> public AdapterDeploymentContextBean(String configFile){
>   .....
> }
>
> and in BasicKeycloakWebSecurityConfigurationAdapter add:
>
> @Value("${keycloak.configFile:WEB-INF/keycloak.json}")
> private String keycloakConfigFile;
>
> @Bean
> protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
>     return new AdapterDeploymentContextBean(keycloakConfigFile);
> }
>
> Best Regards,
>  Andrzej
>
>
>
> 2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:
>
>>
>> Based on the other feedback and the Spring way of providing as many
>> configuration options as possible, I think we should refactor
>> AdapterDeploymentContextBean.
>>
>> However, I rather like the way Spring that divides behavior up into an
>> interface and multiple implementations. I think we should:
>>
>> 1. Refactor the current AdapterDeploymentContextBean to be an interface
>> and maybe rename it AdapterDeploymentContextFactory.
>> 2. Split the current implementation into:
>>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>>    c. JndiAdapterDeploymentContextFactory > load from JNDI
>> 3. The above implementations should extend
>> AbtractAdapterDeploymentContextFactory with something like:
>>
>>
>> protected loadKeycloakDeployment(Resource resource) {
>>         return KeycloakDeploymentBuilder.build(resource.getInputStream());
>> }
>>
>> That would allow anyone to provide a custom
>> AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
>>
>> What do you think? Since we?re refactoring, I?d also like to take into
>> account design multi-tentant support. I think this approach is flexible
>> enough to add that in the future.
>>
>> If we agree this is a good approach you want to take a stab at it Thomas
>> or should I?
>>
>> Best,
>> Scott
>>
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com
>>
>> [image: Latest News + Events]
>> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>
>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <
>> thomas.raehalme at aitiofinland.com> wrote:
>>
>> Hi!
>>
>> We have written a custom subclass of
>> org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable
>> custom location for keycloak.json. The use of custom location is optional
>> and defaults to the standard /WEB-INF/keycloak.json.
>>
>> Our use case is that for developers we have a default keycloak.json
>> included in the application. In production, however, we override the
>> default by using a file that is external to the application. The location
>> of the file is specified in JNDI settings and injected to our subclass with
>> the help of Spring.
>>
>> What do you think would such an extension to AdapterDeploymentContextBean
>> be of general use? I'd be happy to merge our subclass to
>> AdapterDeploymentContextBean and submit a pull request.
>>
>> Best regards,
>> Thomas
>> _______________________________________________
>> 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/20150929/33f3a326/attachment.html 

From srossillo at smartling.com  Mon Sep 28 19:38:31 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 28 Sep 2015 19:38:31 -0400
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <CAA0ckM54Q2eqyBWuBFYx30pWB1CyfF+1uvaDe=LQ8t03C13U6Q@mail.gmail.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
	<CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
	<08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
	<CAA0ckM54Q2eqyBWuBFYx30pWB1CyfF+1uvaDe=LQ8t03C13U6Q@mail.gmail.com>
Message-ID: <EE4BD5E4-F918-4587-BD87-F8247E5F4041@smartling.com>

The other adapters support the concept of Multi Tenancy[0]:

?That one single target application (WAR) can be secured by a single (or clustered) Keycloak server, authenticating its users against different realms. In practice, this means that one application needs to use different keycloak.json files"


[0]: http://keycloak.github.io/docs/userguide/html/ch08.html#multi_tenancy

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

 <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
 <http://www.sigstr.com/>
> On Sep 28, 2015, at 6:10 PM, Andrzej Go?awski <andipansa at gmail.com> wrote:
> 
> Sorry if it is a stupid question, but what do you mean by multi-tenant in this case?
> 
> 
> 
> 2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo at smartling.com <mailto:srossillo at smartling.com>>:
> This could be done if the constructor argument is a Spring Resource[0] instead of a string. It doesn?t help with multi-tenant support but it?s still an improvement.
> 
> 
> [0] http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html <http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html>
> 
> 
> 
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
> 
>  <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>  <http://www.sigstr.com/>
>> On Sep 28, 2015, at 5:04 PM, Andrzej Go?awski <andipansa at gmail.com <mailto:andipansa at gmail.com>> wrote:
>> 
>> Hi
>> 
>> Why not do it via contructor:
>> 
>> public AdapterDeploymentContextBean(String configFile){
>>   .....
>> }
>> 
>> and in BasicKeycloakWebSecurityConfigurationAdapter add:
>> 
>> @Value("${keycloak.configFile:WEB-INF/keycloak.json}")
>> private String keycloakConfigFile;
>> 
>> @Bean
>> protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
>>     return new AdapterDeploymentContextBean(keycloakConfigFile);
>> }
>> 
>> Best Regards,
>>  Andrzej
>> 
>> 
>> 
>> 2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com <mailto:srossillo at smartling.com>>:
>> 
>> Based on the other feedback and the Spring way of providing as many configuration options as possible, I think we should refactor AdapterDeploymentContextBean.
>> 
>> However, I rather like the way Spring that divides behavior up into an interface and multiple implementations. I think we should:
>> 
>> 1. Refactor the current AdapterDeploymentContextBean to be an interface and maybe rename it AdapterDeploymentContextFactory.
>> 2. Split the current implementation into:
>>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>>    c. JndiAdapterDeploymentContextFactory > load from JNDI
>> 3. The above implementations should extend AbtractAdapterDeploymentContextFactory with something like:
>> 
>> 
>> protected loadKeycloakDeployment(Resource resource) {
>>         return KeycloakDeploymentBuilder.build(resource.getInputStream());
>> }
>> 
>> That would allow anyone to provide a custom AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
>> 
>> What do you think? Since we?re refactoring, I?d also like to take into account design multi-tentant support. I think this approach is flexible enough to add that in the future.
>> 
>> If we agree this is a good approach you want to take a stab at it Thomas or should I?
>> 
>> Best,
>> Scott
>> 
>> 
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com <mailto:srossillo at smartling.com>
>> 
>>  <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>>  <http://www.sigstr.com/>
>>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <thomas.raehalme at aitiofinland.com <mailto:thomas.raehalme at aitiofinland.com>> wrote:
>>> 
>>> Hi!
>>> 
>>> We have written a custom subclass of org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable custom location for keycloak.json. The use of custom location is optional and defaults to the standard /WEB-INF/keycloak.json.
>>> 
>>> Our use case is that for developers we have a default keycloak.json included in the application. In production, however, we override the default by using a file that is external to the application. The location of the file is specified in JNDI settings and injected to our subclass with the help of Spring.
>>> 
>>> What do you think would such an extension to AdapterDeploymentContextBean be of general use? I'd be happy to merge our subclass to AdapterDeploymentContextBean and submit a pull request.
>>> 
>>> 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 <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>> 
> 
> 

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

From mposolda at redhat.com  Tue Sep 29 03:35:33 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 29 Sep 2015 09:35:33 +0200
Subject: [keycloak-dev] From Picketlink to Keycloak
In-Reply-To: <CA+UvXkJEG066nvQY7HRY6EywwQyvBcPWt=BZ-31_ZiHLxHJczQ@mail.gmail.com>
References: <CA+UvXk+x7TAEz+tQaPN1gLYpADuVQN41P+LOf05Qp=G4Hp-Wtw@mail.gmail.com>
	<5605BE24.8070008@redhat.com>
	<CA+UvXkJEG066nvQY7HRY6EywwQyvBcPWt=BZ-31_ZiHLxHJczQ@mail.gmail.com>
Message-ID: <560A3F45.6030706@redhat.com>

Keycloak is OOTB server, which redirects you to login screen on Keycloak 
server side and handles authentication for you. If you want to 
authenticate to Keycloak with LDAP users, you can already do that. You 
can create LDAP federation provider in Keycloak admin console and you're 
done. See the docs: 
http://keycloak.github.io/docs/userguide/html/user_federation.html

However for Picketlink JPA IDM, we don't have any migration right now. 
AFAIK we plan to add support for Picketlink federation provider into 
Keycloak, which will allow to migrate users from any picketlink identity 
store (JPA, File, LDAP and others) and use them in Keycloak.

Marek


On 27/09/15 00:13, Arthur Greg?rio wrote:
> i'm using JPA IDM mixed with LDAP authentication, but keyclok seems 
> very different from what picktlink is...
>
> Any idea when docs will be updated to guide users who want migrate 
> from PL do KC, since both will become one and PL is abandoned since 
> 2.7.x release.
>
> Something that will be annoying is having to use an structure as the 
> KC uses to do things that the PL does .. That is, from what little 
> I've seen so far, things will become more complex for applications who 
> just want a identity manager and authorizations.
>
> Like my opensource project, webBudget 
> (github.com/arthurgregorio/web-budget 
> <http://github.com/arthurgregorio/web-budget>) that uses PL
>
> *Arthur P. Greg?rio*
> /+55 45 9958-0302/
> @gregorioarthur
> www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
>
> 2015-09-25 18:35 GMT-03:00 Bill Burke <bburke at redhat.com 
> <mailto:bburke at redhat.com>>:
>
>     Depends what features you use in Picketlink.  Keycloak, right now
>     is an
>     IDP auth server that supports SAML 2.0 and OpenID Connect. We also
>     have
>     client adapters that use a small extension to OpenID Connect as our
>     protocol.  What's in the works?
>
>     * A SAML 2.0 client adapter if you are connecting to IDPs other than
>     Keycloak
>
>     This should be in 1.6.
>
>     On 9/25/2015 9:46 AM, Arthur Greg?rio wrote:
>     > Hi!
>     >
>     > I already have a system running with picketlink, everything
>     works normally.
>     >
>     > However, with the merge of the two projects, I wonder if I can
>     ever move
>     > to keycloak, if already have a migration guide, or how to proceed?
>     >
>     > at.,
>     >
>     > *Arthur P. Greg?rio*
>     > /+55 45 9958-0302 <tel:%2B55%2045%209958-0302>/
>     > @gregorioarthur
>     > www.arthurgregorio.eti.br <http://www.arthurgregorio.eti.br>
>     <http://www.arthurgregorio.eti.br>
>     >
>     >
>     > _______________________________________________
>     > 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/20150929/d7cad3a3/attachment.html 

From andipansa at gmail.com  Tue Sep 29 03:47:09 2015
From: andipansa at gmail.com (=?UTF-8?Q?Andrzej_Go=C5=82awski?=)
Date: Tue, 29 Sep 2015 09:47:09 +0200
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <EE4BD5E4-F918-4587-BD87-F8247E5F4041@smartling.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
	<CAA0ckM4k_fEWB43GufFaJnhZ70B7fPdu2_2hhGidB6ObaHdBCQ@mail.gmail.com>
	<08398673-ECD3-4003-A29A-145F9C6344CB@smartling.com>
	<CAA0ckM54Q2eqyBWuBFYx30pWB1CyfF+1uvaDe=LQ8t03C13U6Q@mail.gmail.com>
	<EE4BD5E4-F918-4587-BD87-F8247E5F4041@smartling.com>
Message-ID: <CAA0ckM6QdgbsV52FNTPp=Osa31UNj78XdnuiYUpw3Yi72bVQEg@mail.gmail.com>

Thank you for explanation !

In that case you could replace Resource with List<Resource> and provide
config files via propery file.

exemple for yml:

keycloak.configFiles:
       - file:/../first-keycloak.json
       - classpath:/../second-keycloak.json

Ofcourse you are the designer of this adapter so decision is yours :)

Best Regards,
 Andrzej

2015-09-29 1:38 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:

> The other adapters support the concept of Multi Tenancy[0]:
>
> ?That one single target application (WAR) can be secured by a single (or
> clustered) Keycloak server, authenticating its users against different
> realms. In practice, this means that one application needs to use
> different keycloak.json files"
>
>
> [0]: http://keycloak.github.io/docs/userguide/html/ch08.html#multi_tenancy
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <http://www.sigstr.com/>
>
> On Sep 28, 2015, at 6:10 PM, Andrzej Go?awski <andipansa at gmail.com> wrote:
>
> Sorry if it is a stupid question, but what do you mean by multi-tenant in
> this case?
>
>
>
> 2015-09-28 23:56 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:
>
>> This could be done if the constructor argument is a Spring Resource[0]
>> instead of a string. It doesn?t help with multi-tenant support but it?s
>> still an improvement.
>>
>>
>> [0]
>> http://docs.spring.io/spring-framework/docs/3.2.x/javadoc-api/org/springframework/core/io/Resource.html
>>
>>
>>
>> Scott Rossillo
>> Smartling | Senior Software Engineer
>> srossillo at smartling.com
>>
>> [image: Latest News + Events]
>> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>
>> On Sep 28, 2015, at 5:04 PM, Andrzej Go?awski <andipansa at gmail.com>
>> wrote:
>>
>> Hi
>>
>> Why not do it via contructor:
>>
>> public AdapterDeploymentContextBean(String configFile){
>>   .....
>> }
>>
>> and in BasicKeycloakWebSecurityConfigurationAdapter add:
>>
>> @Value("${keycloak.configFile:WEB-INF/keycloak.json}")
>> private String keycloakConfigFile;
>>
>> @Bean
>> protected AdapterDeploymentContextBean adapterDeploymentContextBean() {
>>     return new AdapterDeploymentContextBean(keycloakConfigFile);
>> }
>>
>> Best Regards,
>>  Andrzej
>>
>>
>>
>> 2015-09-28 22:51 GMT+02:00 Scott Rossillo <srossillo at smartling.com>:
>>
>>>
>>> Based on the other feedback and the Spring way of providing as many
>>> configuration options as possible, I think we should refactor
>>> AdapterDeploymentContextBean.
>>>
>>> However, I rather like the way Spring that divides behavior up into an
>>> interface and multiple implementations. I think we should:
>>>
>>> 1. Refactor the current AdapterDeploymentContextBean to be an interface
>>> and maybe rename it AdapterDeploymentContextFactory.
>>> 2. Split the current implementation into:
>>>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>>>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>>>    c. JndiAdapterDeploymentContextFactory > load from JNDI
>>> 3. The above implementations should extend
>>> AbtractAdapterDeploymentContextFactory with something like:
>>>
>>>
>>> protected loadKeycloakDeployment(Resource resource) {
>>>
>>>   return KeycloakDeploymentBuilder.build(resource.getInputStream());
>>> }
>>>
>>> That would allow anyone to provide a custom
>>> AdapterDeploymentContextFactory to load the keycloak.json from ?anywhere."
>>>
>>> What do you think? Since we?re refactoring, I?d also like to take into
>>> account design multi-tentant support. I think this approach is flexible
>>> enough to add that in the future.
>>>
>>> If we agree this is a good approach you want to take a stab at it Thomas
>>> or should I?
>>>
>>> Best,
>>> Scott
>>>
>>>
>>> Scott Rossillo
>>> Smartling | Senior Software Engineer
>>> srossillo at smartling.com
>>>
>>> [image: Latest News + Events]
>>> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
>>> [image: Powered by Sigstr] <http://www.sigstr.com/>
>>>
>>> On Sep 25, 2015, at 9:21 AM, Thomas Raehalme <
>>> thomas.raehalme at aitiofinland.com> wrote:
>>>
>>> Hi!
>>>
>>> We have written a custom subclass of
>>> org.keycloak.adapters.springsecurity.AdapterDeploymentContextBean to enable
>>> custom location for keycloak.json. The use of custom location is optional
>>> and defaults to the standard /WEB-INF/keycloak.json.
>>>
>>> Our use case is that for developers we have a default keycloak.json
>>> included in the application. In production, however, we override the
>>> default by using a file that is external to the application. The location
>>> of the file is specified in JNDI settings and injected to our subclass with
>>> the help of Spring.
>>>
>>> What do you think would such an extension to
>>> AdapterDeploymentContextBean be of general use? I'd be happy to merge our
>>> subclass to AdapterDeploymentContextBean and submit a pull request.
>>>
>>> Best regards,
>>> Thomas
>>> _______________________________________________
>>> 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/20150929/7363cc65/attachment-0001.html 

From thomas.raehalme at aitiofinland.com  Tue Sep 29 03:57:28 2015
From: thomas.raehalme at aitiofinland.com (Thomas Raehalme)
Date: Tue, 29 Sep 2015 10:57:28 +0300
Subject: [keycloak-dev] AdapterDeploymentContextBean with custom location
In-Reply-To: <9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
References: <CAPyAMoaJfNUbWLgjDZ-M6-sKEoVVzMu9MncS5F1ykxQ3DuRFow@mail.gmail.com>
	<9094C929-D6E5-4168-AFE5-69CC62F2F557@smartling.com>
Message-ID: <CAPyAMobu4jayHdK16wOSFsNtugq500CeR-RMVQRP8KqPPvWdOA@mail.gmail.com>

Hi!

On Mon, Sep 28, 2015 at 11:51 PM, Scott Rossillo <srossillo at smartling.com>
wrote:

> 1. Refactor the current AdapterDeploymentContextBean to be an interface
> and maybe rename it AdapterDeploymentContextFactory.
>

This sounds an excellent idea.


> 2. Split the current implementation into:
>    a.  ClasspathAdapterDeploymentContextFactory > loads from class path
>    b. WebApplicationAdapterDeploymentContextFactory > loads from WEB-INF
>    c. JndiAdapterDeploymentContextFactory > load from JNDI
>

I'm not sure if we need many implementations at least for different sources
as we could do one which works with an array of Resources to load the
configuration. You could use standard Spring utils to obtain the list of
Resources from properties, yaml, JNDI, etc.

Additional implementation, however, could be one that takes advantage of
KeycloakConfigResolver for multi-tenancy support.

What do you think?


> If we agree this is a good approach you want to take a stab at it Thomas
> or should I?
>

I'm happy to send a pull request regarding this issue.

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

From prabhalar at yahoo.com  Tue Sep 29 07:28:51 2015
From: prabhalar at yahoo.com (Raghuram Prabhala)
Date: Tue, 29 Sep 2015 11:28:51 +0000 (UTC)
Subject: [keycloak-dev] RFC 7636 - Proof Key for Code Exchange by OAuth
	Public Clients
Message-ID: <301390434.2674739.1443526131745.JavaMail.yahoo@mail.yahoo.com>

Any plans to implement the below?
http://www.rfc-editor.org/rfc/rfc7636.txt

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

From remi.cartier at imetrik.com  Tue Sep 29 13:06:17 2015
From: remi.cartier at imetrik.com (Remi Cartier)
Date: Tue, 29 Sep 2015 17:06:17 +0000
Subject: [keycloak-dev] Admin REST - User Roles
Message-ID: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>

Hi guys,

first of all, thank you for that great piece of software, it?s amazing !

Now, down to business.

When I do :

        keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId());
        for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) {
            log.info(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE));
        }

The information I get does not contain any roles, all the roles related fields are ?null?. -

{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}
However in the admin interface I have setup roles at each layer : realm, client

The user I am using to do the queries has all the *realm* roles associated.

is there anything else I need to do ?

thank you for your help !

________________________________

REMI CARTIER
B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)

IMETRIK GLOBAL INC.
T : +1 514 448-6407 x2009
T : +1 866 276-5382 (toll free)
F : +1 514 904-0611

740 Notre Dame St. West, Suite 1575
Montreal, Quebec, Canada H3C 3X6
imetrik.com<http://www.imetrik.com/>

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

From mposolda at redhat.com  Wed Sep 30 06:21:32 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Sep 2015 12:21:32 +0200
Subject: [keycloak-dev] Admin REST - User Roles
In-Reply-To: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>
References: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>
Message-ID: <560BB7AC.6040501@redhat.com>

Hi,

to retrieve realm role mappings of user, you need to use the endpoint 
like 
http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm 
. See the docs for details: 
http://keycloak.github.io/docs/rest-api/overview-index.html

Marek

On 29/09/15 19:06, Remi Cartier wrote:
> Hi guys,
>
> first of all, thank you for that great piece of software, it?s amazing !
>
> Now, down to business.
>
> When I do :
>
>         keycloak = Keycloak.getInstance(getKeycloakServerURL(), 
> getKeycloakRealm(), getKeycloakRealmAdminUsername(), 
> getKeycloakRealmAdminPassword(), getKeycloakClientId());
>         for (UserRepresentation userRepresentation : 
> keycloak.realm(getKeycloakRealm()).users().search(null, 0, 
> Integer.MAX_VALUE)) {
> log.info(ToStringBuilder.reflectionToString(userRepresentation, 
> ToStringStyle.JSON_STYLE));
>         }
>
> The information I get does not contain any roles, all the roles 
> related fields are ?null?. -
>
> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first 
> name","lastName":"last 
> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}
> However in the admin interface I have setup roles at each layer : 
> realm, client
>
> The user I am using to do the queries has all the *realm* roles 
> associated.
>
> is there anything else I need to do ?
>
> thank you for your help !
>
> ------------------------------------------------------------------------
>
>
> REMI CARTIER
>
> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)
>
> *IMETRIK GLOBAL INC.*
> *T :* +1 514 448-6407 x2009
> *T :* +1 866 276-5382 (toll free)
> *F :* +1 514 904-0611
>
> 740 Notre Dame St. West, Suite 1575
> Montreal, Quebec, Canada H3C 3X6
> imetrik.com <http://www.imetrik.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/20150930/43aad207/attachment-0001.html 

From mposolda at redhat.com  Wed Sep 30 06:39:12 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Sep 2015 12:39:12 +0200
Subject: [keycloak-dev] Fixed compilation errors
Message-ID: <560BBBD0.9080805@redhat.com>

I had some compilation errors when I rebased master today. It was about 
different signature of SamlAdapterTestStrategy.uploadSP, which expects 
single String argument, but some tests invoked that with 2 arguments 
(second is keycloakRule). I've removed the second argument from calls 
and changed it like this:

- SamlAdapterTestStrategy.uploadSP("http://localhost:8081/auth", 
keycloakRule);
+ SamlAdapterTestStrategy.uploadSP("http://localhost:8081/auth");

I've added it to my PR for offline tokens. Now the compilation errors 
are fixed and all tests are passing.

Just a heads up. Hope I did not break anything :)

Marek



From remi.cartier at imetrik.com  Wed Sep 30 07:24:05 2015
From: remi.cartier at imetrik.com (Remi Cartier)
Date: Wed, 30 Sep 2015 11:24:05 +0000
Subject: [keycloak-dev] Admin REST - User Roles
In-Reply-To: <560BB7AC.6040501@redhat.com>
References: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>,
	<560BB7AC.6040501@redhat.com>
Message-ID: <E8731B3C90D3134890657137AEA79B65011311B52B@MTL01-DC03.imetrik.com>

Marek,

I see, thank you for your reply.

Wouldn't it be less error/question prone if the endpoint returning all the users wouldn't show the *roles attributes ?
Because they will always be null if I understood correctly.

Regards.

R?mi.

________________________________
From: Marek Posolda [mposolda at redhat.com]
Sent: Wednesday, September 30, 2015 6:21 AM
To: Remi Cartier; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Admin REST - User Roles

Hi,

to retrieve realm role mappings of user, you need to use the endpoint like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm . See the docs for details: http://keycloak.github.io/docs/rest-api/overview-index.html

Marek

On 29/09/15 19:06, Remi Cartier wrote:
Hi guys,

first of all, thank you for that great piece of software, it?s amazing !

Now, down to business.

When I do :

        keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId());
        for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) {
            log.info(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE));
        }

The information I get does not contain any roles, all the roles related fields are ?null?. -

{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}
However in the admin interface I have setup roles at each layer : realm, client

The user I am using to do the queries has all the *realm* roles associated.

is there anything else I need to do ?

thank you for your help !

________________________________

REMI CARTIER
B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)

IMETRIK GLOBAL INC.
T : +1 514 448-6407 x2009
T : +1 866 276-5382 (toll free)
F : +1 514 904-0611

740 Notre Dame St. West, Suite 1575
Montreal, Quebec, Canada H3C 3X6
imetrik.com<http://www.imetrik.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/20150930/f64f254e/attachment.html 

From sthorger at redhat.com  Wed Sep 30 07:39:32 2015
From: sthorger at redhat.com (Stian Thorgersen)
Date: Wed, 30 Sep 2015 13:39:32 +0200
Subject: [keycloak-dev] Admin REST - User Roles
In-Reply-To: <E8731B3C90D3134890657137AEA79B65011311B52B@MTL01-DC03.imetrik.com>
References: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>
	<560BB7AC.6040501@redhat.com>
	<E8731B3C90D3134890657137AEA79B65011311B52B@MTL01-DC03.imetrik.com>
Message-ID: <CAJgngAf2mL7v-MfN4U+OP4Nh1G_z7oeQcMdmZOgVDCa-x+p1vQ@mail.gmail.com>

Does the response actually contain the roles though? You're parsing to
UserRepresentation
then printing it out afterwards.

On 30 September 2015 at 13:24, Remi Cartier <remi.cartier at imetrik.com>
wrote:

> Marek,
>
> I see, thank you for your reply.
>
> Wouldn't it be less error/question prone if the endpoint returning all the
> users wouldn't show the *roles attributes ?
> Because they will always be null if I understood correctly.
>
> Regards.
>
> R?mi.
>
> ------------------------------
> *From:* Marek Posolda [mposolda at redhat.com]
> *Sent:* Wednesday, September 30, 2015 6:21 AM
> *To:* Remi Cartier; keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Admin REST - User Roles
>
> Hi,
>
> to retrieve realm role mappings of user, you need to use the endpoint like
> http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm
> . See the docs for details:
> http://keycloak.github.io/docs/rest-api/overview-index.html
>
> Marek
>
> On 29/09/15 19:06, Remi Cartier wrote:
>
> Hi guys,
>
> first of all, thank you for that great piece of software, it?s amazing !
>
> Now, down to business.
>
> When I do :
>
>         keycloak = Keycloak.getInstance(getKeycloakServerURL(),
> getKeycloakRealm(), getKeycloakRealmAdminUsername(),
> getKeycloakRealmAdminPassword(), getKeycloakClientId());
>         for (UserRepresentation userRepresentation :
> keycloak.realm(getKeycloakRealm()).users().search(null, 0,
> Integer.MAX_VALUE)) {
>             log.info(ToStringBuilder.reflectionToString(userRepresentation,
> ToStringStyle.JSON_STYLE));
>         }
>
> The information I get does not contain any roles, all the roles related
> fields are ?null?. -
>
> {"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first
> name","lastName":"last
> name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}
> However in the admin interface I have setup roles at each layer : realm,
> client
>
> The user I am using to do the queries has all the *realm* roles associated.
>
> is there anything else I need to do ?
>
> thank you for your help !
>
> ------------------------------
>
>
> REMI CARTIER
> B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)
>
> *IMETRIK GLOBAL INC.*
> *T :* +1 514 448-6407 x2009
> *T :* +1 866 276-5382 (toll free)
> *F :* +1 514 904-0611
>
> 740 Notre Dame St. West, Suite 1575
> Montreal, Quebec, Canada H3C 3X6
> imetrik.com <http://www.imetrik.com/>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150930/43647599/attachment-0001.html 

From gerbermichi at me.com  Wed Sep 30 09:39:02 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Wed, 30 Sep 2015 13:39:02 +0000 (GMT)
Subject: [keycloak-dev] Kerberos, login with different user
Message-ID: <6e94d164-47f4-4eb0-ba7f-063614e09159@me.com>

Hi all,

I would like to use kerberos as my standard authentication mechanism, but I also want to have the possibility to log in as an admin over the login form.?
Therefore, I want to skip the kerberos authenticator after a successful logout.
https://issues.jboss.org/browse/KEYCLOAK-1727

How would you solve this problem?

I've got two solutions, one sets a logout session cookie after a logout and then skips the kerberos authentication and another which allows users to skip any kind of alternative authenticators with a query parameter.

Logout Session Cookie
https://github.com/gerbermichi/keycloak/commit/f804d9e13573cb666cf6d2eff1407978c9e5e854

Query Param
https://github.com/gerbermichi/keycloak/commit/abd3bd87f5aa4c28914da677653268c0f44fe6cc

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150930/24b5b579/attachment.html 

From remi.cartier at imetrik.com  Wed Sep 30 10:24:15 2015
From: remi.cartier at imetrik.com (Remi Cartier)
Date: Wed, 30 Sep 2015 14:24:15 +0000
Subject: [keycloak-dev] Admin REST - User Roles
In-Reply-To: <CAJgngAf2mL7v-MfN4U+OP4Nh1G_z7oeQcMdmZOgVDCa-x+p1vQ@mail.gmail.com>
References: <D36DF142-FA22-45C5-A102-FA4F9E5974BF@imetrik.com>
	<560BB7AC.6040501@redhat.com>
	<E8731B3C90D3134890657137AEA79B65011311B52B@MTL01-DC03.imetrik.com>,
	<CAJgngAf2mL7v-MfN4U+OP4Nh1G_z7oeQcMdmZOgVDCa-x+p1vQ@mail.gmail.com>
Message-ID: <E8731B3C90D3134890657137AEA79B65011311C583@MTL01-DC03.imetrik.com>

The JSON response (string) does NOT contain any roles.

________________________________
From: Stian Thorgersen [sthorger at redhat.com]
Sent: Wednesday, September 30, 2015 7:39 AM
To: Remi Cartier
Cc: Marek Posolda; keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Admin REST - User Roles

Does the response actually contain the roles though? You're parsing to UserRepresentation then printing it out afterwards.

On 30 September 2015 at 13:24, Remi Cartier <remi.cartier at imetrik.com<mailto:remi.cartier at imetrik.com>> wrote:
Marek,

I see, thank you for your reply.

Wouldn't it be less error/question prone if the endpoint returning all the users wouldn't show the *roles attributes ?
Because they will always be null if I understood correctly.

Regards.

R?mi.

________________________________
From: Marek Posolda [mposolda at redhat.com<mailto:mposolda at redhat.com>]
Sent: Wednesday, September 30, 2015 6:21 AM
To: Remi Cartier; keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Admin REST - User Roles

Hi,

to retrieve realm role mappings of user, you need to use the endpoint like http://localhost:8080/auth/admin/realms/demo/users/{userid}/role-mappings/realm . See the docs for details: http://keycloak.github.io/docs/rest-api/overview-index.html

Marek

On 29/09/15 19:06, Remi Cartier wrote:
Hi guys,

first of all, thank you for that great piece of software, it?s amazing !

Now, down to business.

When I do :

        keycloak = Keycloak.getInstance(getKeycloakServerURL(), getKeycloakRealm(), getKeycloakRealmAdminUsername(), getKeycloakRealmAdminPassword(), getKeycloakClientId());
        for (UserRepresentation userRepresentation : keycloak.realm(getKeycloakRealm()).users().search(null, 0, Integer.MAX_VALUE)) {
            log.info<http://log.info>(ToStringBuilder.reflectionToString(userRepresentation, ToStringStyle.JSON_STYLE));
        }

The information I get does not contain any roles, all the roles related fields are ?null?. -

{"self":null,"id":"0556717e-ffb9-4c2d-b85b-533d9396f243","createdTimestamp":1443542144845,"username":"admin","enabled":true,"totp":false,"emailVerified":true,"firstName":"first name","lastName":"last name","email":null,"federationLink":null,"serviceAccountClientId":null,"attributes":{key1=[value1]},"credentials":null,"requiredActions":[],"federatedIdentities":null,"realmRoles":null,"clientRoles":null,"clientConsents":null,"applicationRoles":null,"socialLinks":null}
However in the admin interface I have setup roles at each layer : realm, client

The user I am using to do the queries has all the *realm* roles associated.

is there anything else I need to do ?

thank you for your help !

________________________________

REMI CARTIER
B.O.S.S. (Business & Operation Support Systems) P.O (Product Owner)

IMETRIK GLOBAL INC.
T : +1 514 448-6407 x2009<tel:514%20448-6407%20x2009>
T : +1 866 276-5382<tel:866%20276-5382> (toll free)
F : +1 514 904-0611<tel:514%20904-0611>

740 Notre Dame St. West, Suite 1575
Montreal, Quebec, Canada H3C 3X6
imetrik.com<http://www.imetrik.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

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

From ssilvert at redhat.com  Wed Sep 30 19:53:07 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 30 Sep 2015 19:53:07 -0400
Subject: [keycloak-dev] Testing Migration?
Message-ID: <560C75E3.10706@redhat.com>

I've never tested migration before and I wonder if I'm doing it right.   
Keycloak 1.6 server dies before the migration code is ever executed.  
Here is what I did:

Download Keycloak 1.5
Start the server, add a couple of users and a new realm.
Build Keycloak 1.6
Copy the database from 1.5 to 1.6
Start Keycloak 1.6

I get:

19:40:03,411 INFO  [org.hibernate.Version] (ServerService Thread Pool -- 
61) HHH000412: Hibernate Core {4.3.10.Final}
19:40:03,413 INFO  [org.hibernate.cfg.Environment] (ServerService Thread 
Pool -- 61) HHH000206: hibernate.properties not found
19:40:03,414 INFO  [org.hibernate.cfg.Environment] (ServerService Thread 
Pool -- 61) HHH000021: Bytecode provider name : javassist
19:40:03,511 INFO  [org.hibernate.annotations.common.Version] 
(ServerService Thread Pool -- 61) HCANN000001: Hibernate Commons 
Annotations {4.0.5.Final}
19:40:03,551 INFO  [org.hibernate.dialect.Dialect] (ServerService Thread 
Pool -- 61) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
19:40:03,556 WARN  [org.hibernate.dialect.H2Dialect] (ServerService 
Thread Pool -- 61) HHH000431: Unable to determine H2 database version, 
certain features may not work
19:40:03,761 INFO 
[org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] 
(ServerService Thread Pool -- 61) HHH000397: Using ASTQueryTranslatorFactory
19:40:03,789 INFO  [org.hibernate.validator.internal.util.Version] 
(ServerService Thread Pool -- 61) HV000001: Hibernate Validator 5.1.3.Final
19:40:04,857 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] 
(ServerService Thread Pool -- 61) SQL Error: 42122, SQLState: 42S22
19:40:04,857 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] 
(ServerService Thread Pool -- 61) Column "CLIENTENTI1_.ROOT_URL" not 
found; SQL statement:
select realmentit0_.ID as ID1_25_0_, realmentit0_.ACCESS_CODE_LIFESPAN 
as ACCESS_C2_25_0_, realmentit0_.LOGIN_LIFESPAN as LOGIN_LI3_25_0_, 
realmentit0_.USER_ACTION_LIFESP
AN as USER_ACT4_25_0_, realmentit0_.ACCESS_TOKEN_LIFESPAN as 
ACCESS_T5_25_0_, realmentit0_.ACCOUNT_THEME as ACCOUNT_6_25_0_, 
realmentit0_.ADMIN_EVENTS_DETAILS_ENABLED as
ADMIN_EV7_25_0_, realmentit0_.ADMIN_EVENTS_ENABLED as ADMIN_EV8_25_0_, 
realmentit0_.ADMIN_THEME as ADMIN_TH9_25_0_, realmentit0_.BROWSER_FLOW 
as BROWSER10_25_0_, realment
it0_.CERTIFICATE as CERTIFI11_25_0_, realmentit0_.CLIENT_AUTH_FLOW as 
CLIENT_12_25_0_, realmentit0_.CODE_SECRET as CODE_SE13_25_0_, 
realmentit0_.DEFAULT_LOCALE as DEFAULT
... long SQL blah blah blah ...
19:40:04,911 INFO 
[org.hibernate.event.internal.DefaultLoadEventListener] (ServerService 
Thread Pool -- 61) HHH000327: Error performing load command : 
org.hibernate.exception.SQLGrammarException: could not prepare statement
19:40:04,913 ERROR [org.jboss.msc.service.fail] (ServerService Thread 
Pool -- 61) MSC000001: Failed to start service 
jboss.undertow.deployment.default-server.default-host./auth: 
org.jboss.msc.service.StartException in service 
jboss.undertow.deployment.default-server.default-host./auth: 
java.lang.RuntimeException: Failed to construct public 
org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher)
         at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
         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: java.lang.RuntimeException: Failed to construct public 
org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core
.Dispatcher)
         at 
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160)
         at 
org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211)
         at 
org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295)
         at 
org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236)
         at 
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112)
         at 
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36)
         at 
io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
         at 
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:230)
         at 
io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:131)
         at 
io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:511)
         at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101)
         at 
org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
         ... 6 more
Caused by: org.keycloak.models.ModelException: 
javax.persistence.PersistenceException: 
org.hibernate.exception.SQLGrammarException: could not prepare statement
         at 
org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44)
         at 
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34)
         at com.sun.proxy.$Proxy57.find(Unknown Source)
         at 
org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63)
         at 
org.keycloak.models.cache.infinispan.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:150)
         at 
org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40)
         at 
org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31)
         at 
org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:158)
         at 
org.keycloak.services.resources.KeycloakApplication.<init>(KeycloakApplication.java:88)
         at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
         at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
         at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
         at 
org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148)
         ... 19 more
Caused by: javax.persistence.PersistenceException: 
org.hibernate.exception.SQLGrammarException: could not prepare statement
         at 
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763)
         at 
org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694)
         at 
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141)
         at 
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
         at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
         at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
         at java.lang.reflect.Method.invoke(Method.java:497)
         at 
org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32)
         ... 31 more
Caused by: org.hibernate.exception.SQLGrammarException: could not 
prepare statement
         at 
org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:123)
         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.internal.StatementPreparerImpl$StatementPreparationTemplate.prepareStatement(StatementPreparerImpl.java:196)
         at 
org.hibernate.engine.jdbc.internal.StatementPreparerImpl.prepareQueryStatement(StatementPreparerImpl.java:160)
         at 
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.prepareQueryStatement(AbstractLoadPlanBasedLoader.java:257)
         at 
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeQueryStatement(AbstractLoadPlanBasedLoader.java:201)
         at 
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:137)
         at 
org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102)
         at 
org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186)
         at 
org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126)
         at 
org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503)
         at 
org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468)
         at 
org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213)
         at 
org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275)
         at 
org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151)
         at 
org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1106)
         at 
org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176)
         at 
org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2587)
         at org.hibernate.internal.SessionImpl.get(SessionImpl.java:991)
         at 
org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110)
         ... 37 more