From stian at redhat.com  Mon Jun  2 04:43:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 2 Jun 2014 04:43:06 -0400 (EDT)
Subject: [keycloak-dev] Keycloak artifacts now in Maven Central
Message-ID: <1203373801.18646058.1401698586013.JavaMail.zimbra@redhat.com>

Keycloak artifacts are now in Maven Central! This includes the appliance, war and adapters zips.

From stian at redhat.com  Mon Jun  2 05:06:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 2 Jun 2014 05:06:14 -0400 (EDT)
Subject: [keycloak-dev] OpenShift Cartridge updated to Beta1
Message-ID: <1545629965.18652322.1401699974285.JavaMail.zimbra@redhat.com>

The OpenShift Cartridge has just been updated to Keycloak 1.0.beta1

From bburke at redhat.com  Mon Jun  2 09:01:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 09:01:38 -0400
Subject: [keycloak-dev] Next step performance
In-Reply-To: <yrsxjchf78bmygpr0mqj6wam.1401713665002@email.android.com>
References: <53878683.5060206@redhat.com>
	<106250783.17669732.1401444375903.JavaMail.zimbra@redhat.com>
	<53886B93.4000201@redhat.com>
	<yrsxjchf78bmygpr0mqj6wam.1401713665002@email.android.com>
Message-ID: <538C75B2.40501@redhat.com>

No problem.  See you tomorrow.

On 6/2/2014 8:54 AM, Stian Thorgersen wrote:
> I'm watching sick children today. Can we reschedule today's hangout for same time tomorrow?
>
> Bill Burke <bburke at redhat.com> wrote:
>
>
>
> On 5/30/2014 6:06 AM, Stian Thorgersen wrote:
>> Sent invite for Monday in Zimbra (15pm GMT). If that's not suitable let me know.
>>
>> A few more areas to look at:
>>
>> * Profile to find crappy code
>> * Tune FreeMarker and themes
>> * Sharding / sticky sessions - this is probably for later, but I'd like to discuss it in the hangout
>>
>> A few comments on database caching:
>>
>> * We may need to do this in stages
>>      - 2nd level cache for beta-2?
>>      - Something more advanced in after 1.0.final
>> * I'd don't like the idea of us re-inventing the wheel
>>      - Caching has a lot of complex considerations (node discovery, fail-over, node recovery, invalidation, lan/wan, jta, etc.)
>
> I know and agree and have experience with this.  But, these traditional
> caches just don't work well in many environments.
>
>> * I really like the idea of having a cache model provider that delegates to another model for persistence / this is definitively the way to go IMO
>> * User sessions needs to separate considerations, specifically I think we can come up with something clever to minimise the writes required
>>
>
> Yes, User sessions are a special case.
>

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

From bburke at redhat.com  Mon Jun  2 11:22:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 11:22:01 -0400
Subject: [keycloak-dev] emergency release tomorrow
Message-ID: <538C9699.5090303@redhat.com>

Wildfly SSL support was broken...probably because I didn't test it :) 
Going to do a release tomorrow as IMO, this is kind of a blocker.

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

From bburke at redhat.com  Mon Jun  2 11:46:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 11:46:12 -0400
Subject: [keycloak-dev] FYI: month behind
Message-ID: <538C9C44.4070705@redhat.com>

FYI, we're a month behind on our schedule, so I pushed all the dates out 
a month or more on all the releases.  1.0.Final will be August 21.  We 
may release sooner depending on how the performance work goes.



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

From bburke at redhat.com  Mon Jun  2 12:13:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 12:13:57 -0400
Subject: [keycloak-dev] Fixes since beta-1??
Message-ID: <538CA2C5.1030100@redhat.com>

Doing a release tomorrow morning (US - EST).  Were there any fixes from 
beta 1?  I saw a bunch of PRs.  If you know what they are, please 
add/close JIRA targeted at beta-2.

Bill

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

From stian at redhat.com  Mon Jun  2 12:18:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 2 Jun 2014 12:18:03 -0400 (EDT)
Subject: [keycloak-dev] Fixes since beta-1??
In-Reply-To: <538CA2C5.1030100@redhat.com>
References: <538CA2C5.1030100@redhat.com>
Message-ID: <1078774927.18965662.1401725883650.JavaMail.zimbra@redhat.com>

There was a couple fixes to JS lib, neither which has an associated JIRA. I'm pretty confident in those as they where very minor.

Also, some performance improvements for themes. They should be ok, but haven't been extensively tested so far.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 2 June, 2014 5:13:57 PM
> Subject: [keycloak-dev] Fixes since beta-1??
> 
> Doing a release tomorrow morning (US - EST).  Were there any fixes from
> beta 1?  I saw a bunch of PRs.  If you know what they are, please
> add/close JIRA targeted at beta-2.
> 
> Bill
> 
> --
> 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 Jun  2 13:25:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 13:25:45 -0400
Subject: [keycloak-dev] Beta 2 released
Message-ID: <538CB399.5000901@redhat.com>

We had a couple of blocker bugs centered around SSL and Wildfly.  Fixes 
are in, and beta 2 is released.

Check out jira release notes for more details.

Bill

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

From bburke at redhat.com  Mon Jun  2 17:03:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 17:03:50 -0400
Subject: [keycloak-dev] profile results
Message-ID: <538CE6B6.6000806@redhat.com>

I ran 10 threads each running 100 threads.  I get a rate of about 31ms 
per loginpage/processLogin/accessCode2Token flow.

According to JProfiler, 65% of time is spent in the password hashing 
algorithm.  I guess this is not surprising because this password hashing 
algorithm is *supposed* to eat up CPU, right?

BTW, running 20 threads concurrently I start to get deadlocks in the 
database around UserSession processing.  Going to look into that.

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

From bburke at redhat.com  Mon Jun  2 17:50:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 17:50:01 -0400
Subject: [keycloak-dev] profile results
In-Reply-To: <538CE6B6.6000806@redhat.com>
References: <538CE6B6.6000806@redhat.com>
Message-ID: <538CF189.3050107@redhat.com>

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

I wondering if we should have this default value low or high?

On 6/2/2014 5:03 PM, Bill Burke wrote:
> I ran 10 threads each running 100 threads.  I get a rate of about 31ms
> per loginpage/processLogin/accessCode2Token flow.
>
> According to JProfiler, 65% of time is spent in the password hashing
> algorithm.  I guess this is not surprising because this password hashing
> algorithm is *supposed* to eat up CPU, right?
>
> BTW, running 20 threads concurrently I start to get deadlocks in the
> database around UserSession processing.  Going to look into that.
>

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

From bburke at redhat.com  Mon Jun  2 20:33:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 20:33:07 -0400
Subject: [keycloak-dev] deadlocks
Message-ID: <538D17C3.2050909@redhat.com>

I"m getting concurrent deadlocks when doing a login with multiple 
threads.  Its just bizarre and I don't get it.  Check out this error 
message.  Why the hell would "delete from AuthProviders" be called 
??????!?!?!?!?!!!  I don't see a setAuthProviders happening anywhere.

Caused by: org.h2.jdbc.JdbcSQLException: Deadlock detected. The current 
transaction was rolled back. Details: "
Session #8 (user: SA) is waiting to lock PUBLIC.USERSESSIONENTITY while 
locking PUBLIC.AUTHENTICATIONLINKENTITY (exclusive), PUBLIC.USERENTITY 
(exclusive), PUBLIC.AUTHPROVIDERS (exclusive).
Session #5 (user: SA) is waiting to lock PUBLIC.AUTHPROVIDERS while 
locking PUBLIC.USERSESSIONENTITY (exclusive)."; SQL statement:
delete from AuthProviders where RealmEntity_id=? [40001-161]
	at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
	at org.h2.message.DbException.get(DbException.java:169)
	at org.h2.message.DbException.get(DbException.java:146)


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

From bburke at redhat.com  Mon Jun  2 20:51:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 20:51:10 -0400
Subject: [keycloak-dev] deadlocks
In-Reply-To: <538D17C3.2050909@redhat.com>
References: <538D17C3.2050909@redhat.com>
Message-ID: <538D1BFE.2010602@redhat.com>

Ok, I found the problem...

RealmAdapter.getAuthenticationProviders() was sorting the collection 
returned by the realm entity.  If you do this, then Hibernate thinks 
you've modified the collection and it performs an update :)

Can you think of any other places where returned collections are sorted?

On 6/2/2014 8:33 PM, Bill Burke wrote:
> I"m getting concurrent deadlocks when doing a login with multiple
> threads.  Its just bizarre and I don't get it.  Check out this error
> message.  Why the hell would "delete from AuthProviders" be called
> ??????!?!?!?!?!!!  I don't see a setAuthProviders happening anywhere.
>
> Caused by: org.h2.jdbc.JdbcSQLException: Deadlock detected. The current
> transaction was rolled back. Details: "
> Session #8 (user: SA) is waiting to lock PUBLIC.USERSESSIONENTITY while
> locking PUBLIC.AUTHENTICATIONLINKENTITY (exclusive), PUBLIC.USERENTITY
> (exclusive), PUBLIC.AUTHPROVIDERS (exclusive).
> Session #5 (user: SA) is waiting to lock PUBLIC.AUTHPROVIDERS while
> locking PUBLIC.USERSESSIONENTITY (exclusive)."; SQL statement:
> delete from AuthProviders where RealmEntity_id=? [40001-161]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
> 	at org.h2.message.DbException.get(DbException.java:169)
> 	at org.h2.message.DbException.get(DbException.java:146)
>
>

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

From bburke at redhat.com  Mon Jun  2 21:26:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 02 Jun 2014 21:26:14 -0400
Subject: [keycloak-dev] deadlocks
In-Reply-To: <538D1BFE.2010602@redhat.com>
References: <538D17C3.2050909@redhat.com> <538D1BFE.2010602@redhat.com>
Message-ID: <538D2436.5040201@redhat.com>

Also had to remove ManyToOne mappings in UserSessionEntity and 
ClientUserSessionAssociationEntity and use String ids instead.  I guess 
those table locks on usermodel get upgraded when you update 
usersessionentity


On 6/2/2014 8:51 PM, Bill Burke wrote:
> Ok, I found the problem...
>
> RealmAdapter.getAuthenticationProviders() was sorting the collection
> returned by the realm entity.  If you do this, then Hibernate thinks
> you've modified the collection and it performs an update :)
>
> Can you think of any other places where returned collections are sorted?
>
> On 6/2/2014 8:33 PM, Bill Burke wrote:
>> I"m getting concurrent deadlocks when doing a login with multiple
>> threads.  Its just bizarre and I don't get it.  Check out this error
>> message.  Why the hell would "delete from AuthProviders" be called
>> ??????!?!?!?!?!!!  I don't see a setAuthProviders happening anywhere.
>>
>> Caused by: org.h2.jdbc.JdbcSQLException: Deadlock detected. The current
>> transaction was rolled back. Details: "
>> Session #8 (user: SA) is waiting to lock PUBLIC.USERSESSIONENTITY while
>> locking PUBLIC.AUTHENTICATIONLINKENTITY (exclusive), PUBLIC.USERENTITY
>> (exclusive), PUBLIC.AUTHPROVIDERS (exclusive).
>> Session #5 (user: SA) is waiting to lock PUBLIC.AUTHPROVIDERS while
>> locking PUBLIC.USERSESSIONENTITY (exclusive)."; SQL statement:
>> delete from AuthProviders where RealmEntity_id=? [40001-161]
>> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
>> 	at org.h2.message.DbException.get(DbException.java:169)
>> 	at org.h2.message.DbException.get(DbException.java:146)
>>
>>
>

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

From stian at redhat.com  Tue Jun  3 04:21:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Jun 2014 04:21:15 -0400 (EDT)
Subject: [keycloak-dev] profile results
In-Reply-To: <538CF189.3050107@redhat.com>
References: <538CE6B6.6000806@redhat.com> <538CF189.3050107@redhat.com>
Message-ID: <626840970.19335580.1401783675261.JavaMail.zimbra@redhat.com>

My vote is for a sensible middle ground

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 2 June, 2014 10:50:01 PM
> Subject: Re: [keycloak-dev] profile results
> 
> https://issues.jboss.org/browse/KEYCLOAK-508
> 
> I wondering if we should have this default value low or high?
> 
> On 6/2/2014 5:03 PM, Bill Burke wrote:
> > I ran 10 threads each running 100 threads.  I get a rate of about 31ms
> > per loginpage/processLogin/accessCode2Token flow.
> >
> > According to JProfiler, 65% of time is spent in the password hashing
> > algorithm.  I guess this is not surprising because this password hashing
> > algorithm is *supposed* to eat up CPU, right?
> >
> > BTW, running 20 threads concurrently I start to get deadlocks in the
> > database around UserSession processing.  Going to look into that.
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bruno at abstractj.org  Tue Jun  3 06:10:23 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 07:10:23 -0300
Subject: [keycloak-dev] profile results
In-Reply-To: <538CF189.3050107@redhat.com>
References: <538CE6B6.6000806@redhat.com>
 <538CF189.3050107@redhat.com>
Message-ID: <20140603101023.GA88786@abstractj.org>

Good morning Bill, NIST recommends 1000 as the minimum
(http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf). Look for "A
minimum iteration count of 1,000 is recommended".

So I think we can find the middle term, for example LastPass uses 5000 (https://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/).

On 2014-06-02, Bill Burke wrote:
> https://issues.jboss.org/browse/KEYCLOAK-508
>
> I wondering if we should have this default value low or high?
>
> On 6/2/2014 5:03 PM, Bill Burke wrote:
> > I ran 10 threads each running 100 threads.  I get a rate of about 31ms
> > per loginpage/processLogin/accessCode2Token flow.
> >
> > According to JProfiler, 65% of time is spent in the password hashing
> > algorithm.  I guess this is not surprising because this password hashing
> > algorithm is *supposed* to eat up CPU, right?
> >
> > BTW, running 20 threads concurrently I start to get deadlocks in the
> > database around UserSession processing.  Going to look into that.
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From stian at redhat.com  Tue Jun  3 06:23:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Jun 2014 06:23:53 -0400 (EDT)
Subject: [keycloak-dev] profile results
In-Reply-To: <20140603101023.GA88786@abstractj.org>
References: <538CE6B6.6000806@redhat.com> <538CF189.3050107@redhat.com>
	<20140603101023.GA88786@abstractj.org>
Message-ID: <1992794214.19390339.1401791033206.JavaMail.zimbra@redhat.com>

We could check if JS is available, and if it is we could run this on the client side before submitting the login form?

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 June, 2014 11:10:23 AM
> Subject: Re: [keycloak-dev] profile results
> 
> Good morning Bill, NIST recommends 1000 as the minimum
> (http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf). Look
> for "A
> minimum iteration count of 1,000 is recommended".
> 
> So I think we can find the middle term, for example LastPass uses 5000
> (https://helpdesk.lastpass.com/security-options/password-iterations-pbkdf2/).
> 
> On 2014-06-02, Bill Burke wrote:
> > https://issues.jboss.org/browse/KEYCLOAK-508
> >
> > I wondering if we should have this default value low or high?
> >
> > On 6/2/2014 5:03 PM, Bill Burke wrote:
> > > I ran 10 threads each running 100 threads.  I get a rate of about 31ms
> > > per loginpage/processLogin/accessCode2Token flow.
> > >
> > > According to JProfiler, 65% of time is spent in the password hashing
> > > algorithm.  I guess this is not surprising because this password hashing
> > > algorithm is *supposed* to eat up CPU, right?
> > >
> > > BTW, running 20 threads concurrently I start to get deadlocks in the
> > > database around UserSession processing.  Going to look into that.
> > >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> 
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jun  3 08:45:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 03 Jun 2014 08:45:11 -0400
Subject: [keycloak-dev] profile results
In-Reply-To: <626840970.19335580.1401783675261.JavaMail.zimbra@redhat.com>
References: <538CE6B6.6000806@redhat.com> <538CF189.3050107@redhat.com>
	<626840970.19335580.1401783675261.JavaMail.zimbra@redhat.com>
Message-ID: <538DC357.8060303@redhat.com>

There is no sensible middle ground for password hashing IMO.

http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pkbdf2-sha256

Stackoverflow says that its recommended to do 64,000 iterations.  we do 
20,000.

http://en.wikipedia.org/wiki/PBKDF2



On 6/3/2014 4:21 AM, Stian Thorgersen wrote:
> My vote is for a sensible middle ground
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 2 June, 2014 10:50:01 PM
>> Subject: Re: [keycloak-dev] profile results
>>
>> https://issues.jboss.org/browse/KEYCLOAK-508
>>
>> I wondering if we should have this default value low or high?
>>
>> On 6/2/2014 5:03 PM, Bill Burke wrote:
>>> I ran 10 threads each running 100 threads.  I get a rate of about 31ms
>>> per loginpage/processLogin/accessCode2Token flow.
>>>
>>> According to JProfiler, 65% of time is spent in the password hashing
>>> algorithm.  I guess this is not surprising because this password hashing
>>> algorithm is *supposed* to eat up CPU, right?
>>>
>>> BTW, running 20 threads concurrently I start to get deadlocks in the
>>> database around UserSession processing.  Going to look into that.
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bruno at abstractj.org  Tue Jun  3 09:14:25 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 10:14:25 -0300
Subject: [keycloak-dev] profile results
In-Reply-To: <538DC357.8060303@redhat.com>
References: <538CE6B6.6000806@redhat.com> <538CF189.3050107@redhat.com>
	<626840970.19335580.1401783675261.JavaMail.zimbra@redhat.com>
	<538DC357.8060303@redhat.com>
Message-ID: <20140603131425.GA97877@abstractj.org>

It pretty much depends on which machine the system will run, maybe
make password salting configurable is a good idea.

The number of iterations pretty much depends on the computational
resources, you can increase to 100.000.000 for example and make
the system vulnerable to DDoS.

On 2014-06-03, Bill Burke wrote:
> There is no sensible middle ground for password hashing IMO.
>
> http://stackoverflow.com/questions/6054082/recommended-of-iterations-when-using-pkbdf2-sha256
>
> Stackoverflow says that its recommended to do 64,000 iterations.  we do
> 20,000.
>
> http://en.wikipedia.org/wiki/PBKDF2
>
>
>
> On 6/3/2014 4:21 AM, Stian Thorgersen wrote:
> > My vote is for a sensible middle ground
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 2 June, 2014 10:50:01 PM
> >> Subject: Re: [keycloak-dev] profile results
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-508
> >>
> >> I wondering if we should have this default value low or high?
> >>
> >> On 6/2/2014 5:03 PM, Bill Burke wrote:
> >>> I ran 10 threads each running 100 threads.  I get a rate of about 31ms
> >>> per loginpage/processLogin/accessCode2Token flow.
> >>>
> >>> According to JProfiler, 65% of time is spent in the password hashing
> >>> algorithm.  I guess this is not surprising because this password hashing
> >>> algorithm is *supposed* to eat up CPU, right?
> >>>
> >>> BTW, running 20 threads concurrently I start to get deadlocks in the
> >>> database around UserSession processing.  Going to look into that.
> >>>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
>
> --
> 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

--

abstractj

From bburke at redhat.com  Tue Jun  3 09:22:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 03 Jun 2014 09:22:27 -0400
Subject: [keycloak-dev] profile results
In-Reply-To: <20140603131425.GA97877@abstractj.org>
References: <538CE6B6.6000806@redhat.com> <538CF189.3050107@redhat.com>
	<626840970.19335580.1401783675261.JavaMail.zimbra@redhat.com>
	<538DC357.8060303@redhat.com>
	<20140603131425.GA97877@abstractj.org>
Message-ID: <538DCC13.1020306@redhat.com>



On 6/3/2014 9:14 AM, Bruno Oliveira wrote:
> It pretty much depends on which machine the system will run, maybe
> make password salting configurable is a good idea.
>

I put in a JIRA for it.  https://issues.jboss.org/browse/KEYCLOAK-508

> The number of iterations pretty much depends on the computational
> resources, you can increase to 100.000.000 for example and make
> the system vulnerable to DDoS.
>

With the previous default of 20000 iterations it was *already* 
vulnerable to DDoS.

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

From bruno at abstractj.org  Tue Jun  3 09:39:23 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 10:39:23 -0300
Subject: [keycloak-dev] UPS bundled and Widlfly integration
Message-ID: <20140603133923.GB97877@abstractj.org>

Good morning,

During UPS server deployment a NPE is raised with Wildfly ? I understand
that currently only EAP is supported.

Specifically I'm currently looking into this:
https://github.com/keycloak/keycloak/blob/634f61281de16b60ca65668c3d7da9be9a78ad2d/project-integrations/aerogear-ups/app/src/main/java/org/keycloak/example/BootstrapListener.java#L16.

My poor attempt to fix was https://gist.github.com/abstractj/3b6fbdd1a0c81c17cbcb, but no luck.
Is KeycloakServletExtension the place where should I look?


--

abstractj

From bburke at redhat.com  Tue Jun  3 09:44:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 03 Jun 2014 09:44:43 -0400
Subject: [keycloak-dev] UPS bundled and Widlfly integration
In-Reply-To: <20140603133923.GB97877@abstractj.org>
References: <20140603133923.GB97877@abstractj.org>
Message-ID: <538DD14B.8080905@redhat.com>

Maybe it is because the application is configured to use the AS7 adapter 
and not Wildfly adapter?!

On 6/3/2014 9:39 AM, Bruno Oliveira wrote:
> Good morning,
>
> During UPS server deployment a NPE is raised with Wildfly ? I understand
> that currently only EAP is supported.
>
> Specifically I'm currently looking into this:
> https://github.com/keycloak/keycloak/blob/634f61281de16b60ca65668c3d7da9be9a78ad2d/project-integrations/aerogear-ups/app/src/main/java/org/keycloak/example/BootstrapListener.java#L16.
>
> My poor attempt to fix was https://gist.github.com/abstractj/3b6fbdd1a0c81c17cbcb, but no luck.
> Is KeycloakServletExtension the place where should I look?
>
>
> --
>
> abstractj
> _______________________________________________
> 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 matzew at apache.org  Tue Jun  3 10:38:32 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 3 Jun 2014 16:38:32 +0200
Subject: [keycloak-dev] UPS bundled and Widlfly integration
In-Reply-To: <538DD14B.8080905@redhat.com>
References: <20140603133923.GB97877@abstractj.org>
	<538DD14B.8080905@redhat.com>
Message-ID: <CAAg5f2Q4rNk9jqtz+i7B9m+bY=i6psSH_bgxebkrocH7f=R7mg@mail.gmail.com>

yes,

right now the 'ag-push.war' is using AS7 Adapter.

A simple thought would be to do some maven assembly fu, inside of our
'server' project, so that we generate two war files:
* ag-push-eap.war
* ag-push-wf.war


But not sure that's really the best to generate two different WAR files,
each for a different server :-)



On Tue, Jun 3, 2014 at 3:44 PM, Bill Burke <bburke at redhat.com> wrote:

> Maybe it is because the application is configured to use the AS7 adapter
> and not Wildfly adapter?!
>
> On 6/3/2014 9:39 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > During UPS server deployment a NPE is raised with Wildfly ? I understand
> > that currently only EAP is supported.
> >
> > Specifically I'm currently looking into this:
> >
> https://github.com/keycloak/keycloak/blob/634f61281de16b60ca65668c3d7da9be9a78ad2d/project-integrations/aerogear-ups/app/src/main/java/org/keycloak/example/BootstrapListener.java#L16
> .
> >
> > My poor attempt to fix was
> https://gist.github.com/abstractj/3b6fbdd1a0c81c17cbcb, but no luck.
> > Is KeycloakServletExtension the place where should I look?
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > 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
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140603/c5a83508/attachment.html 

From bruno at abstractj.org  Tue Jun  3 12:01:29 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 3 Jun 2014 13:01:29 -0300
Subject: [keycloak-dev] UPS bundled and Widlfly integration
In-Reply-To: <538DD14B.8080905@redhat.com>
References: <20140603133923.GB97877@abstractj.org>
	<538DD14B.8080905@redhat.com>
Message-ID: <20140603160129.GA8674@abstractj.org>

Certainly Bill, I did the changes here:
https://github.com/abstractj/aerogear-unifiedpush-server/commit/75e8318e4e5c60e0a2e4aa7cf9d27c75f98406ad

Do I need to include any additional configuration? The NPE persists,
probably because I missed something.

On 2014-06-03, Bill Burke wrote:
> Maybe it is because the application is configured to use the AS7 adapter
> and not Wildfly adapter?!
>
> On 6/3/2014 9:39 AM, Bruno Oliveira wrote:
> > Good morning,
> >
> > During UPS server deployment a NPE is raised with Wildfly ? I understand
> > that currently only EAP is supported.
> >
> > Specifically I'm currently looking into this:
> > https://github.com/keycloak/keycloak/blob/634f61281de16b60ca65668c3d7da9be9a78ad2d/project-integrations/aerogear-ups/app/src/main/java/org/keycloak/example/BootstrapListener.java#L16.
> >
> > My poor attempt to fix was https://gist.github.com/abstractj/3b6fbdd1a0c81c17cbcb, but no luck.
> > Is KeycloakServletExtension the place where should I look?
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > 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

--

abstractj

From bburke at redhat.com  Thu Jun  5 08:51:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 05 Jun 2014 08:51:47 -0400
Subject: [keycloak-dev] investigating caching
Message-ID: <539067E3.7020205@redhat.com>

I think I have a decent way of doing caching, but it is going to take a 
refactoring of the Model API and KeycloakSession API so that caching can 
be layered (i.e. that we can cache realms/apps, but not cache users). 
For instance, the JPA adapter pretty much is hard-wired to have a loaded 
entity before it makes queries like "select user where user.realm = ? 
and user.name = ?".  We need to move things like user queries up to the 
KeycloakSession level so that we can use things like 
EntityManager.getReference() so that we're not making extra DB calls if 
we need to query a user.

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

From stian at redhat.com  Thu Jun  5 10:05:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 5 Jun 2014 10:05:13 -0400 (EDT)
Subject: [keycloak-dev] investigating caching
In-Reply-To: <539067E3.7020205@redhat.com>
References: <539067E3.7020205@redhat.com>
Message-ID: <219463957.21015943.1401977113230.JavaMail.zimbra@redhat.com>

Makes me wonder if we should extend the *Manager approach and only call the model through that. For example:

  RealmManager realmManager = ??
  UserManager user = realmManager.getUser(userId)


 

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 5 June, 2014 1:51:47 PM
> Subject: [keycloak-dev] investigating caching
> 
> I think I have a decent way of doing caching, but it is going to take a
> refactoring of the Model API and KeycloakSession API so that caching can
> be layered (i.e. that we can cache realms/apps, but not cache users).
> For instance, the JPA adapter pretty much is hard-wired to have a loaded
> entity before it makes queries like "select user where user.realm = ?
> and user.name = ?".  We need to move things like user queries up to the
> KeycloakSession level so that we can use things like
> EntityManager.getReference() so that we're not making extra DB calls if
> we need to query a 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 bburke at redhat.com  Thu Jun  5 10:14:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 05 Jun 2014 10:14:35 -0400
Subject: [keycloak-dev] investigating caching
In-Reply-To: <219463957.21015943.1401977113230.JavaMail.zimbra@redhat.com>
References: <539067E3.7020205@redhat.com>
	<219463957.21015943.1401977113230.JavaMail.zimbra@redhat.com>
Message-ID: <53907B4B.80908@redhat.com>

We can, but querying is still model specific.

On 6/5/2014 10:05 AM, Stian Thorgersen wrote:
> Makes me wonder if we should extend the *Manager approach and only call the model through that. For example:
>
>    RealmManager realmManager = ??
>    UserManager user = realmManager.getUser(userId)
>
>
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 5 June, 2014 1:51:47 PM
>> Subject: [keycloak-dev] investigating caching
>>
>> I think I have a decent way of doing caching, but it is going to take a
>> refactoring of the Model API and KeycloakSession API so that caching can
>> be layered (i.e. that we can cache realms/apps, but not cache users).
>> For instance, the JPA adapter pretty much is hard-wired to have a loaded
>> entity before it makes queries like "select user where user.realm = ?
>> and user.name = ?".  We need to move things like user queries up to the
>> KeycloakSession level so that we can use things like
>> EntityManager.getReference() so that we're not making extra DB calls if
>> we need to query a 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
>>

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

From stian at redhat.com  Thu Jun  5 10:18:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 5 Jun 2014 10:18:01 -0400 (EDT)
Subject: [keycloak-dev] investigating caching
In-Reply-To: <53907B4B.80908@redhat.com>
References: <539067E3.7020205@redhat.com>
	<219463957.21015943.1401977113230.JavaMail.zimbra@redhat.com>
	<53907B4B.80908@redhat.com>
Message-ID: <2116037939.21042946.1401977881151.JavaMail.zimbra@redhat.com>

Sure, I was just thinking that if we have to do a fair amount of reorganizing any-ways (i.e. query users from KeycloakSession instead of RealmModel), then it may be a good time to introduce this.

The benefit would be that we don't create managers manually, and we could shift more of the shared logic out of the models into the managers.

----- 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, 5 June, 2014 3:14:35 PM
> Subject: Re: [keycloak-dev] investigating caching
> 
> We can, but querying is still model specific.
> 
> On 6/5/2014 10:05 AM, Stian Thorgersen wrote:
> > Makes me wonder if we should extend the *Manager approach and only call the
> > model through that. For example:
> >
> >    RealmManager realmManager = ??
> >    UserManager user = realmManager.getUser(userId)
> >
> >
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 5 June, 2014 1:51:47 PM
> >> Subject: [keycloak-dev] investigating caching
> >>
> >> I think I have a decent way of doing caching, but it is going to take a
> >> refactoring of the Model API and KeycloakSession API so that caching can
> >> be layered (i.e. that we can cache realms/apps, but not cache users).
> >> For instance, the JPA adapter pretty much is hard-wired to have a loaded
> >> entity before it makes queries like "select user where user.realm = ?
> >> and user.name = ?".  We need to move things like user queries up to the
> >> KeycloakSession level so that we can use things like
> >> EntityManager.getReference() so that we're not making extra DB calls if
> >> we need to query a 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ssilvert at redhat.com  Thu Jun  5 16:54:26 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 05 Jun 2014 16:54:26 -0400
Subject: [keycloak-dev] Testing Undertow Adapter
Message-ID: <5390D902.6070705@redhat.com>

I'm creating a pure Undertow Adapter that doesn't rely on the Servlet 
API.  It requires some changes to the existing Undertow/Servlet adapter.

I want to make sure I don't break anything.  How do you guys test this 
adapter?

Stan

From stian at redhat.com  Fri Jun  6 03:04:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 6 Jun 2014 03:04:21 -0400 (EDT)
Subject: [keycloak-dev] Testing Undertow Adapter
In-Reply-To: <5390D902.6070705@redhat.com>
References: <5390D902.6070705@redhat.com>
Message-ID: <1245749188.21894205.1402038261935.JavaMail.zimbra@redhat.com>

Tests with regards to adapters are a bit limited currently, but we have AdapterTest in testsuite/integration that tests the basics. Test testsuite runs on Keycloak with an embedded Undertow so should be useful for testing your pure Undertow Adapter.  Beyond that we manually test that the examples work on AS 7.1.1, EAP 6.2, EAP 6.3.Beta and WildFly.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 5 June, 2014 9:54:26 PM
> Subject: [keycloak-dev] Testing Undertow Adapter
> 
> I'm creating a pure Undertow Adapter that doesn't rely on the Servlet
> API.  It requires some changes to the existing Undertow/Servlet adapter.
> 
> I want to make sure I don't break anything.  How do you guys test this
> adapter?
> 
> Stan
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Jun  6 10:15:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 06 Jun 2014 10:15:38 -0400
Subject: [keycloak-dev] Testing Undertow Adapter
In-Reply-To: <1245749188.21894205.1402038261935.JavaMail.zimbra@redhat.com>
References: <5390D902.6070705@redhat.com>
	<1245749188.21894205.1402038261935.JavaMail.zimbra@redhat.com>
Message-ID: <5391CD0A.7060804@redhat.com>

I think the undertow adapter is tested decently.  browser and bearer 
token auth is tested, as well as some of the admin callback api. 
Missing is CORS tests.

On 6/6/2014 3:04 AM, Stian Thorgersen wrote:
> Tests with regards to adapters are a bit limited currently, but we have AdapterTest in testsuite/integration that tests the basics. Test testsuite runs on Keycloak with an embedded Undertow so should be useful for testing your pure Undertow Adapter.  Beyond that we manually test that the examples work on AS 7.1.1, EAP 6.2, EAP 6.3.Beta and WildFly.
>
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 5 June, 2014 9:54:26 PM
>> Subject: [keycloak-dev] Testing Undertow Adapter
>>
>> I'm creating a pure Undertow Adapter that doesn't rely on the Servlet
>> API.  It requires some changes to the existing Undertow/Servlet adapter.
>>
>> I want to make sure I don't break anything.  How do you guys test this
>> adapter?
>>
>> 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
>

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

From ssilvert at redhat.com  Mon Jun  9 14:49:48 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 09 Jun 2014 14:49:48 -0400
Subject: [keycloak-dev] License on source
Message-ID: <539601CC.7050703@redhat.com>

I see a lot of Keycloak source that doesn't declare a license. Shall I 
add the Apache license to source in the module I'm working on?

Stan

From bburke at redhat.com  Mon Jun  9 15:07:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Jun 2014 15:07:57 -0400
Subject: [keycloak-dev] License on source
In-Reply-To: <539601CC.7050703@redhat.com>
References: <539601CC.7050703@redhat.com>
Message-ID: <5396060D.6020900@redhat.com>

That's fine.

On 6/9/2014 2:49 PM, Stan Silvert wrote:
> I see a lot of Keycloak source that doesn't declare a license. Shall I
> add the Apache license to source in the module I'm working on?
>
> Stan
> _______________________________________________
> 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 bruno at abstractj.org  Mon Jun  9 17:39:38 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 9 Jun 2014 18:39:38 -0300
Subject: [keycloak-dev] Retrieving the current logged in username
Message-ID: <20140609213938.GA26157@abstractj.org>

Good morning guys,

Which way is the best to retrieve the current logged in username? I'm
trying with KeycloakSecurityContext, but no luck.

Thanks in advance.

--

abstractj

From ssilvert at redhat.com  Mon Jun  9 17:51:20 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 09 Jun 2014 17:51:20 -0400
Subject: [keycloak-dev] Retrieving the current logged in username
In-Reply-To: <20140609213938.GA26157@abstractj.org>
References: <20140609213938.GA26157@abstractj.org>
Message-ID: <53962C58.9030106@redhat.com>

You are probably looking for KeycloakSecurityContext.getToken().getPreferredUsername()?


On 6/9/2014 5:39 PM, Bruno Oliveira wrote:
> Good morning guys,
>
> Which way is the best to retrieve the current logged in username? I'm
> trying with KeycloakSecurityContext, but no luck.
>
> Thanks in advance.
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon Jun  9 18:48:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Jun 2014 18:48:46 -0400
Subject: [keycloak-dev] Retrieving the current logged in username
In-Reply-To: <20140609213938.GA26157@abstractj.org>
References: <20140609213938.GA26157@abstractj.org>
Message-ID: <539639CE.8070300@redhat.com>

can you get the Principal?  KeycloakPrincipal p = 
(KeycloakPrincipal)securityContext.getUserPrincipal();

KeycloakSecurityContext ctx = p.getKeycloakSecurityContext();

On 6/9/2014 5:39 PM, Bruno Oliveira wrote:
> Good morning guys,
>
> Which way is the best to retrieve the current logged in username? I'm
> trying with KeycloakSecurityContext, but no luck.
>
> Thanks in advance.
>
> --
>
> abstractj
> _______________________________________________
> 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 bruno at abstractj.org  Mon Jun  9 22:33:03 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 9 Jun 2014 23:33:03 -0300
Subject: [keycloak-dev] Retrieving the current logged in username
In-Reply-To: <53962C58.9030106@redhat.com>
References: <20140609213938.GA26157@abstractj.org>
	<53962C58.9030106@redhat.com>
Message-ID: <20140610023303.GA32020@abstractj.org>

Thanks Bill and Stan.

This is what I've been trying to do[1]. Unfortunately after a user is
successfully authenticated the method ".getUserPrincipal" returns null.

I saw an issue reported with old versions of Resteasy[2], but the NPE persists even
after upgrade the project to the latest version.

[1] - https://github.com/abstractj/aerogear-unifiedpush-server/commit/de1f50370f4c339ad394b94def377a4c0072988b#diff-2ab40ceec347387de26ff2d7cab8ecb3R56
[2] - https://issues.jboss.org/browse/AS7-3227

On 2014-06-09, Stan Silvert wrote:
> You are probably looking for KeycloakSecurityContext.getToken().getPreferredUsername()?
>
>
> On 6/9/2014 5:39 PM, Bruno Oliveira wrote:
> > Good morning guys,
> >
> > Which way is the best to retrieve the current logged in username? I'm
> > trying with KeycloakSecurityContext, but no luck.
> >
> > Thanks in advance.
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From bburke at redhat.com  Tue Jun 10 09:15:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 10 Jun 2014 09:15:59 -0400
Subject: [keycloak-dev] Retrieving the current logged in username
In-Reply-To: <20140610023303.GA32020@abstractj.org>
References: <20140609213938.GA26157@abstractj.org>	<53962C58.9030106@redhat.com>
	<20140610023303.GA32020@abstractj.org>
Message-ID: <5397050F.3030805@redhat.com>

Log a JIRA please?  I'll add that to the Beta 3 todo list.

On 6/9/2014 10:33 PM, Bruno Oliveira wrote:
> Thanks Bill and Stan.
>
> This is what I've been trying to do[1]. Unfortunately after a user is
> successfully authenticated the method ".getUserPrincipal" returns null.
>
> I saw an issue reported with old versions of Resteasy[2], but the NPE persists even
> after upgrade the project to the latest version.
>
> [1] - https://github.com/abstractj/aerogear-unifiedpush-server/commit/de1f50370f4c339ad394b94def377a4c0072988b#diff-2ab40ceec347387de26ff2d7cab8ecb3R56
> [2] - https://issues.jboss.org/browse/AS7-3227
>
> On 2014-06-09, Stan Silvert wrote:
>> You are probably looking for KeycloakSecurityContext.getToken().getPreferredUsername()?
>>
>>
>> On 6/9/2014 5:39 PM, Bruno Oliveira wrote:
>>> Good morning guys,
>>>
>>> Which way is the best to retrieve the current logged in username? I'm
>>> trying with KeycloakSecurityContext, but no luck.
>>>
>>> Thanks in advance.
>>>
>>> --
>>>
>>> abstractj
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> --
>
> abstractj
> _______________________________________________
> 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 bruno at abstractj.org  Tue Jun 10 10:20:29 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 10 Jun 2014 11:20:29 -0300
Subject: [keycloak-dev] Retrieving the current logged in username
In-Reply-To: <5397050F.3030805@redhat.com>
References: <20140609213938.GA26157@abstractj.org>
	<53962C58.9030106@redhat.com>
	<20140610023303.GA32020@abstractj.org>
	<5397050F.3030805@redhat.com>
Message-ID: <20140610142029.GA40820@abstractj.org>

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

Thanks Bill.

On 2014-06-10, Bill Burke wrote:
> Log a JIRA please?  I'll add that to the Beta 3 todo list.
>
> On 6/9/2014 10:33 PM, Bruno Oliveira wrote:
> > Thanks Bill and Stan.
> >
> > This is what I've been trying to do[1]. Unfortunately after a user is
> > successfully authenticated the method ".getUserPrincipal" returns null.
> >
> > I saw an issue reported with old versions of Resteasy[2], but the NPE persists even
> > after upgrade the project to the latest version.
> >
> > [1] - https://github.com/abstractj/aerogear-unifiedpush-server/commit/de1f50370f4c339ad394b94def377a4c0072988b#diff-2ab40ceec347387de26ff2d7cab8ecb3R56
> > [2] - https://issues.jboss.org/browse/AS7-3227
> >
> > On 2014-06-09, Stan Silvert wrote:
> >> You are probably looking for KeycloakSecurityContext.getToken().getPreferredUsername()?
> >>
> >>
> >> On 6/9/2014 5:39 PM, Bruno Oliveira wrote:
> >>> Good morning guys,
> >>>
> >>> Which way is the best to retrieve the current logged in username? I'm
> >>> trying with KeycloakSecurityContext, but no luck.
> >>>
> >>> Thanks in advance.
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > 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

--

abstractj

From bburke at redhat.com  Fri Jun 13 09:52:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Jun 2014 09:52:33 -0400
Subject: [keycloak-dev] refactored model for caching
Message-ID: <539B0221.2030602@redhat.com>

I'm almost done with a caching implementation.  Had to do some 
refactoring though

* Some methods were moved from RealmModel to ClientModel and UserModel. 
  scope mapping methods, role mapping methods, stuff that really belonged

* I moved a lot of queries up to the KeycloakSession interface.  The 
reason I did this is so that a caching layer could make queries without 
having to do a DB query to load a realm, app, client, or whatever.

I wanted to commit this stuff now as I changed a lot of files and didn't 
want tons of merge conflicts after you guys get back.  Hopefully I can 
have a cache working in the next few days.

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

From bburke at redhat.com  Fri Jun 13 20:27:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Jun 2014 20:27:56 -0400
Subject: [keycloak-dev] top level cache implemented
Message-ID: <539B970C.6040700@redhat.com>

I implemented a non-clustered simple cache for realms, apps, oauth 
clients, and roles.  Its backed by ConconcurrentHashMaps and is in 
memory.  It is on by default and the model tests use it.

If you want to disable it, go into keycloak-server.json and change the 
modelCache provider to "none".  I'll probably disable it for the release.

For a simple perf test of loading the login page and doing the access 
code flow to obtain a token, performance improved by 20-25%.  I'm 
guessing this improvement would be much higher with a non-embedded DBMS. 
  The only SQL which ran was loading users, load/update of UserSessions, 
and load of roles.  I could do more work to avoid loading roles.

Next steps?

* I need to work on stuff needed by Aerogear and other bugs and release 
beta 3.
* Should Hibernate 2nd level cache be investigated before more work is 
done here?
* Implement optional user caching to "simple" cache to see the 
performance benefits.
* Create a comprehensive integrity test that runs multiple threads that 
update/read concurrently to bang on cache implementation/ keycloak in 
general.
* make the cache clusterable.  Meaning secure invalidation messages.  I 
don't know if this means using Infinispan.  Might be more work to 
incorporate, configure, deploy, and bootstrap infinispan, than to 
provide simple HTTP invalidation messages.  Turning off the cache 
entirely if communication between nodes fails.



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

From cvasilak at gmail.com  Mon Jun 16 05:04:30 2014
From: cvasilak at gmail.com (Christos Vasilakis)
Date: Mon, 16 Jun 2014 12:04:30 +0300
Subject: [keycloak-dev] Revocation of access_token
Message-ID: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>

Hi all,

is there any way a user that holds an ?access_token?  to manually revoke it by posting to a particular URL?

'curl "https://server/realms/application/tokens/revoke?token=<token>'

Sorry if i am missing sth would be glad if you point me to the right direction.

Regards,
Christos






From stian at redhat.com  Mon Jun 16 05:22:23 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jun 2014 05:22:23 -0400 (EDT)
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>
Message-ID: <1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>

You can't revoke individual tokens or refresh tokens, but all tokens (and cookies) are linked to a user session which can be revoked.

To logout the current session (uses cookie):
  https://server/realms/application/tokens/logout

To logout a specific session (you can get the session state from token:
  https://server/realms/application/tokens/logout?session_state=<SESSION>

You can also logout sessions from the account management, or through the admin console.

----- Original Message -----
> From: "Christos Vasilakis" <cvasilak at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 16 June, 2014 10:04:30 AM
> Subject: [keycloak-dev] Revocation of access_token
> 
> Hi all,
> 
> is there any way a user that holds an ?access_token?  to manually revoke it
> by posting to a particular URL?
> 
> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
> 
> Sorry if i am missing sth would be glad if you point me to the right
> direction.
> 
> Regards,
> Christos
> 
> 
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


From corinnekrych at gmail.com  Mon Jun 16 05:51:31 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 16 Jun 2014 11:51:31 +0200
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>
	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>
Message-ID: <7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>

Thanks Stian for you reply

Interesting it looks different from what we?ve seen so far with Google and Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification on revoke toke where you put the token you want to revoke and it will revoke all refreh and access tokens.

++
Corinne
On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:

> You can't revoke individual tokens or refresh tokens, but all tokens (and cookies) are linked to a user session which can be revoked.
> 
> To logout the current session (uses cookie):
>  https://server/realms/application/tokens/logout
> 
> To logout a specific session (you can get the session state from token:
>  https://server/realms/application/tokens/logout?session_state=<SESSION>
> 
> You can also logout sessions from the account management, or through the admin console.
> 
> ----- Original Message -----
>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 16 June, 2014 10:04:30 AM
>> Subject: [keycloak-dev] Revocation of access_token
>> 
>> Hi all,
>> 
>> is there any way a user that holds an ?access_token?  to manually revoke it
>> by posting to a particular URL?
>> 
>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>> 
>> Sorry if i am missing sth would be glad if you point me to the right
>> direction.
>> 
>> Regards,
>> Christos
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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 Jun 16 06:27:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jun 2014 06:27:09 -0400 (EDT)
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>
	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>
	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>
Message-ID: <1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>

We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.

----- Original Message -----
> From: "Corinne Krych" <corinnekrych at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, 16 June, 2014 10:51:31 AM
> Subject: Re: [keycloak-dev] Revocation of access_token
> 
> Thanks Stian for you reply
> 
> Interesting it looks different from what we?ve seen so far with Google and
> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
> on revoke toke where you put the token you want to revoke and it will revoke
> all refreh and access tokens.
> 
> ++
> Corinne
> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > You can't revoke individual tokens or refresh tokens, but all tokens (and
> > cookies) are linked to a user session which can be revoked.
> > 
> > To logout the current session (uses cookie):
> >  https://server/realms/application/tokens/logout
> > 
> > To logout a specific session (you can get the session state from token:
> >  https://server/realms/application/tokens/logout?session_state=<SESSION>
> > 
> > You can also logout sessions from the account management, or through the
> > admin console.
> > 
> > ----- Original Message -----
> >> From: "Christos Vasilakis" <cvasilak at gmail.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 16 June, 2014 10:04:30 AM
> >> Subject: [keycloak-dev] Revocation of access_token
> >> 
> >> Hi all,
> >> 
> >> is there any way a user that holds an ?access_token?  to manually revoke
> >> it
> >> by posting to a particular URL?
> >> 
> >> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
> >> 
> >> Sorry if i am missing sth would be glad if you point me to the right
> >> direction.
> >> 
> >> Regards,
> >> Christos
> >> 
> >> 
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> 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 corinnekrych at gmail.com  Mon Jun 16 06:34:27 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 16 Jun 2014 12:34:27 +0200
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>
	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>
	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>
	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
Message-ID: <BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>

We?ll keep an eye on that.
Thanks,
Corinne
PS: we track it with https://issues.jboss.org/browse/AGIOS-206 

On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:

> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
> 
> ----- Original Message -----
>> From: "Corinne Krych" <corinnekrych at gmail.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>> Sent: Monday, 16 June, 2014 10:51:31 AM
>> Subject: Re: [keycloak-dev] Revocation of access_token
>> 
>> Thanks Stian for you reply
>> 
>> Interesting it looks different from what we?ve seen so far with Google and
>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>> on revoke toke where you put the token you want to revoke and it will revoke
>> all refreh and access tokens.
>> 
>> ++
>> Corinne
>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>> 
>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>> cookies) are linked to a user session which can be revoked.
>>> 
>>> To logout the current session (uses cookie):
>>> https://server/realms/application/tokens/logout
>>> 
>>> To logout a specific session (you can get the session state from token:
>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>> 
>>> You can also logout sessions from the account management, or through the
>>> admin console.
>>> 
>>> ----- Original Message -----
>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>> Subject: [keycloak-dev] Revocation of access_token
>>>> 
>>>> Hi all,
>>>> 
>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>> it
>>>> by posting to a particular URL?
>>>> 
>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>> 
>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>> direction.
>>>> 
>>>> Regards,
>>>> Christos
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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  Mon Jun 16 08:44:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Jun 2014 08:44:35 -0400
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
	<BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
Message-ID: <539EE6B3.2030507@redhat.com>

FYI, even if we could do this, it wouldn't look like it from a user 
perspective if there was an SSO session active and if they visited the 
revoked application again.  In that case they'd just get a new refresh 
token.

On 6/16/2014 6:34 AM, Corinne Krych wrote:
> We?ll keep an eye on that.
> Thanks,
> Corinne
> PS: we track it with https://issues.jboss.org/browse/AGIOS-206
>
> On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:
>
>> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
>>
>> ----- Original Message -----
>>> From: "Corinne Krych" <corinnekrych at gmail.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>>> Sent: Monday, 16 June, 2014 10:51:31 AM
>>> Subject: Re: [keycloak-dev] Revocation of access_token
>>>
>>> Thanks Stian for you reply
>>>
>>> Interesting it looks different from what we?ve seen so far with Google and
>>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>>> on revoke toke where you put the token you want to revoke and it will revoke
>>> all refreh and access tokens.
>>>
>>> ++
>>> Corinne
>>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>>>
>>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>>> cookies) are linked to a user session which can be revoked.
>>>>
>>>> To logout the current session (uses cookie):
>>>> https://server/realms/application/tokens/logout
>>>>
>>>> To logout a specific session (you can get the session state from token:
>>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>>>
>>>> You can also logout sessions from the account management, or through the
>>>> admin console.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>>> Subject: [keycloak-dev] Revocation of access_token
>>>>>
>>>>> Hi all,
>>>>>
>>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>>> it
>>>>> by posting to a particular URL?
>>>>>
>>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>>>
>>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>>> direction.
>>>>>
>>>>> Regards,
>>>>> Christos
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 corinnekrych at gmail.com  Mon Jun 16 08:50:10 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 16 Jun 2014 14:50:10 +0200
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <539EE6B3.2030507@redhat.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
	<BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
	<539EE6B3.2030507@redhat.com>
Message-ID: <BC16C14D-8D2C-4A17-AED0-F3E1238E4F52@gmail.com>

What do you mean?
when an application is revoked (for now using the session revoke), and the uservisit the app again, he will need to get a new refresh and access token and for that he will be prompted again to grant access, right?

++
Corinne
On 16 Jun 2014, at 14:44, Bill Burke <bburke at redhat.com> wrote:

> FYI, even if we could do this, it wouldn't look like it from a user 
> perspective if there was an SSO session active and if they visited the 
> revoked application again.  In that case they'd just get a new refresh 
> token.
> 
> On 6/16/2014 6:34 AM, Corinne Krych wrote:
>> We?ll keep an eye on that.
>> Thanks,
>> Corinne
>> PS: we track it with https://issues.jboss.org/browse/AGIOS-206
>> 
>> On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:
>> 
>>> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
>>> 
>>> ----- Original Message -----
>>>> From: "Corinne Krych" <corinnekrych at gmail.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 16 June, 2014 10:51:31 AM
>>>> Subject: Re: [keycloak-dev] Revocation of access_token
>>>> 
>>>> Thanks Stian for you reply
>>>> 
>>>> Interesting it looks different from what we?ve seen so far with Google and
>>>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>>>> on revoke toke where you put the token you want to revoke and it will revoke
>>>> all refreh and access tokens.
>>>> 
>>>> ++
>>>> Corinne
>>>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>>>> 
>>>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>>>> cookies) are linked to a user session which can be revoked.
>>>>> 
>>>>> To logout the current session (uses cookie):
>>>>> https://server/realms/application/tokens/logout
>>>>> 
>>>>> To logout a specific session (you can get the session state from token:
>>>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>>>> 
>>>>> You can also logout sessions from the account management, or through the
>>>>> admin console.
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>>>> Subject: [keycloak-dev] Revocation of access_token
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>>>> it
>>>>>> by posting to a particular URL?
>>>>>> 
>>>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>>>> 
>>>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>>>> direction.
>>>>>> 
>>>>>> Regards,
>>>>>> Christos
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From stian at redhat.com  Mon Jun 16 09:07:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jun 2014 09:07:00 -0400 (EDT)
Subject: [keycloak-dev] KEYCLOAK-523
In-Reply-To: <1199142116.26490867.1402924011821.JavaMail.zimbra@redhat.com>
Message-ID: <1419128986.26491047.1402924020166.JavaMail.zimbra@redhat.com>

Bill,

Are you looking at https://issues.jboss.org/browse/KEYCLOAK-523? Or should I take a peek?

From bburke at redhat.com  Mon Jun 16 09:19:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Jun 2014 09:19:08 -0400
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <BC16C14D-8D2C-4A17-AED0-F3E1238E4F52@gmail.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
	<BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
	<539EE6B3.2030507@redhat.com>
	<BC16C14D-8D2C-4A17-AED0-F3E1238E4F52@gmail.com>
Message-ID: <539EEECC.1080606@redhat.com>

Depends.  Applications don't have to get grant permission.  OAuth 
clients do.

On 6/16/2014 8:50 AM, Corinne Krych wrote:
> What do you mean?
> when an application is revoked (for now using the session revoke), and the uservisit the app again, he will need to get a new refresh and access token and for that he will be prompted again to grant access, right?
>
> ++
> Corinne
> On 16 Jun 2014, at 14:44, Bill Burke <bburke at redhat.com> wrote:
>
>> FYI, even if we could do this, it wouldn't look like it from a user
>> perspective if there was an SSO session active and if they visited the
>> revoked application again.  In that case they'd just get a new refresh
>> token.
>>
>> On 6/16/2014 6:34 AM, Corinne Krych wrote:
>>> We?ll keep an eye on that.
>>> Thanks,
>>> Corinne
>>> PS: we track it with https://issues.jboss.org/browse/AGIOS-206
>>>
>>> On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:
>>>
>>>> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Corinne Krych" <corinnekrych at gmail.com>
>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, 16 June, 2014 10:51:31 AM
>>>>> Subject: Re: [keycloak-dev] Revocation of access_token
>>>>>
>>>>> Thanks Stian for you reply
>>>>>
>>>>> Interesting it looks different from what we?ve seen so far with Google and
>>>>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>>>>> on revoke toke where you put the token you want to revoke and it will revoke
>>>>> all refreh and access tokens.
>>>>>
>>>>> ++
>>>>> Corinne
>>>>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>
>>>>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>>>>> cookies) are linked to a user session which can be revoked.
>>>>>>
>>>>>> To logout the current session (uses cookie):
>>>>>> https://server/realms/application/tokens/logout
>>>>>>
>>>>>> To logout a specific session (you can get the session state from token:
>>>>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>>>>>
>>>>>> You can also logout sessions from the account management, or through the
>>>>>> admin console.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>>>>> Subject: [keycloak-dev] Revocation of access_token
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>>>>> it
>>>>>>> by posting to a particular URL?
>>>>>>>
>>>>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>>>>>
>>>>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>>>>> direction.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Christos
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>> _______________________________________________
>> 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 Jun 16 09:22:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Jun 2014 09:22:14 -0400
Subject: [keycloak-dev] KEYCLOAK-523
In-Reply-To: <1419128986.26491047.1402924020166.JavaMail.zimbra@redhat.com>
References: <1419128986.26491047.1402924020166.JavaMail.zimbra@redhat.com>
Message-ID: <539EEF86.3000307@redhat.com>

That would be cool if you could look at that.

On 6/16/2014 9:07 AM, Stian Thorgersen wrote:
> Bill,
>
> Are you looking at https://issues.jboss.org/browse/KEYCLOAK-523? Or should I take a peek?
>

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

From corinnekrych at gmail.com  Mon Jun 16 09:26:49 2014
From: corinnekrych at gmail.com (Corinne Krych)
Date: Mon, 16 Jun 2014 15:26:49 +0200
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <539EEECC.1080606@redhat.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
	<BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
	<539EE6B3.2030507@redhat.com>
	<BC16C14D-8D2C-4A17-AED0-F3E1238E4F52@gmail.com>
	<539EEECC.1080606@redhat.com>
Message-ID: <EEBABEA5-84BF-425F-8753-BF8F3A59663C@gmail.com>

Oki.
I should have mentioned that my use case/scenario was for OAuth2 client.
in that case it is similar to other Oauth2 provider: you do need to grant access again after a revoke.

On 16 Jun 2014, at 15:19, Bill Burke <bburke at redhat.com> wrote:

> Depends.  Applications don't have to get grant permission.  OAuth clients do.
> 
> On 6/16/2014 8:50 AM, Corinne Krych wrote:
>> What do you mean?
>> when an application is revoked (for now using the session revoke), and the uservisit the app again, he will need to get a new refresh and access token and for that he will be prompted again to grant access, right?
>> 
>> ++
>> Corinne
>> On 16 Jun 2014, at 14:44, Bill Burke <bburke at redhat.com> wrote:
>> 
>>> FYI, even if we could do this, it wouldn't look like it from a user
>>> perspective if there was an SSO session active and if they visited the
>>> revoked application again.  In that case they'd just get a new refresh
>>> token.
>>> 
>>> On 6/16/2014 6:34 AM, Corinne Krych wrote:
>>>> We?ll keep an eye on that.
>>>> Thanks,
>>>> Corinne
>>>> PS: we track it with https://issues.jboss.org/browse/AGIOS-206
>>>> 
>>>> On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:
>>>> 
>>>>> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
>>>>> 
>>>>> ----- Original Message -----
>>>>>> From: "Corinne Krych" <corinnekrych at gmail.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>>>>>> Sent: Monday, 16 June, 2014 10:51:31 AM
>>>>>> Subject: Re: [keycloak-dev] Revocation of access_token
>>>>>> 
>>>>>> Thanks Stian for you reply
>>>>>> 
>>>>>> Interesting it looks different from what we?ve seen so far with Google and
>>>>>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>>>>>> on revoke toke where you put the token you want to revoke and it will revoke
>>>>>> all refreh and access tokens.
>>>>>> 
>>>>>> ++
>>>>>> Corinne
>>>>>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>> 
>>>>>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>>>>>> cookies) are linked to a user session which can be revoked.
>>>>>>> 
>>>>>>> To logout the current session (uses cookie):
>>>>>>> https://server/realms/application/tokens/logout
>>>>>>> 
>>>>>>> To logout a specific session (you can get the session state from token:
>>>>>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>>>>>> 
>>>>>>> You can also logout sessions from the account management, or through the
>>>>>>> admin console.
>>>>>>> 
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>>>>>> Subject: [keycloak-dev] Revocation of access_token
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>>>>>> it
>>>>>>>> by posting to a particular URL?
>>>>>>>> 
>>>>>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>>>>>> 
>>>>>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>>>>>> direction.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Christos
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>> _______________________________________________
>>> 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 Jun 16 10:10:52 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Jun 2014 10:10:52 -0400
Subject: [keycloak-dev] Revocation of access_token
In-Reply-To: <EEBABEA5-84BF-425F-8753-BF8F3A59663C@gmail.com>
References: <7ED2A0CD-7F1A-4E49-B48C-053F72E486F9@gmail.com>	<1607617098.26374922.1402910543180.JavaMail.zimbra@redhat.com>	<7BC36FEE-C1E3-4D0C-834E-1D263530809A@gmail.com>	<1444375465.26401580.1402914429601.JavaMail.zimbra@redhat.com>
	<BA56A111-1F29-4121-A94D-F7D6FA36AC08@gmail.com>
	<539EE6B3.2030507@redhat.com>
	<BC16C14D-8D2C-4A17-AED0-F3E1238E4F52@gmail.com>
	<539EEECC.1080606@redhat.com>
	<EEBABEA5-84BF-425F-8753-BF8F3A59663C@gmail.com>
Message-ID: <539EFAEC.5030706@redhat.com>

I'm just loathed to do this kind of stuff as its even more database 
updates/inserts.  We're going to need some better alternative ways for 
session management.

On 6/16/2014 9:26 AM, Corinne Krych wrote:
> Oki.
> I should have mentioned that my use case/scenario was for OAuth2 client.
> in that case it is similar to other Oauth2 provider: you do need to grant access again after a revoke.
>
> On 16 Jun 2014, at 15:19, Bill Burke <bburke at redhat.com> wrote:
>
>> Depends.  Applications don't have to get grant permission.  OAuth clients do.
>>
>> On 6/16/2014 8:50 AM, Corinne Krych wrote:
>>> What do you mean?
>>> when an application is revoked (for now using the session revoke), and the uservisit the app again, he will need to get a new refresh and access token and for that he will be prompted again to grant access, right?
>>>
>>> ++
>>> Corinne
>>> On 16 Jun 2014, at 14:44, Bill Burke <bburke at redhat.com> wrote:
>>>
>>>> FYI, even if we could do this, it wouldn't look like it from a user
>>>> perspective if there was an SSO session active and if they visited the
>>>> revoked application again.  In that case they'd just get a new refresh
>>>> token.
>>>>
>>>> On 6/16/2014 6:34 AM, Corinne Krych wrote:
>>>>> We?ll keep an eye on that.
>>>>> Thanks,
>>>>> Corinne
>>>>> PS: we track it with https://issues.jboss.org/browse/AGIOS-206
>>>>>
>>>>> On 16 Jun 2014, at 12:27, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>
>>>>>> We'll probably also add something more like what Google and Facebook have in the future, by having the option to list what grants have been given to clients in account management, and the ability to revoke access to a specific client.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Corinne Krych" <corinnekrych at gmail.com>
>>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>>> Cc: "Christos Vasilakis" <cvasilak at gmail.com>, keycloak-dev at lists.jboss.org
>>>>>>> Sent: Monday, 16 June, 2014 10:51:31 AM
>>>>>>> Subject: Re: [keycloak-dev] Revocation of access_token
>>>>>>>
>>>>>>> Thanks Stian for you reply
>>>>>>>
>>>>>>> Interesting it looks different from what we?ve seen so far with Google and
>>>>>>> Facebook, closer to http://tools.ietf.org/html/rfc7009 draft specification
>>>>>>> on revoke toke where you put the token you want to revoke and it will revoke
>>>>>>> all refreh and access tokens.
>>>>>>>
>>>>>>> ++
>>>>>>> Corinne
>>>>>>> On 16 Jun 2014, at 11:22, Stian Thorgersen <stian at redhat.com> wrote:
>>>>>>>
>>>>>>>> You can't revoke individual tokens or refresh tokens, but all tokens (and
>>>>>>>> cookies) are linked to a user session which can be revoked.
>>>>>>>>
>>>>>>>> To logout the current session (uses cookie):
>>>>>>>> https://server/realms/application/tokens/logout
>>>>>>>>
>>>>>>>> To logout a specific session (you can get the session state from token:
>>>>>>>> https://server/realms/application/tokens/logout?session_state=<SESSION>
>>>>>>>>
>>>>>>>> You can also logout sessions from the account management, or through the
>>>>>>>> admin console.
>>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Christos Vasilakis" <cvasilak at gmail.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Monday, 16 June, 2014 10:04:30 AM
>>>>>>>>> Subject: [keycloak-dev] Revocation of access_token
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> is there any way a user that holds an ?access_token?  to manually revoke
>>>>>>>>> it
>>>>>>>>> by posting to a particular URL?
>>>>>>>>>
>>>>>>>>> 'curl "https://server/realms/application/tokens/revoke?token=<token>'
>>>>>>>>>
>>>>>>>>> Sorry if i am missing sth would be glad if you point me to the right
>>>>>>>>> direction.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Christos
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>> _______________________________________________
>>>> 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
>

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

From bburke at redhat.com  Mon Jun 16 11:24:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Jun 2014 11:24:16 -0400
Subject: [keycloak-dev] need a release?
Message-ID: <539F0C20.3000700@redhat.com>

Do we need one still this week?

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

From ssilvert at redhat.com  Mon Jun 16 12:00:02 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 16 Jun 2014 12:00:02 -0400
Subject: [keycloak-dev] need a release?
In-Reply-To: <539F0C20.3000700@redhat.com>
References: <539F0C20.3000700@redhat.com>
Message-ID: <539F1482.8010503@redhat.com>

On 6/16/2014 11:24 AM, Bill Burke wrote:
> Do we need one still this week?
>
A release this week or next would be helpful to me.  But don't base your 
decision on my needs.  I can continue fine without one.

From stian at redhat.com  Mon Jun 16 12:02:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 16 Jun 2014 12:02:19 -0400 (EDT)
Subject: [keycloak-dev] need a release?
In-Reply-To: <539F0C20.3000700@redhat.com>
References: <539F0C20.3000700@redhat.com>
Message-ID: <272736090.26644359.1402934539497.JavaMail.zimbra@redhat.com>

Yep, AeroGear guys wants a release for Tue/Wed. They are still testing stuff so we'll need to wait for confirmation that everything is working first.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 16 June, 2014 4:24:16 PM
> Subject: [keycloak-dev] need a release?
> 
> Do we need one still this week?
> 
> --
> 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  Mon Jun 16 12:21:15 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 16 Jun 2014 18:21:15 +0200
Subject: [keycloak-dev] need a release?
In-Reply-To: <539F0C20.3000700@redhat.com>
References: <539F0C20.3000700@redhat.com>
Message-ID: <539F197B.10409@redhat.com>

Having release might be helpful for consultants, who are testing with 
Active Directory, so they can use released Keycloak instead of master.

Currently they are testing Keycloak + Active Directory in their 
environment with KC master and it seems that last issue they had is 
maven related (broken picketlink artifact). Having full released 
distribution might help to avoid those issues though.

Marek

On 16.6.2014 17:24, Bill Burke wrote:
> Do we need one still this week?
>


From bruno at abstractj.org  Mon Jun 16 17:56:55 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 16 Jun 2014 18:56:55 -0300
Subject: [keycloak-dev] need a release?
In-Reply-To: <539F1482.8010503@redhat.com>
References: <539F0C20.3000700@redhat.com>
 <539F1482.8010503@redhat.com>
Message-ID: <20140616215655.GA6484@abstractj.org>

Hi guys, sorry for the late response. I think I'm done with my tests and
now most of my tasks are related with the integration into our UI.

+1 on release beta3 Tue or Wed if possible.

On 2014-06-16, Stan Silvert wrote:
> On 6/16/2014 11:24 AM, Bill Burke wrote:
> > Do we need one still this week?
> >
> A release this week or next would be helpful to me.  But don't base your
> decision on my needs.  I can continue fine without one.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From bruno at abstractj.org  Mon Jun 16 23:34:55 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 17 Jun 2014 00:34:55 -0300
Subject: [keycloak-dev] Dynamically add new users/roles
Message-ID: <20140617033454.GA12274@abstractj.org>

Good morning guys,

Does exist any way to programatically add new users and roles with
Keycloak?


--

abstractj

From mposolda at redhat.com  Tue Jun 17 03:17:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 17 Jun 2014 09:17:52 +0200
Subject: [keycloak-dev] Dynamically add new users/roles
In-Reply-To: <20140617033454.GA12274@abstractj.org>
References: <20140617033454.GA12274@abstractj.org>
Message-ID: <539FEBA0.6090409@redhat.com>

Hi Bruno,

yes it exists. You can use our model API to add new users and/or roles. 
I can see that this is already used inside your UpsSecurityApplication 
https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/src/main/java/org/aerogear/ups/security/UpsSecurityApplication.java#L25, 
which is doing some modification to master realm with usage of this 
model API. Note that you always need to wrap all calls to model API into 
KeycloakTransaction as seen in this example.

For more reference on how to retrieve realm, and add users or roles, see 
for example unit test here 
https://github.com/keycloak/keycloak/blob/master/model/tests/src/test/java/org/keycloak/model/test/AdapterTest.java#L241 
(for adding user) and here 
https://github.com/keycloak/keycloak/blob/master/model/tests/src/test/java/org/keycloak/model/test/AdapterTest.java#L433 
for adding role.

Marek


On 17.6.2014 05:34, Bruno Oliveira wrote:
> Good morning guys,
>
> Does exist any way to programatically add new users and roles with
> Keycloak?
>
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Wed Jun 18 13:31:53 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 14:31:53 -0300
Subject: [keycloak-dev] need a release?
In-Reply-To: <539F0C20.3000700@redhat.com>
References: <539F0C20.3000700@redhat.com>
Message-ID: <20140618173153.GA58896@abstractj.org>

Good morning,

Are you guys planning to push Keycloak to nexus this week?

On 2014-06-16, Bill Burke wrote:
> Do we need one still this week?
>
> --
> 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

--

abstractj

From mposolda at redhat.com  Wed Jun 18 14:36:21 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 18 Jun 2014 20:36:21 +0200
Subject: [keycloak-dev] need a release?
In-Reply-To: <20140618173153.GA58896@abstractj.org>
References: <539F0C20.3000700@redhat.com>
	<20140618173153.GA58896@abstractj.org>
Message-ID: <53A1DC25.9000500@redhat.com>

It's in jboss nexus already . For example: 
http://repository.jboss.org/nexus/content/groups/public/org/keycloak/keycloak-account-api/1.0-beta-3/

It's just not in maven central and officially downloadable on 
sourceforge ATM.

Marek

On 18.6.2014 19:31, Bruno Oliveira wrote:
> Good morning,
>
> Are you guys planning to push Keycloak to nexus this week?
>
> On 2014-06-16, Bill Burke wrote:
>> Do we need one still this week?
>>
>> --
>> 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
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bruno at abstractj.org  Wed Jun 18 15:06:12 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Jun 2014 16:06:12 -0300
Subject: [keycloak-dev] need a release?
In-Reply-To: <53A1DC25.9000500@redhat.com>
References: <539F0C20.3000700@redhat.com>
	<20140618173153.GA58896@abstractj.org>
	<53A1DC25.9000500@redhat.com>
Message-ID: <20140618190612.GA62889@abstractj.org>

Thank you Marek!

On 2014-06-18, Marek Posolda wrote:
> It's in jboss nexus already . For example: http://repository.jboss.org/nexus/content/groups/public/org/keycloak/keycloak-account-api/1.0-beta-3/
>
> It's just not in maven central and officially downloadable on sourceforge
> ATM.
>
> Marek
>
> On 18.6.2014 19:31, Bruno Oliveira wrote:
> >Good morning,
> >
> >Are you guys planning to push Keycloak to nexus this week?
> >
> >On 2014-06-16, Bill Burke wrote:
> >>Do we need one still this week?
> >>
> >>--
> >>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
> >--
> >
> >abstractj
> >_______________________________________________
> >keycloak-dev mailing list
> >keycloak-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

--

abstractj

From bburke at redhat.com  Thu Jun 19 10:46:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Jun 2014 10:46:55 -0400
Subject: [keycloak-dev] beta 3 released
Message-ID: <53A2F7DF.7000401@redhat.com>

Mostly a bunch of bug fixes.  Follow links on keycloak.org to download, 
view release notes, etc.


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

From bburke at redhat.com  Thu Jun 19 10:51:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Jun 2014 10:51:33 -0400
Subject: [keycloak-dev] anybody on stateless token service?
Message-ID: <53A2F8F5.6010104@redhat.com>

I'm about to tackle that, unless somebody is already working on it.

Bill

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

From stian at redhat.com  Thu Jun 19 10:55:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Jun 2014 10:55:27 -0400 (EDT)
Subject: [keycloak-dev] anybody on stateless token service?
In-Reply-To: <53A2F8F5.6010104@redhat.com>
References: <53A2F8F5.6010104@redhat.com>
Message-ID: <238645566.29483717.1403189727715.JavaMail.zimbra@redhat.com>

Nopes - I'm looking at chucking millions of users into the db, and Marek is looking at AD/LDAP issues and going to start on jmeter perf tests.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 19 June, 2014 3:51:33 PM
> Subject: [keycloak-dev] anybody on stateless token service?
> 
> I'm about to tackle that, unless somebody is already working on it.
> 
> Bill
> 
> --
> 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 Jun 20 05:17:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Jun 2014 05:17:50 -0400 (EDT)
Subject: [keycloak-dev] Beta-3 release in SourceForge was broken
In-Reply-To: <412984124.29950470.1403255803715.JavaMail.zimbra@redhat.com>
Message-ID: <1711910285.29950938.1403255870098.JavaMail.zimbra@redhat.com>

All,

The files for 1.0-beta-3 I uploaded yesterday to SourceForge was broken (both appliance-dist and war-dist). I've uploaded fixed files now, so if you've already downloaded the release, please download again!

Cheers,
Stian

From bburke at redhat.com  Fri Jun 20 10:43:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Jun 2014 10:43:06 -0400
Subject: [keycloak-dev] stateless access codes committed, anything else?
Message-ID: <53A4487A.4040303@redhat.com>

Is there anything else that is stateful about the token service?

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

From stian at redhat.com  Fri Jun 20 11:08:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Jun 2014 11:08:27 -0400 (EDT)
Subject: [keycloak-dev] stateless access codes committed, anything else?
In-Reply-To: <53A4487A.4040303@redhat.com>
References: <53A4487A.4040303@redhat.com>
Message-ID: <202382550.30226574.1403276907009.JavaMail.zimbra@redhat.com>

Can't think of anything, had a quick look and couldn't spot anything either.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 20 June, 2014 3:43:06 PM
> Subject: [keycloak-dev] stateless access codes committed, anything else?
> 
> Is there anything else that is stateful about the token service?
> 
> --
> 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  Fri Jun 20 11:23:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Jun 2014 11:23:17 -0400
Subject: [keycloak-dev] top-level cache strategy
Message-ID: <53A451E5.10507@redhat.com>

Last week I put in a cache that sits on top of our model API.  I'm going 
to continue with it and *not* use any caching implementation like 
Infinispan.  Here's what it will look like:

* Provider SPI for cache implementation
* Simple hand made cluster cache for Keycloak as follows:
- Cache is currently loaded on demand
- Cached objects are read-only and are invalidated at end of transaction 
if changed.
- ConcurentHashMaps for non-user information.
- LRU cache for UserModel and Credentials.  This will be a synchronized 
LinkedHashMap.
- Cluster nodes will be defined manually in keycloak-server.json under 
the cache scope.
- Simple secure invalidation REST API
- Simple secure ping REST API
- If a remote invalidation or ping fails, then cache will be wiped and 
disabled until a ping can be re-established.

I don't think any of this is much work.

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

From stian at redhat.com  Fri Jun 20 11:37:57 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Jun 2014 11:37:57 -0400 (EDT)
Subject: [keycloak-dev] top-level cache strategy
In-Reply-To: <53A451E5.10507@redhat.com>
References: <53A451E5.10507@redhat.com>
Message-ID: <972775826.30255552.1403278677063.JavaMail.zimbra@redhat.com>

Sounds good to me

A related issue is that I think we should split the model into two:

* Model - realm, apps, clients, roles, scopes
* Users - profiles, credentials, role mappings

I think there's quite a few benefits to this:

* Model is pretty complex (31 tables now)
* Model db will in most cases be small, and could be stored in config files
* Users db will in most cases be large
* Would make it easier to shard (as we replicate the model, while we can shard users)
* Would make it easier to upgrade - model can be updated more frequently with less impact on upgrade, while we should strive to not change users db (if users have 20 million entries it'll take time to upgrade)
* Users may want to implement the Users SPI themselves (and we can provide alternatives), but they are far less likely going to want to change the model

This is an issue I think it would be good to have a hangout about though. Also, not sure if it's viable at all for 1.0.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 20 June, 2014 4:23:17 PM
> Subject: [keycloak-dev] top-level cache strategy
> 
> Last week I put in a cache that sits on top of our model API.  I'm going
> to continue with it and *not* use any caching implementation like
> Infinispan.  Here's what it will look like:
> 
> * Provider SPI for cache implementation
> * Simple hand made cluster cache for Keycloak as follows:
> - Cache is currently loaded on demand
> - Cached objects are read-only and are invalidated at end of transaction
> if changed.
> - ConcurentHashMaps for non-user information.
> - LRU cache for UserModel and Credentials.  This will be a synchronized
> LinkedHashMap.
> - Cluster nodes will be defined manually in keycloak-server.json under
> the cache scope.
> - Simple secure invalidation REST API
> - Simple secure ping REST API
> - If a remote invalidation or ping fails, then cache will be wiped and
> disabled until a ping can be re-established.
> 
> I don't think any of this is much work.
> 
> --
> 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  Fri Jun 20 11:52:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Jun 2014 11:52:19 -0400
Subject: [keycloak-dev] top-level cache strategy
In-Reply-To: <972775826.30255552.1403278677063.JavaMail.zimbra@redhat.com>
References: <53A451E5.10507@redhat.com>
	<972775826.30255552.1403278677063.JavaMail.zimbra@redhat.com>
Message-ID: <53A458B3.9090709@redhat.com>



On 6/20/2014 11:37 AM, Stian Thorgersen wrote:
> Sounds good to me
>
> A related issue is that I think we should split the model into two:
>
> * Model - realm, apps, clients, roles, scopes
> * Users - profiles, credentials, role mappings
>

You forgot User Sessions too.  Which would be the 3rd split, IMO.


>
> This is an issue I think it would be good to have a hangout about though. Also, not sure if it's viable at all for 1.0.
>

We should seriously considering getting it into 1.0.  Its good to get 
these things right before major releases.  Once 1.0 goes out, we're 
going to be supporting a lot more users.

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

From stian at redhat.com  Fri Jun 27 04:56:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 27 Jun 2014 04:56:54 -0400 (EDT)
Subject: [keycloak-dev] Refactoring to KeycloakSession and ProviderSession
In-Reply-To: <1125057000.34588602.1403859324340.JavaMail.zimbra@redhat.com>
Message-ID: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>

I've combined KeycloakSession and ProviderSession into KeycloakSession. There's a single implementation of this (DefaultKeycloakSession).

Model implementations now implement ModelProvider instead of KeycloakSession.

From mposolda at redhat.com  Mon Jun 30 04:08:48 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 30 Jun 2014 10:08:48 +0200
Subject: [keycloak-dev] JMeter Performance test
Message-ID: <53B11B10.8000904@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/490 with first 
prototype of Keycloak performance test with JMeter. For now it's using 
embedded Undertow (reused KeycloakServer stuff from testsuite) also with 
performance-tools, so it's easy to add new users. Most of the stuff is 
configurable through System properties, which allows to easily switch 
different databases and models without any needed changes in 
configuration files (For example PostgreSQL, MySQL, Mongo, 
enabled/disabled simple cache etc), which is also good for easy setup of 
performance test in Jenkins to have it in CI. Some details in README: 
testsuite/performance-web/README.md .

If you like the approach, I can continue and possibly setup CI. For now, 
I've tried some testing on my laptop with 10.000 users in database and 
each user having 1 realm role (available through scope to tested web 
application) and 0 application roles... (I guess having configurable 
number of roles, scopes per user might be useful as well and I can 
possibly add it? )

Each test is using 50 clients (each client having different username, so 
using users like user-0, user-1, user-49 ) and each client doing 50 test 
iterations. Each iteration is doing:
- Redirect to KC login screen
- Login into KC
- Exchange code for token
- Refresh token 2 times
- Logout

Some results from test on my laptop:

PostgreSQL with simple cache disabled:

uri                                       count     total     min     
average max
"Login request"                  2500    381151    10    152 1168
"Confirm Login request"    2500    1202384    39    480    1505
"Exchange code request"  2500    1162489    28    464    1677
"RefreshToken request"     5000    1992961    22    398    1630
"Logout request"               2500    786237    21    314 1383


PostgreSQL with simple cache enabled:

uri                                      count     total     min average 
max
"Login request"                  2500    168819    6    67    857
"Confirm Login request"    2500    412464    18    164    1205
"Exchange code request"  2500    670047    21    268    1121
"RefreshToken request"     5000    997389    10    199    976
"Logout request"               2500    475672    17    190 1328


Mongo model with simple cache disabled:

uri                                       count     total     min     
average max
"Login request"                  2500    171976    6    68 1014
"Confirm Login request"    2500    412258    11    164    981
"Exchange code request"  2500    512125    12    204    1144
"RefreshToken request"     5000    923467    11    184    1073
"Logout request"               2500    367173    10    146 1108


Mongo model with simple cache enabled:

uri                                      count     total     min average 
max
"Login request"                  2500    135489    5    54 1085
"Confirm Login request"    2500    224540    7    89    1318
"Exchange code request"  2500    343649    9    137    905
"RefreshToken request"     5000    556202    8    111    750
"Logout request"               2500    292986    10    117 1574

Marek

From mposolda at redhat.com  Mon Jun 30 05:12:26 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 30 Jun 2014 11:12:26 +0200
Subject: [keycloak-dev] stateless access codes committed, anything else?
In-Reply-To: <53A4487A.4040303@redhat.com>
References: <53A4487A.4040303@redhat.com>
Message-ID: <53B129FA.7090107@redhat.com>

There is one small issue though, that now is possible to exchange same 
code for token multiple times. I am not sure if we already discuss this 
and decide that it's "price to pay" to have stateless TokenService. 
However OAuth2 specs is not so happy with this (See 4.1.2 and 10.5) . 
Did we consider saving codes (or exchanged codes) into DB and have some 
periodic task to cleanup them?

Marek

On 20.6.2014 16:43, Bill Burke wrote:
> Is there anything else that is stateful about the token service?
>


From stian at redhat.com  Mon Jun 30 06:39:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jun 2014 06:39:04 -0400 (EDT)
Subject: [keycloak-dev] Hangout this week to talk about cache and model
	splitting
In-Reply-To: <2065919984.381795.1404123633547.JavaMail.zimbra@redhat.com>
Message-ID: <216348010.404955.1404124744878.JavaMail.zimbra@redhat.com>

I'd like to have a hangout this week to talk about cache, clustering and splitting of the model. I'd like to do this a.s.a.p. so we can decide on what we're going to do for 1.0.final.

Last week I experimented with splitting the model into 3 parts: config, users and sessions. I've got something close to working at the moment. The basic idea is to create a new hybrid model provider that delegates to 3 different providers:

* Config SPI - realms, apps, clients, roles and scope mappings
  * Could quite easily do a json file implementation. However, what about clustering? Could we just reload the whole realm whenever it's changed?
  * Not considering clustering, is there even any reason to store config in a database? Dropping support for DBs and Mongo for config would make things significantly simpler.
  * Can we load everything into mem on startup? How would that affect clustering?
  * Should we add a revision to realms to make it easy to track consistency across servers in a cluster?
  * In the long run we could move code from managers into KeycloakSession and HybridModelProvider (and also extract more shared code from the stores themselves)
  * Does it make sense to have a read and read/write mode for config. For example admin uses read/write config, while logins and such use the read only config
  * We could add a batch mode to the admin console. An admin can perform a number of changes that are kept in a draft version of the config on the server. Once the admin has done all the changes, he can then choose to review the changes through a page in the admin console and click push if he's happy with it. This could be taken further and have some users that are allowed to perform changes, but not push the changes.

* Users SPI
  * Stores users, credentials and role mappings
  * I expect this is the only one users of Keycloak could want to implement themselves
  * What implementations do we provide? DBs, Mongo, LDAP?, Files?. Does it make sense to use PicketLink here (could provide jdbs, files, ldap, etc..)

* Sessions SPI
  * Stores sessions (and probably login failures as well)
  * In-mem implementation makes sense here. However, what about clustering?
  * Do we still want JPA and Mongo implementations?


From bburke at redhat.com  Mon Jun 30 08:32:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 30 Jun 2014 08:32:23 -0400
Subject: [keycloak-dev] stateless access codes committed, anything else?
In-Reply-To: <53B129FA.7090107@redhat.com>
References: <53A4487A.4040303@redhat.com> <53B129FA.7090107@redhat.com>
Message-ID: <53B158D7.1010500@redhat.com>

It is the "price to pay".  We can shrink the timeout of the access code. 
  Right now it is 60 seconds.  Also, Since we're already creating a 
session, might as well have a "state" associated with the session.

On 6/30/2014 5:12 AM, Marek Posolda wrote:
> There is one small issue though, that now is possible to exchange same
> code for token multiple times. I am not sure if we already discuss this
> and decide that it's "price to pay" to have stateless TokenService.
> However OAuth2 specs is not so happy with this (See 4.1.2 and 10.5) .
> Did we consider saving codes (or exchanged codes) into DB and have some
> periodic task to cleanup them?
>
> Marek
>
> On 20.6.2014 16:43, Bill Burke wrote:
>> Is there anything else that is stateful about the token service?
>>
>

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

From bburke at redhat.com  Mon Jun 30 12:25:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 30 Jun 2014 12:25:31 -0400
Subject: [keycloak-dev] Refactoring to KeycloakSession and
	ProviderSession
In-Reply-To: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>
References: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>
Message-ID: <53B18F7B.5000802@redhat.com>

Ugh...Why?  Would have been cool to discuss this before you did this. 
There was a clear separation of things prior to this change:

* ProviderSession was for resolving various session based APIs I thought.
* KeycloakSession was analogous to EntityManager or HibernateSession.

Also, you don't go committing stuff that breaks existing code...i.e. the 
caching stuff I did.


On 6/27/2014 4:56 AM, Stian Thorgersen wrote:
> I've combined KeycloakSession and ProviderSession into KeycloakSession. There's a single implementation of this (DefaultKeycloakSession).
>
> Model implementations now implement ModelProvider instead of KeycloakSession.
> _______________________________________________
> 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 Jun 30 12:37:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 30 Jun 2014 12:37:18 -0400 (EDT)
Subject: [keycloak-dev] Refactoring to KeycloakSession
	and	ProviderSession
In-Reply-To: <53B18F7B.5000802@redhat.com>
References: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>
	<53B18F7B.5000802@redhat.com>
Message-ID: <1854957866.697698.1404146238150.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 30 June, 2014 5:25:31 PM
> Subject: Re: [keycloak-dev] Refactoring to KeycloakSession and	ProviderSession
> 
> Ugh...Why?  Would have been cool to discuss this before you did this.
> There was a clear separation of things prior to this change:
> 
> * ProviderSession was for resolving various session based APIs I thought.
> * KeycloakSession was analogous to EntityManager or HibernateSession.

I didn't really think it was a big deal, as the separation is still there. What used to be KeycloakSession is now ModelProvider, and the new KeycloakSession is just a wrapper to be able to get to both from the same @Context injection.

> 
> Also, you don't go committing stuff that breaks existing code...i.e. the
> caching stuff I did.

I commented out the cache stuff as it wasn't working, see https://issues.jboss.org/browse/KEYCLOAK-527. I tried to fix it, but couldn't quite figure out how to go about doing it, so thought it was best to disable it until you got back and could have a look. I was going to send you an email about it, but of course I forgot that :(

> 
> 
> On 6/27/2014 4:56 AM, Stian Thorgersen wrote:
> > I've combined KeycloakSession and ProviderSession into KeycloakSession.
> > There's a single implementation of this (DefaultKeycloakSession).
> >
> > Model implementations now implement ModelProvider instead of
> > KeycloakSession.
> > _______________________________________________
> > 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 Jun 30 12:45:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 30 Jun 2014 12:45:20 -0400
Subject: [keycloak-dev] Hangout this week to talk about cache and model
 splitting
In-Reply-To: <216348010.404955.1404124744878.JavaMail.zimbra@redhat.com>
References: <216348010.404955.1404124744878.JavaMail.zimbra@redhat.com>
Message-ID: <53B19420.8060909@redhat.com>



On 6/30/2014 6:39 AM, Stian Thorgersen wrote:
> I'd like to have a hangout this week to talk about cache, clustering and splitting of the model. I'd like to do this a.s.a.p. so we can decide on what we're going to do for 1.0.final.
>
> Last week I experimented with splitting the model into 3 parts: config, users and sessions. I've got something close to working at the moment. The basic idea is to create a new hybrid model provider that delegates to 3 different providers:
>

realm, roles, scopes, apps, clients, etc. are *NOT* config.  Please stop 
calling it config. :)

> * Config SPI - realms, apps, clients, roles and scope mappings
>    * Could quite easily do a json file implementation. However, what about clustering? Could we just reload the whole realm whenever it's changed?

This ties into caching as well.

>    * Not considering clustering, is there even any reason to store config in a database? Dropping support for DBs and Mongo for config would make things significantly simpler.

I don't agree having a flat file would make things simpler.
* You'd have to write a flat-file database that could handle session 
rollbacks.
* You'd have to require NFS or some other distributed file system for 
clustering.
* You've just added another storage mechanism the admin has to worry about.

>    * Can we load everything into mem on startup? How would that affect clustering?

That was already the plan with the caching layer I wrote.  As it was, 
the first access to a realm caches all non-user realm metadata.

>    * Should we add a revision to realms to make it easy to track consistency across servers in a cluster?
>    * In the long run we could move code from managers into KeycloakSession and HybridModelProvider (and also extract more shared code from the stores themselves)

95% of the model code is boilerplate.  THere is very little code that is 
duplicate.

>    * Does it make sense to have a read and read/write mode for config. For example admin uses read/write config, while logins and such use the read only config
>    * We could add a batch mode to the admin console. An admin can perform a number of changes that are kept in a draft version of the config on the server. Once the admin has done all the changes, he can then choose to review the changes through a page in the admin console and click push if he's happy with it. This could be taken further and have some users that are allowed to perform changes, but not push the changes.
>

IMO, those are very low priority compared to the other things we have to 
accomplish over the next year.

> * Users SPI
>    * Stores users, credentials and role mappings
>    * I expect this is the only one users of Keycloak could want to implement themselves
>    * What implementations do we provide? DBs, Mongo, LDAP?, Files?. Does it make sense to use PicketLink here (could provide jdbs, files, ldap, etc..)
>

With this separation, do we still need the AuthProvider SPI?

> * Sessions SPI
>    * Stores sessions (and probably login failures as well)
>    * In-mem implementation makes sense here. However, what about clustering?
>    * Do we still want JPA and Mongo implementations?
>

Without a JPA/Mongo implementation for User Sessions, you have to 
introduce another moving part in a cluster environment:  Infinispan, etc.

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

From bburke at redhat.com  Mon Jun 30 12:58:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 30 Jun 2014 12:58:58 -0400
Subject: [keycloak-dev] Refactoring to KeycloakSession and
	ProviderSession
In-Reply-To: <1854957866.697698.1404146238150.JavaMail.zimbra@redhat.com>
References: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>
	<53B18F7B.5000802@redhat.com>
	<1854957866.697698.1404146238150.JavaMail.zimbra@redhat.com>
Message-ID: <53B19752.5020609@redhat.com>



On 6/30/2014 12:37 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 30 June, 2014 5:25:31 PM
>> Subject: Re: [keycloak-dev] Refactoring to KeycloakSession and	ProviderSession
>>
>> Ugh...Why?  Would have been cool to discuss this before you did this.
>> There was a clear separation of things prior to this change:
>>
>> * ProviderSession was for resolving various session based APIs I thought.
>> * KeycloakSession was analogous to EntityManager or HibernateSession.
>
> I didn't really think it was a big deal, as the separation is still there. What used to be KeycloakSession is now ModelProvider, and the new KeycloakSession is just a wrapper to be able to get to both from the same @Context injection.
>

KeycloakSession now mixes up the provider API and the data model.  What 
exactly is the benefit of that?  I thought we were moving to 
*separating* things out not combining them..  Realm meta-model, User 
metamodel, and User Session meta model.

What I'd like to see is ProviderSession becoming a mini-transaction 
manager where our Filter calls commit/rollback on the ProviderSession 
which in turn, calls commit/rollback on all our model APIs.

>>
>> Also, you don't go committing stuff that breaks existing code...i.e. the
>> caching stuff I did.
>
> I commented out the cache stuff as it wasn't working, see https://issues.jboss.org/browse/KEYCLOAK-527. I tried to fix it, but couldn't quite figure out how to go about doing it, so thought it was best to disable it until you got back and could have a look. I was going to send you an email about it, but of course I forgot that :(
>

I guess we don't have any tests for adding/removing scope mappings :(

FYI, it is just a matter of using EntityManager.getReference().  Commit 
incoming.


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