From stian at redhat.com  Wed Apr  1 00:29:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 00:29:31 -0400 (EDT)
Subject: [keycloak-dev] brokered username
In-Reply-To: <551B3DE0.2080205@redhat.com>
References: <551B3DE0.2080205@redhat.com>
Message-ID: <1329960713.9712212.1427862571894.JavaMail.zimbra@redhat.com>

Works for now.

We need to improve on this soon though, it's been outstanding to long. My proposal is:

1. We set a attribute on user that username is generated
2. When username is generated username/password is not displayed in account management
3. We add an option on a identity provider to set if users can enable regular login or not, values for this feature is on/off/required
4. If this is enabled in account management there's an option to set username/password to enable regular login - only once then it converts to displaying username + password reset
5. We add a require action to set username/password - if the option in 3 is set to required after first login with identity provider the user is required to set username + password to enable account
6. We also add an option on a realm to allow users to change username



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 2:37:52 AM
> Subject: [keycloak-dev] brokered username
> 
> When a user gets created I am changing it so that the UserModel username
> will be:
> 
> brokerAlias + "." + username-imported-from-broker
> 
> This is so that we don't have username conflicts.  The downside is that
> if anybody relies on username, it will now have all these extra
> characters i.e. "facebook.bburke123" instead of "bburke123"
> 
> Is this an ok stopgap until we have a better solution?  I think just
> making the username null opens up a wide variety of potential problems
> as a lot of our codebase is dependent on username.
> 
> --
> 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  Wed Apr  1 09:05:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 09:05:35 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <1549480132.10045380.1427893315263.JavaMail.zimbra@redhat.com>
Message-ID: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>

What are the outstanding issues before we can release?

I've been going through bits and pieces and doing some testing, Marek is doing the same (he's testing saml, broker, cors, kerberos examples and is also going to verify db upgrades).

The status of testing is here https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing 

I've identified one issue in the admin console:

* https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider tab for an application is just blank, it should display a list of providers and the option to allow the app to retrieve the tokens. Anyone got a clue what's going on?

From bburke at redhat.com  Wed Apr  1 09:22:57 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 09:22:57 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
Message-ID: <551BF131.9050306@redhat.com>

Has the auth server been tested on EAP 6.x?  Not sure what "Runtimes" 
mean in your test doc.

On 4/1/2015 9:05 AM, Stian Thorgersen wrote:
> What are the outstanding issues before we can release?
>
> I've been going through bits and pieces and doing some testing, Marek is doing the same (he's testing saml, broker, cors, kerberos examples and is also going to verify db upgrades).
>
> The status of testing is here https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing
>
> I've identified one issue in the admin console:
>
> * https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider tab for an application is just blank, it should display a list of providers and the option to allow the app to retrieve the tokens. Anyone got a clue what's going on?
> _______________________________________________
> 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 Apr  1 09:37:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 09:37:16 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <551BF131.9050306@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
Message-ID: <1504820169.10072581.1427895436967.JavaMail.zimbra@redhat.com>

Yep, I've tested EAP 6.2, 6.3 and 6.4

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 3:22:57 PM
> Subject: Re: [keycloak-dev] Release status
> 
> Has the auth server been tested on EAP 6.x?  Not sure what "Runtimes"
> mean in your test doc.
> 
> On 4/1/2015 9:05 AM, Stian Thorgersen wrote:
> > What are the outstanding issues before we can release?
> >
> > I've been going through bits and pieces and doing some testing, Marek is
> > doing the same (he's testing saml, broker, cors, kerberos examples and is
> > also going to verify db upgrades).
> >
> > The status of testing is here
> > https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing
> >
> > I've identified one issue in the admin console:
> >
> > * https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider tab
> > for an application is just blank, it should display a list of providers
> > and the option to allow the app to retrieve the tokens. Anyone got a clue
> > what's going on?
> > _______________________________________________
> > 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  Wed Apr  1 10:14:42 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 10:14:42 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <551BF131.9050306@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
Message-ID: <785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>

Bill - do you know what's going on with https://issues.jboss.org/browse/KEYCLOAK-1172?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 3:22:57 PM
> Subject: Re: [keycloak-dev] Release status
> 
> Has the auth server been tested on EAP 6.x?  Not sure what "Runtimes"
> mean in your test doc.
> 
> On 4/1/2015 9:05 AM, Stian Thorgersen wrote:
> > What are the outstanding issues before we can release?
> >
> > I've been going through bits and pieces and doing some testing, Marek is
> > doing the same (he's testing saml, broker, cors, kerberos examples and is
> > also going to verify db upgrades).
> >
> > The status of testing is here
> > https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing
> >
> > I've identified one issue in the admin console:
> >
> > * https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider tab
> > for an application is just blank, it should display a list of providers
> > and the option to allow the app to retrieve the tokens. Anyone got a clue
> > what's going on?
> > _______________________________________________
> > 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  Wed Apr  1 10:22:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 10:22:42 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
Message-ID: <551BFF32.9060206@redhat.com>

No, I don't.  I"ll look into it after I finish this one thing.

Probably should be implemented differently anyways.  Token exchange 
service should be an application with a role that can be assigned to 
user or applied via a protocol mapper.

On 4/1/2015 10:14 AM, Stian Thorgersen wrote:
> Bill - do you know what's going on with https://issues.jboss.org/browse/KEYCLOAK-1172?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 1 April, 2015 3:22:57 PM
>> Subject: Re: [keycloak-dev] Release status
>>
>> Has the auth server been tested on EAP 6.x?  Not sure what "Runtimes"
>> mean in your test doc.
>>
>> On 4/1/2015 9:05 AM, Stian Thorgersen wrote:
>>> What are the outstanding issues before we can release?
>>>
>>> I've been going through bits and pieces and doing some testing, Marek is
>>> doing the same (he's testing saml, broker, cors, kerberos examples and is
>>> also going to verify db upgrades).
>>>
>>> The status of testing is here
>>> https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing
>>>
>>> I've identified one issue in the admin console:
>>>
>>> * https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider tab
>>> for an application is just blank, it should display a list of providers
>>> and the option to allow the app to retrieve the tokens. Anyone got a clue
>>> what's going on?
>>> _______________________________________________
>>> 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  Wed Apr  1 10:29:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 10:29:13 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <551BFF32.9060206@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
	<551BFF32.9060206@redhat.com>
Message-ID: <18230907.10124042.1427898553264.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, 1 April, 2015 4:22:42 PM
> Subject: Re: [keycloak-dev] Release status
> 
> No, I don't.  I"ll look into it after I finish this one thing.
> 
> Probably should be implemented differently anyways.  Token exchange
> service should be an application with a role that can be assigned to
> user or applied via a protocol mapper.

Yes, token exchange service as app and role sounds much better. That would let you control what users (role-mapping) and apps (scope) that are allowed to access it. Would also work with existing grant features if an "oauth client" request access. Shame we don't have time to change it now, as it'll probably be a bit of work?!

> 
> On 4/1/2015 10:14 AM, Stian Thorgersen wrote:
> > Bill - do you know what's going on with
> > https://issues.jboss.org/browse/KEYCLOAK-1172?
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 1 April, 2015 3:22:57 PM
> >> Subject: Re: [keycloak-dev] Release status
> >>
> >> Has the auth server been tested on EAP 6.x?  Not sure what "Runtimes"
> >> mean in your test doc.
> >>
> >> On 4/1/2015 9:05 AM, Stian Thorgersen wrote:
> >>> What are the outstanding issues before we can release?
> >>>
> >>> I've been going through bits and pieces and doing some testing, Marek is
> >>> doing the same (he's testing saml, broker, cors, kerberos examples and is
> >>> also going to verify db upgrades).
> >>>
> >>> The status of testing is here
> >>> https://docs.google.com/spreadsheets/d/17C_WEHNE03r5DxN71OXGJaytjA6_WjZKCXRcsnmNQD4/edit?usp=sharing
> >>>
> >>> I've identified one issue in the admin console:
> >>>
> >>> * https://issues.jboss.org/browse/KEYCLOAK-1172 - the identity provider
> >>> tab
> >>> for an application is just blank, it should display a list of providers
> >>> and the option to allow the app to retrieve the tokens. Anyone got a clue
> >>> what's going on?
> >>> _______________________________________________
> >>> 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 bburke at redhat.com  Wed Apr  1 10:32:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 10:32:25 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
	<551BFF32.9060206@redhat.com>
	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
Message-ID: <551C0179.7040106@redhat.com>



On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
>
>
> ----- 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, 1 April, 2015 4:22:42 PM
>> Subject: Re: [keycloak-dev] Release status
>>
>> No, I don't.  I"ll look into it after I finish this one thing.
>>
>> Probably should be implemented differently anyways.  Token exchange
>> service should be an application with a role that can be assigned to
>> user or applied via a protocol mapper.
>
> Yes, token exchange service as app and role sounds much better. That would let you control what users (role-mapping) and apps (scope) that are allowed to access it. Would also work with existing grant features if an "oauth client" request access. Shame we don't have time to change it now, as it'll probably be a bit of work?!
>

Can't be done by tomorrow.  Should I just disable the identity provider 
tab until we do this?  Or are users asking for access to external tokens?

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

From stian at redhat.com  Wed Apr  1 10:35:53 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 10:35:53 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <551C0179.7040106@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
	<551BFF32.9060206@redhat.com>
	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
	<551C0179.7040106@redhat.com>
Message-ID: <398594630.10135210.1427898953993.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, 1 April, 2015 4:32:25 PM
> Subject: Re: [keycloak-dev] Release status
> 
> 
> 
> On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
> >
> >
> > ----- 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, 1 April, 2015 4:22:42 PM
> >> Subject: Re: [keycloak-dev] Release status
> >>
> >> No, I don't.  I"ll look into it after I finish this one thing.
> >>
> >> Probably should be implemented differently anyways.  Token exchange
> >> service should be an application with a role that can be assigned to
> >> user or applied via a protocol mapper.
> >
> > Yes, token exchange service as app and role sounds much better. That would
> > let you control what users (role-mapping) and apps (scope) that are
> > allowed to access it. Would also work with existing grant features if an
> > "oauth client" request access. Shame we don't have time to change it now,
> > as it'll probably be a bit of work?!
> >
> 
> Can't be done by tomorrow.  Should I just disable the identity provider
> tab until we do this?  Or are users asking for access to external tokens?

+1 Let's just disable

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

From bburke at redhat.com  Wed Apr  1 10:42:28 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 10:42:28 -0400
Subject: [keycloak-dev] Release status
In-Reply-To: <551C0179.7040106@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>	<551BF131.9050306@redhat.com>	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>	<551BFF32.9060206@redhat.com>	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
	<551C0179.7040106@redhat.com>
Message-ID: <551C03D4.7010608@redhat.com>

Also, a bunch of things about this Token Exchange service bug me making 
me think we shouldn't expose it at this time.

* External tokens shouldn't be stored in user storage.  While social 
tokens are often long living, brokered tokens aren't.  They should 
instead be stored in the UserSession.
* The current implementation of this service stores the entire 
SAMLREsponse document for SAML, and the entire AccessTokenResponse for 
OIDC.  Probably not the most user friendly or greatest idea.
* OIDC has two tokens.  IDToken and Access token.  Both might be needed 
by client app or user.

On 4/1/2015 10:32 AM, Bill Burke wrote:
>
>
> On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
>>
>>
>> ----- 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, 1 April, 2015 4:22:42 PM
>>> Subject: Re: [keycloak-dev] Release status
>>>
>>> No, I don't.  I"ll look into it after I finish this one thing.
>>>
>>> Probably should be implemented differently anyways.  Token exchange
>>> service should be an application with a role that can be assigned to
>>> user or applied via a protocol mapper.
>>
>> Yes, token exchange service as app and role sounds much better. That would let you control what users (role-mapping) and apps (scope) that are allowed to access it. Would also work with existing grant features if an "oauth client" request access. Shame we don't have time to change it now, as it'll probably be a bit of work?!
>>
>
> Can't be done by tomorrow.  Should I just disable the identity provider
> tab until we do this?  Or are users asking for access to external tokens?
>

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

From bburke at redhat.com  Wed Apr  1 10:48:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 10:48:04 -0400
Subject: [keycloak-dev] token exchange
In-Reply-To: <551C03D4.7010608@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>	<551BF131.9050306@redhat.com>	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>	<551BFF32.9060206@redhat.com>	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>	<551C0179.7040106@redhat.com>
	<551C03D4.7010608@redhat.com>
Message-ID: <551C0524.6020800@redhat.com>

Another reason not to store tokens in user storage:

* For saml and oidc at least, the token lifespan is tied to the parent 
IDP's UserSession lifetime.  If a logout is triggered at the parent IDP, 
then these tokens are no longer valid.
* If a user relogins in, then the token is refreshed, which would 
require a database write to the usermodel.



On 4/1/2015 10:42 AM, Bill Burke wrote:
> Also, a bunch of things about this Token Exchange service bug me making
> me think we shouldn't expose it at this time.
>
> * External tokens shouldn't be stored in user storage.  While social
> tokens are often long living, brokered tokens aren't.  They should
> instead be stored in the UserSession.
> * The current implementation of this service stores the entire
> SAMLREsponse document for SAML, and the entire AccessTokenResponse for
> OIDC.  Probably not the most user friendly or greatest idea.
> * OIDC has two tokens.  IDToken and Access token.  Both might be needed
> by client app or user.
>

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

From bburke at redhat.com  Wed Apr  1 10:53:45 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 01 Apr 2015 10:53:45 -0400
Subject: [keycloak-dev] offline access
Message-ID: <551C0679.9090808@redhat.com>

Wanted to discuss again how offline access might be implemented.  IMO, 
offline access should be a REST api.  Clients would request offline 
access and the UserSession would be cloned and the ClientSession would 
be cloned for that particular client.  ID, Access token and refresh 
token would also be regenerated and sent back with the response.

With this approach, the admin console and user account session 
management pages will just work.  These pages will just work they way 
they already work with no extra changes.

Additionally, we would want to allow different session timeouts for 
offline access.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed Apr  1 11:29:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 11:29:19 -0400 (EDT)
Subject: [keycloak-dev] Release status
In-Reply-To: <551C03D4.7010608@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
	<551BFF32.9060206@redhat.com>
	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
	<551C0179.7040106@redhat.com> <551C03D4.7010608@redhat.com>
Message-ID: <2138099394.10192334.1427902159208.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 4:42:28 PM
> Subject: Re: [keycloak-dev] Release status
> 
> Also, a bunch of things about this Token Exchange service bug me making
> me think we shouldn't expose it at this time.

Agree there's some kinks we should work out, so let's hide the "store tokens" option for an identity provider as well as the identity provider tab under applications.

> 
> * External tokens shouldn't be stored in user storage.  While social
> tokens are often long living, brokered tokens aren't.  They should
> instead be stored in the UserSession.

Brokered tokens can be long living, for example offline tokens which we should add support for in KC. As I've said before there's two use-cases for brokering one is authentication the other is access. For access you quite likely want an offline token to permanently get access to an external service after linking the account.

However, offline tokens will most likely be the exception not the rule, so I agree we should store most tokens in user-session, but also have the ability to store offline tokens in user storage (or another permanent store). By the way for a user session it would only make sense to store a single token, which is the token used to authenticate with, but when you're linking an account you may want to store an offline token.

> * The current implementation of this service stores the entire
> SAMLREsponse document for SAML, and the entire AccessTokenResponse for
> OIDC.  Probably not the most user friendly or greatest idea.
> * OIDC has two tokens.  IDToken and Access token.  Both might be needed
> by client app or user.
> 
> On 4/1/2015 10:32 AM, Bill Burke wrote:
> >
> >
> > On 4/1/2015 10:29 AM, Stian Thorgersen wrote:
> >>
> >>
> >> ----- 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, 1 April, 2015 4:22:42 PM
> >>> Subject: Re: [keycloak-dev] Release status
> >>>
> >>> No, I don't.  I"ll look into it after I finish this one thing.
> >>>
> >>> Probably should be implemented differently anyways.  Token exchange
> >>> service should be an application with a role that can be assigned to
> >>> user or applied via a protocol mapper.
> >>
> >> Yes, token exchange service as app and role sounds much better. That would
> >> let you control what users (role-mapping) and apps (scope) that are
> >> allowed to access it. Would also work with existing grant features if an
> >> "oauth client" request access. Shame we don't have time to change it now,
> >> as it'll probably be a bit of work?!
> >>
> >
> > Can't be done by tomorrow.  Should I just disable the identity provider
> > tab until we do this?  Or are users asking for access to external tokens?
> >
> 
> --
> 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 mposolda at redhat.com  Wed Apr  1 12:10:55 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 01 Apr 2015 18:10:55 +0200
Subject: [keycloak-dev] Release status
In-Reply-To: <2138099394.10192334.1427902159208.JavaMail.zimbra@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>	<551BF131.9050306@redhat.com>	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>	<551BFF32.9060206@redhat.com>	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>	<551C0179.7040106@redhat.com>
	<551C03D4.7010608@redhat.com>
	<2138099394.10192334.1427902159208.JavaMail.zimbra@redhat.com>
Message-ID: <551C188F.6090004@redhat.com>

On 1.4.2015 17:29, Stian Thorgersen wrote:
>> Also, a bunch of things about this Token Exchange service bug me making
>> >me think we shouldn't expose it at this time.
> Agree there's some kinks we should work out, so let's hide the "store tokens" option for an identity provider as well as the identity provider tab under applications.
>
Hmm... what about broker examples then? Those are using "storeTokens" 
feature. Should we remove them from the examples distribution for this 
release?

If we're just hide the option in admin console but not remove anything 
from model/representation, the examples should still work though. 
Similarly the tests, which are using storeTokens stuff.

Marek

From stian at redhat.com  Wed Apr  1 13:19:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 13:19:59 -0400 (EDT)
Subject: [keycloak-dev] token exchange
In-Reply-To: <551C0524.6020800@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>
	<551BF131.9050306@redhat.com>
	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>
	<551BFF32.9060206@redhat.com>
	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>
	<551C0179.7040106@redhat.com> <551C03D4.7010608@redhat.com>
	<551C0524.6020800@redhat.com>
Message-ID: <265944867.10270211.1427908799817.JavaMail.zimbra@redhat.com>

As I've said several times now there are two use-cases for tokens:

1. Authentication - here a IdP is used mainly to authenticate a user. The token can (and should probably) be kept in use session. In this case it makes perfect sense to refresh the token alongside the main token.

2. Access - here a IdP is used to gain access to external resources. In this case when a user links the account an offline token is obtained from the external IdP. This token has a long lifetime and has to be stored in user storage (user session is not permanent). In this case an application may use one or more offline tokens that are associated with the account. In this case logout of a user session should not log-out the external IdP as it was not used for authentication. In this case a token  should be refreshed when required by the application. A user account may be linked with multiple IdP each with an offline token, but that doesn't mean they are used all the time. This is not only for social, other IdPs have offline token support as well, we will also.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 4:48:04 PM
> Subject: [keycloak-dev] token exchange
> 
> Another reason not to store tokens in user storage:
> 
> * For saml and oidc at least, the token lifespan is tied to the parent
> IDP's UserSession lifetime.  If a logout is triggered at the parent IDP,
> then these tokens are no longer valid.
> * If a user relogins in, then the token is refreshed, which would
> require a database write to the usermodel.
> 
> 
> 
> On 4/1/2015 10:42 AM, Bill Burke wrote:
> > Also, a bunch of things about this Token Exchange service bug me making
> > me think we shouldn't expose it at this time.
> >
> > * External tokens shouldn't be stored in user storage.  While social
> > tokens are often long living, brokered tokens aren't.  They should
> > instead be stored in the UserSession.
> > * The current implementation of this service stores the entire
> > SAMLREsponse document for SAML, and the entire AccessTokenResponse for
> > OIDC.  Probably not the most user friendly or greatest idea.
> > * OIDC has two tokens.  IDToken and Access token.  Both might be needed
> > by client app or user.
> >
> 
> --
> 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  Wed Apr  1 13:26:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 1 Apr 2015 13:26:06 -0400 (EDT)
Subject: [keycloak-dev] offline access
In-Reply-To: <551C0679.9090808@redhat.com>
References: <551C0679.9090808@redhat.com>
Message-ID: <126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>

I'm not to keen on that idea.

offline is a standard scope in OIDC and an application requests this when first retrieving the token. When an application retrieves a refresh token with the offline scope set it should not be linked with the user session. Instead it should be stored permanently as the application now should have permanent offline access to the users account. If a user decides to revoke the applications access that should be done by going to the account management console and viewing client that have access to their account. This page should list all available clients, what clients have persisted grants, as well as what clients have offline access to their account. From the same page they should be able to revoke access from any client.

As user sessions are not persisted they are not suitable to store offline tokens. Offline tokens will often have a very long expiration time, a year or even no expiration time at all (only manual revoking).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 4:53:45 PM
> Subject: [keycloak-dev] offline access
> 
> Wanted to discuss again how offline access might be implemented.  IMO,
> offline access should be a REST api.  Clients would request offline
> access and the UserSession would be cloned and the ClientSession would
> be cloned for that particular client.  ID, Access token and refresh
> token would also be regenerated and sent back with the response.
> 
> With this approach, the admin console and user account session
> management pages will just work.  These pages will just work they way
> they already work with no extra changes.
> 
> Additionally, we would want to allow different session timeouts for
> offline access.
> --
> 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  Wed Apr  1 17:00:23 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 01 Apr 2015 17:00:23 -0400
Subject: [keycloak-dev] WildFly 9 adapter support
In-Reply-To: <CA+sftsDiNnkE4mC=Czt48rM9dJYLgtzHjsx89Cx-Vce9hzX1Mw@mail.gmail.com>
References: <CA+sftsDiNnkE4mC=Czt48rM9dJYLgtzHjsx89Cx-Vce9hzX1Mw@mail.gmail.com>
Message-ID: <551C5C67.4000303@redhat.com>

Looks like a fix might take awhile. Here is a Jira you can watch if you 
want to follow the progress:
https://issues.jboss.org/browse/KEYCLOAK-1174

On 3/31/2015 4:51 PM, Leonardo Loch Zanivan wrote:
> I'm trying to deploy a keycloak secured application in WildFly 
> 9.0.0-Beta2, but I got a NPE.
>
> It's working fine with WildFly 8.1.0-Final.
>
> 17:41:19,764 ERROR [org.jboss.msc.service.fail] (MSC service thread 
> 1-2) MSC000001: Failed to start service 
> jboss.deployment.unit."app.war".POST_MODULE: 
> org.jboss.msc.service.StartException in service 
> jboss.deployment.unit."app.war".POST_MODULE: WFLYSRV0153: Failed to 
> process phase POST_MODULE of deployment "app.war"
>     at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
>     at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
>     at 
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
>     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)
> *Caused by: java.lang.NullPointerException
>     at 
> org.keycloak.subsystem.extension.KeycloakAdapterConfigDeploymentProcessor.deploy(KeycloakAdapterConfigDeploymentProcessor.java:73)*
>     at 
> org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
>     ... 5 more
>
> 17:41:19,770 ERROR [org.jboss.as.controller.management-operation] 
> (management-handler-thread - 1) WFLYCTL0013: Operation ("deploy") 
> failed - address: ([("deployment" => "app.war")]) - failure 
> description: {"WFLYCTL0080: Failed services" => 
> {"jboss.deployment.unit.\"app.war\".POST_MODULE" => 
> "org.jboss.msc.service.StartException in service 
> jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to 
> process phase POST_MODULE of deployment \"app.war\"
>     Caused by: java.lang.NullPointerException"}}
> 17:41:19,771 ERROR [org.jboss.as.server] (management-handler-thread - 
> 1) WFLYSRV0021: Deploy of deployment "app.war" was rolled back with 
> the following failure message:
> {"WFLYCTL0080: Failed services" => 
> {"jboss.deployment.unit.\"app.war\".POST_MODULE" => 
> "org.jboss.msc.service.StartException in service 
> jboss.deployment.unit.\"app.war\".POST_MODULE: WFLYSRV0153: Failed to 
> process phase POST_MODULE of deployment \"app.war\"
>     Caused by: java.lang.NullPointerException"}}
>
>
>
> _______________________________________________
> 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/20150401/596d58dd/attachment-0001.html 

From mposolda at redhat.com  Thu Apr  2 03:45:16 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 02 Apr 2015 09:45:16 +0200
Subject: [keycloak-dev] Release status
In-Reply-To: <551C188F.6090004@redhat.com>
References: <86045624.10048139.1427893535846.JavaMail.zimbra@redhat.com>	<551BF131.9050306@redhat.com>	<785465966.10108666.1427897682755.JavaMail.zimbra@redhat.com>	<551BFF32.9060206@redhat.com>	<18230907.10124042.1427898553264.JavaMail.zimbra@redhat.com>	<551C0179.7040106@redhat.com>	<551C03D4.7010608@redhat.com>	<2138099394.10192334.1427902159208.JavaMail.zimbra@redhat.com>
	<551C188F.6090004@redhat.com>
Message-ID: <551CF38C.40105@redhat.com>

Should we actually hide the option "Store tokens" from the identity 
provider configuration? Seeing that application tab is removed and 
broker examples as well, but this one is still here.

Marek

On 1.4.2015 18:10, Marek Posolda wrote:
> On 1.4.2015 17:29, Stian Thorgersen wrote:
>>> Also, a bunch of things about this Token Exchange service bug me making
>>>> me think we shouldn't expose it at this time.
>> Agree there's some kinks we should work out, so let's hide the "store tokens" option for an identity provider as well as the identity provider tab under applications.
>>
> Hmm... what about broker examples then? Those are using "storeTokens"
> feature. Should we remove them from the examples distribution for this
> release?
>
> If we're just hide the option in admin console but not remove anything
> from model/representation, the examples should still work though.
> Similarly the tests, which are using storeTokens stuff.
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Apr  2 07:52:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Apr 2015 07:52:54 -0400 (EDT)
Subject: [keycloak-dev] offline access
In-Reply-To: <126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
Message-ID: <2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>

Had an idea about offline tokens.

When a user grants a client access we need to start persisting that so we don't ask the user again and again for the same permissions to be given to the application. This has to be stored permanently and not in user session. That's the mechanism we should use for offline tokens.

When a user grants an application offline access that grant is persisted. This should be a special role. The grant should have an id and consist of: grant_id, user_id, client_id, role_id. If a refresh token has the offline scope it doesn't have to refer to a user session (or client session). Instead all the required information should be kept in the refresh token. The refresh token has a reference to the grant_id. If the grant with the specific grant_id exists we know the user hasn't revoked the access for the application. If it doesn't exist we know the user has revoked the access and the "offline" refresh token is invalid.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 1 April, 2015 7:26:06 PM
> Subject: Re: [keycloak-dev] offline access
> 
> I'm not to keen on that idea.
> 
> offline is a standard scope in OIDC and an application requests this when
> first retrieving the token. When an application retrieves a refresh token
> with the offline scope set it should not be linked with the user session.
> Instead it should be stored permanently as the application now should have
> permanent offline access to the users account. If a user decides to revoke
> the applications access that should be done by going to the account
> management console and viewing client that have access to their account.
> This page should list all available clients, what clients have persisted
> grants, as well as what clients have offline access to their account. From
> the same page they should be able to revoke access from any client.
> 
> As user sessions are not persisted they are not suitable to store offline
> tokens. Offline tokens will often have a very long expiration time, a year
> or even no expiration time at all (only manual revoking).
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 1 April, 2015 4:53:45 PM
> > Subject: [keycloak-dev] offline access
> > 
> > Wanted to discuss again how offline access might be implemented.  IMO,
> > offline access should be a REST api.  Clients would request offline
> > access and the UserSession would be cloned and the ClientSession would
> > be cloned for that particular client.  ID, Access token and refresh
> > token would also be regenerated and sent back with the response.
> > 
> > With this approach, the admin console and user account session
> > management pages will just work.  These pages will just work they way
> > they already work with no extra changes.
> > 
> > Additionally, we would want to allow different session timeouts for
> > offline access.
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Apr  2 08:38:51 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 2 Apr 2015 08:38:51 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.2.0.Beta1 Released
In-Reply-To: <1943269927.10938403.1427978311541.JavaMail.zimbra@redhat.com>
Message-ID: <1466648129.10938551.1427978331196.JavaMail.zimbra@redhat.com>

We're proud to announce the release of Keycloak 1.2.0.Beta1. This is a great release, especially if you're after enterprise capabilities.

The major new features in this release includes:

* Protocol mapping - With protocol mapping it's easy to define what claims are added to the token an application receives.
* Kerberos - It's now possible to authenticate with a Keycloak realm using Kerberos tickets through SPNEGO.
* Identity Brokering - As well as Kerberos you can also authenticate with Keycloak with an external SAML 2.0 or OpenID Connect Identity Provider.
* OpenID Connect improvements - We've made several improvements to comply with the OpenID Connect specification and we've also introduced new features such as Discovery, Session Management and UserInfo endpoint.
* Internationalization support for login and account management Thanks to Michael Gerber the login and account management pages now have internationalization support. We have built in support for English, German and Brazilian Portuguese. We've also made it easy to add your own and if you'd like to contribute a translation let us know.
* Deploy providers as modules - It's now possible to deploy custom providers as modules. This gives you full control of the classloader for your provider.
* Deploy themes as modules - We've made it much simpler to package themes and they can also be deployed as a module. This makes it simpler to distribute themes as well as using custom themes in a cluster.
* Login with Stackoverflow and LinkedIn - Thanks to Vlastimil Eli?? we now have built-in support to login with Stackoverflow and LinkedIn.
* SysLog event listener - Thanks to Giriraj Sharma we now have a syslog event listener.
* Version control on cached resources - A common issue in the past was that the admin console didn't work after upgrading Keycloak. This was caused by the browser caching old html and javascript. We've solved this issue by including a version number in the resource urls, so upgrading should be even simpler now!

To get the release go to www.keycloak.org. For the full lists of issues resolved for this release check https://issues.jboss.org/browse/KEYCLOAK.

Remember to read the migration guide before upgrading as it contains vital information about what's changed and how to upgrade.


From bburke at redhat.com  Thu Apr  2 09:25:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 02 Apr 2015 09:25:02 -0400
Subject: [keycloak-dev] Keycloak 1.2.0.Beta1 Released
In-Reply-To: <1466648129.10938551.1427978331196.JavaMail.zimbra@redhat.com>
References: <1466648129.10938551.1427978331196.JavaMail.zimbra@redhat.com>
Message-ID: <551D432E.8090507@redhat.com>

Also, this was the first release Pedro de Silva from Picketlink 
contributed to.  He put in our Brokering support which is a feature a 
lot of our users are excited about.  You're going to see more great 
things from Pedro going forward.  I'm psyched PL and Keycloak teams are 
combined now.

Also, Raghu Prablahar was instrumental in flushing out SAML and 
brokering bugs and features.  He was working from master all through the 
winter and testing our stuff against other IDPs to make sure it worked.



On 4/2/2015 8:38 AM, Stian Thorgersen wrote:
> We're proud to announce the release of Keycloak 1.2.0.Beta1. This is a great release, especially if you're after enterprise capabilities.
>
> The major new features in this release includes:
>
> * Protocol mapping - With protocol mapping it's easy to define what claims are added to the token an application receives.
> * Kerberos - It's now possible to authenticate with a Keycloak realm using Kerberos tickets through SPNEGO.
> * Identity Brokering - As well as Kerberos you can also authenticate with Keycloak with an external SAML 2.0 or OpenID Connect Identity Provider.
> * OpenID Connect improvements - We've made several improvements to comply with the OpenID Connect specification and we've also introduced new features such as Discovery, Session Management and UserInfo endpoint.
> * Internationalization support for login and account management Thanks to Michael Gerber the login and account management pages now have internationalization support. We have built in support for English, German and Brazilian Portuguese. We've also made it easy to add your own and if you'd like to contribute a translation let us know.
> * Deploy providers as modules - It's now possible to deploy custom providers as modules. This gives you full control of the classloader for your provider.
> * Deploy themes as modules - We've made it much simpler to package themes and they can also be deployed as a module. This makes it simpler to distribute themes as well as using custom themes in a cluster.
> * Login with Stackoverflow and LinkedIn - Thanks to Vlastimil Eli?? we now have built-in support to login with Stackoverflow and LinkedIn.
> * SysLog event listener - Thanks to Giriraj Sharma we now have a syslog event listener.
> * Version control on cached resources - A common issue in the past was that the admin console didn't work after upgrading Keycloak. This was caused by the browser caching old html and javascript. We've solved this issue by including a version number in the resource urls, so upgrading should be even simpler now!
>
> To get the release go to www.keycloak.org. For the full lists of issues resolved for this release check https://issues.jboss.org/browse/KEYCLOAK.
>
> Remember to read the migration guide before upgrading as it contains vital information about what's changed and how to upgrade.
>
> _______________________________________________
> 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 Apr  2 14:54:17 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 2 Apr 2015 14:54:17 -0400 (EDT)
Subject: [keycloak-dev] Critical vulnerabilities in JSON Web Token libraries
In-Reply-To: <2080588963.8119096.1428000652394.JavaMail.zimbra@redhat.com>
Message-ID: <1390082068.8120955.1428000857471.JavaMail.zimbra@redhat.com>

FYI,

    https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

Regards.
Pedro Igor

From dnguyen at ciena.com  Thu Apr  2 15:31:26 2015
From: dnguyen at ciena.com (Nguyen, Dinh)
Date: Thu, 2 Apr 2015 15:31:26 -0400
Subject: [keycloak-dev] User data propagation when keycloak deployed in
	Wildfly cluster
Message-ID: <CBB9EF2338BC8042BB19FEA6322FB441A7469B9F01@ONWVEXCHMB02.ciena.com>

Hi,
Could someone help me with this question.

I have Keycloak deployed in multiple Wildfly instances in a Wildfly cluster of 3 nodes. If I connect to Keycloak in one WF instance and creates a user, does the user information automatically propagated to other Keycloak in other Wildlfy instance. Or I have to connect to the other Wildfly instance and create the same user?

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

From mposolda at redhat.com  Fri Apr  3 01:45:48 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 03 Apr 2015 07:45:48 +0200
Subject: [keycloak-dev] User data propagation when keycloak deployed in
 Wildfly cluster
In-Reply-To: <CBB9EF2338BC8042BB19FEA6322FB441A7469B9F01@ONWVEXCHMB02.ciena.com>
References: <CBB9EF2338BC8042BB19FEA6322FB441A7469B9F01@ONWVEXCHMB02.ciena.com>
Message-ID: <551E290C.6030308@redhat.com>

On 2.4.2015 21:31, Nguyen, Dinh wrote:
>
> Hi,
>
> Could someone help me with this question.
>
> I have Keycloak deployed in multiple Wildfly instances in a Wildfly 
> cluster of 3 nodes. If I connect to Keycloak in one WF instance and 
> creates a user, does the user information automatically propagated to 
> other Keycloak in other Wildlfy instance. Or I have to connect to the 
> other Wildfly instance and create the same user?
>
No, if cluster is set correctly, then the propagation should be done 
automatically. When you create user on node1, you should see him 
immediately in admin console of node2 and node3 too.

Marek
>
> Thanks.
>
>
>
> _______________________________________________
> 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/20150403/1d83eb34/attachment-0001.html 

From mposolda at redhat.com  Fri Apr  3 03:43:55 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 03 Apr 2015 09:43:55 +0200
Subject: [keycloak-dev] Critical vulnerabilities in JSON Web Token
	libraries
In-Reply-To: <1390082068.8120955.1428000857471.JavaMail.zimbra@redhat.com>
References: <1390082068.8120955.1428000857471.JavaMail.zimbra@redhat.com>
Message-ID: <551E44BB.6020903@redhat.com>

It seems to me that we are not vulnerable to this. We're using 
RSATokenVerifier everywhere and only allowed algorithms are the RS256, 
RS384, RS512. And for all of them, attacker would need realm private key 
to sign the token.

Marek


On 2.4.2015 20:54, Pedro Igor Silva wrote:
> FYI,
>
>      https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From prabhalar at yahoo.com  Fri Apr  3 09:19:55 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Fri, 3 Apr 2015 13:19:55 +0000 (UTC)
Subject: [keycloak-dev] [keycloak-user] Keycloak 1.2.0.Beta1 Released
In-Reply-To: <1466648129.10938551.1427978331196.JavaMail.zimbra@redhat.com>
References: <1466648129.10938551.1427978331196.JavaMail.zimbra@redhat.com>
Message-ID: <531579039.4426124.1428067195788.JavaMail.yahoo@mail.yahoo.com>

That's great news Stian. Kudos to the team for putting in a?great deal of functionality in such a short period of time - KC has now taken a big leap in terms of enterprise capabilities.
Can you also outline the roadmap for Keycloak and whether the below will be addressed?1) FIDO protocols2)?STS
Thanks,Raghu
?      From: Stian Thorgersen <stian at redhat.com>
 To: keycloak-dev <keycloak-dev at lists.jboss.org>; "keycloak-user at lists.jboss.org" <keycloak-user at lists.jboss.org> 
 Sent: Thursday, April 2, 2015 8:38 AM
 Subject: [keycloak-user] Keycloak 1.2.0.Beta1 Released
   
We're proud to announce the release of Keycloak 1.2.0.Beta1. This is a great release, especially if you're after enterprise capabilities.

The major new features in this release includes:

* Protocol mapping - With protocol mapping it's easy to define what claims are added to the token an application receives.
* Kerberos - It's now possible to authenticate with a Keycloak realm using Kerberos tickets through SPNEGO.
* Identity Brokering - As well as Kerberos you can also authenticate with Keycloak with an external SAML 2.0 or OpenID Connect Identity Provider.
* OpenID Connect improvements - We've made several improvements to comply with the OpenID Connect specification and we've also introduced new features such as Discovery, Session Management and UserInfo endpoint.
* Internationalization support for login and account management Thanks to Michael Gerber the login and account management pages now have internationalization support. We have built in support for English, German and Brazilian Portuguese. We've also made it easy to add your own and if you'd like to contribute a translation let us know.
* Deploy providers as modules - It's now possible to deploy custom providers as modules. This gives you full control of the classloader for your provider.
* Deploy themes as modules - We've made it much simpler to package themes and they can also be deployed as a module. This makes it simpler to distribute themes as well as using custom themes in a cluster.
* Login with Stackoverflow and LinkedIn - Thanks to Vlastimil Eli?? we now have built-in support to login with Stackoverflow and LinkedIn.
* SysLog event listener - Thanks to Giriraj Sharma we now have a syslog event listener.
* Version control on cached resources - A common issue in the past was that the admin console didn't work after upgrading Keycloak. This was caused by the browser caching old html and javascript. We've solved this issue by including a version number in the resource urls, so upgrading should be even simpler now!

To get the release go to www.keycloak.org. For the full lists of issues resolved for this release check https://issues.jboss.org/browse/KEYCLOAK.

Remember to read the migration guide before upgrading as it contains vital information about what's changed and how to upgrade.

_______________________________________________
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/20150403/e15a281e/attachment.html 

From mposolda at redhat.com  Fri Apr  3 10:02:04 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 03 Apr 2015 16:02:04 +0200
Subject: [keycloak-dev] offline access
In-Reply-To: <2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
References: <551C0679.9090808@redhat.com>	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
Message-ID: <551E9D5C.1070304@redhat.com>

Maybe we should use name "offline tokens" to not confuse them with 
classic "refresh tokens" ? Refresh tokens are used to refresh access 
token and they are always tight to user session, when "offline tokens" 
are not tight to user session.

Also IMO it should be possible that user grants access to client for 
store offline tokens in account management, not just on consent screen 
after login.

I think one of the important usecases for offline tokens would be long 
running non-web services (For example daemon service, which is running 
in background and doing periodic task on behalf of user once per day). 
Hence we should have possibility to grant offline tokens also to non-web 
applications (in other words, via Direct Access Grant). In this case, 
user might need to grant the access to the application in advance via 
Account mgmt.

Marek

On 2.4.2015 13:52, Stian Thorgersen wrote:
> Had an idea about offline tokens.
>
> When a user grants a client access we need to start persisting that so we don't ask the user again and again for the same permissions to be given to the application. This has to be stored permanently and not in user session. That's the mechanism we should use for offline tokens.
>
> When a user grants an application offline access that grant is persisted. This should be a special role. The grant should have an id and consist of: grant_id, user_id, client_id, role_id. If a refresh token has the offline scope it doesn't have to refer to a user session (or client session). Instead all the required information should be kept in the refresh token. The refresh token has a reference to the grant_id. If the grant with the specific grant_id exists we know the user hasn't revoked the access for the application. If it doesn't exist we know the user has revoked the access and the "offline" refresh token is invalid.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 1 April, 2015 7:26:06 PM
>> Subject: Re: [keycloak-dev] offline access
>>
>> I'm not to keen on that idea.
>>
>> offline is a standard scope in OIDC and an application requests this when
>> first retrieving the token. When an application retrieves a refresh token
>> with the offline scope set it should not be linked with the user session.
>> Instead it should be stored permanently as the application now should have
>> permanent offline access to the users account. If a user decides to revoke
>> the applications access that should be done by going to the account
>> management console and viewing client that have access to their account.
>> This page should list all available clients, what clients have persisted
>> grants, as well as what clients have offline access to their account. From
>> the same page they should be able to revoke access from any client.
>>
>> As user sessions are not persisted they are not suitable to store offline
>> tokens. Offline tokens will often have a very long expiration time, a year
>> or even no expiration time at all (only manual revoking).
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 1 April, 2015 4:53:45 PM
>>> Subject: [keycloak-dev] offline access
>>>
>>> Wanted to discuss again how offline access might be implemented.  IMO,
>>> offline access should be a REST api.  Clients would request offline
>>> access and the UserSession would be cloned and the ClientSession would
>>> be cloned for that particular client.  ID, Access token and refresh
>>> token would also be regenerated and sent back with the response.
>>>
>>> With this approach, the admin console and user account session
>>> management pages will just work.  These pages will just work they way
>>> they already work with no extra changes.
>>>
>>> Additionally, we would want to allow different session timeouts for
>>> offline access.
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Fri Apr  3 14:34:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 03 Apr 2015 14:34:50 -0400
Subject: [keycloak-dev] initial PL SAML fork
Message-ID: <551EDD4A.3000105@redhat.com>

I forked picketlink-federation and some of picketlink common into the 
keyclaok-saml-core project.  I did not refactor really anything, but I 
did gut tons of stuff, sts, XACML, and all the WS-*/SOAP stuff, 
handlers.  I tried to keep it solely focused on just a parsing library. 
  I also renamed, consolidated and moved packages.



It looks like we still have a few dependencies left, but we're getting 
closer to Picketlink-less Keycloak.

Bill

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

From bburke at redhat.com  Mon Apr  6 15:23:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 06 Apr 2015 15:23:41 -0400
Subject: [keycloak-dev] broker mappers
Message-ID: <5522DD3D.4040400@redhat.com>

I'm working on broker mappers now.  IDP chaining isn't very useful, IMO, 
if role information can't be imported.

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

From stian at redhat.com  Tue Apr  7 02:55:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 02:55:49 -0400 (EDT)
Subject: [keycloak-dev] Critical vulnerabilities in JSON Web Token
 libraries
In-Reply-To: <1390082068.8120955.1428000857471.JavaMail.zimbra@redhat.com>
References: <1390082068.8120955.1428000857471.JavaMail.zimbra@redhat.com>
Message-ID: <1551514671.13233124.1428389749872.JavaMail.zimbra@redhat.com>

Interesting attack, especially using the public key as hmac secret. Definitively worth considering if/when we add support for more algs ;)

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 2 April, 2015 8:54:17 PM
> Subject: [keycloak-dev] Critical vulnerabilities in JSON Web Token libraries
> 
> FYI,
> 
>     https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/
> 
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Apr  7 02:59:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 02:59:06 -0400 (EDT)
Subject: [keycloak-dev] broker mappers
In-Reply-To: <5522DD3D.4040400@redhat.com>
References: <5522DD3D.4040400@redhat.com>
Message-ID: <1556849583.13234102.1428389946676.JavaMail.zimbra@redhat.com>

Great, I was hoping we could add this for the next release :)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 6 April, 2015 9:23:41 PM
> Subject: [keycloak-dev] broker mappers
> 
> I'm working on broker mappers now.  IDP chaining isn't very useful, IMO,
> if role information can't be imported.
> 
> --
> 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 velias at redhat.com  Tue Apr  7 04:57:16 2015
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 07 Apr 2015 10:57:16 +0200
Subject: [keycloak-dev] How to handle empty strings returned by Social login
 providers in user info - KEYCLOAK-1182
Message-ID: <55239BEC.7090806@redhat.com>

Hi,

during latest testing I find problem with empty string returned in email 
field from GitHub social provider, which causes http 500 error in later 
processing (but seems under some other circumstances only, not for all 
cases), see https://issues.jboss.org/browse/KEYCLOAK-1182

When I look into the code used to take used profile informations (email, 
name, id) from Social provider REST responses, it simply takes what is 
returned and do not care too much what is here.

But other Keycloak code (eg search user by email etc) typically only 
check for null values when testing "existence" of information. If value 
is not null then it takes it as existing one, so empty strings may bring 
problems here as it is used as valid email later.

I believe KC should look at what is returned from Social providers and 
convert empty strings to null values.
It is only small change at one place - 
AbstractOAuth2IdentityProvider.getJsonProperty() which resolves this 
problem.

What do you think about this solution?

I have patch prepared and it works, I can post it as pull request after 
some additional testing.

Vl.

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team


From stian at redhat.com  Tue Apr  7 06:22:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 06:22:43 -0400 (EDT)
Subject: [keycloak-dev] How to handle empty strings returned by Social
 login providers in user info - KEYCLOAK-1182
In-Reply-To: <55239BEC.7090806@redhat.com>
References: <55239BEC.7090806@redhat.com>
Message-ID: <953733764.13318199.1428402163028.JavaMail.zimbra@redhat.com>

Sounds good. I guess you'll fix the null -> "null" issue at the same time?

----- Original Message -----
> From: "Vlastimil Elias" <velias at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 10:57:16 AM
> Subject: [keycloak-dev] How to handle empty strings returned by Social login providers in user info - KEYCLOAK-1182
> 
> Hi,
> 
> during latest testing I find problem with empty string returned in email
> field from GitHub social provider, which causes http 500 error in later
> processing (but seems under some other circumstances only, not for all
> cases), see https://issues.jboss.org/browse/KEYCLOAK-1182
> 
> When I look into the code used to take used profile informations (email,
> name, id) from Social provider REST responses, it simply takes what is
> returned and do not care too much what is here.
> 
> But other Keycloak code (eg search user by email etc) typically only
> check for null values when testing "existence" of information. If value
> is not null then it takes it as existing one, so empty strings may bring
> problems here as it is used as valid email later.
> 
> I believe KC should look at what is returned from Social providers and
> convert empty strings to null values.
> It is only small change at one place -
> AbstractOAuth2IdentityProvider.getJsonProperty() which resolves this
> problem.
> 
> What do you think about this solution?
> 
> I have patch prepared and it works, I can post it as pull request after
> some additional testing.
> 
> Vl.
> 
> --
> Vlastimil Elias
> Principal Software Engineer
> jboss.org Development Team
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From velias at redhat.com  Tue Apr  7 06:49:08 2015
From: velias at redhat.com (Vlastimil Elias)
Date: Tue, 07 Apr 2015 12:49:08 +0200
Subject: [keycloak-dev] How to handle empty strings returned by Social
 login providers in user info - KEYCLOAK-1182
In-Reply-To: <953733764.13318199.1428402163028.JavaMail.zimbra@redhat.com>
References: <55239BEC.7090806@redhat.com>
	<953733764.13318199.1428402163028.JavaMail.zimbra@redhat.com>
Message-ID: <5523B624.6040404@redhat.com>

Hi, sure, I'll patch the second problem also.

I'd also like to add unit test (based on junit) directly into 
keycloak-broker-oidc project to cover behaviour of getJsonProperty() 
method, as I think that is is better place than 
keycloak-testsuite-integration project used for integration tests.

Vl.



On 7.4.2015 12:22, Stian Thorgersen wrote:
> Sounds good. I guess you'll fix the null -> "null" issue at the same time?
>
> ----- Original Message -----
>> From: "Vlastimil Elias" <velias at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 April, 2015 10:57:16 AM
>> Subject: [keycloak-dev] How to handle empty strings returned by Social login providers in user info - KEYCLOAK-1182
>>
>> Hi,
>>
>> during latest testing I find problem with empty string returned in email
>> field from GitHub social provider, which causes http 500 error in later
>> processing (but seems under some other circumstances only, not for all
>> cases), see https://issues.jboss.org/browse/KEYCLOAK-1182
>>
>> When I look into the code used to take used profile informations (email,
>> name, id) from Social provider REST responses, it simply takes what is
>> returned and do not care too much what is here.
>>
>> But other Keycloak code (eg search user by email etc) typically only
>> check for null values when testing "existence" of information. If value
>> is not null then it takes it as existing one, so empty strings may bring
>> problems here as it is used as valid email later.
>>
>> I believe KC should look at what is returned from Social providers and
>> convert empty strings to null values.
>> It is only small change at one place -
>> AbstractOAuth2IdentityProvider.getJsonProperty() which resolves this
>> problem.
>>
>> What do you think about this solution?
>>
>> I have patch prepared and it works, I can post it as pull request after
>> some additional testing.
>>
>> Vl.
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> jboss.org Development Team
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team


From stian at redhat.com  Tue Apr  7 06:53:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 06:53:45 -0400 (EDT)
Subject: [keycloak-dev] How to handle empty strings returned by Social
 login providers in user info - KEYCLOAK-1182
In-Reply-To: <5523B624.6040404@redhat.com>
References: <55239BEC.7090806@redhat.com>
	<953733764.13318199.1428402163028.JavaMail.zimbra@redhat.com>
	<5523B624.6040404@redhat.com>
Message-ID: <1427634888.13333345.1428404025246.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Vlastimil Elias" <velias at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 12:49:08 PM
> Subject: Re: [keycloak-dev] How to handle empty strings returned by Social login providers in user info -
> KEYCLOAK-1182
> 
> Hi, sure, I'll patch the second problem also.
> 
> I'd also like to add unit test (based on junit) directly into
> keycloak-broker-oidc project to cover behaviour of getJsonProperty()
> method, as I think that is is better place than
> keycloak-testsuite-integration project used for integration tests.

We love tests, just slightly less keen on writing them ;)

> 
> Vl.
> 
> 
> 
> On 7.4.2015 12:22, Stian Thorgersen wrote:
> > Sounds good. I guess you'll fix the null -> "null" issue at the same time?
> >
> > ----- Original Message -----
> >> From: "Vlastimil Elias" <velias at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 April, 2015 10:57:16 AM
> >> Subject: [keycloak-dev] How to handle empty strings returned by Social
> >> login providers in user info - KEYCLOAK-1182
> >>
> >> Hi,
> >>
> >> during latest testing I find problem with empty string returned in email
> >> field from GitHub social provider, which causes http 500 error in later
> >> processing (but seems under some other circumstances only, not for all
> >> cases), see https://issues.jboss.org/browse/KEYCLOAK-1182
> >>
> >> When I look into the code used to take used profile informations (email,
> >> name, id) from Social provider REST responses, it simply takes what is
> >> returned and do not care too much what is here.
> >>
> >> But other Keycloak code (eg search user by email etc) typically only
> >> check for null values when testing "existence" of information. If value
> >> is not null then it takes it as existing one, so empty strings may bring
> >> problems here as it is used as valid email later.
> >>
> >> I believe KC should look at what is returned from Social providers and
> >> convert empty strings to null values.
> >> It is only small change at one place -
> >> AbstractOAuth2IdentityProvider.getJsonProperty() which resolves this
> >> problem.
> >>
> >> What do you think about this solution?
> >>
> >> I have patch prepared and it works, I can post it as pull request after
> >> some additional testing.
> >>
> >> Vl.
> >>
> >> --
> >> Vlastimil Elias
> >> Principal Software Engineer
> >> jboss.org Development Team
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Vlastimil Elias
> Principal Software Engineer
> jboss.org Development Team
> 
> 

From stian at redhat.com  Tue Apr  7 07:53:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 07:53:19 -0400 (EDT)
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <831781500.13362373.1428407499681.JavaMail.zimbra@redhat.com>
Message-ID: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>

I'm starting work on combining applications and oauth clients into a single client type.

For now there will be a single toggle to enable/disable grant page, but in the future we can consider having finer grained control of this. For example an application can get role-a without consent screen, but consent screen would be displayed for role-b.

Depending on how long it takes I may add some sort of filtering option on the admin console to make it easier to find a client.

From bburke at redhat.com  Tue Apr  7 08:22:18 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Apr 2015 08:22:18 -0400
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
Message-ID: <5523CBFA.3010102@redhat.com>

I was thinking that we would cram as many features we can into the 1.2 
release, then for 1.3 really focus on:

* refactoring the SPIs
* refactoring the UIs.  Reorganizing them, consolidating them, thinking 
of good defaults.  Think about any features we can remove to simplify things
* Break out the Public and Private apis
* Talk about "config profiles", i.e. Default application templates, and 
stuff like that.
* Improving the "Hello World" experience.

Really focus on usability, simplification, documentation, examples, etc. 
  Take a step back and really think about how to make Keycloak easier to 
use and consume.

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

From bburke at redhat.com  Tue Apr  7 08:26:11 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Apr 2015 08:26:11 -0400
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
References: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
Message-ID: <5523CCE3.4030601@redhat.com>

FYI, I think the correct term might be "consent" rather than "grant". 
"Consent" pops up a lot in the OIDC spec.

On 4/7/2015 7:53 AM, Stian Thorgersen wrote:
> I'm starting work on combining applications and oauth clients into a single client type.
>
> For now there will be a single toggle to enable/disable grant page, but in the future we can consider having finer grained control of this. For example an application can get role-a without consent screen, but consent screen would be displayed for role-b.
>
> Depending on how long it takes I may add some sort of filtering option on the admin console to make it easier to find a client.
> _______________________________________________
> 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 Apr  7 08:38:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 08:38:43 -0400 (EDT)
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <5523CCE3.4030601@redhat.com>
References: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
	<5523CCE3.4030601@redhat.com>
Message-ID: <1758069244.13393994.1428410323925.JavaMail.zimbra@redhat.com>

consent is nicer as well ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 2:26:11 PM
> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> 
> FYI, I think the correct term might be "consent" rather than "grant".
> "Consent" pops up a lot in the OIDC spec.
> 
> On 4/7/2015 7:53 AM, Stian Thorgersen wrote:
> > I'm starting work on combining applications and oauth clients into a single
> > client type.
> >
> > For now there will be a single toggle to enable/disable grant page, but in
> > the future we can consider having finer grained control of this. For
> > example an application can get role-a without consent screen, but consent
> > screen would be displayed for role-b.
> >
> > Depending on how long it takes I may add some sort of filtering option on
> > the admin console to make it easier to find a client.
> > _______________________________________________
> > 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  Tue Apr  7 08:41:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 08:41:07 -0400 (EDT)
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <5523CBFA.3010102@redhat.com>
References: <5523CBFA.3010102@redhat.com>
Message-ID: <181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>

Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll need to do a 1.3 feature release, then focus on refactoring for 1.4?

For 1.2 here's my list for features:

Yes, please

* Unify app and clients (KEYCLOAK-1187 Stian)
* Persist client grants (KEYCLOAK-1070 Marek)
* View/manage client grants in account management (KEYCLOAK-1070 Marek)
* View available clients in account management (KEYCLOAK-1070 Marek)
* Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
* Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
* Identity brokering mapping (KEYCLOAK-1097 Bill)
* Identity brokering - improve token store and retrieval (KEYCLOAK-992)

If time

* Introduce KeycloakContext (KEYCLOAK-1109 Stian)
* Dynamic client registration (KEYCLOAK-684)
* Auth SPI (KEYCLOAK-369)
* Required actions SPI - related to Auth SPI, maybe even same SPI?!? (KEYCLOAK-1188)
* OpenID Certification - ongoing (KEYCLOAK-524)
* LDAP enhancements (KEYCLOAK-886)
* PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 2:22:18 PM
> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
> 
> I was thinking that we would cram as many features we can into the 1.2
> release, then for 1.3 really focus on:
> 
> * refactoring the SPIs
> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
> of good defaults.  Think about any features we can remove to simplify things
> * Break out the Public and Private apis
> * Talk about "config profiles", i.e. Default application templates, and
> stuff like that.
> * Improving the "Hello World" experience.
> 
> Really focus on usability, simplification, documentation, examples, etc.
>   Take a step back and really think about how to make Keycloak easier to
> use and consume.
> 
> --
> 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 Apr  7 09:06:30 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Apr 2015 09:06:30 -0400
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
References: <5523CBFA.3010102@redhat.com>
	<181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
Message-ID: <5523D656.2050106@redhat.com>

Do we need a Keycloak SAML client adapter?

On 4/7/2015 8:41 AM, Stian Thorgersen wrote:
> Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll need to do a 1.3 feature release, then focus on refactoring for 1.4?
>
> For 1.2 here's my list for features:
>
> Yes, please
>
> * Unify app and clients (KEYCLOAK-1187 Stian)
> * Persist client grants (KEYCLOAK-1070 Marek)
> * View/manage client grants in account management (KEYCLOAK-1070 Marek)
> * View available clients in account management (KEYCLOAK-1070 Marek)
> * Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
> * Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
> * Identity brokering mapping (KEYCLOAK-1097 Bill)
> * Identity brokering - improve token store and retrieval (KEYCLOAK-992)
>
> If time
>
> * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
> * Dynamic client registration (KEYCLOAK-684)
> * Auth SPI (KEYCLOAK-369)
> * Required actions SPI - related to Auth SPI, maybe even same SPI?!? (KEYCLOAK-1188)
> * OpenID Certification - ongoing (KEYCLOAK-524)
> * LDAP enhancements (KEYCLOAK-886)
> * PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 April, 2015 2:22:18 PM
>> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
>>
>> I was thinking that we would cram as many features we can into the 1.2
>> release, then for 1.3 really focus on:
>>
>> * refactoring the SPIs
>> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
>> of good defaults.  Think about any features we can remove to simplify things
>> * Break out the Public and Private apis
>> * Talk about "config profiles", i.e. Default application templates, and
>> stuff like that.
>> * Improving the "Hello World" experience.
>>
>> Really focus on usability, simplification, documentation, examples, etc.
>>    Take a step back and really think about how to make Keycloak easier to
>> use and consume.
>>
>> --
>> 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  Tue Apr  7 09:14:47 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 09:14:47 -0400 (EDT)
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <5523D656.2050106@redhat.com>
References: <5523CBFA.3010102@redhat.com>
	<181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
	<5523D656.2050106@redhat.com>
Message-ID: <1182120350.13416665.1428412487123.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: Tuesday, 7 April, 2015 3:06:30 PM
> Subject: Re: [keycloak-dev] thoughts on 1.2->1.3 releases
> 
> Do we need a Keycloak SAML client adapter?

Not for 1.2 AFAIK, but we'll need it for 1.3

> 
> On 4/7/2015 8:41 AM, Stian Thorgersen wrote:
> > Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll
> > need to do a 1.3 feature release, then focus on refactoring for 1.4?
> >
> > For 1.2 here's my list for features:
> >
> > Yes, please
> >
> > * Unify app and clients (KEYCLOAK-1187 Stian)
> > * Persist client grants (KEYCLOAK-1070 Marek)
> > * View/manage client grants in account management (KEYCLOAK-1070 Marek)
> > * View available clients in account management (KEYCLOAK-1070 Marek)
> > * Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
> > * Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
> > * Identity brokering mapping (KEYCLOAK-1097 Bill)
> > * Identity brokering - improve token store and retrieval (KEYCLOAK-992)
> >
> > If time
> >
> > * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
> > * Dynamic client registration (KEYCLOAK-684)
> > * Auth SPI (KEYCLOAK-369)
> > * Required actions SPI - related to Auth SPI, maybe even same SPI?!?
> > (KEYCLOAK-1188)
> > * OpenID Certification - ongoing (KEYCLOAK-524)
> > * LDAP enhancements (KEYCLOAK-886)
> > * PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 April, 2015 2:22:18 PM
> >> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
> >>
> >> I was thinking that we would cram as many features we can into the 1.2
> >> release, then for 1.3 really focus on:
> >>
> >> * refactoring the SPIs
> >> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
> >> of good defaults.  Think about any features we can remove to simplify
> >> things
> >> * Break out the Public and Private apis
> >> * Talk about "config profiles", i.e. Default application templates, and
> >> stuff like that.
> >> * Improving the "Hello World" experience.
> >>
> >> Really focus on usability, simplification, documentation, examples, etc.
> >>    Take a step back and really think about how to make Keycloak easier to
> >> use and consume.
> >>
> >> --
> >> 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  Tue Apr  7 09:18:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 09:18:48 -0400 (EDT)
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <1758069244.13393994.1428410323925.JavaMail.zimbra@redhat.com>
References: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
	<5523CCE3.4030601@redhat.com>
	<1758069244.13393994.1428410323925.JavaMail.zimbra@redhat.com>
Message-ID: <980739095.13419283.1428412728744.JavaMail.zimbra@redhat.com>

This is going to be fun!

So plan is:

1. Remove oauth-client
2. Move everything from abstract client to application
3. Add consent required option to application
4. Rename application to client
5. Migration of db and representations

Please, don't do to much changes to the model and representations in the next few days ;)

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 2:38:43 PM
> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> 
> consent is nicer as well ;)
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 7 April, 2015 2:26:11 PM
> > Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> > 
> > FYI, I think the correct term might be "consent" rather than "grant".
> > "Consent" pops up a lot in the OIDC spec.
> > 
> > On 4/7/2015 7:53 AM, Stian Thorgersen wrote:
> > > I'm starting work on combining applications and oauth clients into a
> > > single
> > > client type.
> > >
> > > For now there will be a single toggle to enable/disable grant page, but
> > > in
> > > the future we can consider having finer grained control of this. For
> > > example an application can get role-a without consent screen, but consent
> > > screen would be displayed for role-b.
> > >
> > > Depending on how long it takes I may add some sort of filtering option on
> > > the admin console to make it easier to find a client.
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Apr  7 09:26:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 07 Apr 2015 09:26:55 -0400
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <980739095.13419283.1428412728744.JavaMail.zimbra@redhat.com>
References: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
	<5523CCE3.4030601@redhat.com>
	<1758069244.13393994.1428410323925.JavaMail.zimbra@redhat.com>
	<980739095.13419283.1428412728744.JavaMail.zimbra@redhat.com>
Message-ID: <5523DB1F.3040503@redhat.com>

Also you forgot:

* Redo all the screencast demos.  I'm happy to do it. (well, not that 
happy), but need to schedule a week for this.



On 4/7/2015 9:18 AM, Stian Thorgersen wrote:
> This is going to be fun!
>
> So plan is:
>
> 1. Remove oauth-client
> 2. Move everything from abstract client to application
> 3. Add consent required option to application
> 4. Rename application to client
> 5. Migration of db and representations
>
> Please, don't do to much changes to the model and representations in the next few days ;)
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 April, 2015 2:38:43 PM
>> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
>>
>> consent is nicer as well ;)
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 7 April, 2015 2:26:11 PM
>>> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
>>>
>>> FYI, I think the correct term might be "consent" rather than "grant".
>>> "Consent" pops up a lot in the OIDC spec.
>>>
>>> On 4/7/2015 7:53 AM, Stian Thorgersen wrote:
>>>> I'm starting work on combining applications and oauth clients into a
>>>> single
>>>> client type.
>>>>
>>>> For now there will be a single toggle to enable/disable grant page, but
>>>> in
>>>> the future we can consider having finer grained control of this. For
>>>> example an application can get role-a without consent screen, but consent
>>>> screen would be displayed for role-b.
>>>>
>>>> Depending on how long it takes I may add some sort of filtering option on
>>>> the admin console to make it easier to find a client.
>>>> _______________________________________________
>>>> 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 lkrzyzan at redhat.com  Tue Apr  7 09:56:44 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Tue, 7 Apr 2015 15:56:44 +0200
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
References: <5523CBFA.3010102@redhat.com>
	<181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
Message-ID: <0194E836-9B8B-4F32-8538-5ED601F42C43@redhat.com>

Hi Stian,
we would need this feature in version 1.2 in our project:
* Introduce KeycloakContext (KEYCLOAK-1109 Stian)

See https://issues.jboss.org/browse/KEYCLOAK-1042 <https://issues.jboss.org/browse/KEYCLOAK-1042> which relates to 1109

Thank you,

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

> On 07 Apr 2015, at 14:41, Stian Thorgersen <stian at redhat.com> wrote:
> 
> Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll need to do a 1.3 feature release, then focus on refactoring for 1.4?
> 
> For 1.2 here's my list for features:
> 
> Yes, please
> 
> * Unify app and clients (KEYCLOAK-1187 Stian)
> * Persist client grants (KEYCLOAK-1070 Marek)
> * View/manage client grants in account management (KEYCLOAK-1070 Marek)
> * View available clients in account management (KEYCLOAK-1070 Marek)
> * Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
> * Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
> * Identity brokering mapping (KEYCLOAK-1097 Bill)
> * Identity brokering - improve token store and retrieval (KEYCLOAK-992)
> 
> If time
> 
> * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
> * Dynamic client registration (KEYCLOAK-684)
> * Auth SPI (KEYCLOAK-369)
> * Required actions SPI - related to Auth SPI, maybe even same SPI?!? (KEYCLOAK-1188)
> * OpenID Certification - ongoing (KEYCLOAK-524)
> * LDAP enhancements (KEYCLOAK-886)
> * PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)
> 
> 
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 April, 2015 2:22:18 PM
>> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
>> 
>> I was thinking that we would cram as many features we can into the 1.2
>> release, then for 1.3 really focus on:
>> 
>> * refactoring the SPIs
>> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
>> of good defaults.  Think about any features we can remove to simplify things
>> * Break out the Public and Private apis
>> * Talk about "config profiles", i.e. Default application templates, and
>> stuff like that.
>> * Improving the "Hello World" experience.
>> 
>> Really focus on usability, simplification, documentation, examples, etc.
>>  Take a step back and really think about how to make Keycloak easier to
>> use and consume.
>> 
>> --
>> 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/20150407/f3cfaca5/attachment.html 

From stian at redhat.com  Tue Apr  7 10:08:51 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 7 Apr 2015 10:08:51 -0400 (EDT)
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <0194E836-9B8B-4F32-8538-5ED601F42C43@redhat.com>
References: <5523CBFA.3010102@redhat.com>
	<181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
	<0194E836-9B8B-4F32-8538-5ED601F42C43@redhat.com>
Message-ID: <1055896912.13507540.1428415731441.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Libor Krzy?anek" <lkrzyzan at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 7 April, 2015 3:56:44 PM
> Subject: Re: [keycloak-dev] thoughts on 1.2->1.3 releases
> 
> Hi Stian,
> we would need this feature in version 1.2 in our project:
> * Introduce KeycloakContext (KEYCLOAK-1109 Stian)

Oki, I'll make sure it makes it in

> 
> See https://issues.jboss.org/browse/KEYCLOAK-1042
> <https://issues.jboss.org/browse/KEYCLOAK-1042> which relates to 1109
> 
> Thank you,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
> > On 07 Apr 2015, at 14:41, Stian Thorgersen <stian at redhat.com> wrote:
> > 
> > Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll
> > need to do a 1.3 feature release, then focus on refactoring for 1.4?
> > 
> > For 1.2 here's my list for features:
> > 
> > Yes, please
> > 
> > * Unify app and clients (KEYCLOAK-1187 Stian)
> > * Persist client grants (KEYCLOAK-1070 Marek)
> > * View/manage client grants in account management (KEYCLOAK-1070 Marek)
> > * View available clients in account management (KEYCLOAK-1070 Marek)
> > * Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
> > * Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
> > * Identity brokering mapping (KEYCLOAK-1097 Bill)
> > * Identity brokering - improve token store and retrieval (KEYCLOAK-992)
> > 
> > If time
> > 
> > * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
> > * Dynamic client registration (KEYCLOAK-684)
> > * Auth SPI (KEYCLOAK-369)
> > * Required actions SPI - related to Auth SPI, maybe even same SPI?!?
> > (KEYCLOAK-1188)
> > * OpenID Certification - ongoing (KEYCLOAK-524)
> > * LDAP enhancements (KEYCLOAK-886)
> > * PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)
> > 
> > 
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 April, 2015 2:22:18 PM
> >> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
> >> 
> >> I was thinking that we would cram as many features we can into the 1.2
> >> release, then for 1.3 really focus on:
> >> 
> >> * refactoring the SPIs
> >> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
> >> of good defaults.  Think about any features we can remove to simplify
> >> things
> >> * Break out the Public and Private apis
> >> * Talk about "config profiles", i.e. Default application templates, and
> >> stuff like that.
> >> * Improving the "Hello World" experience.
> >> 
> >> Really focus on usability, simplification, documentation, examples, etc.
> >>  Take a step back and really think about how to make Keycloak easier to
> >> use and consume.
> >> 
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 


From bruno at abstractj.org  Tue Apr  7 10:17:48 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 7 Apr 2015 11:17:48 -0300
Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying Keycloak
	with JDK 8
Message-ID: <20150407141748.GA27307@abstractj.org>

Good morning guys, I created the following Jira
https://issues.jboss.org/browse/KEYCLOAK-1189. I'm not sure if you
already faced with this issue, but let me know if you need more details.

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Wed Apr  8 00:29:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Apr 2015 00:29:15 -0400 (EDT)
Subject: [keycloak-dev] Unifying applications and oauth clients
In-Reply-To: <5523DB1F.3040503@redhat.com>
References: <1302657384.13362944.1428407599196.JavaMail.zimbra@redhat.com>
	<5523CCE3.4030601@redhat.com>
	<1758069244.13393994.1428410323925.JavaMail.zimbra@redhat.com>
	<980739095.13419283.1428412728744.JavaMail.zimbra@redhat.com>
	<5523DB1F.3040503@redhat.com>
Message-ID: <372763767.14043212.1428467355183.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: Tuesday, 7 April, 2015 3:26:55 PM
> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> 
> Also you forgot:
> 
> * Redo all the screencast demos.  I'm happy to do it. (well, not that
> happy), but need to schedule a week for this.

Maybe we should wait with redoing the screencasts until after we've done the other polishing tasks of the admin console?

> 
> 
> 
> On 4/7/2015 9:18 AM, Stian Thorgersen wrote:
> > This is going to be fun!
> >
> > So plan is:
> >
> > 1. Remove oauth-client
> > 2. Move everything from abstract client to application
> > 3. Add consent required option to application
> > 4. Rename application to client
> > 5. Migration of db and representations
> >
> > Please, don't do to much changes to the model and representations in the
> > next few days ;)
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 7 April, 2015 2:38:43 PM
> >> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> >>
> >> consent is nicer as well ;)
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 7 April, 2015 2:26:11 PM
> >>> Subject: Re: [keycloak-dev] Unifying applications and oauth clients
> >>>
> >>> FYI, I think the correct term might be "consent" rather than "grant".
> >>> "Consent" pops up a lot in the OIDC spec.
> >>>
> >>> On 4/7/2015 7:53 AM, Stian Thorgersen wrote:
> >>>> I'm starting work on combining applications and oauth clients into a
> >>>> single
> >>>> client type.
> >>>>
> >>>> For now there will be a single toggle to enable/disable grant page, but
> >>>> in
> >>>> the future we can consider having finer grained control of this. For
> >>>> example an application can get role-a without consent screen, but
> >>>> consent
> >>>> screen would be displayed for role-b.
> >>>>
> >>>> Depending on how long it takes I may add some sort of filtering option
> >>>> on
> >>>> the admin console to make it easier to find a client.
> >>>> _______________________________________________
> >>>> 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 stian at redhat.com  Wed Apr  8 00:47:36 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Apr 2015 00:47:36 -0400 (EDT)
Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying
 Keycloak	with JDK 8
In-Reply-To: <20150407141748.GA27307@abstractj.org>
References: <20150407141748.GA27307@abstractj.org>
Message-ID: <1329291354.14045817.1428468456049.JavaMail.zimbra@redhat.com>

Looks like we'll have to add our own HttpClient version while we wait for 9 final. Scheduled the issue to be fixed for 1.2.0.RC1.

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 7 April, 2015 4:17:48 PM
> Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying Keycloak	with JDK 8
> 
> Good morning guys, I created the following Jira
> https://issues.jboss.org/browse/KEYCLOAK-1189. I'm not sure if you
> already faced with this issue, but let me know if you need more details.
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Apr  8 03:25:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Apr 2015 03:25:31 -0400 (EDT)
Subject: [keycloak-dev] Keycloak OpenShift Cartridge updated to 1.2.0.Beta1
In-Reply-To: <694212140.14093778.1428477923038.JavaMail.zimbra@redhat.com>
Message-ID: <1946564269.14093836.1428477931444.JavaMail.zimbra@redhat.com>

Keycloak OpenShift Cartridge updated to 1.2.0.Beta1

https://github.com/keycloak/openshift-keycloak-cartridge

From lkrzyzan at redhat.com  Wed Apr  8 05:12:42 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Wed, 8 Apr 2015 11:12:42 +0200
Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
In-Reply-To: <1055896912.13507540.1428415731441.JavaMail.zimbra@redhat.com>
References: <5523CBFA.3010102@redhat.com>
	<181657241.13395204.1428410467094.JavaMail.zimbra@redhat.com>
	<0194E836-9B8B-4F32-8538-5ED601F42C43@redhat.com>
	<1055896912.13507540.1428415731441.JavaMail.zimbra@redhat.com>
Message-ID: <47F20F63-CA13-4E04-9760-C9CF90E33A56@redhat.com>

Thank you Stian,

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

> On 07 Apr 2015, at 16:08, 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: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 7 April, 2015 3:56:44 PM
>> Subject: Re: [keycloak-dev] thoughts on 1.2->1.3 releases
>> 
>> Hi Stian,
>> we would need this feature in version 1.2 in our project:
>> * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
> 
> Oki, I'll make sure it makes it in
> 
>> 
>> See https://issues.jboss.org/browse/KEYCLOAK-1042
>> <https://issues.jboss.org/browse/KEYCLOAK-1042> which relates to 1109
>> 
>> Thank you,
>> 
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>> 
>>> On 07 Apr 2015, at 14:41, Stian Thorgersen <stian at redhat.com> wrote:
>>> 
>>> Makes sense, we have a limited amount of time for 1.2 though. Maybe we'll
>>> need to do a 1.3 feature release, then focus on refactoring for 1.4?
>>> 
>>> For 1.2 here's my list for features:
>>> 
>>> Yes, please
>>> 
>>> * Unify app and clients (KEYCLOAK-1187 Stian)
>>> * Persist client grants (KEYCLOAK-1070 Marek)
>>> * View/manage client grants in account management (KEYCLOAK-1070 Marek)
>>> * View available clients in account management (KEYCLOAK-1070 Marek)
>>> * Remove PL dependencies - SAML (KEYCLOAK-1006 Bill)
>>> * Remove PL dependencies - LDAP (KEYCLOAK-1007 Marek)
>>> * Identity brokering mapping (KEYCLOAK-1097 Bill)
>>> * Identity brokering - improve token store and retrieval (KEYCLOAK-992)
>>> 
>>> If time
>>> 
>>> * Introduce KeycloakContext (KEYCLOAK-1109 Stian)
>>> * Dynamic client registration (KEYCLOAK-684)
>>> * Auth SPI (KEYCLOAK-369)
>>> * Required actions SPI - related to Auth SPI, maybe even same SPI?!?
>>> (KEYCLOAK-1188)
>>> * OpenID Certification - ongoing (KEYCLOAK-524)
>>> * LDAP enhancements (KEYCLOAK-886)
>>> * PatternFly/RCUE enhancements (KEYCLOAK-887 Stian)
>>> 
>>> 
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 7 April, 2015 2:22:18 PM
>>>> Subject: [keycloak-dev] thoughts on 1.2->1.3 releases
>>>> 
>>>> I was thinking that we would cram as many features we can into the 1.2
>>>> release, then for 1.3 really focus on:
>>>> 
>>>> * refactoring the SPIs
>>>> * refactoring the UIs.  Reorganizing them, consolidating them, thinking
>>>> of good defaults.  Think about any features we can remove to simplify
>>>> things
>>>> * Break out the Public and Private apis
>>>> * Talk about "config profiles", i.e. Default application templates, and
>>>> stuff like that.
>>>> * Improving the "Hello World" experience.
>>>> 
>>>> Really focus on usability, simplification, documentation, examples, etc.
>>>> Take a step back and really think about how to make Keycloak easier to
>>>> use and consume.
>>>> 
>>>> --
>>>> 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/20150408/e8081412/attachment.html 

From pslegr at redhat.com  Wed Apr  8 08:00:08 2015
From: pslegr at redhat.com (pslegr)
Date: Wed, 08 Apr 2015 14:00:08 +0200
Subject: [keycloak-dev] Keykload and Swagger.io integration
Message-ID: <55251848.7070903@redhat.com>

Hi guys,

I've found an old thread wrt ${subject} here 
http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001842.html
and I wonder, if there was some further research on it.

I need to integrate Swagger.io and Keycloak

Anyone tried out already, or having some example to show ?

thanks
Pavel


From bruno at abstractj.org  Wed Apr  8 08:41:51 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 08 Apr 2015 05:41:51 -0700 (PDT)
Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying
 Keycloak	with JDK 8
In-Reply-To: <1329291354.14045817.1428468456049.JavaMail.zimbra@redhat.com>
References: <1329291354.14045817.1428468456049.JavaMail.zimbra@redhat.com>
Message-ID: <1428496910534.681bc1c8@Nodemailer>

Thank you Stian



?
abstractj 
PGP: 0x84DC9914

On Wed, Apr 8, 2015 at 1:47 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Looks like we'll have to add our own HttpClient version while we wait for 9 final. Scheduled the issue to be fixed for 1.2.0.RC1.
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 7 April, 2015 4:17:48 PM
>> Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying Keycloak	with JDK 8
>> 
>> Good morning guys, I created the following Jira
>> https://issues.jboss.org/browse/KEYCLOAK-1189. I'm not sure if you
>> already faced with this issue, but let me know if you need more details.
>> 
>> --
>> 
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> 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/20150408/7d187d85/attachment-0001.html 

From bburke at redhat.com  Wed Apr  8 09:05:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Apr 2015 09:05:02 -0400
Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying
 Keycloak with JDK 8
In-Reply-To: <1428496910534.681bc1c8@Nodemailer>
References: <1329291354.14045817.1428468456049.JavaMail.zimbra@redhat.com>
	<1428496910534.681bc1c8@Nodemailer>
Message-ID: <5525277E.7070903@redhat.com>

We might be able to get away with ditching any use of the deprecated 
Resteasy 2.3.x client library and using Apache HTTP client directly.

On 4/8/2015 8:41 AM, Bruno Oliveira wrote:
> Thank you Stian
>
> ? abstractj PGP: 0x84DC9914
>
>
> On Wed, Apr 8, 2015 at 1:47 AM, Stian Thorgersen <stian at redhat.com
> <mailto:stian at redhat.com>> wrote:
>
>     Looks like we'll have to add our own HttpClient version while we
>     wait for 9 final. Scheduled the issue to be fixed for 1.2.0.RC1.
>
>     ----- Original Message -----
>      > From: "Bruno Oliveira" <bruno at abstractj.org>
>      > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>      > Sent: Tuesday, 7 April, 2015 4:17:48 PM
>      > Subject: [keycloak-dev] SSLPeerUnverifiedException when deploying
>     Keycloak with JDK 8
>      >
>      > Good morning guys, I created the following Jira
>      > https://issues.jboss.org/browse/KEYCLOAK-1189. I'm not sure if you
>      > already faced with this issue, but let me know if you need more
>     details.
>      >
>      > --
>      >
>      > abstractj
>      > PGP: 0x84DC9914
>      > _______________________________________________
>      > keycloak-dev mailing list
>      > keycloak-dev at lists.jboss.org
>      > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>      >
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Wed Apr  8 09:18:40 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Apr 2015 15:18:40 +0200
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink federation
	provider?
Message-ID: <55252AB0.8080608@redhat.com>

Not sure if we already decide about $subject. I am in the middle of 
forking LDAP from PLIDM and removing PLIDM dependency. Now I wonder if I 
should:

1) Remove PLIDM dependency entirely from whole codebase

2) Create the module with Picketlink FederationProvider, which won't be 
packaged in distribution by default. This can be separate package used 
on demand by EAP customers to migrate their PLIDM users into Keycloak 
users. This module will be the only place, which will be still dependent 
on PLIDM, but since it won't be in distribution by default, we can 
remove PLIDM dependency from appliance and war distributions.

The reason I am asking is, that current LDAPFederationProvider can be 
quite easily converted into PicketlinkFederationProvider. But limitation 
is, that it will migrate just users. It won't migrate IDM roles into 
Keycloak roles..

Or should I simply go with (1) and don't care about the migration for now?

Marek

From stian at redhat.com  Wed Apr  8 09:33:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 8 Apr 2015 09:33:04 -0400 (EDT)
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink
 federation	provider?
In-Reply-To: <55252AB0.8080608@redhat.com>
References: <55252AB0.8080608@redhat.com>
Message-ID: <1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 8 April, 2015 3:18:40 PM
> Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink federation	provider?
> 
> Not sure if we already decide about $subject. I am in the middle of
> forking LDAP from PLIDM and removing PLIDM dependency. Now I wonder if I
> should:
> 
> 1) Remove PLIDM dependency entirely from whole codebase
> 
> 2) Create the module with Picketlink FederationProvider, which won't be
> packaged in distribution by default. This can be separate package used
> on demand by EAP customers to migrate their PLIDM users into Keycloak
> users. This module will be the only place, which will be still dependent
> on PLIDM, but since it won't be in distribution by default, we can
> remove PLIDM dependency from appliance and war distributions.
> 
> The reason I am asking is, that current LDAPFederationProvider can be
> quite easily converted into PicketlinkFederationProvider. But limitation
> is, that it will migrate just users. It won't migrate IDM roles into
> Keycloak roles..
> 
> Or should I simply go with (1) and don't care about the migration for now?

As 2 can't do roles as well it's not really that useful. Also, since IDM is so flexible I can't see us providing one that works for everyone (if anyone?! at all). So maybe what we should do is to provide an example that users can fork/modify?

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

From mposolda at redhat.com  Wed Apr  8 09:59:32 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Apr 2015 15:59:32 +0200
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink
 federation provider?
In-Reply-To: <1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>
References: <55252AB0.8080608@redhat.com>
	<1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>
Message-ID: <55253444.3010605@redhat.com>

On 8.4.2015 15:33, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 8 April, 2015 3:18:40 PM
>> Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink federation	provider?
>>
>> Not sure if we already decide about $subject. I am in the middle of
>> forking LDAP from PLIDM and removing PLIDM dependency. Now I wonder if I
>> should:
>>
>> 1) Remove PLIDM dependency entirely from whole codebase
>>
>> 2) Create the module with Picketlink FederationProvider, which won't be
>> packaged in distribution by default. This can be separate package used
>> on demand by EAP customers to migrate their PLIDM users into Keycloak
>> users. This module will be the only place, which will be still dependent
>> on PLIDM, but since it won't be in distribution by default, we can
>> remove PLIDM dependency from appliance and war distributions.
>>
>> The reason I am asking is, that current LDAPFederationProvider can be
>> quite easily converted into PicketlinkFederationProvider. But limitation
>> is, that it will migrate just users. It won't migrate IDM roles into
>> Keycloak roles..
>>
>> Or should I simply go with (1) and don't care about the migration for now?
> As 2 can't do roles as well it's not really that useful. Also, since IDM is so flexible I can't see us providing one that works for everyone (if anyone?! at all). So maybe what we should do is to provide an example that users can fork/modify?
Yeah, so maybe adding new example into examples/providers for that?

I can try to do something by tomorrow, but not sure if I catch it. And 
next week I would like to start on persistent client grants. I guess 
it's not an issue to possibly postpone this to some later release?

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


From bburke at redhat.com  Wed Apr  8 10:03:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Apr 2015 10:03:16 -0400
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink
 federation provider?
In-Reply-To: <55253444.3010605@redhat.com>
References: <55252AB0.8080608@redhat.com>	<1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>
	<55253444.3010605@redhat.com>
Message-ID: <55253524.6050800@redhat.com>



On 4/8/2015 9:59 AM, Marek Posolda wrote:
> On 8.4.2015 15:33, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 8 April, 2015 3:18:40 PM
>>> Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink federation	provider?
>>>
>>> Not sure if we already decide about $subject. I am in the middle of
>>> forking LDAP from PLIDM and removing PLIDM dependency. Now I wonder if I
>>> should:
>>>
>>> 1) Remove PLIDM dependency entirely from whole codebase
>>>
>>> 2) Create the module with Picketlink FederationProvider, which won't be
>>> packaged in distribution by default. This can be separate package used
>>> on demand by EAP customers to migrate their PLIDM users into Keycloak
>>> users. This module will be the only place, which will be still dependent
>>> on PLIDM, but since it won't be in distribution by default, we can
>>> remove PLIDM dependency from appliance and war distributions.
>>>
>>> The reason I am asking is, that current LDAPFederationProvider can be
>>> quite easily converted into PicketlinkFederationProvider. But limitation
>>> is, that it will migrate just users. It won't migrate IDM roles into
>>> Keycloak roles..
>>>
>>> Or should I simply go with (1) and don't care about the migration for now?
>> As 2 can't do roles as well it's not really that useful. Also, since IDM is so flexible I can't see us providing one that works for everyone (if anyone?! at all). So maybe what we should do is to provide an example that users can fork/modify?
> Yeah, so maybe adding new example into examples/providers for that?
>
> I can try to do something by tomorrow, but not sure if I catch it. And
> next week I would like to start on persistent client grants. I guess
> it's not an issue to possibly postpone this to some later release?
>

I think it will help us tremendously in product if we have zero PL IDM 
dependencies.  As we discussed in meetings, Picketlink is not going to 
be upgraded in EAP7 and is a few versions back of the latest Picketlink. 
  Keycloak LDAP integration currently has dependencies on latest and 
greatest Picketlink.

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

From mposolda at redhat.com  Wed Apr  8 17:05:51 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 08 Apr 2015 23:05:51 +0200
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink
 federation provider?
In-Reply-To: <55253524.6050800@redhat.com>
References: <55252AB0.8080608@redhat.com>	<1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>	<55253444.3010605@redhat.com>
	<55253524.6050800@redhat.com>
Message-ID: <5525982F.10601@redhat.com>

Sure. For option 2 I meant to remove the PL IDM dependencies from 
distribution, but just keep the example with federation provider, which 
will be installed on demand (just if someone needs to migrate his PLIDM 
DB to Keycloak).

But for now, I've just forked needed Picketlink IDM code into 
federation/ldap module and removed PL IDM dependencies. I've created 
separate JIRA for migration, so we can look at it later when it's 
required: https://issues.jboss.org/browse/KEYCLOAK-1198

I've removed some Picketlink IDM layers like PartitionManager, 
IdentityManager etc and keep just LDAP Identity store. There is still 
space to remove more abstractions though. I will need to re-visit it 
again anyway during work on LDAP enhancements.

I did not remove picketlink dependencies from packaging as it seems they 
are still needed by SAML. At least SAML examples are still using 
Picketlink libraries on SP side. Are we going to fork SAML SP code as well?

Marek

On 8.4.2015 16:03, Bill Burke wrote:
>>>> Or should I simply go with (1) and don't care about the migration for now?
>>> >>As 2 can't do roles as well it's not really that useful. Also, since IDM is so flexible I can't see us providing one that works for everyone (if anyone?! at all). So maybe what we should do is to provide an example that users can fork/modify?
>> >Yeah, so maybe adding new example into examples/providers for that?
>> >
>> >I can try to do something by tomorrow, but not sure if I catch it. And
>> >next week I would like to start on persistent client grants. I guess
>> >it's not an issue to possibly postpone this to some later release?
>> >
> I think it will help us tremendously in product if we have zero PL IDM
> dependencies.  As we discussed in meetings, Picketlink is not going to
> be upgraded in EAP7 and is a few versions back of the latest Picketlink.
>    Keycloak LDAP integration currently has dependencies on latest and
> greatest Picketlink.


From bburke at redhat.com  Wed Apr  8 20:57:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 08 Apr 2015 20:57:03 -0400
Subject: [keycloak-dev] Remove IDM entirely or keep Picketlink
 federation provider?
In-Reply-To: <5525982F.10601@redhat.com>
References: <55252AB0.8080608@redhat.com>	<1402581854.14352974.1428499984784.JavaMail.zimbra@redhat.com>	<55253444.3010605@redhat.com>
	<55253524.6050800@redhat.com> <5525982F.10601@redhat.com>
Message-ID: <5525CE5F.7020403@redhat.com>

I don't think I'm going to fork SAML SP.  I want to see if I can share a 
lot of code between our OIDC and SAML adapters.  Really all the role 
stuff and subject propagation.

On 4/8/2015 5:05 PM, Marek Posolda wrote:
> Sure. For option 2 I meant to remove the PL IDM dependencies from
> distribution, but just keep the example with federation provider, which
> will be installed on demand (just if someone needs to migrate his PLIDM
> DB to Keycloak).
>
> But for now, I've just forked needed Picketlink IDM code into
> federation/ldap module and removed PL IDM dependencies. I've created
> separate JIRA for migration, so we can look at it later when it's
> required: https://issues.jboss.org/browse/KEYCLOAK-1198
>
> I've removed some Picketlink IDM layers like PartitionManager,
> IdentityManager etc and keep just LDAP Identity store. There is still
> space to remove more abstractions though. I will need to re-visit it
> again anyway during work on LDAP enhancements.
>
> I did not remove picketlink dependencies from packaging as it seems they
> are still needed by SAML. At least SAML examples are still using
> Picketlink libraries on SP side. Are we going to fork SAML SP code as well?
>
> Marek
>
> On 8.4.2015 16:03, Bill Burke wrote:
>>>>> Or should I simply go with (1) and don't care about the migration
>>>>> for now?
>>>> >>As 2 can't do roles as well it's not really that useful. Also,
>>>> since IDM is so flexible I can't see us providing one that works for
>>>> everyone (if anyone?! at all). So maybe what we should do is to
>>>> provide an example that users can fork/modify?
>>> >Yeah, so maybe adding new example into examples/providers for that?
>>> >
>>> >I can try to do something by tomorrow, but not sure if I catch it. And
>>> >next week I would like to start on persistent client grants. I guess
>>> >it's not an issue to possibly postpone this to some later release?
>>> >
>> I think it will help us tremendously in product if we have zero PL IDM
>> dependencies.  As we discussed in meetings, Picketlink is not going to
>> be upgraded in EAP7 and is a few versions back of the latest Picketlink.
>>    Keycloak LDAP integration currently has dependencies on latest and
>> greatest Picketlink.
>

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

From stian at redhat.com  Thu Apr  9 06:14:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Apr 2015 06:14:54 -0400 (EDT)
Subject: [keycloak-dev] Why do we have a Direct Grants Only option for oauth
	clients
In-Reply-To: <410923977.14961340.1428574455065.JavaMail.zimbra@redhat.com>
Message-ID: <291859328.14961476.1428574494542.JavaMail.zimbra@redhat.com>

Do we really need the Direct Grants Only option for Clients? IMO it should be the other way around and we should have a 'Direct Grant Allowed' option for Clients.

From stian at redhat.com  Thu Apr  9 07:18:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Apr 2015 07:18:17 -0400 (EDT)
Subject: [keycloak-dev] First round of unifying application and oauth clients
In-Reply-To: <654863170.15047325.1428578100075.JavaMail.zimbra@redhat.com>
Message-ID: <1714537189.15049716.1428578297944.JavaMail.zimbra@redhat.com>

First round of unifying application and oauth clients is done. What I've done is:

* Combined ApplicationModel and OAuthClientModel into ClientModel
* Removed OAuth Clients (html and js) from Admin Console and Admin Endpoints
* Renamed Applications menu entry to Clients in Admin Console

Next steps are:

* Add database migration
* Update Representations (deprecate OAuthClientRepresentation and ApplicationRepresentation and add ClientRepresentation)
* Rename Application to Client in Admin Endpoints and Admin Console html/js
* Look for other references to Application or OAuth Client in code
* Update documentation, including migration guide

From stian at redhat.com  Thu Apr  9 07:30:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Apr 2015 07:30:45 -0400 (EDT)
Subject: [keycloak-dev] Keykload and Swagger.io integration
In-Reply-To: <55251848.7070903@redhat.com>
References: <55251848.7070903@redhat.com>
Message-ID: <1178503542.15056207.1428579045967.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "pslegr" <pslegr at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 8 April, 2015 2:00:08 PM
> Subject: [keycloak-dev] Keykload and Swagger.io integration
> 
> Hi guys,
> 
> I've found an old thread wrt ${subject} here
> http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001842.html
> and I wonder, if there was some further research on it.
> 
> I need to integrate Swagger.io and Keycloak
> 
> Anyone tried out already, or having some example to show ?

Nope, but if you come up with something we want it :)

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

From stian at redhat.com  Thu Apr  9 08:01:09 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 9 Apr 2015 08:01:09 -0400 (EDT)
Subject: [keycloak-dev] offline access
In-Reply-To: <551E9D5C.1070304@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
	<551E9D5C.1070304@redhat.com>
Message-ID: <1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 3 April, 2015 4:02:04 PM
> Subject: Re: [keycloak-dev] offline access
> 
> Maybe we should use name "offline tokens" to not confuse them with
> classic "refresh tokens" ? Refresh tokens are used to refresh access
> token and they are always tight to user session, when "offline tokens"
> are not tight to user session.

I don't think there's anything in OpenID Connect that ties a refresh token to a user session, that's just what we've done.

See http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

> 
> Also IMO it should be possible that user grants access to client for
> store offline tokens in account management, not just on consent screen
> after login.
> 
> I think one of the important usecases for offline tokens would be long
> running non-web services (For example daemon service, which is running
> in background and doing periodic task on behalf of user once per day).
> Hence we should have possibility to grant offline tokens also to non-web
> applications (in other words, via Direct Access Grant). In this case,
> user might need to grant the access to the application in advance via
> Account mgmt.

Interesting idea. If offline access is just a role/scope we can do the same for any grants. That would let a user go into account management and grant a specific client access to any roles, which would make it possible to have an option for a client to require consent when using direct access as well.

But, thinking about it some more requiring consent for direct access is a bit pointless. For direct grant the user provides the client with the username/password so it would be very easy for a malicious client to circumvent requiring consent. For example by storing username/password in plain-text and use that to obtain tokens on behalf of other clients and/or login to account management or other apps directly. 

It's implied that a user has to trust the client (and consents to giving the client full access) when providing the client with the username/password directly. That is unless we add an option where a user can create client specific passwords, in which case a user could limit what roles are permitted for a specific password.

> 
> Marek
> 
> On 2.4.2015 13:52, Stian Thorgersen wrote:
> > Had an idea about offline tokens.
> >
> > When a user grants a client access we need to start persisting that so we
> > don't ask the user again and again for the same permissions to be given to
> > the application. This has to be stored permanently and not in user
> > session. That's the mechanism we should use for offline tokens.
> >
> > When a user grants an application offline access that grant is persisted.
> > This should be a special role. The grant should have an id and consist of:
> > grant_id, user_id, client_id, role_id. If a refresh token has the offline
> > scope it doesn't have to refer to a user session (or client session).
> > Instead all the required information should be kept in the refresh token.
> > The refresh token has a reference to the grant_id. If the grant with the
> > specific grant_id exists we know the user hasn't revoked the access for
> > the application. If it doesn't exist we know the user has revoked the
> > access and the "offline" refresh token is invalid.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 1 April, 2015 7:26:06 PM
> >> Subject: Re: [keycloak-dev] offline access
> >>
> >> I'm not to keen on that idea.
> >>
> >> offline is a standard scope in OIDC and an application requests this when
> >> first retrieving the token. When an application retrieves a refresh token
> >> with the offline scope set it should not be linked with the user session.
> >> Instead it should be stored permanently as the application now should have
> >> permanent offline access to the users account. If a user decides to revoke
> >> the applications access that should be done by going to the account
> >> management console and viewing client that have access to their account.
> >> This page should list all available clients, what clients have persisted
> >> grants, as well as what clients have offline access to their account. From
> >> the same page they should be able to revoke access from any client.
> >>
> >> As user sessions are not persisted they are not suitable to store offline
> >> tokens. Offline tokens will often have a very long expiration time, a year
> >> or even no expiration time at all (only manual revoking).
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 1 April, 2015 4:53:45 PM
> >>> Subject: [keycloak-dev] offline access
> >>>
> >>> Wanted to discuss again how offline access might be implemented.  IMO,
> >>> offline access should be a REST api.  Clients would request offline
> >>> access and the UserSession would be cloned and the ClientSession would
> >>> be cloned for that particular client.  ID, Access token and refresh
> >>> token would also be regenerated and sent back with the response.
> >>>
> >>> With this approach, the admin console and user account session
> >>> management pages will just work.  These pages will just work they way
> >>> they already work with no extra changes.
> >>>
> >>> Additionally, we would want to allow different session timeouts for
> >>> offline access.
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Thu Apr  9 09:02:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 09 Apr 2015 09:02:42 -0400
Subject: [keycloak-dev] offline access
In-Reply-To: <1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
	<551E9D5C.1070304@redhat.com>
	<1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>
Message-ID: <55267872.6010400@redhat.com>



On 4/9/2015 8:01 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 3 April, 2015 4:02:04 PM
>> Subject: Re: [keycloak-dev] offline access
>>
>> Maybe we should use name "offline tokens" to not confuse them with
>> classic "refresh tokens" ? Refresh tokens are used to refresh access
>> token and they are always tight to user session, when "offline tokens"
>> are not tight to user session.
>
> I don't think there's anything in OpenID Connect that ties a refresh token to a user session, that's just what we've done.
>
> See http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
>

That's not the way I read it.  There wouldn't be a section within OIDC 
about offline access if the refresh token wasn't assumed to be a part of 
a session.  IMO, "offline" is really just a persisted user/client 
session.  It is governed by the same exact rules as regular user 
sessions.  A client just needs permission to do it.   You would need to 
store the same exact metadata for "offline" sessions as you would for 
"online" ones.  What additional information is needed for "offline"? 
Again, this boils down in my opinion to just the current user session 
being cloned into a persisted "offline" session.

Admin console screens should be the same for "offline" and user 
sessions.  Main realm session screen has list of applications and the 
number of their online and offline sessions.  Same with the 
application's session page.

The user session page has a list of sessions with an "offline" column 
checked on or off.  This is the same for user account page.



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

From mposolda at redhat.com  Thu Apr  9 10:56:20 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 09 Apr 2015 16:56:20 +0200
Subject: [keycloak-dev] Why do we have a Direct Grants Only option for
 oauth clients
In-Reply-To: <291859328.14961476.1428574494542.JavaMail.zimbra@redhat.com>
References: <291859328.14961476.1428574494542.JavaMail.zimbra@redhat.com>
Message-ID: <55269314.1060208@redhat.com>

Only reason I see is, that you don't need to provide any redirect URI 
for these clients. How about having 3 states? Something like:
- Direct grants only (redirect URI field not mandatory and hidden)
- Direct grants allowed
- Direct grants not allowed

Marek

On 9.4.2015 12:14, Stian Thorgersen wrote:
> Do we really need the Direct Grants Only option for Clients? IMO it should be the other way around and we should have a 'Direct Grant Allowed' option for Clients.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Apr 10 00:27:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Apr 2015 00:27:06 -0400 (EDT)
Subject: [keycloak-dev] Why do we have a Direct Grants Only option for
 oauth clients
In-Reply-To: <55269314.1060208@redhat.com>
References: <291859328.14961476.1428574494542.JavaMail.zimbra@redhat.com>
	<55269314.1060208@redhat.com>
Message-ID: <1372503081.15611164.1428640026500.JavaMail.zimbra@redhat.com>

+1

----- 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, 9 April, 2015 4:56:20 PM
> Subject: Re: [keycloak-dev] Why do we have a Direct Grants Only option for oauth clients
> 
> Only reason I see is, that you don't need to provide any redirect URI
> for these clients. How about having 3 states? Something like:
> - Direct grants only (redirect URI field not mandatory and hidden)
> - Direct grants allowed
> - Direct grants not allowed
> 
> Marek
> 
> On 9.4.2015 12:14, Stian Thorgersen wrote:
> > Do we really need the Direct Grants Only option for Clients? IMO it should
> > be the other way around and we should have a 'Direct Grant Allowed' option
> > for Clients.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Fri Apr 10 01:00:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Apr 2015 01:00:48 -0400 (EDT)
Subject: [keycloak-dev] offline access
In-Reply-To: <55267872.6010400@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
	<551E9D5C.1070304@redhat.com>
	<1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>
	<55267872.6010400@redhat.com>
Message-ID: <143679936.15615323.1428642048905.JavaMail.zimbra@redhat.com>

Cloning into offline persistence is a good way to do it, I'm worried about the complexity of it though. We'd need two separate user session stores and do we look in both when there's a request for a user session? If we don't look in both how do we make sure the persisted sessions are re-loaded into the non-peristed store at startup time? That's even worse in a cluster. I've implemented a hybrid store (where some stuff was kept in jpa and others in-mem) it did end up as a bit of a cluster fuck though.

I don't have an issue with admins managing offline sessions in the existing way they manage sessions, actually that's probably the best way. We would probably need to add support for logging out all or just non-offline when logging out a user or application though.

I don't like the idea of just having an offline column in account management though as I think that's confusing to users. We need to at some point give the account management some TLC as it looks pretty horrible and there's some concepts that's probably confusing to most users. For example sessions, logs and even worse federated identities. As a user I'd expect a list of devices that I have logged in (Home computer, Work computer, Mobile, etc.) and the ability to log that out. Then I'd expect a separate list of applications/clients that can access my account where I can revoke access to a specific client (which would also invalidate any offline access). That's still perfectly achievable with either two approaches though.

Finally, we also need to introduce an offline role/scope that we can assign to applications either through admin console, but it should also be possible to use ?scope=offline which is what the OIDC spec mandates. This would then work together with persisting consent/grants and the account management would show what permissions each client has, including offline access. There should be a single revoke access button for each client. That would remove all persisted consents/grant for that client and also remove all client sessions for that client. Doing that would also expire all "offline" refresh tokens without requiring the user to manually manage "client sessions".

Another thing we should probably also add support to view/manage persisted consents in the admin console. For example an admin should be able to see what consents a user has given to what application and also revoke.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 9 April, 2015 3:02:42 PM
> Subject: Re: [keycloak-dev] offline access
> 
> 
> 
> On 4/9/2015 8:01 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 3 April, 2015 4:02:04 PM
> >> Subject: Re: [keycloak-dev] offline access
> >>
> >> Maybe we should use name "offline tokens" to not confuse them with
> >> classic "refresh tokens" ? Refresh tokens are used to refresh access
> >> token and they are always tight to user session, when "offline tokens"
> >> are not tight to user session.
> >
> > I don't think there's anything in OpenID Connect that ties a refresh token
> > to a user session, that's just what we've done.
> >
> > See http://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess
> >
> 
> That's not the way I read it.  There wouldn't be a section within OIDC
> about offline access if the refresh token wasn't assumed to be a part of
> a session.  IMO, "offline" is really just a persisted user/client
> session.  
> It is governed by the same exact rules as regular user
> sessions.  A client just needs permission to do it.   You would need to
> store the same exact metadata for "offline" sessions as you would for
> "online" ones.  What additional information is needed for "offline"?
> Again, this boils down in my opinion to just the current user session
> being cloned into a persisted "offline" session.
> 
> Admin console screens should be the same for "offline" and user
> sessions.  Main realm session screen has list of applications and the
> number of their online and offline sessions.  Same with the
> application's session page.
> 
> The user session page has a list of sessions with an "offline" column
> checked on or off.  This is the same for user account page.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Fri Apr 10 01:31:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 10 Apr 2015 01:31:54 -0400 (EDT)
Subject: [keycloak-dev] Keycloak Docker image updated to 1.2.0.Beta1
Message-ID: <1157817272.15644671.1428643914944.JavaMail.zimbra@redhat.com>

Keycloak Docker image updated to 1.2.0.Beta1

https://registry.hub.docker.com/u/jboss/keycloak/

From ssilvert at redhat.com  Fri Apr 10 09:15:51 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Apr 2015 09:15:51 -0400
Subject: [keycloak-dev] KeycloakSession question
Message-ID: <5527CD07.90907@redhat.com>

Is KeycloakSession always short-lived?

If so, it might be relatively easy to make the JSON File based 
persistence more robust and probably fix the cache tests that currently 
fail with it.

All KeycloakSessions would share the same in-memory model.  When a 
KeycloakSession ends and requests to write the model to disk, all new 
requests for access to the model are blocked.  When all active 
KeycloakSessions are done, we write out the model and unblock the new 
KeycloakSessions.

But this only works if we can assume KeycloakSession is short-lived.

From bburke at redhat.com  Fri Apr 10 10:24:40 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Apr 2015 10:24:40 -0400
Subject: [keycloak-dev] offline access
In-Reply-To: <143679936.15615323.1428642048905.JavaMail.zimbra@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
	<551E9D5C.1070304@redhat.com>
	<1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>
	<55267872.6010400@redhat.com>
	<143679936.15615323.1428642048905.JavaMail.zimbra@redhat.com>
Message-ID: <5527DD28.8010306@redhat.com>



On 4/10/2015 1:00 AM, Stian Thorgersen wrote:
> Cloning into offline persistence is a good way to do it, I'm worried about the complexity of it though. We'd need two separate user session stores and do we look in both when there's a request for a user session? If we don't look in both how do we make sure the persisted sessions are re-loaded into the non-peristed store at startup time? That's even worse in a cluster. I've implemented a hybrid store (where some stuff was kept in jpa and others in-mem) it did end up as a bit of a cluster fuck though.
>

I'm not worried about the complexity as we do something similar for user 
federation: UserFederationManager.  KeycloakSession also allows you to 
get access to internal storage, verses a logically federated view.

But...when I think about it more, maybe there are performance 
implications to my suggestion?  Would refresh token hit the DB 
unnecessarily?  Maybe this isn't an issue because refresh token requests 
rarely reference expired refresh tokens.

> I don't have an issue with admins managing offline sessions in the existing way they manage sessions, actually that's probably the best way. We would probably need to add support for logging out all or just non-offline when logging out a user or application though.
>
> I don't like the idea of just having an offline column in account management though as I think that's confusing to users. We need to at some point give the account management some TLC as it looks pretty horrible and there's some concepts that's probably confusing to most users. For example sessions, logs and even worse federated identities. As a user I'd expect a list of devices that I have logged in (Home computer, Work computer, Mobile, etc.) and the ability to log that out. Then I'd expect a separate list of applications/clients that can access my account where I can revoke access to a specific client (which would also invalidate any offline access). That's still perfectly achievable with either two approaches though.
>

I agree on account management needing some love.  I'd like to see us 
incorporate IP address demographics, then somebody could see where a 
login was from  i.e. USA, China, etc.  They don't need to see the IP 
address.

We will have to start logging user-agent header information in 
UserSession so that we can determine if the user was logged in via a 
device or not.  We'll also have to add a description to Applications. 
Otherwise the only designations we would be able to show is "Browser, 
Device, and Offline".

> Finally, we also need to introduce an offline role/scope that we can assign to applications either through admin console, but it should also be possible to use ?scope=offline which is what the OIDC spec mandates. This would then work together with persisting consent/grants and the account management would show what permissions each client has, including offline access. There should be a single revoke access button for each client. That would remove all persisted consents/grant for that client and also remove all client sessions for that client. Doing that would also expire all "offline" refresh tokens without requiring the user to manually manage "client sessions".
>
> Another thing we should probably also add support to view/manage persisted consents in the admin console. For example an admin should be able to see what consents a user has given to what application and also revoke.
>

We already know what the user has consented to.  This information is 
within the application's configured metadata: scope mappings, protocol 
mappers, etc.

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

From bburke at redhat.com  Fri Apr 10 10:28:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Apr 2015 10:28:48 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <5527CD07.90907@redhat.com>
References: <5527CD07.90907@redhat.com>
Message-ID: <5527DE20.3070608@redhat.com>

KeycloakSession is analogous to an EntityManager in JPA.  It only exists 
for the duration of the request.  What you'd want is for File-based 
storage to queue up writes and flush them when the KeycloakSession is 
committed.

On 4/10/2015 9:15 AM, Stan Silvert wrote:
> Is KeycloakSession always short-lived?
>
> If so, it might be relatively easy to make the JSON File based
> persistence more robust and probably fix the cache tests that currently
> fail with it.
>
> All KeycloakSessions would share the same in-memory model.  When a
> KeycloakSession ends and requests to write the model to disk, all new
> requests for access to the model are blocked.  When all active
> KeycloakSessions are done, we write out the model and unblock the new
> KeycloakSessions.
>
> But this only works if we can assume KeycloakSession is short-lived.
> _______________________________________________
> 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  Fri Apr 10 11:55:49 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Apr 2015 11:55:49 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <5527DE20.3070608@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
Message-ID: <5527F285.4070003@redhat.com>

On 4/10/2015 10:28 AM, Bill Burke wrote:
> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
> for the duration of the request.  What you'd want is for File-based
> storage to queue up writes and flush them when the KeycloakSession is
> committed.
That's basically what happens now.  The problem is that there is no 
concept of individual writes.  Every time you write, you must write the 
entire model.  With each KeycloakSession having its own copy of the 
model, one KeycloakSession can overwrite the changes of another.

If you use a single shared in-memory model, you have to wait until 
everyone is done writing to it before you can save it to disk. That's 
the scheme I outlined below.  It sounds like it will work since we know 
that each KeycloakSession will end in a timely manner.

>
> On 4/10/2015 9:15 AM, Stan Silvert wrote:
>> Is KeycloakSession always short-lived?
>>
>> If so, it might be relatively easy to make the JSON File based
>> persistence more robust and probably fix the cache tests that currently
>> fail with it.
>>
>> All KeycloakSessions would share the same in-memory model.  When a
>> KeycloakSession ends and requests to write the model to disk, all new
>> requests for access to the model are blocked.  When all active
>> KeycloakSessions are done, we write out the model and unblock the new
>> KeycloakSessions.
>>
>> But this only works if we can assume KeycloakSession is short-lived.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Fri Apr 10 12:28:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 10 Apr 2015 12:28:51 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <5527F285.4070003@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com>
Message-ID: <5527FA43.4050604@redhat.com>

Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a 
write method is called on the adapter, you know that underlying instance 
must be synced at commit time.

So, here are the steps you should do:

1. Somebody accesses RealmModel
2. RealmAdapter is created, it delegates to shared in-memory model
3. If RealmAdapter write method is called copy in-memory model of 
RealmAdapter, make your changes within the copy
4. At commit, flush the changes to the RealmAdapter to main memory model 
and disk.

If you want to get more consistency, add a version field to in-memory 
model, that way you can do "optimistic" concurrency and abort the sync 
if the version field is changed.  We should actually probably do this 
with our JPA model too.

On 4/10/2015 11:55 AM, Stan Silvert wrote:
> On 4/10/2015 10:28 AM, Bill Burke wrote:
>> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
>> for the duration of the request.  What you'd want is for File-based
>> storage to queue up writes and flush them when the KeycloakSession is
>> committed.
> That's basically what happens now.  The problem is that there is no
> concept of individual writes.  Every time you write, you must write the
> entire model.  With each KeycloakSession having its own copy of the
> model, one KeycloakSession can overwrite the changes of another.
>
> If you use a single shared in-memory model, you have to wait until
> everyone is done writing to it before you can save it to disk. That's
> the scheme I outlined below.  It sounds like it will work since we know
> that each KeycloakSession will end in a timely manner.
>
>>
>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
>>> Is KeycloakSession always short-lived?
>>>
>>> If so, it might be relatively easy to make the JSON File based
>>> persistence more robust and probably fix the cache tests that currently
>>> fail with it.
>>>
>>> All KeycloakSessions would share the same in-memory model.  When a
>>> KeycloakSession ends and requests to write the model to disk, all new
>>> requests for access to the model are blocked.  When all active
>>> KeycloakSessions are done, we write out the model and unblock the new
>>> KeycloakSessions.
>>>
>>> But this only works if we can assume KeycloakSession is short-lived.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Fri Apr 10 12:50:17 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 10 Apr 2015 12:50:17 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <5527FA43.4050604@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com> <5527FA43.4050604@redhat.com>
Message-ID: <5527FF49.50208@redhat.com>

Besides needing to implement a way to make the in-memory copy, that 
would leave me with the same problem I have now.

If I write the copy to disk, I might overwrite changes from some other 
KeycloakSession.  Remember, I have to write the whole model to disk and 
my local model might be stale.  This is the problem I have today as 
every KeycloakSession has its own copy that was read from disk.

If I write from the master in-memory model, I need to wait for active 
sessions to end before I write it out to disk.  That's what I'm 
proposing to do.

On 4/10/2015 12:28 PM, Bill Burke wrote:
> Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a
> write method is called on the adapter, you know that underlying instance
> must be synced at commit time.
>
> So, here are the steps you should do:
>
> 1. Somebody accesses RealmModel
> 2. RealmAdapter is created, it delegates to shared in-memory model
> 3. If RealmAdapter write method is called copy in-memory model of
> RealmAdapter, make your changes within the copy
> 4. At commit, flush the changes to the RealmAdapter to main memory model
> and disk.
>
> If you want to get more consistency, add a version field to in-memory
> model, that way you can do "optimistic" concurrency and abort the sync
> if the version field is changed.  We should actually probably do this
> with our JPA model too.
>
> On 4/10/2015 11:55 AM, Stan Silvert wrote:
>> On 4/10/2015 10:28 AM, Bill Burke wrote:
>>> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
>>> for the duration of the request.  What you'd want is for File-based
>>> storage to queue up writes and flush them when the KeycloakSession is
>>> committed.
>> That's basically what happens now.  The problem is that there is no
>> concept of individual writes.  Every time you write, you must write the
>> entire model.  With each KeycloakSession having its own copy of the
>> model, one KeycloakSession can overwrite the changes of another.
>>
>> If you use a single shared in-memory model, you have to wait until
>> everyone is done writing to it before you can save it to disk. That's
>> the scheme I outlined below.  It sounds like it will work since we know
>> that each KeycloakSession will end in a timely manner.
>>
>>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
>>>> Is KeycloakSession always short-lived?
>>>>
>>>> If so, it might be relatively easy to make the JSON File based
>>>> persistence more robust and probably fix the cache tests that currently
>>>> fail with it.
>>>>
>>>> All KeycloakSessions would share the same in-memory model.  When a
>>>> KeycloakSession ends and requests to write the model to disk, all new
>>>> requests for access to the model are blocked.  When all active
>>>> KeycloakSessions are done, we write out the model and unblock the new
>>>> KeycloakSessions.
>>>>
>>>> But this only works if we can assume KeycloakSession is short-lived.
>>>> _______________________________________________
>>>> 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 prabhalar at yahoo.com  Sun Apr 12 06:58:15 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Sun, 12 Apr 2015 10:58:15 +0000 (UTC)
Subject: [keycloak-dev] Cross Client Use case
Message-ID: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>

?We have a use case similar to the one listed in the below url - basically once a user is authenticated, a client application after receiving the tokens from the Provider, shares the tokens with a few other applications that are in a group. The other client applications should be able to verify the tokens without requiring any more user interaction. In the OIDC world, unfortunately, the aud parameter has the clientid of the first app only and it will fail validation by the other apps. So, is there any way this can be? handled in KC?
https://developers.google.com/identity/protocols/CrossClientAuth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150412/867f8112/attachment.html 

From stian at redhat.com  Mon Apr 13 00:44:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Apr 2015 00:44:15 -0400 (EDT)
Subject: [keycloak-dev] offline access
In-Reply-To: <5527DD28.8010306@redhat.com>
References: <551C0679.9090808@redhat.com>
	<126656172.10272367.1427909166809.JavaMail.zimbra@redhat.com>
	<2018487093.10909834.1427975574112.JavaMail.zimbra@redhat.com>
	<551E9D5C.1070304@redhat.com>
	<1557275679.15104071.1428580869576.JavaMail.zimbra@redhat.com>
	<55267872.6010400@redhat.com>
	<143679936.15615323.1428642048905.JavaMail.zimbra@redhat.com>
	<5527DD28.8010306@redhat.com>
Message-ID: <1717533474.16973298.1428900255030.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 10 April, 2015 4:24:40 PM
> Subject: Re: [keycloak-dev] offline access
> 
> 
> 
> On 4/10/2015 1:00 AM, Stian Thorgersen wrote:
> > Cloning into offline persistence is a good way to do it, I'm worried about
> > the complexity of it though. We'd need two separate user session stores
> > and do we look in both when there's a request for a user session? If we
> > don't look in both how do we make sure the persisted sessions are
> > re-loaded into the non-peristed store at startup time? That's even worse
> > in a cluster. I've implemented a hybrid store (where some stuff was kept
> > in jpa and others in-mem) it did end up as a bit of a cluster fuck though.
> >
> 
> I'm not worried about the complexity as we do something similar for user
> federation: UserFederationManager.  KeycloakSession also allows you to
> get access to internal storage, verses a logically federated view.
> 
> But...when I think about it more, maybe there are performance
> implications to my suggestion?  Would refresh token hit the DB
> unnecessarily?  Maybe this isn't an issue because refresh token requests
> rarely reference expired refresh tokens.
> 
> > I don't have an issue with admins managing offline sessions in the existing
> > way they manage sessions, actually that's probably the best way. We would
> > probably need to add support for logging out all or just non-offline when
> > logging out a user or application though.
> >
> > I don't like the idea of just having an offline column in account
> > management though as I think that's confusing to users. We need to at some
> > point give the account management some TLC as it looks pretty horrible and
> > there's some concepts that's probably confusing to most users. For example
> > sessions, logs and even worse federated identities. As a user I'd expect a
> > list of devices that I have logged in (Home computer, Work computer,
> > Mobile, etc.) and the ability to log that out. Then I'd expect a separate
> > list of applications/clients that can access my account where I can revoke
> > access to a specific client (which would also invalidate any offline
> > access). That's still perfectly achievable with either two approaches
> > though.
> >
> 
> I agree on account management needing some love.  I'd like to see us
> incorporate IP address demographics, then somebody could see where a
> login was from  i.e. USA, China, etc.  They don't need to see the IP
> address.
> 
> We will have to start logging user-agent header information in
> UserSession so that we can determine if the user was logged in via a
> device or not.  We'll also have to add a description to Applications.
> Otherwise the only designations we would be able to show is "Browser,
> Device, and Offline".
> 
> > Finally, we also need to introduce an offline role/scope that we can assign
> > to applications either through admin console, but it should also be
> > possible to use ?scope=offline which is what the OIDC spec mandates. This
> > would then work together with persisting consent/grants and the account
> > management would show what permissions each client has, including offline
> > access. There should be a single revoke access button for each client.
> > That would remove all persisted consents/grant for that client and also
> > remove all client sessions for that client. Doing that would also expire
> > all "offline" refresh tokens without requiring the user to manually manage
> > "client sessions".
> >
> > Another thing we should probably also add support to view/manage persisted
> > consents in the admin console. For example an admin should be able to see
> > what consents a user has given to what application and also revoke.
> >
> 
> We already know what the user has consented to.  This information is
> within the application's configured metadata: scope mappings, protocol
> mappers, etc.

Those can change over time though, which means that what a user previously consented to might be different to the clients "scope". Also, at some point we probably should introduce support for scope query param, which means each "login request" from an application could request different scopes. OIDC has a number of "scopes" that I'm pretty sure we need to support if we're going be a valid implementation.

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

From stian at redhat.com  Mon Apr 13 02:02:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Apr 2015 02:02:08 -0400 (EDT)
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <5527FF49.50208@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com> <5527FA43.4050604@redhat.com>
	<5527FF49.50208@redhat.com>
Message-ID: <891468497.17001557.1428904928708.JavaMail.zimbra@redhat.com>

As I've proposed before DefaultFileConnectionProviderFactory should have a ReadWriteLock. DefaultFileConnectionProvider should get a read lock. Then there should be a background thread that writes the changes, this should get a write lock. Simple and efficient.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 10 April, 2015 6:50:17 PM
> Subject: Re: [keycloak-dev] KeycloakSession question
> 
> Besides needing to implement a way to make the in-memory copy, that
> would leave me with the same problem I have now.
> 
> If I write the copy to disk, I might overwrite changes from some other
> KeycloakSession.  Remember, I have to write the whole model to disk and
> my local model might be stale.  This is the problem I have today as
> every KeycloakSession has its own copy that was read from disk.
> 
> If I write from the master in-memory model, I need to wait for active
> sessions to end before I write it out to disk.  That's what I'm
> proposing to do.
> 
> On 4/10/2015 12:28 PM, Bill Burke wrote:
> > Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a
> > write method is called on the adapter, you know that underlying instance
> > must be synced at commit time.
> >
> > So, here are the steps you should do:
> >
> > 1. Somebody accesses RealmModel
> > 2. RealmAdapter is created, it delegates to shared in-memory model
> > 3. If RealmAdapter write method is called copy in-memory model of
> > RealmAdapter, make your changes within the copy
> > 4. At commit, flush the changes to the RealmAdapter to main memory model
> > and disk.
> >
> > If you want to get more consistency, add a version field to in-memory
> > model, that way you can do "optimistic" concurrency and abort the sync
> > if the version field is changed.  We should actually probably do this
> > with our JPA model too.
> >
> > On 4/10/2015 11:55 AM, Stan Silvert wrote:
> >> On 4/10/2015 10:28 AM, Bill Burke wrote:
> >>> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
> >>> for the duration of the request.  What you'd want is for File-based
> >>> storage to queue up writes and flush them when the KeycloakSession is
> >>> committed.
> >> That's basically what happens now.  The problem is that there is no
> >> concept of individual writes.  Every time you write, you must write the
> >> entire model.  With each KeycloakSession having its own copy of the
> >> model, one KeycloakSession can overwrite the changes of another.
> >>
> >> If you use a single shared in-memory model, you have to wait until
> >> everyone is done writing to it before you can save it to disk. That's
> >> the scheme I outlined below.  It sounds like it will work since we know
> >> that each KeycloakSession will end in a timely manner.
> >>
> >>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
> >>>> Is KeycloakSession always short-lived?
> >>>>
> >>>> If so, it might be relatively easy to make the JSON File based
> >>>> persistence more robust and probably fix the cache tests that currently
> >>>> fail with it.
> >>>>
> >>>> All KeycloakSessions would share the same in-memory model.  When a
> >>>> KeycloakSession ends and requests to write the model to disk, all new
> >>>> requests for access to the model are blocked.  When all active
> >>>> KeycloakSessions are done, we write out the model and unblock the new
> >>>> KeycloakSessions.
> >>>>
> >>>> But this only works if we can assume KeycloakSession is short-lived.
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Mon Apr 13 08:00:28 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 13 Apr 2015 08:00:28 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <891468497.17001557.1428904928708.JavaMail.zimbra@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com> <5527FA43.4050604@redhat.com>
	<5527FF49.50208@redhat.com>
	<891468497.17001557.1428904928708.JavaMail.zimbra@redhat.com>
Message-ID: <552BAFDC.4040707@redhat.com>

On 4/13/2015 2:02 AM, Stian Thorgersen wrote:
> As I've proposed before DefaultFileConnectionProviderFactory should have a ReadWriteLock. DefaultFileConnectionProvider should get a read lock. Then there should be a background thread that writes the changes, this should get a write lock. Simple and efficient.
Walk me through this then.  What are you locking on?  The in-memory 
model or the file?  What is the step-by-step process?

I don't see how this is different from my proposal except that you are 
using a background thread.  But I might not be fully understanding what 
you want to do.

BTW, I'm not actively working on this.  But if I get a little spare time 
I'd like to try something that would fix the cache tests and I think 
this might do it.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 10 April, 2015 6:50:17 PM
>> Subject: Re: [keycloak-dev] KeycloakSession question
>>
>> Besides needing to implement a way to make the in-memory copy, that
>> would leave me with the same problem I have now.
>>
>> If I write the copy to disk, I might overwrite changes from some other
>> KeycloakSession.  Remember, I have to write the whole model to disk and
>> my local model might be stale.  This is the problem I have today as
>> every KeycloakSession has its own copy that was read from disk.
>>
>> If I write from the master in-memory model, I need to wait for active
>> sessions to end before I write it out to disk.  That's what I'm
>> proposing to do.
>>
>> On 4/10/2015 12:28 PM, Bill Burke wrote:
>>> Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a
>>> write method is called on the adapter, you know that underlying instance
>>> must be synced at commit time.
>>>
>>> So, here are the steps you should do:
>>>
>>> 1. Somebody accesses RealmModel
>>> 2. RealmAdapter is created, it delegates to shared in-memory model
>>> 3. If RealmAdapter write method is called copy in-memory model of
>>> RealmAdapter, make your changes within the copy
>>> 4. At commit, flush the changes to the RealmAdapter to main memory model
>>> and disk.
>>>
>>> If you want to get more consistency, add a version field to in-memory
>>> model, that way you can do "optimistic" concurrency and abort the sync
>>> if the version field is changed.  We should actually probably do this
>>> with our JPA model too.
>>>
>>> On 4/10/2015 11:55 AM, Stan Silvert wrote:
>>>> On 4/10/2015 10:28 AM, Bill Burke wrote:
>>>>> KeycloakSession is analogous to an EntityManager in JPA.  It only exists
>>>>> for the duration of the request.  What you'd want is for File-based
>>>>> storage to queue up writes and flush them when the KeycloakSession is
>>>>> committed.
>>>> That's basically what happens now.  The problem is that there is no
>>>> concept of individual writes.  Every time you write, you must write the
>>>> entire model.  With each KeycloakSession having its own copy of the
>>>> model, one KeycloakSession can overwrite the changes of another.
>>>>
>>>> If you use a single shared in-memory model, you have to wait until
>>>> everyone is done writing to it before you can save it to disk. That's
>>>> the scheme I outlined below.  It sounds like it will work since we know
>>>> that each KeycloakSession will end in a timely manner.
>>>>
>>>>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
>>>>>> Is KeycloakSession always short-lived?
>>>>>>
>>>>>> If so, it might be relatively easy to make the JSON File based
>>>>>> persistence more robust and probably fix the cache tests that currently
>>>>>> fail with it.
>>>>>>
>>>>>> All KeycloakSessions would share the same in-memory model.  When a
>>>>>> KeycloakSession ends and requests to write the model to disk, all new
>>>>>> requests for access to the model are blocked.  When all active
>>>>>> KeycloakSessions are done, we write out the model and unblock the new
>>>>>> KeycloakSessions.
>>>>>>
>>>>>> But this only works if we can assume KeycloakSession is short-lived.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Mon Apr 13 08:10:44 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 13 Apr 2015 08:10:44 -0400 (EDT)
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <552BAFDC.4040707@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com> <5527FA43.4050604@redhat.com>
	<5527FF49.50208@redhat.com>
	<891468497.17001557.1428904928708.JavaMail.zimbra@redhat.com>
	<552BAFDC.4040707@redhat.com>
Message-ID: <1181526455.17296417.1428927044147.JavaMail.zimbra@redhat.com>

DefaultFileConnectionProviderFactory has a single instance of InMemoryModel and a ReadWriteLock. When creating a DefaultFileConnectionProvider it obtains a read lock and passes it in to DefaultFileConnectionProvider, which is unlocked when DefaultFileConnectionProvider is closed. To write the file you could either have a background thread that does it, or just have DefaultFileConnectionProvider do it. In either case it should first obtain a write lock on the ReadWriteLock associated with DefaultFileConnectionProviderFactory. This lock makes sure that there isn't any sessions changing the model while writing to disk so you don't get inconsistencies.


----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 April, 2015 2:00:28 PM
> Subject: Re: [keycloak-dev] KeycloakSession question
> 
> On 4/13/2015 2:02 AM, Stian Thorgersen wrote:
> > As I've proposed before DefaultFileConnectionProviderFactory should have a
> > ReadWriteLock. DefaultFileConnectionProvider should get a read lock. Then
> > there should be a background thread that writes the changes, this should
> > get a write lock. Simple and efficient.
> Walk me through this then.  What are you locking on?  The in-memory
> model or the file?  What is the step-by-step process?
> 
> I don't see how this is different from my proposal except that you are
> using a background thread.  But I might not be fully understanding what
> you want to do.
> 
> BTW, I'm not actively working on this.  But if I get a little spare time
> I'd like to try something that would fix the cache tests and I think
> this might do it.
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 10 April, 2015 6:50:17 PM
> >> Subject: Re: [keycloak-dev] KeycloakSession question
> >>
> >> Besides needing to implement a way to make the in-memory copy, that
> >> would leave me with the same problem I have now.
> >>
> >> If I write the copy to disk, I might overwrite changes from some other
> >> KeycloakSession.  Remember, I have to write the whole model to disk and
> >> my local model might be stale.  This is the problem I have today as
> >> every KeycloakSession has its own copy that was read from disk.
> >>
> >> If I write from the master in-memory model, I need to wait for active
> >> sessions to end before I write it out to disk.  That's what I'm
> >> proposing to do.
> >>
> >> On 4/10/2015 12:28 PM, Bill Burke wrote:
> >>> Adapters are created per KeycloakSession too (RealmAdapter, etc.).  If a
> >>> write method is called on the adapter, you know that underlying instance
> >>> must be synced at commit time.
> >>>
> >>> So, here are the steps you should do:
> >>>
> >>> 1. Somebody accesses RealmModel
> >>> 2. RealmAdapter is created, it delegates to shared in-memory model
> >>> 3. If RealmAdapter write method is called copy in-memory model of
> >>> RealmAdapter, make your changes within the copy
> >>> 4. At commit, flush the changes to the RealmAdapter to main memory model
> >>> and disk.
> >>>
> >>> If you want to get more consistency, add a version field to in-memory
> >>> model, that way you can do "optimistic" concurrency and abort the sync
> >>> if the version field is changed.  We should actually probably do this
> >>> with our JPA model too.
> >>>
> >>> On 4/10/2015 11:55 AM, Stan Silvert wrote:
> >>>> On 4/10/2015 10:28 AM, Bill Burke wrote:
> >>>>> KeycloakSession is analogous to an EntityManager in JPA.  It only
> >>>>> exists
> >>>>> for the duration of the request.  What you'd want is for File-based
> >>>>> storage to queue up writes and flush them when the KeycloakSession is
> >>>>> committed.
> >>>> That's basically what happens now.  The problem is that there is no
> >>>> concept of individual writes.  Every time you write, you must write the
> >>>> entire model.  With each KeycloakSession having its own copy of the
> >>>> model, one KeycloakSession can overwrite the changes of another.
> >>>>
> >>>> If you use a single shared in-memory model, you have to wait until
> >>>> everyone is done writing to it before you can save it to disk. That's
> >>>> the scheme I outlined below.  It sounds like it will work since we know
> >>>> that each KeycloakSession will end in a timely manner.
> >>>>
> >>>>> On 4/10/2015 9:15 AM, Stan Silvert wrote:
> >>>>>> Is KeycloakSession always short-lived?
> >>>>>>
> >>>>>> If so, it might be relatively easy to make the JSON File based
> >>>>>> persistence more robust and probably fix the cache tests that
> >>>>>> currently
> >>>>>> fail with it.
> >>>>>>
> >>>>>> All KeycloakSessions would share the same in-memory model.  When a
> >>>>>> KeycloakSession ends and requests to write the model to disk, all new
> >>>>>> requests for access to the model are blocked.  When all active
> >>>>>> KeycloakSessions are done, we write out the model and unblock the new
> >>>>>> KeycloakSessions.
> >>>>>>
> >>>>>> But this only works if we can assume KeycloakSession is short-lived.
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From ssilvert at redhat.com  Mon Apr 13 08:24:58 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 13 Apr 2015 08:24:58 -0400
Subject: [keycloak-dev] KeycloakSession question
In-Reply-To: <1181526455.17296417.1428927044147.JavaMail.zimbra@redhat.com>
References: <5527CD07.90907@redhat.com> <5527DE20.3070608@redhat.com>
	<5527F285.4070003@redhat.com> <5527FA43.4050604@redhat.com>
	<5527FF49.50208@redhat.com>
	<891468497.17001557.1428904928708.JavaMail.zimbra@redhat.com>
	<552BAFDC.4040707@redhat.com>
	<1181526455.17296417.1428927044147.JavaMail.zimbra@redhat.com>
Message-ID: <552BB59A.2010200@redhat.com>

On 4/13/2015 8:10 AM, Stian Thorgersen wrote:
> DefaultFileConnectionProviderFactory has a single instance of InMemoryModel and a ReadWriteLock. When creating a DefaultFileConnectionProvider it obtains a read lock and passes it in to DefaultFileConnectionProvider, which is unlocked when DefaultFileConnectionProvider is closed. To write the file you could either have a background thread that does it, or just have DefaultFileConnectionProvider do it. In either case it should first obtain a write lock on the ReadWriteLock associated with DefaultFileConnectionProviderFactory. This lock makes sure that there isn't any sessions changing the model while writing to disk so you don't get inconsistencies.
OK.  That's exactly what I was proposing but I wasn't thinking about 
java.util.current.locks package, which makes the impl easier.  It still 
requires that KeycloakSession is always short-lived but it sounds like 
that is true.  So it should work.

From bburke at redhat.com  Mon Apr 13 09:37:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Apr 2015 09:37:49 -0400
Subject: [keycloak-dev] Cross Client Use case
In-Reply-To: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>
References: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <552BC6AD.4090807@redhat.com>

Our tokens are JsonWebSignatures.  If the other applications have the 
public key of the realm, they can verify those signatures.  Keycloak 
also has a remote validation URL which you can send a token to.

/auth/realms/{realm}/protocol/openid-connect/validate?access_token={token}



On 4/12/2015 6:58 AM, Raghu Prabhala wrote:
>   We have a use case similar to the one listed in the below url -
> basically once a user is authenticated, a client application after
> receiving the tokens from the Provider, shares the tokens with a few
> other applications that are in a group. The other client applications
> should be able to verify the tokens without requiring any more user
> interaction. In the OIDC world, unfortunately, the aud parameter has the
> clientid of the first app only and it will fail validation by the other
> apps. So, is there any way this can be  handled in KC?
>
> https://developers.google.com/identity/protocols/CrossClientAuth
>
>
>
> _______________________________________________
> 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 prabhalar at yahoo.com  Mon Apr 13 10:44:23 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Mon, 13 Apr 2015 10:44:23 -0400
Subject: [keycloak-dev] Cross Client Use case
In-Reply-To: <552BC6AD.4090807@redhat.com>
References: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>
	<552BC6AD.4090807@redhat.com>
Message-ID: <0E14C5AB-F02C-468D-B325-04D52A7B6FF3@yahoo.com>

Thanks Bill - I think the below info would be useful in case we decide to go for remote validation. But if we go for local validation of the tokens then we still have a problem as  we typically verify signature, issuer, expiry time and even audience. The issue is that "aud" will have the clientid of the first app and hence it will fail validation at the second and third apps. To address that issue, I am wondering if KC can be enhanced to group a set of client applications and if any of the apps within that group communicates with KC, then KC puts in all the clientids of all the apps in the group in the "aud" parameter of the tokens? That would address the "aud" validation with the second and third apps. Is that something that can be done in KC?

Thanks,
Raghu

Sent from my iPhone

> On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> Our tokens are JsonWebSignatures.  If the other applications have the 
> public key of the realm, they can verify those signatures.  Keycloak 
> also has a remote validation URL which you can send a token to.
> 
> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={token}
> 
> 
> 
>> On 4/12/2015 6:58 AM, Raghu Prabhala wrote:
>>  We have a use case similar to the one listed in the below url -
>> basically once a user is authenticated, a client application after
>> receiving the tokens from the Provider, shares the tokens with a few
>> other applications that are in a group. The other client applications
>> should be able to verify the tokens without requiring any more user
>> interaction. In the OIDC world, unfortunately, the aud parameter has the
>> clientid of the first app only and it will fail validation by the other
>> apps. So, is there any way this can be  handled in KC?
>> 
>> https://developers.google.com/identity/protocols/CrossClientAuth
>> 
>> 
>> 
>> _______________________________________________
>> 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  Mon Apr 13 11:00:27 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 13 Apr 2015 11:00:27 -0400
Subject: [keycloak-dev] Cross Client Use case
In-Reply-To: <0E14C5AB-F02C-468D-B325-04D52A7B6FF3@yahoo.com>
References: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>
	<552BC6AD.4090807@redhat.com>
	<0E14C5AB-F02C-468D-B325-04D52A7B6FF3@yahoo.com>
Message-ID: <552BDA0B.1000201@redhat.com>

We do not have this capability.  Submit a JIRA and I'll eventually add a 
ProtocolMapper than can add additional audiences.

Alternatively, your applications could have their own internal list of 
valid audiences.  Or, you could just ignore the audience when you validate.

On 4/13/2015 10:44 AM, Raghu Prabhala wrote:
> Thanks Bill - I think the below info would be useful in case we decide to go for remote validation. But if we go for local validation of the tokens then we still have a problem as  we typically verify signature, issuer, expiry time and even audience. The issue is that "aud" will have the clientid of the first app and hence it will fail validation at the second and third apps. To address that issue, I am wondering if KC can be enhanced to group a set of client applications and if any of the apps within that group communicates with KC, then KC puts in all the clientids of all the apps in the group in the "aud" parameter of the tokens? That would address the "aud" validation with the second and third apps. Is that something that can be done in KC?
>
> Thanks,
> Raghu
>
> Sent from my iPhone
>
>> On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> Our tokens are JsonWebSignatures.  If the other applications have the
>> public key of the realm, they can verify those signatures.  Keycloak
>> also has a remote validation URL which you can send a token to.
>>
>> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={token}
>>
>>
>>
>>> On 4/12/2015 6:58 AM, Raghu Prabhala wrote:
>>>   We have a use case similar to the one listed in the below url -
>>> basically once a user is authenticated, a client application after
>>> receiving the tokens from the Provider, shares the tokens with a few
>>> other applications that are in a group. The other client applications
>>> should be able to verify the tokens without requiring any more user
>>> interaction. In the OIDC world, unfortunately, the aud parameter has the
>>> clientid of the first app only and it will fail validation by the other
>>> apps. So, is there any way this can be  handled in KC?
>>>
>>> https://developers.google.com/identity/protocols/CrossClientAuth
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 prabhalar at yahoo.com  Mon Apr 13 11:16:49 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Mon, 13 Apr 2015 11:16:49 -0400
Subject: [keycloak-dev] Cross Client Use case
In-Reply-To: <552BDA0B.1000201@redhat.com>
References: <1081572966.1170749.1428836295074.JavaMail.yahoo@mail.yahoo.com>
	<552BC6AD.4090807@redhat.com>
	<0E14C5AB-F02C-468D-B325-04D52A7B6FF3@yahoo.com>
	<552BDA0B.1000201@redhat.com>
Message-ID: <DC57E8E4-D7BD-4CD4-8D41-F004C3B59CC0@yahoo.com>

Great. I will submit the Jira. Having the internal list of valid audiences is what I had in mind ? as an alternative but that is a slippery road as the app owners could add in valid audiences and we wanted them to be centrally controlled and monitored.

Sent from my iPhone

> On Apr 13, 2015, at 11:00 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> We do not have this capability.  Submit a JIRA and I'll eventually add a ProtocolMapper than can add additional audiences.
> 
> Alternatively, your applications could have their own internal list of valid audiences.  Or, you could just ignore the audience when you validate.
> 
>> On 4/13/2015 10:44 AM, Raghu Prabhala wrote:
>> Thanks Bill - I think the below info would be useful in case we decide to go for remote validation. But if we go for local validation of the tokens then we still have a problem as  we typically verify signature, issuer, expiry time and even audience. The issue is that "aud" will have the clientid of the first app and hence it will fail validation at the second and third apps. To address that issue, I am wondering if KC can be enhanced to group a set of client applications and if any of the apps within that group communicates with KC, then KC puts in all the clientids of all the apps in the group in the "aud" parameter of the tokens? That would address the "aud" validation with the second and third apps. Is that something that can be done in KC?
>> 
>> Thanks,
>> Raghu
>> 
>> Sent from my iPhone
>> 
>>> On Apr 13, 2015, at 9:37 AM, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>> Our tokens are JsonWebSignatures.  If the other applications have the
>>> public key of the realm, they can verify those signatures.  Keycloak
>>> also has a remote validation URL which you can send a token to.
>>> 
>>> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={token}
>>> 
>>> 
>>> 
>>>> On 4/12/2015 6:58 AM, Raghu Prabhala wrote:
>>>>  We have a use case similar to the one listed in the below url -
>>>> basically once a user is authenticated, a client application after
>>>> receiving the tokens from the Provider, shares the tokens with a few
>>>> other applications that are in a group. The other client applications
>>>> should be able to verify the tokens without requiring any more user
>>>> interaction. In the OIDC world, unfortunately, the aud parameter has the
>>>> clientid of the first app only and it will fail validation by the other
>>>> apps. So, is there any way this can be  handled in KC?
>>>> 
>>>> https://developers.google.com/identity/protocols/CrossClientAuth
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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  Tue Apr 14 02:28:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 02:28:19 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <401716569.18000364.1428991992883.JavaMail.zimbra@redhat.com>
Message-ID: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>

We've discussed this and I hope we're all on the same page, but just to confirm here's what we've discussed:

Keycloak Server
---------------

* Standalone
  - Built on WildFly servlet-only
  - No 'standalone/deployments' directory
  - Includes server only sub-system
  - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc, included)
  - Keycloak deployed to root context (http://localhost:8080)
* Demo Bundle
  - Built on WildFly full
  - Includes demo ready deployed and configured
  - Includes server and adapter sub-systems
  - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs, examples, etc.)
  - Keycloak deployed to auth context (http://localhost:8080/auth)
* Installer
  - Installs Keycloak server sub-system into existing WildFly
  - Only "latests" WildFly at the time of release is supported
  - Keycloak deployed to auth context (http://localhost:8080/auth)


Keycloak Embedded
------------------

* Consumed by external JBoss projects to embed Keycloak
* Build-your-own WAR example repo


Keycloak Adapters
-----------------

* Separate download from server
* Installer for WildFly subsystem adapter
* We still have to decide if adapters should have a separate release cycle/version to the server
* We still have to decide if Java adapters should be moved to separate github repo


Finally, a set of releated tasks
--------------------------------

* Split subsystem into server and adapter
* Use standalone.xml instead keycloak-server.json (json will still be supported for embedded)
* Add support to use dmr/jboss-cli for configuring the server (for example a single jboss-cli batch script can add data-source and set Keycloak to use it)
* Add support to use dmr/jboss-cli for configure realms, apps and users
* Add support to use root-context with server subsystem

From stian at redhat.com  Tue Apr 14 04:41:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 04:41:35 -0400 (EDT)
Subject: [keycloak-dev] Hacking on Keycloak docs
In-Reply-To: <902001406.18096314.1429000836540.JavaMail.zimbra@redhat.com>
Message-ID: <384716450.18096496.1429000895708.JavaMail.zimbra@redhat.com>

I've updated the main README.md in the GitHub repo to include some details on how to build and run Keycloak.

As we had some developer related docs in GitHub wiki (https://github.com/keycloak/keycloak/wiki) and some in repo itself (https://github.com/keycloak/keycloak/tree/master/misc) I've deleted the out of date stuff and moved everything to https://github.com/keycloak/keycloak/tree/master/misc.

I've also added a Hacking on Keycloak guide (https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md).

From mstrukel at redhat.com  Tue Apr 14 06:29:30 2015
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 14 Apr 2015 06:29:30 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
Message-ID: <714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>

Yesterday a had a little conversation with Stan, and he thought the code split may result in a lot of subsystem plumbing code duplication and make things more difficult for Elytron integration, and make OOTB config for examples slightly more complicated ...

As far as I understood it the idea is a code split, and module dependencies split, and it's there to be able to make a standalone distribution that will not contain any of adapter-specific configuration / dependencies / modules. The price of duplicated plumbing, and a lack of OOTB adapter configuration for standalone  - server and adapter in the same WildFly - is agreed to be outweighed (so I understand) by some benefits - but I'm not sure what those are (cleaner codebase? The ability to be able to install adapter only into existing WildFly without also installing the server parts - auth-server.war? Something else?)

Server / adapter split will have to identify code that is shared between server and adapter, which will be modularized out of the subsystem.

Stan can tell more, but as I understood his idea was that the one and single subsystem could present two faces, and based on availability of some modules for example present a server only, an adapter only, or a full view of configuration options, and that might be simpler than splitting existing subsystem into three parts - server, adapter, shared.


----- Original Message -----
> We've discussed this and I hope we're all on the same page, but just to
> confirm here's what we've discussed:
> 
> Keycloak Server
> ---------------
> 
> * Standalone
>   - Built on WildFly servlet-only
>   - No 'standalone/deployments' directory
>   - Includes server only sub-system
>   - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
>   included)
>   - Keycloak deployed to root context (http://localhost:8080)
> * Demo Bundle
>   - Built on WildFly full
>   - Includes demo ready deployed and configured
>   - Includes server and adapter sub-systems
>   - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
>   examples, etc.)
>   - Keycloak deployed to auth context (http://localhost:8080/auth)
> * Installer
>   - Installs Keycloak server sub-system into existing WildFly
>   - Only "latests" WildFly at the time of release is supported
>   - Keycloak deployed to auth context (http://localhost:8080/auth)
> 
> 
> Keycloak Embedded
> ------------------
> 
> * Consumed by external JBoss projects to embed Keycloak
> * Build-your-own WAR example repo
> 
> 
> Keycloak Adapters
> -----------------
> 
> * Separate download from server
> * Installer for WildFly subsystem adapter
> * We still have to decide if adapters should have a separate release
> cycle/version to the server
> * We still have to decide if Java adapters should be moved to separate github
> repo
> 
> 
> Finally, a set of releated tasks
> --------------------------------
> 
> * Split subsystem into server and adapter
> * Use standalone.xml instead keycloak-server.json (json will still be
> supported for embedded)
> * Add support to use dmr/jboss-cli for configuring the server (for example a
> single jboss-cli batch script can add data-source and set Keycloak to use
> it)
> * Add support to use dmr/jboss-cli for configure realms, apps and users
> * Add support to use root-context with server subsystem
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From lkrzyzan at redhat.com  Tue Apr 14 06:35:46 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Tue, 14 Apr 2015 12:35:46 +0200
Subject: [keycloak-dev] Hacking on Keycloak docs
In-Reply-To: <384716450.18096496.1429000895708.JavaMail.zimbra@redhat.com>
References: <384716450.18096496.1429000895708.JavaMail.zimbra@redhat.com>
Message-ID: <73F710EF-F5F7-4AA4-B620-48C948B29653@redhat.com>

Perfect!

Thanks,

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

> On 14 Apr 2015, at 10:41, Stian Thorgersen <stian at redhat.com> wrote:
> 
> I've updated the main README.md in the GitHub repo to include some details on how to build and run Keycloak.
> 
> As we had some developer related docs in GitHub wiki (https://github.com/keycloak/keycloak/wiki) and some in repo itself (https://github.com/keycloak/keycloak/tree/master/misc) I've deleted the out of date stuff and moved everything to https://github.com/keycloak/keycloak/tree/master/misc.
> 
> I've also added a Hacking on Keycloak guide (https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md).
> _______________________________________________
> 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/20150414/7edabe21/attachment.html 

From stian at redhat.com  Tue Apr 14 07:32:37 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 07:32:37 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
Message-ID: <280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>

I don't see how splitting the sub-system will make it more difficult for Elytron or OOTB config for examples. Anything we add to those should be just as usable whether or not Keycloak is running locally or remotely.

Splitting the sub-system has the advantages of isolating two very different features. Deploying and configuring Keycloak itself should be completely separated from configuring applications that use Keycloak. It makes the distribution of either cleaner. Also, for the server sub-system we only need to support latest WildFly and the distribution we build on-top of WildFly core/servlets-only. While for the adapter sub-system we'll need to support a range of EAP versions as well as potentially multiple WildFly versions.

Other than some initial boiler plating I don't see any benefits of having a single sub-system, and it'll be much easier to maintain two separate sub-systems IMO as they do two completely different things and it should be possible to deploy a single one of the sub-system or both together.

----- Original Message -----
> From: "Marko Strukelj" <mstrukel at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 14 April, 2015 12:29:30 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> Yesterday a had a little conversation with Stan, and he thought the code
> split may result in a lot of subsystem plumbing code duplication and make
> things more difficult for Elytron integration, and make OOTB config for
> examples slightly more complicated ...
> 
> As far as I understood it the idea is a code split, and module dependencies
> split, and it's there to be able to make a standalone distribution that will
> not contain any of adapter-specific configuration / dependencies / modules.
> The price of duplicated plumbing, and a lack of OOTB adapter configuration
> for standalone  - server and adapter in the same WildFly - is agreed to be
> outweighed (so I understand) by some benefits - but I'm not sure what those
> are (cleaner codebase? The ability to be able to install adapter only into
> existing WildFly without also installing the server parts - auth-server.war?
> Something else?)
> 
> Server / adapter split will have to identify code that is shared between
> server and adapter, which will be modularized out of the subsystem.
> 
> Stan can tell more, but as I understood his idea was that the one and single
> subsystem could present two faces, and based on availability of some modules
> for example present a server only, an adapter only, or a full view of
> configuration options, and that might be simpler than splitting existing
> subsystem into three parts - server, adapter, shared.
> 
> 
> ----- Original Message -----
> > We've discussed this and I hope we're all on the same page, but just to
> > confirm here's what we've discussed:
> > 
> > Keycloak Server
> > ---------------
> > 
> > * Standalone
> >   - Built on WildFly servlet-only
> >   - No 'standalone/deployments' directory
> >   - Includes server only sub-system
> >   - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
> >   included)
> >   - Keycloak deployed to root context (http://localhost:8080)
> > * Demo Bundle
> >   - Built on WildFly full
> >   - Includes demo ready deployed and configured
> >   - Includes server and adapter sub-systems
> >   - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
> >   examples, etc.)
> >   - Keycloak deployed to auth context (http://localhost:8080/auth)
> > * Installer
> >   - Installs Keycloak server sub-system into existing WildFly
> >   - Only "latests" WildFly at the time of release is supported
> >   - Keycloak deployed to auth context (http://localhost:8080/auth)
> > 
> > 
> > Keycloak Embedded
> > ------------------
> > 
> > * Consumed by external JBoss projects to embed Keycloak
> > * Build-your-own WAR example repo
> > 
> > 
> > Keycloak Adapters
> > -----------------
> > 
> > * Separate download from server
> > * Installer for WildFly subsystem adapter
> > * We still have to decide if adapters should have a separate release
> > cycle/version to the server
> > * We still have to decide if Java adapters should be moved to separate
> > github
> > repo
> > 
> > 
> > Finally, a set of releated tasks
> > --------------------------------
> > 
> > * Split subsystem into server and adapter
> > * Use standalone.xml instead keycloak-server.json (json will still be
> > supported for embedded)
> > * Add support to use dmr/jboss-cli for configuring the server (for example
> > a
> > single jboss-cli batch script can add data-source and set Keycloak to use
> > it)
> > * Add support to use dmr/jboss-cli for configure realms, apps and users
> > * Add support to use root-context with server subsystem
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From ssilvert at redhat.com  Tue Apr 14 08:03:39 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 14 Apr 2015 08:03:39 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
	<280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
Message-ID: <552D021B.4020004@redhat.com>

Marko and I discussed this yesterday in HipChat/MW Security.  After 
giving it a lot of thought, I came to most of the same conclusions as Stian.

I do think that having a single subsystem with three different flavors 
(client, server, and both), is a legitimate choice.  It's really easy to 
do as you just have to put conditionals on the calls to 
registerSubmodel() in KeycloakExtension:
https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84

Then you get a single subsystem that can be installed in three different 
ways.  It's up to the installer to add the modules needed for a 
particular flavor.

The feature that needs both server and client in the same subsystem is 
"seamless hello world".  The idea is that you set up the subsystem so 
that any WAR deployed to the server automatically gets Keycloak SSO.  
This requires programmatic setup of both client side and server side.  
That's easier to do if everything is in one place.

But honestly, I'm leaning toward Stian's arguments at the moment.

On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
> I don't see how splitting the sub-system will make it more difficult for Elytron or OOTB config for examples. Anything we add to those should be just as usable whether or not Keycloak is running locally or remotely.
>
> Splitting the sub-system has the advantages of isolating two very different features. Deploying and configuring Keycloak itself should be completely separated from configuring applications that use Keycloak. It makes the distribution of either cleaner. Also, for the server sub-system we only need to support latest WildFly and the distribution we build on-top of WildFly core/servlets-only. While for the adapter sub-system we'll need to support a range of EAP versions as well as potentially multiple WildFly versions.
>
> Other than some initial boiler plating I don't see any benefits of having a single sub-system, and it'll be much easier to maintain two separate sub-systems IMO as they do two completely different things and it should be possible to deploy a single one of the sub-system or both together.
>
> ----- Original Message -----
>> From: "Marko Strukelj" <mstrukel at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 14 April, 2015 12:29:30 PM
>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>
>> Yesterday a had a little conversation with Stan, and he thought the code
>> split may result in a lot of subsystem plumbing code duplication and make
>> things more difficult for Elytron integration, and make OOTB config for
>> examples slightly more complicated ...
>>
>> As far as I understood it the idea is a code split, and module dependencies
>> split, and it's there to be able to make a standalone distribution that will
>> not contain any of adapter-specific configuration / dependencies / modules.
>> The price of duplicated plumbing, and a lack of OOTB adapter configuration
>> for standalone  - server and adapter in the same WildFly - is agreed to be
>> outweighed (so I understand) by some benefits - but I'm not sure what those
>> are (cleaner codebase? The ability to be able to install adapter only into
>> existing WildFly without also installing the server parts - auth-server.war?
>> Something else?)
>>
>> Server / adapter split will have to identify code that is shared between
>> server and adapter, which will be modularized out of the subsystem.
>>
>> Stan can tell more, but as I understood his idea was that the one and single
>> subsystem could present two faces, and based on availability of some modules
>> for example present a server only, an adapter only, or a full view of
>> configuration options, and that might be simpler than splitting existing
>> subsystem into three parts - server, adapter, shared.
>>
>>
>> ----- Original Message -----
>>> We've discussed this and I hope we're all on the same page, but just to
>>> confirm here's what we've discussed:
>>>
>>> Keycloak Server
>>> ---------------
>>>
>>> * Standalone
>>>    - Built on WildFly servlet-only
>>>    - No 'standalone/deployments' directory
>>>    - Includes server only sub-system
>>>    - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
>>>    included)
>>>    - Keycloak deployed to root context (http://localhost:8080)
>>> * Demo Bundle
>>>    - Built on WildFly full
>>>    - Includes demo ready deployed and configured
>>>    - Includes server and adapter sub-systems
>>>    - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
>>>    examples, etc.)
>>>    - Keycloak deployed to auth context (http://localhost:8080/auth)
>>> * Installer
>>>    - Installs Keycloak server sub-system into existing WildFly
>>>    - Only "latests" WildFly at the time of release is supported
>>>    - Keycloak deployed to auth context (http://localhost:8080/auth)
>>>
>>>
>>> Keycloak Embedded
>>> ------------------
>>>
>>> * Consumed by external JBoss projects to embed Keycloak
>>> * Build-your-own WAR example repo
>>>
>>>
>>> Keycloak Adapters
>>> -----------------
>>>
>>> * Separate download from server
>>> * Installer for WildFly subsystem adapter
>>> * We still have to decide if adapters should have a separate release
>>> cycle/version to the server
>>> * We still have to decide if Java adapters should be moved to separate
>>> github
>>> repo
>>>
>>>
>>> Finally, a set of releated tasks
>>> --------------------------------
>>>
>>> * Split subsystem into server and adapter
>>> * Use standalone.xml instead keycloak-server.json (json will still be
>>> supported for embedded)
>>> * Add support to use dmr/jboss-cli for configuring the server (for example
>>> a
>>> single jboss-cli batch script can add data-source and set Keycloak to use
>>> it)
>>> * Add support to use dmr/jboss-cli for configure realms, apps and users
>>> * Add support to use root-context with server subsystem
>>> _______________________________________________
>>> 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  Tue Apr 14 08:13:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 08:13:20 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D021B.4020004@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
	<280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
	<552D021B.4020004@redhat.com>
Message-ID: <949181632.18268364.1429013600778.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 April, 2015 2:03:39 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> Marko and I discussed this yesterday in HipChat/MW Security.  After
> giving it a lot of thought, I came to most of the same conclusions as Stian.
> 
> I do think that having a single subsystem with three different flavors
> (client, server, and both), is a legitimate choice.  It's really easy to
> do as you just have to put conditionals on the calls to
> registerSubmodel() in KeycloakExtension:
> https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84
> 
> Then you get a single subsystem that can be installed in three different
> ways.  It's up to the installer to add the modules needed for a
> particular flavor.

Sure, but I can't see any long term benefits with that approach

> 
> The feature that needs both server and client in the same subsystem is
> "seamless hello world".  The idea is that you set up the subsystem so
> that any WAR deployed to the server automatically gets Keycloak SSO.
> This requires programmatic setup of both client side and server side.
> That's easier to do if everything is in one place.

If you're requiring programmatic setup directly to Keycloak you're doing it wrong IMO. Problem is then it won't work with a remote Keycloak server. It should be seamless if you're using a local or a remote server.

Instead the adapter sub-system should use the admin rest api to configure a local or remote Keycloak server. In the future we'll add dynamic client registration which should make this even easier.

> 
> But honestly, I'm leaning toward Stian's arguments at the moment.
> 
> On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
> > I don't see how splitting the sub-system will make it more difficult for
> > Elytron or OOTB config for examples. Anything we add to those should be
> > just as usable whether or not Keycloak is running locally or remotely.
> >
> > Splitting the sub-system has the advantages of isolating two very different
> > features. Deploying and configuring Keycloak itself should be completely
> > separated from configuring applications that use Keycloak. It makes the
> > distribution of either cleaner. Also, for the server sub-system we only
> > need to support latest WildFly and the distribution we build on-top of
> > WildFly core/servlets-only. While for the adapter sub-system we'll need to
> > support a range of EAP versions as well as potentially multiple WildFly
> > versions.
> >
> > Other than some initial boiler plating I don't see any benefits of having a
> > single sub-system, and it'll be much easier to maintain two separate
> > sub-systems IMO as they do two completely different things and it should
> > be possible to deploy a single one of the sub-system or both together.
> >
> > ----- Original Message -----
> >> From: "Marko Strukelj" <mstrukel at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Tuesday, 14 April, 2015 12:29:30 PM
> >> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>
> >> Yesterday a had a little conversation with Stan, and he thought the code
> >> split may result in a lot of subsystem plumbing code duplication and make
> >> things more difficult for Elytron integration, and make OOTB config for
> >> examples slightly more complicated ...
> >>
> >> As far as I understood it the idea is a code split, and module
> >> dependencies
> >> split, and it's there to be able to make a standalone distribution that
> >> will
> >> not contain any of adapter-specific configuration / dependencies /
> >> modules.
> >> The price of duplicated plumbing, and a lack of OOTB adapter configuration
> >> for standalone  - server and adapter in the same WildFly - is agreed to be
> >> outweighed (so I understand) by some benefits - but I'm not sure what
> >> those
> >> are (cleaner codebase? The ability to be able to install adapter only into
> >> existing WildFly without also installing the server parts -
> >> auth-server.war?
> >> Something else?)
> >>
> >> Server / adapter split will have to identify code that is shared between
> >> server and adapter, which will be modularized out of the subsystem.
> >>
> >> Stan can tell more, but as I understood his idea was that the one and
> >> single
> >> subsystem could present two faces, and based on availability of some
> >> modules
> >> for example present a server only, an adapter only, or a full view of
> >> configuration options, and that might be simpler than splitting existing
> >> subsystem into three parts - server, adapter, shared.
> >>
> >>
> >> ----- Original Message -----
> >>> We've discussed this and I hope we're all on the same page, but just to
> >>> confirm here's what we've discussed:
> >>>
> >>> Keycloak Server
> >>> ---------------
> >>>
> >>> * Standalone
> >>>    - Built on WildFly servlet-only
> >>>    - No 'standalone/deployments' directory
> >>>    - Includes server only sub-system
> >>>    - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples,
> >>>    etc,
> >>>    included)
> >>>    - Keycloak deployed to root context (http://localhost:8080)
> >>> * Demo Bundle
> >>>    - Built on WildFly full
> >>>    - Includes demo ready deployed and configured
> >>>    - Includes server and adapter sub-systems
> >>>    - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
> >>>    examples, etc.)
> >>>    - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>> * Installer
> >>>    - Installs Keycloak server sub-system into existing WildFly
> >>>    - Only "latests" WildFly at the time of release is supported
> >>>    - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>>
> >>>
> >>> Keycloak Embedded
> >>> ------------------
> >>>
> >>> * Consumed by external JBoss projects to embed Keycloak
> >>> * Build-your-own WAR example repo
> >>>
> >>>
> >>> Keycloak Adapters
> >>> -----------------
> >>>
> >>> * Separate download from server
> >>> * Installer for WildFly subsystem adapter
> >>> * We still have to decide if adapters should have a separate release
> >>> cycle/version to the server
> >>> * We still have to decide if Java adapters should be moved to separate
> >>> github
> >>> repo
> >>>
> >>>
> >>> Finally, a set of releated tasks
> >>> --------------------------------
> >>>
> >>> * Split subsystem into server and adapter
> >>> * Use standalone.xml instead keycloak-server.json (json will still be
> >>> supported for embedded)
> >>> * Add support to use dmr/jboss-cli for configuring the server (for
> >>> example
> >>> a
> >>> single jboss-cli batch script can add data-source and set Keycloak to use
> >>> it)
> >>> * Add support to use dmr/jboss-cli for configure realms, apps and users
> >>> * Add support to use root-context with server subsystem
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Tue Apr 14 08:27:03 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 14 Apr 2015 08:27:03 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <949181632.18268364.1429013600778.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
	<280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
	<552D021B.4020004@redhat.com>
	<949181632.18268364.1429013600778.JavaMail.zimbra@redhat.com>
Message-ID: <552D0797.8030609@redhat.com>

On 4/14/2015 8:13 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 14 April, 2015 2:03:39 PM
>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>
>> Marko and I discussed this yesterday in HipChat/MW Security.  After
>> giving it a lot of thought, I came to most of the same conclusions as Stian.
>>
>> I do think that having a single subsystem with three different flavors
>> (client, server, and both), is a legitimate choice.  It's really easy to
>> do as you just have to put conditionals on the calls to
>> registerSubmodel() in KeycloakExtension:
>> https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84
>>
>> Then you get a single subsystem that can be installed in three different
>> ways.  It's up to the installer to add the modules needed for a
>> particular flavor.
> Sure, but I can't see any long term benefits with that approach
>
>> The feature that needs both server and client in the same subsystem is
>> "seamless hello world".  The idea is that you set up the subsystem so
>> that any WAR deployed to the server automatically gets Keycloak SSO.
>> This requires programmatic setup of both client side and server side.
>> That's easier to do if everything is in one place.
> If you're requiring programmatic setup directly to Keycloak you're doing it wrong IMO. Problem is then it won't work with a remote Keycloak server. It should be seamless if you're using a local or a remote server.
No, I'm not thinking of doing direct setup.

I haven't coded the part that does the server side.  I only have code 
that auto-configs the client side.  My intention was to be able to say, 
"Use the local server by default".  For that you need to be able to find 
if there is a single local server.  You can then automatically determine 
its web context.  It's still doable if they are split though.  Just a 
little harder.  Or, that determination can be done manually.
>
> Instead the adapter sub-system should use the admin rest api to configure a local or remote Keycloak server. In the future we'll add dynamic client registration which should make this even easier.
Sounds great.  We'd probably want to do that before we go any further 
with seamless hello world.
>
>> But honestly, I'm leaning toward Stian's arguments at the moment.
>>
>> On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
>>> I don't see how splitting the sub-system will make it more difficult for
>>> Elytron or OOTB config for examples. Anything we add to those should be
>>> just as usable whether or not Keycloak is running locally or remotely.
>>>
>>> Splitting the sub-system has the advantages of isolating two very different
>>> features. Deploying and configuring Keycloak itself should be completely
>>> separated from configuring applications that use Keycloak. It makes the
>>> distribution of either cleaner. Also, for the server sub-system we only
>>> need to support latest WildFly and the distribution we build on-top of
>>> WildFly core/servlets-only. While for the adapter sub-system we'll need to
>>> support a range of EAP versions as well as potentially multiple WildFly
>>> versions.
>>>
>>> Other than some initial boiler plating I don't see any benefits of having a
>>> single sub-system, and it'll be much easier to maintain two separate
>>> sub-systems IMO as they do two completely different things and it should
>>> be possible to deploy a single one of the sub-system or both together.
>>>
>>> ----- Original Message -----
>>>> From: "Marko Strukelj" <mstrukel at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 14 April, 2015 12:29:30 PM
>>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>>>
>>>> Yesterday a had a little conversation with Stan, and he thought the code
>>>> split may result in a lot of subsystem plumbing code duplication and make
>>>> things more difficult for Elytron integration, and make OOTB config for
>>>> examples slightly more complicated ...
>>>>
>>>> As far as I understood it the idea is a code split, and module
>>>> dependencies
>>>> split, and it's there to be able to make a standalone distribution that
>>>> will
>>>> not contain any of adapter-specific configuration / dependencies /
>>>> modules.
>>>> The price of duplicated plumbing, and a lack of OOTB adapter configuration
>>>> for standalone  - server and adapter in the same WildFly - is agreed to be
>>>> outweighed (so I understand) by some benefits - but I'm not sure what
>>>> those
>>>> are (cleaner codebase? The ability to be able to install adapter only into
>>>> existing WildFly without also installing the server parts -
>>>> auth-server.war?
>>>> Something else?)
>>>>
>>>> Server / adapter split will have to identify code that is shared between
>>>> server and adapter, which will be modularized out of the subsystem.
>>>>
>>>> Stan can tell more, but as I understood his idea was that the one and
>>>> single
>>>> subsystem could present two faces, and based on availability of some
>>>> modules
>>>> for example present a server only, an adapter only, or a full view of
>>>> configuration options, and that might be simpler than splitting existing
>>>> subsystem into three parts - server, adapter, shared.
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> We've discussed this and I hope we're all on the same page, but just to
>>>>> confirm here's what we've discussed:
>>>>>
>>>>> Keycloak Server
>>>>> ---------------
>>>>>
>>>>> * Standalone
>>>>>     - Built on WildFly servlet-only
>>>>>     - No 'standalone/deployments' directory
>>>>>     - Includes server only sub-system
>>>>>     - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples,
>>>>>     etc,
>>>>>     included)
>>>>>     - Keycloak deployed to root context (http://localhost:8080)
>>>>> * Demo Bundle
>>>>>     - Built on WildFly full
>>>>>     - Includes demo ready deployed and configured
>>>>>     - Includes server and adapter sub-systems
>>>>>     - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
>>>>>     examples, etc.)
>>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
>>>>> * Installer
>>>>>     - Installs Keycloak server sub-system into existing WildFly
>>>>>     - Only "latests" WildFly at the time of release is supported
>>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
>>>>>
>>>>>
>>>>> Keycloak Embedded
>>>>> ------------------
>>>>>
>>>>> * Consumed by external JBoss projects to embed Keycloak
>>>>> * Build-your-own WAR example repo
>>>>>
>>>>>
>>>>> Keycloak Adapters
>>>>> -----------------
>>>>>
>>>>> * Separate download from server
>>>>> * Installer for WildFly subsystem adapter
>>>>> * We still have to decide if adapters should have a separate release
>>>>> cycle/version to the server
>>>>> * We still have to decide if Java adapters should be moved to separate
>>>>> github
>>>>> repo
>>>>>
>>>>>
>>>>> Finally, a set of releated tasks
>>>>> --------------------------------
>>>>>
>>>>> * Split subsystem into server and adapter
>>>>> * Use standalone.xml instead keycloak-server.json (json will still be
>>>>> supported for embedded)
>>>>> * Add support to use dmr/jboss-cli for configuring the server (for
>>>>> example
>>>>> a
>>>>> single jboss-cli batch script can add data-source and set Keycloak to use
>>>>> it)
>>>>> * Add support to use dmr/jboss-cli for configure realms, apps and users
>>>>> * Add support to use root-context with server subsystem
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Apr 14 08:32:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 08:32:58 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D0797.8030609@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>
	<280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
	<552D021B.4020004@redhat.com>
	<949181632.18268364.1429013600778.JavaMail.zimbra@redhat.com>
	<552D0797.8030609@redhat.com>
Message-ID: <2144912364.18275549.1429014778036.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 April, 2015 2:27:03 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> On 4/14/2015 8:13 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 14 April, 2015 2:03:39 PM
> >> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>
> >> Marko and I discussed this yesterday in HipChat/MW Security.  After
> >> giving it a lot of thought, I came to most of the same conclusions as
> >> Stian.
> >>
> >> I do think that having a single subsystem with three different flavors
> >> (client, server, and both), is a legitimate choice.  It's really easy to
> >> do as you just have to put conditionals on the calls to
> >> registerSubmodel() in KeycloakExtension:
> >> https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84
> >>
> >> Then you get a single subsystem that can be installed in three different
> >> ways.  It's up to the installer to add the modules needed for a
> >> particular flavor.
> > Sure, but I can't see any long term benefits with that approach
> >
> >> The feature that needs both server and client in the same subsystem is
> >> "seamless hello world".  The idea is that you set up the subsystem so
> >> that any WAR deployed to the server automatically gets Keycloak SSO.
> >> This requires programmatic setup of both client side and server side.
> >> That's easier to do if everything is in one place.
> > If you're requiring programmatic setup directly to Keycloak you're doing it
> > wrong IMO. Problem is then it won't work with a remote Keycloak server. It
> > should be seamless if you're using a local or a remote server.
> No, I'm not thinking of doing direct setup.
> 
> I haven't coded the part that does the server side.  I only have code
> that auto-configs the client side.  My intention was to be able to say,
> "Use the local server by default".  For that you need to be able to find
> if there is a single local server.  You can then automatically determine
> its web context.  It's still doable if they are split though.  Just a
> little harder.  Or, that determination can be done manually.
> >
> > Instead the adapter sub-system should use the admin rest api to configure a
> > local or remote Keycloak server. In the future we'll add dynamic client
> > registration which should make this even easier.
> Sounds great.  We'd probably want to do that before we go any further
> with seamless hello world.

Or, use the admin api (there's a java client to make it easier) so we can experiment with it and find out exactly what's needed?

> >
> >> But honestly, I'm leaning toward Stian's arguments at the moment.
> >>
> >> On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
> >>> I don't see how splitting the sub-system will make it more difficult for
> >>> Elytron or OOTB config for examples. Anything we add to those should be
> >>> just as usable whether or not Keycloak is running locally or remotely.
> >>>
> >>> Splitting the sub-system has the advantages of isolating two very
> >>> different
> >>> features. Deploying and configuring Keycloak itself should be completely
> >>> separated from configuring applications that use Keycloak. It makes the
> >>> distribution of either cleaner. Also, for the server sub-system we only
> >>> need to support latest WildFly and the distribution we build on-top of
> >>> WildFly core/servlets-only. While for the adapter sub-system we'll need
> >>> to
> >>> support a range of EAP versions as well as potentially multiple WildFly
> >>> versions.
> >>>
> >>> Other than some initial boiler plating I don't see any benefits of having
> >>> a
> >>> single sub-system, and it'll be much easier to maintain two separate
> >>> sub-systems IMO as they do two completely different things and it should
> >>> be possible to deploy a single one of the sub-system or both together.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Marko Strukelj" <mstrukel at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, 14 April, 2015 12:29:30 PM
> >>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>>>
> >>>> Yesterday a had a little conversation with Stan, and he thought the code
> >>>> split may result in a lot of subsystem plumbing code duplication and
> >>>> make
> >>>> things more difficult for Elytron integration, and make OOTB config for
> >>>> examples slightly more complicated ...
> >>>>
> >>>> As far as I understood it the idea is a code split, and module
> >>>> dependencies
> >>>> split, and it's there to be able to make a standalone distribution that
> >>>> will
> >>>> not contain any of adapter-specific configuration / dependencies /
> >>>> modules.
> >>>> The price of duplicated plumbing, and a lack of OOTB adapter
> >>>> configuration
> >>>> for standalone  - server and adapter in the same WildFly - is agreed to
> >>>> be
> >>>> outweighed (so I understand) by some benefits - but I'm not sure what
> >>>> those
> >>>> are (cleaner codebase? The ability to be able to install adapter only
> >>>> into
> >>>> existing WildFly without also installing the server parts -
> >>>> auth-server.war?
> >>>> Something else?)
> >>>>
> >>>> Server / adapter split will have to identify code that is shared between
> >>>> server and adapter, which will be modularized out of the subsystem.
> >>>>
> >>>> Stan can tell more, but as I understood his idea was that the one and
> >>>> single
> >>>> subsystem could present two faces, and based on availability of some
> >>>> modules
> >>>> for example present a server only, an adapter only, or a full view of
> >>>> configuration options, and that might be simpler than splitting existing
> >>>> subsystem into three parts - server, adapter, shared.
> >>>>
> >>>>
> >>>> ----- Original Message -----
> >>>>> We've discussed this and I hope we're all on the same page, but just to
> >>>>> confirm here's what we've discussed:
> >>>>>
> >>>>> Keycloak Server
> >>>>> ---------------
> >>>>>
> >>>>> * Standalone
> >>>>>     - Built on WildFly servlet-only
> >>>>>     - No 'standalone/deployments' directory
> >>>>>     - Includes server only sub-system
> >>>>>     - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples,
> >>>>>     etc,
> >>>>>     included)
> >>>>>     - Keycloak deployed to root context (http://localhost:8080)
> >>>>> * Demo Bundle
> >>>>>     - Built on WildFly full
> >>>>>     - Includes demo ready deployed and configured
> >>>>>     - Includes server and adapter sub-systems
> >>>>>     - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes
> >>>>>     docs,
> >>>>>     examples, etc.)
> >>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>>>> * Installer
> >>>>>     - Installs Keycloak server sub-system into existing WildFly
> >>>>>     - Only "latests" WildFly at the time of release is supported
> >>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
> >>>>>
> >>>>>
> >>>>> Keycloak Embedded
> >>>>> ------------------
> >>>>>
> >>>>> * Consumed by external JBoss projects to embed Keycloak
> >>>>> * Build-your-own WAR example repo
> >>>>>
> >>>>>
> >>>>> Keycloak Adapters
> >>>>> -----------------
> >>>>>
> >>>>> * Separate download from server
> >>>>> * Installer for WildFly subsystem adapter
> >>>>> * We still have to decide if adapters should have a separate release
> >>>>> cycle/version to the server
> >>>>> * We still have to decide if Java adapters should be moved to separate
> >>>>> github
> >>>>> repo
> >>>>>
> >>>>>
> >>>>> Finally, a set of releated tasks
> >>>>> --------------------------------
> >>>>>
> >>>>> * Split subsystem into server and adapter
> >>>>> * Use standalone.xml instead keycloak-server.json (json will still be
> >>>>> supported for embedded)
> >>>>> * Add support to use dmr/jboss-cli for configuring the server (for
> >>>>> example
> >>>>> a
> >>>>> single jboss-cli batch script can add data-source and set Keycloak to
> >>>>> use
> >>>>> it)
> >>>>> * Add support to use dmr/jboss-cli for configure realms, apps and users
> >>>>> * Add support to use root-context with server subsystem
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From stian at redhat.com  Tue Apr 14 08:34:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 08:34:54 -0400 (EDT)
Subject: [keycloak-dev] Auditing of admin events
In-Reply-To: <375044129.18275667.1429014807709.JavaMail.zimbra@redhat.com>
Message-ID: <888205364.18276349.1429014894254.JavaMail.zimbra@redhat.com>

Giriraj has volunteered to implement auditing of admin events, but we need to figure out how it should work first.

I've added a proposal to https://issues.jboss.org/browse/KEYCLOAK-392, including mock interfaces and admin console screens.

Please have a look asap and comment on it.

From bburke at redhat.com  Tue Apr 14 08:43:52 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Apr 2015 08:43:52 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
Message-ID: <552D0B88.9090004@redhat.com>

* Keycloak Standalone may end up being almost identical to Wildfly full. 
  Think about it, we currently need: JPA, JCA (for connection pooling), 
JTA (because JCA requires it), Servlet, JAX-RS, and 
Infinispan/Clustering.  EJB and CDI we might want to include in the 
future so that users can write real provider components and take 
advantage of all that stuff.  SOAP me may have to add when we do STS. 
That only leaves out JMS and JSF.
* Installer has to work on EAP 6.x too.
* You can't test keycloak server without the adapters and vice-versa. 
Not sure how viable it would be to have them in a separate repo.

On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
> We've discussed this and I hope we're all on the same page, but just to confirm here's what we've discussed:
>
> Keycloak Server
> ---------------
>
> * Standalone
>    - Built on WildFly servlet-only
>    - No 'standalone/deployments' directory
>    - Includes server only sub-system
>    - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc, included)
>    - Keycloak deployed to root context (http://localhost:8080)
> * Demo Bundle
>    - Built on WildFly full
>    - Includes demo ready deployed and configured
>    - Includes server and adapter sub-systems
>    - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs, examples, etc.)
>    - Keycloak deployed to auth context (http://localhost:8080/auth)
> * Installer
>    - Installs Keycloak server sub-system into existing WildFly
>    - Only "latests" WildFly at the time of release is supported
>    - Keycloak deployed to auth context (http://localhost:8080/auth)
>
>
> Keycloak Embedded
> ------------------
>
> * Consumed by external JBoss projects to embed Keycloak
> * Build-your-own WAR example repo
>
>
> Keycloak Adapters
> -----------------
>
> * Separate download from server
> * Installer for WildFly subsystem adapter
> * We still have to decide if adapters should have a separate release cycle/version to the server
> * We still have to decide if Java adapters should be moved to separate github repo
>
>
> Finally, a set of releated tasks
> --------------------------------
>
> * Split subsystem into server and adapter
> * Use standalone.xml instead keycloak-server.json (json will still be supported for embedded)
> * Add support to use dmr/jboss-cli for configuring the server (for example a single jboss-cli batch script can add data-source and set Keycloak to use it)
> * Add support to use dmr/jboss-cli for configure realms, apps and users
> * Add support to use root-context with server subsystem
> _______________________________________________
> 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 Apr 14 08:48:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Apr 2015 08:48:08 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D021B.4020004@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>	<714985102.17987103.1429007370762.JavaMail.zimbra@redhat.com>	<280552000.18240254.1429011157022.JavaMail.zimbra@redhat.com>
	<552D021B.4020004@redhat.com>
Message-ID: <552D0C88.6010803@redhat.com>

Client adapter and server need to be split.  Wildfly will eventually 
come distributed with our client adapters.  We can't be shipping the 
whole server for every single app server that wants to be secured by 
Keycloak.

On 4/14/2015 8:03 AM, Stan Silvert wrote:
> Marko and I discussed this yesterday in HipChat/MW Security.  After
> giving it a lot of thought, I came to most of the same conclusions as Stian.
>
> I do think that having a single subsystem with three different flavors
> (client, server, and both), is a legitimate choice.  It's really easy to
> do as you just have to put conditionals on the calls to
> registerSubmodel() in KeycloakExtension:
> https://github.com/keycloak/keycloak/blob/master/integration/keycloak-subsystem/src/main/java/org/keycloak/subsystem/extension/KeycloakExtension.java#L81-L84
>
> Then you get a single subsystem that can be installed in three different
> ways.  It's up to the installer to add the modules needed for a
> particular flavor.
>
> The feature that needs both server and client in the same subsystem is
> "seamless hello world".  The idea is that you set up the subsystem so
> that any WAR deployed to the server automatically gets Keycloak SSO.
> This requires programmatic setup of both client side and server side.
> That's easier to do if everything is in one place.
>
> But honestly, I'm leaning toward Stian's arguments at the moment.
>
> On 4/14/2015 7:32 AM, Stian Thorgersen wrote:
>> I don't see how splitting the sub-system will make it more difficult for Elytron or OOTB config for examples. Anything we add to those should be just as usable whether or not Keycloak is running locally or remotely.
>>
>> Splitting the sub-system has the advantages of isolating two very different features. Deploying and configuring Keycloak itself should be completely separated from configuring applications that use Keycloak. It makes the distribution of either cleaner. Also, for the server sub-system we only need to support latest WildFly and the distribution we build on-top of WildFly core/servlets-only. While for the adapter sub-system we'll need to support a range of EAP versions as well as potentially multiple WildFly versions.
>>
>> Other than some initial boiler plating I don't see any benefits of having a single sub-system, and it'll be much easier to maintain two separate sub-systems IMO as they do two completely different things and it should be possible to deploy a single one of the sub-system or both together.
>>
>> ----- Original Message -----
>>> From: "Marko Strukelj" <mstrukel at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, 14 April, 2015 12:29:30 PM
>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>>
>>> Yesterday a had a little conversation with Stan, and he thought the code
>>> split may result in a lot of subsystem plumbing code duplication and make
>>> things more difficult for Elytron integration, and make OOTB config for
>>> examples slightly more complicated ...
>>>
>>> As far as I understood it the idea is a code split, and module dependencies
>>> split, and it's there to be able to make a standalone distribution that will
>>> not contain any of adapter-specific configuration / dependencies / modules.
>>> The price of duplicated plumbing, and a lack of OOTB adapter configuration
>>> for standalone  - server and adapter in the same WildFly - is agreed to be
>>> outweighed (so I understand) by some benefits - but I'm not sure what those
>>> are (cleaner codebase? The ability to be able to install adapter only into
>>> existing WildFly without also installing the server parts - auth-server.war?
>>> Something else?)
>>>
>>> Server / adapter split will have to identify code that is shared between
>>> server and adapter, which will be modularized out of the subsystem.
>>>
>>> Stan can tell more, but as I understood his idea was that the one and single
>>> subsystem could present two faces, and based on availability of some modules
>>> for example present a server only, an adapter only, or a full view of
>>> configuration options, and that might be simpler than splitting existing
>>> subsystem into three parts - server, adapter, shared.
>>>
>>>
>>> ----- Original Message -----
>>>> We've discussed this and I hope we're all on the same page, but just to
>>>> confirm here's what we've discussed:
>>>>
>>>> Keycloak Server
>>>> ---------------
>>>>
>>>> * Standalone
>>>>     - Built on WildFly servlet-only
>>>>     - No 'standalone/deployments' directory
>>>>     - Includes server only sub-system
>>>>     - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
>>>>     included)
>>>>     - Keycloak deployed to root context (http://localhost:8080)
>>>> * Demo Bundle
>>>>     - Built on WildFly full
>>>>     - Includes demo ready deployed and configured
>>>>     - Includes server and adapter sub-systems
>>>>     - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
>>>>     examples, etc.)
>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
>>>> * Installer
>>>>     - Installs Keycloak server sub-system into existing WildFly
>>>>     - Only "latests" WildFly at the time of release is supported
>>>>     - Keycloak deployed to auth context (http://localhost:8080/auth)
>>>>
>>>>
>>>> Keycloak Embedded
>>>> ------------------
>>>>
>>>> * Consumed by external JBoss projects to embed Keycloak
>>>> * Build-your-own WAR example repo
>>>>
>>>>
>>>> Keycloak Adapters
>>>> -----------------
>>>>
>>>> * Separate download from server
>>>> * Installer for WildFly subsystem adapter
>>>> * We still have to decide if adapters should have a separate release
>>>> cycle/version to the server
>>>> * We still have to decide if Java adapters should be moved to separate
>>>> github
>>>> repo
>>>>
>>>>
>>>> Finally, a set of releated tasks
>>>> --------------------------------
>>>>
>>>> * Split subsystem into server and adapter
>>>> * Use standalone.xml instead keycloak-server.json (json will still be
>>>> supported for embedded)
>>>> * Add support to use dmr/jboss-cli for configuring the server (for example
>>>> a
>>>> single jboss-cli batch script can add data-source and set Keycloak to use
>>>> it)
>>>> * Add support to use dmr/jboss-cli for configure realms, apps and users
>>>> * Add support to use root-context with server subsystem
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Apr 14 09:10:50 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 14 Apr 2015 09:10:50 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D0B88.9090004@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
Message-ID: <1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 14 April, 2015 2:43:52 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> * Keycloak Standalone may end up being almost identical to Wildfly full.
>   Think about it, we currently need: JPA, JCA (for connection pooling),
> JTA (because JCA requires it), Servlet, JAX-RS, and
> Infinispan/Clustering.  EJB and CDI we might want to include in the
> future so that users can write real provider components and take
> advantage of all that stuff.  SOAP me may have to add when we do STS.
> That only leaves out JMS and JSF.

You're probably right, but AFAIK it's a requirement for product that we build on WildFly core - Bolek?!

> * Installer has to work on EAP 6.x too.

Installer for adapter? I can't see why we need installer for server on EAP.

> * You can't test keycloak server without the adapters and vice-versa.
> Not sure how viable it would be to have them in a separate repo.

You can, but that's still a good reason to keep in same repo.

I guess it would be simplest to keep adapters in same repo. In the release notes we can include which adapters have to be updated (including if they have to be updated at the same time as the server or not).

> 
> On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
> > We've discussed this and I hope we're all on the same page, but just to
> > confirm here's what we've discussed:
> >
> > Keycloak Server
> > ---------------
> >
> > * Standalone
> >    - Built on WildFly servlet-only
> >    - No 'standalone/deployments' directory
> >    - Includes server only sub-system
> >    - Download name keycloak-<version>.[zip|tar.gz] (no docs, examples, etc,
> >    included)
> >    - Keycloak deployed to root context (http://localhost:8080)
> > * Demo Bundle
> >    - Built on WildFly full
> >    - Includes demo ready deployed and configured
> >    - Includes server and adapter sub-systems
> >    - Download name keycloak-bundle-<version>.[zip|tar.gz] (includes docs,
> >    examples, etc.)
> >    - Keycloak deployed to auth context (http://localhost:8080/auth)
> > * Installer
> >    - Installs Keycloak server sub-system into existing WildFly
> >    - Only "latests" WildFly at the time of release is supported
> >    - Keycloak deployed to auth context (http://localhost:8080/auth)
> >
> >
> > Keycloak Embedded
> > ------------------
> >
> > * Consumed by external JBoss projects to embed Keycloak
> > * Build-your-own WAR example repo
> >
> >
> > Keycloak Adapters
> > -----------------
> >
> > * Separate download from server
> > * Installer for WildFly subsystem adapter
> > * We still have to decide if adapters should have a separate release
> > cycle/version to the server
> > * We still have to decide if Java adapters should be moved to separate
> > github repo
> >
> >
> > Finally, a set of releated tasks
> > --------------------------------
> >
> > * Split subsystem into server and adapter
> > * Use standalone.xml instead keycloak-server.json (json will still be
> > supported for embedded)
> > * Add support to use dmr/jboss-cli for configuring the server (for example
> > a single jboss-cli batch script can add data-source and set Keycloak to
> > use it)
> > * Add support to use dmr/jboss-cli for configure realms, apps and users
> > * Add support to use root-context with server subsystem
> > _______________________________________________
> > 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 Apr 14 09:28:53 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 14 Apr 2015 09:28:53 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>
Message-ID: <552D1615.4060400@redhat.com>



On 4/14/2015 9:10 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 14 April, 2015 2:43:52 PM
>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>
>> * Keycloak Standalone may end up being almost identical to Wildfly full.
>>    Think about it, we currently need: JPA, JCA (for connection pooling),
>> JTA (because JCA requires it), Servlet, JAX-RS, and
>> Infinispan/Clustering.  EJB and CDI we might want to include in the
>> future so that users can write real provider components and take
>> advantage of all that stuff.  SOAP me may have to add when we do STS.
>> That only leaves out JMS and JSF.
>
> You're probably right, but AFAIK it's a requirement for product that we build on WildFly core - Bolek?!
>

Should be decided on the level of work needed to build off of Wildfly 
core.  If it is a pain in the ass, then it might not be worth putting 
the time into it.  I'm just not sure how much smaller we could make our 
distro.  If we're going from 150M down to 50M it is worth it.  If its 
150M down to 130M its not.

>> * Installer has to work on EAP 6.x too.
>
> Installer for adapter? I can't see why we need installer for server on EAP.
>

This is for community.  There are many users that run Keycloak community 
on EAP.


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

From ssilvert at redhat.com  Tue Apr 14 20:22:30 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 14 Apr 2015 20:22:30 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
Message-ID: <552DAF46.1050903@redhat.com>

On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
> * Add support to use root-context with server subsystem
>
I tried it out and this already works.  To run the Keycloak server as 
the root context, you just need to change an Undertow setting:
<host name="default-host" alias="localhost" 
default-web-module="main-auth-server.war">

default-web-module should be whatever you named your server in the 
Keycloak subsystem with ".war" appended.  By default, this is 
"main-auth-server.war".

<subsystem xmlns="urn:jboss:domain:keycloak:1.0">
             <auth-server name="main-auth-server">
                 <enabled>true</enabled>
                 <web-context>auth</web-context>
             </auth-server>
         </subsystem>
Whatever you have set for web-context will be ignored.  You could just 
set it to /.

Also Note: If you change the default-web-module after you have already 
booted your server then you will need to wipe out your old keycloak 
database, which will then contain an old invalid redirect url.

Stan

From bdawidow at redhat.com  Wed Apr 15 03:11:36 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Wed, 15 Apr 2015 09:11:36 +0200
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D1615.4060400@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>
	<552D1615.4060400@redhat.com>
Message-ID: <8E80019E-78EE-4A6B-93EF-C4E912D323B9@redhat.com>


> On 14 Apr 2015, at 15:28, Bill Burke <bburke at redhat.com> wrote:
> 
> 
> 
> On 4/14/2015 9:10 AM, Stian Thorgersen wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 14 April, 2015 2:43:52 PM
>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>> 
>>> * Keycloak Standalone may end up being almost identical to Wildfly full.
>>>   Think about it, we currently need: JPA, JCA (for connection pooling),
>>> JTA (because JCA requires it), Servlet, JAX-RS, and
>>> Infinispan/Clustering.  EJB and CDI we might want to include in the
>>> future so that users can write real provider components and take
>>> advantage of all that stuff.  SOAP me may have to add when we do STS.
>>> That only leaves out JMS and JSF.
>> 
>> You're probably right, but AFAIK it's a requirement for product that we build on WildFly core - Bolek?!
>> 
> 
> Should be decided on the level of work needed to build off of Wildfly 
> core.  If it is a pain in the ass, then it might not be worth putting 
> the time into it.  I'm just not sure how much smaller we could make our 
> distro.  If we're going from 150M down to 50M it is worth it.  If its 
> 150M down to 130M its not.

In general we should go with WF Core. Although I agree - lets try bottom up first (WF Core + needed stuff) and see what the difference really is to make a decision. 

>>> * Installer has to work on EAP 6.x too.
>> 
>> Installer for adapter? I can't see why we need installer for server on EAP.
>> 
> 
> This is for community.  There are many users that run Keycloak community 
> on EAP.
> 
> 
> -- 
> 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 pslegr at redhat.com  Wed Apr 15 07:02:42 2015
From: pslegr at redhat.com (pslegr)
Date: Wed, 15 Apr 2015 13:02:42 +0200
Subject: [keycloak-dev] Keykload and Swagger.io integration
In-Reply-To: <1178503542.15056207.1428579045967.JavaMail.zimbra@redhat.com>
References: <55251848.7070903@redhat.com>
	<1178503542.15056207.1428579045967.JavaMail.zimbra@redhat.com>
Message-ID: <552E4552.7020103@redhat.com>



On 9.4.2015 13:30, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "pslegr" <pslegr at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Wednesday, 8 April, 2015 2:00:08 PM
>> Subject: [keycloak-dev] Keykload and Swagger.io integration
>>
>> Hi guys,
>>
>> I've found an old thread wrt ${subject} here
>> http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001842.html
>> and I wonder, if there was some further research on it.
>>
>> I need to integrate Swagger.io and Keycloak
>>
>> Anyone tried out already, or having some example to show ?
> Nope, but if you come up with something we want it :)
Ok, I will try to design it myself and get back to you, so you can
reuse it if you want :)

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


From stian at redhat.com  Wed Apr 15 08:02:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Apr 2015 08:02:43 -0400 (EDT)
Subject: [keycloak-dev] Added KeycloakContext (and updates to
 JBossLoggingEventListenerProvider)
In-Reply-To: <1598600250.67714.1429098275822.JavaMail.zimbra@redhat.com>
Message-ID: <1882074123.82545.1429099363619.JavaMail.zimbra@redhat.com>

I've added KeycloakContext to KeycloakSession. This should help us to not have to pass around things like UriInfo, RealmModel, etc..

I've not refactored much of existing code, we can do that as we go along. In the future get things from KeycloakContext instead of passing it or injecting it. One thing I did was to get rid of the "Flows" stuff which was pretty much gone any ways.

This also provides access to these values for all providers (for example access to cookies within events requested by jboss.org guys, KEYCLOAK-1042).

To test this out I've updated JBossLoggingEventListenerProvider. JBossLoggingEventListenerProvider is now added by default to new realms making it easier to enable log for events. By default success events are logged with debug and error events are logged with warn, this can be changed in keycloak-server.json. To view events enable debug for "org.keycloak.events". If you set "org.keycloak.events" to trace it will also add requestUri and cookies to the log output.

Check out https://github.com/keycloak/keycloak/blob/master/events/jboss-logging/src/main/java/org/keycloak/events/log/JBossLoggingEventListenerProvider.java#L70 for some code ;)

From stian at redhat.com  Wed Apr 15 08:08:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Apr 2015 08:08:07 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <8E80019E-78EE-4A6B-93EF-C4E912D323B9@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>
	<552D1615.4060400@redhat.com>
	<8E80019E-78EE-4A6B-93EF-C4E912D323B9@redhat.com>
Message-ID: <1064653435.86365.1429099687320.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Boleslaw Dawidowicz" <bdawidow at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 15, 2015 9:11:36 AM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> 
> > On 14 Apr 2015, at 15:28, Bill Burke <bburke at redhat.com> wrote:
> > 
> > 
> > 
> > On 4/14/2015 9:10 AM, Stian Thorgersen wrote:
> >> 
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 14 April, 2015 2:43:52 PM
> >>> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>> 
> >>> * Keycloak Standalone may end up being almost identical to Wildfly full.
> >>>   Think about it, we currently need: JPA, JCA (for connection pooling),
> >>> JTA (because JCA requires it), Servlet, JAX-RS, and
> >>> Infinispan/Clustering.  EJB and CDI we might want to include in the
> >>> future so that users can write real provider components and take
> >>> advantage of all that stuff.  SOAP me may have to add when we do STS.
> >>> That only leaves out JMS and JSF.
> >> 
> >> You're probably right, but AFAIK it's a requirement for product that we
> >> build on WildFly core - Bolek?!
> >> 
> > 
> > Should be decided on the level of work needed to build off of Wildfly
> > core.  If it is a pain in the ass, then it might not be worth putting
> > the time into it.  I'm just not sure how much smaller we could make our
> > distro.  If we're going from 150M down to 50M it is worth it.  If its
> > 150M down to 130M its not.

WildFly servlets-only is 27M, so there's a way to go until we reach WildFly full which is 125M.

Not sure what's in the 100M, but one thing that I think is pretty big is the WF console (due to the GWT crap). Do we need that?

> 
> In general we should go with WF Core. Although I agree - lets try bottom up
> first (WF Core + needed stuff) and see what the difference really is to make
> a decision.
> 
> >>> * Installer has to work on EAP 6.x too.
> >> 
> >> Installer for adapter? I can't see why we need installer for server on
> >> EAP.
> >> 
> > 
> > This is for community.  There are many users that run Keycloak community
> > on EAP.
> > 
> > 
> > --
> > 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  Wed Apr 15 08:09:59 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Apr 2015 08:09:59 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <1064653435.86365.1429099687320.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1938040866.18295239.1429017050832.JavaMail.zimbra@redhat.com>
	<552D1615.4060400@redhat.com>
	<8E80019E-78EE-4A6B-93EF-C4E912D323B9@redhat.com>
	<1064653435.86365.1429099687320.JavaMail.zimbra@redhat.com>
Message-ID: <451416708.88076.1429099799530.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Boleslaw Dawidowicz" <bdawidow at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 15, 2015 2:08:07 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> 
> 
> ----- Original Message -----
> > From: "Boleslaw Dawidowicz" <bdawidow at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Wednesday, April 15, 2015 9:11:36 AM
> > Subject: Re: [keycloak-dev] Keycloak distribution changes
> > 
> > 
> > > On 14 Apr 2015, at 15:28, Bill Burke <bburke at redhat.com> wrote:
> > > 
> > > 
> > > 
> > > On 4/14/2015 9:10 AM, Stian Thorgersen wrote:
> > >> 
> > >> 
> > >> ----- Original Message -----
> > >>> From: "Bill Burke" <bburke at redhat.com>
> > >>> To: keycloak-dev at lists.jboss.org
> > >>> Sent: Tuesday, 14 April, 2015 2:43:52 PM
> > >>> Subject: Re: [keycloak-dev] Keycloak distribution changes
> > >>> 
> > >>> * Keycloak Standalone may end up being almost identical to Wildfly
> > >>> full.
> > >>>   Think about it, we currently need: JPA, JCA (for connection pooling),
> > >>> JTA (because JCA requires it), Servlet, JAX-RS, and
> > >>> Infinispan/Clustering.  EJB and CDI we might want to include in the
> > >>> future so that users can write real provider components and take
> > >>> advantage of all that stuff.  SOAP me may have to add when we do STS.
> > >>> That only leaves out JMS and JSF.
> > >> 
> > >> You're probably right, but AFAIK it's a requirement for product that we
> > >> build on WildFly core - Bolek?!
> > >> 
> > > 
> > > Should be decided on the level of work needed to build off of Wildfly
> > > core.  If it is a pain in the ass, then it might not be worth putting
> > > the time into it.  I'm just not sure how much smaller we could make our
> > > distro.  If we're going from 150M down to 50M it is worth it.  If its
> > > 150M down to 130M its not.
> 
> WildFly servlets-only is 27M, so there's a way to go until we reach WildFly
> full which is 125M.
> 
> Not sure what's in the 100M, but one thing that I think is pretty big is the
> WF console (due to the GWT crap). Do we need that?
> 
> > 
> > In general we should go with WF Core. Although I agree - lets try bottom up
> > first (WF Core + needed stuff) and see what the difference really is to
> > make
> > a decision.
> > 
> > >>> * Installer has to work on EAP 6.x too.
> > >> 
> > >> Installer for adapter? I can't see why we need installer for server on
> > >> EAP.
> > >> 
> > > 
> > > This is for community.  There are many users that run Keycloak community
> > > on EAP.

Wouldn't it be KC version A community deploys to WildFly version B, and IAM version C deploys to EAP version D?

> > > 
> > > 
> > > --
> > > 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  Wed Apr 15 08:19:51 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 15 Apr 2015 08:19:51 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552DAF46.1050903@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552DAF46.1050903@redhat.com>
Message-ID: <552E5767.6030901@redhat.com>

On 4/14/2015 8:22 PM, Stan Silvert wrote:
> On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
>> * Add support to use root-context with server subsystem
>>
BTW, I think this should be documented somewhere.  Should it be in the 
doc, wiki, or in a blog?
> I tried it out and this already works.  To run the Keycloak server as
> the root context, you just need to change an Undertow setting:
> <host name="default-host" alias="localhost"
> default-web-module="main-auth-server.war">
>
> default-web-module should be whatever you named your server in the
> Keycloak subsystem with ".war" appended.  By default, this is
> "main-auth-server.war".
>
> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>               <auth-server name="main-auth-server">
>                   <enabled>true</enabled>
>                   <web-context>auth</web-context>
>               </auth-server>
>           </subsystem>
> Whatever you have set for web-context will be ignored.  You could just
> set it to /.
>
> Also Note: If you change the default-web-module after you have already
> booted your server then you will need to wipe out your old keycloak
> database, which will then contain an old invalid redirect url.
>
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Apr 15 08:31:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 15 Apr 2015 08:31:19 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552E5767.6030901@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552DAF46.1050903@redhat.com> <552E5767.6030901@redhat.com>
Message-ID: <668400031.97139.1429101079637.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 15, 2015 2:19:51 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> On 4/14/2015 8:22 PM, Stan Silvert wrote:
> > On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
> >> * Add support to use root-context with server subsystem
> >>
> BTW, I think this should be documented somewhere.  Should it be in the
> doc, wiki, or in a blog?

Docs ;)

We could add to http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/providers.html#d4e411 and include list of what providers and their config options.

> > I tried it out and this already works.  To run the Keycloak server as
> > the root context, you just need to change an Undertow setting:
> > <host name="default-host" alias="localhost"
> > default-web-module="main-auth-server.war">
> >
> > default-web-module should be whatever you named your server in the
> > Keycloak subsystem with ".war" appended.  By default, this is
> > "main-auth-server.war".
> >
> > <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
> >               <auth-server name="main-auth-server">
> >                   <enabled>true</enabled>
> >                   <web-context>auth</web-context>
> >               </auth-server>
> >           </subsystem>
> > Whatever you have set for web-context will be ignored.  You could just
> > set it to /.
> >
> > Also Note: If you change the default-web-module after you have already
> > booted your server then you will need to wipe out your old keycloak
> > database, which will then contain an old invalid redirect url.
> >
> > 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  Wed Apr 15 08:37:18 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 15 Apr 2015 08:37:18 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <668400031.97139.1429101079637.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552DAF46.1050903@redhat.com> <552E5767.6030901@redhat.com>
	<668400031.97139.1429101079637.JavaMail.zimbra@redhat.com>
Message-ID: <552E5B7E.3080005@redhat.com>

On 4/15/2015 8:31 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, April 15, 2015 2:19:51 PM
>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>
>> On 4/14/2015 8:22 PM, Stan Silvert wrote:
>>> On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
>>>> * Add support to use root-context with server subsystem
>>>>
>> BTW, I think this should be documented somewhere.  Should it be in the
>> doc, wiki, or in a blog?
> Docs ;)
>
> We could add to http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/providers.html#d4e411 and include list of what providers and their config options.
Huh?  This isn't about providers.  It's a setting in the Undertow subsystem.
>
>>> I tried it out and this already works.  To run the Keycloak server as
>>> the root context, you just need to change an Undertow setting:
>>> <host name="default-host" alias="localhost"
>>> default-web-module="main-auth-server.war">
>>>
>>> default-web-module should be whatever you named your server in the
>>> Keycloak subsystem with ".war" appended.  By default, this is
>>> "main-auth-server.war".
>>>
>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>>>                <auth-server name="main-auth-server">
>>>                    <enabled>true</enabled>
>>>                    <web-context>auth</web-context>
>>>                </auth-server>
>>>            </subsystem>
>>> Whatever you have set for web-context will be ignored.  You could just
>>> set it to /.
>>>
>>> Also Note: If you change the default-web-module after you have already
>>> booted your server then you will need to wipe out your old keycloak
>>> database, which will then contain an old invalid redirect url.
>>>
>>> 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  Wed Apr 15 09:08:38 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 15 Apr 2015 09:08:38 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552E5B7E.3080005@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552DAF46.1050903@redhat.com> <552E5767.6030901@redhat.com>
	<668400031.97139.1429101079637.JavaMail.zimbra@redhat.com>
	<552E5B7E.3080005@redhat.com>
Message-ID: <552E62D6.6030505@redhat.com>

On 4/15/2015 8:37 AM, Stan Silvert wrote:
> On 4/15/2015 8:31 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, April 15, 2015 2:19:51 PM
>>> Subject: Re: [keycloak-dev] Keycloak distribution changes
>>>
>>> On 4/14/2015 8:22 PM, Stan Silvert wrote:
>>>> On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
>>>>> * Add support to use root-context with server subsystem
>>>>>
>>> BTW, I think this should be documented somewhere.  Should it be in the
>>> doc, wiki, or in a blog?
>> Docs ;)
>>
>> We could add to http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/providers.html#d4e411 and include list of what providers and their config options.
> Huh?  This isn't about providers.  It's a setting in the Undertow subsystem.
If no objection, I'll just add a short section under "Installation and 
configuration".
>>>> I tried it out and this already works.  To run the Keycloak server as
>>>> the root context, you just need to change an Undertow setting:
>>>> <host name="default-host" alias="localhost"
>>>> default-web-module="main-auth-server.war">
>>>>
>>>> default-web-module should be whatever you named your server in the
>>>> Keycloak subsystem with ".war" appended.  By default, this is
>>>> "main-auth-server.war".
>>>>
>>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
>>>>                 <auth-server name="main-auth-server">
>>>>                     <enabled>true</enabled>
>>>>                     <web-context>auth</web-context>
>>>>                 </auth-server>
>>>>             </subsystem>
>>>> Whatever you have set for web-context will be ignored.  You could just
>>>> set it to /.
>>>>
>>>> Also Note: If you change the default-web-module after you have already
>>>> booted your server then you will need to wipe out your old keycloak
>>>> database, which will then contain an old invalid redirect url.
>>>>
>>>> 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
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From lkrzyzan at redhat.com  Wed Apr 15 10:41:22 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Wed, 15 Apr 2015 16:41:22 +0200
Subject: [keycloak-dev] Added KeycloakContext (and updates to
	JBossLoggingEventListenerProvider)
In-Reply-To: <1882074123.82545.1429099363619.JavaMail.zimbra@redhat.com>
References: <1882074123.82545.1429099363619.JavaMail.zimbra@redhat.com>
Message-ID: <CB777CE8-5176-4BBC-9DEB-FF972B6CE8DE@redhat.com>

Thank you very much Stian,
just working on it and seems that it works ;-)

Thanks,

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

> On 15 Apr 2015, at 14:02, Stian Thorgersen <stian at redhat.com> wrote:
> 
> I've added KeycloakContext to KeycloakSession. This should help us to not have to pass around things like UriInfo, RealmModel, etc..
> 
> I've not refactored much of existing code, we can do that as we go along. In the future get things from KeycloakContext instead of passing it or injecting it. One thing I did was to get rid of the "Flows" stuff which was pretty much gone any ways.
> 
> This also provides access to these values for all providers (for example access to cookies within events requested by jboss.org guys, KEYCLOAK-1042).
> 
> To test this out I've updated JBossLoggingEventListenerProvider. JBossLoggingEventListenerProvider is now added by default to new realms making it easier to enable log for events. By default success events are logged with debug and error events are logged with warn, this can be changed in keycloak-server.json. To view events enable debug for "org.keycloak.events". If you set "org.keycloak.events" to trace it will also add requestUri and cookies to the log output.
> 
> Check out https://github.com/keycloak/keycloak/blob/master/events/jboss-logging/src/main/java/org/keycloak/events/log/JBossLoggingEventListenerProvider.java#L70 for some code ;)
> _______________________________________________
> 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/20150415/62061fa7/attachment.html 

From psilva at redhat.com  Wed Apr 15 16:57:55 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 15 Apr 2015 16:57:55 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1297889628.572342.1429131250850.JavaMail.zimbra@redhat.com>
Message-ID: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>

Hi,

    Is KC considering this vulnerability [1] when performing redirects ? Specially for OAuth Clients doing authorization code grant.

Regards.

[1] http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html

From bburke at redhat.com  Wed Apr 15 19:30:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Apr 2015 19:30:02 -0400
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
Message-ID: <552EF47A.8020604@redhat.com>

Just looked, we redirect to an error page.

On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> Hi,
>
>      Is KC considering this vulnerability [1] when performing redirects ? Specially for OAuth Clients doing authorization code grant.
>
> Regards.
>
> [1] http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> _______________________________________________
> 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 Apr 15 19:31:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 15 Apr 2015 19:31:17 -0400
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
Message-ID: <552EF4C5.3050004@redhat.com>

One more thing...

We never redirect unless the redirect URI and client id is validated.

On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> Hi,
>
>      Is KC considering this vulnerability [1] when performing redirects ? Specially for OAuth Clients doing authorization code grant.
>
> Regards.
>
> [1] http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> _______________________________________________
> 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 Apr 16 02:54:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Apr 2015 02:54:08 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552E62D6.6030505@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552DAF46.1050903@redhat.com> <552E5767.6030901@redhat.com>
	<668400031.97139.1429101079637.JavaMail.zimbra@redhat.com>
	<552E5B7E.3080005@redhat.com> <552E62D6.6030505@redhat.com>
Message-ID: <1375544183.893496.1429167248852.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 15, 2015 3:08:38 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> On 4/15/2015 8:37 AM, Stan Silvert wrote:
> > On 4/15/2015 8:31 AM, Stian Thorgersen wrote:
> >> ----- Original Message -----
> >>> From: "Stan Silvert" <ssilvert at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, April 15, 2015 2:19:51 PM
> >>> Subject: Re: [keycloak-dev] Keycloak distribution changes
> >>>
> >>> On 4/14/2015 8:22 PM, Stan Silvert wrote:
> >>>> On 4/14/2015 2:28 AM, Stian Thorgersen wrote:
> >>>>> * Add support to use root-context with server subsystem
> >>>>>
> >>> BTW, I think this should be documented somewhere.  Should it be in the
> >>> doc, wiki, or in a blog?
> >> Docs ;)
> >>
> >> We could add to
> >> http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/userguide/html/providers.html#d4e411
> >> and include list of what providers and their config options.
> > Huh?  This isn't about providers.  It's a setting in the Undertow
> > subsystem.
> If no objection, I'll just add a short section under "Installation and
> configuration".

I somehow read something else first, then read your comment about adding it to docs. Not sure what happened, in either case my answer doesn't make sense at all and yes "Installation and configuration" is a good space for it ;)

> >>>> I tried it out and this already works.  To run the Keycloak server as
> >>>> the root context, you just need to change an Undertow setting:
> >>>> <host name="default-host" alias="localhost"
> >>>> default-web-module="main-auth-server.war">
> >>>>
> >>>> default-web-module should be whatever you named your server in the
> >>>> Keycloak subsystem with ".war" appended.  By default, this is
> >>>> "main-auth-server.war".
> >>>>
> >>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.0">
> >>>>                 <auth-server name="main-auth-server">
> >>>>                     <enabled>true</enabled>
> >>>>                     <web-context>auth</web-context>
> >>>>                 </auth-server>
> >>>>             </subsystem>
> >>>> Whatever you have set for web-context will be ignored.  You could just
> >>>> set it to /.
> >>>>
> >>>> Also Note: If you change the default-web-module after you have already
> >>>> booted your server then you will need to wipe out your old keycloak
> >>>> database, which will then contain an old invalid redirect url.
> >>>>
> >>>> 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
> >>>
> > _______________________________________________
> > 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 Apr 16 03:06:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Apr 2015 03:06:16 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <552EF4C5.3050004@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
Message-ID: <1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>

I don't get the attack, he states that:

  Now let's assume an attacker:
   * Registers a new client to the victim.com provider.
   * Registers a redirect uri like attacker.com.

If the attacker can register a client with a redirect uri, how is it then an open redirect?!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 1:31:17 AM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> One more thing...
> 
> We never redirect unless the redirect URI and client id is validated.
> 
> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> > Hi,
> >
> >      Is KC considering this vulnerability [1] when performing redirects ?
> >      Specially for OAuth Clients doing authorization code grant.
> >
> > Regards.
> >
> > [1]
> > http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> > _______________________________________________
> > 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 kontakt at michalchoinski.pl  Thu Apr 16 05:34:52 2015
From: kontakt at michalchoinski.pl (=?UTF-8?B?TWljaGHFgiBDaG9pxYRza2k=?=)
Date: Thu, 16 Apr 2015 11:34:52 +0200
Subject: [keycloak-dev] Handle case when KC fails to send logout message to
 some application - KEYCLOAK 782
Message-ID: <552F823C.90900@michalchoinski.pl>

Hi everyone!

I'm a potential GSOC student dreaming of working on "Keycloak - 
Certificate Management" project. I spent last few days analysing the 
code, debuging and looking how it really works on the inside.
I'd like to fix a bug which I've chosen from Jira. The issue number is 
KEYCLOAK-782.

In OAuth 2.0 specification (RFC6749) I found the following parameters 
(within item 4.1.2.1.  Error Response) :

server_error
                The authorization server encountered an unexpected
                condition that prevented it from fulfilling the request.
                (This error code is needed because a 500 Internal Server
                Error HTTP status code cannot be returned to the client
                via an HTTP redirect.)

error_description
          OPTIONAL.  Human-readable ASCII [USASCII] text providing
          additional information, used to assist the client developer in
          understanding the error that occurred.
          Values for the "error_description" parameter MUST NOT include
          characters outside the set %x20-21 / %x23-5B / %x5D-7E.

So the uri after logout would look like this:
...&error=server_error&error_description=Logout+from+some+apps+failed

The error_description could be either human readable description or just 
an error code. It should be processed on client side. Keycloak.js should 
be changed to handle it.

These params should be added to OIDCLoginProtocol and of course to 
response when such an error occur.
In first loop iterating on userSessions placed in 
AuthenticationManager.browserLogout there should be saving error when 
backend logout fails. It could be done by adding a note to userSession 
and getting it in finishLogout (first, of course, checking if it exists).

What do you think about the above mentioned solution?

best regards,
Michal Choinski







From srossillo at smartling.com  Thu Apr 16 09:08:13 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Thu, 16 Apr 2015 09:08:13 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
Message-ID: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>

Good morning,

As I mentioned a few days ago on the users mailing list, we developed an
integration between the Keycloak Adapter and Spring Security. The
announcement can be found here:

http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html

The code is here:

http://smartling.github.io/spring-security-keycloak/

Would you be interested in either:

1. Us contributing the code to the Keycloak project or

2. You integrating the code into the Keycloak project


We released the code under the Apache 2.0 license to be compatible
with the Keycloak project. Let me know your thoughts.

Best,

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150416/47e1b260/attachment-0001.html 

From stian at redhat.com  Thu Apr 16 09:24:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Apr 2015 09:24:58 -0400 (EDT)
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
Message-ID: <1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>

If you can prepare a PR for it that'd be great. Please add a 'spring-security' module within the integration module where all the other adapters live. Also, to create a distribution archive for the adapter please add a module inside distribution that packages it up (look at existing modules there for a reference).

----- Original Message -----
> From: "Scott Rossillo" <srossillo at smartling.com>
> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, April 16, 2015 3:08:13 PM
> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
> 
> Good morning,
> 
> As I mentioned a few days ago on the users mailing list, we developed an
> integration between the Keycloak Adapter and Spring Security. The
> announcement can be found here:
> 
> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
> 
> The code is here:
> http://smartling.github.io/spring-security-keycloak/
> Would you be interested in either:
> 1. Us contributing the code to the Keycloak project or
> 2. You integrating the code into the Keycloak project
> 
> We released the code under the Apache 2.0 license to be compatible with the
> Keycloak project. Let me know your thoughts.
> Best,
> Scott
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From psilva at redhat.com  Thu Apr 16 09:35:36 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 Apr 2015 09:35:36 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
	<1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
Message-ID: <1351491168.833171.1429191336646.JavaMail.zimbra@redhat.com>

Yep, but that is pretty much about tricking users. For instance, a malicious client could utilize a user's trust in your authorization server to launch a phishing attack.

Bill already stated that KC redirects to an internal error page instead of redirecting to client when some error occurs (eg.: invalid client_id or redirect uri). Which is one of the most important recommendations [1]. The URI is also validated using the full redirection uri, not only part of it.

Google also provides some restrictions when defining redirect URIs. For instance, you can't use fragments.

[1] https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08

----- 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, April 16, 2015 4:06:16 AM
Subject: Re: [keycloak-dev] Open Redirect Vulnerability

I don't get the attack, he states that:

  Now let's assume an attacker:
   * Registers a new client to the victim.com provider.
   * Registers a redirect uri like attacker.com.

If the attacker can register a client with a redirect uri, how is it then an open redirect?!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 1:31:17 AM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> One more thing...
> 
> We never redirect unless the redirect URI and client id is validated.
> 
> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> > Hi,
> >
> >      Is KC considering this vulnerability [1] when performing redirects ?
> >      Specially for OAuth Clients doing authorization code grant.
> >
> > Regards.
> >
> > [1]
> > http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Apr 16 09:52:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 16 Apr 2015 09:52:17 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1351491168.833171.1429191336646.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
	<1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
	<1351491168.833171.1429191336646.JavaMail.zimbra@redhat.com>
Message-ID: <111508487.1243237.1429192337945.JavaMail.zimbra@redhat.com>

Thinking about it some more the reason I didn't get it is because it's not applicable to Keycloak because we don't allow anyone to register a client. Only admins are allowed to create clients in Keycloak, so a client is a trusted entity.

If it's possible to register untrusted clients, like it is for any social provider (or SaaS service), this becomes a problem. It doesn't have anything to do with verifying the redirect-uri, because you still set a valid redirect-uri. Even worse it's actually a problem with the spec itself as the post says. For any error except a redirect-uri related error it should redirect back to the application. That could be an invalid response_type, invalid_scope, etc..

Google doesn't actually follow the spec as they display an error page for invalid_scope instead of redirecting back to the client.

If we have implement support for anyone to register clients in Keycloak, we need to do the same. If it's a "untrusted client" never redirect to client in case of an error. The rule could be if it requires consent, display error page, if it doesn't require consent redirect to app.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 3:35:36 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> Yep, but that is pretty much about tricking users. For instance, a malicious
> client could utilize a user's trust in your authorization server to launch a
> phishing attack.
> 
> Bill already stated that KC redirects to an internal error page instead of
> redirecting to client when some error occurs (eg.: invalid client_id or
> redirect uri). Which is one of the most important recommendations [1]. The
> URI is also validated using the full redirection uri, not only part of it.
> 
> Google also provides some restrictions when defining redirect URIs. For
> instance, you can't use fragments.
> 
> [1] https://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08
> 
> ----- 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, April 16, 2015 4:06:16 AM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> I don't get the attack, he states that:
> 
>   Now let's assume an attacker:
>    * Registers a new client to the victim.com provider.
>    * Registers a redirect uri like attacker.com.
> 
> If the attacker can register a client with a redirect uri, how is it then an
> open redirect?!
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, April 16, 2015 1:31:17 AM
> > Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> > 
> > One more thing...
> > 
> > We never redirect unless the redirect URI and client id is validated.
> > 
> > On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> > > Hi,
> > >
> > >      Is KC considering this vulnerability [1] when performing redirects ?
> > >      Specially for OAuth Clients doing authorization code grant.
> > >
> > > Regards.
> > >
> > > [1]
> > > http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Apr 16 11:57:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 16 Apr 2015 11:57:02 -0400
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
	<1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
Message-ID: <552FDBCE.6040401@redhat.com>

I thought the attack was: put in an attacker redirect uri and an invalid 
parameter, auth server fails, redirects to non-validated attacker 
redirect uri.

On 4/16/2015 3:06 AM, Stian Thorgersen wrote:
> I don't get the attack, he states that:
>
>    Now let's assume an attacker:
>     * Registers a new client to the victim.com provider.
>     * Registers a redirect uri like attacker.com.
>
> If the attacker can register a client with a redirect uri, how is it then an open redirect?!
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, April 16, 2015 1:31:17 AM
>> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
>>
>> One more thing...
>>
>> We never redirect unless the redirect URI and client id is validated.
>>
>> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
>>> Hi,
>>>
>>>       Is KC considering this vulnerability [1] when performing redirects ?
>>>       Specially for OAuth Clients doing authorization code grant.
>>>
>>> Regards.
>>>
>>> [1]
>>> http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
>>> _______________________________________________
>>> 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 Apr 16 13:51:37 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 16 Apr 2015 13:51:37 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <552FDBCE.6040401@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
	<1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
	<552FDBCE.6040401@redhat.com>
Message-ID: <1527217121.1227561.1429206696999.JavaMail.zimbra@redhat.com>

Another scenario is AS partially validating the redirect uri. For instance, http://somesite.com/attacker.

If the registered redirect uri is just http://somesite.com and the AS is not checking its full format, it may consider that the uri above is valid. What is also covered by KC, so no problem here as well.

----- 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, April 16, 2015 12:57:02 PM
Subject: Re: [keycloak-dev] Open Redirect Vulnerability

I thought the attack was: put in an attacker redirect uri and an invalid 
parameter, auth server fails, redirects to non-validated attacker 
redirect uri.

On 4/16/2015 3:06 AM, Stian Thorgersen wrote:
> I don't get the attack, he states that:
>
>    Now let's assume an attacker:
>     * Registers a new client to the victim.com provider.
>     * Registers a redirect uri like attacker.com.
>
> If the attacker can register a client with a redirect uri, how is it then an open redirect?!
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, April 16, 2015 1:31:17 AM
>> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
>>
>> One more thing...
>>
>> We never redirect unless the redirect URI and client id is validated.
>>
>> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
>>> Hi,
>>>
>>>       Is KC considering this vulnerability [1] when performing redirects ?
>>>       Specially for OAuth Clients doing authorization code grant.
>>>
>>> Regards.
>>>
>>> [1]
>>> http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
>>> _______________________________________________
>>> 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
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Fri Apr 17 01:05:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Apr 2015 01:05:13 -0400 (EDT)
Subject: [keycloak-dev] Open Redirect Vulnerability
In-Reply-To: <1527217121.1227561.1429206696999.JavaMail.zimbra@redhat.com>
References: <1635988407.575940.1429131475653.JavaMail.zimbra@redhat.com>
	<552EF4C5.3050004@redhat.com>
	<1269993325.897788.1429167976180.JavaMail.zimbra@redhat.com>
	<552FDBCE.6040401@redhat.com>
	<1527217121.1227561.1429206696999.JavaMail.zimbra@redhat.com>
Message-ID: <106604902.1690845.1429247113569.JavaMail.zimbra@redhat.com>

This attack assumes that it's a valid client and the redirect uri is valid. It's about untrusted clients being able to bypass user consent by adding expected errors. Google lets anyone register a client so you can register attack.com as a client and the redirect will be perfectly valid. What Google does differently to Facebook is that they don't redirect to the client in an error, so the user will always see a grant page. While Facebook if you enter the wrong scope will redirect to attack.som without showing a consent screen.

We should make sure that Keycloak never redirects to a client that requires consent from the user without user input. Including if there's an error (for example invalid grant_type) and the client requires consent we display a page stating there was an error with a link continue to application. Once a user has consented to a client (persisted grants exists for the user-client) we can redirect to the client as the user has now trusted the client. 

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, April 16, 2015 7:51:37 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> Another scenario is AS partially validating the redirect uri. For instance,
> http://somesite.com/attacker.
> 
> If the registered redirect uri is just http://somesite.com and the AS is not
> checking its full format, it may consider that the uri above is valid. What
> is also covered by KC, so no problem here as well.
> 
> ----- 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, April 16, 2015 12:57:02 PM
> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> 
> I thought the attack was: put in an attacker redirect uri and an invalid
> parameter, auth server fails, redirects to non-validated attacker
> redirect uri.
> 
> On 4/16/2015 3:06 AM, Stian Thorgersen wrote:
> > I don't get the attack, he states that:
> >
> >    Now let's assume an attacker:
> >     * Registers a new client to the victim.com provider.
> >     * Registers a redirect uri like attacker.com.
> >
> > If the attacker can register a client with a redirect uri, how is it then
> > an open redirect?!
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, April 16, 2015 1:31:17 AM
> >> Subject: Re: [keycloak-dev] Open Redirect Vulnerability
> >>
> >> One more thing...
> >>
> >> We never redirect unless the redirect URI and client id is validated.
> >>
> >> On 4/15/2015 4:57 PM, Pedro Igor Silva wrote:
> >>> Hi,
> >>>
> >>>       Is KC considering this vulnerability [1] when performing redirects
> >>>       ?
> >>>       Specially for OAuth Clients doing authorization code grant.
> >>>
> >>> Regards.
> >>>
> >>> [1]
> >>> http://intothesymmetry.blogspot.ch/2015/04/open-redirect-in-rfc6749-aka-oauth-20.html
> >>> _______________________________________________
> >>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Apr 17 05:33:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Apr 2015 05:33:19 -0400 (EDT)
Subject: [keycloak-dev] Admin events take 2
Message-ID: <311188032.1883532.1429263199920.JavaMail.zimbra@redhat.com>

After feedback on admin events design I realised it needed some more work. I've updated the description on the jira issue as well as the mock code/screens.

Please review and comment on:
https://issues.jboss.org/browse/KEYCLOAK-392

From giriraj.sharma27 at gmail.com  Fri Apr 17 07:30:01 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Fri, 17 Apr 2015 17:00:01 +0530
Subject: [keycloak-dev] Hacking on Keycloak docs
In-Reply-To: <73F710EF-F5F7-4AA4-B620-48C948B29653@redhat.com>
References: <384716450.18096496.1429000895708.JavaMail.zimbra@redhat.com>
	<73F710EF-F5F7-4AA4-B620-48C948B29653@redhat.com>
Message-ID: <CAB5vuUwQzKYu8OvRvN2tBWpBjjJW5XfOq65tm=393R1tqKeZXw@mail.gmail.com>

Does the current source code in keycloak repository entirely adheres to
wildfly ide-configs. If yes then its fine.

If it doesn't, then making changes in a file and formatting as per wildfly
ide configs, will introduce some formatting changes too i.e., changes not
relevant to the PR.

On Tue, Apr 14, 2015 at 4:05 PM, Libor Krzy?anek <lkrzyzan at redhat.com>
wrote:

> Perfect!
>
> Thanks,
>
> Libor Krzy?anek
> jboss.org Development Team
>
> On 14 Apr 2015, at 10:41, Stian Thorgersen <stian at redhat.com> wrote:
>
> I've updated the main README.md in the GitHub repo to include some details
> on how to build and run Keycloak.
>
> As we had some developer related docs in GitHub wiki (
> https://github.com/keycloak/keycloak/wiki) and some in repo itself (
> https://github.com/keycloak/keycloak/tree/master/misc) I've deleted the
> out of date stuff and moved everything to
> https://github.com/keycloak/keycloak/tree/master/misc.
>
> I've also added a Hacking on Keycloak guide (
> https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md
> ).
> _______________________________________________
> 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/20150417/05c6cd8b/attachment-0001.html 

From mposolda at redhat.com  Fri Apr 17 08:32:30 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 17 Apr 2015 14:32:30 +0200
Subject: [keycloak-dev] Persistent grants - step 1
Message-ID: <5530FD5E.1040106@redhat.com>

I've sent startup PR for persistent grants. I've added 
GrantedConsentModel (is it good name?) to track the roles and protocol 
mappers user granted on consent screen. Consent screen is not displayed 
if user already approved roles and protocol mappers before. There is 
also new "Access" tab in account management where can user see 
previously granted consents and revoke them for particular client. Is 
"Access" good name for the tab?

There is still some work and I will continue if you don't have any 
comments to the current impl. Remaining TODO is:
- representations
- Mongo model (for now I have just JPA. I hope that "file" model could 
be skipped for now?)
- More automated tests

Some additional things to discuss:
- I would like to add 
ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String> 
with Ids of protocolMappers similarly like current getRoles/setRoles). 
There is one small issue that protocolMappers are actually always 
computed from the ClientModel, which means that there could be 
theoreticallly different protocolMappers displayed to user and then 
later saved to persistent model. Also later we want to add support for 
"scope" parameter, which means that protocolMappers on the consent 
screen could be really different than protocolMappers from the 
ClientModel. Any objections against it?

- It may be good to add ClientModel.setDescription/getDescription, so on 
the consent screen and in Account management Access page is displayed 
the more proper (and localized) description of the client instead of 
clientId (ie. "Have User Privileges in ThirdParty Application" instead 
of "Have User Privileges in third-party"). Any objections against it?

- There is bit related issue 
https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all 
sessions" in Account management doesn't propagate logout to the apps. 
Currently I invalidate clientSessions of particular client and user 
during revoke, but also don't propagate it to the applications. I would 
like to change that and propagate it and also fix KEYCLOAK-1216  at the 
same time. There will be still small issue for JS applications, because 
when just clientSession of JS application is revoked, the logout won't 
be propagated to the actual application because KEYCLOAK_SESSION cookie 
is still valid. So for JS applications, the application will be really 
logged later when accessToken expires. Any objections against it? Any 
idea how to propagate revoke to JS applications?

Thanks,
Marek

From stian at redhat.com  Fri Apr 17 08:54:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 17 Apr 2015 08:54:08 -0400 (EDT)
Subject: [keycloak-dev] Hacking on Keycloak docs
In-Reply-To: <CAB5vuUwQzKYu8OvRvN2tBWpBjjJW5XfOq65tm=393R1tqKeZXw@mail.gmail.com>
References: <384716450.18096496.1429000895708.JavaMail.zimbra@redhat.com>
	<73F710EF-F5F7-4AA4-B620-48C948B29653@redhat.com>
	<CAB5vuUwQzKYu8OvRvN2tBWpBjjJW5XfOq65tm=393R1tqKeZXw@mail.gmail.com>
Message-ID: <1955756266.2022915.1429275248067.JavaMail.zimbra@redhat.com>

Quotes from doc:

"We don't currently enforce a code style in Keycloak, but a good reference is the code style used by WildFly. This can be retrieved from (https://github.com/wildfly/wildfly-core/tree/master/ide-configs)[https://github.com/wildfly/wildfly-core/tree/master/ide-configs]."

"No changes to code not directly related to your change (e.g. no formatting changes or refactoring to existing code, if you want to refactor/improve existing code that's a separate discussion to mailing list and JIRA issue)"

----- Original Message -----
> From: "Giriraj Sharma" <giriraj.sharma27 at gmail.com>
> To: "Libor Krzy?anek" <lkrzyzan at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, April 17, 2015 1:30:01 PM
> Subject: Re: [keycloak-dev] Hacking on Keycloak docs
> 
> Does the current source code in keycloak repository entirely adheres to
> wildfly ide-configs. If yes then its fine.
> 
> If it doesn't, then making changes in a file and formatting as per wildfly
> ide configs, will introduce some formatting changes too i.e., changes not
> relevant to the PR.
> 
> On Tue, Apr 14, 2015 at 4:05 PM, Libor Krzy?anek <lkrzyzan at redhat.com>
> wrote:
> 
> > Perfect!
> >
> > Thanks,
> >
> > Libor Krzy?anek
> > jboss.org Development Team
> >
> > On 14 Apr 2015, at 10:41, Stian Thorgersen <stian at redhat.com> wrote:
> >
> > I've updated the main README.md in the GitHub repo to include some details
> > on how to build and run Keycloak.
> >
> > As we had some developer related docs in GitHub wiki (
> > https://github.com/keycloak/keycloak/wiki) and some in repo itself (
> > https://github.com/keycloak/keycloak/tree/master/misc) I've deleted the
> > out of date stuff and moved everything to
> > https://github.com/keycloak/keycloak/tree/master/misc.
> >
> > I've also added a Hacking on Keycloak guide (
> > https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md
> > ).
> > _______________________________________________
> > 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
>


From bburke at redhat.com  Fri Apr 17 17:16:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Apr 2015 17:16:03 -0400
Subject: [keycloak-dev] out of memory errors on build
Message-ID: <55317813.8020004@redhat.com>

Keycloak master build is really slow and ends up failing with out of 
memory errors.  My maven opts are set to 1 gigabyte max ram.  Somebody 
introduced something nasty in the last few days.

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

From bburke at redhat.com  Fri Apr 17 17:36:44 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 17 Apr 2015 17:36:44 -0400
Subject: [keycloak-dev] out of memory errors on build
In-Reply-To: <55317813.8020004@redhat.com>
References: <55317813.8020004@redhat.com>
Message-ID: <55317CEC.2070101@redhat.com>

Had to bump the surefire forked memory.

On 4/17/2015 5:16 PM, Bill Burke wrote:
> Keycloak master build is really slow and ends up failing with out of
> memory errors.  My maven opts are set to 1 gigabyte max ram.  Somebody
> introduced something nasty in the last few days.
>

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

From stian at redhat.com  Mon Apr 20 01:09:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Apr 2015 01:09:48 -0400 (EDT)
Subject: [keycloak-dev] Keycloak JIRA - github commits sync
In-Reply-To: <5515257B.9020808@redhat.com>
References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com>
	<1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com>
	<F6C39D3B-76CB-4D53-9F1F-E6663C062438@redhat.com>
	<1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com>
	<5515257B.9020808@redhat.com>
Message-ID: <1848625058.3020648.1429506588010.JavaMail.zimbra@redhat.com>

Hi Vlastimil,

Finally got around to adding jboss-jira-hook to Keycloak owner's group. Can you configure jira to show github commits for us now?

Thanks,
Stian

----- Original Message -----
> From: "Vlastimil Elias" <velias at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, March 27, 2015 10:40:11 AM
> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
> 
> Hi Stian,
> 
> general description is at
> https://developer.jboss.org/en/website/blog/2013/03/11/new-way-to-show-github-commits-in-jbossorg-jira
> even it is a bit out of date as jira now shows commits a bit differently.
> But process of adding at the end of the page is valid, so you have to do
> step 2 - jboss-jira-hook github user must be added into the Keycloak
> organization's Owners group. Jira needs this to add webhooks.
> 
> After you configure this then let me know and I can configure jira.
> 
> Cheers
> 
> Vl.
> 
> On 27.3.2015 10:29, Stian Thorgersen wrote:
> 
> 
> 
> Then the answer is yes please :)
> 
> ----- Original Message -----
> 
> 
> 
> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To: "Stian Thorgersen"
> <stian at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Friday, 27 March,
> 2015 10:28:09 AM
> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
> 
> Fully automated.
> 
> Vlastimil can configure it.
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org <http://jboss.org/> Development Team
> 
> 
> 
> On 27 Mar 2015, at 10:27, Stian Thorgersen <stian at redhat.com> wrote:
> 
> Can that be automated? Or does it require manually linking PRs?
> 
> ----- Original Message -----
> 
> 
> 
> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To:
> keycloak-dev at lists.jboss.org Sent: Friday, 27 March, 2015 9:31:48 AM
> Subject: [keycloak-dev] Keycloak JIRA - github commits sync
> 
> Hi there,
> I think it?s very useful to have configured jira project to sync issues
> with
> commits.
> 
> For example I would very quickly see how Stian implemented this
> https://issues.jboss.org/browse/KEYCLOAK-1137 WDYT?
> 
> Thanks,
> 
> Libor Krzy?anek
> jboss.org Development Team
> 
> 
> _______________________________________________
> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Vlastimil Elias
> Principal Software Engineer
> jboss.org Development Team
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Mon Apr 20 01:36:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Apr 2015 01:36:43 -0400 (EDT)
Subject: [keycloak-dev] Persistent grants - step 1
In-Reply-To: <5530FD5E.1040106@redhat.com>
References: <5530FD5E.1040106@redhat.com>
Message-ID: <277041367.3068646.1429508203368.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, April 17, 2015 2:32:30 PM
> Subject: [keycloak-dev] Persistent grants - step 1
> 
> I've sent startup PR for persistent grants. I've added
> GrantedConsentModel (is it good name?) to track the roles and protocol
> mappers user granted on consent screen. Consent screen is not displayed
> if user already approved roles and protocol mappers before. There is
> also new "Access" tab in account management where can user see
> previously granted consents and revoke them for particular client. Is
> "Access" good name for the tab?

UserConsentModel?

I'd rather call the page in account management 'Applications' tab. One thing I'd like us to add is a list of applications a user can access. It makes more sense to me to have a single place to view everything related to applications (which are available, what access do they have, what sessions are they logged-in to, etc..) than having multiple pages.

> 
> There is still some work and I will continue if you don't have any
> comments to the current impl. Remaining TODO is:
> - representations
> - Mongo model (for now I have just JPA. I hope that "file" model could
> be skipped for now?)
> - More automated tests
> 
> Some additional things to discuss:
> - I would like to add
> ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String>
> with Ids of protocolMappers similarly like current getRoles/setRoles).
> There is one small issue that protocolMappers are actually always
> computed from the ClientModel, which means that there could be
> theoreticallly different protocolMappers displayed to user and then
> later saved to persistent model. Also later we want to add support for
> "scope" parameter, which means that protocolMappers on the consent
> screen could be really different than protocolMappers from the
> ClientModel. Any objections against it?
> 
> - It may be good to add ClientModel.setDescription/getDescription, so on
> the consent screen and in Account management Access page is displayed
> the more proper (and localized) description of the client instead of
> clientId (ie. "Have User Privileges in ThirdParty Application" instead
> of "Have User Privileges in third-party"). Any objections against it?

+1 To add, but call it ClientModel.get/setName instead. This makes me think that we need a way to manage localized labels through the console. If someone sets name of a client to ${myClient} then they should also be able to add translations to it through the admin console. That's something to implement later though. 

> 
> - There is bit related issue
> https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all
> sessions" in Account management doesn't propagate logout to the apps.
> Currently I invalidate clientSessions of particular client and user
> during revoke, but also don't propagate it to the applications. I would
> like to change that and propagate it and also fix KEYCLOAK-1216  at the
> same time. There will be still small issue for JS applications, because
> when just clientSession of JS application is revoked, the logout won't
> be propagated to the actual application because KEYCLOAK_SESSION cookie
> is still valid. So for JS applications, the application will be really
> logged later when accessToken expires. Any objections against it? Any
> idea how to propagate revoke to JS applications?

Assuming 1216 is the way it's work all along, let's postpone that. Same goes for propagating "consent revocation" to apps, jira it and postpone to next release.

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

From stian at redhat.com  Mon Apr 20 03:08:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Apr 2015 03:08:13 -0400 (EDT)
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <1616404749.3092353.1429512422571.JavaMail.zimbra@redhat.com>
Message-ID: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>

We've already discussed this, but didn't come to a conclusion.

There's two separate use-cases to consider:

1. Authentication
2. Offline access

For simplicity the examples below assumes OpenID Connect, but same logic applies to SAML.


Authentication
--------------
In this case user authenticates using an external IdP. After the user has authenticated the access and refresh (if available) tokens are stored in user session. Tokens are automatically refreshed by Keycloak to support brokered log out. In this case an application can only retrieve an access token for the identity provider that was used to authenticate the user.


Offline access
--------------
In this case we should add the option "offline access" to the provider config. When enabled we add "offline" to the requested scope. When a user first logs in or links through account mngmt we store the refresh token (aka "offline token") in the user store. As this is a long term token I don't see any problems using the user store for it. In this case an application can retrieve an access token for the identity provider that was used to authenticate the user, but also for an identity providers what have "offline access" enabled and there's an token store in the user store. One issue with this approach is that brokered log out doesn't work. A potential solution to that is that we only request offline access when linking the account, but during authentication don't add the offline scope and use the process from the first use-case.


Token retrieval
---------------
We add a "token service" client to Keycloak that has a "retrieve token" role for each provider. For an application to be able to retrieve the token the user has to have a role mapping on this role and the client has to have a scope on it as well. This results in using standard roles, scopes and consent screens instead of a different mechanism.


For 1.2.0 we should only add support for the "Authentication" use case. I believe we pretty much already have this as Bill did this to support brokered log out. Only thing we need to change is how we manage if a client has access to retrieve the token or not. We should just jira the other use-case and add if it's requested by users.


From velias at redhat.com  Mon Apr 20 04:13:19 2015
From: velias at redhat.com (Vlastimil Elias)
Date: Mon, 20 Apr 2015 10:13:19 +0200
Subject: [keycloak-dev] Keycloak JIRA - github commits sync
In-Reply-To: <1848625058.3020648.1429506588010.JavaMail.zimbra@redhat.com>
References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com>
	<1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com>
	<F6C39D3B-76CB-4D53-9F1F-E6663C062438@redhat.com>
	<1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com>
	<5515257B.9020808@redhat.com>
	<1848625058.3020648.1429506588010.JavaMail.zimbra@redhat.com>
Message-ID: <5534B51F.4050104@redhat.com>

Hi Stian and whole Keycloak team,

JIRA is configured now to show info from Keycloak GitHub repo.
You can see informations about branches, commits, and pull requests in 
the Development section of JIRA issue detail page. The section is 
located on the right side of the page under People and Dates section.
Eg. see https://issues.jboss.org/browse/KEYCLOAK-392


I also added Keycloak repository to our FishEye/Crucible server, see 
https://source.jboss.org/changelog/Keycloak

Cheers

Vlastimil

On 20.4.2015 07:09, Stian Thorgersen wrote:
> Hi Vlastimil,
>
> Finally got around to adding jboss-jira-hook to Keycloak owner's group. Can you configure jira to show github commits for us now?
>
> Thanks,
> Stian
>
> ----- Original Message -----
>> From: "Vlastimil Elias" <velias at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, March 27, 2015 10:40:11 AM
>> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
>>
>> Hi Stian,
>>
>> general description is at
>> https://developer.jboss.org/en/website/blog/2013/03/11/new-way-to-show-github-commits-in-jbossorg-jira
>> even it is a bit out of date as jira now shows commits a bit differently.
>> But process of adding at the end of the page is valid, so you have to do
>> step 2 - jboss-jira-hook github user must be added into the Keycloak
>> organization's Owners group. Jira needs this to add webhooks.
>>
>> After you configure this then let me know and I can configure jira.
>>
>> Cheers
>>
>> Vl.
>>
>> On 27.3.2015 10:29, Stian Thorgersen wrote:
>>
>>
>>
>> Then the answer is yes please :)
>>
>> ----- Original Message -----
>>
>>
>>
>> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To: "Stian Thorgersen"
>> <stian at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Friday, 27 March,
>> 2015 10:28:09 AM
>> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
>>
>> Fully automated.
>>
>> Vlastimil can configure it.
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> jboss.org <http://jboss.org/> Development Team
>>
>>
>>
>> On 27 Mar 2015, at 10:27, Stian Thorgersen <stian at redhat.com> wrote:
>>
>> Can that be automated? Or does it require manually linking PRs?
>>
>> ----- Original Message -----
>>
>>
>>
>> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To:
>> keycloak-dev at lists.jboss.org Sent: Friday, 27 March, 2015 9:31:48 AM
>> Subject: [keycloak-dev] Keycloak JIRA - github commits sync
>>
>> Hi there,
>> I think it?s very useful to have configured jira project to sync issues
>> with
>> commits.
>>
>> For example I would very quickly see how Stian implemented this
>> https://issues.jboss.org/browse/KEYCLOAK-1137 WDYT?
>>
>> Thanks,
>>
>> Libor Krzy?anek
>> jboss.org Development Team
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> jboss.org Development Team
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team


From lkrzyzan at redhat.com  Mon Apr 20 05:10:35 2015
From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=)
Date: Mon, 20 Apr 2015 11:10:35 +0200
Subject: [keycloak-dev] Keycloak JIRA - github commits sync
In-Reply-To: <5534B51F.4050104@redhat.com>
References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com>
	<1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com>
	<F6C39D3B-76CB-4D53-9F1F-E6663C062438@redhat.com>
	<1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com>
	<5515257B.9020808@redhat.com>
	<1848625058.3020648.1429506588010.JavaMail.zimbra@redhat.com>
	<5534B51F.4050104@redhat.com>
Message-ID: <B4351BD5-8988-4076-9A2F-8C8F705BD61D@redhat.com>

Very Cool!

It helps a lot!

Thanks,

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

> On 20 Apr 2015, at 10:13, Vlastimil Elias <velias at redhat.com> wrote:
> 
> Hi Stian and whole Keycloak team,
> 
> JIRA is configured now to show info from Keycloak GitHub repo.
> You can see informations about branches, commits, and pull requests in 
> the Development section of JIRA issue detail page. The section is 
> located on the right side of the page under People and Dates section.
> Eg. see https://issues.jboss.org/browse/KEYCLOAK-392 <https://issues.jboss.org/browse/KEYCLOAK-392>
> 
> 
> I also added Keycloak repository to our FishEye/Crucible server, see 
> https://source.jboss.org/changelog/Keycloak <https://source.jboss.org/changelog/Keycloak>
> 
> Cheers
> 
> Vlastimil
> 
> On 20.4.2015 07:09, Stian Thorgersen wrote:
>> Hi Vlastimil,
>> 
>> Finally got around to adding jboss-jira-hook to Keycloak owner's group. Can you configure jira to show github commits for us now?
>> 
>> Thanks,
>> Stian
>> 
>> ----- Original Message -----
>>> From: "Vlastimil Elias" <velias at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, March 27, 2015 10:40:11 AM
>>> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
>>> 
>>> Hi Stian,
>>> 
>>> general description is at
>>> https://developer.jboss.org/en/website/blog/2013/03/11/new-way-to-show-github-commits-in-jbossorg-jira
>>> even it is a bit out of date as jira now shows commits a bit differently.
>>> But process of adding at the end of the page is valid, so you have to do
>>> step 2 - jboss-jira-hook github user must be added into the Keycloak
>>> organization's Owners group. Jira needs this to add webhooks.
>>> 
>>> After you configure this then let me know and I can configure jira.
>>> 
>>> Cheers
>>> 
>>> Vl.
>>> 
>>> On 27.3.2015 10:29, Stian Thorgersen wrote:
>>> 
>>> 
>>> 
>>> Then the answer is yes please :)
>>> 
>>> ----- Original Message -----
>>> 
>>> 
>>> 
>>> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To: "Stian Thorgersen"
>>> <stian at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Friday, 27 March,
>>> 2015 10:28:09 AM
>>> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
>>> 
>>> Fully automated.
>>> 
>>> Vlastimil can configure it.
>>> 
>>> Thanks,
>>> 
>>> Libor Krzy?anek
>>> jboss.org <http://jboss.org/> Development Team
>>> 
>>> 
>>> 
>>> On 27 Mar 2015, at 10:27, Stian Thorgersen <stian at redhat.com> wrote:
>>> 
>>> Can that be automated? Or does it require manually linking PRs?
>>> 
>>> ----- Original Message -----
>>> 
>>> 
>>> 
>>> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To:
>>> keycloak-dev at lists.jboss.org Sent: Friday, 27 March, 2015 9:31:48 AM
>>> Subject: [keycloak-dev] Keycloak JIRA - github commits sync
>>> 
>>> Hi there,
>>> I think it?s very useful to have configured jira project to sync issues
>>> with
>>> commits.
>>> 
>>> For example I would very quickly see how Stian implemented this
>>> https://issues.jboss.org/browse/KEYCLOAK-1137 WDYT?
>>> 
>>> Thanks,
>>> 
>>> Libor Krzy?anek
>>> jboss.org Development Team
>>> 
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> 
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> jboss.org Development Team
>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> -- 
> Vlastimil Elias
> Principal Software Engineer
> jboss.org <http://jboss.org/> Development Team
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150420/94929a59/attachment-0001.html 

From stian at redhat.com  Mon Apr 20 05:34:58 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Apr 2015 05:34:58 -0400 (EDT)
Subject: [keycloak-dev] Keycloak JIRA - github commits sync
In-Reply-To: <5534B51F.4050104@redhat.com>
References: <01ADCFED-C074-4F8B-91ED-240AE2B94A8C@redhat.com>
	<1903093497.6626423.1427448457307.JavaMail.zimbra@redhat.com>
	<F6C39D3B-76CB-4D53-9F1F-E6663C062438@redhat.com>
	<1383765894.6627256.1427448564160.JavaMail.zimbra@redhat.com>
	<5515257B.9020808@redhat.com>
	<1848625058.3020648.1429506588010.JavaMail.zimbra@redhat.com>
	<5534B51F.4050104@redhat.com>
Message-ID: <829988794.3203716.1429522498237.JavaMail.zimbra@redhat.com>

Nice, thanks for adding it :)

----- Original Message -----
> From: "Vlastimil Elias" <velias at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, April 20, 2015 10:13:19 AM
> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
> 
> Hi Stian and whole Keycloak team,
> 
> JIRA is configured now to show info from Keycloak GitHub repo.
> You can see informations about branches, commits, and pull requests in
> the Development section of JIRA issue detail page. The section is
> located on the right side of the page under People and Dates section.
> Eg. see https://issues.jboss.org/browse/KEYCLOAK-392
> 
> 
> I also added Keycloak repository to our FishEye/Crucible server, see
> https://source.jboss.org/changelog/Keycloak
> 
> Cheers
> 
> Vlastimil
> 
> On 20.4.2015 07:09, Stian Thorgersen wrote:
> > Hi Vlastimil,
> >
> > Finally got around to adding jboss-jira-hook to Keycloak owner's group. Can
> > you configure jira to show github commits for us now?
> >
> > Thanks,
> > Stian
> >
> > ----- Original Message -----
> >> From: "Vlastimil Elias" <velias at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, March 27, 2015 10:40:11 AM
> >> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
> >>
> >> Hi Stian,
> >>
> >> general description is at
> >> https://developer.jboss.org/en/website/blog/2013/03/11/new-way-to-show-github-commits-in-jbossorg-jira
> >> even it is a bit out of date as jira now shows commits a bit differently.
> >> But process of adding at the end of the page is valid, so you have to do
> >> step 2 - jboss-jira-hook github user must be added into the Keycloak
> >> organization's Owners group. Jira needs this to add webhooks.
> >>
> >> After you configure this then let me know and I can configure jira.
> >>
> >> Cheers
> >>
> >> Vl.
> >>
> >> On 27.3.2015 10:29, Stian Thorgersen wrote:
> >>
> >>
> >>
> >> Then the answer is yes please :)
> >>
> >> ----- Original Message -----
> >>
> >>
> >>
> >> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To: "Stian Thorgersen"
> >> <stian at redhat.com> Cc: keycloak-dev at lists.jboss.org Sent: Friday, 27
> >> March,
> >> 2015 10:28:09 AM
> >> Subject: Re: [keycloak-dev] Keycloak JIRA - github commits sync
> >>
> >> Fully automated.
> >>
> >> Vlastimil can configure it.
> >>
> >> Thanks,
> >>
> >> Libor Krzy?anek
> >> jboss.org <http://jboss.org/> Development Team
> >>
> >>
> >>
> >> On 27 Mar 2015, at 10:27, Stian Thorgersen <stian at redhat.com> wrote:
> >>
> >> Can that be automated? Or does it require manually linking PRs?
> >>
> >> ----- Original Message -----
> >>
> >>
> >>
> >> From: "Libor Krzy?anek" <lkrzyzan at redhat.com> To:
> >> keycloak-dev at lists.jboss.org Sent: Friday, 27 March, 2015 9:31:48 AM
> >> Subject: [keycloak-dev] Keycloak JIRA - github commits sync
> >>
> >> Hi there,
> >> I think it?s very useful to have configured jira project to sync issues
> >> with
> >> commits.
> >>
> >> For example I would very quickly see how Stian implemented this
> >> https://issues.jboss.org/browse/KEYCLOAK-1137 WDYT?
> >>
> >> Thanks,
> >>
> >> Libor Krzy?anek
> >> jboss.org Development Team
> >>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> _______________________________________________
> >> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >> --
> >> Vlastimil Elias
> >> Principal Software Engineer
> >> jboss.org Development Team
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> Vlastimil Elias
> Principal Software Engineer
> jboss.org Development Team
> 
> 


From mposolda at redhat.com  Mon Apr 20 10:04:53 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Apr 2015 16:04:53 +0200
Subject: [keycloak-dev] Persistent grants - step 1
In-Reply-To: <277041367.3068646.1429508203368.JavaMail.zimbra@redhat.com>
References: <5530FD5E.1040106@redhat.com>
	<277041367.3068646.1429508203368.JavaMail.zimbra@redhat.com>
Message-ID: <55350785.4050904@redhat.com>

On 20.4.2015 07:36, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, April 17, 2015 2:32:30 PM
>> Subject: [keycloak-dev] Persistent grants - step 1
>>
>> I've sent startup PR for persistent grants. I've added
>> GrantedConsentModel (is it good name?) to track the roles and protocol
>> mappers user granted on consent screen. Consent screen is not displayed
>> if user already approved roles and protocol mappers before. There is
>> also new "Access" tab in account management where can user see
>> previously granted consents and revoke them for particular client. Is
>> "Access" good name for the tab?
> UserConsentModel?
That's better indeed:-)
I will rename it.

>
> I'd rather call the page in account management 'Applications' tab. One thing I'd like us to add is a list of applications a user can access. It makes more sense to me to have a single place to view everything related to applications (which are available, what access do they have, what sessions are they logged-in to, etc..) than having multiple pages.
Tricky is what exactly means "which applications are available" . 
Currently user can retrieve accessToken for any "confidential" or 
"public" application in the realm. And even if user doesn't have any 
roles or  scopes (access token would have both fields realmAccess and 
resourceAccess empty), the access token could be still usable though.

For example our ServerInfoAdminResource endpoint currently allows to be 
authenticated with any accessToken for any client and it doesn't require 
any roles available (which is probably not correct behaviour I guess, 
but that's another issue though...)

>
>> There is still some work and I will continue if you don't have any
>> comments to the current impl. Remaining TODO is:
>> - representations
>> - Mongo model (for now I have just JPA. I hope that "file" model could
>> be skipped for now?)
>> - More automated tests
>>
>> Some additional things to discuss:
>> - I would like to add
>> ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String>
>> with Ids of protocolMappers similarly like current getRoles/setRoles).
>> There is one small issue that protocolMappers are actually always
>> computed from the ClientModel, which means that there could be
>> theoreticallly different protocolMappers displayed to user and then
>> later saved to persistent model. Also later we want to add support for
>> "scope" parameter, which means that protocolMappers on the consent
>> screen could be really different than protocolMappers from the
>> ClientModel. Any objections against it?
>>
>> - It may be good to add ClientModel.setDescription/getDescription, so on
>> the consent screen and in Account management Access page is displayed
>> the more proper (and localized) description of the client instead of
>> clientId (ie. "Have User Privileges in ThirdParty Application" instead
>> of "Have User Privileges in third-party"). Any objections against it?
> +1 To add, but call it ClientModel.get/setName instead. This makes me think that we need a way to manage localized labels through the console. If someone sets name of a client to ${myClient} then they should also be able to add translations to it through the admin console. That's something to implement later though.
hmm... Actually on RoleModel, there is "setDescription/getDescription" 
used as localized field, so I wonder if ClientModel shouldn't be 
consistent with that?

I agree with translations of clients, roles and protocol mappers 
available from admin console. I've proposed that too couple of months ago.

Also I wonder if we should have single "messages_*.properties" scoped to 
the whole Keycloak (theme) instead of separate messages.properties file 
per each theme type? Because there are many keys duplicated per both 
"login" and "account" theme type (and there will be even more if we ever 
add localization for admin console). Classic example are protocol mapper 
or roles descriptions (firstName, lastName, ...)

Marek
>
>> - There is bit related issue
>> https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all
>> sessions" in Account management doesn't propagate logout to the apps.
>> Currently I invalidate clientSessions of particular client and user
>> during revoke, but also don't propagate it to the applications. I would
>> like to change that and propagate it and also fix KEYCLOAK-1216  at the
>> same time. There will be still small issue for JS applications, because
>> when just clientSession of JS application is revoked, the logout won't
>> be propagated to the actual application because KEYCLOAK_SESSION cookie
>> is still valid. So for JS applications, the application will be really
>> logged later when accessToken expires. Any objections against it? Any
>> idea how to propagate revoke to JS applications?
> Assuming 1216 is the way it's work all along, let's postpone that. Same goes for propagating "consent revocation" to apps, jira it and postpone to next release.
>
>> Thanks,
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Mon Apr 20 10:29:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 20 Apr 2015 10:29:26 -0400 (EDT)
Subject: [keycloak-dev] Persistent grants - step 1
In-Reply-To: <55350785.4050904@redhat.com>
References: <5530FD5E.1040106@redhat.com>
	<277041367.3068646.1429508203368.JavaMail.zimbra@redhat.com>
	<55350785.4050904@redhat.com>
Message-ID: <929254461.3416564.1429540166307.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, April 20, 2015 4:04:53 PM
> Subject: Re: [keycloak-dev] Persistent grants - step 1
> 
> On 20.4.2015 07:36, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, April 17, 2015 2:32:30 PM
> >> Subject: [keycloak-dev] Persistent grants - step 1
> >>
> >> I've sent startup PR for persistent grants. I've added
> >> GrantedConsentModel (is it good name?) to track the roles and protocol
> >> mappers user granted on consent screen. Consent screen is not displayed
> >> if user already approved roles and protocol mappers before. There is
> >> also new "Access" tab in account management where can user see
> >> previously granted consents and revoke them for particular client. Is
> >> "Access" good name for the tab?
> > UserConsentModel?
> That's better indeed:-)
> I will rename it.
> 
> >
> > I'd rather call the page in account management 'Applications' tab. One
> > thing I'd like us to add is a list of applications a user can access. It
> > makes more sense to me to have a single place to view everything related
> > to applications (which are available, what access do they have, what
> > sessions are they logged-in to, etc..) than having multiple pages.
> Tricky is what exactly means "which applications are available" .
> Currently user can retrieve accessToken for any "confidential" or
> "public" application in the realm. And even if user doesn't have any
> roles or  scopes (access token would have both fields realmAccess and
> resourceAccess empty), the access token could be still usable though.
> 
> For example our ServerInfoAdminResource endpoint currently allows to be
> authenticated with any accessToken for any client and it doesn't require
> any roles available (which is probably not correct behaviour I guess,
> but that's another issue though...)

You're focusing to much on a corner-case. A client that has a base-url and has a role or scope on at least one of the users roles is sufficient. If that doesn't work for a "special" app it can be solved by simply adding a fictitious role.

ServerInfoAdminResource should probably require at least one admin role to be present, can you jira?

> 
> >
> >> There is still some work and I will continue if you don't have any
> >> comments to the current impl. Remaining TODO is:
> >> - representations
> >> - Mongo model (for now I have just JPA. I hope that "file" model could
> >> be skipped for now?)
> >> - More automated tests
> >>
> >> Some additional things to discuss:
> >> - I would like to add
> >> ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String>
> >> with Ids of protocolMappers similarly like current getRoles/setRoles).
> >> There is one small issue that protocolMappers are actually always
> >> computed from the ClientModel, which means that there could be
> >> theoreticallly different protocolMappers displayed to user and then
> >> later saved to persistent model. Also later we want to add support for
> >> "scope" parameter, which means that protocolMappers on the consent
> >> screen could be really different than protocolMappers from the
> >> ClientModel. Any objections against it?
> >>
> >> - It may be good to add ClientModel.setDescription/getDescription, so on
> >> the consent screen and in Account management Access page is displayed
> >> the more proper (and localized) description of the client instead of
> >> clientId (ie. "Have User Privileges in ThirdParty Application" instead
> >> of "Have User Privileges in third-party"). Any objections against it?
> > +1 To add, but call it ClientModel.get/setName instead. This makes me think
> > that we need a way to manage localized labels through the console. If
> > someone sets name of a client to ${myClient} then they should also be able
> > to add translations to it through the admin console. That's something to
> > implement later though.
> hmm... Actually on RoleModel, there is "setDescription/getDescription"
> used as localized field, so I wonder if ClientModel shouldn't be
> consistent with that?

I disagree. For a role you want to "describe" to the user what the application is requesting access to. In this case the name is meaningless. For example it makes more sense on the consent screen to display "Read your emails" than "Read Email". 

For a app/client it's the name you want to display. For example "ACME Email Readers" makes more sense then "An application that can read emails". There may be a case for adding a description as well to a client (for example to display in account management), but that can be done later if we need to.

> 
> I agree with translations of clients, roles and protocol mappers
> available from admin console. I've proposed that too couple of months ago.

Maybe one day we have time to implement it ;)

> 
> Also I wonder if we should have single "messages_*.properties" scoped to
> the whole Keycloak (theme) instead of separate messages.properties file
> per each theme type? Because there are many keys duplicated per both
> "login" and "account" theme type (and there will be even more if we ever
> add localization for admin console). Classic example are protocol mapper
> or roles descriptions (firstName, lastName, ...)

Same answer as above - it probably makes more sense, but would have to be done later. Actually it probably makes sense to have message bundles completely detached from themes altogether.

> 
> Marek
> >
> >> - There is bit related issue
> >> https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all
> >> sessions" in Account management doesn't propagate logout to the apps.
> >> Currently I invalidate clientSessions of particular client and user
> >> during revoke, but also don't propagate it to the applications. I would
> >> like to change that and propagate it and also fix KEYCLOAK-1216  at the
> >> same time. There will be still small issue for JS applications, because
> >> when just clientSession of JS application is revoked, the logout won't
> >> be propagated to the actual application because KEYCLOAK_SESSION cookie
> >> is still valid. So for JS applications, the application will be really
> >> logged later when accessToken expires. Any objections against it? Any
> >> idea how to propagate revoke to JS applications?
> > Assuming 1216 is the way it's work all along, let's postpone that. Same
> > goes for propagating "consent revocation" to apps, jira it and postpone to
> > next release.
> >
> >> Thanks,
> >> Marek
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From mposolda at redhat.com  Mon Apr 20 10:57:19 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 20 Apr 2015 16:57:19 +0200
Subject: [keycloak-dev] Persistent grants - step 1
In-Reply-To: <929254461.3416564.1429540166307.JavaMail.zimbra@redhat.com>
References: <5530FD5E.1040106@redhat.com>
	<277041367.3068646.1429508203368.JavaMail.zimbra@redhat.com>
	<55350785.4050904@redhat.com>
	<929254461.3416564.1429540166307.JavaMail.zimbra@redhat.com>
Message-ID: <553513CF.2000104@redhat.com>

On 20.4.2015 16:29, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, April 20, 2015 4:04:53 PM
>> Subject: Re: [keycloak-dev] Persistent grants - step 1
>>
>> On 20.4.2015 07:36, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, April 17, 2015 2:32:30 PM
>>>> Subject: [keycloak-dev] Persistent grants - step 1
>>>>
>>>> I've sent startup PR for persistent grants. I've added
>>>> GrantedConsentModel (is it good name?) to track the roles and protocol
>>>> mappers user granted on consent screen. Consent screen is not displayed
>>>> if user already approved roles and protocol mappers before. There is
>>>> also new "Access" tab in account management where can user see
>>>> previously granted consents and revoke them for particular client. Is
>>>> "Access" good name for the tab?
>>> UserConsentModel?
>> That's better indeed:-)
>> I will rename it.
>>
>>> I'd rather call the page in account management 'Applications' tab. One
>>> thing I'd like us to add is a list of applications a user can access. It
>>> makes more sense to me to have a single place to view everything related
>>> to applications (which are available, what access do they have, what
>>> sessions are they logged-in to, etc..) than having multiple pages.
>> Tricky is what exactly means "which applications are available" .
>> Currently user can retrieve accessToken for any "confidential" or
>> "public" application in the realm. And even if user doesn't have any
>> roles or  scopes (access token would have both fields realmAccess and
>> resourceAccess empty), the access token could be still usable though.
>>
>> For example our ServerInfoAdminResource endpoint currently allows to be
>> authenticated with any accessToken for any client and it doesn't require
>> any roles available (which is probably not correct behaviour I guess,
>> but that's another issue though...)
> You're focusing to much on a corner-case. A client that has a base-url and has a role or scope on at least one of the users roles is sufficient. If that doesn't work for a "special" app it can be solved by simply adding a fictitious role.
yeah, focusing on corner case is maybe one of my issues :-)

I will do the way you mentioned.
>
> ServerInfoAdminResource should probably require at least one admin role to be present, can you jira?
https://issues.jboss.org/browse/KEYCLOAK-1218
>
>>>> There is still some work and I will continue if you don't have any
>>>> comments to the current impl. Remaining TODO is:
>>>> - representations
>>>> - Mongo model (for now I have just JPA. I hope that "file" model could
>>>> be skipped for now?)
>>>> - More automated tests
>>>>
>>>> Some additional things to discuss:
>>>> - I would like to add
>>>> ClientSessionModel.setProtocolMappers/getProtocolMappers (Set<String>
>>>> with Ids of protocolMappers similarly like current getRoles/setRoles).
>>>> There is one small issue that protocolMappers are actually always
>>>> computed from the ClientModel, which means that there could be
>>>> theoreticallly different protocolMappers displayed to user and then
>>>> later saved to persistent model. Also later we want to add support for
>>>> "scope" parameter, which means that protocolMappers on the consent
>>>> screen could be really different than protocolMappers from the
>>>> ClientModel. Any objections against it?
>>>>
>>>> - It may be good to add ClientModel.setDescription/getDescription, so on
>>>> the consent screen and in Account management Access page is displayed
>>>> the more proper (and localized) description of the client instead of
>>>> clientId (ie. "Have User Privileges in ThirdParty Application" instead
>>>> of "Have User Privileges in third-party"). Any objections against it?
>>> +1 To add, but call it ClientModel.get/setName instead. This makes me think
>>> that we need a way to manage localized labels through the console. If
>>> someone sets name of a client to ${myClient} then they should also be able
>>> to add translations to it through the admin console. That's something to
>>> implement later though.
>> hmm... Actually on RoleModel, there is "setDescription/getDescription"
>> used as localized field, so I wonder if ClientModel shouldn't be
>> consistent with that?
> I disagree. For a role you want to "describe" to the user what the application is requesting access to. In this case the name is meaningless. For example it makes more sense on the consent screen to display "Read your emails" than "Read Email".
>
> For a app/client it's the name you want to display. For example "ACME Email Readers" makes more sense then "An application that can read emails". There may be a case for adding a description as well to a client (for example to display in account management), but that can be done later if we need to.
ok, makes sense
>
>> I agree with translations of clients, roles and protocol mappers
>> available from admin console. I've proposed that too couple of months ago.
> Maybe one day we have time to implement it ;)
>
>> Also I wonder if we should have single "messages_*.properties" scoped to
>> the whole Keycloak (theme) instead of separate messages.properties file
>> per each theme type? Because there are many keys duplicated per both
>> "login" and "account" theme type (and there will be even more if we ever
>> add localization for admin console). Classic example are protocol mapper
>> or roles descriptions (firstName, lastName, ...)
> Same answer as above - it probably makes more sense, but would have to be done later. Actually it probably makes sense to have message bundles completely detached from themes altogether.

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

Single file is also more friendly to localization community contributors 
IMO. They don't need to translate same things twice and it will help to 
avoid the situation when contributor translates just messages for  
"login" but miss the "account" or "email".

Marek
>> Marek
>>>> - There is bit related issue
>>>> https://issues.jboss.org/browse/KEYCLOAK-1216 that click on "Logout all
>>>> sessions" in Account management doesn't propagate logout to the apps.
>>>> Currently I invalidate clientSessions of particular client and user
>>>> during revoke, but also don't propagate it to the applications. I would
>>>> like to change that and propagate it and also fix KEYCLOAK-1216  at the
>>>> same time. There will be still small issue for JS applications, because
>>>> when just clientSession of JS application is revoked, the logout won't
>>>> be propagated to the actual application because KEYCLOAK_SESSION cookie
>>>> is still valid. So for JS applications, the application will be really
>>>> logged later when accessToken expires. Any objections against it? Any
>>>> idea how to propagate revoke to JS applications?
>>> Assuming 1216 is the way it's work all along, let's postpone that. Same
>>> goes for propagating "consent revocation" to apps, jira it and postpone to
>>> next release.
>>>
>>>> Thanks,
>>>> Marek
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>


From leonardo.zanivan at gmail.com  Mon Apr 20 18:50:44 2015
From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan)
Date: Mon, 20 Apr 2015 22:50:44 +0000
Subject: [keycloak-dev] KeycloakSecurityContext serialization issue
Message-ID: <CA+sftsB8w6F48Neqx+GzGrMvH6Pr+tS7mpBMfSx=U=MCjREfDw@mail.gmail.com>

Hi,

I'm facing a problem while deserializing KeycloakSecurityContext of a Basic
Auth KeycloakAccount.

KeycloakSecurityContext stores Basic Auth base64 token instead of Access
Token, so deserialization code fail!

*String[] parts = encoded.split("\\."); if (parts.length < 2 ||
parts.length > 3) throw new IllegalArgumentException("Parsing error");*
https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/KeycloakSecurityContext.java
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150420/5bc37c91/attachment.html 

From srossillo at smartling.com  Mon Apr 20 19:02:28 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 20 Apr 2015 19:02:28 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
Message-ID: <2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>

Hi,

There are two different approaches here. The project I mentioned still relies on a Keycloak adapter being present in the servlet container. It?s not quite the final product I need but it would be useful to people who can declare their protected resources in web.xml.

What I?m working on now is a Keycloak adapter-less Spring Security integration. Basically, it?s a Keycloak Spring Security Adapter that can stand on it?s own and protect resources based on the Spring Security configuration. It?s this latter implementation that I believe has the most value.

Question for you: Do you want to see both approaches covered or is one approach more in line with the Keycloak project?s goals?

In my option, the latter, Keycloak Spring Security Adapter, is of more value, but please let me know your thoughts.

Thanks in advance,
Scott


> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> If you can prepare a PR for it that'd be great. Please add a 'spring-security' module within the integration module where all the other adapters live. Also, to create a distribution archive for the adapter please add a module inside distribution that packages it up (look at existing modules there for a reference).
> 
> ----- Original Message -----
>> From: "Scott Rossillo" <srossillo at smartling.com>
>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, April 16, 2015 3:08:13 PM
>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>> 
>> Good morning,
>> 
>> As I mentioned a few days ago on the users mailing list, we developed an
>> integration between the Keycloak Adapter and Spring Security. The
>> announcement can be found here:
>> 
>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>> 
>> The code is here:
>> http://smartling.github.io/spring-security-keycloak/
>> Would you be interested in either:
>> 1. Us contributing the code to the Keycloak project or
>> 2. You integrating the code into the Keycloak project
>> 
>> We released the code under the Apache 2.0 license to be compatible with the
>> Keycloak project. Let me know your thoughts.
>> Best,
>> Scott
>> 
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From stian at redhat.com  Tue Apr 21 02:47:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 21 Apr 2015 02:47:35 -0400 (EDT)
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
Message-ID: <1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>

It's been years since I last looked at Spring, so I'm not the person to ask ;)

It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.

----- Original Message -----
> From: "Scott Rossillo" <srossillo at smartling.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 21 April, 2015 1:02:28 AM
> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
> 
> Hi,
> 
> There are two different approaches here. The project I mentioned still relies
> on a Keycloak adapter being present in the servlet container. It?s not quite
> the final product I need but it would be useful to people who can declare
> their protected resources in web.xml.
> 
> What I?m working on now is a Keycloak adapter-less Spring Security
> integration. Basically, it?s a Keycloak Spring Security Adapter that can
> stand on it?s own and protect resources based on the Spring Security
> configuration. It?s this latter implementation that I believe has the most
> value.
> 
> Question for you: Do you want to see both approaches covered or is one
> approach more in line with the Keycloak project?s goals?
> 
> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
> but please let me know your thoughts.
> 
> Thanks in advance,
> Scott
> 
> 
> > On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
> > 
> > If you can prepare a PR for it that'd be great. Please add a
> > 'spring-security' module within the integration module where all the other
> > adapters live. Also, to create a distribution archive for the adapter
> > please add a module inside distribution that packages it up (look at
> > existing modules there for a reference).
> > 
> > ----- Original Message -----
> >> From: "Scott Rossillo" <srossillo at smartling.com>
> >> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, April 16, 2015 3:08:13 PM
> >> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
> >> 
> >> Good morning,
> >> 
> >> As I mentioned a few days ago on the users mailing list, we developed an
> >> integration between the Keycloak Adapter and Spring Security. The
> >> announcement can be found here:
> >> 
> >> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
> >> 
> >> The code is here:
> >> http://smartling.github.io/spring-security-keycloak/
> >> Would you be interested in either:
> >> 1. Us contributing the code to the Keycloak project or
> >> 2. You integrating the code into the Keycloak project
> >> 
> >> We released the code under the Apache 2.0 license to be compatible with
> >> the
> >> Keycloak project. Let me know your thoughts.
> >> Best,
> >> Scott
> >> 
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
>


From mposolda at redhat.com  Tue Apr 21 03:17:00 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 21 Apr 2015 09:17:00 +0200
Subject: [keycloak-dev] KeycloakSecurityContext serialization issue
In-Reply-To: <CA+sftsB8w6F48Neqx+GzGrMvH6Pr+tS7mpBMfSx=U=MCjREfDw@mail.gmail.com>
References: <CA+sftsB8w6F48Neqx+GzGrMvH6Pr+tS7mpBMfSx=U=MCjREfDw@mail.gmail.com>
Message-ID: <5535F96C.8060107@redhat.com>

That's strange, serialization and deserialization of 
KeycloakSecurityContext should work fine. KeycloakSecurityContext 
actually uses java custom serialization (it implements writeObject and 
readObject methods). So during deserialization it calls readObject and 
creates AccessToken and IDToken from the base64 encoded token. This 
works fine in cluster and we also have the test for it: 
https://github.com/keycloak/keycloak/blob/master/core/src/test/java/org/keycloak/SkeletonKeyTokenTest.java#L58 
.

If you still seeing issues and you think that it's bug, feel free to 
create JIRA. But please add the exact steps to reproduce to the JIRA.

Thanks,
Marek

On 21.4.2015 00:50, Leonardo Loch Zanivan wrote:
> Hi,
>
> I'm facing a problem while deserializing KeycloakSecurityContext of a 
> Basic Auth KeycloakAccount.
>
> KeycloakSecurityContext stores Basic Auth base64 token instead of 
> Access Token, so deserialization code fail!
>
> *String[] parts = encoded.split("\\."); if (parts.length < 2 || 
> parts.length > 3) throw new IllegalArgumentException("Parsing error");*
> https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/KeycloakSecurityContext.java
>
>
> _______________________________________________
> 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/20150421/3e2c5ab8/attachment.html 

From bburke at redhat.com  Tue Apr 21 10:53:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Apr 2015 10:53:55 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
	<1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
Message-ID: <55366483.40809@redhat.com>

FYI, Our common adapter module is a bit convoluted as it is shared 
between different versions of Jetty, Tomcat, JBoss, and Wildfly who all 
do security a bit differently.  A pure Spring adapter would be great, 
but we have zero experience with Spring Security.  I've done some 
component integration work with core Spring awhile back, but nothing for 
years.

On 4/21/2015 2:47 AM, Stian Thorgersen wrote:
> It's been years since I last looked at Spring, so I'm not the person to ask ;)
>
> It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.
>
> ----- Original Message -----
>> From: "Scott Rossillo" <srossillo at smartling.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 21 April, 2015 1:02:28 AM
>> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
>>
>> Hi,
>>
>> There are two different approaches here. The project I mentioned still relies
>> on a Keycloak adapter being present in the servlet container. It?s not quite
>> the final product I need but it would be useful to people who can declare
>> their protected resources in web.xml.
>>
>> What I?m working on now is a Keycloak adapter-less Spring Security
>> integration. Basically, it?s a Keycloak Spring Security Adapter that can
>> stand on it?s own and protect resources based on the Spring Security
>> configuration. It?s this latter implementation that I believe has the most
>> value.
>>
>> Question for you: Do you want to see both approaches covered or is one
>> approach more in line with the Keycloak project?s goals?
>>
>> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
>> but please let me know your thoughts.
>>
>> Thanks in advance,
>> Scott
>>
>>
>>> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>>
>>> If you can prepare a PR for it that'd be great. Please add a
>>> 'spring-security' module within the integration module where all the other
>>> adapters live. Also, to create a distribution archive for the adapter
>>> please add a module inside distribution that packages it up (look at
>>> existing modules there for a reference).
>>>
>>> ----- Original Message -----
>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Thursday, April 16, 2015 3:08:13 PM
>>>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>
>>>> Good morning,
>>>>
>>>> As I mentioned a few days ago on the users mailing list, we developed an
>>>> integration between the Keycloak Adapter and Spring Security. The
>>>> announcement can be found here:
>>>>
>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>>>>
>>>> The code is here:
>>>> http://smartling.github.io/spring-security-keycloak/
>>>> Would you be interested in either:
>>>> 1. Us contributing the code to the Keycloak project or
>>>> 2. You integrating the code into the Keycloak project
>>>>
>>>> We released the code under the Apache 2.0 license to be compatible with
>>>> the
>>>> Keycloak project. Let me know your thoughts.
>>>> Best,
>>>> Scott
>>>>
>>>> _______________________________________________
>>>> 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 srossillo at smartling.com  Tue Apr 21 10:54:08 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 21 Apr 2015 10:54:08 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
	<1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
Message-ID: <AE9B48E2-BDF7-4711-A852-180DE52A862E@smartling.com>

Yes, the pure Spring Security adapter will heavily use adapter-core and be configurable with keycloak.json by default.

Hope to have a PR at end of week for discussion.

Best,
Scott

> On Apr 21, 2015, at 2:47 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> It's been years since I last looked at Spring, so I'm not the person to ask ;)
> 
> It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.
> 
> ----- Original Message -----
>> From: "Scott Rossillo" <srossillo at smartling.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 21 April, 2015 1:02:28 AM
>> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
>> 
>> Hi,
>> 
>> There are two different approaches here. The project I mentioned still relies
>> on a Keycloak adapter being present in the servlet container. It?s not quite
>> the final product I need but it would be useful to people who can declare
>> their protected resources in web.xml.
>> 
>> What I?m working on now is a Keycloak adapter-less Spring Security
>> integration. Basically, it?s a Keycloak Spring Security Adapter that can
>> stand on it?s own and protect resources based on the Spring Security
>> configuration. It?s this latter implementation that I believe has the most
>> value.
>> 
>> Question for you: Do you want to see both approaches covered or is one
>> approach more in line with the Keycloak project?s goals?
>> 
>> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
>> but please let me know your thoughts.
>> 
>> Thanks in advance,
>> Scott
>> 
>> 
>>> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>> 
>>> If you can prepare a PR for it that'd be great. Please add a
>>> 'spring-security' module within the integration module where all the other
>>> adapters live. Also, to create a distribution archive for the adapter
>>> please add a module inside distribution that packages it up (look at
>>> existing modules there for a reference).
>>> 
>>> ----- Original Message -----
>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Thursday, April 16, 2015 3:08:13 PM
>>>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>>>> 
>>>> Good morning,
>>>> 
>>>> As I mentioned a few days ago on the users mailing list, we developed an
>>>> integration between the Keycloak Adapter and Spring Security. The
>>>> announcement can be found here:
>>>> 
>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>>>> 
>>>> The code is here:
>>>> http://smartling.github.io/spring-security-keycloak/
>>>> Would you be interested in either:
>>>> 1. Us contributing the code to the Keycloak project or
>>>> 2. You integrating the code into the Keycloak project
>>>> 
>>>> We released the code under the Apache 2.0 license to be compatible with
>>>> the
>>>> Keycloak project. Let me know your thoughts.
>>>> Best,
>>>> Scott
>>>> 
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> 



From srossillo at smartling.com  Tue Apr 21 11:19:21 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 21 Apr 2015 11:19:21 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <55366483.40809@redhat.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
	<1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
	<55366483.40809@redhat.com>
Message-ID: <BE40EC4C-EB58-4F04-8DC7-667EAC8F7F9A@smartling.com>

Hi Bill,

I?ll try to get some code out soon so we can review. The adapter core does take care of a lot of the integration with KC and verification, which can be reused. The main component from adapter core that?s helpful is RequestAuthenticator, which means I'll implement a few abstract methods, and provide implementations of HttpFacade and AdapterTokenStore.

The main Spring classes for authentication are an AuthenticationProcessingFilter and an AuthenticationProvider. The AuthenticationProcessingFilter will delegate authentication and authorization requests to an implementation of RequestAuthenticator and the AuthenticationProcessingFilter basically votes on whether or not to accept the authentication.

If I was going to do this without RequestAuthenticator, I may as well write a generic Spring Security OIDC client, but that would be ton more work and would be more difficult to configure. I like how the adapters let users get started quickly, by adding a library and inserting the generated keycloak.json file into their deployment. The main goal of the Kyecloak Spring Security adapter is to eliminate the requirement that we use web.xml security constraints and the need for a container specific adapter.

Spring Security is a lot more flexible than the servlet security spec on what endpoints should be protected and how. A lot of Spring Security users are accustomed to that flexibility and I'd like to bring that to Keycloak while maintaining your adapter deployment simplicity.

~ Scott


> On Apr 21, 2015, at 10:53 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> FYI, Our common adapter module is a bit convoluted as it is shared 
> between different versions of Jetty, Tomcat, JBoss, and Wildfly who all 
> do security a bit differently.  A pure Spring adapter would be great, 
> but we have zero experience with Spring Security.  I've done some 
> component integration work with core Spring awhile back, but nothing for 
> years.
> 
> On 4/21/2015 2:47 AM, Stian Thorgersen wrote:
>> It's been years since I last looked at Spring, so I'm not the person to ask ;)
>> 
>> It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.
>> 
>> ----- Original Message -----
>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, 21 April, 2015 1:02:28 AM
>>> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
>>> 
>>> Hi,
>>> 
>>> There are two different approaches here. The project I mentioned still relies
>>> on a Keycloak adapter being present in the servlet container. It?s not quite
>>> the final product I need but it would be useful to people who can declare
>>> their protected resources in web.xml.
>>> 
>>> What I?m working on now is a Keycloak adapter-less Spring Security
>>> integration. Basically, it?s a Keycloak Spring Security Adapter that can
>>> stand on it?s own and protect resources based on the Spring Security
>>> configuration. It?s this latter implementation that I believe has the most
>>> value.
>>> 
>>> Question for you: Do you want to see both approaches covered or is one
>>> approach more in line with the Keycloak project?s goals?
>>> 
>>> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
>>> but please let me know your thoughts.
>>> 
>>> Thanks in advance,
>>> Scott
>>> 
>>> 
>>>> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>>> 
>>>> If you can prepare a PR for it that'd be great. Please add a
>>>> 'spring-security' module within the integration module where all the other
>>>> adapters live. Also, to create a distribution archive for the adapter
>>>> please add a module inside distribution that packages it up (look at
>>>> existing modules there for a reference).
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Thursday, April 16, 2015 3:08:13 PM
>>>>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>> 
>>>>> Good morning,
>>>>> 
>>>>> As I mentioned a few days ago on the users mailing list, we developed an
>>>>> integration between the Keycloak Adapter and Spring Security. The
>>>>> announcement can be found here:
>>>>> 
>>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>>>>> 
>>>>> The code is here:
>>>>> http://smartling.github.io/spring-security-keycloak/
>>>>> Would you be interested in either:
>>>>> 1. Us contributing the code to the Keycloak project or
>>>>> 2. You integrating the code into the Keycloak project
>>>>> 
>>>>> We released the code under the Apache 2.0 license to be compatible with
>>>>> the
>>>>> Keycloak project. Let me know your thoughts.
>>>>> Best,
>>>>> Scott
>>>>> 
>>>>> _______________________________________________
>>>>> 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 mstrukel at redhat.com  Tue Apr 21 11:36:43 2015
From: mstrukel at redhat.com (Marko Strukelj)
Date: Tue, 21 Apr 2015 11:36:43 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <552D0B88.9090004@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
Message-ID: <1235821228.4518849.1429630603498.JavaMail.zimbra@redhat.com>


> * Installer has to work on EAP 6.x too.

I suppose you only mean it for adapter, not for the server?

Currently auth-server support is only part of wildfly-subsystem, which ATM also contains EAP 6.x support which makes it use deprecated subsystem APIs. Keeping things that way is not a good foundation for the future on top of WildFly 10.

The server / adapter subsystem split will result in wildfly-subsystem become wildfly-server-subsystem, and wildfly-adapter-subsystem. In order to keep things clean we would have to extract EAP 6.x support out into another module.

There is wildfly-as7-subsystem which currently only contains adapter support. Since EAP 6.x is API compatible with AS7 it seems a better place for EAP 6.x parts.


From leonardo.zanivan at gmail.com  Tue Apr 21 11:46:43 2015
From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan)
Date: Tue, 21 Apr 2015 15:46:43 +0000
Subject: [keycloak-dev] KeycloakSecurityContext serialization issue
In-Reply-To: <5535F96C.8060107@redhat.com>
References: <CA+sftsB8w6F48Neqx+GzGrMvH6Pr+tS7mpBMfSx=U=MCjREfDw@mail.gmail.com>
	<5535F96C.8060107@redhat.com>
Message-ID: <CA+sftsApzbypjnguWMEdzfDQk_M2gnPuDf2afv1H522WKVxLMg@mail.gmail.com>

Serialization works fine with BearerRequestAuthentication or
Bearer/DirectLoginModule. The only problem is
BasicAuthRequestAuthentication.

In RequestAuthentication.java, RefreshableKeycloakSecurityContext is
created with Bearer.getTokenString(), but token string has Basic Auth
credentials instead of access token.

I'll create a JIRA for this.

On Tue, Apr 21, 2015 at 4:17 AM Marek Posolda <mposolda at redhat.com> wrote:

>  That's strange, serialization and deserialization of
> KeycloakSecurityContext should work fine. KeycloakSecurityContext actually
> uses java custom serialization (it implements writeObject and readObject
> methods). So during deserialization it calls readObject and creates
> AccessToken and IDToken from the base64 encoded token. This works fine in
> cluster and we also have the test for it:
> https://github.com/keycloak/keycloak/blob/master/core/src/test/java/org/keycloak/SkeletonKeyTokenTest.java#L58
> .
>
> If you still seeing issues and you think that it's bug, feel free to
> create JIRA. But please add the exact steps to reproduce to the JIRA.
>
> Thanks,
> Marek
>
>
> On 21.4.2015 00:50, Leonardo Loch Zanivan wrote:
>
>   Hi,
>
>  I'm facing a problem while deserializing KeycloakSecurityContext of a
> Basic Auth KeycloakAccount.
>
> KeycloakSecurityContext stores Basic Auth base64 token instead of Access
> Token, so deserialization code fail!
>
> *String[] parts = encoded.split("\\."); if (parts.length < 2 ||
> parts.length > 3) throw new IllegalArgumentException("Parsing error");*
>
> https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/KeycloakSecurityContext.java
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150421/ca1e5757/attachment.html 

From leonardo.zanivan at gmail.com  Tue Apr 21 11:55:37 2015
From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan)
Date: Tue, 21 Apr 2015 15:55:37 +0000
Subject: [keycloak-dev] KeycloakSecurityContext serialization issue
In-Reply-To: <CA+sftsApzbypjnguWMEdzfDQk_M2gnPuDf2afv1H522WKVxLMg@mail.gmail.com>
References: <CA+sftsB8w6F48Neqx+GzGrMvH6Pr+tS7mpBMfSx=U=MCjREfDw@mail.gmail.com>
	<5535F96C.8060107@redhat.com>
	<CA+sftsApzbypjnguWMEdzfDQk_M2gnPuDf2afv1H522WKVxLMg@mail.gmail.com>
Message-ID: <CA+sftsD+Q5B3m+q_TmAfhAVLAQ40agDPieuNDrJhAx-GEeAwQA@mail.gmail.com>

ISSUE: https://issues.jboss.org/browse/KEYCLOAK-1222
PR: https://github.com/keycloak/keycloak/pull/1167

I provided a fix with a small modification in
BearerTokenRequestAuthenticator.authenticateToken(HttpFacade exchange,
String tokenString).

Please fix for 1.2 Final.

On Tue, Apr 21, 2015 at 12:46 PM Leonardo Loch Zanivan <
leonardo.zanivan at gmail.com> wrote:

> Serialization works fine with BearerRequestAuthentication or
> Bearer/DirectLoginModule. The only problem is
> BasicAuthRequestAuthentication.
>
> In RequestAuthentication.java, RefreshableKeycloakSecurityContext is
> created with Bearer.getTokenString(), but token string has Basic Auth
> credentials instead of access token.
>
> I'll create a JIRA for this.
>
> On Tue, Apr 21, 2015 at 4:17 AM Marek Posolda <mposolda at redhat.com> wrote:
>
>>  That's strange, serialization and deserialization of
>> KeycloakSecurityContext should work fine. KeycloakSecurityContext actually
>> uses java custom serialization (it implements writeObject and readObject
>> methods). So during deserialization it calls readObject and creates
>> AccessToken and IDToken from the base64 encoded token. This works fine in
>> cluster and we also have the test for it:
>> https://github.com/keycloak/keycloak/blob/master/core/src/test/java/org/keycloak/SkeletonKeyTokenTest.java#L58
>> .
>>
>> If you still seeing issues and you think that it's bug, feel free to
>> create JIRA. But please add the exact steps to reproduce to the JIRA.
>>
>> Thanks,
>> Marek
>>
>>
>> On 21.4.2015 00:50, Leonardo Loch Zanivan wrote:
>>
>>   Hi,
>>
>>  I'm facing a problem while deserializing KeycloakSecurityContext of a
>> Basic Auth KeycloakAccount.
>>
>> KeycloakSecurityContext stores Basic Auth base64 token instead of Access
>> Token, so deserialization code fail!
>>
>> *String[] parts = encoded.split("\\."); if (parts.length < 2 ||
>> parts.length > 3) throw new IllegalArgumentException("Parsing error");*
>>
>> https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/KeycloakSecurityContext.java
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150421/c720b041/attachment.html 

From bburke at redhat.com  Tue Apr 21 13:06:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Apr 2015 13:06:41 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <BE40EC4C-EB58-4F04-8DC7-667EAC8F7F9A@smartling.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
	<1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
	<55366483.40809@redhat.com>
	<BE40EC4C-EB58-4F04-8DC7-667EAC8F7F9A@smartling.com>
Message-ID: <553683A1.9030302@redhat.com>

FYI: Generic OIDC is not enough.  OIDC does not have a SP logout 
callback.  So, the admin console would not be able to remotely logout 
the user.  There's also a few other events that the admin console can 
push to SPs, i.e. Not-before policies, and later on, black/white lists.

On 4/21/2015 11:19 AM, Scott Rossillo wrote:
> Hi Bill,
>
> I?ll try to get some code out soon so we can review. The adapter core does take care of a lot of the integration with KC and verification, which can be reused. The main component from adapter core that?s helpful is RequestAuthenticator, which means I'll implement a few abstract methods, and provide implementations of HttpFacade and AdapterTokenStore.
>
> The main Spring classes for authentication are an AuthenticationProcessingFilter and an AuthenticationProvider. The AuthenticationProcessingFilter will delegate authentication and authorization requests to an implementation of RequestAuthenticator and the AuthenticationProcessingFilter basically votes on whether or not to accept the authentication.
>
> If I was going to do this without RequestAuthenticator, I may as well write a generic Spring Security OIDC client, but that would be ton more work and would be more difficult to configure. I like how the adapters let users get started quickly, by adding a library and inserting the generated keycloak.json file into their deployment. The main goal of the Kyecloak Spring Security adapter is to eliminate the requirement that we use web.xml security constraints and the need for a container specific adapter.
>
> Spring Security is a lot more flexible than the servlet security spec on what endpoints should be protected and how. A lot of Spring Security users are accustomed to that flexibility and I'd like to bring that to Keycloak while maintaining your adapter deployment simplicity.
>
> ~ Scott
>
>
>> On Apr 21, 2015, at 10:53 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> FYI, Our common adapter module is a bit convoluted as it is shared
>> between different versions of Jetty, Tomcat, JBoss, and Wildfly who all
>> do security a bit differently.  A pure Spring adapter would be great,
>> but we have zero experience with Spring Security.  I've done some
>> component integration work with core Spring awhile back, but nothing for
>> years.
>>
>> On 4/21/2015 2:47 AM, Stian Thorgersen wrote:
>>> It's been years since I last looked at Spring, so I'm not the person to ask ;)
>>>
>>> It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.
>>>
>>> ----- Original Message -----
>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, 21 April, 2015 1:02:28 AM
>>>> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>
>>>> Hi,
>>>>
>>>> There are two different approaches here. The project I mentioned still relies
>>>> on a Keycloak adapter being present in the servlet container. It?s not quite
>>>> the final product I need but it would be useful to people who can declare
>>>> their protected resources in web.xml.
>>>>
>>>> What I?m working on now is a Keycloak adapter-less Spring Security
>>>> integration. Basically, it?s a Keycloak Spring Security Adapter that can
>>>> stand on it?s own and protect resources based on the Spring Security
>>>> configuration. It?s this latter implementation that I believe has the most
>>>> value.
>>>>
>>>> Question for you: Do you want to see both approaches covered or is one
>>>> approach more in line with the Keycloak project?s goals?
>>>>
>>>> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
>>>> but please let me know your thoughts.
>>>>
>>>> Thanks in advance,
>>>> Scott
>>>>
>>>>
>>>>> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>
>>>>> If you can prepare a PR for it that'd be great. Please add a
>>>>> 'spring-security' module within the integration module where all the other
>>>>> adapters live. Also, to create a distribution archive for the adapter
>>>>> please add a module inside distribution that packages it up (look at
>>>>> existing modules there for a reference).
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Thursday, April 16, 2015 3:08:13 PM
>>>>>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>>>
>>>>>> Good morning,
>>>>>>
>>>>>> As I mentioned a few days ago on the users mailing list, we developed an
>>>>>> integration between the Keycloak Adapter and Spring Security. The
>>>>>> announcement can be found here:
>>>>>>
>>>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>>>>>>
>>>>>> The code is here:
>>>>>> http://smartling.github.io/spring-security-keycloak/
>>>>>> Would you be interested in either:
>>>>>> 1. Us contributing the code to the Keycloak project or
>>>>>> 2. You integrating the code into the Keycloak project
>>>>>>
>>>>>> We released the code under the Apache 2.0 license to be compatible with
>>>>>> the
>>>>>> Keycloak project. Let me know your thoughts.
>>>>>> Best,
>>>>>> Scott
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>

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

From bburke at redhat.com  Tue Apr 21 13:07:47 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Apr 2015 13:07:47 -0400
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <1235821228.4518849.1429630603498.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1235821228.4518849.1429630603498.JavaMail.zimbra@redhat.com>
Message-ID: <553683E3.9010807@redhat.com>

For the server too.  we have a number of people deploying server on EAP 
6.  IMO, we should probably keep this until EAP 7 is available in beta.

On 4/21/2015 11:36 AM, Marko Strukelj wrote:
>
>> * Installer has to work on EAP 6.x too.
>
> I suppose you only mean it for adapter, not for the server?
>
> Currently auth-server support is only part of wildfly-subsystem, which ATM also contains EAP 6.x support which makes it use deprecated subsystem APIs. Keeping things that way is not a good foundation for the future on top of WildFly 10.
>
> The server / adapter subsystem split will result in wildfly-subsystem become wildfly-server-subsystem, and wildfly-adapter-subsystem. In order to keep things clean we would have to extract EAP 6.x support out into another module.
>
> There is wildfly-as7-subsystem which currently only contains adapter support. Since EAP 6.x is API compatible with AS7 it seems a better place for EAP 6.x parts.
>

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

From srossillo at smartling.com  Tue Apr 21 13:08:33 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Tue, 21 Apr 2015 13:08:33 -0400
Subject: [keycloak-dev] Spring Security for Keycloak Contribution
In-Reply-To: <553683A1.9030302@redhat.com>
References: <CALAqdu8AKL8_jUZ1nm4nK8kTaddmy3+Y6KwZPX=GWX3aE03d+A@mail.gmail.com>
	<1471622835.1223144.1429190698740.JavaMail.zimbra@redhat.com>
	<2207DE96-3E6C-4F59-A713-D0FF7138B8C3@smartling.com>
	<1167791036.3844119.1429598855892.JavaMail.zimbra@redhat.com>
	<55366483.40809@redhat.com>
	<BE40EC4C-EB58-4F04-8DC7-667EAC8F7F9A@smartling.com>
	<553683A1.9030302@redhat.com>
Message-ID: <18217106-7845-4C1C-BF7A-7F4C037A78C4@smartling.com>

Good point, all the more reason to implement as a Keycloak adapter.


> On Apr 21, 2015, at 1:06 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> FYI: Generic OIDC is not enough.  OIDC does not have a SP logout callback.  So, the admin console would not be able to remotely logout the user.  There's also a few other events that the admin console can push to SPs, i.e. Not-before policies, and later on, black/white lists.
> 
> On 4/21/2015 11:19 AM, Scott Rossillo wrote:
>> Hi Bill,
>> 
>> I?ll try to get some code out soon so we can review. The adapter core does take care of a lot of the integration with KC and verification, which can be reused. The main component from adapter core that?s helpful is RequestAuthenticator, which means I'll implement a few abstract methods, and provide implementations of HttpFacade and AdapterTokenStore.
>> 
>> The main Spring classes for authentication are an AuthenticationProcessingFilter and an AuthenticationProvider. The AuthenticationProcessingFilter will delegate authentication and authorization requests to an implementation of RequestAuthenticator and the AuthenticationProcessingFilter basically votes on whether or not to accept the authentication.
>> 
>> If I was going to do this without RequestAuthenticator, I may as well write a generic Spring Security OIDC client, but that would be ton more work and would be more difficult to configure. I like how the adapters let users get started quickly, by adding a library and inserting the generated keycloak.json file into their deployment. The main goal of the Kyecloak Spring Security adapter is to eliminate the requirement that we use web.xml security constraints and the need for a container specific adapter.
>> 
>> Spring Security is a lot more flexible than the servlet security spec on what endpoints should be protected and how. A lot of Spring Security users are accustomed to that flexibility and I'd like to bring that to Keycloak while maintaining your adapter deployment simplicity.
>> 
>> ~ Scott
>> 
>> 
>>> On Apr 21, 2015, at 10:53 AM, Bill Burke <bburke at redhat.com> wrote:
>>> 
>>> FYI, Our common adapter module is a bit convoluted as it is shared
>>> between different versions of Jetty, Tomcat, JBoss, and Wildfly who all
>>> do security a bit differently.  A pure Spring adapter would be great,
>>> but we have zero experience with Spring Security.  I've done some
>>> component integration work with core Spring awhile back, but nothing for
>>> years.
>>> 
>>> On 4/21/2015 2:47 AM, Stian Thorgersen wrote:
>>>> It's been years since I last looked at Spring, so I'm not the person to ask ;)
>>>> 
>>>> It sounds like the pure Spring Security Adapter is the better option. You should at try to use code from integration/adapter-core module as that's used as the core for all our current Java based adapters. Also, it should be configurable by supplying a keycloak.json file.
>>>> 
>>>> ----- Original Message -----
>>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Tuesday, 21 April, 2015 1:02:28 AM
>>>>> Subject: Re: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> There are two different approaches here. The project I mentioned still relies
>>>>> on a Keycloak adapter being present in the servlet container. It?s not quite
>>>>> the final product I need but it would be useful to people who can declare
>>>>> their protected resources in web.xml.
>>>>> 
>>>>> What I?m working on now is a Keycloak adapter-less Spring Security
>>>>> integration. Basically, it?s a Keycloak Spring Security Adapter that can
>>>>> stand on it?s own and protect resources based on the Spring Security
>>>>> configuration. It?s this latter implementation that I believe has the most
>>>>> value.
>>>>> 
>>>>> Question for you: Do you want to see both approaches covered or is one
>>>>> approach more in line with the Keycloak project?s goals?
>>>>> 
>>>>> In my option, the latter, Keycloak Spring Security Adapter, is of more value,
>>>>> but please let me know your thoughts.
>>>>> 
>>>>> Thanks in advance,
>>>>> Scott
>>>>> 
>>>>> 
>>>>>> On Apr 16, 2015, at 9:24 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>> 
>>>>>> If you can prepare a PR for it that'd be great. Please add a
>>>>>> 'spring-security' module within the integration module where all the other
>>>>>> adapters live. Also, to create a distribution archive for the adapter
>>>>>> please add a module inside distribution that packages it up (look at
>>>>>> existing modules there for a reference).
>>>>>> 
>>>>>> ----- Original Message -----
>>>>>>> From: "Scott Rossillo" <srossillo at smartling.com>
>>>>>>> To: "keycloak-dev" <keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Thursday, April 16, 2015 3:08:13 PM
>>>>>>> Subject: [keycloak-dev] Spring Security for Keycloak Contribution
>>>>>>> 
>>>>>>> Good morning,
>>>>>>> 
>>>>>>> As I mentioned a few days ago on the users mailing list, we developed an
>>>>>>> integration between the Keycloak Adapter and Spring Security. The
>>>>>>> announcement can be found here:
>>>>>>> 
>>>>>>> http://lists.jboss.org/pipermail/keycloak-user/2015-April/001992.html
>>>>>>> 
>>>>>>> The code is here:
>>>>>>> http://smartling.github.io/spring-security-keycloak/
>>>>>>> Would you be interested in either:
>>>>>>> 1. Us contributing the code to the Keycloak project or
>>>>>>> 2. You integrating the code into the Keycloak project
>>>>>>> 
>>>>>>> We released the code under the Apache 2.0 license to be compatible with
>>>>>>> the
>>>>>>> Keycloak project. Let me know your thoughts.
>>>>>>> Best,
>>>>>>> Scott
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com



From bburke at redhat.com  Tue Apr 21 17:41:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 21 Apr 2015 17:41:12 -0400
Subject: [keycloak-dev] generic migration?
Message-ID: <5536C3F8.9030101@redhat.com>

Do we have a way to plug in generic version migration?  I need to add a 
ClientModel and a role for that ClientModel.  Right now it looks like I 
have to do it manually for JDBC and Mongo.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Wed Apr 22 03:08:47 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 22 Apr 2015 09:08:47 +0200
Subject: [keycloak-dev] generic migration?
In-Reply-To: <5536C3F8.9030101@redhat.com>
References: <5536C3F8.9030101@redhat.com>
Message-ID: <553748FF.6000202@redhat.com>

We are doing everything manually right now :-\

I don't think we can use ORM as when you migrating the DB, you have the 
codebase with the newest version, but data in database are still in the 
old version. So there are fields in the table in DB, which are not on 
the object in the codebase and viceversa.

I've added MigrationProvider, which is useful for some common migration 
tasks useful for both JPA, Mongo and JSON representations. But not sure 
if it is helpful for your usecase...

Marek

On 21.4.2015 23:41, Bill Burke wrote:
> Do we have a way to plug in generic version migration?  I need to add a
> ClientModel and a role for that ClientModel.  Right now it looks like I
> have to do it manually for JDBC and Mongo.


From stian at redhat.com  Wed Apr 22 05:14:10 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Apr 2015 05:14:10 -0400 (EDT)
Subject: [keycloak-dev] generic migration?
In-Reply-To: <553748FF.6000202@redhat.com>
References: <5536C3F8.9030101@redhat.com> <553748FF.6000202@redhat.com>
Message-ID: <931244049.4673401.1429694050152.JavaMail.zimbra@redhat.com>

Would be nice to add this

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 22 April, 2015 9:08:47 AM
> Subject: Re: [keycloak-dev] generic migration?
> 
> We are doing everything manually right now :-\
> 
> I don't think we can use ORM as when you migrating the DB, you have the
> codebase with the newest version, but data in database are still in the
> old version. So there are fields in the table in DB, which are not on
> the object in the codebase and viceversa.
> 
> I've added MigrationProvider, which is useful for some common migration
> tasks useful for both JPA, Mongo and JSON representations. But not sure
> if it is helpful for your usecase...
> 
> Marek
> 
> On 21.4.2015 23:41, Bill Burke wrote:
> > Do we have a way to plug in generic version migration?  I need to add a
> > ClientModel and a role for that ClientModel.  Right now it looks like I
> > have to do it manually for JDBC and Mongo.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Apr 22 07:27:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 22 Apr 2015 07:27:29 -0400 (EDT)
Subject: [keycloak-dev] Keycloak distribution changes
In-Reply-To: <1235821228.4518849.1429630603498.JavaMail.zimbra@redhat.com>
References: <979837581.18005145.1428992899230.JavaMail.zimbra@redhat.com>
	<552D0B88.9090004@redhat.com>
	<1235821228.4518849.1429630603498.JavaMail.zimbra@redhat.com>
Message-ID: <1402954146.4723348.1429702049018.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marko Strukelj" <mstrukel at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 21 April, 2015 5:36:43 PM
> Subject: Re: [keycloak-dev] Keycloak distribution changes
> 
> 
> > * Installer has to work on EAP 6.x too.
> 
> I suppose you only mean it for adapter, not for the server?
> 
> Currently auth-server support is only part of wildfly-subsystem, which ATM
> also contains EAP 6.x support which makes it use deprecated subsystem APIs.
> Keeping things that way is not a good foundation for the future on top of
> WildFly 10.

The server subsystem needs to support latest stable EAP (6.4) and WildFly (8.2.0.Final). Once WildFly 9.0.0.Final is out we can drop WildFly 8.2.0.Final. Once EAP 7.0 is out we can drop EAP 6.4.

> 
> The server / adapter subsystem split will result in wildfly-subsystem become
> wildfly-server-subsystem, and wildfly-adapter-subsystem. In order to keep
> things clean we would have to extract EAP 6.x support out into another
> module.
> 
> There is wildfly-as7-subsystem which currently only contains adapter support.
> Since EAP 6.x is API compatible with AS7 it seems a better place for EAP 6.x
> parts.

Agreed - wildfly-adapter-subsystem should target WildFly/Undertow, while as7-adapter-subsystem should target EAP/JBossAS

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

From pslegr at redhat.com  Wed Apr 22 11:33:34 2015
From: pslegr at redhat.com (pslegr)
Date: Wed, 22 Apr 2015 17:33:34 +0200
Subject: [keycloak-dev] Keykload and Swagger.io integration
In-Reply-To: <552E4552.7020103@redhat.com>
References: <55251848.7070903@redhat.com>	<1178503542.15056207.1428579045967.JavaMail.zimbra@redhat.com>
	<552E4552.7020103@redhat.com>
Message-ID: <5537BF4E.4000702@redhat.com>



On 15.4.2015 13:02, pslegr wrote:
>
> On 9.4.2015 13:30, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "pslegr" <pslegr at redhat.com>
>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Wednesday, 8 April, 2015 2:00:08 PM
>>> Subject: [keycloak-dev] Keykload and Swagger.io integration
>>>
>>> Hi guys,
>>>
>>> I've found an old thread wrt ${subject} here
>>> http://lists.jboss.org/pipermail/keycloak-dev/2014-May/001842.html
>>> and I wonder, if there was some further research on it.
>>>
>>> I need to integrate Swagger.io and Keycloak
>>>
>>> Anyone tried out already, or having some example to show ?
>> Nope, but if you come up with something we want it :)
> Ok, I will try to design it myself and get back to you, so you can
> reuse it if you want :)
https://github.com/project-ncl/pnc/commit/b85b1ad0a1415751946c57a281c05f7b828c3ad6

It is simple usage of Keycloak JS adapter plus Swagger adding additional 
header via
window.authorizations.add("oauth2", 
newApiKeyAuthorization("Authorization", "Bearer "+keycloak.token, 
"header"));

works quite nice with 'login-required'
I did not deal with logout...

>
> cheers
> Pavel
>>> thanks
>>> Pavel
>>>
>>> _______________________________________________
>>> 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/20150422/0a836a6f/attachment-0001.html 

From stian at redhat.com  Thu Apr 23 01:52:55 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 01:52:55 -0400 (EDT)
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
Message-ID: <1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>

Any comments on this?

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 20 April, 2015 9:08:13 AM
> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> We've already discussed this, but didn't come to a conclusion.
> 
> There's two separate use-cases to consider:
> 
> 1. Authentication
> 2. Offline access
> 
> For simplicity the examples below assumes OpenID Connect, but same logic
> applies to SAML.
> 
> 
> Authentication
> --------------
> In this case user authenticates using an external IdP. After the user has
> authenticated the access and refresh (if available) tokens are stored in
> user session. Tokens are automatically refreshed by Keycloak to support
> brokered log out. In this case an application can only retrieve an access
> token for the identity provider that was used to authenticate the user.
> 
> 
> Offline access
> --------------
> In this case we should add the option "offline access" to the provider
> config. When enabled we add "offline" to the requested scope. When a user
> first logs in or links through account mngmt we store the refresh token (aka
> "offline token") in the user store. As this is a long term token I don't see
> any problems using the user store for it. In this case an application can
> retrieve an access token for the identity provider that was used to
> authenticate the user, but also for an identity providers what have "offline
> access" enabled and there's an token store in the user store. One issue with
> this approach is that brokered log out doesn't work. A potential solution to
> that is that we only request offline access when linking the account, but
> during authentication don't add the offline scope and use the process from
> the first use-case.
> 
> 
> Token retrieval
> ---------------
> We add a "token service" client to Keycloak that has a "retrieve token" role
> for each provider. For an application to be able to retrieve the token the
> user has to have a role mapping on this role and the client has to have a
> scope on it as well. This results in using standard roles, scopes and
> consent screens instead of a different mechanism.
> 
> 
> For 1.2.0 we should only add support for the "Authentication" use case. I
> believe we pretty much already have this as Bill did this to support
> brokered log out. Only thing we need to change is how we manage if a client
> has access to retrieve the token or not. We should just jira the other
> use-case and add if it's requested by users.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Thu Apr 23 05:31:25 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Apr 2015 11:31:25 +0200
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
Message-ID: <5538BBED.2000109@redhat.com>

On 23.4.2015 07:52, Stian Thorgersen wrote:
> Any comments on this?
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 20 April, 2015 9:08:13 AM
>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>> We've already discussed this, but didn't come to a conclusion.
>>
>> There's two separate use-cases to consider:
>>
>> 1. Authentication
>> 2. Offline access
>>
>> For simplicity the examples below assumes OpenID Connect, but same logic
>> applies to SAML.
>>
>>
>> Authentication
>> --------------
>> In this case user authenticates using an external IdP. After the user has
>> authenticated the access and refresh (if available) tokens are stored in
>> user session. Tokens are automatically refreshed by Keycloak to support
>> brokered log out. In this case an application can only retrieve an access
>> token for the identity provider that was used to authenticate the user.
>>
>>
>> Offline access
>> --------------
>> In this case we should add the option "offline access" to the provider
>> config. When enabled we add "offline" to the requested scope. When a user
>> first logs in or links through account mngmt we store the refresh token (aka
>> "offline token") in the user store. As this is a long term token I don't see
>> any problems using the user store for it. In this case an application can
>> retrieve an access token for the identity provider that was used to
>> authenticate the user, but also for an identity providers what have "offline
>> access" enabled and there's an token store in the user store. One issue with
>> this approach is that brokered log out doesn't work. A potential solution to
>> that is that we only request offline access when linking the account, but
>> during authentication don't add the offline scope and use the process from
>> the first use-case.
I believe that brokered logout will work as long as we store the flag on 
UserSession specifying which identity provider was used to authenticate 
the user in particular session?

For example if Google was used to authenticate user and Google offline 
token was obtained during this authentication, then Keycloak logout will 
propagate logout to the Google provider and invalidate Google offline 
token as well. But if Google wasn't used for authenticating user in that 
particular session (user already had offline Google token linked 
previously to his account), then Keycloak logout won't propagate logout 
to the Google and won't invalidate offline token.
>>
>>
>> Token retrieval
>> ---------------
>> We add a "token service" client to Keycloak that has a "retrieve token" role
>> for each provider. For an application to be able to retrieve the token the
>> user has to have a role mapping on this role and the client has to have a
>> scope on it as well. This results in using standard roles, scopes and
>> consent screens instead of a different mechanism.
+1

Marek
>>
>>
>> For 1.2.0 we should only add support for the "Authentication" use case. I
>> believe we pretty much already have this as Bill did this to support
>> brokered log out. Only thing we need to change is how we manage if a client
>> has access to retrieve the token or not. We should just jira the other
>> use-case and add if it's requested by users.
>>
>> _______________________________________________
>> 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 Apr 23 06:40:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 06:40:31 -0400 (EDT)
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <5538BBED.2000109@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
Message-ID: <393990816.5461114.1429785631418.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>, "Bill Burke"
> <bburke at redhat.com>
> Sent: Thursday, 23 April, 2015 11:31:25 AM
> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> On 23.4.2015 07:52, Stian Thorgersen wrote:
> > Any comments on this?
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 20 April, 2015 9:08:13 AM
> >> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> >>
> >> We've already discussed this, but didn't come to a conclusion.
> >>
> >> There's two separate use-cases to consider:
> >>
> >> 1. Authentication
> >> 2. Offline access
> >>
> >> For simplicity the examples below assumes OpenID Connect, but same logic
> >> applies to SAML.
> >>
> >>
> >> Authentication
> >> --------------
> >> In this case user authenticates using an external IdP. After the user has
> >> authenticated the access and refresh (if available) tokens are stored in
> >> user session. Tokens are automatically refreshed by Keycloak to support
> >> brokered log out. In this case an application can only retrieve an access
> >> token for the identity provider that was used to authenticate the user.
> >>
> >>
> >> Offline access
> >> --------------
> >> In this case we should add the option "offline access" to the provider
> >> config. When enabled we add "offline" to the requested scope. When a user
> >> first logs in or links through account mngmt we store the refresh token
> >> (aka
> >> "offline token") in the user store. As this is a long term token I don't
> >> see
> >> any problems using the user store for it. In this case an application can
> >> retrieve an access token for the identity provider that was used to
> >> authenticate the user, but also for an identity providers what have
> >> "offline
> >> access" enabled and there's an token store in the user store. One issue
> >> with
> >> this approach is that brokered log out doesn't work. A potential solution
> >> to
> >> that is that we only request offline access when linking the account, but
> >> during authentication don't add the offline scope and use the process from
> >> the first use-case.
> I believe that brokered logout will work as long as we store the flag on
> UserSession specifying which identity provider was used to authenticate
> the user in particular session?
> 
> For example if Google was used to authenticate user and Google offline
> token was obtained during this authentication, then Keycloak logout will
> propagate logout to the Google provider and invalidate Google offline
> token as well. But if Google wasn't used for authenticating user in that
> particular session (user already had offline Google token linked
> previously to his account), then Keycloak logout won't propagate logout
> to the Google and won't invalidate offline token.

I don't think we should invalidate an offline token on logout. That should only be done by unlinking in the account management.

We could request offline scope online when linking, which is stored in user store. If someone logs in with the same provider we don't request offline and store that token in user session.

> >>
> >>
> >> Token retrieval
> >> ---------------
> >> We add a "token service" client to Keycloak that has a "retrieve token"
> >> role
> >> for each provider. For an application to be able to retrieve the token the
> >> user has to have a role mapping on this role and the client has to have a
> >> scope on it as well. This results in using standard roles, scopes and
> >> consent screens instead of a different mechanism.
> +1
> 
> Marek
> >>
> >>
> >> For 1.2.0 we should only add support for the "Authentication" use case. I
> >> believe we pretty much already have this as Bill did this to support
> >> brokered log out. Only thing we need to change is how we manage if a
> >> client
> >> has access to retrieve the token or not. We should just jira the other
> >> use-case and add if it's requested by users.
> >>
> >> _______________________________________________
> >> 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 fadiabdeen at gmail.com  Thu Apr 23 08:55:00 2015
From: fadiabdeen at gmail.com (Fadi Abdin)
Date: Thu, 23 Apr 2015 08:55:00 -0400
Subject: [keycloak-dev] Implicit Flow
Message-ID: <CABXXV0S9Q3+sMkYODz_Lj7g4=vFAeng7FgSrjjtWcBJvsPdrjQ@mail.gmail.com>

Does anyone know if the OAuth2 implicit flow on keycloak is supported ?

I am trying to retrieve the access_token directly after logging in. Ideally
it should work if you send response_type=token , but it always returns a
code=... no matter what is the response_type ..

Does anyone know how to get this to work or if its even supported ?

Thanks,
Fadi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150423/ab273e85/attachment.html 

From bburke at redhat.com  Thu Apr 23 09:03:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Apr 2015 09:03:07 -0400
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
Message-ID: <5538ED8B.5060106@redhat.com>



On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
> Any comments on this?
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 20 April, 2015 9:08:13 AM
>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>> We've already discussed this, but didn't come to a conclusion.
>>
>> There's two separate use-cases to consider:
>>
>> 1. Authentication
>> 2. Offline access
>>
>> For simplicity the examples below assumes OpenID Connect, but same logic
>> applies to SAML.
>>
>>
>> Authentication
>> --------------
>> In this case user authenticates using an external IdP. After the user has
>> authenticated the access and refresh (if available) tokens are stored in
>> user session. Tokens are automatically refreshed by Keycloak to support
>> brokered log out. In this case an application can only retrieve an access
>> token for the identity provider that was used to authenticate the user.
>>

I don't know if SAML has refresh.  Half the social providers don't either.

I'm a bit wary of automatic background refresh.  Every active 
usersession would have to be polled periodically.  Don't know if that 
would be a big performance issue or not.  Maybe just do on-demand 
refresh checks?

>>
>> Offline access
>> --------------
>> In this case we should add the option "offline access" to the provider
>> config. When enabled we add "offline" to the requested scope. When a user
>> first logs in or links through account mngmt we store the refresh token (aka
>> "offline token") in the user store. As this is a long term token I don't see
>> any problems using the user store for it. In this case an application can
>> retrieve an access token for the identity provider that was used to
>> authenticate the user, but also for an identity providers what have "offline
>> access" enabled and there's an token store in the user store. One issue with
>> this approach is that brokered log out doesn't work. A potential solution to
>> that is that we only request offline access when linking the account, but
>> during authentication don't add the offline scope and use the process from
>> the first use-case.
>>

If offline access is persisted, couldn't the external token still be 
stored in the persisted UserSession?


>>
>> Token retrieval
>> ---------------
>> We add a "token service" client to Keycloak that has a "retrieve token" role
>> for each provider. For an application to be able to retrieve the token the
>> user has to have a role mapping on this role and the client has to have a
>> scope on it as well. This results in using standard roles, scopes and
>> consent screens instead of a different mechanism.
>>

I implemented it as one master role for reading the external token. 
Wouldn't this be better?  Isn't one role per provider too fine grained? 
  Think about social, you'd have to assign 6-7 different roles to the 
user.  Although doing a role per provider would definitely make it 
easier to implement as I wouldn't have to implement the migration stuff 
I emailed about the other day.

BTW, I'm almost done with this. I ran into a problem testing where I 
uncovered a brokered logout bug and I've spent most of my time fixing that.


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

From stian at redhat.com  Thu Apr 23 09:03:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 09:03:33 -0400 (EDT)
Subject: [keycloak-dev] Implicit Flow
In-Reply-To: <CABXXV0S9Q3+sMkYODz_Lj7g4=vFAeng7FgSrjjtWcBJvsPdrjQ@mail.gmail.com>
References: <CABXXV0S9Q3+sMkYODz_Lj7g4=vFAeng7FgSrjjtWcBJvsPdrjQ@mail.gmail.com>
Message-ID: <1223487834.5532238.1429794213492.JavaMail.zimbra@redhat.com>

implicit is not supported atm

response_type=token returns an error in the latest release

----- Original Message -----
> From: "Fadi Abdin" <fadiabdeen at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 23 April, 2015 2:55:00 PM
> Subject: [keycloak-dev] Implicit Flow
> 
> Does anyone know if the OAuth2 implicit flow on keycloak is supported ?
> 
> I am trying to retrieve the access_token directly after logging in. Ideally
> it should work if you send response_type=token , but it always returns a
> code=... no matter what is the response_type ..
> 
> Does anyone know how to get this to work or if its even supported ?
> 
> Thanks,
> Fadi
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Thu Apr 23 09:07:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Apr 2015 09:07:21 -0400
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
	<393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
Message-ID: <5538EE89.7070506@redhat.com>



On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>, "Bill Burke"
>> <bburke at redhat.com>
>> Sent: Thursday, 23 April, 2015 11:31:25 AM
>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>> On 23.4.2015 07:52, Stian Thorgersen wrote:
>>> Any comments on this?
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>
>>>> We've already discussed this, but didn't come to a conclusion.
>>>>
>>>> There's two separate use-cases to consider:
>>>>
>>>> 1. Authentication
>>>> 2. Offline access
>>>>
>>>> For simplicity the examples below assumes OpenID Connect, but same logic
>>>> applies to SAML.
>>>>
>>>>
>>>> Authentication
>>>> --------------
>>>> In this case user authenticates using an external IdP. After the user has
>>>> authenticated the access and refresh (if available) tokens are stored in
>>>> user session. Tokens are automatically refreshed by Keycloak to support
>>>> brokered log out. In this case an application can only retrieve an access
>>>> token for the identity provider that was used to authenticate the user.
>>>>
>>>>
>>>> Offline access
>>>> --------------
>>>> In this case we should add the option "offline access" to the provider
>>>> config. When enabled we add "offline" to the requested scope. When a user
>>>> first logs in or links through account mngmt we store the refresh token
>>>> (aka
>>>> "offline token") in the user store. As this is a long term token I don't
>>>> see
>>>> any problems using the user store for it. In this case an application can
>>>> retrieve an access token for the identity provider that was used to
>>>> authenticate the user, but also for an identity providers what have
>>>> "offline
>>>> access" enabled and there's an token store in the user store. One issue
>>>> with
>>>> this approach is that brokered log out doesn't work. A potential solution
>>>> to
>>>> that is that we only request offline access when linking the account, but
>>>> during authentication don't add the offline scope and use the process from
>>>> the first use-case.
>> I believe that brokered logout will work as long as we store the flag on
>> UserSession specifying which identity provider was used to authenticate
>> the user in particular session?
>>
>> For example if Google was used to authenticate user and Google offline
>> token was obtained during this authentication, then Keycloak logout will
>> propagate logout to the Google provider and invalidate Google offline
>> token as well. But if Google wasn't used for authenticating user in that
>> particular session (user already had offline Google token linked
>> previously to his account), then Keycloak logout won't propagate logout
>> to the Google and won't invalidate offline token.
>
> I don't think we should invalidate an offline token on logout. That should only be done by unlinking in the account management.
>
> We could request offline scope online when linking, which is stored in user store. If someone logs in with the same provider we don't request offline and store that token in user session.
>

If offline is implemented as a persisted clone of UserSession, then 
there is no extra work to be done.  UserSession already stores the 
broker that logged in the user.  note.BROKER_PROVIDER_ID.


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

From stian at redhat.com  Thu Apr 23 09:13:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 09:13:13 -0400 (EDT)
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <5538ED8B.5060106@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538ED8B.5060106@redhat.com>
Message-ID: <579312276.5540389.1429794793097.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 23 April, 2015 3:03:07 PM
> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> 
> 
> On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
> > Any comments on this?
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 20 April, 2015 9:08:13 AM
> >> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> >>
> >> We've already discussed this, but didn't come to a conclusion.
> >>
> >> There's two separate use-cases to consider:
> >>
> >> 1. Authentication
> >> 2. Offline access
> >>
> >> For simplicity the examples below assumes OpenID Connect, but same logic
> >> applies to SAML.
> >>
> >>
> >> Authentication
> >> --------------
> >> In this case user authenticates using an external IdP. After the user has
> >> authenticated the access and refresh (if available) tokens are stored in
> >> user session. Tokens are automatically refreshed by Keycloak to support
> >> brokered log out. In this case an application can only retrieve an access
> >> token for the identity provider that was used to authenticate the user.
> >>
> 
> I don't know if SAML has refresh.  Half the social providers don't either.
> 
> I'm a bit wary of automatic background refresh.  Every active
> usersession would have to be polled periodically.  Don't know if that
> would be a big performance issue or not.  Maybe just do on-demand
> refresh checks?

I thought that was how the brokered logout worked. I agree that a automatic background refresh would be crazy.

How does the brokered logout actually work then?

> 
> >>
> >> Offline access
> >> --------------
> >> In this case we should add the option "offline access" to the provider
> >> config. When enabled we add "offline" to the requested scope. When a user
> >> first logs in or links through account mngmt we store the refresh token
> >> (aka
> >> "offline token") in the user store. As this is a long term token I don't
> >> see
> >> any problems using the user store for it. In this case an application can
> >> retrieve an access token for the identity provider that was used to
> >> authenticate the user, but also for an identity providers what have
> >> "offline
> >> access" enabled and there's an token store in the user store. One issue
> >> with
> >> this approach is that brokered log out doesn't work. A potential solution
> >> to
> >> that is that we only request offline access when linking the account, but
> >> during authentication don't add the offline scope and use the process from
> >> the first use-case.
> >>
> 
> If offline access is persisted, couldn't the external token still be
> stored in the persisted UserSession?

The offline token shouldn't be associated with a specific user session. It should be associated with a user.

> 
> 
> >>
> >> Token retrieval
> >> ---------------
> >> We add a "token service" client to Keycloak that has a "retrieve token"
> >> role
> >> for each provider. For an application to be able to retrieve the token the
> >> user has to have a role mapping on this role and the client has to have a
> >> scope on it as well. This results in using standard roles, scopes and
> >> consent screens instead of a different mechanism.
> >>
> 
> I implemented it as one master role for reading the external token.
> Wouldn't this be better?  Isn't one role per provider too fine grained?
>   Think about social, you'd have to assign 6-7 different roles to the
> user.  Although doing a role per provider would definitely make it
> easier to implement as I wouldn't have to implement the migration stuff
> I emailed about the other day.

I guess that's fine for now, no need to over complicate things if not necessary - we can just see if anyone complains and wants something more fine-grained.

> 
> BTW, I'm almost done with this. I ran into a problem testing where I
> uncovered a brokered logout bug and I've spent most of my time fixing that.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Apr 23 09:50:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 09:50:24 -0400 (EDT)
Subject: [keycloak-dev] Distribution changes
In-Reply-To: <174261056.5558327.1429796736849.JavaMail.zimbra@redhat.com>
Message-ID: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>

I've pushed a fair amount of changes to the distribution:

* Release is built with "mvn -Pjboss-release install" now as this is consistent with jboss-parent. Also this builds javadoc as well now, so no need to run those separate.
* distribution/examples - a zip with all the examples
* distribution/server-overlay - a zip that can be extracted into an existing WF 8.2.0.Final to install KC, includes docs. Currently it contains server*.xml all with KC enabled, but I was thinking we should just have standalone-keycloak.xml instead
* distribution/server-dist - a zip with WF 8.2.0.Final + server-overlay
* distribution/server-bundle - a bundle with server and examples zip, this should at some point be changed to a dl with demo preloaded onto it
* adapter dists are moved into distribution/adapters, just to clean it up a bit
* Started updating docs, but there's a bit more work to review/update it to make sure it matches updated dists

From bburke at redhat.com  Thu Apr 23 10:04:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Apr 2015 10:04:16 -0400
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <579312276.5540389.1429794793097.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538ED8B.5060106@redhat.com>
	<579312276.5540389.1429794793097.JavaMail.zimbra@redhat.com>
Message-ID: <5538FBE0.60000@redhat.com>



On 4/23/2015 9:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 23 April, 2015 3:03:07 PM
>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>>
>>
>> On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
>>> Any comments on this?
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>
>>>> We've already discussed this, but didn't come to a conclusion.
>>>>
>>>> There's two separate use-cases to consider:
>>>>
>>>> 1. Authentication
>>>> 2. Offline access
>>>>
>>>> For simplicity the examples below assumes OpenID Connect, but same logic
>>>> applies to SAML.
>>>>
>>>>
>>>> Authentication
>>>> --------------
>>>> In this case user authenticates using an external IdP. After the user has
>>>> authenticated the access and refresh (if available) tokens are stored in
>>>> user session. Tokens are automatically refreshed by Keycloak to support
>>>> brokered log out. In this case an application can only retrieve an access
>>>> token for the identity provider that was used to authenticate the user.
>>>>
>>
>> I don't know if SAML has refresh.  Half the social providers don't either.
>>
>> I'm a bit wary of automatic background refresh.  Every active
>> usersession would have to be polled periodically.  Don't know if that
>> would be a big performance issue or not.  Maybe just do on-demand
>> refresh checks?
>
> I thought that was how the brokered logout worked. I agree that a automatic background refresh would be crazy.
>
> How does the brokered logout actually work then?
>

I don't check external token expiration at the moment or do any refreshes.


>>
>>>>
>>>> Offline access
>>>> --------------
>>>> In this case we should add the option "offline access" to the provider
>>>> config. When enabled we add "offline" to the requested scope. When a user
>>>> first logs in or links through account mngmt we store the refresh token
>>>> (aka
>>>> "offline token") in the user store. As this is a long term token I don't
>>>> see
>>>> any problems using the user store for it. In this case an application can
>>>> retrieve an access token for the identity provider that was used to
>>>> authenticate the user, but also for an identity providers what have
>>>> "offline
>>>> access" enabled and there's an token store in the user store. One issue
>>>> with
>>>> this approach is that brokered log out doesn't work. A potential solution
>>>> to
>>>> that is that we only request offline access when linking the account, but
>>>> during authentication don't add the offline scope and use the process from
>>>> the first use-case.
>>>>
>>
>> If offline access is persisted, couldn't the external token still be
>> stored in the persisted UserSession?
>
> The offline token shouldn't be associated with a specific user session. It should be associated with a user.
>

See my other email.  If offline token is implemented as persisted cloned 
extension of UserSession, then everything will be available.


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

From stian at redhat.com  Thu Apr 23 10:12:14 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 23 Apr 2015 10:12:14 -0400 (EDT)
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <5538EE89.7070506@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
	<393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
	<5538EE89.7070506@redhat.com>
Message-ID: <396434274.5583834.1429798334429.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 23 April, 2015 3:07:21 PM
> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
> 
> 
> 
> On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >> <keycloak-dev at lists.jboss.org>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Sent: Thursday, 23 April, 2015 11:31:25 AM
> >> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
> >>
> >> On 23.4.2015 07:52, Stian Thorgersen wrote:
> >>> Any comments on this?
> >>>
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Monday, 20 April, 2015 9:08:13 AM
> >>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
> >>>>
> >>>> We've already discussed this, but didn't come to a conclusion.
> >>>>
> >>>> There's two separate use-cases to consider:
> >>>>
> >>>> 1. Authentication
> >>>> 2. Offline access
> >>>>
> >>>> For simplicity the examples below assumes OpenID Connect, but same logic
> >>>> applies to SAML.
> >>>>
> >>>>
> >>>> Authentication
> >>>> --------------
> >>>> In this case user authenticates using an external IdP. After the user
> >>>> has
> >>>> authenticated the access and refresh (if available) tokens are stored in
> >>>> user session. Tokens are automatically refreshed by Keycloak to support
> >>>> brokered log out. In this case an application can only retrieve an
> >>>> access
> >>>> token for the identity provider that was used to authenticate the user.
> >>>>
> >>>>
> >>>> Offline access
> >>>> --------------
> >>>> In this case we should add the option "offline access" to the provider
> >>>> config. When enabled we add "offline" to the requested scope. When a
> >>>> user
> >>>> first logs in or links through account mngmt we store the refresh token
> >>>> (aka
> >>>> "offline token") in the user store. As this is a long term token I don't
> >>>> see
> >>>> any problems using the user store for it. In this case an application
> >>>> can
> >>>> retrieve an access token for the identity provider that was used to
> >>>> authenticate the user, but also for an identity providers what have
> >>>> "offline
> >>>> access" enabled and there's an token store in the user store. One issue
> >>>> with
> >>>> this approach is that brokered log out doesn't work. A potential
> >>>> solution
> >>>> to
> >>>> that is that we only request offline access when linking the account,
> >>>> but
> >>>> during authentication don't add the offline scope and use the process
> >>>> from
> >>>> the first use-case.
> >> I believe that brokered logout will work as long as we store the flag on
> >> UserSession specifying which identity provider was used to authenticate
> >> the user in particular session?
> >>
> >> For example if Google was used to authenticate user and Google offline
> >> token was obtained during this authentication, then Keycloak logout will
> >> propagate logout to the Google provider and invalidate Google offline
> >> token as well. But if Google wasn't used for authenticating user in that
> >> particular session (user already had offline Google token linked
> >> previously to his account), then Keycloak logout won't propagate logout
> >> to the Google and won't invalidate offline token.
> >
> > I don't think we should invalidate an offline token on logout. That should
> > only be done by unlinking in the account management.
> >
> > We could request offline scope online when linking, which is stored in user
> > store. If someone logs in with the same provider we don't request offline
> > and store that token in user session.
> >
> 
> If offline is implemented as a persisted clone of UserSession, then
> there is no extra work to be done.  UserSession already stores the
> broker that logged in the user.  note.BROKER_PROVIDER_ID.

There's two separate "offline" though:

1. App request offline access from Keycloak - this one makes with persisted clone of UserSession
2. Keycloak requests offline token from external IdP - how would this work with persisted clone of UserSession?

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

From shivasaxena999 at gmail.com  Thu Apr 23 10:15:07 2015
From: shivasaxena999 at gmail.com (Shiva Saxena)
Date: Thu, 23 Apr 2015 19:45:07 +0530
Subject: [keycloak-dev] Documentation for the list of parameters of JSON
	file for realm creation
Message-ID: <CADjggukKcDqX4mhoA_onj6wfmJmmaWp1SoCDrOx746WYSzoZtA@mail.gmail.com>

Hi Everyone,

I saw a good number of github example where we can create realms in
keycloak, via uploading a JSON.

Unfortunately  I wan unable to find any documentation that lists the
parameters we can put in this JSON file to customize the realm.

Can some body guide me to some documentation that lists the list of
parameters we can pass for realm creation.

--
Thanks & Regards
Shiva Saxena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150423/77a7e372/attachment.html 

From bburke at redhat.com  Thu Apr 23 10:30:55 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Apr 2015 10:30:55 -0400
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <396434274.5583834.1429798334429.JavaMail.zimbra@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
	<393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
	<5538EE89.7070506@redhat.com>
	<396434274.5583834.1429798334429.JavaMail.zimbra@redhat.com>
Message-ID: <5539021F.8010406@redhat.com>



On 4/23/2015 10:12 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 23 April, 2015 3:07:21 PM
>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>
>>
>>
>> On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>> <keycloak-dev at lists.jboss.org>, "Bill Burke"
>>>> <bburke at redhat.com>
>>>> Sent: Thursday, 23 April, 2015 11:31:25 AM
>>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>
>>>> On 23.4.2015 07:52, Stian Thorgersen wrote:
>>>>> Any comments on this?
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>>>>>
>>>>>> We've already discussed this, but didn't come to a conclusion.
>>>>>>
>>>>>> There's two separate use-cases to consider:
>>>>>>
>>>>>> 1. Authentication
>>>>>> 2. Offline access
>>>>>>
>>>>>> For simplicity the examples below assumes OpenID Connect, but same logic
>>>>>> applies to SAML.
>>>>>>
>>>>>>
>>>>>> Authentication
>>>>>> --------------
>>>>>> In this case user authenticates using an external IdP. After the user
>>>>>> has
>>>>>> authenticated the access and refresh (if available) tokens are stored in
>>>>>> user session. Tokens are automatically refreshed by Keycloak to support
>>>>>> brokered log out. In this case an application can only retrieve an
>>>>>> access
>>>>>> token for the identity provider that was used to authenticate the user.
>>>>>>
>>>>>>
>>>>>> Offline access
>>>>>> --------------
>>>>>> In this case we should add the option "offline access" to the provider
>>>>>> config. When enabled we add "offline" to the requested scope. When a
>>>>>> user
>>>>>> first logs in or links through account mngmt we store the refresh token
>>>>>> (aka
>>>>>> "offline token") in the user store. As this is a long term token I don't
>>>>>> see
>>>>>> any problems using the user store for it. In this case an application
>>>>>> can
>>>>>> retrieve an access token for the identity provider that was used to
>>>>>> authenticate the user, but also for an identity providers what have
>>>>>> "offline
>>>>>> access" enabled and there's an token store in the user store. One issue
>>>>>> with
>>>>>> this approach is that brokered log out doesn't work. A potential
>>>>>> solution
>>>>>> to
>>>>>> that is that we only request offline access when linking the account,
>>>>>> but
>>>>>> during authentication don't add the offline scope and use the process
>>>>>> from
>>>>>> the first use-case.
>>>> I believe that brokered logout will work as long as we store the flag on
>>>> UserSession specifying which identity provider was used to authenticate
>>>> the user in particular session?
>>>>
>>>> For example if Google was used to authenticate user and Google offline
>>>> token was obtained during this authentication, then Keycloak logout will
>>>> propagate logout to the Google provider and invalidate Google offline
>>>> token as well. But if Google wasn't used for authenticating user in that
>>>> particular session (user already had offline Google token linked
>>>> previously to his account), then Keycloak logout won't propagate logout
>>>> to the Google and won't invalidate offline token.
>>>
>>> I don't think we should invalidate an offline token on logout. That should
>>> only be done by unlinking in the account management.
>>>
>>> We could request offline scope online when linking, which is stored in user
>>> store. If someone logs in with the same provider we don't request offline
>>> and store that token in user session.
>>>
>>
>> If offline is implemented as a persisted clone of UserSession, then
>> there is no extra work to be done.  UserSession already stores the
>> broker that logged in the user.  note.BROKER_PROVIDER_ID.
>
> There's two separate "offline" though:
>
> 1. App request offline access from Keycloak - this one makes with persisted clone of UserSession
> 2. Keycloak requests offline token from external IdP - how would this work with persisted clone of UserSession?
>

Why would Keycloak ever want an offline token?  Or an offline token not 
associated with a UserSession?  They only thing I could think of is if 
you want to bypass logging into the external IDP.

FYI, I think you're getting into some extreme edge cases.  Something I 
have no interest in implementing.

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

From mposolda at redhat.com  Thu Apr 23 12:53:43 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Apr 2015 18:53:43 +0200
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <5539021F.8010406@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
	<393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
	<5538EE89.7070506@redhat.com>
	<396434274.5583834.1429798334429.JavaMail.zimbra@redhat.com>
	<5539021F.8010406@redhat.com>
Message-ID: <55392397.6030009@redhat.com>

On 23.4.2015 16:30, Bill Burke wrote:
>
>
> On 4/23/2015 10:12 AM, Stian Thorgersen wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" 
>>> <mposolda at redhat.com>
>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Thursday, 23 April, 2015 3:07:21 PM
>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and 
>>> retrieval
>>>
>>>
>>>
>>> On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>>> <keycloak-dev at lists.jboss.org>, "Bill Burke"
>>>>> <bburke at redhat.com>
>>>>> Sent: Thursday, 23 April, 2015 11:31:25 AM
>>>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and 
>>>>> retrieval
>>>>>
>>>>> On 23.4.2015 07:52, Stian Thorgersen wrote:
>>>>>> Any comments on this?
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>>>>> Subject: [keycloak-dev] Identity Brokering token storage and 
>>>>>>> retrieval
>>>>>>>
>>>>>>> We've already discussed this, but didn't come to a conclusion.
>>>>>>>
>>>>>>> There's two separate use-cases to consider:
>>>>>>>
>>>>>>> 1. Authentication
>>>>>>> 2. Offline access
>>>>>>>
>>>>>>> For simplicity the examples below assumes OpenID Connect, but 
>>>>>>> same logic
>>>>>>> applies to SAML.
>>>>>>>
>>>>>>>
>>>>>>> Authentication
>>>>>>> --------------
>>>>>>> In this case user authenticates using an external IdP. After the 
>>>>>>> user
>>>>>>> has
>>>>>>> authenticated the access and refresh (if available) tokens are 
>>>>>>> stored in
>>>>>>> user session. Tokens are automatically refreshed by Keycloak to 
>>>>>>> support
>>>>>>> brokered log out. In this case an application can only retrieve an
>>>>>>> access
>>>>>>> token for the identity provider that was used to authenticate 
>>>>>>> the user.
>>>>>>>
>>>>>>>
>>>>>>> Offline access
>>>>>>> --------------
>>>>>>> In this case we should add the option "offline access" to the 
>>>>>>> provider
>>>>>>> config. When enabled we add "offline" to the requested scope. 
>>>>>>> When a
>>>>>>> user
>>>>>>> first logs in or links through account mngmt we store the 
>>>>>>> refresh token
>>>>>>> (aka
>>>>>>> "offline token") in the user store. As this is a long term token 
>>>>>>> I don't
>>>>>>> see
>>>>>>> any problems using the user store for it. In this case an 
>>>>>>> application
>>>>>>> can
>>>>>>> retrieve an access token for the identity provider that was used to
>>>>>>> authenticate the user, but also for an identity providers what have
>>>>>>> "offline
>>>>>>> access" enabled and there's an token store in the user store. 
>>>>>>> One issue
>>>>>>> with
>>>>>>> this approach is that brokered log out doesn't work. A potential
>>>>>>> solution
>>>>>>> to
>>>>>>> that is that we only request offline access when linking the 
>>>>>>> account,
>>>>>>> but
>>>>>>> during authentication don't add the offline scope and use the 
>>>>>>> process
>>>>>>> from
>>>>>>> the first use-case.
>>>>> I believe that brokered logout will work as long as we store the 
>>>>> flag on
>>>>> UserSession specifying which identity provider was used to 
>>>>> authenticate
>>>>> the user in particular session?
>>>>>
>>>>> For example if Google was used to authenticate user and Google 
>>>>> offline
>>>>> token was obtained during this authentication, then Keycloak 
>>>>> logout will
>>>>> propagate logout to the Google provider and invalidate Google offline
>>>>> token as well. But if Google wasn't used for authenticating user 
>>>>> in that
>>>>> particular session (user already had offline Google token linked
>>>>> previously to his account), then Keycloak logout won't propagate 
>>>>> logout
>>>>> to the Google and won't invalidate offline token.
>>>>
>>>> I don't think we should invalidate an offline token on logout. That 
>>>> should
>>>> only be done by unlinking in the account management.
>>>>
>>>> We could request offline scope online when linking, which is stored 
>>>> in user
>>>> store. If someone logs in with the same provider we don't request 
>>>> offline
>>>> and store that token in user session.
>>>>
>>>
>>> If offline is implemented as a persisted clone of UserSession, then
>>> there is no extra work to be done.  UserSession already stores the
>>> broker that logged in the user.  note.BROKER_PROVIDER_ID.
>>
>> There's two separate "offline" though:
>>
>> 1. App request offline access from Keycloak - this one makes with 
>> persisted clone of UserSession
>> 2. Keycloak requests offline token from external IdP - how would this 
>> work with persisted clone of UserSession?
>>
>
> Why would Keycloak ever want an offline token?  Or an offline token 
> not associated with a UserSession?  They only thing I could think of 
> is if you want to bypass logging into the external IDP.
>
> FYI, I think you're getting into some extreme edge cases. Something I 
> have no interest in implementing.
>
I think it is about the possibility to use all the 3rd party tokens in 
one application. For example I have application secured by Keycloak, 
which wants to display list of my friends from Facebook and also from 
Google. On Monday I login into the application through Google. On 
Tuesday I login into that application from Facebook, but I still want to 
display my friends from both Facebook and Google. So application would 
need to have possibility to reuse the token obtained from Google the 
previous day.

Note that I want offline token from Google, but I don't need offline 
UserSession from Keycloak itself. Both Keycloak sessions from Monday and 
Tuesday are short lived (ie. I spent just 5 minutes playing with my 
application every day)

Marek

From mposolda at redhat.com  Thu Apr 23 12:56:52 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 23 Apr 2015 18:56:52 +0200
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <5538ED8B.5060106@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538ED8B.5060106@redhat.com>
Message-ID: <55392454.20509@redhat.com>

On 23.4.2015 15:03, Bill Burke wrote:
>
> On 4/23/2015 1:52 AM, Stian Thorgersen wrote:
>> Any comments on this?
>>
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>> Subject: [keycloak-dev] Identity Brokering token storage and retrieval
>>>
>>> We've already discussed this, but didn't come to a conclusion.
>>>
>>> There's two separate use-cases to consider:
>>>
>>> 1. Authentication
>>> 2. Offline access
>>>
>>> For simplicity the examples below assumes OpenID Connect, but same logic
>>> applies to SAML.
>>>
>>>
>>> Authentication
>>> --------------
>>> In this case user authenticates using an external IdP. After the user has
>>> authenticated the access and refresh (if available) tokens are stored in
>>> user session. Tokens are automatically refreshed by Keycloak to support
>>> brokered log out. In this case an application can only retrieve an access
>>> token for the identity provider that was used to authenticate the user.
>>>
> I don't know if SAML has refresh.  Half the social providers don't either.
Yeah, which makes it tricky what exactly is "offline" token as it 
depends on the provider though. For example Twitter doesn't expire 
accessTokens, so in case of Twitter, each access token can be considered 
as "offline" token. Similarly for Facebook which doesn't support 
refresh, but access token are long-lived (like valid for 2 moths or so)...

Marek
>
> I'm a bit wary of automatic background refresh.  Every active
> usersession would have to be polled periodically.  Don't know if that
> would be a big performance issue or not.  Maybe just do on-demand
> refresh checks?
>
>>> Offline access
>>> --------------
>>> In this case we should add the option "offline access" to the provider
>>> config. When enabled we add "offline" to the requested scope. When a user
>>> first logs in or links through account mngmt we store the refresh token (aka
>>> "offline token") in the user store. As this is a long term token I don't see
>>> any problems using the user store for it. In this case an application can
>>> retrieve an access token for the identity provider that was used to
>>> authenticate the user, but also for an identity providers what have "offline
>>> access" enabled and there's an token store in the user store. One issue with
>>> this approach is that brokered log out doesn't work. A potential solution to
>>> that is that we only request offline access when linking the account, but
>>> during authentication don't add the offline scope and use the process from
>>> the first use-case.
>>>
> If offline access is persisted, couldn't the external token still be
> stored in the persisted UserSession?
>
>
>>> Token retrieval
>>> ---------------
>>> We add a "token service" client to Keycloak that has a "retrieve token" role
>>> for each provider. For an application to be able to retrieve the token the
>>> user has to have a role mapping on this role and the client has to have a
>>> scope on it as well. This results in using standard roles, scopes and
>>> consent screens instead of a different mechanism.
>>>
> I implemented it as one master role for reading the external token.
> Wouldn't this be better?  Isn't one role per provider too fine grained?
>    Think about social, you'd have to assign 6-7 different roles to the
> user.  Although doing a role per provider would definitely make it
> easier to implement as I wouldn't have to implement the migration stuff
> I emailed about the other day.
>
> BTW, I'm almost done with this. I ran into a problem testing where I
> uncovered a brokered logout bug and I've spent most of my time fixing that.
>
>


From bburke at redhat.com  Thu Apr 23 14:37:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 23 Apr 2015 14:37:07 -0400
Subject: [keycloak-dev] Identity Brokering token storage and retrieval
In-Reply-To: <55392397.6030009@redhat.com>
References: <308199138.3103033.1429513693921.JavaMail.zimbra@redhat.com>
	<1152223511.5272598.1429768375123.JavaMail.zimbra@redhat.com>
	<5538BBED.2000109@redhat.com>
	<393990816.5461114.1429785631418.JavaMail.zimbra@redhat.com>
	<5538EE89.7070506@redhat.com>
	<396434274.5583834.1429798334429.JavaMail.zimbra@redhat.com>
	<5539021F.8010406@redhat.com> <55392397.6030009@redhat.com>
Message-ID: <55393BD3.8030305@redhat.com>



On 4/23/2015 12:53 PM, Marek Posolda wrote:
> On 23.4.2015 16:30, Bill Burke wrote:
>>
>>
>> On 4/23/2015 10:12 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda"
>>>> <mposolda at redhat.com>
>>>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Thursday, 23 April, 2015 3:07:21 PM
>>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and
>>>> retrieval
>>>>
>>>>
>>>>
>>>> On 4/23/2015 6:40 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
>>>>>> <keycloak-dev at lists.jboss.org>, "Bill Burke"
>>>>>> <bburke at redhat.com>
>>>>>> Sent: Thursday, 23 April, 2015 11:31:25 AM
>>>>>> Subject: Re: [keycloak-dev] Identity Brokering token storage and
>>>>>> retrieval
>>>>>>
>>>>>> On 23.4.2015 07:52, Stian Thorgersen wrote:
>>>>>>> Any comments on this?
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>>> Sent: Monday, 20 April, 2015 9:08:13 AM
>>>>>>>> Subject: [keycloak-dev] Identity Brokering token storage and
>>>>>>>> retrieval
>>>>>>>>
>>>>>>>> We've already discussed this, but didn't come to a conclusion.
>>>>>>>>
>>>>>>>> There's two separate use-cases to consider:
>>>>>>>>
>>>>>>>> 1. Authentication
>>>>>>>> 2. Offline access
>>>>>>>>
>>>>>>>> For simplicity the examples below assumes OpenID Connect, but
>>>>>>>> same logic
>>>>>>>> applies to SAML.
>>>>>>>>
>>>>>>>>
>>>>>>>> Authentication
>>>>>>>> --------------
>>>>>>>> In this case user authenticates using an external IdP. After the
>>>>>>>> user
>>>>>>>> has
>>>>>>>> authenticated the access and refresh (if available) tokens are
>>>>>>>> stored in
>>>>>>>> user session. Tokens are automatically refreshed by Keycloak to
>>>>>>>> support
>>>>>>>> brokered log out. In this case an application can only retrieve an
>>>>>>>> access
>>>>>>>> token for the identity provider that was used to authenticate
>>>>>>>> the user.
>>>>>>>>
>>>>>>>>
>>>>>>>> Offline access
>>>>>>>> --------------
>>>>>>>> In this case we should add the option "offline access" to the
>>>>>>>> provider
>>>>>>>> config. When enabled we add "offline" to the requested scope.
>>>>>>>> When a
>>>>>>>> user
>>>>>>>> first logs in or links through account mngmt we store the
>>>>>>>> refresh token
>>>>>>>> (aka
>>>>>>>> "offline token") in the user store. As this is a long term token
>>>>>>>> I don't
>>>>>>>> see
>>>>>>>> any problems using the user store for it. In this case an
>>>>>>>> application
>>>>>>>> can
>>>>>>>> retrieve an access token for the identity provider that was used to
>>>>>>>> authenticate the user, but also for an identity providers what have
>>>>>>>> "offline
>>>>>>>> access" enabled and there's an token store in the user store.
>>>>>>>> One issue
>>>>>>>> with
>>>>>>>> this approach is that brokered log out doesn't work. A potential
>>>>>>>> solution
>>>>>>>> to
>>>>>>>> that is that we only request offline access when linking the
>>>>>>>> account,
>>>>>>>> but
>>>>>>>> during authentication don't add the offline scope and use the
>>>>>>>> process
>>>>>>>> from
>>>>>>>> the first use-case.
>>>>>> I believe that brokered logout will work as long as we store the
>>>>>> flag on
>>>>>> UserSession specifying which identity provider was used to
>>>>>> authenticate
>>>>>> the user in particular session?
>>>>>>
>>>>>> For example if Google was used to authenticate user and Google
>>>>>> offline
>>>>>> token was obtained during this authentication, then Keycloak
>>>>>> logout will
>>>>>> propagate logout to the Google provider and invalidate Google offline
>>>>>> token as well. But if Google wasn't used for authenticating user
>>>>>> in that
>>>>>> particular session (user already had offline Google token linked
>>>>>> previously to his account), then Keycloak logout won't propagate
>>>>>> logout
>>>>>> to the Google and won't invalidate offline token.
>>>>>
>>>>> I don't think we should invalidate an offline token on logout. That
>>>>> should
>>>>> only be done by unlinking in the account management.
>>>>>
>>>>> We could request offline scope online when linking, which is stored
>>>>> in user
>>>>> store. If someone logs in with the same provider we don't request
>>>>> offline
>>>>> and store that token in user session.
>>>>>
>>>>
>>>> If offline is implemented as a persisted clone of UserSession, then
>>>> there is no extra work to be done.  UserSession already stores the
>>>> broker that logged in the user.  note.BROKER_PROVIDER_ID.
>>>
>>> There's two separate "offline" though:
>>>
>>> 1. App request offline access from Keycloak - this one makes with
>>> persisted clone of UserSession
>>> 2. Keycloak requests offline token from external IdP - how would this
>>> work with persisted clone of UserSession?
>>>
>>
>> Why would Keycloak ever want an offline token?  Or an offline token
>> not associated with a UserSession?  They only thing I could think of
>> is if you want to bypass logging into the external IDP.
>>
>> FYI, I think you're getting into some extreme edge cases. Something I
>> have no interest in implementing.
>>
> I think it is about the possibility to use all the 3rd party tokens in
> one application. For example I have application secured by Keycloak,
> which wants to display list of my friends from Facebook and also from
> Google. On Monday I login into the application through Google. On
> Tuesday I login into that application from Facebook, but I still want to
> display my friends from both Facebook and Google. So application would
> need to have possibility to reuse the token obtained from Google the
> previous day.
>
> Note that I want offline token from Google, but I don't need offline
> UserSession from Keycloak itself. Both Keycloak sessions from Monday and
> Tuesday are short lived (ie. I spent just 5 minutes playing with my
> application every day)
>

So I guess we just keep storing external "tokens" the way we are doing 
it: in the FederatedIdentityModel.  I'll add a "refresh" method to 
IdentityProvider interface that will be called by the refreshToken 
operation if the user is attached to an identity provider.

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

From stian at redhat.com  Fri Apr 24 00:40:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Apr 2015 00:40:06 -0400 (EDT)
Subject: [keycloak-dev] Documentation for the list of parameters of
	JSON	file for realm creation
In-Reply-To: <CADjggukKcDqX4mhoA_onj6wfmJmmaWp1SoCDrOx746WYSzoZtA@mail.gmail.com>
References: <CADjggukKcDqX4mhoA_onj6wfmJmmaWp1SoCDrOx746WYSzoZtA@mail.gmail.com>
Message-ID: <571824704.5914893.1429850406961.JavaMail.zimbra@redhat.com>

We don't have proper documentation of these, but you can look at Javadocs:

http://docs.jboss.org/keycloak/docs/1.2.0.Beta1/javadocs/org/keycloak/representations/idm/package-frame.html

The field names in the json representation are the same as in Java.

----- Original Message -----
> From: "Shiva Saxena" <shivasaxena999 at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 23 April, 2015 4:15:07 PM
> Subject: [keycloak-dev] Documentation for the list of parameters of JSON	file for realm creation
> 
> Hi Everyone,
> 
> I saw a good number of github example where we can create realms in keycloak,
> via uploading a JSON.
> 
> Unfortunately I wan unable to find any documentation that lists the
> parameters we can put in this JSON file to customize the realm.
> 
> Can some body guide me to some documentation that lists the list of
> parameters we can pass for realm creation.
> 
> --
> Thanks & Regards
> Shiva Saxena
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Fri Apr 24 03:29:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 24 Apr 2015 03:29:32 -0400 (EDT)
Subject: [keycloak-dev] Distribution changes
In-Reply-To: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>
References: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>
Message-ID: <1002185417.5955745.1429860572572.JavaMail.zimbra@redhat.com>

A couple changes:

server-overlay:
* Added standalone-keycloak.xml as this allows extracting into wildfly without overwriting existing configs
* Removed docs into separate docs dist (reduces size from 27MB to 15MB)

server-dist:
* Removed standalone/deployments and deployment processor

Remaining work is to do the demo bundle. Plan is to have it include WF + server-overlay + demo preloaded. Also include all examples and docs.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 23 April, 2015 3:50:24 PM
> Subject: [keycloak-dev] Distribution changes
> 
> I've pushed a fair amount of changes to the distribution:
> 
> * Release is built with "mvn -Pjboss-release install" now as this is
> consistent with jboss-parent. Also this builds javadoc as well now, so no
> need to run those separate.
> * distribution/examples - a zip with all the examples
> * distribution/server-overlay - a zip that can be extracted into an existing
> WF 8.2.0.Final to install KC, includes docs. Currently it contains
> server*.xml all with KC enabled, but I was thinking we should just have
> standalone-keycloak.xml instead
> * distribution/server-dist - a zip with WF 8.2.0.Final + server-overlay
> * distribution/server-bundle - a bundle with server and examples zip, this
> should at some point be changed to a dl with demo preloaded onto it
> * adapter dists are moved into distribution/adapters, just to clean it up a
> bit
> * Started updating docs, but there's a bit more work to review/update it to
> make sure it matches updated dists
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Fri Apr 24 13:20:01 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 24 Apr 2015 19:20:01 +0200
Subject: [keycloak-dev] Sharing HttpClient in backchannelLogout
Message-ID: <553A7B41.5010008@redhat.com>

Looks that both OIDCLoginProtocol.backchannelLogout and 
SamlProtocol.backchannelLogout always create new instance of Apache 
HttpClient used just during single invocation. I suspect this is not 
very good for performance as HTTP connections pool needs to be always 
created again and again? We're doing it even if client doesn't have 
adminUrl (no sending of HTTP request is even needed).

I wonder if we should share single instance of HttpClient (or 
ApacheHttpClient4Executor) per LoginProtocolFactory? Or even better, if 
we convert AuthenticationManager to the SPI (which is planned AFAIK) and 
pass the executor from there?

Marek

From prabhalar at yahoo.com  Fri Apr 24 16:44:24 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Fri, 24 Apr 2015 16:44:24 -0400
Subject: [keycloak-dev] Oidc bug?
Message-ID: <5EE87C8E-3DC4-4DB1-99E4-5F074B5B087B@yahoo.com>

Bill,

Sometime back I mentioned to you that I used to get a "connect refused" from KC when I tried the token end point.

I think I am able to simulate it more often using 1.2 beta release - it happens randomly if you follow the below steps
1) open up browser and try the basic flow 3 or 4 times. Then close the browser
2) repeat the above 3 or 4 times and you may see the issue 

I believe it is due to the sessions KC creates.  Clearing the session from admin gui will address the issue.

Unfortunately the logs do not show anything - is there any configuration that will help me gather more info?

Thanks 
Raghu

Sent from my iPhone

From bburke at redhat.com  Fri Apr 24 18:40:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 24 Apr 2015 18:40:05 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <5EE87C8E-3DC4-4DB1-99E4-5F074B5B087B@yahoo.com>
References: <5EE87C8E-3DC4-4DB1-99E4-5F074B5B087B@yahoo.com>
Message-ID: <553AC645.1030906@redhat.com>

What kind of app?  Login and logout 3 or 4 times?  Same user or 
different users?

On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
> Bill,
>
> Sometime back I mentioned to you that I used to get a "connect refused" from KC when I tried the token end point.
>
> I think I am able to simulate it more often using 1.2 beta release - it happens randomly if you follow the below steps
> 1) open up browser and try the basic flow 3 or 4 times. Then close the browser
> 2) repeat the above 3 or 4 times and you may see the issue
>
> I believe it is due to the sessions KC creates.  Clearing the session from admin gui will address the issue.
>
> Unfortunately the logs do not show anything - is there any configuration that will help me gather more info?
>
> Thanks
> Raghu
>
> Sent from my iPhone
> _______________________________________________
> 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  Mon Apr 27 01:06:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 01:06:45 -0400 (EDT)
Subject: [keycloak-dev] Sharing HttpClient in backchannelLogout
In-Reply-To: <553A7B41.5010008@redhat.com>
References: <553A7B41.5010008@redhat.com>
Message-ID: <771009545.6923673.1430111205227.JavaMail.zimbra@redhat.com>

We should do it proper and add a HttpClient SPI/provider. That way we can also allow configuring what truststore it uses.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 April, 2015 7:20:01 PM
> Subject: [keycloak-dev] Sharing HttpClient in backchannelLogout
> 
> Looks that both OIDCLoginProtocol.backchannelLogout and
> SamlProtocol.backchannelLogout always create new instance of Apache
> HttpClient used just during single invocation. I suspect this is not
> very good for performance as HTTP connections pool needs to be always
> created again and again? We're doing it even if client doesn't have
> adminUrl (no sending of HTTP request is even needed).
> 
> I wonder if we should share single instance of HttpClient (or
> ApacheHttpClient4Executor) per LoginProtocolFactory? Or even better, if
> we convert AuthenticationManager to the SPI (which is planned AFAIK) and
> pass the executor from there?
> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Apr 27 02:37:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 02:37:35 -0400 (EDT)
Subject: [keycloak-dev] Supported environments
In-Reply-To: <321414059.6985097.1430116310352.JavaMail.zimbra@redhat.com>
Message-ID: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>

For 1.2.0.Final the server should be deployable to:

* WildFly 8.2.0.Final
* EAP 6.4.0.GA

After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's released). As APIs has changed, and there's also new features in WF 9 we can leverage, the cleanest way to do this is to drop support for deploying to EAP 6.4.0.GA.

With regards to adapters what versions should we support:

* AS7 - can we drop this?
* WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and 9.0.0.Final)?
* EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3, 6.4)?

From mposolda at redhat.com  Mon Apr 27 03:29:40 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 27 Apr 2015 09:29:40 +0200
Subject: [keycloak-dev] Sharing HttpClient in backchannelLogout
In-Reply-To: <771009545.6923673.1430111205227.JavaMail.zimbra@redhat.com>
References: <553A7B41.5010008@redhat.com>
	<771009545.6923673.1430111205227.JavaMail.zimbra@redhat.com>
Message-ID: <553DE564.80208@redhat.com>

I agree that SPI will be even better. Will allow us to configure also 
all other stuff like connection pooling etc. Created 
https://issues.jboss.org/browse/KEYCLOAK-1231

Marek

On 27.4.2015 07:06, Stian Thorgersen wrote:
> We should do it proper and add a HttpClient SPI/provider. That way we can also allow configuring what truststore it uses.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 24 April, 2015 7:20:01 PM
>> Subject: [keycloak-dev] Sharing HttpClient in backchannelLogout
>>
>> Looks that both OIDCLoginProtocol.backchannelLogout and
>> SamlProtocol.backchannelLogout always create new instance of Apache
>> HttpClient used just during single invocation. I suspect this is not
>> very good for performance as HTTP connections pool needs to be always
>> created again and again? We're doing it even if client doesn't have
>> adminUrl (no sending of HTTP request is even needed).
>>
>> I wonder if we should share single instance of HttpClient (or
>> ApacheHttpClient4Executor) per LoginProtocolFactory? Or even better, if
>> we convert AuthenticationManager to the SPI (which is planned AFAIK) and
>> pass the executor from there?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Mon Apr 27 05:09:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 05:09:29 -0400 (EDT)
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <1538677483.7117804.1430125403512.JavaMail.zimbra@redhat.com>
Message-ID: <56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>

I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).

Remaining work:

* KEYCLOAK-1229	Re-enable broker examples - Bill can you look at this?
* KEYCLOAK-1189	SSLPeerUnverifiedException when deploying Keycloak with JDK 8 - I'm looking at this ATM, testing if including a httpcomponents module with slot=4.3 works
* KEYCLOAK-1180	keycloak proxy needs different redirect uri config - Bill can you look at this? Or shall we just post-pone it?
* KEYCLOAK-1040	Allow import of realm keys (like we do for SAML) - shall we post-pone this?
* KEYCLOAK-1070	Persist client grants - almost done

I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme by default", basically changing l&f of admin console to better match standard PatternFly. Ideally this would be done prior to 1.2.0.CR1 release, but I'm not sure how long it'll take. If IO can finish this tomorrow I'll include it, if not I'll post-pone it.

Anything else? Would be great if everyone can look at distribution changes I did and comment/complain about it ASAP!

We'll follow-up with a 1.2.0.Final next week.

From prabhalar at yahoo.com  Mon Apr 27 05:52:51 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Mon, 27 Apr 2015 09:52:51 +0000 (UTC)
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <553AC645.1030906@redhat.com>
References: <553AC645.1030906@redhat.com>
Message-ID: <1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>

It is a Client application?(confidential) running on a different host. Was trying out the basic flow using the same id multiple times.? Opened up? IE browser, accessed the client application which invoked the OIDC basic flow,?retrieving auth code, followed by tokens and finally user info. On successful retrieval of all that information, opened another tab instance?of?the browser?and once again accessed the web application and the oidc flow followed. Did that?with a few tab instances. Finally closed all the instances of the browser (didn't logoff from KC?in any instance). 
Then started another cycle of the same process?and then ran into that issue. It appears that when you login multiple times (around 8-10)?to KC using the same user id in quick intervals without logging off, the issue occurs. Will continue to do some more testing today and hopefully can nail the behavior. 
Is there any configuration that will help me gather detailed logs?


     From: Bill Burke <bburke at redhat.com>
 To: keycloak-dev at lists.jboss.org 
 Sent: Friday, April 24, 2015 6:40 PM
 Subject: Re: [keycloak-dev] Oidc bug?
   
What kind of app?? Login and logout 3 or 4 times?? Same user or 
different users?



On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
> Bill,
>
> Sometime back I mentioned to you that I used to get a "connect refused" from KC when I tried the token end point.
>
> I think I am able to simulate it more often using 1.2 beta release - it happens randomly if you follow the below steps
> 1) open up browser and try the basic flow 3 or 4 times. Then close the browser
> 2) repeat the above 3 or 4 times and you may see the issue
>
> I believe it is due to the sessions KC creates.? Clearing the session from admin gui will address the issue.
>
> Unfortunately the logs do not show anything - is there any configuration that will help me gather more info?
>
> Thanks
> Raghu
>
> Sent from my iPhone
> _______________________________________________
> 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/20150427/70db15d6/attachment.html 

From bburke at redhat.com  Mon Apr 27 08:37:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 08:37:05 -0400
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
References: <56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
Message-ID: <553E2D71.4020209@redhat.com>

I need to add a jira for 1.2.CR1 for generic migration.  Broker token 
access requires the creation of an application and role and its stupid 
to do it manually for every storage option.

On 4/27/2015 5:09 AM, Stian Thorgersen wrote:
> I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
>
> Remaining work:
>
> * KEYCLOAK-1229	Re-enable broker examples - Bill can you look at this?
> * KEYCLOAK-1189	SSLPeerUnverifiedException when deploying Keycloak with JDK 8 - I'm looking at this ATM, testing if including a httpcomponents module with slot=4.3 works
> * KEYCLOAK-1180	keycloak proxy needs different redirect uri config - Bill can you look at this? Or shall we just post-pone it?
> * KEYCLOAK-1040	Allow import of realm keys (like we do for SAML) - shall we post-pone this?
> * KEYCLOAK-1070	Persist client grants - almost done
>
> I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme by default", basically changing l&f of admin console to better match standard PatternFly. Ideally this would be done prior to 1.2.0.CR1 release, but I'm not sure how long it'll take. If IO can finish this tomorrow I'll include it, if not I'll post-pone it.
>
> Anything else? Would be great if everyone can look at distribution changes I did and comment/complain about it ASAP!
>
> We'll follow-up with a 1.2.0.Final next week.
> _______________________________________________
> 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  Mon Apr 27 09:48:29 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 09:48:29 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
References: <553AC645.1030906@redhat.com>
	<1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <553E3E2D.6020706@redhat.com>

What kind of web app is it?  Is it a servlet app using our adapter?

On 4/27/2015 5:52 AM, Raghu Prabhala wrote:
> It is a Client application (confidential) running on a different host.
> Was trying out the basic flow using the same id multiple times.  Opened
> up  IE browser, accessed the client application which invoked the OIDC
> basic flow, retrieving auth code, followed by tokens and finally user
> info. On successful retrieval of all that information, opened another
> tab instance of the browser and once again accessed the web application
> and the oidc flow followed. Did that with a few tab instances. Finally
> closed all the instances of the browser (didn't logoff from KC in any
> instance).
>
> Then started another cycle of the same process and then ran into that
> issue. It appears that when you login multiple times (around 8-10) to KC
> using the same user id in quick intervals without logging off, the issue
> occurs. Will continue to do some more testing today and hopefully can
> nail the behavior.
>
> Is there any configuration that will help me gather detailed logs?
>
>
>
> ------------------------------------------------------------------------
> *From:* Bill Burke <bburke at redhat.com>
> *To:* keycloak-dev at lists.jboss.org
> *Sent:* Friday, April 24, 2015 6:40 PM
> *Subject:* Re: [keycloak-dev] Oidc bug?
>
> What kind of app?  Login and logout 3 or 4 times?  Same user or
> different users?
>
>
>
> On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
>  > Bill,
>  >
>  > Sometime back I mentioned to you that I used to get a "connect
> refused" from KC when I tried the token end point.
>  >
>  > I think I am able to simulate it more often using 1.2 beta release -
> it happens randomly if you follow the below steps
>  > 1) open up browser and try the basic flow 3 or 4 times. Then close
> the browser
>  > 2) repeat the above 3 or 4 times and you may see the issue
>  >
>  > I believe it is due to the sessions KC creates.  Clearing the session
> from admin gui will address the issue.
>  >
>  > Unfortunately the logs do not show anything - is there any
> configuration that will help me gather more info?
>  >
>  > Thanks
>  > Raghu
>  >
>  > Sent from my iPhone
>
>  > _______________________________________________
>  > 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 <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 prabhalar at yahoo.com  Mon Apr 27 09:53:27 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Mon, 27 Apr 2015 09:53:27 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <553E3E2D.6020706@redhat.com>
References: <553AC645.1030906@redhat.com>
	<1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
	<553E3E2D.6020706@redhat.com>
Message-ID: <96A2FCCA-BE1A-4705-8A9A-F09D988026EC@yahoo.com>

Yes, servlet based but uses libraries based on Apache oltu. Those libraries and the web app were tested against Ping with no issues observed

Sent from my iPhone

> On Apr 27, 2015, at 9:48 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> What kind of web app is it?  Is it a servlet app using our adapter?
> 
>> On 4/27/2015 5:52 AM, Raghu Prabhala wrote:
>> It is a Client application (confidential) running on a different host.
>> Was trying out the basic flow using the same id multiple times.  Opened
>> up  IE browser, accessed the client application which invoked the OIDC
>> basic flow, retrieving auth code, followed by tokens and finally user
>> info. On successful retrieval of all that information, opened another
>> tab instance of the browser and once again accessed the web application
>> and the oidc flow followed. Did that with a few tab instances. Finally
>> closed all the instances of the browser (didn't logoff from KC in any
>> instance).
>> 
>> Then started another cycle of the same process and then ran into that
>> issue. It appears that when you login multiple times (around 8-10) to KC
>> using the same user id in quick intervals without logging off, the issue
>> occurs. Will continue to do some more testing today and hopefully can
>> nail the behavior.
>> 
>> Is there any configuration that will help me gather detailed logs?
>> 
>> 
>> 
>> ------------------------------------------------------------------------
>> *From:* Bill Burke <bburke at redhat.com>
>> *To:* keycloak-dev at lists.jboss.org
>> *Sent:* Friday, April 24, 2015 6:40 PM
>> *Subject:* Re: [keycloak-dev] Oidc bug?
>> 
>> What kind of app?  Login and logout 3 or 4 times?  Same user or
>> different users?
>> 
>> 
>> 
>> On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
>> > Bill,
>> >
>> > Sometime back I mentioned to you that I used to get a "connect
>> refused" from KC when I tried the token end point.
>> >
>> > I think I am able to simulate it more often using 1.2 beta release -
>> it happens randomly if you follow the below steps
>> > 1) open up browser and try the basic flow 3 or 4 times. Then close
>> the browser
>> > 2) repeat the above 3 or 4 times and you may see the issue
>> >
>> > I believe it is due to the sessions KC creates.  Clearing the session
>> from admin gui will address the issue.
>> >
>> > Unfortunately the logs do not show anything - is there any
>> configuration that will help me gather more info?
>> >
>> > Thanks
>> > Raghu
>> >
>> > Sent from my iPhone
>> 
>> > _______________________________________________
>> > 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 <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 bburke at redhat.com  Mon Apr 27 09:54:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 09:54:31 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <553E3E2D.6020706@redhat.com>
References: <553AC645.1030906@redhat.com>	<1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
	<553E3E2D.6020706@redhat.com>
Message-ID: <553E3F97.9080608@redhat.com>

I don't understand why Keycloak would even be accessed after the first 
login.  For a servlet app with our adapter, when you open the 2nd tab, 
cookies are already set in the client app and you are already logged in.

On 4/27/2015 9:48 AM, Bill Burke wrote:
> What kind of web app is it?  Is it a servlet app using our adapter?
>
> On 4/27/2015 5:52 AM, Raghu Prabhala wrote:
>> It is a Client application (confidential) running on a different host.
>> Was trying out the basic flow using the same id multiple times.  Opened
>> up  IE browser, accessed the client application which invoked the OIDC
>> basic flow, retrieving auth code, followed by tokens and finally user
>> info. On successful retrieval of all that information, opened another
>> tab instance of the browser and once again accessed the web application
>> and the oidc flow followed. Did that with a few tab instances. Finally
>> closed all the instances of the browser (didn't logoff from KC in any
>> instance).
>>
>> Then started another cycle of the same process and then ran into that
>> issue. It appears that when you login multiple times (around 8-10) to KC
>> using the same user id in quick intervals without logging off, the issue
>> occurs. Will continue to do some more testing today and hopefully can
>> nail the behavior.
>>
>> Is there any configuration that will help me gather detailed logs?
>>
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Bill Burke <bburke at redhat.com>
>> *To:* keycloak-dev at lists.jboss.org
>> *Sent:* Friday, April 24, 2015 6:40 PM
>> *Subject:* Re: [keycloak-dev] Oidc bug?
>>
>> What kind of app?  Login and logout 3 or 4 times?  Same user or
>> different users?
>>
>>
>>
>> On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
>>   > Bill,
>>   >
>>   > Sometime back I mentioned to you that I used to get a "connect
>> refused" from KC when I tried the token end point.
>>   >
>>   > I think I am able to simulate it more often using 1.2 beta release -
>> it happens randomly if you follow the below steps
>>   > 1) open up browser and try the basic flow 3 or 4 times. Then close
>> the browser
>>   > 2) repeat the above 3 or 4 times and you may see the issue
>>   >
>>   > I believe it is due to the sessions KC creates.  Clearing the session
>> from admin gui will address the issue.
>>   >
>>   > Unfortunately the logs do not show anything - is there any
>> configuration that will help me gather more info?
>>   >
>>   > Thanks
>>   > Raghu
>>   >
>>   > Sent from my iPhone
>>
>>   > _______________________________________________
>>   > 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 <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 bburke at redhat.com  Mon Apr 27 10:01:43 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 10:01:43 -0400
Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
Message-ID: <553E4147.2000902@redhat.com>

Maybe there is no need to have a separate demo and server dist?  The 
difference is 2 Megabytes. 148 vs. 146.

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

From prabhalar at yahoo.com  Mon Apr 27 10:09:53 2015
From: prabhalar at yahoo.com (Raghu Prabhala)
Date: Mon, 27 Apr 2015 10:09:53 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <553E3F97.9080608@redhat.com>
References: <553AC645.1030906@redhat.com>
	<1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
	<553E3E2D.6020706@redhat.com> <553E3F97.9080608@redhat.com>
Message-ID: <F56DE772-D23B-4999-A207-C25594F81CD0@yahoo.com>

We are not using KC adapters. We typically provide all our clients with our libraries which will be used in their client applications and their requirements vary. Some of them do not use sessions in their applications. So, in those cases, each request to their application will trigger an authentication request to KC. Even though that is not ideal, we have to support them.

Sent from my iPhone

> On Apr 27, 2015, at 9:54 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> I don't understand why Keycloak would even be accessed after the first 
> login.  For a servlet app with our adapter, when you open the 2nd tab, 
> cookies are already set in the client app and you are already logged in.
> 
>> On 4/27/2015 9:48 AM, Bill Burke wrote:
>> What kind of web app is it?  Is it a servlet app using our adapter?
>> 
>>> On 4/27/2015 5:52 AM, Raghu Prabhala wrote:
>>> It is a Client application (confidential) running on a different host.
>>> Was trying out the basic flow using the same id multiple times.  Opened
>>> up  IE browser, accessed the client application which invoked the OIDC
>>> basic flow, retrieving auth code, followed by tokens and finally user
>>> info. On successful retrieval of all that information, opened another
>>> tab instance of the browser and once again accessed the web application
>>> and the oidc flow followed. Did that with a few tab instances. Finally
>>> closed all the instances of the browser (didn't logoff from KC in any
>>> instance).
>>> 
>>> Then started another cycle of the same process and then ran into that
>>> issue. It appears that when you login multiple times (around 8-10) to KC
>>> using the same user id in quick intervals without logging off, the issue
>>> occurs. Will continue to do some more testing today and hopefully can
>>> nail the behavior.
>>> 
>>> Is there any configuration that will help me gather detailed logs?
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------
>>> *From:* Bill Burke <bburke at redhat.com>
>>> *To:* keycloak-dev at lists.jboss.org
>>> *Sent:* Friday, April 24, 2015 6:40 PM
>>> *Subject:* Re: [keycloak-dev] Oidc bug?
>>> 
>>> What kind of app?  Login and logout 3 or 4 times?  Same user or
>>> different users?
>>> 
>>> 
>>> 
>>>> On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
>>>> Bill,
>>>> 
>>>> Sometime back I mentioned to you that I used to get a "connect
>>> refused" from KC when I tried the token end point.
>>>> 
>>>> I think I am able to simulate it more often using 1.2 beta release -
>>> it happens randomly if you follow the below steps
>>>> 1) open up browser and try the basic flow 3 or 4 times. Then close
>>> the browser
>>>> 2) repeat the above 3 or 4 times and you may see the issue
>>>> 
>>>> I believe it is due to the sessions KC creates.  Clearing the session
>>> from admin gui will address the issue.
>>>> 
>>>> Unfortunately the logs do not show anything - is there any
>>> configuration that will help me gather more info?
>>>> 
>>>> Thanks
>>>> Raghu
>>>> 
>>>> Sent from my iPhone
>>> 
>>>> _______________________________________________
>>>> 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 <http://bill.burkecentral.com/>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Mon Apr 27 10:24:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 10:24:11 -0400 (EDT)
Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
In-Reply-To: <553E4147.2000902@redhat.com>
References: <553E4147.2000902@redhat.com>
Message-ID: <1179569168.7358709.1430144651017.JavaMail.zimbra@redhat.com>

The plan is that server-dist will be built on WF servlets-only and should be ~30MB or something. It would not include the adapters, nor support deploying JEE apps.

The demo-dist will include the docs and examples. It would include WF full. Also, my hope was that the demo would come pre-configured and deployed. So to try Keycloak and demos all that is required is to dl, extract and run this bundle.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 27 April, 2015 4:01:43 PM
> Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
> 
> Maybe there is no need to have a separate demo and server dist?  The
> difference is 2 Megabytes. 148 vs. 146.
> 
> --
> 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  Mon Apr 27 10:25:57 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 10:25:57 -0400
Subject: [keycloak-dev] Oidc bug?
In-Reply-To: <F56DE772-D23B-4999-A207-C25594F81CD0@yahoo.com>
References: <553AC645.1030906@redhat.com>
	<1177854029.4974412.1430128371489.JavaMail.yahoo@mail.yahoo.com>
	<553E3E2D.6020706@redhat.com> <553E3F97.9080608@redhat.com>
	<F56DE772-D23B-4999-A207-C25594F81CD0@yahoo.com>
Message-ID: <553E46F5.9060008@redhat.com>

Raghu, you really need to come with more information or it is next to 
impossible for me to debug your issues.

What is your KC setup?  What kind of UserSessions are you using? 
in-memory?  JPA?  Mongo?  What is your user store?  Realm store?  There 
is no server side stack trace?  Just nothing?  No warning?  No error 
message, nothing?  An example app with steps to reproduce the problem 
would be preferred.

I tried logging in and closing browser, relogin, about 15 times in a row 
and I don't see your problem.

On 4/27/2015 10:09 AM, Raghu Prabhala wrote:
> We are not using KC adapters. We typically provide all our clients with our libraries which will be used in their client applications and their requirements vary. Some of them do not use sessions in their applications. So, in those cases, each request to their application will trigger an authentication request to KC. Even though that is not ideal, we have to support them.
>
> Sent from my iPhone
>
>> On Apr 27, 2015, at 9:54 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>> I don't understand why Keycloak would even be accessed after the first
>> login.  For a servlet app with our adapter, when you open the 2nd tab,
>> cookies are already set in the client app and you are already logged in.
>>
>>> On 4/27/2015 9:48 AM, Bill Burke wrote:
>>> What kind of web app is it?  Is it a servlet app using our adapter?
>>>
>>>> On 4/27/2015 5:52 AM, Raghu Prabhala wrote:
>>>> It is a Client application (confidential) running on a different host.
>>>> Was trying out the basic flow using the same id multiple times.  Opened
>>>> up  IE browser, accessed the client application which invoked the OIDC
>>>> basic flow, retrieving auth code, followed by tokens and finally user
>>>> info. On successful retrieval of all that information, opened another
>>>> tab instance of the browser and once again accessed the web application
>>>> and the oidc flow followed. Did that with a few tab instances. Finally
>>>> closed all the instances of the browser (didn't logoff from KC in any
>>>> instance).
>>>>
>>>> Then started another cycle of the same process and then ran into that
>>>> issue. It appears that when you login multiple times (around 8-10) to KC
>>>> using the same user id in quick intervals without logging off, the issue
>>>> occurs. Will continue to do some more testing today and hopefully can
>>>> nail the behavior.
>>>>
>>>> Is there any configuration that will help me gather detailed logs?
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>> *From:* Bill Burke <bburke at redhat.com>
>>>> *To:* keycloak-dev at lists.jboss.org
>>>> *Sent:* Friday, April 24, 2015 6:40 PM
>>>> *Subject:* Re: [keycloak-dev] Oidc bug?
>>>>
>>>> What kind of app?  Login and logout 3 or 4 times?  Same user or
>>>> different users?
>>>>
>>>>
>>>>
>>>>> On 4/24/2015 4:44 PM, Raghu Prabhala wrote:
>>>>> Bill,
>>>>>
>>>>> Sometime back I mentioned to you that I used to get a "connect
>>>> refused" from KC when I tried the token end point.
>>>>>
>>>>> I think I am able to simulate it more often using 1.2 beta release -
>>>> it happens randomly if you follow the below steps
>>>>> 1) open up browser and try the basic flow 3 or 4 times. Then close
>>>> the browser
>>>>> 2) repeat the above 3 or 4 times and you may see the issue
>>>>>
>>>>> I believe it is due to the sessions KC creates.  Clearing the session
>>>> from admin gui will address the issue.
>>>>>
>>>>> Unfortunately the logs do not show anything - is there any
>>>> configuration that will help me gather more info?
>>>>>
>>>>> Thanks
>>>>> Raghu
>>>>>
>>>>> Sent from my iPhone
>>>>
>>>>> _______________________________________________
>>>>> 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 <http://bill.burkecentral.com/>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Mon Apr 27 10:43:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 10:43:12 -0400
Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
In-Reply-To: <1179569168.7358709.1430144651017.JavaMail.zimbra@redhat.com>
References: <553E4147.2000902@redhat.com>
	<1179569168.7358709.1430144651017.JavaMail.zimbra@redhat.com>
Message-ID: <553E4B00.4070407@redhat.com>

FYI, the screencast tutorials assume a clean, unconfigured keycloak 
server.  Also, remember that any directory structure change in the 
distro makes the screencasts tutorials out of date.


On 4/27/2015 10:24 AM, Stian Thorgersen wrote:
> The plan is that server-dist will be built on WF servlets-only and should be ~30MB or something. It would not include the adapters, nor support deploying JEE apps.
>
> The demo-dist will include the docs and examples. It would include WF full. Also, my hope was that the demo would come pre-configured and deployed. So to try Keycloak and demos all that is required is to dl, extract and run this bundle.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 27 April, 2015 4:01:43 PM
>> Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
>>
>> Maybe there is no need to have a separate demo and server dist?  The
>> difference is 2 Megabytes. 148 vs. 146.
>>
>> --
>> 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 srossillo at smartling.com  Mon Apr 27 11:31:55 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Mon, 27 Apr 2015 11:31:55 -0400
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
References: <1538677483.7117804.1430125403512.JavaMail.zimbra@redhat.com>
	<56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
Message-ID: <CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>

We're hoping to send a PR for KEYCLOAK-1238
<https://issues.jboss.org/browse/KEYCLOAK-1238> (I just created JIRA) by
end of day today. Hopefully you guys can review and include in RC1. If not,
we'll figure something out.

I'll followup after the PR and some demos are published.

Best,
Scott

On Mon, Apr 27, 2015 at 5:09 AM, Stian Thorgersen <stian at redhat.com> wrote:

> I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
>
> Remaining work:
>
> * KEYCLOAK-1229 Re-enable broker examples - Bill can you look at this?
> * KEYCLOAK-1189 SSLPeerUnverifiedException when deploying Keycloak with
> JDK 8 - I'm looking at this ATM, testing if including a httpcomponents
> module with slot=4.3 works
> * KEYCLOAK-1180 keycloak proxy needs different redirect uri config - Bill
> can you look at this? Or shall we just post-pone it?
> * KEYCLOAK-1040 Allow import of realm keys (like we do for SAML) - shall
> we post-pone this?
> * KEYCLOAK-1070 Persist client grants - almost done
>
> I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme by
> default", basically changing l&f of admin console to better match standard
> PatternFly. Ideally this would be done prior to 1.2.0.CR1 release, but I'm
> not sure how long it'll take. If IO can finish this tomorrow I'll include
> it, if not I'll post-pone it.
>
> Anything else? Would be great if everyone can look at distribution changes
> I did and comment/complain about it ASAP!
>
> We'll follow-up with a 1.2.0.Final next week.
> _______________________________________________
> 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/20150427/e3257d7f/attachment.html 

From giriraj.sharma27 at gmail.com  Mon Apr 27 11:47:18 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Mon, 27 Apr 2015 21:17:18 +0530
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>
References: <1538677483.7117804.1430125403512.JavaMail.zimbra@redhat.com>
	<56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
	<CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>
Message-ID: <CAB5vuUxNeVXVC-gH-BSNzG-F=K6Y5ZMAz5PeFf5DjoRPgJ1QnQ@mail.gmail.com>

I submitted PR for [KEYCLOAK-392
<https://issues.jboss.org/browse/KEYCLOAK-392>] - *Admin audit events* last
weekend but it shall not be easy to review and include it in the next RC1
release considering that the tentative date for release is Wednesday.
We can rather consider it for the next to next release or after whenever it
is reviewed.

On Mon, Apr 27, 2015 at 9:01 PM, Scott Rossillo <srossillo at smartling.com>
wrote:

> We're hoping to send a PR for KEYCLOAK-1238
> <https://issues.jboss.org/browse/KEYCLOAK-1238> (I just created JIRA) by
> end of day today. Hopefully you guys can review and include in RC1. If not,
> we'll figure something out.
>
> I'll followup after the PR and some demos are published.
>
> Best,
> Scott
>
> On Mon, Apr 27, 2015 at 5:09 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>> I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
>>
>> Remaining work:
>>
>> * KEYCLOAK-1229 Re-enable broker examples - Bill can you look at this?
>> * KEYCLOAK-1189 SSLPeerUnverifiedException when deploying Keycloak with
>> JDK 8 - I'm looking at this ATM, testing if including a httpcomponents
>> module with slot=4.3 works
>> * KEYCLOAK-1180 keycloak proxy needs different redirect uri config - Bill
>> can you look at this? Or shall we just post-pone it?
>> * KEYCLOAK-1040 Allow import of realm keys (like we do for SAML) - shall
>> we post-pone this?
>> * KEYCLOAK-1070 Persist client grants - almost done
>>
>> I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme
>> by default", basically changing l&f of admin console to better match
>> standard PatternFly. Ideally this would be done prior to 1.2.0.CR1 release,
>> but I'm not sure how long it'll take. If IO can finish this tomorrow I'll
>> include it, if not I'll post-pone it.
>>
>> Anything else? Would be great if everyone can look at distribution
>> changes I did and comment/complain about it ASAP!
>>
>> We'll follow-up with a 1.2.0.Final next week.
>> _______________________________________________
>> 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/20150427/02453086/attachment.html 

From stian at redhat.com  Mon Apr 27 13:10:25 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 13:10:25 -0400 (EDT)
Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
In-Reply-To: <553E4B00.4070407@redhat.com>
References: <553E4147.2000902@redhat.com>
	<1179569168.7358709.1430144651017.JavaMail.zimbra@redhat.com>
	<553E4B00.4070407@redhat.com>
Message-ID: <1703765811.7510443.1430154625722.JavaMail.zimbra@redhat.com>

The screencast will have to be redone soon in either case as we're doing changes to the admin console.

With the main server distribution not being a JEE server any more the demo/screencast will either have to use the standalone server + separate WF server. Or to install the server and subsystem into an existing WF server. I'd say we should cater for both. KC + WF full is for development, KC standalone + separate WF is for production.

----- 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, 27 April, 2015 4:43:12 PM
> Subject: Re: [keycloak-dev] 2M diff between demo-dist and server-dist
> 
> FYI, the screencast tutorials assume a clean, unconfigured keycloak
> server.  Also, remember that any directory structure change in the
> distro makes the screencasts tutorials out of date.
> 
> 
> On 4/27/2015 10:24 AM, Stian Thorgersen wrote:
> > The plan is that server-dist will be built on WF servlets-only and should
> > be ~30MB or something. It would not include the adapters, nor support
> > deploying JEE apps.
> >
> > The demo-dist will include the docs and examples. It would include WF full.
> > Also, my hope was that the demo would come pre-configured and deployed. So
> > to try Keycloak and demos all that is required is to dl, extract and run
> > this bundle.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 27 April, 2015 4:01:43 PM
> >> Subject: [keycloak-dev] 2M diff between demo-dist and server-dist
> >>
> >> Maybe there is no need to have a separate demo and server dist?  The
> >> difference is 2 Megabytes. 148 vs. 146.
> >>
> >> --
> >> 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  Mon Apr 27 13:11:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 13:11:33 -0400 (EDT)
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <CAB5vuUxNeVXVC-gH-BSNzG-F=K6Y5ZMAz5PeFf5DjoRPgJ1QnQ@mail.gmail.com>
References: <1538677483.7117804.1430125403512.JavaMail.zimbra@redhat.com>
	<56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
	<CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>
	<CAB5vuUxNeVXVC-gH-BSNzG-F=K6Y5ZMAz5PeFf5DjoRPgJ1QnQ@mail.gmail.com>
Message-ID: <1607092746.7510930.1430154693401.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Giriraj Sharma" <giriraj.sharma27 at gmail.com>
> To: "Scott Rossillo" <srossillo at smartling.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 27 April, 2015 5:47:18 PM
> Subject: Re: [keycloak-dev] 1.2.0.CR1 release on Wednesday
> 
> I submitted PR for [KEYCLOAK-392
> <https://issues.jboss.org/browse/KEYCLOAK-392>] - *Admin audit events* last
> weekend but it shall not be easy to review and include it in the next RC1
> release considering that the tentative date for release is Wednesday.
> We can rather consider it for the next to next release or after whenever it
> is reviewed.

I wasn't aware you'd completed it, my bad. I'll look at it tomorrow and see if it's ready to include.

> 
> On Mon, Apr 27, 2015 at 9:01 PM, Scott Rossillo <srossillo at smartling.com>
> wrote:
> 
> > We're hoping to send a PR for KEYCLOAK-1238
> > <https://issues.jboss.org/browse/KEYCLOAK-1238> (I just created JIRA) by
> > end of day today. Hopefully you guys can review and include in RC1. If not,
> > we'll figure something out.
> >
> > I'll followup after the PR and some demos are published.
> >
> > Best,
> > Scott
> >
> > On Mon, Apr 27, 2015 at 5:09 AM, Stian Thorgersen <stian at redhat.com>
> > wrote:
> >
> >> I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
> >>
> >> Remaining work:
> >>
> >> * KEYCLOAK-1229 Re-enable broker examples - Bill can you look at this?
> >> * KEYCLOAK-1189 SSLPeerUnverifiedException when deploying Keycloak with
> >> JDK 8 - I'm looking at this ATM, testing if including a httpcomponents
> >> module with slot=4.3 works
> >> * KEYCLOAK-1180 keycloak proxy needs different redirect uri config - Bill
> >> can you look at this? Or shall we just post-pone it?
> >> * KEYCLOAK-1040 Allow import of realm keys (like we do for SAML) - shall
> >> we post-pone this?
> >> * KEYCLOAK-1070 Persist client grants - almost done
> >>
> >> I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme
> >> by default", basically changing l&f of admin console to better match
> >> standard PatternFly. Ideally this would be done prior to 1.2.0.CR1
> >> release,
> >> but I'm not sure how long it'll take. If IO can finish this tomorrow I'll
> >> include it, if not I'll post-pone it.
> >>
> >> Anything else? Would be great if everyone can look at distribution
> >> changes I did and comment/complain about it ASAP!
> >>
> >> We'll follow-up with a 1.2.0.Final next week.
> >> _______________________________________________
> >> 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
> 

From stian at redhat.com  Mon Apr 27 13:12:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 27 Apr 2015 13:12:54 -0400 (EDT)
Subject: [keycloak-dev] 1.2.0.CR1 release on Wednesday
In-Reply-To: <CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>
References: <1538677483.7117804.1430125403512.JavaMail.zimbra@redhat.com>
	<56383819.7121639.1430125769412.JavaMail.zimbra@redhat.com>
	<CALAqdu9ZOVmGXdYptL5w+-QaOsGBxALEVZiZsMkYdmeKa51RZQ@mail.gmail.com>
Message-ID: <1525178794.7511405.1430154774388.JavaMail.zimbra@redhat.com>

If there's example and docs included in the PR and we can easily test it then we can try to include it.

----- Original Message -----
> From: "Scott Rossillo" <srossillo at smartling.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, 27 April, 2015 5:31:55 PM
> Subject: Re: [keycloak-dev] 1.2.0.CR1 release on Wednesday
> 
> We're hoping to send a PR for KEYCLOAK-1238
> <https://issues.jboss.org/browse/KEYCLOAK-1238> (I just created JIRA) by
> end of day today. Hopefully you guys can review and include in RC1. If not,
> we'll figure something out.
> 
> I'll followup after the PR and some demos are published.
> 
> Best,
> Scott
> 
> On Mon, Apr 27, 2015 at 5:09 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > I'd like to release 1.2.0.CR1 on Wednesday (or Thursday at the latest!).
> >
> > Remaining work:
> >
> > * KEYCLOAK-1229 Re-enable broker examples - Bill can you look at this?
> > * KEYCLOAK-1189 SSLPeerUnverifiedException when deploying Keycloak with
> > JDK 8 - I'm looking at this ATM, testing if including a httpcomponents
> > module with slot=4.3 works
> > * KEYCLOAK-1180 keycloak proxy needs different redirect uri config - Bill
> > can you look at this? Or shall we just post-pone it?
> > * KEYCLOAK-1040 Allow import of realm keys (like we do for SAML) - shall
> > we post-pone this?
> > * KEYCLOAK-1070 Persist client grants - almost done
> >
> > I'd also like to do "KEYCLOAK-887 Use standard RCUE or Patternfly theme by
> > default", basically changing l&f of admin console to better match standard
> > PatternFly. Ideally this would be done prior to 1.2.0.CR1 release, but I'm
> > not sure how long it'll take. If IO can finish this tomorrow I'll include
> > it, if not I'll post-pone it.
> >
> > Anything else? Would be great if everyone can look at distribution changes
> > I did and comment/complain about it ASAP!
> >
> > We'll follow-up with a 1.2.0.Final next week.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 

From bburke at redhat.com  Mon Apr 27 16:15:23 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 27 Apr 2015 16:15:23 -0400
Subject: [keycloak-dev] generic model migration
Message-ID: <553E98DB.8030408@redhat.com>

I implemented this as a singleton data item in JPA or Mongo or File.  I 
jsut store the current version.  Implementation is in 
MigrationModelManager and it just checks the currently stored version 
versus the deployed version.  Its all hardcoded at the moment, but does 
give some abstraction.  I think it is good enough going forward.  Don't 
need anything fancy.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Mon Apr 27 17:37:18 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 27 Apr 2015 23:37:18 +0200
Subject: [keycloak-dev] generic model migration
In-Reply-To: <553E98DB.8030408@redhat.com>
References: <553E98DB.8030408@redhat.com>
Message-ID: <553EAC0E.9040103@redhat.com>

TBH, I am not sure if it's the way to go...

The problem is that implementation like MigrationTo1_2_0_RC1 is directly 
using Model API. This can be problematic IMO because when your DB is in 
old version and you call the model operation like:

realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID);

it could fail as source code is in newest version and hence JPA 
implementation expects the newest DB schema and fields in DB. But 
database is in old version and doesn't yet have those fields. That's why 
it seems to me that only stable way of migration is really the "native" 
calling of DB operations, which sucks but should work :-\

Marek

On 27.4.2015 22:15, Bill Burke wrote:
> I implemented this as a singleton data item in JPA or Mongo or File.  I
> jsut store the current version.  Implementation is in
> MigrationModelManager and it just checks the currently stored version
> versus the deployed version.  Its all hardcoded at the moment, but does
> give some abstraction.  I think it is good enough going forward.  Don't
> need anything fancy.


From stian at redhat.com  Tue Apr 28 00:27:41 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Apr 2015 00:27:41 -0400 (EDT)
Subject: [keycloak-dev] generic model migration
In-Reply-To: <553EAC0E.9040103@redhat.com>
References: <553E98DB.8030408@redhat.com> <553EAC0E.9040103@redhat.com>
Message-ID: <942540143.7737020.1430195261845.JavaMail.zimbra@redhat.com>

I reckon it works, but older updates will have to be refactored when we change the model.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, April 27, 2015 11:37:18 PM
> Subject: Re: [keycloak-dev] generic model migration
> 
> TBH, I am not sure if it's the way to go...
> 
> The problem is that implementation like MigrationTo1_2_0_RC1 is directly
> using Model API. This can be problematic IMO because when your DB is in
> old version and you call the model operation like:
> 
> realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID);
> 
> it could fail as source code is in newest version and hence JPA
> implementation expects the newest DB schema and fields in DB. But
> database is in old version and doesn't yet have those fields. That's why
> it seems to me that only stable way of migration is really the "native"
> calling of DB operations, which sucks but should work :-\
> 
> Marek
> 
> On 27.4.2015 22:15, Bill Burke wrote:
> > I implemented this as a singleton data item in JPA or Mongo or File.  I
> > jsut store the current version.  Implementation is in
> > MigrationModelManager and it just checks the currently stored version
> > versus the deployed version.  Its all hardcoded at the moment, but does
> > give some abstraction.  I think it is good enough going forward.  Don't
> > need anything fancy.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Apr 28 02:16:01 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 28 Apr 2015 08:16:01 +0200
Subject: [keycloak-dev] generic model migration
In-Reply-To: <942540143.7737020.1430195261845.JavaMail.zimbra@redhat.com>
References: <553E98DB.8030408@redhat.com> <553EAC0E.9040103@redhat.com>
	<942540143.7737020.1430195261845.JavaMail.zimbra@redhat.com>
Message-ID: <553F25A1.5020001@redhat.com>

Ah, sorry. I somehow missed the MigrationModelManager is executed after 
the DB schema is already updated. My bad. Shouldn't write emails so late 
in the night ;-)

Marek

On 28.4.2015 06:27, Stian Thorgersen wrote:
> I reckon it works, but older updates will have to be refactored when we change the model.
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, April 27, 2015 11:37:18 PM
>> Subject: Re: [keycloak-dev] generic model migration
>>
>> TBH, I am not sure if it's the way to go...
>>
>> The problem is that implementation like MigrationTo1_2_0_RC1 is directly
>> using Model API. This can be problematic IMO because when your DB is in
>> old version and you call the model operation like:
>>
>> realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID);
>>
>> it could fail as source code is in newest version and hence JPA
>> implementation expects the newest DB schema and fields in DB. But
>> database is in old version and doesn't yet have those fields. That's why
>> it seems to me that only stable way of migration is really the "native"
>> calling of DB operations, which sucks but should work :-\
>>
>> Marek
>>
>> On 27.4.2015 22:15, Bill Burke wrote:
>>> I implemented this as a singleton data item in JPA or Mongo or File.  I
>>> jsut store the current version.  Implementation is in
>>> MigrationModelManager and it just checks the currently stored version
>>> versus the deployed version.  Its all hardcoded at the moment, but does
>>> give some abstraction.  I think it is good enough going forward.  Don't
>>> need anything fancy.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bdawidow at redhat.com  Tue Apr 28 03:33:15 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Tue, 28 Apr 2015 09:33:15 +0200
Subject: [keycloak-dev] Supported environments
In-Reply-To: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
Message-ID: <553F37BB.3070903@redhat.com>



W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
> For 1.2.0.Final the server should be deployable to:
>
> * WildFly 8.2.0.Final
> * EAP 6.4.0.GA
>
> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's released). As APIs has changed, and there's also new features in WF 9 we can leverage, the cleanest way to do this is to drop support for deploying to EAP 6.4.0.GA.
>
> With regards to adapters what versions should we support:
>
> * AS7 - can we drop this?
> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and 9.0.0.Final)?
> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3, 6.4)?

Would go with only latest stable WF and only last minor of EAP 6.

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

-- 
Boles?aw Dawidowicz


From bburke at redhat.com  Tue Apr 28 08:24:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Apr 2015 08:24:16 -0400
Subject: [keycloak-dev] generic model migration
In-Reply-To: <553F25A1.5020001@redhat.com>
References: <553E98DB.8030408@redhat.com> <553EAC0E.9040103@redhat.com>
	<942540143.7737020.1430195261845.JavaMail.zimbra@redhat.com>
	<553F25A1.5020001@redhat.com>
Message-ID: <553F7BF0.2070708@redhat.com>

You're right though.  It will break and need to be refactored.  But our 
model is pretty stable.

On 4/28/2015 2:16 AM, Marek Posolda wrote:
> Ah, sorry. I somehow missed the MigrationModelManager is executed after
> the DB schema is already updated. My bad. Shouldn't write emails so late
> in the night ;-)
>
> Marek
>
> On 28.4.2015 06:27, Stian Thorgersen wrote:
>> I reckon it works, but older updates will have to be refactored when
>> we change the model.
>>
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>>> Sent: Monday, April 27, 2015 11:37:18 PM
>>> Subject: Re: [keycloak-dev] generic model migration
>>>
>>> TBH, I am not sure if it's the way to go...
>>>
>>> The problem is that implementation like MigrationTo1_2_0_RC1 is directly
>>> using Model API. This can be problematic IMO because when your DB is in
>>> old version and you call the model operation like:
>>>
>>> realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID);
>>>
>>> it could fail as source code is in newest version and hence JPA
>>> implementation expects the newest DB schema and fields in DB. But
>>> database is in old version and doesn't yet have those fields. That's why
>>> it seems to me that only stable way of migration is really the "native"
>>> calling of DB operations, which sucks but should work :-\
>>>
>>> Marek
>>>
>>> On 27.4.2015 22:15, Bill Burke wrote:
>>>> I implemented this as a singleton data item in JPA or Mongo or File.  I
>>>> jsut store the current version.  Implementation is in
>>>> MigrationModelManager and it just checks the currently stored version
>>>> versus the deployed version.  Its all hardcoded at the moment, but does
>>>> give some abstraction.  I think it is good enough going forward.  Don't
>>>> need anything fancy.
>>> _______________________________________________
>>> 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 Apr 28 10:00:46 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Apr 2015 10:00:46 -0400
Subject: [keycloak-dev] Supported environments
In-Reply-To: <553F37BB.3070903@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com>
Message-ID: <553F928E.9010805@redhat.com>



On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
>
>
> W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
>> For 1.2.0.Final the server should be deployable to:
>>
>> * WildFly 8.2.0.Final
>> * EAP 6.4.0.GA
>>
>> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's released). As APIs has changed, and there's also new features in WF 9 we can leverage, the cleanest way to do this is to drop support for deploying to EAP 6.4.0.GA.
>>
>> With regards to adapters what versions should we support:
>>
>> * AS7 - can we drop this?
>> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and 9.0.0.Final)?
>> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3, 6.4)?
>
> Would go with only latest stable WF and only last minor of EAP 6.
>

We should never drop adapter support for any platform.   The larger our 
adapter pool, the larger our user base will be.

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

From stian at redhat.com  Tue Apr 28 10:02:37 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 28 Apr 2015 10:02:37 -0400 (EDT)
Subject: [keycloak-dev] Supported environments
In-Reply-To: <553F928E.9010805@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com> <553F928E.9010805@redhat.com>
Message-ID: <1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, April 28, 2015 4:00:46 PM
> Subject: Re: [keycloak-dev] Supported environments
> 
> 
> 
> On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
> >
> >
> > W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
> >> For 1.2.0.Final the server should be deployable to:
> >>
> >> * WildFly 8.2.0.Final
> >> * EAP 6.4.0.GA
> >>
> >> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's
> >> released). As APIs has changed, and there's also new features in WF 9 we
> >> can leverage, the cleanest way to do this is to drop support for
> >> deploying to EAP 6.4.0.GA.
> >>
> >> With regards to adapters what versions should we support:
> >>
> >> * AS7 - can we drop this?
> >> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and
> >> 9.0.0.Final)?
> >> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3,
> >> 6.4)?
> >
> > Would go with only latest stable WF and only last minor of EAP 6.
> >
> 
> We should never drop adapter support for any platform.   The larger our
> adapter pool, the larger our user base will be.

So we're maintaining AS7 support for ever?!?

> 
> --
> 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 guydavis.ca at gmail.com  Tue Apr 28 10:47:27 2015
From: guydavis.ca at gmail.com (Guy Davis)
Date: Tue, 28 Apr 2015 08:47:27 -0600
Subject: [keycloak-dev] Supported environments
In-Reply-To: <1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com> <553F928E.9010805@redhat.com>
	<1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
Message-ID: <CAAgmn1qTTCr1_zn8mSsumprTjUtLnz7mURN7p+W3PYXBHf1WXw@mail.gmail.com>

+1 for maintaining AS 7 adapter support for a while longer.  For various
reasons, we're still stuck on the JBoss AS7 for another 6 months or so.
Keeping this Keycloak adapter for now would be very much appreciated!

Thanks,
Guy

On Tue, Apr 28, 2015 at 8:02 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, April 28, 2015 4:00:46 PM
> > Subject: Re: [keycloak-dev] Supported environments
> >
> >
> >
> > On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
> > >
> > >
> > > W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
> > >> For 1.2.0.Final the server should be deployable to:
> > >>
> > >> * WildFly 8.2.0.Final
> > >> * EAP 6.4.0.GA
> > >>
> > >> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's
> > >> released). As APIs has changed, and there's also new features in WF 9
> we
> > >> can leverage, the cleanest way to do this is to drop support for
> > >> deploying to EAP 6.4.0.GA.
> > >>
> > >> With regards to adapters what versions should we support:
> > >>
> > >> * AS7 - can we drop this?
> > >> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and
> > >> 9.0.0.Final)?
> > >> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3,
> > >> 6.4)?
> > >
> > > Would go with only latest stable WF and only last minor of EAP 6.
> > >
> >
> > We should never drop adapter support for any platform.   The larger our
> > adapter pool, the larger our user base will be.
>
> So we're maintaining AS7 support for ever?!?
>
> >
> > --
> > 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/20150428/829a0fc1/attachment-0001.html 

From bburke at redhat.com  Tue Apr 28 11:14:45 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 28 Apr 2015 11:14:45 -0400
Subject: [keycloak-dev] Supported environments
In-Reply-To: <1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com> <553F928E.9010805@redhat.com>
	<1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
Message-ID: <553FA3E5.9050905@redhat.com>



On 4/28/2015 10:02 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, April 28, 2015 4:00:46 PM
>> Subject: Re: [keycloak-dev] Supported environments
>>
>>
>>
>> On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
>>>
>>>
>>> W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
>>>> For 1.2.0.Final the server should be deployable to:
>>>>
>>>> * WildFly 8.2.0.Final
>>>> * EAP 6.4.0.GA
>>>>
>>>> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's
>>>> released). As APIs has changed, and there's also new features in WF 9 we
>>>> can leverage, the cleanest way to do this is to drop support for
>>>> deploying to EAP 6.4.0.GA.
>>>>
>>>> With regards to adapters what versions should we support:
>>>>
>>>> * AS7 - can we drop this?
>>>> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and
>>>> 9.0.0.Final)?
>>>> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3,
>>>> 6.4)?
>>>
>>> Would go with only latest stable WF and only last minor of EAP 6.
>>>
>>
>> We should never drop adapter support for any platform.   The larger our
>> adapter pool, the larger our user base will be.
>
> So we're maintaining AS7 support for ever?!?
>

I don't think it will be much of an issue.  These old platforms are 
pretty static and the adapters are generic enough to evolve.


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

From mposolda at redhat.com  Tue Apr 28 11:52:11 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 28 Apr 2015 17:52:11 +0200
Subject: [keycloak-dev] "Direct grants only" switch broken in admin console
Message-ID: <553FACAB.2050800@redhat.com>

The "Direct grants only" switch doesn't seem to work in admin console in 
Clients screen. It doesn't hide redirect URI and value is not persisted 
(it's always off).

Recently we discussed to convert it into combobox of 3 states:
1) Direct grants only, which hides redirect URI
2) Direct grants enabled
3) Direct grants disabled

but I am not sure if we agree on it.

Maybe for RC1 we can just hide the switch from UI and then for 
1.2.0.Final we can properly fix it and convert it into the combobox. 
What do you think?

Marek

From mposolda at redhat.com  Wed Apr 29 10:00:30 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 29 Apr 2015 16:00:30 +0200
Subject: [keycloak-dev] Distribution changes
In-Reply-To: <1002185417.5955745.1429860572572.JavaMail.zimbra@redhat.com>
References: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>
	<1002185417.5955745.1429860572572.JavaMail.zimbra@redhat.com>
Message-ID: <5540E3FE.7000604@redhat.com>

Few comments to distribution:

1) server-dist doesn't have standalone/deployments and so it's supposed 
to just contain auth-server and not any applications right? In this case 
we can remove all adapter jars from it? Probably bunch of other modules 
(and maybe extensions) could be cleaned as well

2) On the other hand, demo-dist is actually based on server-dist and 
hence doesn't have standalone/deployments and deployment processor. I 
suppose this should be really fixed before we release?

3) demo-dist doesn't need to have modules keycloak-as7-adapter and 
keycloak-as7-subsystem as it's based on wildfly

4) demo-dist doesn't have security-domains with KeycloakLoginModule and 
SAML2LoginModule declared in standalone-*.xml . Just server-overlay has 
them. Since we want demo-dist to contain examples, it should have the 
security domains added IMO

5) There is no documentation about needed steps to deploy auth-server on 
EAP 6.4. Unzip server-overlay and running:

./standalone.xml -c standalone-keycloak.xml

obviously doesn't work as standalone-keycloak.xml is based on 
standalone.xml from WF 8.2. So we should have instructions what should 
be done to setup server in standalone.xml (keycloak extension, keycloak 
subsystem, KeycloakDS datasource). There are some instructions in 
documentation how to add extension and subsystem, but those are in 
"Adapters" chapter of the docs.

Instructions for manual setup of standalone-*.xml are needed also in 
case that people want to add server-overlay to the WildFly server, which 
is using clustering and hence standalone-ha.xml or 
standalone-ha-full.xml (current standalone-keycloak.xml is based only on 
standalone.xml)


With respect to comments 1-4, is it really good that demo-dist is based 
on server-dist? It looks that there will be quite major differences 
between those two.

Marek

On 24.4.2015 09:29, Stian Thorgersen wrote:
> A couple changes:
>
> server-overlay:
> * Added standalone-keycloak.xml as this allows extracting into wildfly without overwriting existing configs
> * Removed docs into separate docs dist (reduces size from 27MB to 15MB)
>
> server-dist:
> * Removed standalone/deployments and deployment processor
>
> Remaining work is to do the demo bundle. Plan is to have it include WF + server-overlay + demo preloaded. Also include all examples and docs.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 23 April, 2015 3:50:24 PM
>> Subject: [keycloak-dev] Distribution changes
>>
>> I've pushed a fair amount of changes to the distribution:
>>
>> * Release is built with "mvn -Pjboss-release install" now as this is
>> consistent with jboss-parent. Also this builds javadoc as well now, so no
>> need to run those separate.
>> * distribution/examples - a zip with all the examples
>> * distribution/server-overlay - a zip that can be extracted into an existing
>> WF 8.2.0.Final to install KC, includes docs. Currently it contains
>> server*.xml all with KC enabled, but I was thinking we should just have
>> standalone-keycloak.xml instead
>> * distribution/server-dist - a zip with WF 8.2.0.Final + server-overlay
>> * distribution/server-bundle - a bundle with server and examples zip, this
>> should at some point be changed to a dl with demo preloaded onto it
>> * adapter dists are moved into distribution/adapters, just to clean it up a
>> bit
>> * Started updating docs, but there's a bit more work to review/update it to
>> make sure it matches updated dists
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Wed Apr 29 10:51:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 10:51:17 -0400
Subject: [keycloak-dev] linkage errors around ApacheHttpClient
Message-ID: <5540EFE5.103@redhat.com>

FYI,

Need to hold up any release as there are linkage errors with 
ApacheHTTPClient

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

From bburke at redhat.com  Wed Apr 29 14:21:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 14:21:12 -0400
Subject: [keycloak-dev] Reason for Apache Httpcomponents 4.3?
Message-ID: <55412118.2000505@redhat.com>

We are getting linkage errors in a few places because Resteasy (and 
Wildfly 8.2.0) depends on apache httpcomponents 4.2.1 and keycloak uses 
4.3.

Is there a reason for the 4.3 switch?

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

From srossillo at smartling.com  Wed Apr 29 14:26:32 2015
From: srossillo at smartling.com (Scott Rossillo)
Date: Wed, 29 Apr 2015 14:26:32 -0400
Subject: [keycloak-dev] Reason for Apache Httpcomponents 4.3?
In-Reply-To: <55412118.2000505@redhat.com>
References: <55412118.2000505@redhat.com>
Message-ID: <CALAqdu-1LMeKtLcZU=Xiuu2kuSHpG5vUTOiUEy4GRVGhru51vQ@mail.gmail.com>

That was the spring security branch merge. I initially needed 4.3 but 4.2.x
should work.

On Wednesday, April 29, 2015, Bill Burke <bburke at redhat.com> wrote:

> We are getting linkage errors in a few places because Resteasy (and
> Wildfly 8.2.0) depends on apache httpcomponents 4.2.1 and keycloak uses
> 4.3.
>
> Is there a reason for the 4.3 switch?
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <javascript:;>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150429/c476f6ec/attachment.html 

From bburke at redhat.com  Wed Apr 29 14:30:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 14:30:03 -0400
Subject: [keycloak-dev] Reason for Apache Httpcomponents 4.3?
In-Reply-To: <CALAqdu-1LMeKtLcZU=Xiuu2kuSHpG5vUTOiUEy4GRVGhru51vQ@mail.gmail.com>
References: <55412118.2000505@redhat.com>
	<CALAqdu-1LMeKtLcZU=Xiuu2kuSHpG5vUTOiUEy4GRVGhru51vQ@mail.gmail.com>
Message-ID: <5541232B.1050306@redhat.com>

Nope that was Stian's commit on Monday.

On 4/29/2015 2:26 PM, Scott Rossillo wrote:
> That was the spring security branch merge. I initially needed 4.3 but
> 4.2.x should work.
>
> On Wednesday, April 29, 2015, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     We are getting linkage errors in a few places because Resteasy (and
>     Wildfly 8.2.0) depends on apache httpcomponents 4.2.1 and keycloak uses
>     4.3.
>
>     Is there a reason for the 4.3 switch?
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <javascript:;>
>     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 Apr 29 14:33:35 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 14:33:35 -0400
Subject: [keycloak-dev] Reason for Apache Httpcomponents 4.3?
In-Reply-To: <5541232B.1050306@redhat.com>
References: <55412118.2000505@redhat.com>	<CALAqdu-1LMeKtLcZU=Xiuu2kuSHpG5vUTOiUEy4GRVGhru51vQ@mail.gmail.com>
	<5541232B.1050306@redhat.com>
Message-ID: <554123FF.3060102@redhat.com>

Ok this is the reason:

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

On 4/29/2015 2:30 PM, Bill Burke wrote:
> Nope that was Stian's commit on Monday.
>
> On 4/29/2015 2:26 PM, Scott Rossillo wrote:
>> That was the spring security branch merge. I initially needed 4.3 but
>> 4.2.x should work.
>>
>> On Wednesday, April 29, 2015, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>>      We are getting linkage errors in a few places because Resteasy (and
>>      Wildfly 8.2.0) depends on apache httpcomponents 4.2.1 and keycloak uses
>>      4.3.
>>
>>      Is there a reason for the 4.3 switch?
>>
>>      --
>>      Bill Burke
>>      JBoss, a division of Red Hat
>>      http://bill.burkecentral.com
>>      _______________________________________________
>>      keycloak-dev mailing list
>>      keycloak-dev at lists.jboss.org <javascript:;>
>>      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 Apr 29 14:36:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 14:36:08 -0400
Subject: [keycloak-dev] linkage errors around ApacheHttpClient
In-Reply-To: <5540EFE5.103@redhat.com>
References: <5540EFE5.103@redhat.com>
Message-ID: <55412498.5070209@redhat.com>

Our code uses Resteasy's old client library.  We generate an Apache 
HttpClient object in keycloak using Apache HC 4.3.x, then pass it to the 
resteasy client library constructor. Hence linkage error.

I guess I'll just change the code to using HC directly.

On 4/29/2015 10:51 AM, Bill Burke wrote:
> FYI,
>
> Need to hold up any release as there are linkage errors with
> ApacheHTTPClient
>

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

From bburke at redhat.com  Wed Apr 29 15:55:22 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 15:55:22 -0400
Subject: [keycloak-dev] account theme unfinished?
Message-ID: <5541372A.5000007@redhat.com>

Master was broken.  It could not load the account theme as its parent 
was still patternfly.  I fixed it, but it seems that the account theme 
is still the old style.  Not sure if you meant to change it to the new 
black styling the admin and login pages have.

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

From bburke at redhat.com  Wed Apr 29 22:00:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 22:00:38 -0400
Subject: [keycloak-dev] apache http client changes
Message-ID: <55418CC6.5080506@redhat.com>

Because we have incompatibilites and linkage errors with Apache HTTP 
Client in WIldfly I did the following changes:

* I created an Apache HTTP Client "connections provider" module which 
outgoing server connections now use.
* This provider is configured in keycloak-server.json and documentation 
is in docbook for it.
* Outgoing HTTP requests no longer use Resteasy ClientRequest.

Things to do:
* We need stress tests for backchannel logouts and other 
ResourceAdminManager requests.  Broker and admin console.  Now that an 
HttpClient instance is only created once at boot time instead of per 
request, we need to make absolutely sure connections are being cleaned up.
* I need to test backchannel and ResourceAdminManager requests with 
SSL/HTTPS.

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

From bburke at redhat.com  Wed Apr 29 22:04:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 29 Apr 2015 22:04:42 -0400
Subject: [keycloak-dev] login fonts need to be brightened
Message-ID: <55418DBA.7050301@redhat.com>

SOme of the fonts are really dark, specifically in the login page.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu Apr 30 02:08:34 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 02:08:34 -0400 (EDT)
Subject: [keycloak-dev] linkage errors around ApacheHttpClient
In-Reply-To: <55412498.5070209@redhat.com>
References: <5540EFE5.103@redhat.com> <55412498.5070209@redhat.com>
Message-ID: <493384703.10105837.1430374114454.JavaMail.zimbra@redhat.com>

Is this fixed?

What was the problems you saw as it worked fine when I tested it. I assume I didn't test it well enough :/

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 29, 2015 8:36:08 PM
> Subject: Re: [keycloak-dev] linkage errors around ApacheHttpClient
> 
> Our code uses Resteasy's old client library.  We generate an Apache
> HttpClient object in keycloak using Apache HC 4.3.x, then pass it to the
> resteasy client library constructor. Hence linkage error.
> 
> I guess I'll just change the code to using HC directly.
> 
> On 4/29/2015 10:51 AM, Bill Burke wrote:
> > FYI,
> >
> > Need to hold up any release as there are linkage errors with
> > ApacheHTTPClient
> >
> 
> --
> 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 Apr 30 02:09:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 02:09:13 -0400 (EDT)
Subject: [keycloak-dev] account theme unfinished?
In-Reply-To: <5541372A.5000007@redhat.com>
References: <5541372A.5000007@redhat.com>
Message-ID: <649303324.10105993.1430374153732.JavaMail.zimbra@redhat.com>

Doing account theme today

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, April 29, 2015 9:55:22 PM
> Subject: [keycloak-dev] account theme unfinished?
> 
> Master was broken.  It could not load the account theme as its parent
> was still patternfly.  I fixed it, but it seems that the account theme
> is still the old style.  Not sure if you meant to change it to the new
> black styling the admin and login pages have.
> 
> --
> 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 Apr 30 02:10:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 02:10:27 -0400 (EDT)
Subject: [keycloak-dev] login fonts need to be brightened
In-Reply-To: <55418DBA.7050301@redhat.com>
References: <55418DBA.7050301@redhat.com>
Message-ID: <1592425735.10106161.1430374227017.JavaMail.zimbra@redhat.com>

I'll look at it. Looking at https://www.patternfly.org/patterns/login-page/ they should be white, not grey as now

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, April 30, 2015 4:04:42 AM
> Subject: [keycloak-dev] login fonts need to be brightened
> 
> SOme of the fonts are really dark, specifically in the login page.
> --
> 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 Apr 30 02:33:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 02:33:00 -0400 (EDT)
Subject: [keycloak-dev] Distribution changes
In-Reply-To: <5540E3FE.7000604@redhat.com>
References: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>
	<1002185417.5955745.1429860572572.JavaMail.zimbra@redhat.com>
	<5540E3FE.7000604@redhat.com>
Message-ID: <684942668.10111426.1430375580292.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: Wednesday, April 29, 2015 4:00:30 PM
> Subject: Re: [keycloak-dev] Distribution changes
> 
> Few comments to distribution:
> 
> 1) server-dist doesn't have standalone/deployments and so it's supposed
> to just contain auth-server and not any applications right? In this case
> we can remove all adapter jars from it? Probably bunch of other modules
> (and maybe extensions) could be cleaned as well

In the next release it'll be the build on top of WF core. This is a "preview" of what's coming.

We'll remove the adapter jars once we have split subsystem into separate server and adapter subsystems. I'm pretty sure removing this now will cause problems.

> 
> 2) On the other hand, demo-dist is actually based on server-dist and
> hence doesn't have standalone/deployments and deployment processor. I
> suppose this should be really fixed before we release?

demo-dist wasn't supposed to be based on server-dist. I'll fix that and base it on WF + server-overlay.

> 
> 3) demo-dist doesn't need to have modules keycloak-as7-adapter and
> keycloak-as7-subsystem as it's based on wildfly

I'll try to remove these.

> 
> 4) demo-dist doesn't have security-domains with KeycloakLoginModule and
> SAML2LoginModule declared in standalone-*.xml . Just server-overlay has
> them. Since we want demo-dist to contain examples, it should have the
> security domains added IMO

Yep. Will fix

> 
> 5) There is no documentation about needed steps to deploy auth-server on
> EAP 6.4. Unzip server-overlay and running:
> 
> ./standalone.xml -c standalone-keycloak.xml
> 
> obviously doesn't work as standalone-keycloak.xml is based on
> standalone.xml from WF 8.2. So we should have instructions what should
> be done to setup server in standalone.xml (keycloak extension, keycloak
> subsystem, KeycloakDS datasource). There are some instructions in
> documentation how to add extension and subsystem, but those are in
> "Adapters" chapter of the docs.
> 
> Instructions for manual setup of standalone-*.xml are needed also in
> case that people want to add server-overlay to the WildFly server, which
> is using clustering and hence standalone-ha.xml or
> standalone-ha-full.xml (current standalone-keycloak.xml is based only on
> standalone.xml)

Agreed - I'll improve the docs

> 
> 
> With respect to comments 1-4, is it really good that demo-dist is based
> on server-dist? It looks that there will be quite major differences
> between those two.

Nope - the plan is server-dist is pure KC, while demo-dist is a bundle with WF + KC server and adapter + docs + examples. Maybe we should call it dev bundle instead?

> 
> Marek
> 
> On 24.4.2015 09:29, Stian Thorgersen wrote:
> > A couple changes:
> >
> > server-overlay:
> > * Added standalone-keycloak.xml as this allows extracting into wildfly
> > without overwriting existing configs
> > * Removed docs into separate docs dist (reduces size from 27MB to 15MB)
> >
> > server-dist:
> > * Removed standalone/deployments and deployment processor
> >
> > Remaining work is to do the demo bundle. Plan is to have it include WF +
> > server-overlay + demo preloaded. Also include all examples and docs.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, 23 April, 2015 3:50:24 PM
> >> Subject: [keycloak-dev] Distribution changes
> >>
> >> I've pushed a fair amount of changes to the distribution:
> >>
> >> * Release is built with "mvn -Pjboss-release install" now as this is
> >> consistent with jboss-parent. Also this builds javadoc as well now, so no
> >> need to run those separate.
> >> * distribution/examples - a zip with all the examples
> >> * distribution/server-overlay - a zip that can be extracted into an
> >> existing
> >> WF 8.2.0.Final to install KC, includes docs. Currently it contains
> >> server*.xml all with KC enabled, but I was thinking we should just have
> >> standalone-keycloak.xml instead
> >> * distribution/server-dist - a zip with WF 8.2.0.Final + server-overlay
> >> * distribution/server-bundle - a bundle with server and examples zip, this
> >> should at some point be changed to a dl with demo preloaded onto it
> >> * adapter dists are moved into distribution/adapters, just to clean it up
> >> a
> >> bit
> >> * Started updating docs, but there's a bit more work to review/update it
> >> to
> >> make sure it matches updated dists
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bdawidow at redhat.com  Thu Apr 30 03:16:35 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Thu, 30 Apr 2015 09:16:35 +0200
Subject: [keycloak-dev] Supported environments
In-Reply-To: <553FA3E5.9050905@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com> <553F928E.9010805@redhat.com>
	<1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
	<553FA3E5.9050905@redhat.com>
Message-ID: <58793995-C4AB-4F0C-A22B-DDD81EA0ADFC@redhat.com>


> On 28 Apr 2015, at 17:14, Bill Burke <bburke at redhat.com> wrote:
> 
> 
> 
> On 4/28/2015 10:02 AM, Stian Thorgersen wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, April 28, 2015 4:00:46 PM
>>> Subject: Re: [keycloak-dev] Supported environments
>>> 
>>> 
>>> 
>>> On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
>>>> 
>>>> 
>>>> W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
>>>>> For 1.2.0.Final the server should be deployable to:
>>>>> 
>>>>> * WildFly 8.2.0.Final
>>>>> * EAP 6.4.0.GA
>>>>> 
>>>>> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's
>>>>> released). As APIs has changed, and there's also new features in WF 9 we
>>>>> can leverage, the cleanest way to do this is to drop support for
>>>>> deploying to EAP 6.4.0.GA.
>>>>> 
>>>>> With regards to adapters what versions should we support:
>>>>> 
>>>>> * AS7 - can we drop this?
>>>>> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and
>>>>> 9.0.0.Final)?
>>>>> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3,
>>>>> 6.4)?
>>>> 
>>>> Would go with only latest stable WF and only last minor of EAP 6.
>>>> 
>>> 
>>> We should never drop adapter support for any platform.   The larger our
>>> adapter pool, the larger our user base will be.
>> 
>> So we're maintaining AS7 support for ever?!?
>> 
> 
> I don't think it will be much of an issue.  These old platforms are 
> pretty static and the adapters are generic enough to evolve.
> 

IMO it is all about maintenance cost of covering many versions of same container. If it is low enough then it shouldn?t be a problem - especially for adapters. 

> 
> -- 
> 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 bdawidow at redhat.com  Thu Apr 30 03:17:14 2015
From: bdawidow at redhat.com (Boleslaw Dawidowicz)
Date: Thu, 30 Apr 2015 09:17:14 +0200
Subject: [keycloak-dev] Distribution changes
In-Reply-To: <684942668.10111426.1430375580292.JavaMail.zimbra@redhat.com>
References: <1665653883.5563097.1429797024665.JavaMail.zimbra@redhat.com>
	<1002185417.5955745.1429860572572.JavaMail.zimbra@redhat.com>
	<5540E3FE.7000604@redhat.com>
	<684942668.10111426.1430375580292.JavaMail.zimbra@redhat.com>
Message-ID: <0C52A752-8DAC-4C02-9DCB-DB0B07E042F5@redhat.com>


> On 30 Apr 2015, at 08:33, Stian Thorgersen <stian at redhat.com> wrote:
> 
> 
> 
> ----- 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: Wednesday, April 29, 2015 4:00:30 PM
>> Subject: Re: [keycloak-dev] Distribution changes
>> 
>> Few comments to distribution:
>> 
>> 1) server-dist doesn't have standalone/deployments and so it's supposed
>> to just contain auth-server and not any applications right? In this case
>> we can remove all adapter jars from it? Probably bunch of other modules
>> (and maybe extensions) could be cleaned as well
> 
> In the next release it'll be the build on top of WF core. This is a "preview" of what's coming.
> 
> We'll remove the adapter jars once we have split subsystem into separate server and adapter subsystems. I'm pretty sure removing this now will cause problems.
> 
>> 
>> 2) On the other hand, demo-dist is actually based on server-dist and
>> hence doesn't have standalone/deployments and deployment processor. I
>> suppose this should be really fixed before we release?
> 
> demo-dist wasn't supposed to be based on server-dist. I'll fix that and base it on WF + server-overlay.
> 
>> 
>> 3) demo-dist doesn't need to have modules keycloak-as7-adapter and
>> keycloak-as7-subsystem as it's based on wildfly
> 
> I'll try to remove these.
> 
>> 
>> 4) demo-dist doesn't have security-domains with KeycloakLoginModule and
>> SAML2LoginModule declared in standalone-*.xml . Just server-overlay has
>> them. Since we want demo-dist to contain examples, it should have the
>> security domains added IMO
> 
> Yep. Will fix
> 
>> 
>> 5) There is no documentation about needed steps to deploy auth-server on
>> EAP 6.4. Unzip server-overlay and running:
>> 
>> ./standalone.xml -c standalone-keycloak.xml
>> 
>> obviously doesn't work as standalone-keycloak.xml is based on
>> standalone.xml from WF 8.2. So we should have instructions what should
>> be done to setup server in standalone.xml (keycloak extension, keycloak
>> subsystem, KeycloakDS datasource). There are some instructions in
>> documentation how to add extension and subsystem, but those are in
>> "Adapters" chapter of the docs.
>> 
>> Instructions for manual setup of standalone-*.xml are needed also in
>> case that people want to add server-overlay to the WildFly server, which
>> is using clustering and hence standalone-ha.xml or
>> standalone-ha-full.xml (current standalone-keycloak.xml is based only on
>> standalone.xml)
> 
> Agreed - I'll improve the docs
> 
>> 
>> 
>> With respect to comments 1-4, is it really good that demo-dist is based
>> on server-dist? It looks that there will be quite major differences
>> between those two.
> 
> Nope - the plan is server-dist is pure KC, while demo-dist is a bundle with WF + KC server and adapter + docs + examples. Maybe we should call it dev bundle instead?

I like the dev bundle idea :) 

> 
>> 
>> Marek
>> 
>> On 24.4.2015 09:29, Stian Thorgersen wrote:
>>> A couple changes:
>>> 
>>> server-overlay:
>>> * Added standalone-keycloak.xml as this allows extracting into wildfly
>>> without overwriting existing configs
>>> * Removed docs into separate docs dist (reduces size from 27MB to 15MB)
>>> 
>>> server-dist:
>>> * Removed standalone/deployments and deployment processor
>>> 
>>> Remaining work is to do the demo bundle. Plan is to have it include WF +
>>> server-overlay + demo preloaded. Also include all examples and docs.
>>> 
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Thursday, 23 April, 2015 3:50:24 PM
>>>> Subject: [keycloak-dev] Distribution changes
>>>> 
>>>> I've pushed a fair amount of changes to the distribution:
>>>> 
>>>> * Release is built with "mvn -Pjboss-release install" now as this is
>>>> consistent with jboss-parent. Also this builds javadoc as well now, so no
>>>> need to run those separate.
>>>> * distribution/examples - a zip with all the examples
>>>> * distribution/server-overlay - a zip that can be extracted into an
>>>> existing
>>>> WF 8.2.0.Final to install KC, includes docs. Currently it contains
>>>> server*.xml all with KC enabled, but I was thinking we should just have
>>>> standalone-keycloak.xml instead
>>>> * distribution/server-dist - a zip with WF 8.2.0.Final + server-overlay
>>>> * distribution/server-bundle - a bundle with server and examples zip, this
>>>> should at some point be changed to a dl with demo preloaded onto it
>>>> * adapter dists are moved into distribution/adapters, just to clean it up
>>>> a
>>>> bit
>>>> * Started updating docs, but there's a bit more work to review/update it
>>>> to
>>>> make sure it matches updated dists
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> 
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> 
>> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From stian at redhat.com  Thu Apr 30 03:31:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 03:31:07 -0400 (EDT)
Subject: [keycloak-dev] Supported environments
In-Reply-To: <58793995-C4AB-4F0C-A22B-DDD81EA0ADFC@redhat.com>
References: <1772635493.6996053.1430116655042.JavaMail.zimbra@redhat.com>
	<553F37BB.3070903@redhat.com> <553F928E.9010805@redhat.com>
	<1265597720.8269171.1430229757824.JavaMail.zimbra@redhat.com>
	<553FA3E5.9050905@redhat.com>
	<58793995-C4AB-4F0C-A22B-DDD81EA0ADFC@redhat.com>
Message-ID: <963306069.10133132.1430379067894.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Boleslaw Dawidowicz" <bdawidow at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, April 30, 2015 9:16:35 AM
> Subject: Re: [keycloak-dev] Supported environments
> 
> 
> > On 28 Apr 2015, at 17:14, Bill Burke <bburke at redhat.com> wrote:
> > 
> > 
> > 
> > On 4/28/2015 10:02 AM, Stian Thorgersen wrote:
> >> 
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, April 28, 2015 4:00:46 PM
> >>> Subject: Re: [keycloak-dev] Supported environments
> >>> 
> >>> 
> >>> 
> >>> On 4/28/2015 3:33 AM, Boleslaw Dawidowicz wrote:
> >>>> 
> >>>> 
> >>>> W dniu 2015-04-27 o 08:37, Stian Thorgersen pisze:
> >>>>> For 1.2.0.Final the server should be deployable to:
> >>>>> 
> >>>>> * WildFly 8.2.0.Final
> >>>>> * EAP 6.4.0.GA
> >>>>> 
> >>>>> After 1.2.0.Final we should move on to WildFly 9.0.0.Final (once it's
> >>>>> released). As APIs has changed, and there's also new features in WF 9
> >>>>> we
> >>>>> can leverage, the cleanest way to do this is to drop support for
> >>>>> deploying to EAP 6.4.0.GA.
> >>>>> 
> >>>>> With regards to adapters what versions should we support:
> >>>>> 
> >>>>> * AS7 - can we drop this?
> >>>>> * WildFly - only last (9.0.0.Final) or two last (8.2.0.Final and
> >>>>> 9.0.0.Final)?
> >>>>> * EAP - only last (6.4), two last (6.3, 6.4) or three last (6.2, 6.3,
> >>>>> 6.4)?
> >>>> 
> >>>> Would go with only latest stable WF and only last minor of EAP 6.
> >>>> 
> >>> 
> >>> We should never drop adapter support for any platform.   The larger our
> >>> adapter pool, the larger our user base will be.
> >> 
> >> So we're maintaining AS7 support for ever?!?
> >> 
> > 
> > I don't think it will be much of an issue.  These old platforms are
> > pretty static and the adapters are generic enough to evolve.
> > 
> 
> IMO it is all about maintenance cost of covering many versions of same
> container. If it is low enough then it shouldn?t be a problem - especially
> for adapters.

We need to ability to test adapters with full containers, not just embedded containers. Once we have that for an adapter the maintenance cost goes down significantly. Currently even though we have tests for the adapters, we still don't know if they work until we've manually tested it. For example if there's a problems in modules or the adapter subsystem that can only be properly tested on a full WildFly server.

Same goes for the server and examples - we need to run tests against a full server build, not just an embedded Undertow.

> 
> > 
> > --
> > 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 Apr 30 05:08:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 30 Apr 2015 05:08:29 -0400 (EDT)
Subject: [keycloak-dev] Keycloak 1.2.0.CR1 delayed to Monday
Message-ID: <330033191.10196956.1430384909272.JavaMail.zimbra@redhat.com>

We need a bit more time to finish things and test, so let's delay release until Monday

From bburke at redhat.com  Thu Apr 30 08:33:28 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 30 Apr 2015 08:33:28 -0400
Subject: [keycloak-dev] linkage errors around ApacheHttpClient
In-Reply-To: <493384703.10105837.1430374114454.JavaMail.zimbra@redhat.com>
References: <5540EFE5.103@redhat.com> <55412498.5070209@redhat.com>
	<493384703.10105837.1430374114454.JavaMail.zimbra@redhat.com>
Message-ID: <55422118.1010104@redhat.com>

I saw a linkage error exceptoin whenever a ApacheHttpClient4Executor was 
created.  Again, this is because the resteasy module has a dependency on 
4.2 and the HttpClient created and passed to the 
ApacheHttpClient4Executor constructor was a 4.3 one.

On 4/30/2015 2:08 AM, Stian Thorgersen wrote:
> Is this fixed?
>
> What was the problems you saw as it worked fine when I tested it. I assume I didn't test it well enough :/
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, April 29, 2015 8:36:08 PM
>> Subject: Re: [keycloak-dev] linkage errors around ApacheHttpClient
>>
>> Our code uses Resteasy's old client library.  We generate an Apache
>> HttpClient object in keycloak using Apache HC 4.3.x, then pass it to the
>> resteasy client library constructor. Hence linkage error.
>>
>> I guess I'll just change the code to using HC directly.
>>
>> On 4/29/2015 10:51 AM, Bill Burke wrote:
>>> FYI,
>>>
>>> Need to hold up any release as there are linkage errors with
>>> ApacheHTTPClient
>>>
>>
>> --
>> 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