From mposolda at redhat.com  Tue Jul  1 03:21:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 01 Jul 2014 09:21:05 +0200
Subject: [keycloak-dev] stateless access codes committed, anything else?
In-Reply-To: <53B158D7.1010500@redhat.com>
References: <53A4487A.4040303@redhat.com> <53B129FA.7090107@redhat.com>
	<53B158D7.1010500@redhat.com>
Message-ID: <53B26161.50809@redhat.com>

On 30.6.2014 14:32, Bill Burke wrote:
> 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.
I think it could work this way. After login will be association of 
"code" with UserSession created. And once later user wants to exchange 
code, it can be verified if code is associated with UserSession and send 
token just in case that it is. Then "code" association will be removed 
from UserSession, so it's not possible to exchange same code another time.

It seems to me that it's safer and overhead is not so big, as we already 
creating UserSession after login, so only additional thing will be just 
this "code" association. My vote is to go for it:)

Marek

>
> 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?
>>>
>>
>


From mposolda at redhat.com  Tue Jul  1 03:48:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 01 Jul 2014 09:48:05 +0200
Subject: [keycloak-dev] Refactoring to KeycloakSession and
	ProviderSession
In-Reply-To: <53B19752.5020609@redhat.com>
References: <1924825648.34589245.1403859414616.JavaMail.zimbra@redhat.com>	<53B18F7B.5000802@redhat.com>	<1854957866.697698.1404146238150.JavaMail.zimbra@redhat.com>
	<53B19752.5020609@redhat.com>
Message-ID: <53B267B5.8090705@redhat.com>

On 30.6.2014 18:58, Bill Burke wrote:
>
> 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.
I wonder if we can abstract the fact that there are 3 different 
meta-models from the code, which consumes it? In other words, still have 
same API to invoke the "model" like it currently is (current 
KeycloakSession) but have KeycloakSession implementation to just 
delegate the invocations to proper meta-models (Realm, User, 
UserSession)? This would mean that RealmModelProvider, UserModelProvider 
and UserSessionModelProvider will be invoked just from 
DefaultKeycloakSession.

This would mean that consuming code will be simpler and doesn't need to 
retrieve 3 different providers from KeycloakSession (or 
ProviderSession), but just one.

>
> 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.
+1, I think that it will be in line with the design of KeycloakSession 
of the only externally "consumed" part. So KeycloakSession 
begin/commit/rollback will be called by Filter, and it will delegate 
calls to begin/commit/rollback to all 3 meta-models.

Separation of "ProviderSession" and "KeycloakSession" makes sense to me, 
but IMO stuff like transaction management belongs more to 
KeycloakSession than to ProviderSession.

My vote is for restore previous "ProviderSession" for accessing various 
components and rename "KeycloakSession" to something like "ModelSession" 
or "PersistentSession" . KeycloakSession doesn't mean much and it's not 
so clear that it's component for dealing with model/persistent stuff.

Marek
>
>>> 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.
>
>


From mposolda at redhat.com  Tue Jul  1 04:16:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 01 Jul 2014 10:16:05 +0200
Subject: [keycloak-dev] Hangout this week to talk about cache and model
 splitting
In-Reply-To: <53B19420.8060909@redhat.com>
References: <216348010.404955.1404124744878.JavaMail.zimbra@redhat.com>
	<53B19420.8060909@redhat.com>
Message-ID: <53B26E45.9080104@redhat.com>

On 30.6.2014 18:45, Bill Burke wrote:
>
> 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.
I wonder if we can reconsider again to use Infinispan:-)

It has support for both clustering and transactions. Should address the 
issues you mentioned here. They have the SPIs to sync with persistence 
layers 
http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_persistence 
and eventually we can provide our own SPI implementations.

The secure communication among cluster nodes is possible to achieve at 
JGroups level by add support for ENCRYPT (encrypt cluster communication) 
and AUTH (authenticate cluster nodes before join cluster). Some details 
here http://www.jgroups.org/manual/html/protlist.html#Security . I 
looked at ENCRYPT and unfortunately it seems that it's not possible to 
secure the communication just with Keycloak itself, as it needs 
symmetric SecretKey for encode/decode communication between cluster 
nodes, when Keycloak provides private/public. SecretKey can be either 
read from JCEKS keystore file or automatically generated by first 
cluster node and then shared with other nodes with usage of asymmetric 
private/public. It seems that with some tweaks we can use Keycloak keys 
here.

I can investigate it more, if you see Infinispan as an option.
>
>>     * 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?
I would say yes as implementing AuthProvider is still much easier then 
implementing whole users storage. And we already have some community 
members who implemented their own AuthenticationProviders.

And for example LDAP is good just for authentication, but much more 
tricky for save all other things related to UserModel (for example 
attributes, requiredActions etc) due to static nature of LDAP schema.

Marek
>
>> * 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.
>


From stian at redhat.com  Tue Jul  1 04:47:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 1 Jul 2014 04:47:21 -0400 (EDT)
Subject: [keycloak-dev] Hangout this week to talk about cache and model
 splitting
In-Reply-To: <53B19420.8060909@redhat.com>
References: <216348010.404955.1404124744878.JavaMail.zimbra@redhat.com>
	<53B19420.8060909@redhat.com>
Message-ID: <1353691824.1088558.1404204441435.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:45:20 PM
> Subject: Re: [keycloak-dev] Hangout this week to talk about cache and model splitting
> 
> 
> 
> 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. :)

Realms SPI?

> 
> > * 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.

I was thinking something a lot simpler. A single keycloak-realms.json file, and whenever anything is changed the whole file is written again. Thinking about it some more it only makes sense in smaller deployments, where there's only one or two realms, a few apps and a few roles. So we'd still want DBs.

We could add this quite easily as we already need to have the capability of importing/exporting the whole db to a json file. It could just have a limitation that it doesn't do clustering, so would only be aimed for test/dev and small deployments.

> 
> >    * 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.

Basically what I was wondering here was if we could eagerly fetch everything for a realm and just load everything in mem in one go. Also, does it make sense to load it at startup rather than on first visit? 

> 
> >    * 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.

There's still 5% ;)

> 
> >    * 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.

Totally agree, those where just some ideas that popped into my head.

> 
> > * 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?

AuthProvider is trying to achieve something different than storing users, and the combination of the two is quite flexible. Someone could still achieve what they can achieve with AuthProvider by creating a UserProvider impl that delegates to another UserProvider impl for storage, so maybe we could respin the AuthProvider SPI into a UserProvider that can use another UserProvider for storing users, and one or more UserProviders for authentication. That way we'd still have the capability, but with it less hard-coded into the core code.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | AuthUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Authenticate  +--------------------+


Same again with Sync SPI, that could be done as a delegating UserProvider store.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | SyncUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Sync          +--------------------+

> 
> > * 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.

Yep, for 1.0.final we should do JPA/Mongo. Then in the future consider Infinispan or somethin'.

I've added a very simple in-mem session store though that can be used in non-clustered mode and test/dev.

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jul  1 04:51:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 1 Jul 2014 04:51:11 -0400 (EDT)
Subject: [keycloak-dev] JMeter Performance test
In-Reply-To: <53B11B10.8000904@redhat.com>
References: <53B11B10.8000904@redhat.com>
Message-ID: <191540611.1090261.1404204671413.JavaMail.zimbra@redhat.com>

Merged

One quick question can you easily point the performance tests to an external server? So that we can test with the WildFly dist rather than embedded Undertow.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 30 June, 2014 9:08:48 AM
> Subject: [keycloak-dev] JMeter Performance test
> 
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Jul  1 05:42:01 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 01 Jul 2014 11:42:01 +0200
Subject: [keycloak-dev] JMeter Performance test
In-Reply-To: <191540611.1090261.1404204671413.JavaMail.zimbra@redhat.com>
References: <53B11B10.8000904@redhat.com>
	<191540611.1090261.1404204671413.JavaMail.zimbra@redhat.com>
Message-ID: <53B28269.3040000@redhat.com>

On 1.7.2014 10:51, Stian Thorgersen wrote:
> Merged
>
> One quick question can you easily point the performance tests to an external server? So that we can test with the WildFly dist rather than embedded Undertow.
Yes, you can point it to any server you want. There are just 2 things 
though:

1) Performance test is using different users right now (IMO much more 
close to "real" environment than using same username in all sessions), 
so it needs users to be created before running jmeter test. So 
KeycloakPerfServer (embedded undertow) now uses perf-tools and users are 
created with it. So the Wildfly/AS7 would also need perf-tools deployed 
and users created with that.

2) It uses simple web application for performance testing. So the 
application needs to be deployed as well.

I was also thinking about using Keycloak TokenService endpoints 
directly,however in the web application there is some pre/post 
processing and parsing of tokens etc, which is much easier to do in Java 
then in JMeter itself. which allows to check for example that correct 
user is logged and so it's easier to verify that performance test is 
doing what is is supposed to do and using different user in each session 
etc.

Do you think it makes sense to have also test for TokenService endpoints 
directly? Was also wondering about adding tests for AccountService as 
this might be used by any user, so this stuff can be used quite often? 
Not sure about admin console as this won't be hardly used by many users 
at the same time (load won't be so big to admin console endpoints).

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, 30 June, 2014 9:08:48 AM
>> Subject: [keycloak-dev] JMeter Performance test
>>
>> 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
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bruno at abstractj.org  Thu Jul  3 14:46:44 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 3 Jul 2014 15:46:44 -0300
Subject: [keycloak-dev] Account management integration
Message-ID: <20140703184644.GA61831@abstractj.org>

Good morning guys,

Do you know if is possible to customize the label of
referrer URLs on account management interface. I would like to change
this value
http://photon.abstractj.org/Keycloak_Account_Management_2014-07-03_15-41-05_2014-07-03_15-41-15.jpg
to something like "Back to UnifiedPush server". The change is based on
discussions started here
https://github.com/aerogear/aerogear-unifiedpush-server/pull/267.

I tried several approaches:

- Change the application name to something like "UnifiedPush server"
- Include "UnifiedPush+server" on referrer and also
  "UnifiedPush%20server"
- Make use of referrerURI with the admin URL, instead of referrer

Looking at account.ftl it seems like whitespaces are not accepted.

Thanks in advance.

--

abstractj

From bburke at redhat.com  Thu Jul  3 15:12:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 03 Jul 2014 15:12:53 -0400
Subject: [keycloak-dev] How the cache works
Message-ID: <53B5AB35.5060202@redhat.com>

Wanted to write up how the cache works.  Its not very efficient on how 
it decides to do invalidations, but this was the easiest approach.

* There are RealmAdapter, UserAdapter, etc. in the cache module just 
like any other adapter
* These adapter objects are created once per session and reused with 
each lookup
* Any non-read method invoked will cause a persistence adapter to be 
found for that model.  The cache adapter object will then, from then on, 
delegate to that persistence adapter.
* Invalidations happen at the end of a transaction
* Any create, update, or delete method invoked will cause a invalidation 
event to be registered.
* If you call RealmModel.removeOAuthClient(), RealmModel.addRole(), 
etc...this also causes the realm to be registered for invalidation. 
Same thing with applications etc.  This is true for everything but user 
sessions and users.
* Anything registered for invalidation will cause the cache provider to 
return a persistent model for any top level lookups.
* persistent adapter methods should never try and typecast a Model 
reference to an adapter class.  This is problematic for JPA as you need 
to set up entity relationships.  To get around this, 
EntityManager.getReference() is used.  Doesn't seem to be as much a 
problem in the mongo one.

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

From mposolda at redhat.com  Fri Jul  4 03:10:05 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 04 Jul 2014 09:10:05 +0200
Subject: [keycloak-dev] Account management integration
In-Reply-To: <20140703184644.GA61831@abstractj.org>
References: <20140703184644.GA61831@abstractj.org>
Message-ID: <53B6534D.5050705@redhat.com>

Hi Bruno,

i've tried to test a bit and for me it works even with space in URI. For 
example I've added application "New Name" and this URL: 
http://localhost:8081/auth/realms/perf-realm/account?referrer=New%20Name
works in both FF and Chrome.

Make sure that your application has correctly set "Base URL", otherwise 
referrer won't be used and displayed in account management.

Marek

On 3.7.2014 20:46, Bruno Oliveira wrote:
> Good morning guys,
>
> Do you know if is possible to customize the label of
> referrer URLs on account management interface. I would like to change
> this value
> http://photon.abstractj.org/Keycloak_Account_Management_2014-07-03_15-41-05_2014-07-03_15-41-15.jpg
> to something like "Back to UnifiedPush server". The change is based on
> discussions started here
> https://github.com/aerogear/aerogear-unifiedpush-server/pull/267.
>
> I tried several approaches:
>
> - Change the application name to something like "UnifiedPush server"
> - Include "UnifiedPush+server" on referrer and also
>    "UnifiedPush%20server"
> - Make use of referrerURI with the admin URL, instead of referrer
>
> Looking at account.ftl it seems like whitespaces are not accepted.
>
> Thanks in advance.
>
> --
>
> abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Jul  4 04:10:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 04:10:06 -0400 (EDT)
Subject: [keycloak-dev] Account management integration
In-Reply-To: <53B6534D.5050705@redhat.com>
References: <20140703184644.GA61831@abstractj.org>
	<53B6534D.5050705@redhat.com>
Message-ID: <36976758.3776997.1404461406889.JavaMail.zimbra@redhat.com>

I think we should add a title to realms and apps for this purpose. Having capitals and spaces in names that are used in URLs is not good IMO.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bruno Oliveira" <bruno at abstractj.org>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 4 July, 2014 8:10:05 AM
> Subject: Re: [keycloak-dev] Account management integration
> 
> Hi Bruno,
> 
> i've tried to test a bit and for me it works even with space in URI. For
> example I've added application "New Name" and this URL:
> http://localhost:8081/auth/realms/perf-realm/account?referrer=New%20Name
> works in both FF and Chrome.
> 
> Make sure that your application has correctly set "Base URL", otherwise
> referrer won't be used and displayed in account management.
> 
> Marek
> 
> On 3.7.2014 20:46, Bruno Oliveira wrote:
> > Good morning guys,
> >
> > Do you know if is possible to customize the label of
> > referrer URLs on account management interface. I would like to change
> > this value
> > http://photon.abstractj.org/Keycloak_Account_Management_2014-07-03_15-41-05_2014-07-03_15-41-15.jpg
> > to something like "Back to UnifiedPush server". The change is based on
> > discussions started here
> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/267.
> >
> > I tried several approaches:
> >
> > - Change the application name to something like "UnifiedPush server"
> > - Include "UnifiedPush+server" on referrer and also
> >    "UnifiedPush%20server"
> > - Make use of referrerURI with the admin URL, instead of referrer
> >
> > Looking at account.ftl it seems like whitespaces are not accepted.
> >
> > 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
> 

From stian at redhat.com  Fri Jul  4 04:12:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 04:12:20 -0400 (EDT)
Subject: [keycloak-dev] Add title for Realm, Applications, Clients and Roles
In-Reply-To: <664061015.3777599.1404461470220.JavaMail.zimbra@redhat.com>
Message-ID: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>

I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.

This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).

Any objections?

From mposolda at redhat.com  Fri Jul  4 04:32:49 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 04 Jul 2014 10:32:49 +0200
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
References: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
Message-ID: <53B666B1.7050400@redhat.com>

On 4.7.2014 10:12, Stian Thorgersen wrote:
> I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.
>
> This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).
+1

For roles we already have "description" though, which is used in oauth 
grant screen, so I wonder if it can be "description" instead of "title" ?

Would be nice if it's not mandatory though, so for example in UI it will 
display "title/description" just in case that it's filled, otherwise 
fallback to name?

Marek

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


From stian at redhat.com  Fri Jul  4 04:38:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 04:38:59 -0400 (EDT)
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <53B666B1.7050400@redhat.com>
References: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
	<53B666B1.7050400@redhat.com>
Message-ID: <828867504.3816365.1404463139805.JavaMail.zimbra@redhat.com>

I forgot about roles already having this. So, let's just add description to realms, apps and clients.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 4 July, 2014 9:32:49 AM
> Subject: Re: [keycloak-dev] Add title for Realm, Applications, Clients and Roles
> 
> On 4.7.2014 10:12, Stian Thorgersen wrote:
> > I propose we add a title for Realm, Applications, Clients and Roles. In
> > admin console, login forms and account management we should then use the
> > title if specified, otherwise use the name.
> >
> > This allows having a URL friendly name (for example "realm-one") while
> > having a human friendly title for interfaces (Realm One).
> +1
> 
> For roles we already have "description" though, which is used in oauth
> grant screen, so I wonder if it can be "description" instead of "title" ?
> 
> Would be nice if it's not mandatory though, so for example in UI it will
> display "title/description" just in case that it's filled, otherwise
> fallback to name?
> 
> Marek
> 
> >
> > Any objections?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Fri Jul  4 04:52:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 04:52:20 -0400 (EDT)
Subject: [keycloak-dev] Removing UserModel#NotBefore
Message-ID: <1830342524.3825142.1404463940282.JavaMail.zimbra@redhat.com>

I've removed NotBefore from the Users. User sessions takes care of this, so it's not needed.

From bruno at abstractj.org  Fri Jul  4 07:55:53 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 4 Jul 2014 08:55:53 -0300
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
References: <664061015.3777599.1404461470220.JavaMail.zimbra@redhat.com>
	<1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
Message-ID: <20140704115553.GA69955@abstractj.org>

+1 I would call "alias"

On 2014-07-04, Stian Thorgersen wrote:
> I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.
>
> This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).
>
> Any objections?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From bruno at abstractj.org  Fri Jul  4 07:56:59 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 4 Jul 2014 08:56:59 -0300
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <53B666B1.7050400@redhat.com>
References: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
	<53B666B1.7050400@redhat.com>
Message-ID: <20140704115659.GB69955@abstractj.org>

On 2014-07-04, Marek Posolda wrote:
> On 4.7.2014 10:12, Stian Thorgersen wrote:
> > I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.
> >
> > This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).
> +1
>
> For roles we already have "description" though, which is used in oauth
> grant screen, so I wonder if it can be "description" instead of "title" ?

If we already have this concept +1 for description

>
> Would be nice if it's not mandatory though, so for example in UI it will
> display "title/description" just in case that it's filled, otherwise
> fallback to name?
>
> Marek
>
> >
> > Any objections?
> > _______________________________________________
> > 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 bruno at abstractj.org  Fri Jul  4 08:02:50 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Fri, 4 Jul 2014 09:02:50 -0300
Subject: [keycloak-dev] Account management integration
In-Reply-To: <53B6534D.5050705@redhat.com>
References: <20140703184644.GA61831@abstractj.org>
	<53B6534D.5050705@redhat.com>
Message-ID: <20140704120250.GC69955@abstractj.org>

Thanks Marek, I leave it as is now and make use of the "description"
field in the future like Stian suggested[1]

[1] - http://lists.jboss.org/pipermail/keycloak-dev/2014-July/001990.html

On 2014-07-04, Marek Posolda wrote:
> Hi Bruno,
>
> i've tried to test a bit and for me it works even with space in URI. For
> example I've added application "New Name" and this URL:
> http://localhost:8081/auth/realms/perf-realm/account?referrer=New%20Name
> works in both FF and Chrome.
>
> Make sure that your application has correctly set "Base URL", otherwise
> referrer won't be used and displayed in account management.
>
> Marek
>
> On 3.7.2014 20:46, Bruno Oliveira wrote:
> >Good morning guys,
> >
> >Do you know if is possible to customize the label of
> >referrer URLs on account management interface. I would like to change
> >this value
> >http://photon.abstractj.org/Keycloak_Account_Management_2014-07-03_15-41-05_2014-07-03_15-41-15.jpg
> >to something like "Back to UnifiedPush server". The change is based on
> >discussions started here
> >https://github.com/aerogear/aerogear-unifiedpush-server/pull/267.
> >
> >I tried several approaches:
> >
> >- Change the application name to something like "UnifiedPush server"
> >- Include "UnifiedPush+server" on referrer and also
> >   "UnifiedPush%20server"
> >- Make use of referrerURI with the admin URL, instead of referrer
> >
> >Looking at account.ftl it seems like whitespaces are not accepted.
> >
> >Thanks in advance.
> >
> >--
> >
> >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  Fri Jul  4 08:34:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 04 Jul 2014 08:34:50 -0400
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
References: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
Message-ID: <53B69F6A.9010804@redhat.com>

Small addition, but its an additional complexity.  What is wrong with 
spaces, caps, etc. in URLs?  They work fine.

On 7/4/2014 4:12 AM, Stian Thorgersen wrote:
> I propose we add a title for Realm, Applications, Clients and Roles. In admin console, login forms and account management we should then use the title if specified, otherwise use the name.
>
> This allows having a URL friendly name (for example "realm-one") while having a human friendly title for interfaces (Realm One).
>
> Any objections?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Jul  4 08:39:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 08:39:21 -0400 (EDT)
Subject: [keycloak-dev] Add title for Realm, Applications,
 Clients and Roles
In-Reply-To: <53B69F6A.9010804@redhat.com>
References: <1566758637.3778131.1404461540802.JavaMail.zimbra@redhat.com>
	<53B69F6A.9010804@redhat.com>
Message-ID: <1737641106.3990515.1404477561263.JavaMail.zimbra@redhat.com>

Sure, they work, but are not very pretty. I also think that folks will often want them to be different.

Another good reason for adding this is that once we add internationalization support we'd have to make the descriptions support that as well. We can't add internationalization support to names, as that simply wouldn't work.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 4 July, 2014 1:34:50 PM
> Subject: Re: [keycloak-dev] Add title for Realm, Applications, Clients and Roles
> 
> Small addition, but its an additional complexity.  What is wrong with
> spaces, caps, etc. in URLs?  They work fine.
> 
> On 7/4/2014 4:12 AM, Stian Thorgersen wrote:
> > I propose we add a title for Realm, Applications, Clients and Roles. In
> > admin console, login forms and account management we should then use the
> > title if specified, otherwise use the name.
> >
> > This allows having a URL friendly name (for example "realm-one") while
> > having a human friendly title for interfaces (Realm One).
> >
> > Any objections?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Jul  4 09:17:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 4 Jul 2014 09:17:21 -0400 (EDT)
Subject: [keycloak-dev] Status on model splitting
In-Reply-To: <37256657.4017589.1404479645793.JavaMail.zimbra@redhat.com>
Message-ID: <18630940.4018344.1404479841568.JavaMail.zimbra@redhat.com>

I've implemented JPA realms, users and sessions, as well as mem sessions. It also works fine with the cache.

I still have a bit of work to do before I can commit it though. I'd like to do some clean-up as well as implement Mongo providers.

In the mean time if anyone needs to do any minor changes to the model just go ahead, and I'll merge it once I'm ready (hopefully early next week).

From mposolda at redhat.com  Mon Jul  7 10:22:58 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 07 Jul 2014 16:22:58 +0200
Subject: [keycloak-dev] Changes in reps
Message-ID: <53BAAD42.3080807@redhat.com>

Hi,

When working on export/import, I did some changes to reps. Specifically:

- Remove "roleMappings", "applicationRoleMappings" and "socialMappings" 
from RealmRepresentation and instead adding it directly under 
UserRepresentation. So for user, we will have something like:

         {
             "username": "admin",
             ...
             "realmRoles": [ "admin" ],
             "applicationRoles": [
                 "Application": [ "app-admin" ],
                 "OtherApp": [  "otherapp-admin" ]
             ]
         }

The main reason is that for big number of users, we may need to paginate 
them (For example add first 10k users of realm into one file and then 
another 10k users into another file etc), so it will be nice to have all 
info related to user in one place.

- Added optional fields "hashedValue" and "salt" to 
CredentialRepresentation. The thing is that if we want to do export, we 
can't use plain-text "value", but we need to export it into 
"hashedValue" . I am still keeping the "value", so it will be still 
possible to import users with plain-text password as it is now. The main 
usecase for "hashedValue"+"salt" is really just export/import (Import 
passwords, which were previously exported)

Let me know if you see some issues with it.

Thanks,
Marek



From bburke at redhat.com  Mon Jul  7 10:47:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 07 Jul 2014 10:47:41 -0400
Subject: [keycloak-dev] Changes in reps
In-Reply-To: <53BAAD42.3080807@redhat.com>
References: <53BAAD42.3080807@redhat.com>
Message-ID: <53BAB30D.60106@redhat.com>

I don't remember why I did it that way to begin with.  Maybe it was a 
dumb reason. :)

Sounds like a good plan.  Make sure though you update all the .json 
files that use the old format.

On 7/7/2014 10:22 AM, Marek Posolda wrote:
> Hi,
>
> When working on export/import, I did some changes to reps. Specifically:
>
> - Remove "roleMappings", "applicationRoleMappings" and "socialMappings"
> from RealmRepresentation and instead adding it directly under
> UserRepresentation. So for user, we will have something like:
>
>           {
>               "username": "admin",
>               ...
>               "realmRoles": [ "admin" ],
>               "applicationRoles": [
>                   "Application": [ "app-admin" ],
>                   "OtherApp": [  "otherapp-admin" ]
>               ]
>           }
>
> The main reason is that for big number of users, we may need to paginate
> them (For example add first 10k users of realm into one file and then
> another 10k users into another file etc), so it will be nice to have all
> info related to user in one place.
>
> - Added optional fields "hashedValue" and "salt" to
> CredentialRepresentation. The thing is that if we want to do export, we
> can't use plain-text "value", but we need to export it into
> "hashedValue" . I am still keeping the "value", so it will be still
> possible to import users with plain-text password as it is now. The main
> usecase for "hashedValue"+"salt" is really just export/import (Import
> passwords, which were previously exported)
>
> Let me know if you see some issues with it.
>
> Thanks,
> Marek
>
>
> _______________________________________________
> 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 Jul  7 10:59:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 7 Jul 2014 10:59:22 -0400 (EDT)
Subject: [keycloak-dev] Renamed loginName to username
Message-ID: <1376982562.5044111.1404745162860.JavaMail.zimbra@redhat.com>

We had both username and loginName at various places in the code. To make it consistent I've renamed loginName to username.

From mposolda at redhat.com  Mon Jul  7 11:45:34 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 07 Jul 2014 17:45:34 +0200
Subject: [keycloak-dev] Changes in reps
In-Reply-To: <53BAB30D.60106@redhat.com>
References: <53BAAD42.3080807@redhat.com> <53BAB30D.60106@redhat.com>
Message-ID: <53BAC09E.4080603@redhat.com>

On 7.7.2014 16:47, Bill Burke wrote:
> I don't remember why I did it that way to begin with.  Maybe it was a
> dumb reason. :)
Maybe I know :) As AFAIR it was always User associated with Application 
before application secret was introduced in KC. So maybe you wanted to 
be sure that all users, roles and applications are created before doing 
roleMappings and applicationRoleMappings.

I am thinking also about removing scopeMappings and 
applicationScopeMappings and move it instead under particular client? So 
for example, we will have client representation like:
     "oauthClients" : [
         {
             "name" : "oauthclient",
             "enabled": true,
             "secret": "clientpassword",
             "realmScopes": [ "admin" ],
             "applicationScopes": [
                "MyApplication": [ "app-user-role" ]
             ]
         }
     ],

It's more intuitive than separate scopeMappings and 
applicationScopeMappings IMO. Only small disadvantage I can see is, that 
we may need to be sure that all applications and roles are created 
before adding scopes, so it would need to iterate 2 times over 
ApplicationRepresentations though...

Let me know if you want me to proceed with this scopes change.

I believe that it's easier to change reps now, than after 1.0.Final, so 
might be good time to do all potential improvements now.

Marek
>
> Sounds like a good plan.  Make sure though you update all the .json
> files that use the old format.
>
> On 7/7/2014 10:22 AM, Marek Posolda wrote:
>> Hi,
>>
>> When working on export/import, I did some changes to reps. Specifically:
>>
>> - Remove "roleMappings", "applicationRoleMappings" and "socialMappings"
>> from RealmRepresentation and instead adding it directly under
>> UserRepresentation. So for user, we will have something like:
>>
>>            {
>>                "username": "admin",
>>                ...
>>                "realmRoles": [ "admin" ],
>>                "applicationRoles": [
>>                    "Application": [ "app-admin" ],
>>                    "OtherApp": [  "otherapp-admin" ]
>>                ]
>>            }
>>
>> The main reason is that for big number of users, we may need to paginate
>> them (For example add first 10k users of realm into one file and then
>> another 10k users into another file etc), so it will be nice to have all
>> info related to user in one place.
>>
>> - Added optional fields "hashedValue" and "salt" to
>> CredentialRepresentation. The thing is that if we want to do export, we
>> can't use plain-text "value", but we need to export it into
>> "hashedValue" . I am still keeping the "value", so it will be still
>> possible to import users with plain-text password as it is now. The main
>> usecase for "hashedValue"+"salt" is really just export/import (Import
>> passwords, which were previously exported)
>>
>> Let me know if you see some issues with it.
>>
>> Thanks,
>> Marek
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Mon Jul  7 19:03:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 07 Jul 2014 19:03:45 -0400
Subject: [keycloak-dev] AdminAPITest
Message-ID: <53BB2751.4020101@redhat.com>

FYI:

Developing a testsuite that takes a RealmRepresentation and tries to 
invoke/generate as many Admin REST api cals as possible based on that 
RealmRepresentation.  Goal is to attain 100% coverage on the Admin REST API.

Just in case somebody else might be thinking of working on it.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Jul  8 04:33:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 04:33:54 -0400 (EDT)
Subject: [keycloak-dev] AdminAPITest
In-Reply-To: <53BB2751.4020101@redhat.com>
References: <53BB2751.4020101@redhat.com>
Message-ID: <1556314687.5433523.1404808434756.JavaMail.zimbra@redhat.com>

Nice, it was the plan that the GateIn QA guys would look at this, but they can concentrate on the admin console. Maybe they can also test some adapters, for example keycloak.js

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 12:03:45 AM
> Subject: [keycloak-dev] AdminAPITest
> 
> FYI:
> 
> Developing a testsuite that takes a RealmRepresentation and tries to
> invoke/generate as many Admin REST api cals as possible based on that
> RealmRepresentation.  Goal is to attain 100% coverage on the Admin REST API.
> 
> Just in case somebody else might be thinking of working on it.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From matzew at apache.org  Tue Jul  8 05:38:36 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 8 Jul 2014 11:38:36 +0200
Subject: [keycloak-dev] UPS bundled and Widlfly integration
In-Reply-To: <20140603160129.GA8674@abstractj.org>
References: <20140603133923.GB97877@abstractj.org>
	<538DD14B.8080905@redhat.com> <20140603160129.GA8674@abstractj.org>
Message-ID: <CAAg5f2TXZBCyMCq3Yb_xsUNm9O9O0Ndufjhdnr5CEcgXggg9pg@mail.gmail.com>

Hello,

the NPE is present because the AdapterDeploymentContext is null, when using
the WildFly Adapter.

I tried to deploy this example to WildFly:
https://github.com/matzew/keycloak/tree/wildfly/project-integrations/aerogear-ups

The 'auth-server' works fine, and on the 'app' I simply changed the used
adapter:
https://github.com/matzew/keycloak/commit/c3f5d687fdb02f164bb87b9459332063c60b78e5

Now when I am deploying the app.war file, I am getting a NPE inside of the
BootstrapListener:


Caused by: java.lang.NullPointerException
at
org.keycloak.example.BootstrapListener.contextInitialized(BootstrapListener.java:24)
at
io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:173)
at
io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:190)
... 7 more



Looking at the sources, I see that the Undertow/WildFly adapters do behave
a bit different than the AS7 one.

A few observations, the AS7 adapter is not 'failing' if the
getConfigInputStream() returns null:
https://github.com/keycloak/keycloak/blob/master/integration/as7-eap6/adapter/src/main/java/org/keycloak/adapters/as7/KeycloakAuthenticatorValve.java#L114-L119

The AS7 apdater also stashes the AdapterDeploymentContext on the
servletContext:
https://github.com/keycloak/keycloak/blob/master/integration/as7-eap6/adapter/src/main/java/org/keycloak/adapters/as7/KeycloakAuthenticatorValve.java#L121

This is not done by the WildFly/Undertow Adapter, which causes the NPE that
Bruno and I are facing, when trying to deploy on WildFly


-Matthias






On Tue, Jun 3, 2014 at 6:01 PM, Bruno Oliveira <bruno at abstractj.org> wrote:

> 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
> _______________________________________________
> 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/20140708/6b495b5e/attachment-0001.html 

From stian at redhat.com  Tue Jul  8 07:10:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 07:10:09 -0400 (EDT)
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <498069172.5515844.1404817599140.JavaMail.zimbra@redhat.com>
Message-ID: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>

I've committed the hybrid store including jpa store implementations. It's enabled by default for the testsuite and the server, using jpa for realms and users, and mem for sessions.

By default the JPA stores all use the same persistence-unit, but it's possible to split into multiple persistence-units and configure through keycloak-server.json if someone wants to for example store realms in one db and users in another.

Remaining work includes:

* Mongo stores
* Updates to Keycloak session - remove model methods and add an enlist transaction feature for providers
* EntityManager and Mongo connection providers - I'm going to add providers for retrieving EntityManager instances and Mongo clients. The main reason for this is so that multiple stores can share the same connection/transaction when possible
* Delete JPA and Mongo model providers
* Update tests

From bburke at redhat.com  Tue Jul  8 08:10:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 08:10:49 -0400
Subject: [keycloak-dev] AdminAPITest
In-Reply-To: <1556314687.5433523.1404808434756.JavaMail.zimbra@redhat.com>
References: <53BB2751.4020101@redhat.com>
	<1556314687.5433523.1404808434756.JavaMail.zimbra@redhat.com>
Message-ID: <53BBDFC9.3090306@redhat.com>

Was waiting for your hybrid commit to do other work.  Needed something 
to keep me busy.

On 7/8/2014 4:33 AM, Stian Thorgersen wrote:
> Nice, it was the plan that the GateIn QA guys would look at this, but they can concentrate on the admin console. Maybe they can also test some adapters, for example keycloak.js
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 July, 2014 12:03:45 AM
>> Subject: [keycloak-dev] AdminAPITest
>>
>> FYI:
>>
>> Developing a testsuite that takes a RealmRepresentation and tries to
>> invoke/generate as many Admin REST api cals as possible based on that
>> RealmRepresentation.  Goal is to attain 100% coverage on the Admin REST API.
>>
>> Just in case somebody else might be thinking of working on it.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Tue Jul  8 08:17:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 08:17:17 -0400
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
Message-ID: <53BBE14D.50907@redhat.com>



On 7/8/2014 7:10 AM, Stian Thorgersen wrote:
> I've committed the hybrid store including jpa store implementations. It's enabled by default for the testsuite and the server, using jpa for realms and users, and mem for sessions.
>
> By default the JPA stores all use the same persistence-unit, but it's possible to split into multiple persistence-units and configure through keycloak-server.json if someone wants to for example store realms in one db and users in another.
>
> Remaining work includes:
>
> * Mongo stores
> * Updates to Keycloak session - remove model methods and add an enlist transaction feature for providers
> * EntityManager and Mongo connection providers - I'm going to add providers for retrieving EntityManager instances and Mongo clients. The main reason for this is so that multiple stores can share the same connection/transaction when possible

My memory is hazy, but I think there is some automatic session 
management that EMF is supposed to do.  So I don't think you need 
keycloak providers for EM creation. I'll have to look into it.

> * Delete JPA and Mongo model providers
> * Update tests
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jul  8 08:37:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 08:37:38 -0400 (EDT)
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <53BBE14D.50907@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
	<53BBE14D.50907@redhat.com>
Message-ID: <1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 1:17:17 PM
> Subject: Re: [keycloak-dev] Hybrid store committed
> 
> 
> 
> On 7/8/2014 7:10 AM, Stian Thorgersen wrote:
> > I've committed the hybrid store including jpa store implementations. It's
> > enabled by default for the testsuite and the server, using jpa for realms
> > and users, and mem for sessions.
> >
> > By default the JPA stores all use the same persistence-unit, but it's
> > possible to split into multiple persistence-units and configure through
> > keycloak-server.json if someone wants to for example store realms in one
> > db and users in another.
> >
> > Remaining work includes:
> >
> > * Mongo stores
> > * Updates to Keycloak session - remove model methods and add an enlist
> > transaction feature for providers
> > * EntityManager and Mongo connection providers - I'm going to add providers
> > for retrieving EntityManager instances and Mongo clients. The main reason
> > for this is so that multiple stores can share the same
> > connection/transaction when possible
> 
> My memory is hazy, but I think there is some automatic session
> management that EMF is supposed to do.  So I don't think you need
> keycloak providers for EM creation. I'll have to look into it.

It may share the connection, but it's not going to share the transaction. With the EM provider we can have a single transaction enlisted with the KeycloakSession. At the moment you could end up with 4 transactions (realms, users, sessions and audit) for a single request!

> 
> > * Delete JPA and Mongo model providers
> > * Update tests
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul  8 10:00:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 10:00:46 -0400
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
	<53BBE14D.50907@redhat.com>
	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>
Message-ID: <53BBF98E.2070305@redhat.com>



On 7/8/2014 8:37 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 July, 2014 1:17:17 PM
>> Subject: Re: [keycloak-dev] Hybrid store committed
>>
>>
>>
>> On 7/8/2014 7:10 AM, Stian Thorgersen wrote:
>>> I've committed the hybrid store including jpa store implementations. It's
>>> enabled by default for the testsuite and the server, using jpa for realms
>>> and users, and mem for sessions.
>>>
>>> By default the JPA stores all use the same persistence-unit, but it's
>>> possible to split into multiple persistence-units and configure through
>>> keycloak-server.json if someone wants to for example store realms in one
>>> db and users in another.
>>>
>>> Remaining work includes:
>>>
>>> * Mongo stores
>>> * Updates to Keycloak session - remove model methods and add an enlist
>>> transaction feature for providers
>>> * EntityManager and Mongo connection providers - I'm going to add providers
>>> for retrieving EntityManager instances and Mongo clients. The main reason
>>> for this is so that multiple stores can share the same
>>> connection/transaction when possible
>>
>> My memory is hazy, but I think there is some automatic session
>> management that EMF is supposed to do.  So I don't think you need
>> keycloak providers for EM creation. I'll have to look into it.
>
> It may share the connection, but it's not going to share the transaction. With the EM provider we can have a single transaction enlisted with the KeycloakSession. At the moment you could end up with 4 transactions (realms, users, sessions and audit) for a single request!
>

Are you sure it doesn't share the same transaction?  It definitely does 
for JTA.

Bill

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

From bburke at redhat.com  Tue Jul  8 10:07:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 10:07:33 -0400
Subject: [keycloak-dev] confused on new model
Message-ID: <53BBFB25.7070503@redhat.com>

I see a directory jpa/  The old model.  What is that used for now? 
Anything?  Can it be deleted?

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

From stian at redhat.com  Tue Jul  8 10:12:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 10:12:14 -0400 (EDT)
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <53BBF98E.2070305@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
	<53BBE14D.50907@redhat.com>
	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>
	<53BBF98E.2070305@redhat.com>
Message-ID: <2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>

If we used beans and container managed transactions then it might do that. It may also just create multiple transactions and do a 2PC. But, we don't, we start/commit our own transactions in Hibernate, and at the moment we explicitly create multiple transactions.

Before I'll start this I'll check what happens. I'm sure I can relatively easily add some debug statements for when jdbc connections and transactions are created.

It may also be better for us to create a UserTransaction and have the EM's enlist with that, instead of managing our own. That way we would get proper 2PC when its supported. That may be a bit overkill though, as I don't think we'd often want to update multiple databases at the same time.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 3:00:46 PM
> Subject: Re: [keycloak-dev] Hybrid store committed
> 
> 
> 
> On 7/8/2014 8:37 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 8 July, 2014 1:17:17 PM
> >> Subject: Re: [keycloak-dev] Hybrid store committed
> >>
> >>
> >>
> >> On 7/8/2014 7:10 AM, Stian Thorgersen wrote:
> >>> I've committed the hybrid store including jpa store implementations. It's
> >>> enabled by default for the testsuite and the server, using jpa for realms
> >>> and users, and mem for sessions.
> >>>
> >>> By default the JPA stores all use the same persistence-unit, but it's
> >>> possible to split into multiple persistence-units and configure through
> >>> keycloak-server.json if someone wants to for example store realms in one
> >>> db and users in another.
> >>>
> >>> Remaining work includes:
> >>>
> >>> * Mongo stores
> >>> * Updates to Keycloak session - remove model methods and add an enlist
> >>> transaction feature for providers
> >>> * EntityManager and Mongo connection providers - I'm going to add
> >>> providers
> >>> for retrieving EntityManager instances and Mongo clients. The main reason
> >>> for this is so that multiple stores can share the same
> >>> connection/transaction when possible
> >>
> >> My memory is hazy, but I think there is some automatic session
> >> management that EMF is supposed to do.  So I don't think you need
> >> keycloak providers for EM creation. I'll have to look into it.
> >
> > It may share the connection, but it's not going to share the transaction.
> > With the EM provider we can have a single transaction enlisted with the
> > KeycloakSession. At the moment you could end up with 4 transactions
> > (realms, users, sessions and audit) for a single request!
> >
> 
> Are you sure it doesn't share the same transaction?  It definitely does
> for JTA.
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue Jul  8 10:13:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 10:13:43 -0400 (EDT)
Subject: [keycloak-dev] confused on new model
In-Reply-To: <53BBFB25.7070503@redhat.com>
References: <53BBFB25.7070503@redhat.com>
Message-ID: <86818608.5651897.1404828823790.JavaMail.zimbra@redhat.com>

I'll delete it soon. There's some tests that uses it atm.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 3:07:33 PM
> Subject: [keycloak-dev] confused on new model
> 
> I see a directory jpa/  The old model.  What is that used for now?
> Anything?  Can it be deleted?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul  8 10:27:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 10:27:11 -0400
Subject: [keycloak-dev] triple abstraction?
Message-ID: <53BBFFBF.7060103@redhat.com>

Geez,

We now have a 6 levels of indirection:

KeycloakSession->ModelProvider->Model API->Hybrid API->Adapter->Entity

Too...much...abstraction....  It needs to be consolidated.  When you're 
done with the mongo store, I'd like to refactor and merge the model and 
hybrid apis and get services/ to use it.  We need this done before 
beta-4 and beyond.  I can't really finish my cache work until the 
underlying API is on a solid foundation, and right now, IMO, it isn't.

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

From stian at redhat.com  Tue Jul  8 10:35:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 10:35:21 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BBFFBF.7060103@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
Message-ID: <2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>

I've removed the model methods from KeycloakSession, so that's one level of indirection gone.

Are you talking about dropping Model API?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 3:27:11 PM
> Subject: [keycloak-dev] triple abstraction?
> 
> Geez,
> 
> We now have a 6 levels of indirection:
> 
> KeycloakSession->ModelProvider->Model API->Hybrid API->Adapter->Entity
> 
> Too...much...abstraction....  It needs to be consolidated.  When you're
> done with the mongo store, I'd like to refactor and merge the model and
> hybrid apis and get services/ to use it.  We need this done before
> beta-4 and beyond.  I can't really finish my cache work until the
> underlying API is on a solid foundation, and right now, IMO, it isn't.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Jul  8 10:46:50 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 08 Jul 2014 16:46:50 +0200
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>	<53BBE14D.50907@redhat.com>	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>	<53BBF98E.2070305@redhat.com>
	<2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>
Message-ID: <53BC045A.70500@redhat.com>

On 8.7.2014 16:12, Stian Thorgersen wrote:
> If we used beans and container managed transactions then it might do that. It may also just create multiple transactions and do a 2PC. But, we don't, we start/commit our own transactions in Hibernate, and at the moment we explicitly create multiple transactions.
>
> Before I'll start this I'll check what happens. I'm sure I can relatively easily add some debug statements for when jdbc connections and transactions are created.
>
> It may also be better for us to create a UserTransaction and have the EM's enlist with that, instead of managing our own. That way we would get proper 2PC when its supported. That may be a bit overkill though, as I don't think we'd often want to update multiple databases at the same time.
+1 to use UserTransaction and JTA. I think earlier or later we may need 
to support 2PC anyway. Also AFAIK with JTA the jdbc connection is 
created "lazily" with Hibernate. In details if 
"hibernate.current_session_context_class" is "thread" (which is by 
default) then new JDBC connection is always opened when calling 
"hibernateSession.getTransaction().begin()" . But when 
"hibernate.current_session_context_class" is "jta" it retrieves JDBC 
connection lazily when DB call is needed by Hibernate.

At least, last time I used this, it behaved this way. I used plain 
hibernate API though (not JPA EntityManager), but I don't think that the 
behaviour is different with JPA.

With respect to the fact that we have caching layer, there may be many 
HTTP requests, which won't need to open JDBC connection, which might be 
nice performance gain IMO.

Marek
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 July, 2014 3:00:46 PM
>> Subject: Re: [keycloak-dev] Hybrid store committed
>>
>>
>>
>> On 7/8/2014 8:37 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 8 July, 2014 1:17:17 PM
>>>> Subject: Re: [keycloak-dev] Hybrid store committed
>>>>
>>>>
>>>>
>>>> On 7/8/2014 7:10 AM, Stian Thorgersen wrote:
>>>>> I've committed the hybrid store including jpa store implementations. It's
>>>>> enabled by default for the testsuite and the server, using jpa for realms
>>>>> and users, and mem for sessions.
>>>>>
>>>>> By default the JPA stores all use the same persistence-unit, but it's
>>>>> possible to split into multiple persistence-units and configure through
>>>>> keycloak-server.json if someone wants to for example store realms in one
>>>>> db and users in another.
>>>>>
>>>>> Remaining work includes:
>>>>>
>>>>> * Mongo stores
>>>>> * Updates to Keycloak session - remove model methods and add an enlist
>>>>> transaction feature for providers
>>>>> * EntityManager and Mongo connection providers - I'm going to add
>>>>> providers
>>>>> for retrieving EntityManager instances and Mongo clients. The main reason
>>>>> for this is so that multiple stores can share the same
>>>>> connection/transaction when possible
>>>> My memory is hazy, but I think there is some automatic session
>>>> management that EMF is supposed to do.  So I don't think you need
>>>> keycloak providers for EM creation. I'll have to look into it.
>>> It may share the connection, but it's not going to share the transaction.
>>> With the EM provider we can have a single transaction enlisted with the
>>> KeycloakSession. At the moment you could end up with 4 transactions
>>> (realms, users, sessions and audit) for a single request!
>>>
>> Are you sure it doesn't share the same transaction?  It definitely does
>> for JTA.
>>
>> 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  Tue Jul  8 10:52:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 10:52:10 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
Message-ID: <53BC059A.8050405@redhat.com>



On 7/8/2014 10:35 AM, Stian Thorgersen wrote:
> I've removed the model methods from KeycloakSession, so that's one level of indirection gone.
>
> Are you talking about dropping Model API?
>

Dropping Model API or Hybrid API.  Would probably be easier to drop 
Hybrid and replace some Model API methods (i.e. addUser()) with 
ModelProvider equivalent.

Maybe you can't because of cross-provider joins for things like roles? 
Then again, maybe you should let the UserProvider decide how to convert 
a role mapping to a referenced RoleModel and vice versa.

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

From bburke at redhat.com  Tue Jul  8 11:01:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 11:01:18 -0400
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <53BC045A.70500@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>	<53BBE14D.50907@redhat.com>	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>	<53BBF98E.2070305@redhat.com>
	<2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>
	<53BC045A.70500@redhat.com>
Message-ID: <53BC07BE.8000401@redhat.com>



On 7/8/2014 10:46 AM, Marek Posolda wrote:
> On 8.7.2014 16:12, Stian Thorgersen wrote:
>> If we used beans and container managed transactions then it might do
>> that. It may also just create multiple transactions and do a 2PC. But,
>> we don't, we start/commit our own transactions in Hibernate, and at
>> the moment we explicitly create multiple transactions.
>>
>> Before I'll start this I'll check what happens. I'm sure I can
>> relatively easily add some debug statements for when jdbc connections
>> and transactions are created.
>>
>> It may also be better for us to create a UserTransaction and have the
>> EM's enlist with that, instead of managing our own. That way we would
>> get proper 2PC when its supported. That may be a bit overkill though,
>> as I don't think we'd often want to update multiple databases at the
>> same time.
> +1 to use UserTransaction and JTA. I think earlier or later we may need
> to support 2PC anyway. Also AFAIK with JTA the jdbc connection is
> created "lazily" with Hibernate. In details if
> "hibernate.current_session_context_class" is "thread" (which is by
> default) then new JDBC connection is always opened when calling
> "hibernateSession.getTransaction().begin()" . But when
> "hibernate.current_session_context_class" is "jta" it retrieves JDBC
> connection lazily when DB call is needed by Hibernate.
>
> At least, last time I used this, it behaved this way. I used plain
> hibernate API though (not JPA EntityManager), but I don't think that the
> behaviour is different with JPA.
>
> With respect to the fact that we have caching layer, there may be many
> HTTP requests, which won't need to open JDBC connection, which might be
> nice performance gain IMO.
>

UserTransaction and JTA would make things easier.  CDI would make things 
easier too.

My only concern is that we've just narrowed where Keycloak can be 
deployed.  Currently, its not to much of a leap to install Keycloak, 
Hibernate and Resteasy on Tomcat.


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

From stian at redhat.com  Tue Jul  8 11:16:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 11:16:25 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BC059A.8050405@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
Message-ID: <81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>

Dropping Hybrid API sounds like pretty much undoing all the work I've done the last couple weeks :(

IMO what we should do is to drop the Model API/SPI. Instead make it into a single implementation that delegates to the various providers (RealmProvider, UserProvider, SessionProvider and probably also CacheProvider). We can then merge this with RealmManager, ApplicationManager, etc. and instead have a single ModelManager.

I don't think it's a good idea to make the UserProvider create RoleModels. The UserProvider should be as simple as possible IMO, and shouldn't deal with Realms, Apps, Roles, etc, other than through simple id's. 

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 3:52:10 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> On 7/8/2014 10:35 AM, Stian Thorgersen wrote:
> > I've removed the model methods from KeycloakSession, so that's one level of
> > indirection gone.
> >
> > Are you talking about dropping Model API?
> >
> 
> Dropping Model API or Hybrid API.  Would probably be easier to drop
> Hybrid and replace some Model API methods (i.e. addUser()) with
> ModelProvider equivalent.
> 
> Maybe you can't because of cross-provider joins for things like roles?
> Then again, maybe you should let the UserProvider decide how to convert
> a role mapping to a referenced RoleModel and vice versa.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue Jul  8 11:19:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 11:19:06 -0400 (EDT)
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <53BC07BE.8000401@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
	<53BBE14D.50907@redhat.com>
	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>
	<53BBF98E.2070305@redhat.com>
	<2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>
	<53BC045A.70500@redhat.com> <53BC07BE.8000401@redhat.com>
Message-ID: <950859504.5712458.1404832746424.JavaMail.zimbra@redhat.com>

At some point we'll probably have to run on a trimmed down WildFly (no JavaEE stuff). Not sure if the transaction manager would still be there though.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:01:18 PM
> Subject: Re: [keycloak-dev] Hybrid store committed
> 
> 
> 
> On 7/8/2014 10:46 AM, Marek Posolda wrote:
> > On 8.7.2014 16:12, Stian Thorgersen wrote:
> >> If we used beans and container managed transactions then it might do
> >> that. It may also just create multiple transactions and do a 2PC. But,
> >> we don't, we start/commit our own transactions in Hibernate, and at
> >> the moment we explicitly create multiple transactions.
> >>
> >> Before I'll start this I'll check what happens. I'm sure I can
> >> relatively easily add some debug statements for when jdbc connections
> >> and transactions are created.
> >>
> >> It may also be better for us to create a UserTransaction and have the
> >> EM's enlist with that, instead of managing our own. That way we would
> >> get proper 2PC when its supported. That may be a bit overkill though,
> >> as I don't think we'd often want to update multiple databases at the
> >> same time.
> > +1 to use UserTransaction and JTA. I think earlier or later we may need
> > to support 2PC anyway. Also AFAIK with JTA the jdbc connection is
> > created "lazily" with Hibernate. In details if
> > "hibernate.current_session_context_class" is "thread" (which is by
> > default) then new JDBC connection is always opened when calling
> > "hibernateSession.getTransaction().begin()" . But when
> > "hibernate.current_session_context_class" is "jta" it retrieves JDBC
> > connection lazily when DB call is needed by Hibernate.
> >
> > At least, last time I used this, it behaved this way. I used plain
> > hibernate API though (not JPA EntityManager), but I don't think that the
> > behaviour is different with JPA.
> >
> > With respect to the fact that we have caching layer, there may be many
> > HTTP requests, which won't need to open JDBC connection, which might be
> > nice performance gain IMO.
> >
> 
> UserTransaction and JTA would make things easier.  CDI would make things
> easier too.
> 
> My only concern is that we've just narrowed where Keycloak can be
> deployed.  Currently, its not to much of a leap to install Keycloak,
> Hibernate and Resteasy on Tomcat.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Jul  8 11:21:46 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 11:21:46 -0400
Subject: [keycloak-dev] How would you handle an external user store?
Message-ID: <53BC0C8A.4050305@redhat.com>

It is not very clear going forward the relationship between 
AuthenticationProvider and UserProvider.  My understanding was that 
UserProvider split was implemented to help users handle the case where 
they have an existing user store they want to use.  IMO, 
AuthenticationProvider have overlapping concerns and should be merged.

Let's say we have LdAP that stores

username,
password,
address
phone

But no role mappings.  How would you handle both authentication and 
implementing the UserProvider with role mapping support?

I just think our current way/split of UserProvider, 
AuthenticationProvider, and UserModel just isn't going to cut it going 
forward.  Think of federation too where one Keycloak server might have 
to federate multiple user stores.  Each of those stores might have 
static data models which don't fully support Keycloak metadata which may 
require us to store some user information in Keycloak's storage.

I think a UserProvider needs to tell keycloak:

* What user metadata it stores
* What credential types does the UserProvider store?
* What credential types should the store validate?
* What credential types should Keycloak validate?

Keycloak needs a reference to local storage to the UserProvider so it 
can create local UserModels if necessary.  The local UserModel needs to 
have metadata that answers all the above questions.

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

From bburke at redhat.com  Tue Jul  8 11:29:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 11:29:03 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
Message-ID: <53BC0E3F.4010009@redhat.com>



On 7/8/2014 11:16 AM, Stian Thorgersen wrote:
> Dropping Hybrid API sounds like pretty much undoing all the work I've done the last couple weeks :(
>

I honestly have some serious concerns that this split will solve much. 
See my previous email.

> IMO what we should do is to drop the Model API/SPI. Instead make it into a single implementation that delegates to the various providers (RealmProvider, UserProvider, SessionProvider and probably also CacheProvider). We can then merge this with RealmManager, ApplicationManager, etc. and instead have a single ModelManager.
>
> I don't think it's a good idea to make the UserProvider create RoleModels. The UserProvider should be as simple as possible IMO, and shouldn't deal with Realms, Apps, Roles, etc, other than through simple id's.
>

That's not what I said.  UserProvider may have to map between an 
existing static user role mapping in some existing LDAP store to a role 
defined in Keycloak.  It may be impossible to map one to one a Keycloak 
role id and the role mapping stored in the customer's user database.

Federating an existing user store is pretty hard to do even with the 
current split.  Not only does the UserProvider make some pretty steep 
assumptions, tts pretty hard, IMO, to understand exactly where 
AuthenticationProvider begins and the UserProvider takes over, or the 
relationship between the two.

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

From stian at redhat.com  Tue Jul  8 11:39:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 11:39:02 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BC0E3F.4010009@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
Message-ID: <214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:29:03 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> On 7/8/2014 11:16 AM, Stian Thorgersen wrote:
> > Dropping Hybrid API sounds like pretty much undoing all the work I've done
> > the last couple weeks :(
> >
> 
> I honestly have some serious concerns that this split will solve much.
> See my previous email.

Which email?

> 
> > IMO what we should do is to drop the Model API/SPI. Instead make it into a
> > single implementation that delegates to the various providers
> > (RealmProvider, UserProvider, SessionProvider and probably also
> > CacheProvider). We can then merge this with RealmManager,
> > ApplicationManager, etc. and instead have a single ModelManager.
> >
> > I don't think it's a good idea to make the UserProvider create RoleModels.
> > The UserProvider should be as simple as possible IMO, and shouldn't deal
> > with Realms, Apps, Roles, etc, other than through simple id's.
> >
> 
> That's not what I said.  UserProvider may have to map between an
> existing static user role mapping in some existing LDAP store to a role
> defined in Keycloak.  It may be impossible to map one to one a Keycloak
> role id and the role mapping stored in the customer's user database.

Sure, I assumed the UserProvider would do that by returning the id of the Keycloak role it maps to.

> 
> Federating an existing user store is pretty hard to do even with the
> current split.  Not only does the UserProvider make some pretty steep
> assumptions, tts pretty hard, IMO, to understand exactly where
> AuthenticationProvider begins and the UserProvider takes over, or the
> relationship between the two.

See my previous email where I proposed that AuthenticationProvider could be dropped and replaced by a delegating UserProvider with the same functionality.

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

From stian at redhat.com  Tue Jul  8 11:42:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 11:42:12 -0400 (EDT)
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <53BC0C8A.4050305@redhat.com>
References: <53BC0C8A.4050305@redhat.com>
Message-ID: <854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>

Cut/paste from previous email:


AuthProvider is trying to achieve something different than storing users, and the combination of the two is quite flexible. Someone could still achieve what they can achieve with AuthProvider by creating a UserProvider impl that delegates to another UserProvider impl for storage, so maybe we could respin the AuthProvider SPI into a UserProvider that can use another UserProvider for storing users, and one or more UserProviders for authentication. That way we'd still have the capability, but with it less hard-coded into the core code.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | AuthUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Authenticate  +--------------------+


Same again with Sync SPI, that could be done as a delegating UserProvider store.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | SyncUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Sync          +--------------------+



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:21:46 PM
> Subject: [keycloak-dev] How would you handle an external user store?
> 
> It is not very clear going forward the relationship between
> AuthenticationProvider and UserProvider.  My understanding was that
> UserProvider split was implemented to help users handle the case where
> they have an existing user store they want to use.  IMO,
> AuthenticationProvider have overlapping concerns and should be merged.
> 
> Let's say we have LdAP that stores
> 
> username,
> password,
> address
> phone
> 
> But no role mappings.  How would you handle both authentication and
> implementing the UserProvider with role mapping support?
> 
> I just think our current way/split of UserProvider,
> AuthenticationProvider, and UserModel just isn't going to cut it going
> forward.  Think of federation too where one Keycloak server might have
> to federate multiple user stores.  Each of those stores might have
> static data models which don't fully support Keycloak metadata which may
> require us to store some user information in Keycloak's storage.
> 
> I think a UserProvider needs to tell keycloak:
> 
> * What user metadata it stores
> * What credential types does the UserProvider store?
> * What credential types should the store validate?
> * What credential types should Keycloak validate?
> 
> Keycloak needs a reference to local storage to the UserProvider so it
> can create local UserModels if necessary.  The local UserModel needs to
> have metadata that answers all the above questions.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jul  8 12:01:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 8 Jul 2014 12:01:46 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
Message-ID: <77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>

I thought we where at an agreement with splitting the model. If that's not the case, and to be able to actually do a release sometime soon, I propose we just revert back to how it was before.

For argument sake the benefits for this split include:

* Users are what we need to federate, this split makes that a lot simpler IMO
* Users are what people may want to store in their own schema, again this makes it a lot simpler IMO
* Can store different things in different store types. For example realms in a json file, users in a relational database and sessions in a in-mem data-grid
* Realms store can be changed if we need to. Relative quick and easy to export/import to update.
* Users store shouldn't be changed frequently. Updating a database with 20 million entries is non-trivial
* Model was getting pretty big and complex, with loads of tables. Splitting makes it simpler IMO

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:39:02 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 8 July, 2014 4:29:03 PM
> > Subject: Re: [keycloak-dev] triple abstraction?
> > 
> > 
> > 
> > On 7/8/2014 11:16 AM, Stian Thorgersen wrote:
> > > Dropping Hybrid API sounds like pretty much undoing all the work I've
> > > done
> > > the last couple weeks :(
> > >
> > 
> > I honestly have some serious concerns that this split will solve much.
> > See my previous email.
> 
> Which email?
> 
> > 
> > > IMO what we should do is to drop the Model API/SPI. Instead make it into
> > > a
> > > single implementation that delegates to the various providers
> > > (RealmProvider, UserProvider, SessionProvider and probably also
> > > CacheProvider). We can then merge this with RealmManager,
> > > ApplicationManager, etc. and instead have a single ModelManager.
> > >
> > > I don't think it's a good idea to make the UserProvider create
> > > RoleModels.
> > > The UserProvider should be as simple as possible IMO, and shouldn't deal
> > > with Realms, Apps, Roles, etc, other than through simple id's.
> > >
> > 
> > That's not what I said.  UserProvider may have to map between an
> > existing static user role mapping in some existing LDAP store to a role
> > defined in Keycloak.  It may be impossible to map one to one a Keycloak
> > role id and the role mapping stored in the customer's user database.
> 
> Sure, I assumed the UserProvider would do that by returning the id of the
> Keycloak role it maps to.
> 
> > 
> > Federating an existing user store is pretty hard to do even with the
> > current split.  Not only does the UserProvider make some pretty steep
> > assumptions, tts pretty hard, IMO, to understand exactly where
> > AuthenticationProvider begins and the UserProvider takes over, or the
> > relationship between the two.
> 
> See my previous email where I proposed that AuthenticationProvider could be
> dropped and replaced by a delegating UserProvider with the same
> functionality.
> 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul  8 12:50:04 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 12:50:04 -0400
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
References: <53BC0C8A.4050305@redhat.com>
	<854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
Message-ID: <53BC213C.4040107@redhat.com>



On 7/8/2014 11:42 AM, Stian Thorgersen wrote:
> Cut/paste from previous email:
>

Which didn't answer anything for me.

>
> AuthProvider is trying to achieve something different than storing users, and the combination of the two is quite flexible.

They serve different purposes? And yet AuthProvider stores users:

AuthProvider.registerUser()

and retrieves them:

AuthProvider.getUser()

Then you have AuthenticationManager which creates a UserModel, sets up 
an AuthenticationLink.  So a developer has to implement registerUser() 
as well as the create interfaces of UserProvider.

More often than not, authentication and user storage will be from the 
same place, then you have to doubly configure the LDAP connection for 
both the UserProvider and the AuthProvider.  Except one is configured in 
the Admin Console (AuthProvider) and the other within keycloak-server.json.

You really don't see how this is screwed up?

> Someone could still achieve what they can achieve with AuthProvider by creating a UserProvider impl that delegates to another UserProvider impl for storage, so maybe we could respin the AuthProvider SPI into a UserProvider that can use another UserProvider for storing users, and one or more UserProviders for authentication. That way we'd still have the capability, but with it less hard-coded into the core code.
>

Of course, which is why I asked the question, WTF do we still have 
AuthProvider?  The two need to be merged and credential validation needs 
to move down to the User interface level.

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

From bburke at redhat.com  Tue Jul  8 13:14:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 13:14:35 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
Message-ID: <53BC26FB.6010603@redhat.com>



On 7/8/2014 12:01 PM, Stian Thorgersen wrote:
> I thought we where at an agreement with splitting the model. If that's not the case, and to be able to actually do a release sometime soon, I propose we just revert back to how it was before.
>

I did not know you were going to write a completely new persistence 
abstraction underneath our existing persistence abstraction.  I thought 
the existing Model interfaces were going to be retained/refactored and 
you were just going to split out how UserModel, Realm, and UserSessions 
were looked up.

> For argument sake the benefits for this split include:
>
> * Users are what we need to federate, this split makes that a lot simpler IMO
> * Users are what people may want to store in their own schema, again this makes it a lot simpler IMO
> * Can store different things in different store types. For example realms in a json file, users in a relational database and sessions in a in-mem data-grid
> * Realms store can be changed if we need to. Relative quick and easy to export/import to update.
> * Users store shouldn't be changed frequently. Updating a database with 20 million entries is non-trivial

All you did to improve the 20 million use case was remove secondary key 
constraints from UserEntity and UserRoleMappingEntity, which could have 
been done in the existing model.

> * Model was getting pretty big and complex, with loads of tables. Splitting makes it simpler IMO
>

Bah! our data model is not complex!

Summary of my perspective

* Model API was written so that the implementation details of storage 
wouldn't be exposed to the service layer.  So, if we retired the Model 
API in favor of using the Hybrid API, the service layer would be dealing 
with user ids, role ids, realm ids, client ids, instead of UserModel, 
RoleModel, RealmModel, and ClientModel.
* The Adapter classes existed to bridge between the Model API and the 
persistence API.  I think you lost that notion in the Hybrid model as it 
is completely String ID based.
* The line between AuthentcationProvider and UserProvider is now blurred 
and confusing as they both provide a mechanism to create and look up 
users.  I'm not even sure you could have a LDAP store that is both a 
UserProvider and AuthenticationProvider.


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

From mposolda at redhat.com  Tue Jul  8 16:06:19 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 08 Jul 2014 22:06:19 +0200
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <53BC213C.4040107@redhat.com>
References: <53BC0C8A.4050305@redhat.com>	<854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
	<53BC213C.4040107@redhat.com>
Message-ID: <53BC4F3B.7010507@redhat.com>

On 8.7.2014 18:50, Bill Burke wrote:
>> AuthProvider is trying to achieve something different than storing users, and the combination of the two is quite flexible.
> They serve different purposes? And yet AuthProvider stores users:
>
> AuthProvider.registerUser()
>
> and retrieves them:
>
> AuthProvider.getUser()
>
> Then you have AuthenticationManager which creates a UserModel, sets up
> an AuthenticationLink.  So a developer has to implement registerUser()
> as well as the create interfaces of UserProvider.
IMO the difference is:
- UserProvider is used to implement whole storage SPI and store *all* 
informations needed for user (roles, socialLinks, requiredRoles etc...)

- AuthenticationProvider is used just for password based authentication 
and hence need just very small subset of UserProvider methods. Note that 
methods "registerUser" and "updatePassword" are not mandatory to 
implement if you set "passwordUpdateSupported" for particular 
AuthenticationProvider to false. Method "registerUser" is used just to 
send "some" data of UserModel to the Auth store, but it doesn't need to 
be all (For example with LDAP you store just username, firstName, 
lastName, email ).

The point is, that AuthenticationProvider is really easy to implement as 
it doesn't need to store all Keycloak data related to user. See 
PropertiesAuthenticationProvider from our examples. And note that we 
already have community members, who implement their own Authentication 
providers. IMO LDAP, Properties file, or legacy database are classic 
example, which suits much better as AuthenticationProvider than 
UserProvider.

I am not sure if Federation based on metadata on UserModel is good idea. 
I think we already discussed Federation approach and the decision was to 
avoid it due to many reasons. I believe that Authentication SPI and Sync 
SPI were introduced mainly to avoid federation approach...

  I am happy with AuthUserProvider, which delegates "store" to other 
underlying UserProvider, but authentication to one or more 
AuthenticationProviders. This might help to remove the "authentication" 
related code from AuthenticationManager. So something like:

                                          +--------------------+
                            Store         |                    |
                             +------------>  JpaUserProvider   |
                             |            |                    |
                             |            +--------------------+
          +------------------+
          |                  |
          | AuthUserProvider |            +--------------------+
          |                  |            |                    |
          +------------------+            |  LDAPAuthenticationProvider  |
                             +------------>                    |
                            Authenticate  +--------------------+



LDAPUserProvider or PropertiesFileUserProvider doesn't make much sense 
to me as implementors would need to leave almost all methods empty or 
"throw new NotImplementedException()"

>
> More often than not, authentication and user storage will be from the
> same place, then you have to doubly configure the LDAP connection for
> both the UserProvider and the AuthProvider.  Except one is configured in
> the Admin Console (AuthProvider) and the other within keycloak-server.json.
I don't think so. AuthenticationProvider is used mainly for case when 
you don't have both authentication and user storage in same place. With 
AuthUserProvider Stian proposed, we might have AuthUserProvider to be 
used in cases when user configured some AuthenticationProviders. 
Otherwise directly use JpaUserProvider to store everything (including 
authentication) and completely skip AuthenticationProvider layer in this 
case.

As I said LDAPUserProvider doesn't make much sense to me, so it's not 
needed to configure in 2 places. AFAIK in next KC version, the plan for 
stuff like SMTP and LDAP is to remove it from realm configuration and 
move it to keycloak-server.json . And also the possibility to configure 
stuff from keycloak-server.json in admin console UI.

Marek



From mposolda at redhat.com  Tue Jul  8 16:11:17 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 08 Jul 2014 22:11:17 +0200
Subject: [keycloak-dev] Hybrid store committed
In-Reply-To: <950859504.5712458.1404832746424.JavaMail.zimbra@redhat.com>
References: <579807992.5517463.1404817809329.JavaMail.zimbra@redhat.com>
	<53BBE14D.50907@redhat.com>
	<1700352830.5576762.1404823058467.JavaMail.zimbra@redhat.com>
	<53BBF98E.2070305@redhat.com>
	<2074913902.5650765.1404828734287.JavaMail.zimbra@redhat.com>
	<53BC045A.70500@redhat.com> <53BC07BE.8000401@redhat.com>
	<950859504.5712458.1404832746424.JavaMail.zimbra@redhat.com>
Message-ID: <53BC5065.1080802@redhat.com>

Yeah, I wonder if this can be an optional feature? You will have 
possibility to choose either JTA or delegate to EntityManager 
transaction API. So something like:

public void begin() {
  if (configuration.isJTAEnabled()) {
    // delegate to UserTransaction
  } else {
   // delegate to EntityManager
  }
}

With Tomcat, embedded Undertow or trimmed Wildfly, people will always 
need to use EntityManager (JPA API). But on AS7/Wildfly they may use JTA.

Marek

On 8.7.2014 17:19, Stian Thorgersen wrote:
> At some point we'll probably have to run on a trimmed down WildFly (no JavaEE stuff). Not sure if the transaction manager would still be there though.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 8 July, 2014 4:01:18 PM
>> Subject: Re: [keycloak-dev] Hybrid store committed
>>
>>
>>
>> On 7/8/2014 10:46 AM, Marek Posolda wrote:
>>> On 8.7.2014 16:12, Stian Thorgersen wrote:
>>>> If we used beans and container managed transactions then it might do
>>>> that. It may also just create multiple transactions and do a 2PC. But,
>>>> we don't, we start/commit our own transactions in Hibernate, and at
>>>> the moment we explicitly create multiple transactions.
>>>>
>>>> Before I'll start this I'll check what happens. I'm sure I can
>>>> relatively easily add some debug statements for when jdbc connections
>>>> and transactions are created.
>>>>
>>>> It may also be better for us to create a UserTransaction and have the
>>>> EM's enlist with that, instead of managing our own. That way we would
>>>> get proper 2PC when its supported. That may be a bit overkill though,
>>>> as I don't think we'd often want to update multiple databases at the
>>>> same time.
>>> +1 to use UserTransaction and JTA. I think earlier or later we may need
>>> to support 2PC anyway. Also AFAIK with JTA the jdbc connection is
>>> created "lazily" with Hibernate. In details if
>>> "hibernate.current_session_context_class" is "thread" (which is by
>>> default) then new JDBC connection is always opened when calling
>>> "hibernateSession.getTransaction().begin()" . But when
>>> "hibernate.current_session_context_class" is "jta" it retrieves JDBC
>>> connection lazily when DB call is needed by Hibernate.
>>>
>>> At least, last time I used this, it behaved this way. I used plain
>>> hibernate API though (not JPA EntityManager), but I don't think that the
>>> behaviour is different with JPA.
>>>
>>> With respect to the fact that we have caching layer, there may be many
>>> HTTP requests, which won't need to open JDBC connection, which might be
>>> nice performance gain IMO.
>>>
>> UserTransaction and JTA would make things easier.  CDI would make things
>> easier too.
>>
>> My only concern is that we've just narrowed where Keycloak can be
>> deployed.  Currently, its not to much of a leap to install Keycloak,
>> Hibernate and Resteasy on Tomcat.
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>


From bburke at redhat.com  Tue Jul  8 19:10:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 08 Jul 2014 19:10:55 -0400
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <53BC4F3B.7010507@redhat.com>
References: <53BC0C8A.4050305@redhat.com>	<854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
	<53BC213C.4040107@redhat.com> <53BC4F3B.7010507@redhat.com>
Message-ID: <53BC7A7F.6060104@redhat.com>



On 7/8/2014 4:06 PM, Marek Posolda wrote:
> On 8.7.2014 18:50, Bill Burke wrote:
>>> AuthProvider is trying to achieve something different than storing
>>> users, and the combination of the two is quite flexible.
>> They serve different purposes? And yet AuthProvider stores users:
>>
>> AuthProvider.registerUser()
>>
>> and retrieves them:
>>
>> AuthProvider.getUser()
>>
>> Then you have AuthenticationManager which creates a UserModel, sets up
>> an AuthenticationLink.  So a developer has to implement registerUser()
>> as well as the create interfaces of UserProvider.
> IMO the difference is:
> - UserProvider is used to implement whole storage SPI and store *all*
> informations needed for user (roles, socialLinks, requiredRoles etc...)
>
> - AuthenticationProvider is used just for password based authentication
> and hence need just very small subset of UserProvider methods. Note that
> methods "registerUser" and "updatePassword" are not mandatory to
> implement if you set "passwordUpdateSupported" for particular
> AuthenticationProvider to false. Method "registerUser" is used just to
> send "some" data of UserModel to the Auth store, but it doesn't need to
> be all (For example with LDAP you store just username, firstName,
> lastName, email ).
>

I was under the impression that LDAP schemas often store more than 
username, first, last, and email. i.e. address, phone number, really any 
number of claims.  They also can store role mappings as well, correct? 
So if a user has all those things in LDAP *AND* they want to 
authenticate through LDAP, what do they do?

The same could be said of RDBMS too.

> The point is, that AuthenticationProvider is really easy to implement as
> it doesn't need to store all Keycloak data related to user.

But that is not currently how you use AuthenticationProvider.

If the user is not already stored in a Keycloak UserModel, then 
AuthenticationProvider.getUser() must be implemented.  Otherwise 
INVALID_USER is returned.


Besides.  UserProvider is just as easy to implement.

> See
> PropertiesAuthenticationProvider from our examples. And note that we
> already have community members, who implement their own Authentication
> providers. IMO LDAP, Properties file, or legacy database are classic
> example, which suits much better as AuthenticationProvider than
> UserProvider.
>

I really don't care if users are already implementing SPIs for a beta 
project.  The time to fix the SPIs is *NOW* not after 1.0 Final release. 
  Once the APIs/SPIs go final, we are stuck with them.


> I am not sure if Federation based on metadata on UserModel is good idea.
> I think we already discussed Federation approach and the decision was to
> avoid it due to many reasons. I believe that Authentication SPI and Sync
> SPI were introduced mainly to avoid federation approach...
>

What Sync SPI are you talking about?  We don't have a Sync SPI.  We only 
have a one-way half-baked sync from AuthenticationProvider.AuthUser -> 
UserModel.

>   I am happy with AuthUserProvider

Drawing 3 boxes with lines between them does not an SPI make.

, which delegates "store" to other
> underlying UserProvider, but authentication to one or more
> AuthenticationProviders. This might help to remove the "authentication"
> related code from AuthenticationManager. So something like:
>
>                                           +--------------------+
>                             Store         |                    |
>                              +------------>  JpaUserProvider   |
>                              |            |                    |
>                              |            +--------------------+
>           +------------------+
>           |                  |
>           | AuthUserProvider |            +--------------------+
>           |                  |            |                    |
>           +------------------+            |  LDAPAuthenticationProvider  |
>                              +------------>                    |
>                             Authenticate  +--------------------+
>
>
>
> LDAPUserProvider or PropertiesFileUserProvider doesn't make much sense
> to me as implementors would need to leave almost all methods empty or
> "throw new NotImplementedException()"
>

They wouldn't leave these methods empty.  Take a look at the 
UserProvider methods.  For example

     User getUserById(String id, String realm);
     User getUserByUsername(String username, String realm);
     User getUserByEmail(String email, String realm);
     User getUserByAttribute(String name, String value, String realm);


Would not an LDAPUserProvider do an LDAP query to see if the user 
exists, then import the user into local UserProvider storage, then 
return that object?

UserProvider.verifyCredentials(User user, Credentials... credentials)

If LDAP only verifies password, then do an LDAP query, otherwise 
delegate to the local UserProvider.

If the local User is modified, then wouldn't it be prudent for the 
LDAPUserProvider to wrap return User instances so that it could register 
sync events?  Sync events that would trigger the update to get back to 
the LDAP server eventually?

IMO, UserProvider is the *perfect* place to implement a Sync API.  Out 
of the box, we would have an LDAPUserProvider which you could configure 
in the admin console.  i.e. specify connection parameters and attribute 
mappings.  Anything beyond that common use case would have to be written 
by the user.

> As I said LDAPUserProvider doesn't make much sense to me, so it's not
> needed to configure in 2 places. AFAIK in next KC version, the plan for
> stuff like SMTP and LDAP is to remove it from realm configuration and
> move it to keycloak-server.json . And also the possibility to configure
> stuff from keycloak-server.json in admin console UI.
>

If you move LDAP config to keycloak-server.json then you remove the 
notion of Keycloak being able to have multiple and distinct realms. 
Same goes with SMTP.  You might want to use different email/password for 
email login for different realms.

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

From mposolda at redhat.com  Wed Jul  9 03:02:14 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 09 Jul 2014 09:02:14 +0200
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <53BC7A7F.6060104@redhat.com>
References: <53BC0C8A.4050305@redhat.com>	<854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
	<53BC213C.4040107@redhat.com> <53BC4F3B.7010507@redhat.com>
	<53BC7A7F.6060104@redhat.com>
Message-ID: <53BCE8F6.9020504@redhat.com>

On 9.7.2014 01:10, Bill Burke wrote:
>
>
> On 7/8/2014 4:06 PM, Marek Posolda wrote:
>> On 8.7.2014 18:50, Bill Burke wrote:
>>>> AuthProvider is trying to achieve something different than storing
>>>> users, and the combination of the two is quite flexible.
>>> They serve different purposes? And yet AuthProvider stores users:
>>>
>>> AuthProvider.registerUser()
>>>
>>> and retrieves them:
>>>
>>> AuthProvider.getUser()
>>>
>>> Then you have AuthenticationManager which creates a UserModel, sets up
>>> an AuthenticationLink.  So a developer has to implement registerUser()
>>> as well as the create interfaces of UserProvider.
>> IMO the difference is:
>> - UserProvider is used to implement whole storage SPI and store *all*
>> informations needed for user (roles, socialLinks, requiredRoles etc...)
>>
>> - AuthenticationProvider is used just for password based authentication
>> and hence need just very small subset of UserProvider methods. Note that
>> methods "registerUser" and "updatePassword" are not mandatory to
>> implement if you set "passwordUpdateSupported" for particular
>> AuthenticationProvider to false. Method "registerUser" is used just to
>> send "some" data of UserModel to the Auth store, but it doesn't need to
>> be all (For example with LDAP you store just username, firstName,
>> lastName, email ).
>>
>
> I was under the impression that LDAP schemas often store more than 
> username, first, last, and email. i.e. address, phone number, really 
> any number of claims.  They also can store role mappings as well, 
> correct? 
Yeah, they can store phone, address and also role mappings etc. But they 
can't easily store generic attributes, requiredActions etc.
> So if a user has all those things in LDAP *AND* they want to 
> authenticate through LDAP, what do they do?
I think that's the idea behind Sync SPI, which doesn't yet exist, but is 
planned for next version. This will allow one-way or two-way sync of all 
the possible stuff including roles between Keycloak and external store 
like LDAP. More info in JIRA https://issues.jboss.org/browse/KEYCLOAK-373
>
> The same could be said of RDBMS too.
>
>> The point is, that AuthenticationProvider is really easy to implement as
>> it doesn't need to store all Keycloak data related to user.
>
> But that is not currently how you use AuthenticationProvider.
>
> If the user is not already stored in a Keycloak UserModel, then 
> AuthenticationProvider.getUser() must be implemented.  Otherwise 
> INVALID_USER is returned.
>
>
> Besides.  UserProvider is just as easy to implement.
>
>> See
>> PropertiesAuthenticationProvider from our examples. And note that we
>> already have community members, who implement their own Authentication
>> providers. IMO LDAP, Properties file, or legacy database are classic
>> example, which suits much better as AuthenticationProvider than
>> UserProvider.
>>
>
> I really don't care if users are already implementing SPIs for a beta 
> project.  The time to fix the SPIs is *NOW* not after 1.0 Final 
> release.  Once the APIs/SPIs go final, we are stuck with them.
>
>
>> I am not sure if Federation based on metadata on UserModel is good idea.
>> I think we already discussed Federation approach and the decision was to
>> avoid it due to many reasons. I believe that Authentication SPI and Sync
>> SPI were introduced mainly to avoid federation approach...
>>
>
> What Sync SPI are you talking about?  We don't have a Sync SPI. We 
> only have a one-way half-baked sync from 
> AuthenticationProvider.AuthUser -> UserModel.
>
>>   I am happy with AuthUserProvider
>
> Drawing 3 boxes with lines between them does not an SPI make.
>
> , which delegates "store" to other
>> underlying UserProvider, but authentication to one or more
>> AuthenticationProviders. This might help to remove the "authentication"
>> related code from AuthenticationManager. So something like:
>>
>>                                           +--------------------+
>>                             Store         |                    |
>>                              +------------> JpaUserProvider   |
>>                              |            |                    |
>>                              |            +--------------------+
>>           +------------------+
>>           |                  |
>>           | AuthUserProvider |            +--------------------+
>>           |                  |            |                    |
>>           +------------------+            | 
>> LDAPAuthenticationProvider  |
>> +------------>                    |
>>                             Authenticate  +--------------------+
>>
>>
>>
>> LDAPUserProvider or PropertiesFileUserProvider doesn't make much sense
>> to me as implementors would need to leave almost all methods empty or
>> "throw new NotImplementedException()"
>>
>
> They wouldn't leave these methods empty.  Take a look at the 
> UserProvider methods.  For example
>
>     User getUserById(String id, String realm);
>     User getUserByUsername(String username, String realm);
>     User getUserByEmail(String email, String realm);
>     User getUserByAttribute(String name, String value, String realm);
>
>
> Would not an LDAPUserProvider do an LDAP query to see if the user 
> exists, then import the user into local UserProvider storage, then 
> return that object?
>
> UserProvider.verifyCredentials(User user, Credentials... credentials)
AFAIR many SSO servers like CAS allow easy way for users to plug their 
authentication mechanism. If only way to do this in Keycloak is to 
implement whole UserProvider interface, it looks a bit like overhead to 
me. For authentication purposes only, people need just to implement 
"getUserByUsername" and eventually "getUserByEmail", but for example 
they don't need "getUserById"or "getUserBytAttribute"
>
> If LDAP only verifies password, then do an LDAP query, otherwise 
> delegate to the local UserProvider.
>
> If the local User is modified, then wouldn't it be prudent for the 
> LDAPUserProvider to wrap return User instances so that it could 
> register sync events?  Sync events that would trigger the update to 
> get back to the LDAP server eventually?
>
> IMO, UserProvider is the *perfect* place to implement a Sync API. Out 
> of the box, we would have an LDAPUserProvider which you could 
> configure in the admin console.  i.e. specify connection parameters 
> and attribute mappings.  Anything beyond that common use case would 
> have to be written by the user.
I agree that UserProvider is good place to call authentication or 
register sync events. Just not sure if it's good to mandate people to 
implement whole UserProvider interface if they want just subset of it 
(like only authentication related methods)...
>
>> As I said LDAPUserProvider doesn't make much sense to me, so it's not
>> needed to configure in 2 places. AFAIK in next KC version, the plan for
>> stuff like SMTP and LDAP is to remove it from realm configuration and
>> move it to keycloak-server.json . And also the possibility to configure
>> stuff from keycloak-server.json in admin console UI.
>>
>
> If you move LDAP config to keycloak-server.json then you remove the 
> notion of Keycloak being able to have multiple and distinct realms. 
> Same goes with SMTP.  You might want to use different email/password 
> for email login for different realms.
>
I think the plan here is to have something like "datasources" . 
Basically you can have configurations like "LDAPConfig1" or 
"SMTPConfig1" at keycloak-server.json level and then each realm can 
point just to this name. This will allow that 2 realms can share same 
SMTP/LDAP configuration without repeating stuff, but also it will still 
be possibility to use different configuration by each realm if they want to.

Marek

From stian at redhat.com  Wed Jul  9 06:00:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 9 Jul 2014 06:00:40 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BC26FB.6010603@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
Message-ID: <553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>

Okay, this all hybrid stuff ended up taking more time and becoming more complex than I hoped. There's also still work to be done, and even once that's completed there'd still be more to do. 

I think the correct path forward is to:

1. Recover the JPA model provider
2. Branch the Hybrid model provider
3. Delete the Hybrid model provider from master

Then we can consider what changes if any to do to the model. I'd like to keep the Hybrid model provider in a branch for a while as there are some things in there that may be useful.

A few things that we should consider include:

* Can we reduce the need to update database schemas in the future? I think by cleaning up the entities, and also replacing a lot of columns with attributes we can. For example adding an additional config field to RealmModel shouldn't require us updating the database schema
* If we need to update database schemas how do we do this? Export/import would work for realms, but not for users I think (users would just require a too big downtime if there's millions)
* Do we want to store sessions in memory?
* Cache deals with realms well, but does this work for users or do we just need to make sure loading users from the database performs well?
* With regards to the above I was wondering if we could prevent loading users from cache/db to refresh a token, or to logout a user. If a user is deleted or disabled the session should be deleted, so the only reason I can see to check this is if role mappings have changed, and we could add a dirtyRoles flag to the session for this. Basically dirtyRoles is set to true on all users sessions whenever role-mappings are updated, we would then reload the user/role-mappings on refresh tokens only if dirtyRoles is true.. This would result in us only having to load the user from db once for a "session", and hence there shouldn't really be a need to cache it.
* Do we want to be able to store realms and users separately?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 6:14:35 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> On 7/8/2014 12:01 PM, Stian Thorgersen wrote:
> > I thought we where at an agreement with splitting the model. If that's not
> > the case, and to be able to actually do a release sometime soon, I propose
> > we just revert back to how it was before.
> >
> 
> I did not know you were going to write a completely new persistence
> abstraction underneath our existing persistence abstraction.  I thought
> the existing Model interfaces were going to be retained/refactored and
> you were just going to split out how UserModel, Realm, and UserSessions
> were looked up.
> 
> > For argument sake the benefits for this split include:
> >
> > * Users are what we need to federate, this split makes that a lot simpler
> > IMO
> > * Users are what people may want to store in their own schema, again this
> > makes it a lot simpler IMO
> > * Can store different things in different store types. For example realms
> > in a json file, users in a relational database and sessions in a in-mem
> > data-grid
> > * Realms store can be changed if we need to. Relative quick and easy to
> > export/import to update.
> > * Users store shouldn't be changed frequently. Updating a database with 20
> > million entries is non-trivial
> 
> All you did to improve the 20 million use case was remove secondary key
> constraints from UserEntity and UserRoleMappingEntity, which could have
> been done in the existing model.
> 
> > * Model was getting pretty big and complex, with loads of tables. Splitting
> > makes it simpler IMO
> >
> 
> Bah! our data model is not complex!
> 
> Summary of my perspective
> 
> * Model API was written so that the implementation details of storage
> wouldn't be exposed to the service layer.  So, if we retired the Model
> API in favor of using the Hybrid API, the service layer would be dealing
> with user ids, role ids, realm ids, client ids, instead of UserModel,
> RoleModel, RealmModel, and ClientModel.
> * The Adapter classes existed to bridge between the Model API and the
> persistence API.  I think you lost that notion in the Hybrid model as it
> is completely String ID based.
> * The line between AuthentcationProvider and UserProvider is now blurred
> and confusing as they both provide a mechanism to create and look up
> users.  I'm not even sure you could have a LDAP store that is both a
> UserProvider and AuthenticationProvider.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed Jul  9 09:33:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 09 Jul 2014 09:33:48 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<2120047377.5669432.1404830121253.JavaMail.zimbra@redhat.com>
	<53BC059A.8050405@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
Message-ID: <53BD44BC.1020307@redhat.com>



On 7/9/2014 6:00 AM, Stian Thorgersen wrote:
> Okay, this all hybrid stuff ended up taking more time and becoming more complex than I hoped. There's also still work to be done, and even once that's completed there'd still be more to do.
>
> I think the correct path forward is to:
>
> 1. Recover the JPA model provider

We should.  Is that hard to do?

> 2. Branch the Hybrid model provider
> 3. Delete the Hybrid model provider from master
>
> Then we can consider what changes if any to do to the model. I'd like to keep the Hybrid model provider in a branch for a while as there are some things in there that may be useful.
>

Are you sure?  After thinking about things overnight, there's a lot of 
things hybrid model solved.  What freaked me out was that I thought the 
Model API was just going to be refactored and the ModelProvider split 
into RealmProvider, UserProvider, and UserSessionProvider.

> A few things that we should consider include:
>
> * Can we reduce the need to update database schemas in the future? I think by cleaning up the entities, and also replacing a lot of columns with attributes we can. For example adding an additional config field to RealmModel shouldn't require us updating the database schema

Your hybrid implementation made me realize how important this will be to 
do across the board for Realm, Apps, Users, etc.  But this should be a 
storage implementation detail, right?  And not part of the Model API? 
Please?  :)

i.e. the brute force settings could be stored as attributes, but the 
model API would still expose them as getter methods.  I hate doing 
things like  map.get("maxFailures") vs. realm.getMaxfailures().  Having 
actual methods in the model api makes refactoring much much easier too.


> * If we need to update database schemas how do we do this? Export/import would work for realms, but not for users I think (users would just require a too big downtime if there's millions)

If we change, for instance, how user "required actions" are stored, 
wouldn't we have to write a migration script anyways?  IIRC, adding 
tables or altering a table to add a column isn't such a big deal.  What 
is a big deal is removing a column.

Maybe we should just provide migration scripts in between releases that 
require them?

> * Do we want to store sessions in memory?

Don't we need both persistence and in-memory storage for sessions?  For 
1.0 we're not going to test clustering configurations, but, shouldn't it 
still be possible to cluster Keycloak if the cache is shut off and 
persistence session implementation is used?

> * Cache deals with realms well, but does this work for users or do we just need to make sure loading users from the database performs well?

It works for users.

> * With regards to the above I was wondering if we could prevent loading users from cache/db to refresh a token, or to logout a user. If a user is deleted or disabled the session should be deleted, so the only reason I can see to check this is if role mappings have changed, and we could add a dirtyRoles flag to the session for this. Basically dirtyRoles is set to true on all users sessions whenever role-mappings are updated, we would then reload the user/role-mappings on refresh tokens only if dirtyRoles is true.. This would result in us only having to load the user from db once for a "session", and hence there shouldn't really be a need to cache it.

The cache implementation handles grantRole() by invalidating the user in 
the cache.  It doesn't handle role removal.   But it does lookup the 
role to build the role mapping list.

     @Override
     public Set<RoleModel> getRoleMappings() {
         if (updated != null) return updated.getRoleMappings();
         Set<RoleModel> roles = new HashSet<RoleModel>();
         for (String id : cached.getRoleMappings()) {
             roles.add(cacheSession.getRoleById(id, realm));

         }
         return roles;
     }



Maybe it could be as easy as just invalidating the user and delegating 
to the persistence model if the role from the role mapping doesn't exist?

> * Do we want to be able to store realms and users separately?
>

I don't know.  We need a sync API architecture to be able to support all 
keycloak features.  This means we need to be able to store user metadata 
for each user.

These steps should be taken IMO:

* bring back JPA model
* Retire Hybrid....BUT...ARE YOU SURE?!!!  You usually make better 
decisions than me...
* Split Model API and JPA/Mongo impls into RealmProvider, UserProvider, 
and UserSessionProvider.
* Keep Hybrid in codebase until we're done with ModelProvider refactoring
* Move Hybrid to branch
* Change JPA implementation to be more generic.  Attribute based for 
many settings.
* Rethink AuthenticationProvider SPI. Users really want to be able to 
delegate to their own database or LDAP storage and we need to provide 
better flexibility.

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

From bburke at redhat.com  Wed Jul  9 09:45:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 09 Jul 2014 09:45:10 -0400
Subject: [keycloak-dev] How would you handle an external user store?
In-Reply-To: <53BCE8F6.9020504@redhat.com>
References: <53BC0C8A.4050305@redhat.com>	<854455659.5731507.1404834132880.JavaMail.zimbra@redhat.com>
	<53BC213C.4040107@redhat.com> <53BC4F3B.7010507@redhat.com>
	<53BC7A7F.6060104@redhat.com> <53BCE8F6.9020504@redhat.com>
Message-ID: <53BD4766.1050801@redhat.com>



On 7/9/2014 3:02 AM, Marek Posolda wrote:
>> UserProvider.verifyCredentials(User user, Credentials... credentials)
> AFAIR many SSO servers like CAS allow easy way for users to plug their
> authentication mechanism. If only way to do this in Keycloak is to
> implement whole UserProvider interface, it looks a bit like overhead to
> me. For authentication purposes only, people need just to implement
> "getUserByUsername" and eventually "getUserByEmail", but for example
> they don't need "getUserById"or "getUserBytAttribute"

Provide a base class like UserProviderDelegate.  Default implementation 
delegates to local UserProvider storage for each UserProvider method. 
Our default LDAP impl overrides getUserByUsername, getUserByEmail, and 
verifyCredentials.  addUser() would eventually be overriden to work with 
the Sync API.


>>
>> If LDAP only verifies password, then do an LDAP query, otherwise
>> delegate to the local UserProvider.
>>
>> If the local User is modified, then wouldn't it be prudent for the
>> LDAPUserProvider to wrap return User instances so that it could
>> register sync events?  Sync events that would trigger the update to
>> get back to the LDAP server eventually?
>>
>> IMO, UserProvider is the *perfect* place to implement a Sync API. Out
>> of the box, we would have an LDAPUserProvider which you could
>> configure in the admin console.  i.e. specify connection parameters
>> and attribute mappings.  Anything beyond that common use case would
>> have to be written by the user.
> I agree that UserProvider is good place to call authentication or
> register sync events. Just not sure if it's good to mandate people to
> implement whole UserProvider interface if they want just subset of it
> (like only authentication related methods)...

Picketlink IDM API separates credential storage and security metamodel. 
  AuthenticationProvider mixes these concerns.  From reading our user 
list, it seems that users want to delegate user+credential storage.  I 
didn't see any questions regarding just credential storage.

AuthenticationProvider also doesn't provide a means for Keycloak to 
manage LDAP users.  The user actually has to log in once before Keycloak 
can manage that user.

>>
>>> As I said LDAPUserProvider doesn't make much sense to me, so it's not
>>> needed to configure in 2 places. AFAIK in next KC version, the plan for
>>> stuff like SMTP and LDAP is to remove it from realm configuration and
>>> move it to keycloak-server.json . And also the possibility to configure
>>> stuff from keycloak-server.json in admin console UI.
>>>
>>
>> If you move LDAP config to keycloak-server.json then you remove the
>> notion of Keycloak being able to have multiple and distinct realms.
>> Same goes with SMTP.  You might want to use different email/password
>> for email login for different realms.
>>
> I think the plan here is to have something like "datasources" .
> Basically you can have configurations like "LDAPConfig1" or
> "SMTPConfig1" at keycloak-server.json level and then each realm can
> point just to this name. This will allow that 2 realms can share same
> SMTP/LDAP configuration without repeating stuff, but also it will still
> be possibility to use different configuration by each realm if they want
> to.
>

Not convinced that ldap or smtp config would ever be shared between 
different realms.  I think the usual deployment will be one realm with 
the master realm disabled.

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

From stian at redhat.com  Wed Jul  9 10:19:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 9 Jul 2014 10:19:28 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BD44BC.1020307@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
Message-ID: <2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>

Oki, so how about:

1. Recover the JPA model provider, and set that as the default
2. Retire, but keep Hybrid model around until we're done
3. Extract user sessions from ModelProvider into UserSessionProvider, and add mem/jpa/mongo implementations
4. Review what we have, and make sure everyone is happy with the approach taken for UserSessionProvider
5. Extract users and role-mappings from ModelProvider into UserProvider, and add jpa/mongo implementations
6. Again, let's review and make sure everyone is happy
7. Rename ModelProvider to RealmProvider
8. Consider refactorings to the models (such as using attributes instead of columns)

I also think we'll need a EntityManagerProvider and a MongoClientProvider to make sure we have a single connection/transaction per-request. 

For 1.0.final I think we could introduce a limitation that we'll only allow one store at a time, so we don't have to deal with multiple-transactions (or 2pc).

More comments inline

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 9 July, 2014 2:33:48 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> On 7/9/2014 6:00 AM, Stian Thorgersen wrote:
> > Okay, this all hybrid stuff ended up taking more time and becoming more
> > complex than I hoped. There's also still work to be done, and even once
> > that's completed there'd still be more to do.
> >
> > I think the correct path forward is to:
> >
> > 1. Recover the JPA model provider
> 
> We should.  Is that hard to do?

Nopes, already have it in a branch just need to merge it ;)

> 
> > 2. Branch the Hybrid model provider
> > 3. Delete the Hybrid model provider from master
> >
> > Then we can consider what changes if any to do to the model. I'd like to
> > keep the Hybrid model provider in a branch for a while as there are some
> > things in there that may be useful.
> >
> 
> Are you sure?  After thinking about things overnight, there's a lot of
> things hybrid model solved.  What freaked me out was that I thought the
> Model API was just going to be refactored and the ModelProvider split
> into RealmProvider, UserProvider, and UserSessionProvider.

Yes - I attacked this the wrong way around, and should have done it in the way I've suggested above.

> 
> > A few things that we should consider include:
> >
> > * Can we reduce the need to update database schemas in the future? I think
> > by cleaning up the entities, and also replacing a lot of columns with
> > attributes we can. For example adding an additional config field to
> > RealmModel shouldn't require us updating the database schema
> 
> Your hybrid implementation made me realize how important this will be to
> do across the board for Realm, Apps, Users, etc.  But this should be a
> storage implementation detail, right?  And not part of the Model API?
> Please?  :)
> 
> i.e. the brute force settings could be stored as attributes, but the
> model API would still expose them as getter methods.  I hate doing
> things like  map.get("maxFailures") vs. realm.getMaxfailures().  Having
> actual methods in the model api makes refactoring much much easier too.

How about:

  int maxFailures = map.containsKey("maxFailures") ? Integer.parseInt(map.get("maxFailures)) : 0;

Just kidding, it would be insane to do that in services ;)

> 
> 
> > * If we need to update database schemas how do we do this? Export/import
> > would work for realms, but not for users I think (users would just require
> > a too big downtime if there's millions)
> 
> If we change, for instance, how user "required actions" are stored,
> wouldn't we have to write a migration script anyways?  IIRC, adding
> tables or altering a table to add a column isn't such a big deal.  What
> is a big deal is removing a column.
> 
> Maybe we should just provide migration scripts in between releases that
> require them?

If stored as plain attributes, Keycloak could rewrite them on a live server.

Migration scripts may be the only feasible way to go, but I'm worried about the complexity of writing and testing these scripts for all the different DB variations, including Mongo.

> 
> > * Do we want to store sessions in memory?
> 
> Don't we need both persistence and in-memory storage for sessions?  For
> 1.0 we're not going to test clustering configurations, but, shouldn't it
> still be possible to cluster Keycloak if the cache is shut off and
> persistence session implementation is used?

Sure, let's do both. In the future we could consider Infinispan, or something similar.

> 
> > * Cache deals with realms well, but does this work for users or do we just
> > need to make sure loading users from the database performs well?
> 
> It works for users.

My point was, if we can tweak things so we only have to retrieve users from the database on login do we even need to cache users? It would make the overhead of a distributed cache significantly smaller, as admins are not going to update realms and such frequently, but if you have a large number of users they'll be changing passwords, profiles, etc, all the time.

I'm thinking:

* Realms - are own cache with the http invalidation messages
* Sessions - Infinispan
* Users - no cache, we can retrieve the info we need from tokens and session

> 
> > * With regards to the above I was wondering if we could prevent loading
> > users from cache/db to refresh a token, or to logout a user. If a user is
> > deleted or disabled the session should be deleted, so the only reason I
> > can see to check this is if role mappings have changed, and we could add a
> > dirtyRoles flag to the session for this. Basically dirtyRoles is set to
> > true on all users sessions whenever role-mappings are updated, we would
> > then reload the user/role-mappings on refresh tokens only if dirtyRoles is
> > true.. This would result in us only having to load the user from db once
> > for a "session", and hence there shouldn't really be a need to cache it.
> 
> The cache implementation handles grantRole() by invalidating the user in
> the cache.  It doesn't handle role removal.   But it does lookup the
> role to build the role mapping list.
> 
>      @Override
>      public Set<RoleModel> getRoleMappings() {
>          if (updated != null) return updated.getRoleMappings();
>          Set<RoleModel> roles = new HashSet<RoleModel>();
>          for (String id : cached.getRoleMappings()) {
>              roles.add(cacheSession.getRoleById(id, realm));
> 
>          }
>          return roles;
>      }
> 
> 
> 
> Maybe it could be as easy as just invalidating the user and delegating
> to the persistence model if the role from the role mapping doesn't exist?
> 
> > * Do we want to be able to store realms and users separately?
> >
> 
> I don't know.  We need a sync API architecture to be able to support all
> keycloak features.  This means we need to be able to store user metadata
> for each user.
> 
> These steps should be taken IMO:
> 
> * bring back JPA model
> * Retire Hybrid....BUT...ARE YOU SURE?!!!  You usually make better
> decisions than me...
> * Split Model API and JPA/Mongo impls into RealmProvider, UserProvider,
> and UserSessionProvider.
> * Keep Hybrid in codebase until we're done with ModelProvider refactoring
> * Move Hybrid to branch
> * Change JPA implementation to be more generic.  Attribute based for
> many settings.
> * Rethink AuthenticationProvider SPI. Users really want to be able to
> delegate to their own database or LDAP storage and we need to provide
> better flexibility.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Jul  9 11:24:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 9 Jul 2014 11:24:45 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com> <53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
Message-ID: <1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>

I've reverted the JPA model provider, which is now the default in master.

I also started a user session provider and changed the mem session provider from hybrid to implement this instead. Have a look at it at:

  https://github.com/stianst/keycloak/tree/user-session-provider

Specifically at:

  https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java

How simple this was pretty much verifies to me that the approach I took previously was utterly wrong!

Let's have a Hangout tomorrow?

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 9 July, 2014 3:19:28 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> Oki, so how about:
> 
> 1. Recover the JPA model provider, and set that as the default
> 2. Retire, but keep Hybrid model around until we're done
> 3. Extract user sessions from ModelProvider into UserSessionProvider, and add
> mem/jpa/mongo implementations
> 4. Review what we have, and make sure everyone is happy with the approach
> taken for UserSessionProvider
> 5. Extract users and role-mappings from ModelProvider into UserProvider, and
> add jpa/mongo implementations
> 6. Again, let's review and make sure everyone is happy
> 7. Rename ModelProvider to RealmProvider
> 8. Consider refactorings to the models (such as using attributes instead of
> columns)
> 
> I also think we'll need a EntityManagerProvider and a MongoClientProvider to
> make sure we have a single connection/transaction per-request.
> 
> For 1.0.final I think we could introduce a limitation that we'll only allow
> one store at a time, so we don't have to deal with multiple-transactions (or
> 2pc).
> 
> More comments inline
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 9 July, 2014 2:33:48 PM
> > Subject: Re: [keycloak-dev] triple abstraction?
> > 
> > 
> > 
> > On 7/9/2014 6:00 AM, Stian Thorgersen wrote:
> > > Okay, this all hybrid stuff ended up taking more time and becoming more
> > > complex than I hoped. There's also still work to be done, and even once
> > > that's completed there'd still be more to do.
> > >
> > > I think the correct path forward is to:
> > >
> > > 1. Recover the JPA model provider
> > 
> > We should.  Is that hard to do?
> 
> Nopes, already have it in a branch just need to merge it ;)
> 
> > 
> > > 2. Branch the Hybrid model provider
> > > 3. Delete the Hybrid model provider from master
> > >
> > > Then we can consider what changes if any to do to the model. I'd like to
> > > keep the Hybrid model provider in a branch for a while as there are some
> > > things in there that may be useful.
> > >
> > 
> > Are you sure?  After thinking about things overnight, there's a lot of
> > things hybrid model solved.  What freaked me out was that I thought the
> > Model API was just going to be refactored and the ModelProvider split
> > into RealmProvider, UserProvider, and UserSessionProvider.
> 
> Yes - I attacked this the wrong way around, and should have done it in the
> way I've suggested above.
> 
> > 
> > > A few things that we should consider include:
> > >
> > > * Can we reduce the need to update database schemas in the future? I
> > > think
> > > by cleaning up the entities, and also replacing a lot of columns with
> > > attributes we can. For example adding an additional config field to
> > > RealmModel shouldn't require us updating the database schema
> > 
> > Your hybrid implementation made me realize how important this will be to
> > do across the board for Realm, Apps, Users, etc.  But this should be a
> > storage implementation detail, right?  And not part of the Model API?
> > Please?  :)
> > 
> > i.e. the brute force settings could be stored as attributes, but the
> > model API would still expose them as getter methods.  I hate doing
> > things like  map.get("maxFailures") vs. realm.getMaxfailures().  Having
> > actual methods in the model api makes refactoring much much easier too.
> 
> How about:
> 
>   int maxFailures = map.containsKey("maxFailures") ?
>   Integer.parseInt(map.get("maxFailures)) : 0;
> 
> Just kidding, it would be insane to do that in services ;)
> 
> > 
> > 
> > > * If we need to update database schemas how do we do this? Export/import
> > > would work for realms, but not for users I think (users would just
> > > require
> > > a too big downtime if there's millions)
> > 
> > If we change, for instance, how user "required actions" are stored,
> > wouldn't we have to write a migration script anyways?  IIRC, adding
> > tables or altering a table to add a column isn't such a big deal.  What
> > is a big deal is removing a column.
> > 
> > Maybe we should just provide migration scripts in between releases that
> > require them?
> 
> If stored as plain attributes, Keycloak could rewrite them on a live server.
> 
> Migration scripts may be the only feasible way to go, but I'm worried about
> the complexity of writing and testing these scripts for all the different DB
> variations, including Mongo.
> 
> > 
> > > * Do we want to store sessions in memory?
> > 
> > Don't we need both persistence and in-memory storage for sessions?  For
> > 1.0 we're not going to test clustering configurations, but, shouldn't it
> > still be possible to cluster Keycloak if the cache is shut off and
> > persistence session implementation is used?
> 
> Sure, let's do both. In the future we could consider Infinispan, or something
> similar.
> 
> > 
> > > * Cache deals with realms well, but does this work for users or do we
> > > just
> > > need to make sure loading users from the database performs well?
> > 
> > It works for users.
> 
> My point was, if we can tweak things so we only have to retrieve users from
> the database on login do we even need to cache users? It would make the
> overhead of a distributed cache significantly smaller, as admins are not
> going to update realms and such frequently, but if you have a large number
> of users they'll be changing passwords, profiles, etc, all the time.
> 
> I'm thinking:
> 
> * Realms - are own cache with the http invalidation messages
> * Sessions - Infinispan
> * Users - no cache, we can retrieve the info we need from tokens and session
> 
> > 
> > > * With regards to the above I was wondering if we could prevent loading
> > > users from cache/db to refresh a token, or to logout a user. If a user is
> > > deleted or disabled the session should be deleted, so the only reason I
> > > can see to check this is if role mappings have changed, and we could add
> > > a
> > > dirtyRoles flag to the session for this. Basically dirtyRoles is set to
> > > true on all users sessions whenever role-mappings are updated, we would
> > > then reload the user/role-mappings on refresh tokens only if dirtyRoles
> > > is
> > > true.. This would result in us only having to load the user from db once
> > > for a "session", and hence there shouldn't really be a need to cache it.
> > 
> > The cache implementation handles grantRole() by invalidating the user in
> > the cache.  It doesn't handle role removal.   But it does lookup the
> > role to build the role mapping list.
> > 
> >      @Override
> >      public Set<RoleModel> getRoleMappings() {
> >          if (updated != null) return updated.getRoleMappings();
> >          Set<RoleModel> roles = new HashSet<RoleModel>();
> >          for (String id : cached.getRoleMappings()) {
> >              roles.add(cacheSession.getRoleById(id, realm));
> > 
> >          }
> >          return roles;
> >      }
> > 
> > 
> > 
> > Maybe it could be as easy as just invalidating the user and delegating
> > to the persistence model if the role from the role mapping doesn't exist?
> > 
> > > * Do we want to be able to store realms and users separately?
> > >
> > 
> > I don't know.  We need a sync API architecture to be able to support all
> > keycloak features.  This means we need to be able to store user metadata
> > for each user.
> > 
> > These steps should be taken IMO:
> > 
> > * bring back JPA model
> > * Retire Hybrid....BUT...ARE YOU SURE?!!!  You usually make better
> > decisions than me...
> > * Split Model API and JPA/Mongo impls into RealmProvider, UserProvider,
> > and UserSessionProvider.
> > * Keep Hybrid in codebase until we're done with ModelProvider refactoring
> > * Move Hybrid to branch
> > * Change JPA implementation to be more generic.  Attribute based for
> > many settings.
> > * Rethink AuthenticationProvider SPI. Users really want to be able to
> > delegate to their own database or LDAP storage and we need to provide
> > better flexibility.
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Jul  9 11:28:55 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 09 Jul 2014 11:28:55 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<81936893.5709561.1404832585002.JavaMail.zimbra@redhat.com>
	<53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
Message-ID: <53BD5FB7.8050203@redhat.com>



On 7/9/2014 10:19 AM, Stian Thorgersen wrote:
> Oki, so how about:
>
> 1. Recover the JPA model provider, and set that as the default
> 2. Retire, but keep Hybrid model around until we're done
> 3. Extract user sessions from ModelProvider into UserSessionProvider, and add mem/jpa/mongo implementations
> 4. Review what we have, and make sure everyone is happy with the approach taken for UserSessionProvider
> 5. Extract users and role-mappings from ModelProvider into UserProvider, and add jpa/mongo implementations
> 6. Again, let's review and make sure everyone is happy
> 7. Rename ModelProvider to RealmProvider
> 8. Consider refactorings to the models (such as using attributes instead of columns)
>

9. We need to rethink AuthenticationProvider.

I'm willing to do any/all of that work.  It overlaps with cache changes 
I'd need to make.  I'm kind of in a holding pattern anyways until all 
the above is resolved.

> I also think we'll need a EntityManagerProvider and a MongoClientProvider to make sure we have a single connection/transaction per-request.
>
> For 1.0.final I think we could introduce a limitation that we'll only allow one store at a time, so we don't have to deal with multiple-transactions (or 2pc).
>

We will have 2pc problems when we eventually have a distributed cache.


More comments inline.

>>
>>> * Cache deals with realms well, but does this work for users or do we just
>>> need to make sure loading users from the database performs well?
>>
>> It works for users.
>
> My point was, if we can tweak things so we only have to retrieve users from the database on login do we even need to cache users? It would make the overhead of a distributed cache significantly smaller, as admins are not going to update realms and such frequently, but if you have a large number of users they'll be changing passwords, profiles, etc, all the time.
>

IMO, users will usually be static too.  Not as static as realm metadata, 
but they won't change daily, even weekly.

The only overhead of a distributed cache for users is when a user is 
updated.  And the only overhead is a simple invalidation message to 
invalidate the user.

> I'm thinking:
>
> * Realms - are own cache with the http invalidation messages
> * Sessions - Infinispan
> * Users - no cache, we can retrieve the info we need from tokens and session
>

User cache is very useful, even with millions of users and a much 
smaller cache.  Between processLogin, accessCodeToToken, refreshToken, 
UserModel is needed for all those requests.  So caching an active user 
is not a waste, especially if access code timeouts are much shorter than 
average active session times.

FYI, beside checking session logout/timeout, refreshToken also exists to 
get the latest and greatest scope and role mappings.

Also, IMO, we could probably cache 100s of thousands of users maybe 
millions on average machines.  1 million users at 1k per user is 1 
gigabyte ram.  I'm not convinced that millions of users will be the norm 
for keycloak.


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

From bburke at redhat.com  Wed Jul  9 11:35:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 09 Jul 2014 11:35:47 -0400
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com> <53BC0E3F.4010009@redhat.com>
	<214119139.5729636.1404833942249.JavaMail.zimbra@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
	<1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>
Message-ID: <53BD6153.3070406@redhat.com>



On 7/9/2014 11:24 AM, Stian Thorgersen wrote:
> I've reverted the JPA model provider, which is now the default in master.
>
> I also started a user session provider and changed the mem session provider from hybrid to implement this instead. Have a look at it at:
>
>    https://github.com/stianst/keycloak/tree/user-session-provider
>
> Specifically at:
>
>    https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java
>
> How simple this was pretty much verifies to me that the approach I took previously was utterly wrong!
>

Looks good so far.  Let me know if I can help with anything as again, 
I"m kind of in a holding pattern.

Bill

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

From bburke at redhat.com  Wed Jul  9 17:37:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 09 Jul 2014 17:37:38 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
Message-ID: <53BDB622.7060608@redhat.com>

To expand on our discussion around AuthenticationProvider.   With the 
currrent implementation of AuthenticationProvider, Keycloak admin 
console cannot be used to manage external users until the user has 
logged in and a UserModel creation has happened.  We would need to 
duplicate the "import" logic that is within AuthenticationManager 
wherever UserProvider.getUserByXXXX() is invoked.  Not only that, but 
role mappings and other claim data may be contained in external storage. 
  The authentictionProvider interface is inadequate for these scenarios.


My thinking is that for federation and sync would come in three flavors:

* Keycloak storage.  What we currently implement.
* Full external storage.  The app developer will use their own 
persistence model to store and manage users.  In this case, they need to 
fully implement the UserProvider interface.  Handle social links, 
required actions, role mappings etc.
* A sync/import model.  In this case, keycloak is augmenting an existing 
user storage.  This would require partially or fully importing the user 
from the external store into Keycloak UserModel/Provider storage.   The 
import is required so that Keycloak can managed REQUIRED ACTIONS, social 
links, and add additional or manage existing credential types.  We also 
need the import to establish relationships between the user and 
UserSession metadata.  We may also have to handle role mappings within 
Keycloak.  A sync/import model example could be an LDAP store that just 
contains username, email, first/last, and password.  And the admin wants 
to add role mappings and totp.

How would it work?

I think all this should be done through a common UserProvider interface. 
  Initially be able to federate only 1 additional external store as I'm 
worried that there may be the possibility of duplicate user names if you 
allow more than one and you'd need a way at login to pick which one to 
log in from.

UserProviderFactory would specify its feature set:

Query Capabilities:
REGISTRATION
QUERY_BY_USER_ID
QUERY_BY_USERNAME
QUERY_BY_EMAIL
QUERY_BY_ATTRIBUTES

And its supported credential validation:
PASSWORD_VALIDATION
TOTP_VALIDATION
CERT_VALIDATION

And its supported credential storage:
PASSWORD_STORAGE
TOTP_STORAGE
CERT_STORAGE

There would a FederatedUserProvider to manage local and federated storage.

*Locating a user:*

1.  FederatedUserProvider queries local storage first.
2. Check realm to see if federated storage configured
3. Load that provider
4. See if that provider supports query method, if not return null
5. Call query method on provider

Provider performs the following on user location:
6. Do custom query to find user
7. Get a local storage session and create a user within local storage 
importing whatever can be imported.
8. Mark in local user storage which provider loaded it.
9. return the local user

*Required Actions and Credential management*
1. Find provider used to load user
2. Check credential storage options
3. If provider doesn't support credential update/storage, then store in 
local storage


*Authentication*
1. Find user in local storage
2. See if credential is stored in local storage, validate from there if so.
3. If not stored, check provider validation options.  Abort if not supported
4. Invoke on external provider to validate credentials supported by that 
provider


Did I cover everything?








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

From stian at redhat.com  Thu Jul 10 03:19:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 10 Jul 2014 03:19:16 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BD6153.3070406@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<77624686.5749349.1404835306005.JavaMail.zimbra@redhat.com>
	<53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
	<1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>
	<53BD6153.3070406@redhat.com>
Message-ID: <218944943.7119873.1404976756260.JavaMail.zimbra@redhat.com>

Ping me when you're online and we can have a Hangout to divide this work

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 9 July, 2014 4:35:47 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> On 7/9/2014 11:24 AM, Stian Thorgersen wrote:
> > I've reverted the JPA model provider, which is now the default in master.
> >
> > I also started a user session provider and changed the mem session provider
> > from hybrid to implement this instead. Have a look at it at:
> >
> >    https://github.com/stianst/keycloak/tree/user-session-provider
> >
> > Specifically at:
> >
> >    https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java
> >
> > How simple this was pretty much verifies to me that the approach I took
> > previously was utterly wrong!
> >
> 
> Looks good so far.  Let me know if I can help with anything as again,
> I"m kind of in a holding pattern.
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Jul 10 06:43:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 10 Jul 2014 06:43:05 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <218944943.7119873.1404976756260.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com> <53BC26FB.6010603@redhat.com>
	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>
	<53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
	<1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>
	<53BD6153.3070406@redhat.com>
	<218944943.7119873.1404976756260.JavaMail.zimbra@redhat.com>
Message-ID: <1109523685.7222634.1404988985316.JavaMail.zimbra@redhat.com>

A suggestion to how we can split this work:

Stian: Finish the UserSessionProvider (including mem, jpa and mongo implementations). Then I can do the EntityManagerProvider and MongoConnectionProvider, then look at transactions.

Bill: Split the remainder of the ModelProvider into RealmProvider and UserProvider, and at the same time do the cache work.

Marek: Work on import/export to use same representations as admin endpoints.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 10 July, 2014 8:19:16 AM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> Ping me when you're online and we can have a Hangout to divide this work
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 9 July, 2014 4:35:47 PM
> > Subject: Re: [keycloak-dev] triple abstraction?
> > 
> > 
> > 
> > On 7/9/2014 11:24 AM, Stian Thorgersen wrote:
> > > I've reverted the JPA model provider, which is now the default in master.
> > >
> > > I also started a user session provider and changed the mem session
> > > provider
> > > from hybrid to implement this instead. Have a look at it at:
> > >
> > >    https://github.com/stianst/keycloak/tree/user-session-provider
> > >
> > > Specifically at:
> > >
> > >    https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java
> > >
> > > How simple this was pretty much verifies to me that the approach I took
> > > previously was utterly wrong!
> > >
> > 
> > Looks good so far.  Let me know if I can help with anything as again,
> > I"m kind of in a holding pattern.
> > 
> > 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 mposolda at redhat.com  Thu Jul 10 07:41:02 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 10 Jul 2014 13:41:02 +0200
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BDB622.7060608@redhat.com>
References: <53BDB622.7060608@redhat.com>
Message-ID: <53BE7BCE.3000607@redhat.com>

On 9.7.2014 23:37, Bill Burke wrote:
> To expand on our discussion around AuthenticationProvider.   With the
> currrent implementation of AuthenticationProvider, Keycloak admin
> console cannot be used to manage external users until the user has
> logged in and a UserModel creation has happened.  We would need to
> duplicate the "import" logic that is within AuthenticationManager
> wherever UserProvider.getUserByXXXX() is invoked.  Not only that, but
> role mappings and other claim data may be contained in external storage.
>    The authentictionProvider interface is inadequate for these scenarios.
>
>
> My thinking is that for federation and sync would come in three flavors:
>
> * Keycloak storage.  What we currently implement.
> * Full external storage.  The app developer will use their own
> persistence model to store and manage users.  In this case, they need to
> fully implement the UserProvider interface.  Handle social links,
> required actions, role mappings etc.
> * A sync/import model.  In this case, keycloak is augmenting an existing
> user storage.  This would require partially or fully importing the user
> from the external store into Keycloak UserModel/Provider storage.   The
> import is required so that Keycloak can managed REQUIRED ACTIONS, social
> links, and add additional or manage existing credential types.  We also
> need the import to establish relationships between the user and
> UserSession metadata.  We may also have to handle role mappings within
> Keycloak.  A sync/import model example could be an LDAP store that just
> contains username, email, first/last, and password.  And the admin wants
> to add role mappings and totp.
>
> How would it work?
>
> I think all this should be done through a common UserProvider interface.
>    Initially be able to federate only 1 additional external store as I'm
> worried that there may be the possibility of duplicate user names if you
> allow more than one and you'd need a way at login to pick which one to
> log in from.
>
> UserProviderFactory would specify its feature set:
>
> Query Capabilities:
> REGISTRATION
> QUERY_BY_USER_ID
> QUERY_BY_USERNAME
> QUERY_BY_EMAIL
> QUERY_BY_ATTRIBUTES
>
> And its supported credential validation:
> PASSWORD_VALIDATION
> TOTP_VALIDATION
> CERT_VALIDATION
>
> And its supported credential storage:
> PASSWORD_STORAGE
> TOTP_STORAGE
> CERT_STORAGE
>
> There would a FederatedUserProvider to manage local and federated storage.
>
> *Locating a user:*
>
> 1.  FederatedUserProvider queries local storage first.
> 2. Check realm to see if federated storage configured
> 3. Load that provider
> 4. See if that provider supports query method, if not return null
> 5. Call query method on provider
>
> Provider performs the following on user location:
> 6. Do custom query to find user
> 7. Get a local storage session and create a user within local storage
> importing whatever can be imported.
> 8. Mark in local user storage which provider loaded it.
> 9. return the local user
>
> *Required Actions and Credential management*
> 1. Find provider used to load user
> 2. Check credential storage options
> 3. If provider doesn't support credential update/storage, then store in
> local storage
>
>
> *Authentication*
> 1. Find user in local storage
> 2. See if credential is stored in local storage, validate from there if so.
> 3. If not stored, check provider validation options.  Abort if not supported
> 4. Invoke on external provider to validate credentials supported by that
> provider
>
>
> Did I cover everything?
>
How about creating of users? Will be new users added just to local 
storage and not to the "external provider" storage?

Also not sure what's your plan for role mappings? Will be role mappings 
loaded from "external provider" just in case that provider supports role 
mappings? But what if roles from provider doesn't exist in Keycloak?

And finally getUsers(), searchForUser, searchForUserByAttributes in both 
non-paginated and paginated versions?

IMO Federation approach is quite tricky. We already did this in GateIn 
(picketlink 1.X) and had quite bad issues. Especially performance 
issues. For example getUsers() with pagination+sorting is almost 
impossible if you have some users just in "local" store, some users in 
"external" store, and some synced in both. For example if there are 
users "a", "b" in external storage, then users "b", "c" in local storage 
and you call getUsers() you would need to merge them from both storages 
to have correct list with "a", "b" and "c". If you want this with 
pagination+sorting then it's much more tricky... If you want proper 
results, you defacto need to load all users from both stores and sort 
them programmatically, which completely bypasses pagination.

That's why I would prefer "sync" among "federation" approach. In 
shortcut with "sync" approach will be users (and eventually their role 
mappings) synced from external store into Keycloak and most of the 
UserProvider methods would deal just with "local" provider. Only 
exception are authentication related methods, and also "update" methods, 
which will need to update local user and also "external" users. But 
SyncProvider won't need to implement methods like getUsers(), 
searchFor**, getUserBy** etc as all users will be available locally.




In details, I can imagine to have things working this way:

* There will be Sync SPI configured per realm, which will allow to sync 
users from "external store" to Keycloak.

* It will be possible to configure when to sync users. For example it 
can be full sync from LDAP at server startup or triggered from admin 
console. Then some periodic sync (triggered for example once per day).

* I am not sure if we need full sync from Keycloak to "external 
provider" but probably not. Once user, role or user credential will be 
updated in Keycloak, it will be also immediatelly synced to external 
provider (if provider is not read-only).

* It depends on SyncProvider implementation, what user data are synced. 
For example in case of LDAP it will be just email+first,lastName and 
eventually role mappings.

* SyncProvider may also support roles + role mappings from external 
store. SyncProvider will be able to import roles into RealmProvider and 
then particular role mappings into UserProvider.

* Users synced from "external provider" will have link to this provider 
similarly like it's now. In case that provider is read-write, then all 
newly created users in Keycloak will be synced into "external provider" 
immediatelly also with the credential (if syncProvider supports 
particular credential)

I would propose the interface like this to handle both 
sync/authentication (not sure if "SyncProvider" is good name, maybe 
rather "ExternalUserProvider"). I can imagine something like this:


public interface SyncProvider {

   /**
    * Invoked when new user is registered (or added through admin 
console) and just if SyncProvider supports RW_USER
    *
    * @return user with added "link" . Link is filled by external 
provider (for example ID from LDAP)
    */
   UserModel addUser(UserModel user);

   /**
     * Invoked when credential of user is changed and just if: 
SyncProvider is RW_PASSWORD (or RW_TOTP) and user has "link" to provider
     */
   void updateCredential(UserModel user, Credential credential);

  /**
    * Invoked when user has link to externalProvider and particular 
credential is supported.  (Otherwise credential is validated against 
"local" UserProvider)
    */
   boolean validateCredential(UserModel user, Credential credential);

   /**
     * Invoked just when full sync from "external store" to Keycloak is 
requested. Method could be empty if SyncProvider doesn't suppport Roles 
+ Role mappings
     * Not sure if role also needs to have "link" . Probably not.
     */
   List<RoleModel> getRoles();

   /**
    * Invoked just when full sync from "external store" to Keycloak is 
requested. Method could be empty if SyncProvider doesn't support Roles + 
Role mappings
    */
   void updateRole(RoleModel role);

   /**
    * Invoked just when full sync from "external store" to Keycloak is 
requested. It's invoked *after* getAllRoles(), so Keycloak knows roles 
mapped to users
    */
   List<UserModel> getAllUsers();

   /**
    * List features supported by particular provider
    */
   List<Feature> getMetadata();
}

For metadata I can see the list with RW_ROLE, RO_ROLE (If provider 
supports storing of roles and role mappings), RW_USER, RO_USER (If 
provider supports storing of users), RW_PASSWORD, RO_PASSWORD (If 
provider supports passwords), RO_TOTP, RW_TOTP (If provider supports 
storing of totp)

In admin console, it will be possible to configure just subset of 
available features. For example LDAPSyncProvider supports both RO and RW 
for users,roles and passwords, but for RO deployments, people can check 
just RO_ROLE, RO_USER, RO_PASSWORD, which means that LDAP is read-only 
and users will be synced just from LDAP to Keycloak and passwords will 
be verified against LDAP, but nothing will be written back to LDAP.

* Finally we will have WrapperUserProvider, which will delegate most 
method calls to "local" UserProvider. Just methods like verifyCredential 
will be eventually delegated to SyncProvider (if credential is supported 
and user has link to this provider) . Also method "addUser" will add 
user to both "local" and SyncProvider (if RW_USER is configured for 
SyncProvider) etc.

* Currently we support to configure more AuthenticationProviders per 
realm. I agree that this is probably overhead and most deployments will 
be fine with just provider. In case of read-only LDAP, just users synced 
from LDAP will be authenticated against LDAP (they will have "link" to 
LDAP/Picketlink provider). Newly created users won't have link to LDAP 
and hence their password will be validated against "local" UserProvider.

wdyt?

Marek

From mposolda at redhat.com  Thu Jul 10 07:46:32 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 10 Jul 2014 13:46:32 +0200
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <1109523685.7222634.1404988985316.JavaMail.zimbra@redhat.com>
References: <53BBFFBF.7060103@redhat.com>
	<53BC26FB.6010603@redhat.com>	<553196277.6337582.1404900040432.JavaMail.zimbra@redhat.com>	<53BD44BC.1020307@redhat.com>	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>	<1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>	<53BD6153.3070406@redhat.com>	<218944943.7119873.1404976756260.JavaMail.zimbra@redhat.com>
	<1109523685.7222634.1404988985316.JavaMail.zimbra@redhat.com>
Message-ID: <53BE7D18.6030105@redhat.com>

On 10.7.2014 12:43, Stian Thorgersen wrote:
> A suggestion to how we can split this work:
>
> Stian: Finish the UserSessionProvider (including mem, jpa and mongo implementations). Then I can do the EntityManagerProvider and MongoConnectionProvider, then look at transactions.
>
> Bill: Split the remainder of the ModelProvider into RealmProvider and UserProvider, and at the same time do the cache work.
>
> Marek: Work on import/export to use same representations as admin endpoints.
Yeah, I am already working in export/import now. I am using 
ModelProvider atm I believe it won't be hard to refactor later once 
model split is fully finished.

Marek
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 10 July, 2014 8:19:16 AM
>> Subject: Re: [keycloak-dev] triple abstraction?
>>
>> Ping me when you're online and we can have a Hangout to divide this work
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 9 July, 2014 4:35:47 PM
>>> Subject: Re: [keycloak-dev] triple abstraction?
>>>
>>>
>>>
>>> On 7/9/2014 11:24 AM, Stian Thorgersen wrote:
>>>> I've reverted the JPA model provider, which is now the default in master.
>>>>
>>>> I also started a user session provider and changed the mem session
>>>> provider
>>>> from hybrid to implement this instead. Have a look at it at:
>>>>
>>>>     https://github.com/stianst/keycloak/tree/user-session-provider
>>>>
>>>> Specifically at:
>>>>
>>>>     https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java
>>>>
>>>> How simple this was pretty much verifies to me that the approach I took
>>>> previously was utterly wrong!
>>>>
>>> Looks good so far.  Let me know if I can help with anything as again,
>>> I"m kind of in a holding pattern.
>>>
>>> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Jul 10 09:47:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 10 Jul 2014 09:47:27 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BE7BCE.3000607@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
Message-ID: <53BE996F.8080806@redhat.com>



On 7/10/2014 7:41 AM, Marek Posolda wrote:
>
> That's why I would prefer "sync" among "federation" approach.

Which is exactly what I'm proposing.  Except it allows for syncs/imports 
into Keycloak on demand.  You already use AuthenticationProvider in this 
manner!

My impression of a sync model is that Keycloak works with user data in 
local Keycloak storage.  User metadata is imported from external storage 
(either on demand or at startp and periodically synced).  Keycloak can 
manage/modify/augment this imported user data locally.  The changelog is 
obtained from the Sync API and updates sent back to the external storage.


> In
> shortcut with "sync" approach will be users (and eventually their role
> mappings) synced from external store into Keycloak and most of the
> UserProvider methods would deal just with "local" provider. Only
> exception are authentication related methods, and also "update" methods,
> which will need to update local user and also "external" users. But
> SyncProvider won't need to implement methods like getUsers(),
> searchFor**, getUserBy** etc as all users will be available locally.
>

The problem with this approach is that new users don't get imported into 
Keycloak until the sync gets invoked.  Syncing more than once per day, 
or even once per week may not be feasible.  If the external storage does 
not have a changelog, syncing would involve iterating through each and 
every user in external storage and syncing it with the keycloak 
database.  A full sync could take hours.


>
>
>
> In details, I can imagine to have things working this way:
>
> * There will be Sync SPI configured per realm, which will allow to sync
> users from "external store" to Keycloak.
>

+1

> * It will be possible to configure when to sync users. For example it
> can be full sync from LDAP at server startup or triggered from admin
> console. Then some periodic sync (triggered for example once per day).
>

+1

> * I am not sure if we need full sync from Keycloak to "external
> provider" but probably not. Once user, role or user credential will be
> updated in Keycloak, it will be also immediatelly synced to external
> provider (if provider is not read-only).
>

If you don't implement through the UserProvider/UserModel interface then 
you would need an Event model for which the SyncProvider listens to so 
that it can sync the user on demand.

> * It depends on SyncProvider implementation, what user data are synced.
> For example in case of LDAP it will be just email+first,lastName and
> eventually role mappings.
>
> * SyncProvider may also support roles + role mappings from external
> store. SyncProvider will be able to import roles into RealmProvider and
> then particular role mappings into UserProvider.
>
> * Users synced from "external provider" will have link to this provider
> similarly like it's now. In case that provider is read-write, then all
> newly created users in Keycloak will be synced into "external provider"
> immediatelly also with the credential (if syncProvider supports
> particular credential)
>
> I would propose the interface like this to handle both
> sync/authentication (not sure if "SyncProvider" is good name, maybe
> rather "ExternalUserProvider"). I can imagine something like this:
>
>
> public interface SyncProvider {
>

I think your SyncProvider interface is very limiting and even unusable. 
  For example, getAllUsers() is completely unfeasible if there is a 
large user database.


IMO it would be something like this:

public interface ChronJob {

    void invoke(KeycloakSessionFactory factory);
}

ChronJob would be scheduled to run at boot time and/or periodically by 
the admin console.  Periodic and boot time syncs would be implemented 
here.  The sync operation needs to have full control of when 
transactions begin and end so updates/creates/deletes can be executed in 
batches.

On demand syncing would be done through an implementation of 
UserProvider as I proposed earlier.  On-demand syncing is:

* Importing a user on demand
* Updating external storage on demand.

We would also have an event changelog that would be implemented as, or 
act like a persistent JMS Topic.  This event topic shouldn't be used to 
implement on-demand sync, but rather for when the external storage is 
read only.:

interface ChangeEvent {
    enum EventType {
        CREATE, UPDATE, DELETE
    }



    long getTimestamp();
    EventType getEventType();
    String getItemId();
    String getItemType(); // UserModel, RoleModel
}

EventListeners could perform the syncs on demand.  Or, a ChronJob could 
be something like a persistence JMS Topic subscriber and replay change 
events.

We could decide that we don't support user updates for read-only stores. 
  Then, in that case, IMO, we don't need a changelog event queue.




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

From stian at redhat.com  Thu Jul 10 11:51:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 10 Jul 2014 11:51:15 -0400 (EDT)
Subject: [keycloak-dev] triple abstraction?
In-Reply-To: <53BE7D18.6030105@redhat.com>
References: <53BBFFBF.7060103@redhat.com> <53BD44BC.1020307@redhat.com>
	<2060043494.6535411.1404915568052.JavaMail.zimbra@redhat.com>
	<1236685281.6585213.1404919485339.JavaMail.zimbra@redhat.com>
	<53BD6153.3070406@redhat.com>
	<218944943.7119873.1404976756260.JavaMail.zimbra@redhat.com>
	<1109523685.7222634.1404988985316.JavaMail.zimbra@redhat.com>
	<53BE7D18.6030105@redhat.com>
Message-ID: <1193842219.7585762.1405007475544.JavaMail.zimbra@redhat.com>

Added UserProvider with mem implementation. JPA and Mongo coming up next.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 10 July, 2014 12:46:32 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> On 10.7.2014 12:43, Stian Thorgersen wrote:
> > A suggestion to how we can split this work:
> >
> > Stian: Finish the UserSessionProvider (including mem, jpa and mongo
> > implementations). Then I can do the EntityManagerProvider and
> > MongoConnectionProvider, then look at transactions.
> >
> > Bill: Split the remainder of the ModelProvider into RealmProvider and
> > UserProvider, and at the same time do the cache work.
> >
> > Marek: Work on import/export to use same representations as admin
> > endpoints.
> Yeah, I am already working in export/import now. I am using
> ModelProvider atm I believe it won't be hard to refactor later once
> model split is fully finished.
> 
> Marek
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 10 July, 2014 8:19:16 AM
> >> Subject: Re: [keycloak-dev] triple abstraction?
> >>
> >> Ping me when you're online and we can have a Hangout to divide this work
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Stian Thorgersen" <stian at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 9 July, 2014 4:35:47 PM
> >>> Subject: Re: [keycloak-dev] triple abstraction?
> >>>
> >>>
> >>>
> >>> On 7/9/2014 11:24 AM, Stian Thorgersen wrote:
> >>>> I've reverted the JPA model provider, which is now the default in
> >>>> master.
> >>>>
> >>>> I also started a user session provider and changed the mem session
> >>>> provider
> >>>> from hybrid to implement this instead. Have a look at it at:
> >>>>
> >>>>     https://github.com/stianst/keycloak/tree/user-session-provider
> >>>>
> >>>> Specifically at:
> >>>>
> >>>>     https://github.com/stianst/keycloak/blob/user-session-provider/model/api/src/main/java/org/keycloak/models/UserSessionProvider.java
> >>>>
> >>>> How simple this was pretty much verifies to me that the approach I took
> >>>> previously was utterly wrong!
> >>>>
> >>> Looks good so far.  Let me know if I can help with anything as again,
> >>> I"m kind of in a holding pattern.
> >>>
> >>> 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
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Thu Jul 10 15:01:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 10 Jul 2014 21:01:33 +0200
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BE996F.8080806@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com>
Message-ID: <53BEE30D.6050703@redhat.com>

On 10.7.2014 15:47, Bill Burke wrote:
>
>
> On 7/10/2014 7:41 AM, Marek Posolda wrote:
>>
>> That's why I would prefer "sync" among "federation" approach.
>
> Which is exactly what I'm proposing.  Except it allows for 
> syncs/imports into Keycloak on demand.  You already use 
> AuthenticationProvider in this manner!
oops, I though that with AuthProvider you don't like the fact that just 
LDAP users authenticated with Keycloak are available in Keycloak DB;-)


>
> My impression of a sync model is that Keycloak works with user data in 
> local Keycloak storage.  User metadata is imported from external 
> storage (either on demand or at startp and periodically synced).  
> Keycloak can manage/modify/augment this imported user data locally.  
> The changelog is obtained from the Sync API and updates sent back to 
> the external storage.
>
>
>> In
>> shortcut with "sync" approach will be users (and eventually their role
>> mappings) synced from external store into Keycloak and most of the
>> UserProvider methods would deal just with "local" provider. Only
>> exception are authentication related methods, and also "update" methods,
>> which will need to update local user and also "external" users. But
>> SyncProvider won't need to implement methods like getUsers(),
>> searchFor**, getUserBy** etc as all users will be available locally.
>>
>
> The problem with this approach is that new users don't get imported 
> into Keycloak until the sync gets invoked.  Syncing more than once per 
> day, or even once per week may not be feasible.  If the external 
> storage does not have a changelog, syncing would involve iterating 
> through each and every user in external storage and syncing it with 
> the keycloak database.  A full sync could take hours.
Yes, but how to do it differently?
(a) For methods like: UserProvider.getUsers(), UserProvider.searchFor*** 
we can either:
1) retrieve users just from "local" store
2) Federate users and merge them from both "local" and "external" store.

Federation approach (2) has quite bad performance issues (especially 
with pagination+sorting), so I would prefer (1). But this really 
requires full sync from external store into KC IMO.


(b) Then we have methods for retrieve single user:
getUserBy*** --- here we can try to retrieve user from 'local' store and 
fallback to 'external'. In that case, user will be synced on demand to 
KC database (similar approach like AuthenticationProvider), but then we 
have the issue that just those users, who were retrieved from 
externalStore will be available in KC.

I think that we can either:
(1) Federate users from both stores
(2) Temporarily allow that just some users from LDAP are available in KC 
database (those who were authenticated or for which getUserBy*** was called)
(3) Do full sync

I don't know if you see some other solution, but I would say that if we 
want to avoid (1) and (2) we really need to do full sync. So I would 
imagine that if someone configure externalStore, he will also need to 
trigger full sync to KC to have all users added to Keycloak.
>
>
>>
>>
>>
>> In details, I can imagine to have things working this way:
>>
>> * There will be Sync SPI configured per realm, which will allow to sync
>> users from "external store" to Keycloak.
>>
>
> +1
>
>> * It will be possible to configure when to sync users. For example it
>> can be full sync from LDAP at server startup or triggered from admin
>> console. Then some periodic sync (triggered for example once per day).
>>
>
> +1
>
>> * I am not sure if we need full sync from Keycloak to "external
>> provider" but probably not. Once user, role or user credential will be
>> updated in Keycloak, it will be also immediatelly synced to external
>> provider (if provider is not read-only).
>>
>
> If you don't implement through the UserProvider/UserModel interface 
> then you would need an Event model for which the SyncProvider listens 
> to so that it can sync the user on demand.
yep, I think that it works to implement this in UserProvider (and 
RealmProvider for roles). Basically you have something like 
"WrapperUserProvider" and once add/update/delete user is invoked, it 
will perform the operation on "local" UserProvider and then invoke 
particular method on SyncProvider to sync it back into external storage.
>
>> * It depends on SyncProvider implementation, what user data are synced.
>> For example in case of LDAP it will be just email+first,lastName and
>> eventually role mappings.
>>
>> * SyncProvider may also support roles + role mappings from external
>> store. SyncProvider will be able to import roles into RealmProvider and
>> then particular role mappings into UserProvider.
>>
>> * Users synced from "external provider" will have link to this provider
>> similarly like it's now. In case that provider is read-write, then all
>> newly created users in Keycloak will be synced into "external provider"
>> immediatelly also with the credential (if syncProvider supports
>> particular credential)
>>
>> I would propose the interface like this to handle both
>> sync/authentication (not sure if "SyncProvider" is good name, maybe
>> rather "ExternalUserProvider"). I can imagine something like this:
>>
>>
>> public interface SyncProvider {
>>
>
> I think your SyncProvider interface is very limiting and even 
> unusable.  For example, getAllUsers() is completely unfeasible if 
> there is a large user database.
oops, sorry. It's maybe not clear from method name and javadoc that 
"getAllUsers" is intended to be used for sync *from* External storage 
*to* Keycloak. The idea is that "getAllUsers" (or 
"syncAllUsersFromExternalStore" or whatever it's named) will be called 
by admin when he wants full sync from external storage to KC.

IMO sync from Keycloak to external storage is quite easy. We can either 
do it immediatelly when add/update/delete user/role is invoked or we can 
use some event approach you proposed with periodic (or on demand) sync 
of just "dirty" entities. We already have AuditProvider, which could be 
eventually used.

Personally I would prefer to always do sync from KC immediatelly as 
event queue doesn't always work. For example when you have RW LDAP and 
you register new user in Keycloak, you would need to save this user and 
his password immediatelly into external store. Save it somewhere in 
Keycloak database and then clear once Chron Job is triggered doesn't 
work IMO as it would mean that we will need to save passwords in 
plain-text until they are synced into LDAP. Which doesn't make much 
sense IMO.

So for sync from Keycloak to externalStore, I would personally always do 
it immediatelly after operation is performed on 
UserProvider/RealmProvider. It's not so big overhead IMO.

But the main issue is sync from externalStore to Keycloak. We can easily 
add changelog to Keycloak, but we don't have control under external 
storage...

I don't know if LDAP servers support changelog, probably yes but I don't 
think that it's standardized, maybe some LDAP servers support 
"proprietary" way of doing changelog. I can check if some LDAP supports 
this and how it works with them...

But fact is that if externalProvider doesn't support changelog, then how 
to do sync without something like "getAllUsers" (or "syncAllUsers")? I 
know that this is quite overhead, but I really don't see how to do 
"partial" sync from 3rd party provider if it doesn't support changelogs...

Marek
>
>
> IMO it would be something like this:
>
> public interface ChronJob {
>
>    void invoke(KeycloakSessionFactory factory);
> }
>
> ChronJob would be scheduled to run at boot time and/or periodically by 
> the admin console.  Periodic and boot time syncs would be implemented 
> here.  The sync operation needs to have full control of when 
> transactions begin and end so updates/creates/deletes can be executed 
> in batches.
>
> On demand syncing would be done through an implementation of 
> UserProvider as I proposed earlier.  On-demand syncing is:
>
> * Importing a user on demand
> * Updating external storage on demand.
>
> We would also have an event changelog that would be implemented as, or 
> act like a persistent JMS Topic.  This event topic shouldn't be used 
> to implement on-demand sync, but rather for when the external storage 
> is read only.:
>
> interface ChangeEvent {
>    enum EventType {
>        CREATE, UPDATE, DELETE
>    }
>
>
>
>    long getTimestamp();
>    EventType getEventType();
>    String getItemId();
>    String getItemType(); // UserModel, RoleModel
> }
>
> EventListeners could perform the syncs on demand.  Or, a ChronJob 
> could be something like a persistence JMS Topic subscriber and replay 
> change events.
>
> We could decide that we don't support user updates for read-only 
> stores.  Then, in that case, IMO, we don't need a changelog event queue.
>
>
>
>


From stian at redhat.com  Fri Jul 11 04:22:45 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 04:22:45 -0400 (EDT)
Subject: [keycloak-dev] Do we still need project-integrations/aerogear-ups
Message-ID: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>

Can we delete project-integrations/aerogear-ups, or do we still need it?

From matzew at apache.org  Fri Jul 11 05:38:37 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 11 Jul 2014 11:38:37 +0200
Subject: [keycloak-dev] Do we still need
	project-integrations/aerogear-ups
In-Reply-To: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>
References: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2TQnzkfAQJhqXFGZN8kgoWAjPR577fd-ZzB_J+zh9xWiA@mail.gmail.com>

It helped us to for getting the UPS integration running.

I used it basically as a 'simple way' to describe error, instead of having
to mess around w/ UPS, as things are reproducable w/ the KC src base (e.g.
KEYCLOAK-556 );
But if you have strong feelings around deleting it, go for it

-Matthias


On Fri, Jul 11, 2014 at 10:22 AM, Stian Thorgersen <stian at redhat.com> wrote:

> Can we delete project-integrations/aerogear-ups, or do we still need it?
> _______________________________________________
> 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/20140711/9f376cc0/attachment.html 

From stian at redhat.com  Fri Jul 11 07:35:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 07:35:38 -0400 (EDT)
Subject: [keycloak-dev] Do we still need
 project-integrations/aerogear-ups
In-Reply-To: <CAAg5f2TQnzkfAQJhqXFGZN8kgoWAjPR577fd-ZzB_J+zh9xWiA@mail.gmail.com>
References: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>
	<CAAg5f2TQnzkfAQJhqXFGZN8kgoWAjPR577fd-ZzB_J+zh9xWiA@mail.gmail.com>
Message-ID: <35904124.8126213.1405078538303.JavaMail.zimbra@redhat.com>

No strong feelings, just checking if it's actually still in use, so if you still use it we'll keep it ;)

----- Original Message -----
> From: "Matthias Wessendorf" <matzew at apache.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 11 July, 2014 10:38:37 AM
> Subject: Re: [keycloak-dev] Do we still need project-integrations/aerogear-ups
> 
> It helped us to for getting the UPS integration running.
> 
> I used it basically as a 'simple way' to describe error, instead of having
> to mess around w/ UPS, as things are reproducable w/ the KC src base (e.g.
> KEYCLOAK-556 );
> But if you have strong feelings around deleting it, go for it
> 
> -Matthias
> 
> 
> On Fri, Jul 11, 2014 at 10:22 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> > Can we delete project-integrations/aerogear-ups, or do we still need it?
> > _______________________________________________
> > 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
> 

From stian at redhat.com  Fri Jul 11 08:29:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 08:29:49 -0400 (EDT)
Subject: [keycloak-dev] JPA connections provider and multiple transaction
	support
In-Reply-To: <597196694.8176112.1405081386602.JavaMail.zimbra@redhat.com>
Message-ID: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>

To prevent creating multiple EntityManager's for a single request I've added a JPAConnectionProvider that is used to share an EntityManager instance between multiple providers.

  https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
  https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java

In the future we could consider adding support for multiple persistence-units, but for now I think we should have a limitation that all JPA providers use the same database/persistence-unit.

I've also added some very basic support to KeycloakSession so providers can enlist their transactions with the session:

  https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
  https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java

The idea being that a provider when used can enlist its transaction with the session.

I've not committed any of this to master as I wanted to have everyone's opinion on it first.

From stian at redhat.com  Fri Jul 11 09:05:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 09:05:55 -0400 (EDT)
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BEE30D.6050703@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
Message-ID: <2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>

This sounds like exactly what we need. There are quite a lot of kinks to work out though.

With that in mind I think we should limit the scope of this for 1.0.final to something along the lines of what AuthProvider does now. Question is for 1.0.final do we:

* Extract user related methods into UserProvider - my vote is yes
* Deprecate AuthProvider and provide something similar through UserProvider - I'm unsure about this
* Try to cover all basis in UserProvider such as sync, etc - my vote is no

With regards to SPIs in general there are some that are aimed at internal use only, others that are aimed at public use, and I guess we could flag certain SPIs as likely to change in the future (such as AuthProvider).

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 10 July, 2014 8:01:33 PM
> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
> 
> On 10.7.2014 15:47, Bill Burke wrote:
> >
> >
> > On 7/10/2014 7:41 AM, Marek Posolda wrote:
> >>
> >> That's why I would prefer "sync" among "federation" approach.
> >
> > Which is exactly what I'm proposing.  Except it allows for
> > syncs/imports into Keycloak on demand.  You already use
> > AuthenticationProvider in this manner!
> oops, I though that with AuthProvider you don't like the fact that just
> LDAP users authenticated with Keycloak are available in Keycloak DB;-)
> 
> 
> >
> > My impression of a sync model is that Keycloak works with user data in
> > local Keycloak storage.  User metadata is imported from external
> > storage (either on demand or at startp and periodically synced).
> > Keycloak can manage/modify/augment this imported user data locally.
> > The changelog is obtained from the Sync API and updates sent back to
> > the external storage.
> >
> >
> >> In
> >> shortcut with "sync" approach will be users (and eventually their role
> >> mappings) synced from external store into Keycloak and most of the
> >> UserProvider methods would deal just with "local" provider. Only
> >> exception are authentication related methods, and also "update" methods,
> >> which will need to update local user and also "external" users. But
> >> SyncProvider won't need to implement methods like getUsers(),
> >> searchFor**, getUserBy** etc as all users will be available locally.
> >>
> >
> > The problem with this approach is that new users don't get imported
> > into Keycloak until the sync gets invoked.  Syncing more than once per
> > day, or even once per week may not be feasible.  If the external
> > storage does not have a changelog, syncing would involve iterating
> > through each and every user in external storage and syncing it with
> > the keycloak database.  A full sync could take hours.
> Yes, but how to do it differently?
> (a) For methods like: UserProvider.getUsers(), UserProvider.searchFor***
> we can either:
> 1) retrieve users just from "local" store
> 2) Federate users and merge them from both "local" and "external" store.
> 
> Federation approach (2) has quite bad performance issues (especially
> with pagination+sorting), so I would prefer (1). But this really
> requires full sync from external store into KC IMO.
> 
> 
> (b) Then we have methods for retrieve single user:
> getUserBy*** --- here we can try to retrieve user from 'local' store and
> fallback to 'external'. In that case, user will be synced on demand to
> KC database (similar approach like AuthenticationProvider), but then we
> have the issue that just those users, who were retrieved from
> externalStore will be available in KC.
> 
> I think that we can either:
> (1) Federate users from both stores
> (2) Temporarily allow that just some users from LDAP are available in KC
> database (those who were authenticated or for which getUserBy*** was called)
> (3) Do full sync
> 
> I don't know if you see some other solution, but I would say that if we
> want to avoid (1) and (2) we really need to do full sync. So I would
> imagine that if someone configure externalStore, he will also need to
> trigger full sync to KC to have all users added to Keycloak.
> >
> >
> >>
> >>
> >>
> >> In details, I can imagine to have things working this way:
> >>
> >> * There will be Sync SPI configured per realm, which will allow to sync
> >> users from "external store" to Keycloak.
> >>
> >
> > +1
> >
> >> * It will be possible to configure when to sync users. For example it
> >> can be full sync from LDAP at server startup or triggered from admin
> >> console. Then some periodic sync (triggered for example once per day).
> >>
> >
> > +1
> >
> >> * I am not sure if we need full sync from Keycloak to "external
> >> provider" but probably not. Once user, role or user credential will be
> >> updated in Keycloak, it will be also immediatelly synced to external
> >> provider (if provider is not read-only).
> >>
> >
> > If you don't implement through the UserProvider/UserModel interface
> > then you would need an Event model for which the SyncProvider listens
> > to so that it can sync the user on demand.
> yep, I think that it works to implement this in UserProvider (and
> RealmProvider for roles). Basically you have something like
> "WrapperUserProvider" and once add/update/delete user is invoked, it
> will perform the operation on "local" UserProvider and then invoke
> particular method on SyncProvider to sync it back into external storage.
> >
> >> * It depends on SyncProvider implementation, what user data are synced.
> >> For example in case of LDAP it will be just email+first,lastName and
> >> eventually role mappings.
> >>
> >> * SyncProvider may also support roles + role mappings from external
> >> store. SyncProvider will be able to import roles into RealmProvider and
> >> then particular role mappings into UserProvider.
> >>
> >> * Users synced from "external provider" will have link to this provider
> >> similarly like it's now. In case that provider is read-write, then all
> >> newly created users in Keycloak will be synced into "external provider"
> >> immediatelly also with the credential (if syncProvider supports
> >> particular credential)
> >>
> >> I would propose the interface like this to handle both
> >> sync/authentication (not sure if "SyncProvider" is good name, maybe
> >> rather "ExternalUserProvider"). I can imagine something like this:
> >>
> >>
> >> public interface SyncProvider {
> >>
> >
> > I think your SyncProvider interface is very limiting and even
> > unusable.  For example, getAllUsers() is completely unfeasible if
> > there is a large user database.
> oops, sorry. It's maybe not clear from method name and javadoc that
> "getAllUsers" is intended to be used for sync *from* External storage
> *to* Keycloak. The idea is that "getAllUsers" (or
> "syncAllUsersFromExternalStore" or whatever it's named) will be called
> by admin when he wants full sync from external storage to KC.
> 
> IMO sync from Keycloak to external storage is quite easy. We can either
> do it immediatelly when add/update/delete user/role is invoked or we can
> use some event approach you proposed with periodic (or on demand) sync
> of just "dirty" entities. We already have AuditProvider, which could be
> eventually used.
> 
> Personally I would prefer to always do sync from KC immediatelly as
> event queue doesn't always work. For example when you have RW LDAP and
> you register new user in Keycloak, you would need to save this user and
> his password immediatelly into external store. Save it somewhere in
> Keycloak database and then clear once Chron Job is triggered doesn't
> work IMO as it would mean that we will need to save passwords in
> plain-text until they are synced into LDAP. Which doesn't make much
> sense IMO.
> 
> So for sync from Keycloak to externalStore, I would personally always do
> it immediatelly after operation is performed on
> UserProvider/RealmProvider. It's not so big overhead IMO.
> 
> But the main issue is sync from externalStore to Keycloak. We can easily
> add changelog to Keycloak, but we don't have control under external
> storage...
> 
> I don't know if LDAP servers support changelog, probably yes but I don't
> think that it's standardized, maybe some LDAP servers support
> "proprietary" way of doing changelog. I can check if some LDAP supports
> this and how it works with them...
> 
> But fact is that if externalProvider doesn't support changelog, then how
> to do sync without something like "getAllUsers" (or "syncAllUsers")? I
> know that this is quite overhead, but I really don't see how to do
> "partial" sync from 3rd party provider if it doesn't support changelogs...
> 
> Marek
> >
> >
> > IMO it would be something like this:
> >
> > public interface ChronJob {
> >
> >    void invoke(KeycloakSessionFactory factory);
> > }
> >
> > ChronJob would be scheduled to run at boot time and/or periodically by
> > the admin console.  Periodic and boot time syncs would be implemented
> > here.  The sync operation needs to have full control of when
> > transactions begin and end so updates/creates/deletes can be executed
> > in batches.
> >
> > On demand syncing would be done through an implementation of
> > UserProvider as I proposed earlier.  On-demand syncing is:
> >
> > * Importing a user on demand
> > * Updating external storage on demand.
> >
> > We would also have an event changelog that would be implemented as, or
> > act like a persistent JMS Topic.  This event topic shouldn't be used
> > to implement on-demand sync, but rather for when the external storage
> > is read only.:
> >
> > interface ChangeEvent {
> >    enum EventType {
> >        CREATE, UPDATE, DELETE
> >    }
> >
> >
> >
> >    long getTimestamp();
> >    EventType getEventType();
> >    String getItemId();
> >    String getItemType(); // UserModel, RoleModel
> > }
> >
> > EventListeners could perform the syncs on demand.  Or, a ChronJob
> > could be something like a persistence JMS Topic subscriber and replay
> > change events.
> >
> > We could decide that we don't support user updates for read-only
> > stores.  Then, in that case, IMO, we don't need a changelog event queue.
> >
> >
> >
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From matzew at apache.org  Fri Jul 11 09:08:56 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Fri, 11 Jul 2014 15:08:56 +0200
Subject: [keycloak-dev] Do we still need
	project-integrations/aerogear-ups
In-Reply-To: <35904124.8126213.1405078538303.JavaMail.zimbra@redhat.com>
References: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>
	<CAAg5f2TQnzkfAQJhqXFGZN8kgoWAjPR577fd-ZzB_J+zh9xWiA@mail.gmail.com>
	<35904124.8126213.1405078538303.JavaMail.zimbra@redhat.com>
Message-ID: <CAAg5f2RGPOd05BGeB6L5BmoXnk5egrcwjuuf4pG1XxnvqTf5kg@mail.gmail.com>

I think reproducing the mentioned issue was easier w that example. Perhaps
for you on fixing/testing as well.
But there is IMO no real need for it. Just a convenience


On Fri, Jul 11, 2014 at 1:35 PM, Stian Thorgersen <stian at redhat.com> wrote:

> No strong feelings, just checking if it's actually still in use, so if you
> still use it we'll keep it ;)
>
> ----- Original Message -----
> > From: "Matthias Wessendorf" <matzew at apache.org>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 11 July, 2014 10:38:37 AM
> > Subject: Re: [keycloak-dev] Do we still need
> project-integrations/aerogear-ups
> >
> > It helped us to for getting the UPS integration running.
> >
> > I used it basically as a 'simple way' to describe error, instead of
> having
> > to mess around w/ UPS, as things are reproducable w/ the KC src base
> (e.g.
> > KEYCLOAK-556 );
> > But if you have strong feelings around deleting it, go for it
> >
> > -Matthias
> >
> >
> > On Fri, Jul 11, 2014 at 10:22 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > > Can we delete project-integrations/aerogear-ups, or do we still need
> it?
> > > _______________________________________________
> > > 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
> >
>



-- 
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/20140711/f81e55bc/attachment.html 

From bburke at redhat.com  Fri Jul 11 10:09:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 10:09:22 -0400
Subject: [keycloak-dev] Do we still need
	project-integrations/aerogear-ups
In-Reply-To: <35904124.8126213.1405078538303.JavaMail.zimbra@redhat.com>
References: <161943847.8040396.1405066965612.JavaMail.zimbra@redhat.com>	<CAAg5f2TQnzkfAQJhqXFGZN8kgoWAjPR577fd-ZzB_J+zh9xWiA@mail.gmail.com>
	<35904124.8126213.1405078538303.JavaMail.zimbra@redhat.com>
Message-ID: <53BFF012.1070102@redhat.com>

We need to update it I believe!  :)

On 7/11/2014 7:35 AM, Stian Thorgersen wrote:
> No strong feelings, just checking if it's actually still in use, so if you still use it we'll keep it ;)
>
> ----- Original Message -----
>> From: "Matthias Wessendorf" <matzew at apache.org>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, 11 July, 2014 10:38:37 AM
>> Subject: Re: [keycloak-dev] Do we still need project-integrations/aerogear-ups
>>
>> It helped us to for getting the UPS integration running.
>>
>> I used it basically as a 'simple way' to describe error, instead of having
>> to mess around w/ UPS, as things are reproducable w/ the KC src base (e.g.
>> KEYCLOAK-556 );
>> But if you have strong feelings around deleting it, go for it
>>
>> -Matthias
>>
>>
>> On Fri, Jul 11, 2014 at 10:22 AM, Stian Thorgersen <stian at redhat.com> wrote:
>>
>>> Can we delete project-integrations/aerogear-ups, or do we still need it?
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Jul 11 10:12:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 10:12:41 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
Message-ID: <53BFF0D9.3000907@redhat.com>


On 7/11/2014 9:05 AM, Stian Thorgersen wrote:
> This sounds like exactly what we need. There are quite a lot of kinks to work out though.
>

My vote is we fix AuthProvider and sync now.  Do another iteration. 
Users *really* want this.  You're right, there's a lot of kinks we need 
to work out, but we don't want a large set of users we have to move off 
of an existing SPI.

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

From bburke at redhat.com  Fri Jul 11 10:26:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 10:26:38 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BEE30D.6050703@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
Message-ID: <53BFF41E.9010504@redhat.com>



On 7/10/2014 3:01 PM, Marek Posolda wrote:
>> The problem with this approach is that new users don't get imported
>> into Keycloak until the sync gets invoked.  Syncing more than once per
>> day, or even once per week may not be feasible.  If the external
>> storage does not have a changelog, syncing would involve iterating
>> through each and every user in external storage and syncing it with
>> the keycloak database.  A full sync could take hours.
> Yes, but how to do it differently?
> (a) For methods like: UserProvider.getUsers(), UserProvider.searchFor***
> we can either:
> 1) retrieve users just from "local" store
> 2) Federate users and merge them from both "local" and "external" store.
>
> Federation approach (2) has quite bad performance issues (especially
> with pagination+sorting), so I would prefer (1). But this really
> requires full sync from external store into KC IMO.
>
>
> (b) Then we have methods for retrieve single user:
> getUserBy*** --- here we can try to retrieve user from 'local' store and
> fallback to 'external'. In that case, user will be synced on demand to
> KC database (similar approach like AuthenticationProvider), but then we
> have the issue that just those users, who were retrieved from
> externalStore will be available in KC.
>
> I think that we can either:
> (1) Federate users from both stores
> (2) Temporarily allow that just some users from LDAP are available in KC
> database (those who were authenticated or for which getUserBy*** was
> called)
> (3) Do full sync
>
> I don't know if you see some other solution, but I would say that if we
> want to avoid (1) and (2) we really need to do full sync. So I would
> imagine that if someone configure externalStore, he will also need to
> trigger full sync to KC to have all users added to Keycloak.


Really depends on the UserProvider implementation IMO.  The UserProvider 
doesn't have to import the users on search/getAll operations. The 
UserModels returned could be proxies.  Probably harder than I'm stating, 
but its quite possible its not.


> Personally I would prefer to always do sync from KC immediatelly as
> event queue doesn't always work.

+1.  We'll probably eventually have to have an event queue, but I'd like 
to avoid it.

>
> But fact is that if externalProvider doesn't support changelog, then how
> to do sync without something like "getAllUsers" (or "syncAllUsers")? I
> know that this is quite overhead, but I really don't see how to do
> "partial" sync from 3rd party provider if it doesn't support changelogs...
>


How do we do external store->Keycloak sync?  *WE* don't.  The user does! 
:)  Again  Have a very simple ChronJob that can be scheduled.  I don't 
think there's any detailed SPI we can write that will solve all user needs.

> Marek
>>
>>
>> IMO it would be something like this:
>>
>> public interface ChronJob {
>>
>>    void invoke(KeycloakSessionFactory factory);
>> }
>>

The ChronJob has full access to local keycloak storage and can begin and 
end transactions as needed.  We can probably provide one out of the box 
for LDAP based on simple mapping metadata that can be configured, but 
anything more complex has to be written by the user.


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

From stian at redhat.com  Fri Jul 11 11:21:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 11:21:20 -0400 (EDT)
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BFF0D9.3000907@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
	<53BFF0D9.3000907@redhat.com>
Message-ID: <1375288052.8340298.1405092080826.JavaMail.zimbra@redhat.com>

I'm happy to push for this if you think we can still deliver 1.0.final in a reasonable time.

Can we do this in stages? First split ModelProvider into RealmProvider and UserProvider, update cache etc. Then start work on this in a branch? So we can roll 1.0.final without it if it turns out to take to long to delivery?

Would be good to have a Hangout again next week to discuss the next steps!

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 11 July, 2014 3:12:41 PM
> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
> 
> 
> On 7/11/2014 9:05 AM, Stian Thorgersen wrote:
> > This sounds like exactly what we need. There are quite a lot of kinks to
> > work out though.
> >
> 
> My vote is we fix AuthProvider and sync now.  Do another iteration.
> Users *really* want this.  You're right, there's a lot of kinks we need
> to work out, but we don't want a large set of users we have to move off
> of an existing SPI.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Fri Jul 11 11:36:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 11:36:24 -0400 (EDT)
Subject: [keycloak-dev] Moved user session model tests to
	testsuite/integration
In-Reply-To: <120342924.8349008.1405092940328.JavaMail.zimbra@redhat.com>
Message-ID: <704613642.8349246.1405092984150.JavaMail.zimbra@redhat.com>

I moved UserSession related tests to:

  https://github.com/stianst/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/model/UserSessionProviderTest.java
 
The reason is that UserSession tests rely on Realms and Users so need a ModelProvider to run. It also makes it easier to run it with different configurations.

I think we should move the rest of the tests in model/tests to the same place. This will help once we split the model into RealmProvider and UserProvider.

If everyone is happy with this I can do it next week.

From stian at redhat.com  Fri Jul 11 11:50:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 11:50:03 -0400 (EDT)
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction	support
In-Reply-To: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
Message-ID: <1136214639.8373391.1405093803659.JavaMail.zimbra@redhat.com>

Added Mongo connection provider as well, and moved the MongoStore stuff there:

  https://github.com/stianst/keycloak/blob/master/connections/mongo/src/main/java/org/keycloak/connections/mongo/DefaultMongoConnectionProvider.java
  https://github.com/stianst/keycloak/blob/master/connections/mongo/src/main/java/org/keycloak/connections/mongo/DefaultMongoConnectionFactoryProvider.java

Now neither the MongoModelProvider:

  https://github.com/stianst/keycloak/blob/master/model/mongo/src/main/java/org/keycloak/models/mongo/keycloak/adapters/MongoModelProviderFactory.java

Or the JpaModelProvider:

  https://github.com/stianst/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/JpaModelProviderFactory.java

Has to deal with connections or transactions.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 11 July, 2014 1:29:49 PM
> Subject: [keycloak-dev] JPA connections provider and multiple transaction	support
> 
> To prevent creating multiple EntityManager's for a single request I've added
> a JPAConnectionProvider that is used to share an EntityManager instance
> between multiple providers.
> 
>   https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>   https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
> 
> In the future we could consider adding support for multiple
> persistence-units, but for now I think we should have a limitation that all
> JPA providers use the same database/persistence-unit.
> 
> I've also added some very basic support to KeycloakSession so providers can
> enlist their transactions with the session:
> 
>   https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>   https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
> 
> The idea being that a provider when used can enlist its transaction with the
> session.
> 
> I've not committed any of this to master as I wanted to have everyone's
> opinion on it first.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Jul 11 11:57:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 11:57:37 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <1375288052.8340298.1405092080826.JavaMail.zimbra@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
	<53BFF0D9.3000907@redhat.com>
	<1375288052.8340298.1405092080826.JavaMail.zimbra@redhat.com>
Message-ID: <53C00971.6020302@redhat.com>

What else is there after this?  THere's nothing major left.

On 7/11/2014 11:21 AM, Stian Thorgersen wrote:
> I'm happy to push for this if you think we can still deliver 1.0.final in a reasonable time.
>
> Can we do this in stages? First split ModelProvider into RealmProvider and UserProvider, update cache etc. Then start work on this in a branch? So we can roll 1.0.final without it if it turns out to take to long to delivery?
>
> Would be good to have a Hangout again next week to discuss the next steps!
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 11 July, 2014 3:12:41 PM
>> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
>>
>>
>> On 7/11/2014 9:05 AM, Stian Thorgersen wrote:
>>> This sounds like exactly what we need. There are quite a lot of kinks to
>>> work out though.
>>>
>>
>> My vote is we fix AuthProvider and sync now.  Do another iteration.
>> Users *really* want this.  You're right, there's a lot of kinks we need
>> to work out, but we don't want a large set of users we have to move off
>> of an existing SPI.
>>
>> --
>> 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 stian at redhat.com  Fri Jul 11 12:02:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 11 Jul 2014 12:02:02 -0400 (EDT)
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53C00971.6020302@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
	<53BFF0D9.3000907@redhat.com>
	<1375288052.8340298.1405092080826.JavaMail.zimbra@redhat.com>
	<53C00971.6020302@redhat.com>
Message-ID: <1850318534.8390207.1405094522726.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, 11 July, 2014 4:57:37 PM
> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
> 
> What else is there after this?  THere's nothing major left.

Yep, only minor things. We can't all work on this though? It'll probably also take a while?

> 
> On 7/11/2014 11:21 AM, Stian Thorgersen wrote:
> > I'm happy to push for this if you think we can still deliver 1.0.final in a
> > reasonable time.
> >
> > Can we do this in stages? First split ModelProvider into RealmProvider and
> > UserProvider, update cache etc. Then start work on this in a branch? So we
> > can roll 1.0.final without it if it turns out to take to long to delivery?
> >
> > Would be good to have a Hangout again next week to discuss the next steps!
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda"
> >> <mposolda at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 11 July, 2014 3:12:41 PM
> >> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
> >>
> >>
> >> On 7/11/2014 9:05 AM, Stian Thorgersen wrote:
> >>> This sounds like exactly what we need. There are quite a lot of kinks to
> >>> work out though.
> >>>
> >>
> >> My vote is we fix AuthProvider and sync now.  Do another iteration.
> >> Users *really* want this.  You're right, there's a lot of kinks we need
> >> to work out, but we don't want a large set of users we have to move off
> >> of an existing SPI.
> >>
> >> --
> >> 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  Fri Jul 11 12:19:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 12:19:51 -0400
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <1850318534.8390207.1405094522726.JavaMail.zimbra@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<2006214836.8209358.1405083955176.JavaMail.zimbra@redhat.com>
	<53BFF0D9.3000907@redhat.com>
	<1375288052.8340298.1405092080826.JavaMail.zimbra@redhat.com>
	<53C00971.6020302@redhat.com>
	<1850318534.8390207.1405094522726.JavaMail.zimbra@redhat.com>
Message-ID: <53C00EA7.1020400@redhat.com>



On 7/11/2014 12:02 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Friday, 11 July, 2014 4:57:37 PM
>> Subject: Re: [keycloak-dev] sync/federation requirements/ideas
>>
>> What else is there after this?  THere's nothing major left.
>
> Yep, only minor things. We can't all work on this though? It'll probably also take a while?
>

There's still stuff to do.  pagination, and about 20 other issues.


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

From bburke at redhat.com  Fri Jul 11 13:00:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 13:00:02 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <1136214639.8373391.1405093803659.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<1136214639.8373391.1405093803659.JavaMail.zimbra@redhat.com>
Message-ID: <53C01812.9060803@redhat.com>

I don't think you committed this.

On 7/11/2014 11:50 AM, Stian Thorgersen wrote:
> Added Mongo connection provider as well, and moved the MongoStore stuff there:
>
>    https://github.com/stianst/keycloak/blob/master/connections/mongo/src/main/java/org/keycloak/connections/mongo/DefaultMongoConnectionProvider.java
>    https://github.com/stianst/keycloak/blob/master/connections/mongo/src/main/java/org/keycloak/connections/mongo/DefaultMongoConnectionFactoryProvider.java
>
> Now neither the MongoModelProvider:
>
>    https://github.com/stianst/keycloak/blob/master/model/mongo/src/main/java/org/keycloak/models/mongo/keycloak/adapters/MongoModelProviderFactory.java
>
> Or the JpaModelProvider:
>
>    https://github.com/stianst/keycloak/blob/master/model/jpa/src/main/java/org/keycloak/models/jpa/JpaModelProviderFactory.java
>
> Has to deal with connections or transactions.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Friday, 11 July, 2014 1:29:49 PM
>> Subject: [keycloak-dev] JPA connections provider and multiple transaction	support
>>
>> To prevent creating multiple EntityManager's for a single request I've added
>> a JPAConnectionProvider that is used to share an EntityManager instance
>> between multiple providers.
>>
>>    https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>    https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>
>> In the future we could consider adding support for multiple
>> persistence-units, but for now I think we should have a limitation that all
>> JPA providers use the same database/persistence-unit.
>>
>> I've also added some very basic support to KeycloakSession so providers can
>> enlist their transactions with the session:
>>
>>    https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>    https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>
>> The idea being that a provider when used can enlist its transaction with the
>> session.
>>
>> I've not committed any of this to master as I wanted to have everyone's
>> opinion on it first.
>> _______________________________________________
>> 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 bburke at redhat.com  Fri Jul 11 15:52:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 15:52:12 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
Message-ID: <53C0406C.8070805@redhat.com>

Please get this in.  I can't finish with UserProvider split until you do.

On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
> To prevent creating multiple EntityManager's for a single request I've added a JPAConnectionProvider that is used to share an EntityManager instance between multiple providers.
>
>    https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>    https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>
> In the future we could consider adding support for multiple persistence-units, but for now I think we should have a limitation that all JPA providers use the same database/persistence-unit.
>
> I've also added some very basic support to KeycloakSession so providers can enlist their transactions with the session:
>
>    https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>    https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>
> The idea being that a provider when used can enlist its transaction with the session.
>
> I've not committed any of this to master as I wanted to have everyone's opinion on it first.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Fri Jul 11 18:11:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 18:11:53 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <53C0406C.8070805@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com>
Message-ID: <53C06129.5050506@redhat.com>

Actually I think there is a better way.

public interface TransactionManaged {

    KeycloakTransaction getTransaction();
}

public interface KeycloakSession implements TransactionManaged {}
public interface UserProvider implements TransactionManaged{}

etc.


KeycloakSession.getProvider() will check to see if the provider is 
transaction managed.  If KeycloakSession has an active transaction, then 
a transaction will be created for that provider and registered with an 
internal TM.




On 7/11/2014 3:52 PM, Bill Burke wrote:
> Please get this in.  I can't finish with UserProvider split until you do.
>
> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
>> To prevent creating multiple EntityManager's for a single request I've added a JPAConnectionProvider that is used to share an EntityManager instance between multiple providers.
>>
>>     https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>     https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>
>> In the future we could consider adding support for multiple persistence-units, but for now I think we should have a limitation that all JPA providers use the same database/persistence-unit.
>>
>> I've also added some very basic support to KeycloakSession so providers can enlist their transactions with the session:
>>
>>     https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>     https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>
>> The idea being that a provider when used can enlist its transaction with the session.
>>
>> I've not committed any of this to master as I wanted to have everyone's opinion on it first.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Fri Jul 11 19:42:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 11 Jul 2014 19:42:07 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <53C06129.5050506@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>	<53C0406C.8070805@redhat.com>
	<53C06129.5050506@redhat.com>
Message-ID: <53C0764F.2050007@redhat.com>

Ok, I committed something.

* KeycloakSession keeps track of enlisted provider KeycloakTransactions.
* KeycloakSession.getTransaction().commit() and rollback() will iterate 
these enlisted transactions
* getProvider() just returns a provider
* model() and sessions() creates a ModelProvider or UserSessionProvider 
and enlists their transactions.
* model() and sessions() throw IllegalStateException if 
KeycloakSession.transaction hasn't started yet.
* KeycloakSession has an enlist() method.





On 7/11/2014 6:11 PM, Bill Burke wrote:
> Actually I think there is a better way.
>
> public interface TransactionManaged {
>
>      KeycloakTransaction getTransaction();
> }
>
> public interface KeycloakSession implements TransactionManaged {}
> public interface UserProvider implements TransactionManaged{}
>
> etc.
>
>
> KeycloakSession.getProvider() will check to see if the provider is
> transaction managed.  If KeycloakSession has an active transaction, then
> a transaction will be created for that provider and registered with an
> internal TM.
>
>
>
>
> On 7/11/2014 3:52 PM, Bill Burke wrote:
>> Please get this in.  I can't finish with UserProvider split until you do.
>>
>> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
>>> To prevent creating multiple EntityManager's for a single request I've added a JPAConnectionProvider that is used to share an EntityManager instance between multiple providers.
>>>
>>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>>
>>> In the future we could consider adding support for multiple persistence-units, but for now I think we should have a limitation that all JPA providers use the same database/persistence-unit.
>>>
>>> I've also added some very basic support to KeycloakSession so providers can enlist their transactions with the session:
>>>
>>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>>
>>> The idea being that a provider when used can enlist its transaction with the session.
>>>
>>> I've not committed any of this to master as I wanted to have everyone's opinion on it first.
>>> _______________________________________________
>>> 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 Jul 14 04:13:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jul 2014 04:13:44 -0400 (EDT)
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <53C0764F.2050007@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
Message-ID: <1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>

I had this working, including sharing Jpa/Mongo connection providers. Which I sent out an email to get feedback for......

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 12 July, 2014 12:42:07 AM
> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
> 
> Ok, I committed something.
> 
> * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
> * KeycloakSession.getTransaction().commit() and rollback() will iterate
> these enlisted transactions
> * getProvider() just returns a provider
> * model() and sessions() creates a ModelProvider or UserSessionProvider
> and enlists their transactions.
> * model() and sessions() throw IllegalStateException if
> KeycloakSession.transaction hasn't started yet.
> * KeycloakSession has an enlist() method.
> 
> 
> 
> 
> 
> On 7/11/2014 6:11 PM, Bill Burke wrote:
> > Actually I think there is a better way.
> >
> > public interface TransactionManaged {
> >
> >      KeycloakTransaction getTransaction();
> > }
> >
> > public interface KeycloakSession implements TransactionManaged {}
> > public interface UserProvider implements TransactionManaged{}
> >
> > etc.
> >
> >
> > KeycloakSession.getProvider() will check to see if the provider is
> > transaction managed.  If KeycloakSession has an active transaction, then
> > a transaction will be created for that provider and registered with an
> > internal TM.
> >
> >
> >
> >
> > On 7/11/2014 3:52 PM, Bill Burke wrote:
> >> Please get this in.  I can't finish with UserProvider split until you do.
> >>
> >> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
> >>> To prevent creating multiple EntityManager's for a single request I've
> >>> added a JPAConnectionProvider that is used to share an EntityManager
> >>> instance between multiple providers.
> >>>
> >>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
> >>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
> >>>
> >>> In the future we could consider adding support for multiple
> >>> persistence-units, but for now I think we should have a limitation that
> >>> all JPA providers use the same database/persistence-unit.
> >>>
> >>> I've also added some very basic support to KeycloakSession so providers
> >>> can enlist their transactions with the session:
> >>>
> >>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
> >>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
> >>>
> >>> The idea being that a provider when used can enlist its transaction with
> >>> the session.
> >>>
> >>> I've not committed any of this to master as I wanted to have everyone's
> >>> opinion on it first.
> >>> _______________________________________________
> >>> 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 Jul 14 05:19:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jul 2014 05:19:12 -0400 (EDT)
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
	<1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
Message-ID: <869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>

Committed the final changes to UserProvider, including working Mem, JPA and Mongo implementations.

Also, added the JPA and Mongo Connection Providers. With the connection providers we can now have a single EntityManager instance shared between ModelProvider (and UserProvider when ready), UserSessionProvider and Audit.

Had to change the multiple-transaction stuff that was added to master because with the connection providers the model (and others) do not actually start a transaction themselves. Transactional providers are now required to enlist a transaction if they want to, this won't be common to do as they should use the connection providers which will do it for them.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 14 July, 2014 9:13:44 AM
> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
> 
> I had this working, including sharing Jpa/Mongo connection providers. Which I
> sent out an email to get feedback for......
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Saturday, 12 July, 2014 12:42:07 AM
> > Subject: Re: [keycloak-dev] JPA connections provider and multiple
> > transaction support
> > 
> > Ok, I committed something.
> > 
> > * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
> > * KeycloakSession.getTransaction().commit() and rollback() will iterate
> > these enlisted transactions
> > * getProvider() just returns a provider
> > * model() and sessions() creates a ModelProvider or UserSessionProvider
> > and enlists their transactions.
> > * model() and sessions() throw IllegalStateException if
> > KeycloakSession.transaction hasn't started yet.
> > * KeycloakSession has an enlist() method.
> > 
> > 
> > 
> > 
> > 
> > On 7/11/2014 6:11 PM, Bill Burke wrote:
> > > Actually I think there is a better way.
> > >
> > > public interface TransactionManaged {
> > >
> > >      KeycloakTransaction getTransaction();
> > > }
> > >
> > > public interface KeycloakSession implements TransactionManaged {}
> > > public interface UserProvider implements TransactionManaged{}
> > >
> > > etc.
> > >
> > >
> > > KeycloakSession.getProvider() will check to see if the provider is
> > > transaction managed.  If KeycloakSession has an active transaction, then
> > > a transaction will be created for that provider and registered with an
> > > internal TM.
> > >
> > >
> > >
> > >
> > > On 7/11/2014 3:52 PM, Bill Burke wrote:
> > >> Please get this in.  I can't finish with UserProvider split until you
> > >> do.
> > >>
> > >> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
> > >>> To prevent creating multiple EntityManager's for a single request I've
> > >>> added a JPAConnectionProvider that is used to share an EntityManager
> > >>> instance between multiple providers.
> > >>>
> > >>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
> > >>>      https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
> > >>>
> > >>> In the future we could consider adding support for multiple
> > >>> persistence-units, but for now I think we should have a limitation that
> > >>> all JPA providers use the same database/persistence-unit.
> > >>>
> > >>> I've also added some very basic support to KeycloakSession so providers
> > >>> can enlist their transactions with the session:
> > >>>
> > >>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
> > >>>      https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
> > >>>
> > >>> The idea being that a provider when used can enlist its transaction
> > >>> with
> > >>> the session.
> > >>>
> > >>> I've not committed any of this to master as I wanted to have everyone's
> > >>> opinion on it first.
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >>
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Jul 14 07:05:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jul 2014 07:05:54 -0400 (EDT)
Subject: [keycloak-dev] Removed fix version for pagination support for roles
In-Reply-To: <873866752.9488661.1405335927080.JavaMail.zimbra@redhat.com>
Message-ID: <664375461.9488773.1405335954622.JavaMail.zimbra@redhat.com>

I removed fix version on https://issues.jboss.org/browse/KEYCLOAK-513 (used to be 1.0-beta-4). I'm not convinced that anyone will have enough roles to warrant implementing this.

From stian at redhat.com  Mon Jul 14 09:42:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jul 2014 09:42:50 -0400 (EDT)
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <53C3DC99.80102@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
	<1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
	<869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
	<53C3DC99.80102@redhat.com>
Message-ID: <428086927.9645951.1405345370860.JavaMail.zimbra@redhat.com>

Yep, all done.

Marek is working on import/export, but he'll need to update that to work with the changes you do to the model so that can be committed after you've finished.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 14 July, 2014 2:35:21 PM
> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
> 
> So, are you guys done with your model work?  I can do dig into it now
> without worrying that it will change entirely in between work days?
> 
> On 7/14/2014 5:19 AM, Stian Thorgersen wrote:
> > Committed the final changes to UserProvider, including working Mem, JPA and
> > Mongo implementations.
> >
> > Also, added the JPA and Mongo Connection Providers. With the connection
> > providers we can now have a single EntityManager instance shared between
> > ModelProvider (and UserProvider when ready), UserSessionProvider and
> > Audit.
> >
> > Had to change the multiple-transaction stuff that was added to master
> > because with the connection providers the model (and others) do not
> > actually start a transaction themselves. Transactional providers are now
> > required to enlist a transaction if they want to, this won't be common to
> > do as they should use the connection providers which will do it for them.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 14 July, 2014 9:13:44 AM
> >> Subject: Re: [keycloak-dev] JPA connections provider and multiple
> >> transaction support
> >>
> >> I had this working, including sharing Jpa/Mongo connection providers.
> >> Which I
> >> sent out an email to get feedback for......
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Saturday, 12 July, 2014 12:42:07 AM
> >>> Subject: Re: [keycloak-dev] JPA connections provider and multiple
> >>> transaction support
> >>>
> >>> Ok, I committed something.
> >>>
> >>> * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
> >>> * KeycloakSession.getTransaction().commit() and rollback() will iterate
> >>> these enlisted transactions
> >>> * getProvider() just returns a provider
> >>> * model() and sessions() creates a ModelProvider or UserSessionProvider
> >>> and enlists their transactions.
> >>> * model() and sessions() throw IllegalStateException if
> >>> KeycloakSession.transaction hasn't started yet.
> >>> * KeycloakSession has an enlist() method.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 7/11/2014 6:11 PM, Bill Burke wrote:
> >>>> Actually I think there is a better way.
> >>>>
> >>>> public interface TransactionManaged {
> >>>>
> >>>>       KeycloakTransaction getTransaction();
> >>>> }
> >>>>
> >>>> public interface KeycloakSession implements TransactionManaged {}
> >>>> public interface UserProvider implements TransactionManaged{}
> >>>>
> >>>> etc.
> >>>>
> >>>>
> >>>> KeycloakSession.getProvider() will check to see if the provider is
> >>>> transaction managed.  If KeycloakSession has an active transaction, then
> >>>> a transaction will be created for that provider and registered with an
> >>>> internal TM.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On 7/11/2014 3:52 PM, Bill Burke wrote:
> >>>>> Please get this in.  I can't finish with UserProvider split until you
> >>>>> do.
> >>>>>
> >>>>> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
> >>>>>> To prevent creating multiple EntityManager's for a single request I've
> >>>>>> added a JPAConnectionProvider that is used to share an EntityManager
> >>>>>> instance between multiple providers.
> >>>>>>
> >>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
> >>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
> >>>>>>
> >>>>>> In the future we could consider adding support for multiple
> >>>>>> persistence-units, but for now I think we should have a limitation
> >>>>>> that
> >>>>>> all JPA providers use the same database/persistence-unit.
> >>>>>>
> >>>>>> I've also added some very basic support to KeycloakSession so
> >>>>>> providers
> >>>>>> can enlist their transactions with the session:
> >>>>>>
> >>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
> >>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
> >>>>>>
> >>>>>> The idea being that a provider when used can enlist its transaction
> >>>>>> with
> >>>>>> the session.
> >>>>>>
> >>>>>> I've not committed any of this to master as I wanted to have
> >>>>>> everyone's
> >>>>>> opinion on it first.
> >>>>>> _______________________________________________
> >>>>>> keycloak-dev mailing list
> >>>>>> keycloak-dev at lists.jboss.org
> >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Jul 14 12:10:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 14 Jul 2014 12:10:04 -0400 (EDT)
Subject: [keycloak-dev] Auth-method Keycloak required on Undertow,
	but not on AS7
In-Reply-To: <1281419908.9789234.1405354195897.JavaMail.zimbra@redhat.com>
Message-ID: <199396109.9789320.1405354204980.JavaMail.zimbra@redhat.com>

I've just fixed this issue for the AeroGear guys:

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

While doing it I noticed that it works with auth-method=BASIC on AS7, but on WildFly/Undertow I had to change it to Keycloak. Is there a reason why this isn't the same on both?

From bburke at redhat.com  Mon Jul 14 09:17:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Jul 2014 09:17:31 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
	<1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
	<869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
Message-ID: <53C3D86B.1040703@redhat.com>

Great thanks.  Hopefully I didn't create too big of a merge conflict.

On 7/14/2014 5:19 AM, Stian Thorgersen wrote:
> Committed the final changes to UserProvider, including working Mem, JPA and Mongo implementations.
>
> Also, added the JPA and Mongo Connection Providers. With the connection providers we can now have a single EntityManager instance shared between ModelProvider (and UserProvider when ready), UserSessionProvider and Audit.
>
> Had to change the multiple-transaction stuff that was added to master because with the connection providers the model (and others) do not actually start a transaction themselves. Transactional providers are now required to enlist a transaction if they want to, this won't be common to do as they should use the connection providers which will do it for them.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 14 July, 2014 9:13:44 AM
>> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
>>
>> I had this working, including sharing Jpa/Mongo connection providers. Which I
>> sent out an email to get feedback for......
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Saturday, 12 July, 2014 12:42:07 AM
>>> Subject: Re: [keycloak-dev] JPA connections provider and multiple
>>> transaction support
>>>
>>> Ok, I committed something.
>>>
>>> * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
>>> * KeycloakSession.getTransaction().commit() and rollback() will iterate
>>> these enlisted transactions
>>> * getProvider() just returns a provider
>>> * model() and sessions() creates a ModelProvider or UserSessionProvider
>>> and enlists their transactions.
>>> * model() and sessions() throw IllegalStateException if
>>> KeycloakSession.transaction hasn't started yet.
>>> * KeycloakSession has an enlist() method.
>>>
>>>
>>>
>>>
>>>
>>> On 7/11/2014 6:11 PM, Bill Burke wrote:
>>>> Actually I think there is a better way.
>>>>
>>>> public interface TransactionManaged {
>>>>
>>>>       KeycloakTransaction getTransaction();
>>>> }
>>>>
>>>> public interface KeycloakSession implements TransactionManaged {}
>>>> public interface UserProvider implements TransactionManaged{}
>>>>
>>>> etc.
>>>>
>>>>
>>>> KeycloakSession.getProvider() will check to see if the provider is
>>>> transaction managed.  If KeycloakSession has an active transaction, then
>>>> a transaction will be created for that provider and registered with an
>>>> internal TM.
>>>>
>>>>
>>>>
>>>>
>>>> On 7/11/2014 3:52 PM, Bill Burke wrote:
>>>>> Please get this in.  I can't finish with UserProvider split until you
>>>>> do.
>>>>>
>>>>> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
>>>>>> To prevent creating multiple EntityManager's for a single request I've
>>>>>> added a JPAConnectionProvider that is used to share an EntityManager
>>>>>> instance between multiple providers.
>>>>>>
>>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>>>>>
>>>>>> In the future we could consider adding support for multiple
>>>>>> persistence-units, but for now I think we should have a limitation that
>>>>>> all JPA providers use the same database/persistence-unit.
>>>>>>
>>>>>> I've also added some very basic support to KeycloakSession so providers
>>>>>> can enlist their transactions with the session:
>>>>>>
>>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>>>>>
>>>>>> The idea being that a provider when used can enlist its transaction
>>>>>> with
>>>>>> the session.
>>>>>>
>>>>>> I've not committed any of this to master as I wanted to have everyone's
>>>>>> opinion on it first.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From mposolda at redhat.com  Mon Jul 14 08:02:41 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Jul 2014 14:02:41 +0200
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53C384A0.3080202@redhat.com>
References: <53C384A0.3080202@redhat.com>
Message-ID: <53C3C6E1.5060501@redhat.com>




-------- Original Message --------
Subject: 	Re: [keycloak-dev] sync/federation requirements/ideas
Date: 	Mon, 14 Jul 2014 09:20:00 +0200
From: 	Marek Posolda <mposolda at redhat.com>
To: 	Bill Burke <bburke at redhat.com>, "keycloak-dev at lists.jboss.org" 
<keycloak-dev at lists.jboss.org>



On 11.7.2014 16:26, Bill Burke wrote:
>
>
> On 7/10/2014 3:01 PM, Marek Posolda wrote:
>>> The problem with this approach is that new users don't get imported
>>> into Keycloak until the sync gets invoked.  Syncing more than once per
>>> day, or even once per week may not be feasible.  If the external
>>> storage does not have a changelog, syncing would involve iterating
>>> through each and every user in external storage and syncing it with
>>> the keycloak database.  A full sync could take hours.
>> Yes, but how to do it differently?
>> (a) For methods like: UserProvider.getUsers(), UserProvider.searchFor***
>> we can either:
>> 1) retrieve users just from "local" store
>> 2) Federate users and merge them from both "local" and "external" store.
>>
>> Federation approach (2) has quite bad performance issues (especially
>> with pagination+sorting), so I would prefer (1). But this really
>> requires full sync from external store into KC IMO.
>>
>>
>> (b) Then we have methods for retrieve single user:
>> getUserBy*** --- here we can try to retrieve user from 'local' store and
>> fallback to 'external'. In that case, user will be synced on demand to
>> KC database (similar approach like AuthenticationProvider), but then we
>> have the issue that just those users, who were retrieved from
>> externalStore will be available in KC.
>>
>> I think that we can either:
>> (1) Federate users from both stores
>> (2) Temporarily allow that just some users from LDAP are available in KC
>> database (those who were authenticated or for which getUserBy*** was
>> called)
>> (3) Do full sync
>>
>> I don't know if you see some other solution, but I would say that if we
>> want to avoid (1) and (2) we really need to do full sync. So I would
>> imagine that if someone configure externalStore, he will also need to
>> trigger full sync to KC to have all users added to Keycloak.
>
>
> Really depends on the UserProvider implementation IMO.  The
> UserProvider doesn't have to import the users on search/getAll
> operations. The UserModels returned could be proxies.  Probably harder
> than I'm stating, but its quite possible its not.
>
>
>> Personally I would prefer to always do sync from KC immediatelly as
>> event queue doesn't always work.
>
> +1.  We'll probably eventually have to have an event queue, but I'd
> like to avoid it.
>
>>
>> But fact is that if externalProvider doesn't support changelog, then how
>> to do sync without something like "getAllUsers" (or "syncAllUsers")? I
>> know that this is quite overhead, but I really don't see how to do
>> "partial" sync from 3rd party provider if it doesn't support
>> changelogs...
>>
>
>
> How do we do external store->Keycloak sync?  *WE* don't.  The user
> does! :)  Again  Have a very simple ChronJob that can be scheduled.  I
> don't think there's any detailed SPI we can write that will solve all
> user needs.
>
>> Marek
>>>
>>>
>>> IMO it would be something like this:
>>>
>>> public interface ChronJob {
>>>
>>>    void invoke(KeycloakSessionFactory factory);
>>> }
>>>
>
> The ChronJob has full access to local keycloak storage and can begin
> and end transactions as needed.  We can probably provide one out of
> the box for LDAP based on simple mapping metadata that can be
> configured, but anything more complex has to be written by the user.
>
>
ok, once I finish export/import I can take a look how it looks with LDAP
and changelogs, but unfortunately I don't think that it's standardized
way to support this for all LDAP servers... Will also take a look at
pagination, which is surely supported by most of LDAP servers AFAIK. The
point for pagination is, that for example sync large LDAP with 100K
users is probably not going to happen in single Keycloak transaction,
but ChronJob would likely need to do it paginated in more transactions.

Marek



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

From mposolda at redhat.com  Mon Jul 14 03:20:00 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 14 Jul 2014 09:20:00 +0200
Subject: [keycloak-dev] sync/federation requirements/ideas
In-Reply-To: <53BFF41E.9010504@redhat.com>
References: <53BDB622.7060608@redhat.com> <53BE7BCE.3000607@redhat.com>
	<53BE996F.8080806@redhat.com> <53BEE30D.6050703@redhat.com>
	<53BFF41E.9010504@redhat.com>
Message-ID: <53C384A0.3080202@redhat.com>

On 11.7.2014 16:26, Bill Burke wrote:
>
>
> On 7/10/2014 3:01 PM, Marek Posolda wrote:
>>> The problem with this approach is that new users don't get imported
>>> into Keycloak until the sync gets invoked.  Syncing more than once per
>>> day, or even once per week may not be feasible.  If the external
>>> storage does not have a changelog, syncing would involve iterating
>>> through each and every user in external storage and syncing it with
>>> the keycloak database.  A full sync could take hours.
>> Yes, but how to do it differently?
>> (a) For methods like: UserProvider.getUsers(), UserProvider.searchFor***
>> we can either:
>> 1) retrieve users just from "local" store
>> 2) Federate users and merge them from both "local" and "external" store.
>>
>> Federation approach (2) has quite bad performance issues (especially
>> with pagination+sorting), so I would prefer (1). But this really
>> requires full sync from external store into KC IMO.
>>
>>
>> (b) Then we have methods for retrieve single user:
>> getUserBy*** --- here we can try to retrieve user from 'local' store and
>> fallback to 'external'. In that case, user will be synced on demand to
>> KC database (similar approach like AuthenticationProvider), but then we
>> have the issue that just those users, who were retrieved from
>> externalStore will be available in KC.
>>
>> I think that we can either:
>> (1) Federate users from both stores
>> (2) Temporarily allow that just some users from LDAP are available in KC
>> database (those who were authenticated or for which getUserBy*** was
>> called)
>> (3) Do full sync
>>
>> I don't know if you see some other solution, but I would say that if we
>> want to avoid (1) and (2) we really need to do full sync. So I would
>> imagine that if someone configure externalStore, he will also need to
>> trigger full sync to KC to have all users added to Keycloak.
>
>
> Really depends on the UserProvider implementation IMO.  The 
> UserProvider doesn't have to import the users on search/getAll 
> operations. The UserModels returned could be proxies.  Probably harder 
> than I'm stating, but its quite possible its not.
>
>
>> Personally I would prefer to always do sync from KC immediatelly as
>> event queue doesn't always work.
>
> +1.  We'll probably eventually have to have an event queue, but I'd 
> like to avoid it.
>
>>
>> But fact is that if externalProvider doesn't support changelog, then how
>> to do sync without something like "getAllUsers" (or "syncAllUsers")? I
>> know that this is quite overhead, but I really don't see how to do
>> "partial" sync from 3rd party provider if it doesn't support 
>> changelogs...
>>
>
>
> How do we do external store->Keycloak sync?  *WE* don't.  The user 
> does! :)  Again  Have a very simple ChronJob that can be scheduled.  I 
> don't think there's any detailed SPI we can write that will solve all 
> user needs.
>
>> Marek
>>>
>>>
>>> IMO it would be something like this:
>>>
>>> public interface ChronJob {
>>>
>>>    void invoke(KeycloakSessionFactory factory);
>>> }
>>>
>
> The ChronJob has full access to local keycloak storage and can begin 
> and end transactions as needed.  We can probably provide one out of 
> the box for LDAP based on simple mapping metadata that can be 
> configured, but anything more complex has to be written by the user.
>
>
ok, once I finish export/import I can take a look how it looks with LDAP 
and changelogs, but unfortunately I don't think that it's standardized 
way to support this for all LDAP servers... Will also take a look at 
pagination, which is surely supported by most of LDAP servers AFAIK. The 
point for pagination is, that for example sync large LDAP with 100K 
users is probably not going to happen in single Keycloak transaction, 
but ChronJob would likely need to do it paginated in more transactions.

Marek

From bburke at redhat.com  Mon Jul 14 09:35:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Jul 2014 09:35:21 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
	<1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
	<869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
Message-ID: <53C3DC99.80102@redhat.com>

So, are you guys done with your model work?  I can do dig into it now 
without worrying that it will change entirely in between work days?

On 7/14/2014 5:19 AM, Stian Thorgersen wrote:
> Committed the final changes to UserProvider, including working Mem, JPA and Mongo implementations.
>
> Also, added the JPA and Mongo Connection Providers. With the connection providers we can now have a single EntityManager instance shared between ModelProvider (and UserProvider when ready), UserSessionProvider and Audit.
>
> Had to change the multiple-transaction stuff that was added to master because with the connection providers the model (and others) do not actually start a transaction themselves. Transactional providers are now required to enlist a transaction if they want to, this won't be common to do as they should use the connection providers which will do it for them.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 14 July, 2014 9:13:44 AM
>> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
>>
>> I had this working, including sharing Jpa/Mongo connection providers. Which I
>> sent out an email to get feedback for......
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Saturday, 12 July, 2014 12:42:07 AM
>>> Subject: Re: [keycloak-dev] JPA connections provider and multiple
>>> transaction support
>>>
>>> Ok, I committed something.
>>>
>>> * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
>>> * KeycloakSession.getTransaction().commit() and rollback() will iterate
>>> these enlisted transactions
>>> * getProvider() just returns a provider
>>> * model() and sessions() creates a ModelProvider or UserSessionProvider
>>> and enlists their transactions.
>>> * model() and sessions() throw IllegalStateException if
>>> KeycloakSession.transaction hasn't started yet.
>>> * KeycloakSession has an enlist() method.
>>>
>>>
>>>
>>>
>>>
>>> On 7/11/2014 6:11 PM, Bill Burke wrote:
>>>> Actually I think there is a better way.
>>>>
>>>> public interface TransactionManaged {
>>>>
>>>>       KeycloakTransaction getTransaction();
>>>> }
>>>>
>>>> public interface KeycloakSession implements TransactionManaged {}
>>>> public interface UserProvider implements TransactionManaged{}
>>>>
>>>> etc.
>>>>
>>>>
>>>> KeycloakSession.getProvider() will check to see if the provider is
>>>> transaction managed.  If KeycloakSession has an active transaction, then
>>>> a transaction will be created for that provider and registered with an
>>>> internal TM.
>>>>
>>>>
>>>>
>>>>
>>>> On 7/11/2014 3:52 PM, Bill Burke wrote:
>>>>> Please get this in.  I can't finish with UserProvider split until you
>>>>> do.
>>>>>
>>>>> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
>>>>>> To prevent creating multiple EntityManager's for a single request I've
>>>>>> added a JPAConnectionProvider that is used to share an EntityManager
>>>>>> instance between multiple providers.
>>>>>>
>>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>>>>>       https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>>>>>
>>>>>> In the future we could consider adding support for multiple
>>>>>> persistence-units, but for now I think we should have a limitation that
>>>>>> all JPA providers use the same database/persistence-unit.
>>>>>>
>>>>>> I've also added some very basic support to KeycloakSession so providers
>>>>>> can enlist their transactions with the session:
>>>>>>
>>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>>>>>       https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>>>>>
>>>>>> The idea being that a provider when used can enlist its transaction
>>>>>> with
>>>>>> the session.
>>>>>>
>>>>>> I've not committed any of this to master as I wanted to have everyone's
>>>>>> opinion on it first.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bburke at redhat.com  Mon Jul 14 10:21:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 14 Jul 2014 10:21:27 -0400
Subject: [keycloak-dev] JPA connections provider and multiple
 transaction support
In-Reply-To: <428086927.9645951.1405345370860.JavaMail.zimbra@redhat.com>
References: <1016349624.8179365.1405081789657.JavaMail.zimbra@redhat.com>
	<53C0406C.8070805@redhat.com> <53C06129.5050506@redhat.com>
	<53C0764F.2050007@redhat.com>
	<1704742890.9394597.1405325624557.JavaMail.zimbra@redhat.com>
	<869630686.9428578.1405329552335.JavaMail.zimbra@redhat.com>
	<53C3DC99.80102@redhat.com>
	<428086927.9645951.1405345370860.JavaMail.zimbra@redhat.com>
Message-ID: <53C3E767.4030306@redhat.com>

Marek,

If you want to commit earlier thats fine too.

On 7/14/2014 9:42 AM, Stian Thorgersen wrote:
> Yep, all done.
>
> Marek is working on import/export, but he'll need to update that to work with the changes you do to the model so that can be committed after you've finished.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 14 July, 2014 2:35:21 PM
>> Subject: Re: [keycloak-dev] JPA connections provider and multiple transaction support
>>
>> So, are you guys done with your model work?  I can do dig into it now
>> without worrying that it will change entirely in between work days?
>>
>> On 7/14/2014 5:19 AM, Stian Thorgersen wrote:
>>> Committed the final changes to UserProvider, including working Mem, JPA and
>>> Mongo implementations.
>>>
>>> Also, added the JPA and Mongo Connection Providers. With the connection
>>> providers we can now have a single EntityManager instance shared between
>>> ModelProvider (and UserProvider when ready), UserSessionProvider and
>>> Audit.
>>>
>>> Had to change the multiple-transaction stuff that was added to master
>>> because with the connection providers the model (and others) do not
>>> actually start a transaction themselves. Transactional providers are now
>>> required to enlist a transaction if they want to, this won't be common to
>>> do as they should use the connection providers which will do it for them.
>>>
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, 14 July, 2014 9:13:44 AM
>>>> Subject: Re: [keycloak-dev] JPA connections provider and multiple
>>>> transaction support
>>>>
>>>> I had this working, including sharing Jpa/Mongo connection providers.
>>>> Which I
>>>> sent out an email to get feedback for......
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Saturday, 12 July, 2014 12:42:07 AM
>>>>> Subject: Re: [keycloak-dev] JPA connections provider and multiple
>>>>> transaction support
>>>>>
>>>>> Ok, I committed something.
>>>>>
>>>>> * KeycloakSession keeps track of enlisted provider KeycloakTransactions.
>>>>> * KeycloakSession.getTransaction().commit() and rollback() will iterate
>>>>> these enlisted transactions
>>>>> * getProvider() just returns a provider
>>>>> * model() and sessions() creates a ModelProvider or UserSessionProvider
>>>>> and enlists their transactions.
>>>>> * model() and sessions() throw IllegalStateException if
>>>>> KeycloakSession.transaction hasn't started yet.
>>>>> * KeycloakSession has an enlist() method.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 7/11/2014 6:11 PM, Bill Burke wrote:
>>>>>> Actually I think there is a better way.
>>>>>>
>>>>>> public interface TransactionManaged {
>>>>>>
>>>>>>        KeycloakTransaction getTransaction();
>>>>>> }
>>>>>>
>>>>>> public interface KeycloakSession implements TransactionManaged {}
>>>>>> public interface UserProvider implements TransactionManaged{}
>>>>>>
>>>>>> etc.
>>>>>>
>>>>>>
>>>>>> KeycloakSession.getProvider() will check to see if the provider is
>>>>>> transaction managed.  If KeycloakSession has an active transaction, then
>>>>>> a transaction will be created for that provider and registered with an
>>>>>> internal TM.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/11/2014 3:52 PM, Bill Burke wrote:
>>>>>>> Please get this in.  I can't finish with UserProvider split until you
>>>>>>> do.
>>>>>>>
>>>>>>> On 7/11/2014 8:29 AM, Stian Thorgersen wrote:
>>>>>>>> To prevent creating multiple EntityManager's for a single request I've
>>>>>>>> added a JPAConnectionProvider that is used to share an EntityManager
>>>>>>>> instance between multiple providers.
>>>>>>>>
>>>>>>>>        https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProviderFactory.java
>>>>>>>>        https://github.com/stianst/keycloak/blob/master/connections/jpa/src/main/java/org/keycloak/connections/jpa/DefaultJpaConnectionProvider.java
>>>>>>>>
>>>>>>>> In the future we could consider adding support for multiple
>>>>>>>> persistence-units, but for now I think we should have a limitation
>>>>>>>> that
>>>>>>>> all JPA providers use the same database/persistence-unit.
>>>>>>>>
>>>>>>>> I've also added some very basic support to KeycloakSession so
>>>>>>>> providers
>>>>>>>> can enlist their transactions with the session:
>>>>>>>>
>>>>>>>>        https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakSession.java
>>>>>>>>        https://github.com/stianst/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/KeycloakTransactionManager.java
>>>>>>>>
>>>>>>>> The idea being that a provider when used can enlist its transaction
>>>>>>>> with
>>>>>>>> the session.
>>>>>>>>
>>>>>>>> I've not committed any of this to master as I wanted to have
>>>>>>>> everyone's
>>>>>>>> opinion on it first.
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>

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

From mposolda at redhat.com  Tue Jul 15 08:38:08 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 15 Jul 2014 14:38:08 +0200
Subject: [keycloak-dev] Issue with CacheModel
Message-ID: <53C520B0.3000604@redhat.com>

Hi,

During export/import I may want to remove some data (like realm) and 
overwrite it with imported one. But actually I have some issues during 
testing and looks like it's caused by the fact that not all the data are 
properly invalidated during removal of entities.

For example when removing realm, there is just realm itself marked for 
invalidation 
https://github.com/keycloak/keycloak/blob/master/model/invalidation-cache/model-adapters/src/main/java/org/keycloak/models/cache/DefaultCacheModelProvider.java#L268 
. Actually with JPA model, the call to  getDelegate().removeRealm(id) 
also seems to invalidate application and application roles (due to the 
call to getApplicationById() which uses CacheModel) but realm roles, 
oauth clients and users are not invalidated. For Mongo model, there are 
no data invalidated at all.

Question is if CacheModelProvider should rely on ModelProvider to 
invalidate cached data during getDelegate().removeRealm ? Shouldn't it 
be the responsibility of CacheModelProvider itself to find all cached 
data related to particular realm (in this case all applications, oauth 
clients, realm roles, app roles, users) and invalidate them?

Marek

From bburke at redhat.com  Tue Jul 15 10:43:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 10:43:17 -0400
Subject: [keycloak-dev] Issue with CacheModel
In-Reply-To: <53C520B0.3000604@redhat.com>
References: <53C520B0.3000604@redhat.com>
Message-ID: <53C53E05.8070708@redhat.com>

Ooops.  Good catch.

On 7/15/2014 8:38 AM, Marek Posolda wrote:
> Hi,
>
> During export/import I may want to remove some data (like realm) and
> overwrite it with imported one. But actually I have some issues during
> testing and looks like it's caused by the fact that not all the data are
> properly invalidated during removal of entities.
>
> For example when removing realm, there is just realm itself marked for
> invalidation
> https://github.com/keycloak/keycloak/blob/master/model/invalidation-cache/model-adapters/src/main/java/org/keycloak/models/cache/DefaultCacheModelProvider.java#L268
> . Actually with JPA model, the call to  getDelegate().removeRealm(id)
> also seems to invalidate application and application roles (due to the
> call to getApplicationById() which uses CacheModel) but realm roles,
> oauth clients and users are not invalidated. For Mongo model, there are
> no data invalidated at all.
>
> Question is if CacheModelProvider should rely on ModelProvider to
> invalidate cached data during getDelegate().removeRealm ? Shouldn't it
> be the responsibility of CacheModelProvider itself to find all cached
> data related to particular realm (in this case all applications, oauth
> clients, realm roles, app roles, users) and invalidate them?
>
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Tue Jul 15 10:50:32 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 15 Jul 2014 16:50:32 +0200
Subject: [keycloak-dev] Export/import into representations
Message-ID: <53C53FB8.9070509@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/523 for 
export/import with same representation as admin realm.

- It's still possible to export into encrypted ZIP file (default 
possibility), into directory or all realms into single JSON file.

- With export to directory, data of each realm are exported into 
separate file and users are also exported into separate file. It's 
configurable how many users will be in single file (By default it's 5000 
users per file) and it's using separate transaction per each file (set 
of users). So for example if you have realm with 20.000 users the realm 
will be exported into 5 separate files (1 file like "demo-realm.json" 
for realm data and 4 files like "demo-users-0.json", "demo-users-1.json" 
etc for users).

- Export to encrypted ZIP is quite similar like export to directory 
(realms and users in separate files inside ZIP), but all data are 
canonicalized. This is default possibility and is intended for 
production use

- Export into single JSON file allows to export all realms including 
users into single JSON file (array of RealmRepresentations). This is 
intended to be used mainly for development

- I've moved some code from "services" module as from there it's not 
available to export/import. I've moved class ModelToRepresentation to 
model/api and I've also extracted some code from managers (RealmManager, 
ApplicationManager, OAuthClientManager, RolesManager) to 
RepresentationToModel class.

- I've moved tests to testsuite/integration . Right now there is 
ExportImportTest, which tests all 3 providers (zip, dir, singleFile).

- Question: Is it plan to move some manager classes like RealmManager, 
ApplicationManager, OAuthClientManager and RolesManager to model/api as 
well? These don't have dependencies on other stuff in "services" and it 
will be useful for stuff like export/import to have them available. For 
example export/import may need the code for setup masterAdmin 
application (as if I import realm, I've need to check if particular 
master application like "demo-realm" exists in master realm and create 
it if doesn't, so I've needed to move some related code from 
RealmManager for setup this too).

- Export/import is still checked at server startup with system properties.
Question: How big priority it is to support export from admin console? 
TBH it shouldn't be hard to add it but it seems to me that this option 
is useful more for development than production as during export from 
admin console could be realm data edited in the meantime (For example if 
some other user registers himself in the meantime when admin triggered 
export). The solution might be JAX-RS or Http Filter, which will refuse 
request to realm when export is in progress. Do we want to go that way? 
Maybe just possibility to export current realm to single JSON file is 
sufficient in admin console?

Let me know if you have some other ideas/proposals

Thanks,
Marek

From stian at redhat.com  Tue Jul 15 10:51:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 15 Jul 2014 10:51:11 -0400 (EDT)
Subject: [keycloak-dev] Fixes for MySQL 5.1
In-Reply-To: <1970182879.10596875.1405435833564.JavaMail.zimbra@redhat.com>
Message-ID: <1994657155.10597257.1405435871690.JavaMail.zimbra@redhat.com>

I've added some fixes for MySQL 5.1 to https://github.com/stianst/keycloak/commit/723a50197ce4489c30d1ca3604c0eb915b01c1d5

Bill - can I commit this now? Or do you want me to wait until after you've finished (I don't mind merging it once it is)?

Basically it doesn't support keys longer than 1000 bytes, which turns out to be varchar 200, not 255 as default. So I've set all id's that are uuid's to 36, and the others to 200 (user username only, and only used as a foreign key in login failures).

From mposolda at redhat.com  Tue Jul 15 10:52:13 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 15 Jul 2014 16:52:13 +0200
Subject: [keycloak-dev] Issue with CacheModel
In-Reply-To: <53C53E05.8070708@redhat.com>
References: <53C520B0.3000604@redhat.com> <53C53E05.8070708@redhat.com>
Message-ID: <53C5401D.9040605@redhat.com>

I've added workaround to DefaultCacheModel.removeRealm for invalidate 
realm roles as I needed that to have test passing. Feel free to fix more 
properly once you figure out:-)

Marek

On 15.7.2014 16:43, Bill Burke wrote:
> Ooops.  Good catch.
>
> On 7/15/2014 8:38 AM, Marek Posolda wrote:
>> Hi,
>>
>> During export/import I may want to remove some data (like realm) and
>> overwrite it with imported one. But actually I have some issues during
>> testing and looks like it's caused by the fact that not all the data are
>> properly invalidated during removal of entities.
>>
>> For example when removing realm, there is just realm itself marked for
>> invalidation
>> https://github.com/keycloak/keycloak/blob/master/model/invalidation-cache/model-adapters/src/main/java/org/keycloak/models/cache/DefaultCacheModelProvider.java#L268
>> . Actually with JPA model, the call to  getDelegate().removeRealm(id)
>> also seems to invalidate application and application roles (due to the
>> call to getApplicationById() which uses CacheModel) but realm roles,
>> oauth clients and users are not invalidated. For Mongo model, there are
>> no data invalidated at all.
>>
>> Question is if CacheModelProvider should rely on ModelProvider to
>> invalidate cached data during getDelegate().removeRealm ? Shouldn't it
>> be the responsibility of CacheModelProvider itself to find all cached
>> data related to particular realm (in this case all applications, oauth
>> clients, realm roles, app roles, users) and invalidate them?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Jul 15 11:13:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 15 Jul 2014 11:13:51 -0400 (EDT)
Subject: [keycloak-dev] Export/import into representations
In-Reply-To: <53C53FB8.9070509@redhat.com>
References: <53C53FB8.9070509@redhat.com>
Message-ID: <2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>

Great stuff Marek

Some comments inline

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 15 July, 2014 3:50:32 PM
> Subject: [keycloak-dev] Export/import into representations
> 
> I've sent PR https://github.com/keycloak/keycloak/pull/523 for
> export/import with same representation as admin realm.
> 
> - It's still possible to export into encrypted ZIP file (default
> possibility), into directory or all realms into single JSON file.
> 
> - With export to directory, data of each realm are exported into
> separate file and users are also exported into separate file. It's
> configurable how many users will be in single file (By default it's 5000
> users per file) and it's using separate transaction per each file (set
> of users). So for example if you have realm with 20.000 users the realm
> will be exported into 5 separate files (1 file like "demo-realm.json"
> for realm data and 4 files like "demo-users-0.json", "demo-users-1.json"
> etc for users).
> 
> - Export to encrypted ZIP is quite similar like export to directory
> (realms and users in separate files inside ZIP), but all data are
> canonicalized. This is default possibility and is intended for
> production use
> 
> - Export into single JSON file allows to export all realms including
> users into single JSON file (array of RealmRepresentations). This is
> intended to be used mainly for development
> 
> - I've moved some code from "services" module as from there it's not
> available to export/import. I've moved class ModelToRepresentation to
> model/api and I've also extracted some code from managers (RealmManager,
> ApplicationManager, OAuthClientManager, RolesManager) to
> RepresentationToModel class.
> 
> - I've moved tests to testsuite/integration . Right now there is
> ExportImportTest, which tests all 3 providers (zip, dir, singleFile).
> 
> - Question: Is it plan to move some manager classes like RealmManager,
> ApplicationManager, OAuthClientManager and RolesManager to model/api as
> well? These don't have dependencies on other stuff in "services" and it
> will be useful for stuff like export/import to have them available. For
> example export/import may need the code for setup masterAdmin
> application (as if I import realm, I've need to check if particular
> master application like "demo-realm" exists in master realm and create
> it if doesn't, so I've needed to move some related code from
> RealmManager for setup this too).

+1

> 
> - Export/import is still checked at server startup with system properties.
> Question: How big priority it is to support export from admin console?
> TBH it shouldn't be hard to add it but it seems to me that this option
> is useful more for development than production as during export from
> admin console could be realm data edited in the meantime (For example if
> some other user registers himself in the meantime when admin triggered
> export). The solution might be JAX-RS or Http Filter, which will refuse
> request to realm when export is in progress. Do we want to go that way?
> Maybe just possibility to export current realm to single JSON file is
> sufficient in admin console?

It could be nice to be able to export realms through the console. For exporting realm we could disable any calls to admin console to make sure realms don't change. For users we could disable account mngmt, required actions, registrations, and other things that'll do writes, while still allowing users to login etc.

LDAP/Sync is much higher priority IMO though. Probably best to post-pone this to later, or even wait until/if we get requests for it.

> 
> Let me know if you have some other ideas/proposals
> 
> Thanks,
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul 15 11:20:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 11:20:51 -0400
Subject: [keycloak-dev] Export/import into representations
In-Reply-To: <2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>
References: <53C53FB8.9070509@redhat.com>
	<2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>
Message-ID: <53C546D3.5000401@redhat.com>



On 7/15/2014 11:13 AM, Stian Thorgersen wrote:
>> - Question: Is it plan to move some manager classes like RealmManager,
>> ApplicationManager, OAuthClientManager and RolesManager to model/api as
>> well? These don't have dependencies on other stuff in "services" and it
>> will be useful for stuff like export/import to have them available. For
>> example export/import may need the code for setup masterAdmin
>> application (as if I import realm, I've need to check if particular
>> master application like "demo-realm" exists in master realm and create
>> it if doesn't, so I've needed to move some related code from
>> RealmManager for setup this too).
>
> +1
>

Can we wait on moving managers?  Please?  :)  BTW, I think there is 
JAX-RS code in some managers.

> LDAP/Sync is much higher priority IMO though. Probably best to post-pone this to later, or even wait until/if we get requests for it.
>

I'd really like to implement the ideas I talked about before about 
LDAP/Sync.  I was going to tackle that after UserProvider split (which 
should be today or tomorrow).


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

From stian at redhat.com  Tue Jul 15 11:49:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 15 Jul 2014 11:49:18 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <469700665.10636716.1405438861991.JavaMail.zimbra@redhat.com>
Message-ID: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>

After the token manager was made stateless the full code is sent in emails (reset password and verify email), this is not very nice as it's very long.

Two ideas on how to fix this:

1. Save the code (user sessions?) and convert back to sending just the code id in the email
2. Send the info required to create a code (clientId, scope, state and redirect encoded with the realm key)
3. Send a short code that has to be copied/pasted back into the current login form

My thoughts are:

1. Nice and simple, but requires "storing" the code temporarily. Another thing we could do is to associate it with the session, this would make sure the email can only be clicked by the user that actually initiated it.
2. Not so nice as I think it'll still create too long links (especially if redirect and state are big).
3. Kinda nice, but changes the way it all works. This may actually be the optimal and more secure way to do it though.

See https://issues.jboss.org/browse/KEYCLOAK-542 for how big the link in the email actually is ;)

From bburke at redhat.com  Tue Jul 15 11:59:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 11:59:02 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
Message-ID: <53C54FC6.5050301@redhat.com>

Can you wait to fix this?  I have changes everywhere. :)

But, I thought AccessCode could be:

id, session-id, timestamp

UserSession has a Enum login-state (logging-in, logged-in, etc.) and is 
associated with AccessCode and stores any information that is needed. 
FYI, the token is generated right now so scope doesn't have to be 
recalculated.  Maybe this isn't really an optimization as signature 
generation would take a lot longer :)

If that's what you're saying +1.

On 7/15/2014 11:49 AM, Stian Thorgersen wrote:
> After the token manager was made stateless the full code is sent in emails (reset password and verify email), this is not very nice as it's very long.
>
> Two ideas on how to fix this:
>
> 1. Save the code (user sessions?) and convert back to sending just the code id in the email
> 2. Send the info required to create a code (clientId, scope, state and redirect encoded with the realm key)
> 3. Send a short code that has to be copied/pasted back into the current login form
>
> My thoughts are:
>
> 1. Nice and simple, but requires "storing" the code temporarily. Another thing we could do is to associate it with the session, this would make sure the email can only be clicked by the user that actually initiated it.
> 2. Not so nice as I think it'll still create too long links (especially if redirect and state are big).
> 3. Kinda nice, but changes the way it all works. This may actually be the optimal and more secure way to do it though.
>
> See https://issues.jboss.org/browse/KEYCLOAK-542 for how big the link in the email actually is ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jul 15 12:34:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 15 Jul 2014 12:34:06 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C54FC6.5050301@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
Message-ID: <165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 15 July, 2014 4:59:02 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> Can you wait to fix this?  I have changes everywhere. :)

Yes, I was just thinking about how it could be done

> 
> But, I thought AccessCode could be:
> 
> id, session-id, timestamp
> 
> UserSession has a Enum login-state (logging-in, logged-in, etc.) and is
> associated with AccessCode and stores any information that is needed.
> FYI, the token is generated right now so scope doesn't have to be
> recalculated.  Maybe this isn't really an optimization as signature
> generation would take a lot longer :)
> 
> If that's what you're saying +1.

Are you referring to option 1, storing the required info in the user session temporarily? Not sure I understand the details about what you're proposing though.

> 
> On 7/15/2014 11:49 AM, Stian Thorgersen wrote:
> > After the token manager was made stateless the full code is sent in emails
> > (reset password and verify email), this is not very nice as it's very
> > long.
> >
> > Two ideas on how to fix this:
> >
> > 1. Save the code (user sessions?) and convert back to sending just the code
> > id in the email
> > 2. Send the info required to create a code (clientId, scope, state and
> > redirect encoded with the realm key)
> > 3. Send a short code that has to be copied/pasted back into the current
> > login form
> >
> > My thoughts are:
> >
> > 1. Nice and simple, but requires "storing" the code temporarily. Another
> > thing we could do is to associate it with the session, this would make
> > sure the email can only be clicked by the user that actually initiated it.
> > 2. Not so nice as I think it'll still create too long links (especially if
> > redirect and state are big).
> > 3. Kinda nice, but changes the way it all works. This may actually be the
> > optimal and more secure way to do it though.
> >
> > See https://issues.jboss.org/browse/KEYCLOAK-542 for how big the link in
> > the email actually is ;)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul 15 13:14:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 13:14:45 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
Message-ID: <53C56185.60301@redhat.com>



On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
>> If that's what you're saying +1.
>
> Are you referring to option 1, storing the required info in the user session temporarily? Not sure I understand the details about what you're proposing though.
>

Yes, option 1.  AccessCode should be associated with the user session. 
Appropriate state needs to be stored in the session as AccessCode 
currently saves a lot of stuff.

Then the code only has to contain:

id, session-id, timestamp



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

From bburke at redhat.com  Tue Jul 15 15:51:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 15:51:50 -0400
Subject: [keycloak-dev] ExportImportTest disabled, breaks build
Message-ID: <53C58656.2000703@redhat.com>

When running the ExportImportTest with the build it causes other tests 
to fail.  I spent an hour or two trying to figure it out, I couldn't. 
This is off of master *BEFORE* I did my big commit.  Its not a caching 
issue as I ran tests without the cache.  It seems that users are not 
being deleted.  There's some other issues too even if I change the 
usernames used in the ExportImportTest.

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

From bburke at redhat.com  Tue Jul 15 15:59:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 15 Jul 2014 15:59:24 -0400
Subject: [keycloak-dev] UserProvider merged
Message-ID: <53C5881C.7060404@redhat.com>

* ModelProvider renamed to RealmProvider
* All user related methods except for credential validation removed from 
RealmModel
* KeycloakSession.users() gets you a UserProvider
* All classes now use UserProvider to work with users.
* KeycloakSession.model() renamed to realms()
* There are two cache providers now.  One for realms, other for users.

TODO:
* JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to 
RoleEntity and RealmEntity respectively.  Do we want to keep these 
constraints?
* JPA and Mongo RealmEntity and UserEntity should be refactored to be 
attribute based as in the Hybrid model.  As Stian suggested, this will 
allow us flexibility in the future.
* Credential validation, update needs to move from RealmModel to 
UserProvider.  I'll do this tomorrow.



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

From stian at redhat.com  Wed Jul 16 04:23:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 04:23:11 -0400 (EDT)
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <53C5881C.7060404@redhat.com>
References: <53C5881C.7060404@redhat.com>
Message-ID: <1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 15 July, 2014 8:59:24 PM
> Subject: [keycloak-dev] UserProvider merged
> 
> * ModelProvider renamed to RealmProvider
> * All user related methods except for credential validation removed from
> RealmModel
> * KeycloakSession.users() gets you a UserProvider
> * All classes now use UserProvider to work with users.
> * KeycloakSession.model() renamed to realms()
> * There are two cache providers now.  One for realms, other for users.
> 
> TODO:
> * JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to
> RoleEntity and RealmEntity respectively.  Do we want to keep these
> constraints?

I think we should not have any direct links (i.e. foreign keys) between entities in user provider and realm provider.

> * JPA and Mongo RealmEntity and UserEntity should be refactored to be
> attribute based as in the Hybrid model.  As Stian suggested, this will
> allow us flexibility in the future.

I'd also like to have a generic configuration mechanism for providers. This would include being able to store configuration as well as change it through the admin console.

Potentially something I could work on while you guys do sync?

> * Credential validation, update needs to move from RealmModel to
> UserProvider.  I'll do this tomorrow.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 16 04:58:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 04:58:25 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C56185.60301@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
Message-ID: <1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>

Are you talking about reducing the size of the code altogether or just for the email links?

I was thinking about just saving the base64 encoded access-code with the user session temporarily, then sending the the access code id (36 char uuid as before) in the email. First time the user clicks on the link the access code would be removed from the session, so this would also make the links a one-time-click thing. 

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 15 July, 2014 6:14:45 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> 
> 
> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
> >> If that's what you're saying +1.
> >
> > Are you referring to option 1, storing the required info in the user
> > session temporarily? Not sure I understand the details about what you're
> > proposing though.
> >
> 
> Yes, option 1.  AccessCode should be associated with the user session.
> Appropriate state needs to be stored in the session as AccessCode
> currently saves a lot of stuff.
> 
> Then the code only has to contain:
> 
> id, session-id, timestamp
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Wed Jul 16 05:56:43 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 11:56:43 +0200
Subject: [keycloak-dev] Export/import into representations
In-Reply-To: <2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>
References: <53C53FB8.9070509@redhat.com>
	<2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>
Message-ID: <53C64C5B.5080109@redhat.com>

On 15.7.2014 17:13, Stian Thorgersen wrote:
> It could be nice to be able to export realms through the console. For exporting realm we could disable any calls to admin console to make sure realms don't change. For users we could disable account mngmt, required actions, registrations, and other things that'll do writes, while still allowing users to login etc.
I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-561 without 
fix version for now.

Marek

From mposolda at redhat.com  Wed Jul 16 05:59:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 11:59:52 +0200
Subject: [keycloak-dev] Export/import into representations
In-Reply-To: <53C546D3.5000401@redhat.com>
References: <53C53FB8.9070509@redhat.com>	<2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>
	<53C546D3.5000401@redhat.com>
Message-ID: <53C64D18.4020800@redhat.com>

On 15.7.2014 17:20, Bill Burke wrote:
>
> On 7/15/2014 11:13 AM, Stian Thorgersen wrote:
>>> - Question: Is it plan to move some manager classes like RealmManager,
>>> ApplicationManager, OAuthClientManager and RolesManager to model/api as
>>> well? These don't have dependencies on other stuff in "services" and it
>>> will be useful for stuff like export/import to have them available. For
>>> example export/import may need the code for setup masterAdmin
>>> application (as if I import realm, I've need to check if particular
>>> master application like "demo-realm" exists in master realm and create
>>> it if doesn't, so I've needed to move some related code from
>>> RealmManager for setup this too).
>> +1
>>
> Can we wait on moving managers?  Please?  :)  BTW, I think there is
> JAX-RS code in some managers.
yeah, I meant just RealmManager, ApplicationManager, OAuthClientManager 
and UserManager, which doesn't have dependency on JAX-RS and they deal 
mainly with model api.

Marek
>
>> LDAP/Sync is much higher priority IMO though. Probably best to post-pone this to later, or even wait until/if we get requests for it.
>>
> I'd really like to implement the ideas I talked about before about
> LDAP/Sync.  I was going to tackle that after UserProvider split (which
> should be today or tomorrow).
>
>


From mposolda at redhat.com  Wed Jul 16 06:01:49 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 12:01:49 +0200
Subject: [keycloak-dev] ExportImportTest disabled, breaks build
In-Reply-To: <53C58656.2000703@redhat.com>
References: <53C58656.2000703@redhat.com>
Message-ID: <53C64D8D.1050203@redhat.com>

Looks like Windows specific issue again as CI is failing as well, but 
just on Windows:-(

Will try to figure out windows machine, reproduce and fix it.

Marek

On 15.7.2014 21:51, Bill Burke wrote:
> When running the ExportImportTest with the build it causes other tests
> to fail.  I spent an hour or two trying to figure it out, I couldn't.
> This is off of master *BEFORE* I did my big commit.  Its not a caching
> issue as I ran tests without the cache.  It seems that users are not
> being deleted.  There's some other issues too even if I change the
> usernames used in the ExportImportTest.
>


From mposolda at redhat.com  Wed Jul 16 06:34:39 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 12:34:39 +0200
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>	<53C54FC6.5050301@redhat.com>	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
Message-ID: <53C6553F.6070805@redhat.com>

+1 to associate code with the UserSession and remove it once code is 
exchanged. This will also help to fix the issue we discussed before, 
that now it's possible to exchange same code multiple times, which is 
not in line with OAuth2 specs . Created 
https://issues.jboss.org/browse/KEYCLOAK-560 and linked with 
https://issues.jboss.org/browse/KEYCLOAK-542

Marek

On 16.7.2014 10:58, Stian Thorgersen wrote:
> Are you talking about reducing the size of the code altogether or just for the email links?
>
> I was thinking about just saving the base64 encoded access-code with the user session temporarily, then sending the the access code id (36 char uuid as before) in the email. First time the user clicks on the link the access code would be removed from the session, so this would also make the links a one-time-click thing.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 15 July, 2014 6:14:45 PM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>>
>>
>> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
>>>> If that's what you're saying +1.
>>> Are you referring to option 1, storing the required info in the user
>>> session temporarily? Not sure I understand the details about what you're
>>> proposing though.
>>>
>> Yes, option 1.  AccessCode should be associated with the user session.
>> Appropriate state needs to be stored in the session as AccessCode
>> currently saves a lot of stuff.
>>
>> Then the code only has to contain:
>>
>> id, session-id, timestamp
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Jul 16 06:54:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 06:54:11 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C6553F.6070805@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
Message-ID: <851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>

This is probably what you've said already Bill, but just to make sure:

1. Associate the required information to create a token from an access code with the user session (basically what's in AccessCodeEntry now)
2. The code that is sent as the query param only contains id, session-id, timestamp
3. Once we receive a code to swap for a token we remove the information added in 1 from the user session and use this to generate the token

Couple questions:

* Do we do this just for emails? or also for the code sent in login redirects?
* Do we really need session-id and timestamp, or isn't id enough?
* Isn't this pretty much just going back to state-full TokenManager except we're saving it in the UserSession instead of TokenManager itself? 

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 11:34:39 AM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> +1 to associate code with the UserSession and remove it once code is
> exchanged. This will also help to fix the issue we discussed before,
> that now it's possible to exchange same code multiple times, which is
> not in line with OAuth2 specs . Created
> https://issues.jboss.org/browse/KEYCLOAK-560 and linked with
> https://issues.jboss.org/browse/KEYCLOAK-542
> 
> Marek
> 
> On 16.7.2014 10:58, Stian Thorgersen wrote:
> > Are you talking about reducing the size of the code altogether or just for
> > the email links?
> >
> > I was thinking about just saving the base64 encoded access-code with the
> > user session temporarily, then sending the the access code id (36 char
> > uuid as before) in the email. First time the user clicks on the link the
> > access code would be removed from the session, so this would also make the
> > links a one-time-click thing.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 15 July, 2014 6:14:45 PM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >>
> >>
> >> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
> >>>> If that's what you're saying +1.
> >>> Are you referring to option 1, storing the required info in the user
> >>> session temporarily? Not sure I understand the details about what you're
> >>> proposing though.
> >>>
> >> Yes, option 1.  AccessCode should be associated with the user session.
> >> Appropriate state needs to be stored in the session as AccessCode
> >> currently saves a lot of stuff.
> >>
> >> Then the code only has to contain:
> >>
> >> id, session-id, timestamp
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Wed Jul 16 07:42:58 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 13:42:58 +0200
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
Message-ID: <53C66542.7050807@redhat.com>

On 16.7.2014 12:54, Stian Thorgersen wrote:
> This is probably what you've said already Bill, but just to make sure:
>
> 1. Associate the required information to create a token from an access code with the user session (basically what's in AccessCodeEntry now)
> 2. The code that is sent as the query param only contains id, session-id, timestamp
> 3. Once we receive a code to swap for a token we remove the information added in 1 from the user session and use this to generate the token
>
> Couple questions:
>
> * Do we do this just for emails? or also for the code sent in login redirects?
I would personally do it for all to avoid the possibility of exchange 
same code for token multiple times.
> * Do we really need session-id and timestamp, or isn't id enough?
I think that session-id is needed to find associated session? As request 
for exchanging code to token doesn't have access to browser cookie, so 
the info should be associated with the code parameter itself? Maybe 
another option is that UserSessionProvider will allow to find associated 
session by codeId (something like method on UserSessionProvider like:

UserSessionModel getUserSessionByCode(RealmModel realm, String code);

> * Isn't this pretty much just going back to state-full TokenManager except we're saving it in the UserSession instead of TokenManager itself?
IMO UserSessionProvider has possibilities, which TokenManager didn't 
have. Like storing sessions either inMemory or in DB (and hence be 
cluster-aware), periodic removal of expired sessions to avoid memory 
leaks etc.

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 11:34:39 AM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>> +1 to associate code with the UserSession and remove it once code is
>> exchanged. This will also help to fix the issue we discussed before,
>> that now it's possible to exchange same code multiple times, which is
>> not in line with OAuth2 specs . Created
>> https://issues.jboss.org/browse/KEYCLOAK-560 and linked with
>> https://issues.jboss.org/browse/KEYCLOAK-542
>>
>> Marek
>>
>> On 16.7.2014 10:58, Stian Thorgersen wrote:
>>> Are you talking about reducing the size of the code altogether or just for
>>> the email links?
>>>
>>> I was thinking about just saving the base64 encoded access-code with the
>>> user session temporarily, then sending the the access code id (36 char
>>> uuid as before) in the email. First time the user clicks on the link the
>>> access code would be removed from the session, so this would also make the
>>> links a one-time-click thing.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 15 July, 2014 6:14:45 PM
>>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
>>>> long
>>>>
>>>>
>>>>
>>>> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
>>>>>> If that's what you're saying +1.
>>>>> Are you referring to option 1, storing the required info in the user
>>>>> session temporarily? Not sure I understand the details about what you're
>>>>> proposing though.
>>>>>
>>>> Yes, option 1.  AccessCode should be associated with the user session.
>>>> Appropriate state needs to be stored in the session as AccessCode
>>>> currently saves a lot of stuff.
>>>>
>>>> Then the code only has to contain:
>>>>
>>>> id, session-id, timestamp
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Wed Jul 16 07:50:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 07:50:06 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C66542.7050807@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C66542.7050807@redhat.com>
Message-ID: <1447324187.11137163.1405511406672.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 12:42:58 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> On 16.7.2014 12:54, Stian Thorgersen wrote:
> > This is probably what you've said already Bill, but just to make sure:
> >
> > 1. Associate the required information to create a token from an access code
> > with the user session (basically what's in AccessCodeEntry now)
> > 2. The code that is sent as the query param only contains id, session-id,
> > timestamp
> > 3. Once we receive a code to swap for a token we remove the information
> > added in 1 from the user session and use this to generate the token
> >
> > Couple questions:
> >
> > * Do we do this just for emails? or also for the code sent in login
> > redirects?
> I would personally do it for all to avoid the possibility of exchange
> same code for token multiple times.
> > * Do we really need session-id and timestamp, or isn't id enough?
> I think that session-id is needed to find associated session? As request
> for exchanging code to token doesn't have access to browser cookie, so
> the info should be associated with the code parameter itself? Maybe
> another option is that UserSessionProvider will allow to find associated
> session by codeId (something like method on UserSessionProvider like:
> 
> UserSessionModel getUserSessionByCode(RealmModel realm, String code);

Yep, I was assuming you'd use the "code id" to lookup the access code details including the user session.

> 
> > * Isn't this pretty much just going back to state-full TokenManager except
> > we're saving it in the UserSession instead of TokenManager itself?
> IMO UserSessionProvider has possibilities, which TokenManager didn't
> have. Like storing sessions either inMemory or in DB (and hence be
> cluster-aware), periodic removal of expired sessions to avoid memory
> leaks etc.

Yup, but instead of making TokenManager have those options we made it stateless instead. By doing this we're going back to it being state-full. Just pointing out the obvious really ;) 

> 
> Marek
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 11:34:39 AM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >> +1 to associate code with the UserSession and remove it once code is
> >> exchanged. This will also help to fix the issue we discussed before,
> >> that now it's possible to exchange same code multiple times, which is
> >> not in line with OAuth2 specs . Created
> >> https://issues.jboss.org/browse/KEYCLOAK-560 and linked with
> >> https://issues.jboss.org/browse/KEYCLOAK-542
> >>
> >> Marek
> >>
> >> On 16.7.2014 10:58, Stian Thorgersen wrote:
> >>> Are you talking about reducing the size of the code altogether or just
> >>> for
> >>> the email links?
> >>>
> >>> I was thinking about just saving the base64 encoded access-code with the
> >>> user session temporarily, then sending the the access code id (36 char
> >>> uuid as before) in the email. First time the user clicks on the link the
> >>> access code would be removed from the session, so this would also make
> >>> the
> >>> links a one-time-click thing.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 15 July, 2014 6:14:45 PM
> >>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >>>> long
> >>>>
> >>>>
> >>>>
> >>>> On 7/15/2014 12:34 PM, Stian Thorgersen wrote:
> >>>>>> If that's what you're saying +1.
> >>>>> Are you referring to option 1, storing the required info in the user
> >>>>> session temporarily? Not sure I understand the details about what
> >>>>> you're
> >>>>> proposing though.
> >>>>>
> >>>> Yes, option 1.  AccessCode should be associated with the user session.
> >>>> Appropriate state needs to be stored in the session as AccessCode
> >>>> currently saves a lot of stuff.
> >>>>
> >>>> Then the code only has to contain:
> >>>>
> >>>> id, session-id, timestamp
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From bburke at redhat.com  Wed Jul 16 08:27:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 08:27:21 -0400
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
Message-ID: <53C66FA9.2020308@redhat.com>



On 7/16/2014 4:23 AM, Stian Thorgersen wrote:
>> * JPA and Mongo RealmEntity and UserEntity should be refactored to be
>> attribute based as in the Hybrid model.  As Stian suggested, this will
>> allow us flexibility in the future.
>
> I'd also like to have a generic configuration mechanism for providers. This would include being able to store configuration as well as change it through the admin console.
>
> Potentially something I could work on while you guys do sync?
>

This would overlap with sync refactor.  Just a thought, except for our 
base LDAP support, would we want generic config mechanism in admin 
console?  What if user needs something more than name/value pairs for 
config?


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

From bburke at redhat.com  Wed Jul 16 08:43:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 08:43:51 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C54FC6.5050301@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
Message-ID: <53C67387.3030202@redhat.com>



On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
> This is probably what you've said already Bill, but just to make sure:
>
> 1. Associate the required information to create a token from an access code with the user session (basically what's in AccessCodeEntry now)
> 2. The code that is sent as the query param only contains id, session-id, timestamp
> 3. Once we receive a code to swap for a token we remove the information added in 1 from the user session and use this to generate the token
>
> Couple questions:
>
> * Do we do this just for emails? or also for the code sent in login redirects?
> * Do we really need session-id and timestamp, or isn't id enough?

Actually, do we even need a specific access code?  Even for OAuth 2 
flow?  Just pass around the session id.  All information to validate 
calls, especially accessCodeToToken[1] should be in the UserSession. 
You just have to make absolutely sure you are validating redirect uri 
and client-id to guard against swapping.

> * Isn't this pretty much just going back to state-full TokenManager except we're saving it in the UserSession instead of TokenManager itself?
>

Yup. :)  LOL!!!!!

[1] http://tools.ietf.org/html/rfc6749#section-4.1.3



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

From bburke at redhat.com  Wed Jul 16 08:47:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 08:47:53 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C67387.3030202@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>	<53C54FC6.5050301@redhat.com>	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>	<53C56185.60301@redhat.com>	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>	<53C6553F.6070805@redhat.com>	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com>
Message-ID: <53C67479.3000404@redhat.com>



On 7/16/2014 8:43 AM, Bill Burke wrote:
>
>
> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>> This is probably what you've said already Bill, but just to make sure:
>>
>> 1. Associate the required information to create a token from an access code with the user session (basically what's in AccessCodeEntry now)
>> 2. The code that is sent as the query param only contains id, session-id, timestamp
>> 3. Once we receive a code to swap for a token we remove the information added in 1 from the user session and use this to generate the token
>>
>> Couple questions:
>>
>> * Do we do this just for emails? or also for the code sent in login redirects?
>> * Do we really need session-id and timestamp, or isn't id enough?
>
> Actually, do we even need a specific access code?  Even for OAuth 2
> flow?  Just pass around the session id.  All information to validate
> calls, especially accessCodeToToken[1] should be in the UserSession.
> You just have to make absolutely sure you are validating redirect uri
> and client-id to guard against swapping.
>

Actually maybe the access code should be a digitally signed session-id? 
  Then you're fully protected from people guessing session-ids. 
Granted, the window to guess is relatively short.  *shrug* I don't know. :)

>> * Isn't this pretty much just going back to state-full TokenManager except we're saving it in the UserSession instead of TokenManager itself?
>>
>
> Yup. :)  LOL!!!!!
>
> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
>
>
>

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

From stian at redhat.com  Wed Jul 16 08:47:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 08:47:55 -0400 (EDT)
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <53C66FA9.2020308@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
	<53C66FA9.2020308@redhat.com>
Message-ID: <939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 1:27:21 PM
> Subject: Re: [keycloak-dev] UserProvider merged
> 
> 
> 
> On 7/16/2014 4:23 AM, Stian Thorgersen wrote:
> >> * JPA and Mongo RealmEntity and UserEntity should be refactored to be
> >> attribute based as in the Hybrid model.  As Stian suggested, this will
> >> allow us flexibility in the future.
> >
> > I'd also like to have a generic configuration mechanism for providers. This
> > would include being able to store configuration as well as change it
> > through the admin console.
> >
> > Potentially something I could work on while you guys do sync?
> >
> 
> This would overlap with sync refactor.  Just a thought, except for our
> base LDAP support, would we want generic config mechanism in admin
> console?  What if user needs something more than name/value pairs for
> config?

Generic config mechanism for sync you mean?

I was thinking it would be nice to have something available to all SPIs and providers. Name/value pairs would be simplest with regards to storing and also editing through the admin console.


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

From stian at redhat.com  Wed Jul 16 08:56:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 08:56:09 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C67479.3000404@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
Message-ID: <239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 1:47:53 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> 
> 
> On 7/16/2014 8:43 AM, Bill Burke wrote:
> >
> >
> > On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
> >> This is probably what you've said already Bill, but just to make sure:
> >>
> >> 1. Associate the required information to create a token from an access
> >> code with the user session (basically what's in AccessCodeEntry now)
> >> 2. The code that is sent as the query param only contains id, session-id,
> >> timestamp
> >> 3. Once we receive a code to swap for a token we remove the information
> >> added in 1 from the user session and use this to generate the token
> >>
> >> Couple questions:
> >>
> >> * Do we do this just for emails? or also for the code sent in login
> >> redirects?
> >> * Do we really need session-id and timestamp, or isn't id enough?
> >
> > Actually, do we even need a specific access code?  Even for OAuth 2
> > flow?  Just pass around the session id.  All information to validate
> > calls, especially accessCodeToToken[1] should be in the UserSession.
> > You just have to make absolutely sure you are validating redirect uri
> > and client-id to guard against swapping.
> >
> 
> Actually maybe the access code should be a digitally signed session-id?
>   Then you're fully protected from people guessing session-ids.
> Granted, the window to guess is relatively short.  *shrug* I don't know. :)

It can't just be session-id as there's multiple apps/clients per-session, also even multiple logins for a single app. How about session-id + client-id + timestamp, and we sign it as well?

> 
> >> * Isn't this pretty much just going back to state-full TokenManager except
> >> we're saving it in the UserSession instead of TokenManager itself?
> >>
> >
> > Yup. :)  LOL!!!!!
> >
> > [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
> >
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Jul 16 08:59:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 08:59:51 -0400
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
	<53C66FA9.2020308@redhat.com>
	<939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>
Message-ID: <53C67747.6060900@redhat.com>



On 7/16/2014 8:47 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 1:27:21 PM
>> Subject: Re: [keycloak-dev] UserProvider merged
>>
>>
>>
>> On 7/16/2014 4:23 AM, Stian Thorgersen wrote:
>>>> * JPA and Mongo RealmEntity and UserEntity should be refactored to be
>>>> attribute based as in the Hybrid model.  As Stian suggested, this will
>>>> allow us flexibility in the future.
>>>
>>> I'd also like to have a generic configuration mechanism for providers. This
>>> would include being able to store configuration as well as change it
>>> through the admin console.
>>>
>>> Potentially something I could work on while you guys do sync?
>>>
>>
>> This would overlap with sync refactor.  Just a thought, except for our
>> base LDAP support, would we want generic config mechanism in admin
>> console?  What if user needs something more than name/value pairs for
>> config?
>

Re-reading what you wrote, maybe I misunderstood?  You want a generic 
way to store and manage keycloak-server.json through admin console?


> Generic config mechanism for sync you mean?
>

Yes.

I think sync is in two parts:

* A UserProvider.  For on-demand sync.
* A "chron job" for periodic bulk sync.

Both would want generic config mechanism and realm-specific storage for 
this config.

> I was thinking it would be nice to have something available to all SPIs and providers. Name/value pairs would be simplest with regards to storing and also editing through the admin console.
>

What are the security implications of this in a multi-tenant 
environment?  Might not want a specific realm admin to be able to modify 
keycloak-server.json


What about just allowing user to enter in Json?



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

From mposolda at redhat.com  Wed Jul 16 09:05:15 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 15:05:15 +0200
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>	<53C56185.60301@redhat.com>	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>	<53C6553F.6070805@redhat.com>	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>	<53C67387.3030202@redhat.com>
	<53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
Message-ID: <53C6788B.5040603@redhat.com>

On 16.7.2014 14:56, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>>
>>
>> On 7/16/2014 8:43 AM, Bill Burke wrote:
>>>
>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>>>> This is probably what you've said already Bill, but just to make sure:
>>>>
>>>> 1. Associate the required information to create a token from an access
>>>> code with the user session (basically what's in AccessCodeEntry now)
>>>> 2. The code that is sent as the query param only contains id, session-id,
>>>> timestamp
>>>> 3. Once we receive a code to swap for a token we remove the information
>>>> added in 1 from the user session and use this to generate the token
>>>>
>>>> Couple questions:
>>>>
>>>> * Do we do this just for emails? or also for the code sent in login
>>>> redirects?
>>>> * Do we really need session-id and timestamp, or isn't id enough?
>>> Actually, do we even need a specific access code?  Even for OAuth 2
>>> flow?  Just pass around the session id.  All information to validate
>>> calls, especially accessCodeToToken[1] should be in the UserSession.
>>> You just have to make absolutely sure you are validating redirect uri
>>> and client-id to guard against swapping.
>>>
>> Actually maybe the access code should be a digitally signed session-id?
>>    Then you're fully protected from people guessing session-ids.
>> Granted, the window to guess is relatively short.  *shrug* I don't know. :)
> It can't just be session-id as there's multiple apps/clients per-session, also even multiple logins for a single app. How about session-id + client-id + timestamp, and we sign it as well?
Sorry to mention it again, but looks that this is still not enough to 
help with the requirement of "Authorization codes MUST be short lived 
and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)

Marek
>
>>>> * Isn't this pretty much just going back to state-full TokenManager except
>>>> we're saving it in the UserSession instead of TokenManager itself?
>>>>
>>> Yup. :)  LOL!!!!!
>>>
>>> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
>>>
>>>
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Jul 16 09:08:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 09:08:11 -0400 (EDT)
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <53C67747.6060900@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
	<53C66FA9.2020308@redhat.com>
	<939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>
	<53C67747.6060900@redhat.com>
Message-ID: <643843464.11191522.1405516091677.JavaMail.zimbra@redhat.com>

The idea for provider config was:

A provider can have a server-wide config (keycloak-server.json) as well as realm-specific configs. 

Server-wide config would at least initially be configured only through keycloak-server.json and would also require a server restart. We could look at making this configurable through admin console as well.

Realm specific config would be configurable through the admin console. You would go to a "Providers" tab in the admin console, then you'd have a menu that lists out all SPIs. So you would for example click on Sync. You could then configure which Sync providers are enabled for the Realm, as well as set configuration for them. With regards to config I thought key/value would be sufficient, and much simpler to deal with.
 
With that regards it would probably make sense that KeycloakSession would be bound to a specific realm so we could create Provider instances with the correct config.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 1:59:51 PM
> Subject: Re: [keycloak-dev] UserProvider merged
> 
> 
> 
> On 7/16/2014 8:47 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 1:27:21 PM
> >> Subject: Re: [keycloak-dev] UserProvider merged
> >>
> >>
> >>
> >> On 7/16/2014 4:23 AM, Stian Thorgersen wrote:
> >>>> * JPA and Mongo RealmEntity and UserEntity should be refactored to be
> >>>> attribute based as in the Hybrid model.  As Stian suggested, this will
> >>>> allow us flexibility in the future.
> >>>
> >>> I'd also like to have a generic configuration mechanism for providers.
> >>> This
> >>> would include being able to store configuration as well as change it
> >>> through the admin console.
> >>>
> >>> Potentially something I could work on while you guys do sync?
> >>>
> >>
> >> This would overlap with sync refactor.  Just a thought, except for our
> >> base LDAP support, would we want generic config mechanism in admin
> >> console?  What if user needs something more than name/value pairs for
> >> config?
> >
> 
> Re-reading what you wrote, maybe I misunderstood?  You want a generic
> way to store and manage keycloak-server.json through admin console?
> 
> 
> > Generic config mechanism for sync you mean?
> >
> 
> Yes.
> 
> I think sync is in two parts:
> 
> * A UserProvider.  For on-demand sync.
> * A "chron job" for periodic bulk sync.
> 
> Both would want generic config mechanism and realm-specific storage for
> this config.
> 
> > I was thinking it would be nice to have something available to all SPIs and
> > providers. Name/value pairs would be simplest with regards to storing and
> > also editing through the admin console.
> >
> 
> What are the security implications of this in a multi-tenant
> environment?  Might not want a specific realm admin to be able to modify
> keycloak-server.json
> 
> 
> What about just allowing user to enter in Json?
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Wed Jul 16 09:09:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 09:09:22 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>
	<53C56185.60301@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
Message-ID: <53C67982.2070601@redhat.com>



On 7/16/2014 8:56 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>>
>>
>> On 7/16/2014 8:43 AM, Bill Burke wrote:
>>>
>>>
>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>>>> This is probably what you've said already Bill, but just to make sure:
>>>>
>>>> 1. Associate the required information to create a token from an access
>>>> code with the user session (basically what's in AccessCodeEntry now)
>>>> 2. The code that is sent as the query param only contains id, session-id,
>>>> timestamp
>>>> 3. Once we receive a code to swap for a token we remove the information
>>>> added in 1 from the user session and use this to generate the token
>>>>
>>>> Couple questions:
>>>>
>>>> * Do we do this just for emails? or also for the code sent in login
>>>> redirects?
>>>> * Do we really need session-id and timestamp, or isn't id enough?
>>>
>>> Actually, do we even need a specific access code?  Even for OAuth 2
>>> flow?  Just pass around the session id.  All information to validate
>>> calls, especially accessCodeToToken[1] should be in the UserSession.
>>> You just have to make absolutely sure you are validating redirect uri
>>> and client-id to guard against swapping.
>>>
>>
>> Actually maybe the access code should be a digitally signed session-id?
>>    Then you're fully protected from people guessing session-ids.
>> Granted, the window to guess is relatively short.  *shrug* I don't know. :)
>
> It can't just be session-id as there's multiple apps/clients per-session, also even multiple logins for a single app. How about session-id + client-id + timestamp, and we sign it as well?
>

OH yeah...right.  Ugh.

Dont you really just need access-code-id and session-id?  UserSession 
stores the rest of the state needed to verify and expire codes, specific 
to each access-code.  Maybe ClientUserSessionAssociationEntity 
transforms into this access-code storage.  Then you could keep track of 
when a token was created for this client, when access code was created, 
state of access-code flow, etc.


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

From stian at redhat.com  Wed Jul 16 09:09:37 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 09:09:37 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C6788B.5040603@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
Message-ID: <1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 2:05:15 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> On 16.7.2014 14:56, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 1:47:53 PM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >>
> >>
> >> On 7/16/2014 8:43 AM, Bill Burke wrote:
> >>>
> >>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
> >>>> This is probably what you've said already Bill, but just to make sure:
> >>>>
> >>>> 1. Associate the required information to create a token from an access
> >>>> code with the user session (basically what's in AccessCodeEntry now)
> >>>> 2. The code that is sent as the query param only contains id,
> >>>> session-id,
> >>>> timestamp
> >>>> 3. Once we receive a code to swap for a token we remove the information
> >>>> added in 1 from the user session and use this to generate the token
> >>>>
> >>>> Couple questions:
> >>>>
> >>>> * Do we do this just for emails? or also for the code sent in login
> >>>> redirects?
> >>>> * Do we really need session-id and timestamp, or isn't id enough?
> >>> Actually, do we even need a specific access code?  Even for OAuth 2
> >>> flow?  Just pass around the session id.  All information to validate
> >>> calls, especially accessCodeToToken[1] should be in the UserSession.
> >>> You just have to make absolutely sure you are validating redirect uri
> >>> and client-id to guard against swapping.
> >>>
> >> Actually maybe the access code should be a digitally signed session-id?
> >>    Then you're fully protected from people guessing session-ids.
> >> Granted, the window to guess is relatively short.  *shrug* I don't know.
> >> :)
> > It can't just be session-id as there's multiple apps/clients per-session,
> > also even multiple logins for a single app. How about session-id +
> > client-id + timestamp, and we sign it as well?
> Sorry to mention it again, but looks that this is still not enough to
> help with the requirement of "Authorization codes MUST be short lived
> and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)

Short lived would be covered as there's a timestamp. For single-use we'd have to add the timestamp to the user session or somethin'

> 
> Marek
> >
> >>>> * Isn't this pretty much just going back to state-full TokenManager
> >>>> except
> >>>> we're saving it in the UserSession instead of TokenManager itself?
> >>>>
> >>> Yup. :)  LOL!!!!!
> >>>
> >>> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
> >>>
> >>>
> >>>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Wed Jul 16 09:09:50 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 15:09:50 +0200
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C6788B.5040603@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>	<165115536.10772725.1405442046884.JavaMail.zimbra@redhat.com>	<53C56185.60301@redhat.com>	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>	<53C6553F.6070805@redhat.com>	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>	<53C67387.3030202@redhat.com>	<53C67479.3000404@redhat.com>	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
Message-ID: <53C6799E.5060908@redhat.com>

On 16.7.2014 15:05, Marek Posolda wrote:
> On 16.7.2014 14:56, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>>
>>>
>>>
>>> On 7/16/2014 8:43 AM, Bill Burke wrote:
>>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>>>>> This is probably what you've said already Bill, but just to make sure:
>>>>>
>>>>> 1. Associate the required information to create a token from an access
>>>>> code with the user session (basically what's in AccessCodeEntry now)
>>>>> 2. The code that is sent as the query param only contains id, session-id,
>>>>> timestamp
>>>>> 3. Once we receive a code to swap for a token we remove the information
>>>>> added in 1 from the user session and use this to generate the token
>>>>>
>>>>> Couple questions:
>>>>>
>>>>> * Do we do this just for emails? or also for the code sent in login
>>>>> redirects?
>>>>> * Do we really need session-id and timestamp, or isn't id enough?
>>>> Actually, do we even need a specific access code?  Even for OAuth 2
>>>> flow?  Just pass around the session id.  All information to validate
>>>> calls, especially accessCodeToToken[1] should be in the UserSession.
>>>> You just have to make absolutely sure you are validating redirect uri
>>>> and client-id to guard against swapping.
>>>>
>>> Actually maybe the access code should be a digitally signed session-id?
>>>     Then you're fully protected from people guessing session-ids.
>>> Granted, the window to guess is relatively short.  *shrug* I don't know. :)
>> It can't just be session-id as there's multiple apps/clients per-session, also even multiple logins for a single app. How about session-id + client-id + timestamp, and we sign it as well?
> Sorry to mention it again, but looks that this is still not enough to
> help with the requirement of "Authorization codes MUST be short lived
> and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)
Or maybe we can just revoke the request is client with particular 
"client_id" is already associated with this session?

>
> Marek
>>>>> * Isn't this pretty much just going back to state-full TokenManager except
>>>>> we're saving it in the UserSession instead of TokenManager itself?
>>>>>
>>>> Yup. :)  LOL!!!!!
>>>>
>>>> [1] http://tools.ietf.org/html/rfc6749#section-4.1.3
>>>>
>>>>
>>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Jul 16 09:11:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 09:11:21 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C67982.2070601@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C67982.2070601@redhat.com>
Message-ID: <1446172311.11193567.1405516281814.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 2:09:22 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> 
> 
> On 7/16/2014 8:56 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 1:47:53 PM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >>
> >>
> >> On 7/16/2014 8:43 AM, Bill Burke wrote:
> >>>
> >>>
> >>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
> >>>> This is probably what you've said already Bill, but just to make sure:
> >>>>
> >>>> 1. Associate the required information to create a token from an access
> >>>> code with the user session (basically what's in AccessCodeEntry now)
> >>>> 2. The code that is sent as the query param only contains id,
> >>>> session-id,
> >>>> timestamp
> >>>> 3. Once we receive a code to swap for a token we remove the information
> >>>> added in 1 from the user session and use this to generate the token
> >>>>
> >>>> Couple questions:
> >>>>
> >>>> * Do we do this just for emails? or also for the code sent in login
> >>>> redirects?
> >>>> * Do we really need session-id and timestamp, or isn't id enough?
> >>>
> >>> Actually, do we even need a specific access code?  Even for OAuth 2
> >>> flow?  Just pass around the session id.  All information to validate
> >>> calls, especially accessCodeToToken[1] should be in the UserSession.
> >>> You just have to make absolutely sure you are validating redirect uri
> >>> and client-id to guard against swapping.
> >>>
> >>
> >> Actually maybe the access code should be a digitally signed session-id?
> >>    Then you're fully protected from people guessing session-ids.
> >> Granted, the window to guess is relatively short.  *shrug* I don't know.
> >> :)
> >
> > It can't just be session-id as there's multiple apps/clients per-session,
> > also even multiple logins for a single app. How about session-id +
> > client-id + timestamp, and we sign it as well?
> >
> 
> OH yeah...right.  Ugh.
> 
> Dont you really just need access-code-id and session-id?  UserSession
> stores the rest of the state needed to verify and expire codes, specific
> to each access-code.  Maybe ClientUserSessionAssociationEntity
> transforms into this access-code storage.  Then you could keep track of
> when a token was created for this client, when access code was created,
> state of access-code flow, etc.

Yup, I think something like that would be the best way to go. Don't even need session-id in that case, as we should be able to retrieve this based on just the access-code-id.

We'd only need to make sure the access-code-id was safe to use so that it can't be guessed, or as you say slap on a digital signature. 

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

From bburke at redhat.com  Wed Jul 16 09:14:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 09:14:45 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<1696455477.11064210.1405501105081.JavaMail.zimbra@redhat.com>
	<53C6553F.6070805@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
	<1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
Message-ID: <53C67AC5.2000103@redhat.com>



On 7/16/2014 9:09 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 2:05:15 PM
>> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
>>
>> On 16.7.2014 14:56, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
>>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
>>>> long
>>>>
>>>>
>>>>
>>>> On 7/16/2014 8:43 AM, Bill Burke wrote:
>>>>>
>>>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
>>>>>> This is probably what you've said already Bill, but just to make sure:
>>>>>>
>>>>>> 1. Associate the required information to create a token from an access
>>>>>> code with the user session (basically what's in AccessCodeEntry now)
>>>>>> 2. The code that is sent as the query param only contains id,
>>>>>> session-id,
>>>>>> timestamp
>>>>>> 3. Once we receive a code to swap for a token we remove the information
>>>>>> added in 1 from the user session and use this to generate the token
>>>>>>
>>>>>> Couple questions:
>>>>>>
>>>>>> * Do we do this just for emails? or also for the code sent in login
>>>>>> redirects?
>>>>>> * Do we really need session-id and timestamp, or isn't id enough?
>>>>> Actually, do we even need a specific access code?  Even for OAuth 2
>>>>> flow?  Just pass around the session id.  All information to validate
>>>>> calls, especially accessCodeToToken[1] should be in the UserSession.
>>>>> You just have to make absolutely sure you are validating redirect uri
>>>>> and client-id to guard against swapping.
>>>>>
>>>> Actually maybe the access code should be a digitally signed session-id?
>>>>     Then you're fully protected from people guessing session-ids.
>>>> Granted, the window to guess is relatively short.  *shrug* I don't know.
>>>> :)
>>> It can't just be session-id as there's multiple apps/clients per-session,
>>> also even multiple logins for a single app. How about session-id +
>>> client-id + timestamp, and we sign it as well?
>> Sorry to mention it again, but looks that this is still not enough to
>> help with the requirement of "Authorization codes MUST be short lived
>> and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)
>
> Short lived would be covered as there's a timestamp. For single-use we'd have to add the timestamp to the user session or somethin'
>

See my last email.  Just store everything within 
ClientUserSessionAssociationEntity and have a 
ClientUserSessionAssociationEntity per access-code.

class ClientUserSessionAssociationEntity {

    @Id
    String accessCode;

    @ManyToOne
    UserSessionEntity session;

    boolean accessCodeActive;

    long timestamp;

    String clientId;

}




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

From bburke at redhat.com  Wed Jul 16 09:25:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 09:25:36 -0400
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <643843464.11191522.1405516091677.JavaMail.zimbra@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
	<53C66FA9.2020308@redhat.com>
	<939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>
	<53C67747.6060900@redhat.com>
	<643843464.11191522.1405516091677.JavaMail.zimbra@redhat.com>
Message-ID: <53C67D50.4020502@redhat.com>



On 7/16/2014 9:08 AM, Stian Thorgersen wrote:
> The idea for provider config was:
>
> A provider can have a server-wide config (keycloak-server.json) as well as realm-specific configs.
>
> Server-wide config would at least initially be configured only through keycloak-server.json and would also require a server restart. We could look at making this configurable through admin console as well.
>
> Realm specific config would be configurable through the admin console. You would go to a "Providers" tab in the admin console, then you'd have a menu that lists out all SPIs. So you would for example click on Sync. You could then configure which Sync providers are enabled for the Realm, as well as set configuration for them. With regards to config I thought key/value would be sufficient, and much simpler to deal with.
>
> With that regards it would probably make sense that KeycloakSession would be bound to a specific realm so we could create Provider instances with the correct config.
>

Don't you have a Catch 22 with KeycloakSession and RealmProvider?

For sync/federation I was thinking that KeycloakSession.users() would 
take a RealmModel parameter though.

Maybe something like this for an SPI?

interface RealmLoadedProviderFactory<T extends Provider> {

     T createProvider(KeycloakSession session, RealmModel realm);
}


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

From stian at redhat.com  Wed Jul 16 09:29:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 09:29:49 -0400 (EDT)
Subject: [keycloak-dev] UserProvider merged
In-Reply-To: <53C67D50.4020502@redhat.com>
References: <53C5881C.7060404@redhat.com>
	<1221331337.11053630.1405498991734.JavaMail.zimbra@redhat.com>
	<53C66FA9.2020308@redhat.com>
	<939220489.11173448.1405514875109.JavaMail.zimbra@redhat.com>
	<53C67747.6060900@redhat.com>
	<643843464.11191522.1405516091677.JavaMail.zimbra@redhat.com>
	<53C67D50.4020502@redhat.com>
Message-ID: <2137432983.11209060.1405517389480.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 2:25:36 PM
> Subject: Re: [keycloak-dev] UserProvider merged
> 
> 
> 
> On 7/16/2014 9:08 AM, Stian Thorgersen wrote:
> > The idea for provider config was:
> >
> > A provider can have a server-wide config (keycloak-server.json) as well as
> > realm-specific configs.
> >
> > Server-wide config would at least initially be configured only through
> > keycloak-server.json and would also require a server restart. We could
> > look at making this configurable through admin console as well.
> >
> > Realm specific config would be configurable through the admin console. You
> > would go to a "Providers" tab in the admin console, then you'd have a menu
> > that lists out all SPIs. So you would for example click on Sync. You could
> > then configure which Sync providers are enabled for the Realm, as well as
> > set configuration for them. With regards to config I thought key/value
> > would be sufficient, and much simpler to deal with.
> >
> > With that regards it would probably make sense that KeycloakSession would
> > be bound to a specific realm so we could create Provider instances with
> > the correct config.
> >
> 
> Don't you have a Catch 22 with KeycloakSession and RealmProvider?

True - would it make sense to add a higher level thing for listing realms, adding/removing realms? 99% of the code would still use KeycloakSession which is bound to one Realm. Only RealmsResource would need to use that stuff.

> 
> For sync/federation I was thinking that KeycloakSession.users() would
> take a RealmModel parameter though.
> 
> Maybe something like this for an SPI?
> 
> interface RealmLoadedProviderFactory<T extends Provider> {
> 
>      T createProvider(KeycloakSession session, RealmModel realm);
> }
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Wed Jul 16 10:12:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 10:12:15 -0400 (EDT)
Subject: [keycloak-dev] Remaining work and who does what for beta-4
In-Reply-To: <475141861.11234910.1405519048076.JavaMail.zimbra@redhat.com>
Message-ID: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>

Now that the craziness of splitting the model is behind us I think we should figure out exactly what's left to do for beta-4, who's doing what and an estimated release date.

Here's the list of things I can come up with:

1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to RoleEntity and RealmEntity respectively.
2. JPA and Mongo RealmEntity and UserEntity should be refactored to be attribute based as in the Hybrid model.
3. Credential validation, update needs to move from RealmModel to UserProvider.
4. Sync support in UserProvider
5. LDAP implementation for 4
6. Access code work (reducing code size, email link size, single-use code, etc.)
7. Pagination support for users
8. Improve delete of users

My vote is yes to all above!

Also, a couple of things we should consider:

9. Add generic configuration for providers, including the ability to configure any providers through the admin console
10. Have KeycloakSession bound to a specific realm

My suggestion is:

* Bill - works on sync support in UserSession 
* Marek - works on LDAP implementation for sync
* Stian - I can either get started on 9 and 10, or scrape of the rest. Depends on whether or not we decide to do them or not.

If we're going to have a chance of releasing 1.0.final in August, I think we should aim at having beta-4 (with an actual code freeze!) towards the end of July. We'll need at least 1 month to do tests, security audit, update docs, etc.

Also, I'm away 13 days and Marek is away 8 days in August!

From bburke at redhat.com  Wed Jul 16 11:12:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 11:12:51 -0400
Subject: [keycloak-dev] Remaining work and who does what for beta-4
In-Reply-To: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>
References: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>
Message-ID: <53C69673.8050401@redhat.com>



On 7/16/2014 10:12 AM, Stian Thorgersen wrote:
> Now that the craziness of splitting the model is behind us I think we should figure out exactly what's left to do for beta-4, who's doing what and an estimated release date.
>
> Here's the list of things I can come up with:
>
> 1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to RoleEntity and RealmEntity respectively.
> 2. JPA and Mongo RealmEntity and UserEntity should be refactored to be attribute based as in the Hybrid model.
> 3. Credential validation, update needs to move from RealmModel to UserProvider.
> 4. Sync support in UserProvider
> 5. LDAP implementation for 4
> 6. Access code work (reducing code size, email link size, single-use code, etc.)
> 7. Pagination support for users
> 8. Improve delete of users
>
> My vote is yes to all above!
>
> Also, a couple of things we should consider:
>
> 9. Add generic configuration for providers, including the ability to configure any providers through the admin console
> 10. Have KeycloakSession bound to a specific realm
>

I'm working on 1-5 and 8.  I think I can be done in 5-7 business days. 
1-3, 8 are really easy, at least for JPA.  Was going to copy what stian 
did for Hybrid for attribute queries.

-1 for #10.  We need per-realm providers probably for everything, but 
RealmProvider.  4 and 5 will be impacted by per-realm UserProvider.  #5 
will be a refactoring of Marek's current code to fit model we've been 
discussing for #4.

IMO, #9 comes in 2 parts.  1st part is a generic Config per-realm 
storage.  2nd is Provider config through admin console.

I vote Stian does #6 and #9.  Marek finishes 7 and looks into LDAP 
changelogs.  There's also a few bugs/enhancements here and there still 
in JIRA.

> Also, I'm away 13 days and Marek is away 8 days in August!

I'm away last week of August.


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

From stian at redhat.com  Wed Jul 16 12:04:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 12:04:11 -0400 (EDT)
Subject: [keycloak-dev] Remaining work and who does what for beta-4
In-Reply-To: <53C69673.8050401@redhat.com>
References: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>
	<53C69673.8050401@redhat.com>
Message-ID: <1902238974.11326743.1405526651886.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 4:12:51 PM
> Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4
> 
> 
> 
> On 7/16/2014 10:12 AM, Stian Thorgersen wrote:
> > Now that the craziness of splitting the model is behind us I think we
> > should figure out exactly what's left to do for beta-4, who's doing what
> > and an estimated release date.
> >
> > Here's the list of things I can come up with:
> >
> > 1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to
> > RoleEntity and RealmEntity respectively.
> > 2. JPA and Mongo RealmEntity and UserEntity should be refactored to be
> > attribute based as in the Hybrid model.
> > 3. Credential validation, update needs to move from RealmModel to
> > UserProvider.
> > 4. Sync support in UserProvider
> > 5. LDAP implementation for 4
> > 6. Access code work (reducing code size, email link size, single-use code,
> > etc.)
> > 7. Pagination support for users
> > 8. Improve delete of users
> >
> > My vote is yes to all above!
> >
> > Also, a couple of things we should consider:
> >
> > 9. Add generic configuration for providers, including the ability to
> > configure any providers through the admin console
> > 10. Have KeycloakSession bound to a specific realm
> >
> 
> I'm working on 1-5 and 8.  I think I can be done in 5-7 business days.
> 1-3, 8 are really easy, at least for JPA.  Was going to copy what stian
> did for Hybrid for attribute queries.
> 
> -1 for #10.  We need per-realm providers probably for everything, but
> RealmProvider.  4 and 5 will be impacted by per-realm UserProvider.  #5
> will be a refactoring of Marek's current code to fit model we've been
> discussing for #4.

I probably agree with regards to #10. Maybe instead providers can either be global or per-realm?

> 
> IMO, #9 comes in 2 parts.  1st part is a generic Config per-realm
> storage.  2nd is Provider config through admin console.

Can you elaborate on what you mean about config per-realm storage?

> 
> I vote Stian does #6 and #9.  Marek finishes 7 and looks into LDAP
> changelogs.  There's also a few bugs/enhancements here and there still
> in JIRA.

Sounds good.

I've already started 7 and I'm almost done. Basically just copying what I did for pagination of sessions.

> 
> > Also, I'm away 13 days and Marek is away 8 days in August!
> 
> I'm away last week of August.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 16 12:16:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 12:16:22 -0400 (EDT)
Subject: [keycloak-dev] Admin console broken (fix coming!)
In-Reply-To: <1037027409.11332433.1405527368470.JavaMail.zimbra@redhat.com>
Message-ID: <792175406.11332510.1405527382638.JavaMail.zimbra@redhat.com>

Some idiot (aka me) has broken the admin console. Some changes I did to keycloak.js are causing a redirect loop. Fix coming asap!!

From bburke at redhat.com  Wed Jul 16 12:24:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 12:24:58 -0400
Subject: [keycloak-dev] Remaining work and who does what for beta-4
In-Reply-To: <1902238974.11326743.1405526651886.JavaMail.zimbra@redhat.com>
References: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>
	<53C69673.8050401@redhat.com>
	<1902238974.11326743.1405526651886.JavaMail.zimbra@redhat.com>
Message-ID: <53C6A75A.4000605@redhat.com>



On 7/16/2014 12:04 PM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 16 July, 2014 4:12:51 PM
>> Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4
>>
>>
>>
>> On 7/16/2014 10:12 AM, Stian Thorgersen wrote:
>>> Now that the craziness of splitting the model is behind us I think we
>>> should figure out exactly what's left to do for beta-4, who's doing what
>>> and an estimated release date.
>>>
>>> Here's the list of things I can come up with:
>>>
>>> 1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to
>>> RoleEntity and RealmEntity respectively.
>>> 2. JPA and Mongo RealmEntity and UserEntity should be refactored to be
>>> attribute based as in the Hybrid model.
>>> 3. Credential validation, update needs to move from RealmModel to
>>> UserProvider.
>>> 4. Sync support in UserProvider
>>> 5. LDAP implementation for 4
>>> 6. Access code work (reducing code size, email link size, single-use code,
>>> etc.)
>>> 7. Pagination support for users
>>> 8. Improve delete of users
>>>
>>> My vote is yes to all above!
>>>
>>> Also, a couple of things we should consider:
>>>
>>> 9. Add generic configuration for providers, including the ability to
>>> configure any providers through the admin console
>>> 10. Have KeycloakSession bound to a specific realm
>>>
>>
>> I'm working on 1-5 and 8.  I think I can be done in 5-7 business days.
>> 1-3, 8 are really easy, at least for JPA.  Was going to copy what stian
>> did for Hybrid for attribute queries.
>>
>> -1 for #10.  We need per-realm providers probably for everything, but
>> RealmProvider.  4 and 5 will be impacted by per-realm UserProvider.  #5
>> will be a refactoring of Marek's current code to fit model we've been
>> discussing for #4.
>
> I probably agree with regards to #10. Maybe instead providers can either be global or per-realm?
>

I think it ties into #9.  See below:


>>
>> IMO, #9 comes in 2 parts.  1st part is a generic Config per-realm
>> storage.  2nd is Provider config through admin console.
>
> Can you elaborate on what you mean about config per-realm storage?
>

interface RealmModel {

    org.keycloak.Config getProviderConfig();

}

I thought that was what you were proposing.  There would need to be a 
non-static and write interface for Config though.

Then KeycloakSession changes:

Provider getProvider(Realm realm, Class providerClass);

getProvider() grabs Config.Scope from the RealmModel for the provider 
and creates a ProviderFactory per realm.

Just a thought.  Maybe it can't work in practice.


>>
>> I vote Stian does #6 and #9.  Marek finishes 7 and looks into LDAP
>> changelogs.  There's also a few bugs/enhancements here and there still
>> in JIRA.
>
> Sounds good.
>
> I've already started 7 and I'm almost done. Basically just copying what I did for pagination of sessions.
>

Yeah, I hope to have 1-3, and 8 done by the time you wake up tomorrow.

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

From stian at redhat.com  Wed Jul 16 12:40:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 12:40:18 -0400 (EDT)
Subject: [keycloak-dev] Admin console broken (fix coming!)
In-Reply-To: <792175406.11332510.1405527382638.JavaMail.zimbra@redhat.com>
References: <792175406.11332510.1405527382638.JavaMail.zimbra@redhat.com>
Message-ID: <1266163460.11347827.1405528818385.JavaMail.zimbra@redhat.com>

Fixed

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Wednesday, 16 July, 2014 5:16:22 PM
> Subject: [keycloak-dev] Admin console broken (fix coming!)
> 
> Some idiot (aka me) has broken the admin console. Some changes I did to
> keycloak.js are causing a redirect loop. Fix coming asap!!
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 16 13:04:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 16 Jul 2014 13:04:12 -0400 (EDT)
Subject: [keycloak-dev] Remaining work and who does what for beta-4
In-Reply-To: <53C6A75A.4000605@redhat.com>
References: <763459708.11245411.1405519935765.JavaMail.zimbra@redhat.com>
	<53C69673.8050401@redhat.com>
	<1902238974.11326743.1405526651886.JavaMail.zimbra@redhat.com>
	<53C6A75A.4000605@redhat.com>
Message-ID: <1408637299.11399812.1405530252972.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 5:24:58 PM
> Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4
> 
> 
> 
> On 7/16/2014 12:04 PM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 4:12:51 PM
> >> Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4
> >>
> >>
> >>
> >> On 7/16/2014 10:12 AM, Stian Thorgersen wrote:
> >>> Now that the craziness of splitting the model is behind us I think we
> >>> should figure out exactly what's left to do for beta-4, who's doing what
> >>> and an estimated release date.
> >>>
> >>> Here's the list of things I can come up with:
> >>>
> >>> 1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to
> >>> RoleEntity and RealmEntity respectively.
> >>> 2. JPA and Mongo RealmEntity and UserEntity should be refactored to be
> >>> attribute based as in the Hybrid model.
> >>> 3. Credential validation, update needs to move from RealmModel to
> >>> UserProvider.
> >>> 4. Sync support in UserProvider
> >>> 5. LDAP implementation for 4
> >>> 6. Access code work (reducing code size, email link size, single-use
> >>> code,
> >>> etc.)
> >>> 7. Pagination support for users
> >>> 8. Improve delete of users
> >>>
> >>> My vote is yes to all above!
> >>>
> >>> Also, a couple of things we should consider:
> >>>
> >>> 9. Add generic configuration for providers, including the ability to
> >>> configure any providers through the admin console
> >>> 10. Have KeycloakSession bound to a specific realm
> >>>
> >>
> >> I'm working on 1-5 and 8.  I think I can be done in 5-7 business days.
> >> 1-3, 8 are really easy, at least for JPA.  Was going to copy what stian
> >> did for Hybrid for attribute queries.
> >>
> >> -1 for #10.  We need per-realm providers probably for everything, but
> >> RealmProvider.  4 and 5 will be impacted by per-realm UserProvider.  #5
> >> will be a refactoring of Marek's current code to fit model we've been
> >> discussing for #4.
> >
> > I probably agree with regards to #10. Maybe instead providers can either be
> > global or per-realm?
> >
> 
> I think it ties into #9.  See below:
> 
> 
> >>
> >> IMO, #9 comes in 2 parts.  1st part is a generic Config per-realm
> >> storage.  2nd is Provider config through admin console.
> >
> > Can you elaborate on what you mean about config per-realm storage?
> >
> 
> interface RealmModel {
> 
>     org.keycloak.Config getProviderConfig();
> 
> }
> 
> I thought that was what you were proposing.  There would need to be a
> non-static and write interface for Config though.
> 
> Then KeycloakSession changes:
> 
> Provider getProvider(Realm realm, Class providerClass);
> 
> getProvider() grabs Config.Scope from the RealmModel for the provider
> and creates a ProviderFactory per realm.
> 
> Just a thought.  Maybe it can't work in practice.

Something like that could work. I'll think about it some more tomorrow ;) 

> 
> 
> >>
> >> I vote Stian does #6 and #9.  Marek finishes 7 and looks into LDAP
> >> changelogs.  There's also a few bugs/enhancements here and there still
> >> in JIRA.
> >
> > Sounds good.
> >
> > I've already started 7 and I'm almost done. Basically just copying what I
> > did for pagination of sessions.
> >
> 
> Yeah, I hope to have 1-3, and 8 done by the time you wake up tomorrow.

I get up at 6am! Not by personal choice :(

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

From mposolda at redhat.com  Wed Jul 16 14:26:18 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 16 Jul 2014 20:26:18 +0200
Subject: [keycloak-dev] ExportImportTest disabled, breaks build
In-Reply-To: <53C64D8D.1050203@redhat.com>
References: <53C58656.2000703@redhat.com> <53C64D8D.1050203@redhat.com>
Message-ID: <53C6C3CA.6000904@redhat.com>

Finally it passes for me on Windows and also with CI, so I hope it pass 
for you as well:-)
PR is https://github.com/keycloak/keycloak/pull/531

Marek

On 16.7.2014 12:01, Marek Posolda wrote:
> Looks like Windows specific issue again as CI is failing as well, but 
> just on Windows:-(
>
> Will try to figure out windows machine, reproduce and fix it.
>
> Marek
>
> On 15.7.2014 21:51, Bill Burke wrote:
>> When running the ExportImportTest with the build it causes other tests
>> to fail.  I spent an hour or two trying to figure it out, I couldn't.
>> This is off of master *BEFORE* I did my big commit.  Its not a caching
>> issue as I ran tests without the cache.  It seems that users are not
>> being deleted.  There's some other issues too even if I change the
>> usernames used in the ExportImportTest.
>>
>


From bburke at redhat.com  Wed Jul 16 15:35:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 15:35:42 -0400
Subject: [keycloak-dev] ExportImportTest disabled, breaks build
In-Reply-To: <53C6C3CA.6000904@redhat.com>
References: <53C58656.2000703@redhat.com> <53C64D8D.1050203@redhat.com>
	<53C6C3CA.6000904@redhat.com>
Message-ID: <53C6D40E.1010903@redhat.com>

Passes.  Thanks.  What was the problem?

On 7/16/2014 2:26 PM, Marek Posolda wrote:
> Finally it passes for me on Windows and also with CI, so I hope it pass
> for you as well:-)
> PR is https://github.com/keycloak/keycloak/pull/531
>
> Marek
>
> On 16.7.2014 12:01, Marek Posolda wrote:
>> Looks like Windows specific issue again as CI is failing as well, but
>> just on Windows:-(
>>
>> Will try to figure out windows machine, reproduce and fix it.
>>
>> Marek
>>
>> On 15.7.2014 21:51, Bill Burke wrote:
>>> When running the ExportImportTest with the build it causes other tests
>>> to fail.  I spent an hour or two trying to figure it out, I couldn't.
>>> This is off of master *BEFORE* I did my big commit.  Its not a caching
>>> issue as I ran tests without the cache.  It seems that users are not
>>> being deleted.  There's some other issues too even if I change the
>>> usernames used in the ExportImportTest.
>>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Wed Jul 16 19:42:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 16 Jul 2014 19:42:28 -0400
Subject: [keycloak-dev] need help on JPA schema changes
Message-ID: <53C70DE4.1000801@redhat.com>

I refactored some things for both performance and for bulk delete of 
users.

* use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity, 
etc.  This is more efficient than strings
* Ditched all @ElementCollections from UserEntity.  Bulk delete does not 
cascade and there is no way to bulk delete @ElementCollections from 
JPAQL!  This caused me to add UserAttributeEntity and 
UserRequiredActionEntity
* Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity 
so that it can be bulk deleted.

Questions:

I'm not sure about moving things like social links to UserAttributes. 
SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are 
all in separate tables.  Except for AuthenticationLinkEntity, which I 
hope to deal away with on the AuthenticationProvider refactor, I think 
UserEntity is fine the way it is.

Are we *ABSOLUTELY* sure we want to remove secondary key constraints 
from UserRoleMappingEntity and UserEntity for role and realm 
respectively?  These constraints caught a lot of problems for me that I 
wouldn't have found otherwise.  I just don't think we'd ever store users 
and realms in different stores.


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

From mposolda at redhat.com  Thu Jul 17 03:05:47 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 09:05:47 +0200
Subject: [keycloak-dev] ExportImportTest disabled, breaks build
In-Reply-To: <53C6D40E.1010903@redhat.com>
References: <53C58656.2000703@redhat.com>
	<53C64D8D.1050203@redhat.com>	<53C6C3CA.6000904@redhat.com>
	<53C6D40E.1010903@redhat.com>
Message-ID: <53C775CB.2040905@redhat.com>

First it was bad directory for exporting files. This is because if you 
do something like this:

String dirPath = "target" + File.separator + "export-import";
String dir = "foo".replace("foo", dirPath);

then result on Windows is: "targetexport-import" and not 
"target\export-import" as expected :-)
Solved with Matcher.quoteReplacement.

Also I didn't remove System properties related to export/import after 
finish the test, so it was trying to import previously exported stuff in 
other tests. Deleting users after test wasn't sufficient as still next 
test was import them from previously exported files and hence was able 
to saw them. Not sure why it isn't problem on my laptop as well (maybe 
different test order?)

Finally on some windows systems, when you call "server.stop()", it takes 
some time until undertow server is really stopped. This seems to be the 
issue just on Jenkins windows machine (not on the remote machine in 
Brno, which I used for remote testing). Still I added some code to 
AbstractKeycloakRule.stopServer() to wait until server is really stopped.

Marek


On 16.7.2014 21:35, Bill Burke wrote:
> Passes.  Thanks.  What was the problem?
>
> On 7/16/2014 2:26 PM, Marek Posolda wrote:
>> Finally it passes for me on Windows and also with CI, so I hope it pass
>> for you as well:-)
>> PR is https://github.com/keycloak/keycloak/pull/531
>>
>> Marek
>>
>> On 16.7.2014 12:01, Marek Posolda wrote:
>>> Looks like Windows specific issue again as CI is failing as well, but
>>> just on Windows:-(
>>>
>>> Will try to figure out windows machine, reproduce and fix it.
>>>
>>> Marek
>>>
>>> On 15.7.2014 21:51, Bill Burke wrote:
>>>> When running the ExportImportTest with the build it causes other tests
>>>> to fail.  I spent an hour or two trying to figure it out, I couldn't.
>>>> This is off of master *BEFORE* I did my big commit.  Its not a caching
>>>> issue as I ran tests without the cache.  It seems that users are not
>>>> being deleted.  There's some other issues too even if I change the
>>>> usernames used in the ExportImportTest.
>>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From mposolda at redhat.com  Thu Jul 17 04:34:07 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 10:34:07 +0200
Subject: [keycloak-dev] Export/import into representations
In-Reply-To: <53C64D18.4020800@redhat.com>
References: <53C53FB8.9070509@redhat.com>	<2045098415.10614378.1405437231815.JavaMail.zimbra@redhat.com>	<53C546D3.5000401@redhat.com>
	<53C64D18.4020800@redhat.com>
Message-ID: <53C78A7F.1070705@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/533 which 
improves a bit existing export/import to use users pagination as it's 
available now in master.

I've also added method UserProvider.getUsersCount() to count total 
number of users. I am using that for export/import and I believe it 
might be useful for admin console too to see total number of 
users/pages? Not sure if we need "count" methods for 
UserProvider.searchFor*** ?

Marek

On 16.7.2014 11:59, Marek Posolda wrote:
> On 15.7.2014 17:20, Bill Burke wrote:
>> On 7/15/2014 11:13 AM, Stian Thorgersen wrote:
>>>> - Question: Is it plan to move some manager classes like RealmManager,
>>>> ApplicationManager, OAuthClientManager and RolesManager to model/api as
>>>> well? These don't have dependencies on other stuff in "services" and it
>>>> will be useful for stuff like export/import to have them available. For
>>>> example export/import may need the code for setup masterAdmin
>>>> application (as if I import realm, I've need to check if particular
>>>> master application like "demo-realm" exists in master realm and create
>>>> it if doesn't, so I've needed to move some related code from
>>>> RealmManager for setup this too).
>>> +1
>>>
>> Can we wait on moving managers?  Please?  :)  BTW, I think there is
>> JAX-RS code in some managers.
> yeah, I meant just RealmManager, ApplicationManager, OAuthClientManager
> and UserManager, which doesn't have dependency on JAX-RS and they deal
> mainly with model api.
>
> Marek
>>> LDAP/Sync is much higher priority IMO though. Probably best to post-pone this to later, or even wait until/if we get requests for it.
>>>
>> I'd really like to implement the ideas I talked about before about
>> LDAP/Sync.  I was going to tackle that after UserProvider split (which
>> should be today or tomorrow).
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Jul 17 06:31:27 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 12:31:27 +0200
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <53C70DE4.1000801@redhat.com>
References: <53C70DE4.1000801@redhat.com>
Message-ID: <53C7A5FF.8070409@redhat.com>

On 17.7.2014 01:42, Bill Burke wrote:
> I refactored some things for both performance and for bulk delete of
> users.
>
> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
> etc.  This is more efficient than strings
> * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
> cascade and there is no way to bulk delete @ElementCollections from
> JPAQL!  This caused me to add UserAttributeEntity and
> UserRequiredActionEntity
> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
> so that it can be bulk deleted.
>
> Questions:
>
> I'm not sure about moving things like social links to UserAttributes.
> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
> all in separate tables.  Except for AuthenticationLinkEntity, which I
> hope to deal away with on the AuthenticationProvider refactor, I think
> UserEntity is fine the way it is.
I wonder that something like AuthenticationLinkEntity (even if named 
differently) will be still needed? For users synced from LDAP, you may 
want to keep the link to LDAP to particular user?
>
> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
> from UserRoleMappingEntity and UserEntity for role and realm
> respectively?  These constraints caught a lot of problems for me that I
> wouldn't have found otherwise.  I just don't think we'd ever store users
> and realms in different stores.
I am not sure about. Just want to point the usecase with migration 
between versions. For example if Realm change between Keycloak 1.0 and 
Keycloak 1.1, people may want to migrate their database (hence they 
export realmModel to JSON, transform it to 1.1 and import it again). And 
if user model won't change between versions, people won't need to 
export/import and delete all users as it's quite overhead to do it if 
they have like 20 million users in DB. Hence it might be useful if it's 
possible to delete just realm model stuff, but still keep all users in 
DB. Will it be possible with these constraints?

Also doesn't similar problem exists for user sessions as well? I mean 
that with bulk deleting of users, it seems that UserSessions for 
particular user are not deleted? Probably not a big issue as there is 
periodic cleanup of sessions...

Marek

From stian at redhat.com  Thu Jul 17 07:02:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 07:02:36 -0400 (EDT)
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <53C70DE4.1000801@redhat.com>
References: <53C70DE4.1000801@redhat.com>
Message-ID: <1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 12:42:28 AM
> Subject: [keycloak-dev] need help on JPA schema changes
> 
> I refactored some things for both performance and for bulk delete of
> users.
> 
> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
> etc.  This is more efficient than strings

I replaced all the long ids with composite ids (for example UserRoleMappingEntity id is now userId + roleId). BTW we stopped using generated long ids as they didn't work for all databases, but that's not a problem any more as there's no generated ids at all now.

> * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
> cascade and there is no way to bulk delete @ElementCollections from
> JPAQL!  This caused me to add UserAttributeEntity and
> UserRequiredActionEntity

I hate ElementCollections, it's never worked properly! Much better to do what you've done now so you get more control.

> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
> so that it can be bulk deleted.
> 
> Questions:
> 
> I'm not sure about moving things like social links to UserAttributes.
> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
> all in separate tables.  Except for AuthenticationLinkEntity, which I
> hope to deal away with on the AuthenticationProvider refactor, I think
> UserEntity is fine the way it is.

I can see two reasons to removing this. First using attributes instead means we should be less likely to require schema changes in the future. Secondly it will reduce the number of joins (and/or separate selects) to retrieve a user. I think it's worth doing some performance eval with regards to the latter.

> 
> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
> from UserRoleMappingEntity and UserEntity for role and realm
> respectively?  These constraints caught a lot of problems for me that I
> wouldn't have found otherwise.  I just don't think we'd ever store users
> and realms in different stores.

My vote is yes, but I don't feel to strongly about it (at least not atm). With regards to constraints (and being able to delete users for a realm when a realm is deleted, etc.) that is something we need to make to work in either case if users are to be able to implement their own UserProviders. In the future I think there will be cases where someone will want to store realms and users in separate databases. For example for a really big deployment realms would go into a single replicated db, while for users you may want to shard as well.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 17 07:08:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 07:08:17 -0400 (EDT)
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>
References: <53C70DE4.1000801@redhat.com>
	<1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>
Message-ID: <1150716482.11869356.1405595297143.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 12:02:36 PM
> Subject: Re: [keycloak-dev] need help on JPA schema changes
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 17 July, 2014 12:42:28 AM
> > Subject: [keycloak-dev] need help on JPA schema changes
> > 
> > I refactored some things for both performance and for bulk delete of
> > users.
> > 
> > * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
> > etc.  This is more efficient than strings
> 
> I replaced all the long ids with composite ids (for example
> UserRoleMappingEntity id is now userId + roleId). BTW we stopped using
> generated long ids as they didn't work for all databases, but that's not a
> problem any more as there's no generated ids at all now.
> 
> > * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
> > cascade and there is no way to bulk delete @ElementCollections from
> > JPAQL!  This caused me to add UserAttributeEntity and
> > UserRequiredActionEntity
> 
> I hate ElementCollections, it's never worked properly! Much better to do what
> you've done now so you get more control.
> 
> > * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
> > so that it can be bulk deleted.
> > 
> > Questions:
> > 
> > I'm not sure about moving things like social links to UserAttributes.
> > SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
> > all in separate tables.  Except for AuthenticationLinkEntity, which I
> > hope to deal away with on the AuthenticationProvider refactor, I think
> > UserEntity is fine the way it is.
> 
> I can see two reasons to removing this. First using attributes instead means
> we should be less likely to require schema changes in the future. Secondly
> it will reduce the number of joins (and/or separate selects) to retrieve a
> user. I think it's worth doing some performance eval with regards to the
> latter.
> 
> > 
> > Are we *ABSOLUTELY* sure we want to remove secondary key constraints
> > from UserRoleMappingEntity and UserEntity for role and realm
> > respectively?  These constraints caught a lot of problems for me that I
> > wouldn't have found otherwise.  I just don't think we'd ever store users
> > and realms in different stores.
> 
> My vote is yes, but I don't feel to strongly about it (at least not atm).
> With regards to constraints (and being able to delete users for a realm when
> a realm is deleted, etc.) that is something we need to make to work in
> either case if users are to be able to implement their own UserProviders. In
> the future I think there will be cases where someone will want to store
> realms and users in separate databases. For example for a really big
> deployment realms would go into a single replicated db, while for users you
> may want to shard as well.

Another thing I just thought about if UserEntity.realm is a RealmEntity you actually have to go and fetch the RealmEntity to create or update 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
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 17 08:55:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 08:55:55 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <918203312.11986749.1405601204210.JavaMail.zimbra@redhat.com>
Message-ID: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>

As we didn't have enough things to do last minute I come up with more things which I think we should do for 1.0.final:

1. Configure JPA through keycloak-server.json instead of persistence.xml

This would be super simple to do, and would let us have a single persistence.xml for everything (testsuite, server, project-integrations). Everything worthy of configuring in persistence.xml (including datasource) can be passed in the Map overrides when creating the EntityManagerFactory.


2. Introduce server-dependencies-min and server-dependencies-all poms

We have a few places that includes all the dependencies required (server, testsuite/integration and testsuite/) as well as other project such as AeroGear and LiveOak. Instead of everyone having to list all the dependencies they could have a single dependency on either server-dependencies-min or server-dependencies-all. Min would exclude most if not all provider implementations (such as PicketLink/LDAP, social providers, etc).


3. TOTP SPI

At the moment we only support Google Authenticator, I don't think that's sufficient. We should at the very least add support for one more, and have an SPI so users can add their own. I think this would be related to the UserProvider sync work, as some UserProvider implementations may require both a password and totp to verify a users credentials, while others would only be able to verify the password and then have Keycloak verify the totp.

Also, do we need to support users with more than one totp? Personally I have two for work (one I use daily and another for backup).

From bburke at redhat.com  Thu Jul 17 09:03:20 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 09:03:20 -0400
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <53C7A5FF.8070409@redhat.com>
References: <53C70DE4.1000801@redhat.com> <53C7A5FF.8070409@redhat.com>
Message-ID: <53C7C998.4080905@redhat.com>



On 7/17/2014 6:31 AM, Marek Posolda wrote:
> On 17.7.2014 01:42, Bill Burke wrote:
>> I refactored some things for both performance and for bulk delete of
>> users.
>>
>> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
>> etc.  This is more efficient than strings
>> * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
>> cascade and there is no way to bulk delete @ElementCollections from
>> JPAQL!  This caused me to add UserAttributeEntity and
>> UserRequiredActionEntity
>> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
>> so that it can be bulk deleted.
>>
>> Questions:
>>
>> I'm not sure about moving things like social links to UserAttributes.
>> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
>> all in separate tables.  Except for AuthenticationLinkEntity, which I
>> hope to deal away with on the AuthenticationProvider refactor, I think
>> UserEntity is fine the way it is.
> I wonder that something like AuthenticationLinkEntity (even if named
> differently) will be still needed? For users synced from LDAP, you may
> want to keep the link to LDAP to particular user?

I don't think AuthenticatioLinkEntity should be part of the UserModel 
API.  The reason being is that this is metadata specific to the 
"federation provider" and may be different per "federation provider".

>>
>> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
>> from UserRoleMappingEntity and UserEntity for role and realm
>> respectively?  These constraints caught a lot of problems for me that I
>> wouldn't have found otherwise.  I just don't think we'd ever store users
>> and realms in different stores.
> I am not sure about. Just want to point the usecase with migration
> between versions. For example if Realm change between Keycloak 1.0 and
> Keycloak 1.1, people may want to migrate their database (hence they
> export realmModel to JSON, transform it to 1.1 and import it again). And
> if user model won't change between versions, people won't need to
> export/import and delete all users as it's quite overhead to do it if
> they have like 20 million users in DB. Hence it might be useful if it's
> possible to delete just realm model stuff, but still keep all users in
> DB. Will it be possible with these constraints?
>

Ah, really good point.  Can't drop realm tables or export-reimport realm 
data and keep users around.

> Also doesn't similar problem exists for user sessions as well? I mean
> that with bulk deleting of users, it seems that UserSessions for
> particular user are not deleted? Probably not a big issue as there is
> periodic cleanup of sessions...
>

Good point, but I think Stian has it covered with 
UserSessionProvider.onRealmRemoved().


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

From bburke at redhat.com  Thu Jul 17 09:14:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 09:14:21 -0400
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
Message-ID: <53C7CC2D.7080609@redhat.com>



On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
> As we didn't have enough things to do last minute I come up with more things which I think we should do for 1.0.final:
>
> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>
> This would be super simple to do, and would let us have a single persistence.xml for everything (testsuite, server, project-integrations). Everything worthy of configuring in persistence.xml (including datasource) can be passed in the Map overrides when creating the EntityManagerFactory.
>

-1.  I don't think learning a new configuration format for 
persistence.xml is user friendly.  Users would have to translate the 
Hibernate documentation to our json format.

>
> 2. Introduce server-dependencies-min and server-dependencies-all poms
>
> We have a few places that includes all the dependencies required (server, testsuite/integration and testsuite/) as well as other project such as AeroGear and LiveOak. Instead of everyone having to list all the dependencies they could have a single dependency on either server-dependencies-min or server-dependencies-all. Min would exclude most if not all provider implementations (such as PicketLink/LDAP, social providers, etc).
>

+1

>
> 3. TOTP SPI
>
> At the moment we only support Google Authenticator, I don't think that's sufficient. We should at the very least add support for one more, and have an SPI so users can add their own. I think this would be related to the UserProvider sync work, as some UserProvider implementations may require both a password and totp to verify a users credentials, while others would only be able to verify the password and then have Keycloak verify the totp.
>

+1. Do  we have cycles to include in 1.0?

> Also, do we need to support users with more than one totp? Personally I have two for work (one I use daily and another for backup).

+1. Do  we have cycles to include in 1.0?
\
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu Jul 17 09:20:25 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 09:20:25 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <53C7CC2D.7080609@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C7CC2D.7080609@redhat.com>
Message-ID: <1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 2:14:21 PM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> 
> 
> On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
> > As we didn't have enough things to do last minute I come up with more
> > things which I think we should do for 1.0.final:
> >
> > 1. Configure JPA through keycloak-server.json instead of persistence.xml
> >
> > This would be super simple to do, and would let us have a single
> > persistence.xml for everything (testsuite, server, project-integrations).
> > Everything worthy of configuring in persistence.xml (including datasource)
> > can be passed in the Map overrides when creating the EntityManagerFactory.
> >
> 
> -1.  I don't think learning a new configuration format for
> persistence.xml is user friendly.  Users would have to translate the
> Hibernate documentation to our json format.

It would support both, configuration can either be done through persistence.xml or keycloak-server.json. We could use the same property names, so it would just be a matter of putting it in keycloak-server instead of properties in persistence.xml.

Also, why do our users need to understand Hibernate/JPA just to be able to configure what data-source to use for Keycloak?

> 
> >
> > 2. Introduce server-dependencies-min and server-dependencies-all poms
> >
> > We have a few places that includes all the dependencies required (server,
> > testsuite/integration and testsuite/) as well as other project such as
> > AeroGear and LiveOak. Instead of everyone having to list all the
> > dependencies they could have a single dependency on either
> > server-dependencies-min or server-dependencies-all. Min would exclude most
> > if not all provider implementations (such as PicketLink/LDAP, social
> > providers, etc).
> >
> 
> +1
> 
> >
> > 3. TOTP SPI
> >
> > At the moment we only support Google Authenticator, I don't think that's
> > sufficient. We should at the very least add support for one more, and have
> > an SPI so users can add their own. I think this would be related to the
> > UserProvider sync work, as some UserProvider implementations may require
> > both a password and totp to verify a users credentials, while others would
> > only be able to verify the password and then have Keycloak verify the
> > totp.
> >
> 
> +1. Do  we have cycles to include in 1.0?
> 
> > Also, do we need to support users with more than one totp? Personally I
> > have two for work (one I use daily and another for backup).
> 
> +1. Do  we have cycles to include in 1.0?
> \
> --
> 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 Jul 17 09:21:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 09:21:19 -0400
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>
References: <53C70DE4.1000801@redhat.com>
	<1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>
Message-ID: <53C7CDCF.1070005@redhat.com>



On 7/17/2014 7:02 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 17 July, 2014 12:42:28 AM
>> Subject: [keycloak-dev] need help on JPA schema changes
>>
>> I refactored some things for both performance and for bulk delete of
>> users.
>>
>> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
>> etc.  This is more efficient than strings
>
> I replaced all the long ids with composite ids (for example UserRoleMappingEntity id is now userId + roleId). BTW we stopped using generated long ids as they didn't work for all databases, but that's not a problem any more as there's no generated ids at all now.
>

Awesome!  I tried to do that, but I couldn't figure out the JPA magic to 
do it and was getting constraint errors in some tests.

>> * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
>> cascade and there is no way to bulk delete @ElementCollections from
>> JPAQL!  This caused me to add UserAttributeEntity and
>> UserRequiredActionEntity
>
> I hate ElementCollections, it's never worked properly! Much better to do what you've done now so you get more control.
>

will have to do the same for Realm.

>> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
>> so that it can be bulk deleted.
>>
>> Questions:
>>
>> I'm not sure about moving things like social links to UserAttributes.
>> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
>> all in separate tables.  Except for AuthenticationLinkEntity, which I
>> hope to deal away with on the AuthenticationProvider refactor, I think
>> UserEntity is fine the way it is.
>
> I can see two reasons to removing this. First using attributes instead means we should be less likely to require schema changes in the future. Secondly it will reduce the number of joins (and/or separate selects) to retrieve a user. I think it's worth doing some performance eval with regards to the latter.
>

Not sure I agree that schema change is a problem, but the joins make sense.

>>
>> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
>> from UserRoleMappingEntity and UserEntity for role and realm
>> respectively?  These constraints caught a lot of problems for me that I
>> wouldn't have found otherwise.  I just don't think we'd ever store users
>> and realms in different stores.
>
> My vote is yes, but I don't feel to strongly about it (at least not atm). With regards to constraints (and being able to delete users for a realm when a realm is deleted, etc.) that is something we need to make to work in either case if users are to be able to implement their own UserProviders. In the future I think there will be cases where someone will want to store realms and users in separate databases. For example for a really big deployment realms would go into a single replicated db, while for users you may want to shard as well.
>

Marek already made the export--reimport point.  Can't remove/re-add 
realm/role rows if there are constraints.

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

From stian at redhat.com  Thu Jul 17 09:23:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 09:23:40 -0400 (EDT)
Subject: [keycloak-dev] need help on JPA schema changes
In-Reply-To: <53C7CDCF.1070005@redhat.com>
References: <53C70DE4.1000801@redhat.com>
	<1744765399.11866431.1405594956057.JavaMail.zimbra@redhat.com>
	<53C7CDCF.1070005@redhat.com>
Message-ID: <1603349517.12035632.1405603420498.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 2:21:19 PM
> Subject: Re: [keycloak-dev] need help on JPA schema changes
> 
> 
> 
> On 7/17/2014 7:02 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 17 July, 2014 12:42:28 AM
> >> Subject: [keycloak-dev] need help on JPA schema changes
> >>
> >> I refactored some things for both performance and for bulk delete of
> >> users.
> >>
> >> * use long @Id for all non-exposed entities, i.e. UserRoleMappingEntity,
> >> etc.  This is more efficient than strings
> >
> > I replaced all the long ids with composite ids (for example
> > UserRoleMappingEntity id is now userId + roleId). BTW we stopped using
> > generated long ids as they didn't work for all databases, but that's not a
> > problem any more as there's no generated ids at all now.
> >
> 
> Awesome!  I tried to do that, but I couldn't figure out the JPA magic to
> do it and was getting constraint errors in some tests.

I banged my head against the wall quite hard before I figure it out! Why don't we just move the JDBC ;)

> 
> >> * Ditched all @ElementCollections from UserEntity.  Bulk delete does not
> >> cascade and there is no way to bulk delete @ElementCollections from
> >> JPAQL!  This caused me to add UserAttributeEntity and
> >> UserRequiredActionEntity
> >
> > I hate ElementCollections, it's never worked properly! Much better to do
> > what you've done now so you get more control.
> >
> 
> will have to do the same for Realm.
> 
> >> * Added @ManyToOne UserEntity relationship to AuthenticationLinkEntity
> >> so that it can be bulk deleted.
> >>
> >> Questions:
> >>
> >> I'm not sure about moving things like social links to UserAttributes.
> >> SocialLinkEntity, UserRoleMappingEntity, UserRequiredActionEntity are
> >> all in separate tables.  Except for AuthenticationLinkEntity, which I
> >> hope to deal away with on the AuthenticationProvider refactor, I think
> >> UserEntity is fine the way it is.
> >
> > I can see two reasons to removing this. First using attributes instead
> > means we should be less likely to require schema changes in the future.
> > Secondly it will reduce the number of joins (and/or separate selects) to
> > retrieve a user. I think it's worth doing some performance eval with
> > regards to the latter.
> >
> 
> Not sure I agree that schema change is a problem, but the joins make sense.
> 
> >>
> >> Are we *ABSOLUTELY* sure we want to remove secondary key constraints
> >> from UserRoleMappingEntity and UserEntity for role and realm
> >> respectively?  These constraints caught a lot of problems for me that I
> >> wouldn't have found otherwise.  I just don't think we'd ever store users
> >> and realms in different stores.
> >
> > My vote is yes, but I don't feel to strongly about it (at least not atm).
> > With regards to constraints (and being able to delete users for a realm
> > when a realm is deleted, etc.) that is something we need to make to work
> > in either case if users are to be able to implement their own
> > UserProviders. In the future I think there will be cases where someone
> > will want to store realms and users in separate databases. For example for
> > a really big deployment realms would go into a single replicated db, while
> > for users you may want to shard as well.
> >
> 
> Marek already made the export--reimport point.  Can't remove/re-add
> realm/role rows if there are constraints.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bruno at abstractj.org  Thu Jul 17 09:25:34 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 17 Jul 2014 10:25:34 -0300
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
References: <918203312.11986749.1405601204210.JavaMail.zimbra@redhat.com>
	<965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
Message-ID: <20140717132534.GB71531@abstractj.org>

Good morning Stian,

Is the revocation of the refresh token[1][2] also planned?

[1] -
http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html
[2] - http://tools.ietf.org/html/rfc7009

On 2014-07-17, Stian Thorgersen wrote:
> As we didn't have enough things to do last minute I come up with more things which I think we should do for 1.0.final:
>
> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>
> This would be super simple to do, and would let us have a single persistence.xml for everything (testsuite, server, project-integrations). Everything worthy of configuring in persistence.xml (including datasource) can be passed in the Map overrides when creating the EntityManagerFactory.
>
>
> 2. Introduce server-dependencies-min and server-dependencies-all poms
>
> We have a few places that includes all the dependencies required (server, testsuite/integration and testsuite/) as well as other project such as AeroGear and LiveOak. Instead of everyone having to list all the dependencies they could have a single dependency on either server-dependencies-min or server-dependencies-all. Min would exclude most if not all provider implementations (such as PicketLink/LDAP, social providers, etc).
>
>
> 3. TOTP SPI
>
> At the moment we only support Google Authenticator, I don't think that's sufficient. We should at the very least add support for one more, and have an SPI so users can add their own. I think this would be related to the UserProvider sync work, as some UserProvider implementations may require both a password and totp to verify a users credentials, while others would only be able to verify the password and then have Keycloak verify the totp.
>
> Also, do we need to support users with more than one totp? Personally I have two for work (one I use daily and another for backup).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj

From stian at redhat.com  Thu Jul 17 09:30:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 09:30:16 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <20140717132534.GB71531@abstractj.org>
References: <918203312.11986749.1405601204210.JavaMail.zimbra@redhat.com>
	<965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<20140717132534.GB71531@abstractj.org>
Message-ID: <1091967333.12040908.1405603816018.JavaMail.zimbra@redhat.com>

Nope, if it something you really really really need it we could look at it. Or at least consider for 1.1

I don't think we'd allow revoking individual refresh tokens, but instead allow revoking a client from a specific user session. The end result would be pretty much the same, except if there was multiple refresh tokens active for a client they would all be invalidated.

The revoking part is easy, it to endpoints, admin console and account management that is more time consuming :/

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 17 July, 2014 2:25:34 PM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> Good morning Stian,
> 
> Is the revocation of the refresh token[1][2] also planned?
> 
> [1] -
> http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html
> [2] - http://tools.ietf.org/html/rfc7009
> 
> On 2014-07-17, Stian Thorgersen wrote:
> > As we didn't have enough things to do last minute I come up with more
> > things which I think we should do for 1.0.final:
> >
> > 1. Configure JPA through keycloak-server.json instead of persistence.xml
> >
> > This would be super simple to do, and would let us have a single
> > persistence.xml for everything (testsuite, server, project-integrations).
> > Everything worthy of configuring in persistence.xml (including datasource)
> > can be passed in the Map overrides when creating the EntityManagerFactory.
> >
> >
> > 2. Introduce server-dependencies-min and server-dependencies-all poms
> >
> > We have a few places that includes all the dependencies required (server,
> > testsuite/integration and testsuite/) as well as other project such as
> > AeroGear and LiveOak. Instead of everyone having to list all the
> > dependencies they could have a single dependency on either
> > server-dependencies-min or server-dependencies-all. Min would exclude most
> > if not all provider implementations (such as PicketLink/LDAP, social
> > providers, etc).
> >
> >
> > 3. TOTP SPI
> >
> > At the moment we only support Google Authenticator, I don't think that's
> > sufficient. We should at the very least add support for one more, and have
> > an SPI so users can add their own. I think this would be related to the
> > UserProvider sync work, as some UserProvider implementations may require
> > both a password and totp to verify a users credentials, while others would
> > only be able to verify the password and then have Keycloak verify the
> > totp.
> >
> > Also, do we need to support users with more than one totp? Personally I
> > have two for work (one I use daily and another for backup).
> > _______________________________________________
> > 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 Jul 17 09:30:18 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 09:30:18 -0400
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C7CC2D.7080609@redhat.com>
	<1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>
Message-ID: <53C7CFEA.9090808@redhat.com>



On 7/17/2014 9:20 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 17 July, 2014 2:14:21 PM
>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
>>
>>
>>
>> On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
>>> As we didn't have enough things to do last minute I come up with more
>>> things which I think we should do for 1.0.final:
>>>
>>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>>>
>>> This would be super simple to do, and would let us have a single
>>> persistence.xml for everything (testsuite, server, project-integrations).
>>> Everything worthy of configuring in persistence.xml (including datasource)
>>> can be passed in the Map overrides when creating the EntityManagerFactory.
>>>
>>
>> -1.  I don't think learning a new configuration format for
>> persistence.xml is user friendly.  Users would have to translate the
>> Hibernate documentation to our json format.
>
> It would support both, configuration can either be done through persistence.xml or keycloak-server.json. We could use the same property names, so it would just be a matter of putting it in keycloak-server instead of properties in persistence.xml.
>
> Also, why do our users need to understand Hibernate/JPA just to be able to configure what data-source to use for Keycloak?
>

Actually, you're right.  We wouldn't even need a persistence.xml file. 
We wouldn't need even any JPA specific settings in keycloak-server.json 
by default too, right?



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

From bburke at redhat.com  Thu Jul 17 09:33:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 09:33:28 -0400
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <20140717132534.GB71531@abstractj.org>
References: <918203312.11986749.1405601204210.JavaMail.zimbra@redhat.com>	<965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<20140717132534.GB71531@abstractj.org>
Message-ID: <53C7D0A8.5000607@redhat.com>



On 7/17/2014 9:25 AM, Bruno Oliveira wrote:
> Good morning Stian,
>
> Is the revocation of the refresh token[1][2] also planned?
>
> [1] -
> http://lists.jboss.org/pipermail/keycloak-dev/2014-June/001950.html
> [2] - http://tools.ietf.org/html/rfc7009
>

This is what you currently can do:

1. You can set up a notBefore policy realm-wide.  This will invalidate 
all refresh tokens realm wide.
2. You can invalidate a user session which invalidates all refresh 
tokens created under that session.

Bill

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

From stian at redhat.com  Thu Jul 17 09:33:36 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 09:33:36 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <53C7CFEA.9090808@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C7CC2D.7080609@redhat.com>
	<1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>
	<53C7CFEA.9090808@redhat.com>
Message-ID: <1443893518.12043745.1405604016544.JavaMail.zimbra@redhat.com>

We would need peristence.xml just to list the entity-classes. Everything else would be configured through keycloak-server.json, and we could support both Hibernate property names and simpler Keycloak names.

The nice thing about having a persistence.xml with just the entity-classes is that if someone is a Hibernate wizard they can just not specify anything in keycloak-server.json, and just configure it all through the persistence.xml

BTW if we did this, do we even have to explode the auth-server.war in the dist? Templates are extracted to standalone/configuration/templates and configuration is done through standalone/configuration/keycloak-server.json.

----- 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, 17 July, 2014 2:30:18 PM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> 
> 
> On 7/17/2014 9:20 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 17 July, 2014 2:14:21 PM
> >> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >>
> >>
> >>
> >> On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
> >>> As we didn't have enough things to do last minute I come up with more
> >>> things which I think we should do for 1.0.final:
> >>>
> >>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
> >>>
> >>> This would be super simple to do, and would let us have a single
> >>> persistence.xml for everything (testsuite, server, project-integrations).
> >>> Everything worthy of configuring in persistence.xml (including
> >>> datasource)
> >>> can be passed in the Map overrides when creating the
> >>> EntityManagerFactory.
> >>>
> >>
> >> -1.  I don't think learning a new configuration format for
> >> persistence.xml is user friendly.  Users would have to translate the
> >> Hibernate documentation to our json format.
> >
> > It would support both, configuration can either be done through
> > persistence.xml or keycloak-server.json. We could use the same property
> > names, so it would just be a matter of putting it in keycloak-server
> > instead of properties in persistence.xml.
> >
> > Also, why do our users need to understand Hibernate/JPA just to be able to
> > configure what data-source to use for Keycloak?
> >
> 
> Actually, you're right.  We wouldn't even need a persistence.xml file.
> We wouldn't need even any JPA specific settings in keycloak-server.json
> by default too, right?
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Thu Jul 17 10:48:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 16:48:45 +0200
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <1443893518.12043745.1405604016544.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>	<53C7CC2D.7080609@redhat.com>	<1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>	<53C7CFEA.9090808@redhat.com>
	<1443893518.12043745.1405604016544.JavaMail.zimbra@redhat.com>
Message-ID: <53C7E24D.5030803@redhat.com>

+1 as long as it's still possible to override hibernate properties also 
with system properties as it's now. Overriding through system properties 
is useful especially for running tests with various databases in CI, so 
it's possible to configure MS-SQL etc in Jenkins just by setup few 
system properties instead of copying/editing configuration files, which 
would be a pain.

Marek

On 17.7.2014 15:33, Stian Thorgersen wrote:
> We would need peristence.xml just to list the entity-classes. Everything else would be configured through keycloak-server.json, and we could support both Hibernate property names and simpler Keycloak names.
>
> The nice thing about having a persistence.xml with just the entity-classes is that if someone is a Hibernate wizard they can just not specify anything in keycloak-server.json, and just configure it all through the persistence.xml
>
> BTW if we did this, do we even have to explode the auth-server.war in the dist? Templates are extracted to standalone/configuration/templates and configuration is done through standalone/configuration/keycloak-server.json.
>
> ----- 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, 17 July, 2014 2:30:18 PM
>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
>>
>>
>>
>> On 7/17/2014 9:20 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 17 July, 2014 2:14:21 PM
>>>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
>>>>
>>>>
>>>>
>>>> On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
>>>>> As we didn't have enough things to do last minute I come up with more
>>>>> things which I think we should do for 1.0.final:
>>>>>
>>>>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>>>>>
>>>>> This would be super simple to do, and would let us have a single
>>>>> persistence.xml for everything (testsuite, server, project-integrations).
>>>>> Everything worthy of configuring in persistence.xml (including
>>>>> datasource)
>>>>> can be passed in the Map overrides when creating the
>>>>> EntityManagerFactory.
>>>>>
>>>> -1.  I don't think learning a new configuration format for
>>>> persistence.xml is user friendly.  Users would have to translate the
>>>> Hibernate documentation to our json format.
>>> It would support both, configuration can either be done through
>>> persistence.xml or keycloak-server.json. We could use the same property
>>> names, so it would just be a matter of putting it in keycloak-server
>>> instead of properties in persistence.xml.
>>>
>>> Also, why do our users need to understand Hibernate/JPA just to be able to
>>> configure what data-source to use for Keycloak?
>>>
>> Actually, you're right.  We wouldn't even need a persistence.xml file.
>> We wouldn't need even any JPA specific settings in keycloak-server.json
>> by default too, right?
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Jul 17 10:52:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 10:52:38 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <53C7E24D.5030803@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C7CC2D.7080609@redhat.com>
	<1262300503.12032861.1405603225808.JavaMail.zimbra@redhat.com>
	<53C7CFEA.9090808@redhat.com>
	<1443893518.12043745.1405604016544.JavaMail.zimbra@redhat.com>
	<53C7E24D.5030803@redhat.com>
Message-ID: <958390938.12118769.1405608758091.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 3:48:45 PM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> +1 as long as it's still possible to override hibernate properties also
> with system properties as it's now. Overriding through system properties
> is useful especially for running tests with various databases in CI, so
> it's possible to configure MS-SQL etc in Jenkins just by setup few
> system properties instead of copying/editing configuration files, which
> would be a pain.

Wanted to talk to you about that, I think Jenkins should configure the KeycloakDS datasource. That's how we'll document it for users to do, so that's how we should test it.

Look at https://github.com/aerogear/aerogear-unifiedpush-server/tree/master/databases. It should be fairly straightforward to use those scripts with jboss-cli.sh to configure the datasource?

> 
> Marek
> 
> On 17.7.2014 15:33, Stian Thorgersen wrote:
> > We would need peristence.xml just to list the entity-classes. Everything
> > else would be configured through keycloak-server.json, and we could
> > support both Hibernate property names and simpler Keycloak names.
> >
> > The nice thing about having a persistence.xml with just the entity-classes
> > is that if someone is a Hibernate wizard they can just not specify
> > anything in keycloak-server.json, and just configure it all through the
> > persistence.xml
> >
> > BTW if we did this, do we even have to explode the auth-server.war in the
> > dist? Templates are extracted to standalone/configuration/templates and
> > configuration is done through
> > standalone/configuration/keycloak-server.json.
> >
> > ----- 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, 17 July, 2014 2:30:18 PM
> >> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >>
> >>
> >>
> >> On 7/17/2014 9:20 AM, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 17 July, 2014 2:14:21 PM
> >>>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >>>>
> >>>>
> >>>>
> >>>> On 7/17/2014 8:55 AM, Stian Thorgersen wrote:
> >>>>> As we didn't have enough things to do last minute I come up with more
> >>>>> things which I think we should do for 1.0.final:
> >>>>>
> >>>>> 1. Configure JPA through keycloak-server.json instead of
> >>>>> persistence.xml
> >>>>>
> >>>>> This would be super simple to do, and would let us have a single
> >>>>> persistence.xml for everything (testsuite, server,
> >>>>> project-integrations).
> >>>>> Everything worthy of configuring in persistence.xml (including
> >>>>> datasource)
> >>>>> can be passed in the Map overrides when creating the
> >>>>> EntityManagerFactory.
> >>>>>
> >>>> -1.  I don't think learning a new configuration format for
> >>>> persistence.xml is user friendly.  Users would have to translate the
> >>>> Hibernate documentation to our json format.
> >>> It would support both, configuration can either be done through
> >>> persistence.xml or keycloak-server.json. We could use the same property
> >>> names, so it would just be a matter of putting it in keycloak-server
> >>> instead of properties in persistence.xml.
> >>>
> >>> Also, why do our users need to understand Hibernate/JPA just to be able
> >>> to
> >>> configure what data-source to use for Keycloak?
> >>>
> >> Actually, you're right.  We wouldn't even need a persistence.xml file.
> >> We wouldn't need even any JPA specific settings in keycloak-server.json
> >> by default too, right?
> >>
> >>
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Thu Jul 17 11:00:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 17 Jul 2014 11:00:30 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C67AC5.2000103@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
	<1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
	<53C67AC5.2000103@redhat.com>
Message-ID: <453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>

Just started on this. Quick summary of my attack plan:

1. Remove AccessToken from AccessCode. Instead add List<String> rolesRequested and create AccessToken in TokenService.accessCodeToToken. Any reasons why this wouldn't work?
2. Move some info from AccessCode to UserSession, and remove anything redundant. For example username used to login, auth-method (social or form), remember-me.
3. Add info from AccessCode to UserSessionProvider and send signed key instead as the code query param.

With regards to the required info here's what I've come up with:

To verify the code:

* Need to know it hasn't been done before - can either be done by having a timestamp on ClientAssociation that is incremented every time a code is requested/used, or by having a ClientAssociation per-code. As we'll need to store more specific to a code than just the fact it has been used or not, I think it's best to just have a ClientAssociation per-code
* Not expired - no prob
* Session active - no prob
* redirect_uri when retrieving code matches redirect_uri query param when swapping for token - we don't do this currently I think, but spec requires it. This would require a ClientAssociation per-code.
* Correct client_id - no prob, just make sure code belongs to the client_id query param

Then to create the token we need:

* List of roles requested - the union of user roles and app/client scope. This would require a ClientAssociation per-code as the role-mappings/scope could change between user granted the roles to the client and the code is exchanged. Also in the future once we add a scope query param this will be required.
* Realm - no prob, user-session is associated with a realm
* Client - no prob, ClientAssociation is associated with a client
* User - no prob, user-session is associated with a user
* Session - no prob, user-session is a session ;)

All in all it seems like a bit more work than I initially considered. Or am I attacking this completely wrong?!?


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 16 July, 2014 2:14:45 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> 
> 
> On 7/16/2014 9:09 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 16 July, 2014 2:05:15 PM
> >> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >> long
> >>
> >> On 16.7.2014 14:56, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Wednesday, 16 July, 2014 1:47:53 PM
> >>>> Subject: Re: [keycloak-dev] Reset password and verify email links are to
> >>>> long
> >>>>
> >>>>
> >>>>
> >>>> On 7/16/2014 8:43 AM, Bill Burke wrote:
> >>>>>
> >>>>> On 7/16/2014 6:54 AM, Stian Thorgersen wrote:
> >>>>>> This is probably what you've said already Bill, but just to make sure:
> >>>>>>
> >>>>>> 1. Associate the required information to create a token from an access
> >>>>>> code with the user session (basically what's in AccessCodeEntry now)
> >>>>>> 2. The code that is sent as the query param only contains id,
> >>>>>> session-id,
> >>>>>> timestamp
> >>>>>> 3. Once we receive a code to swap for a token we remove the
> >>>>>> information
> >>>>>> added in 1 from the user session and use this to generate the token
> >>>>>>
> >>>>>> Couple questions:
> >>>>>>
> >>>>>> * Do we do this just for emails? or also for the code sent in login
> >>>>>> redirects?
> >>>>>> * Do we really need session-id and timestamp, or isn't id enough?
> >>>>> Actually, do we even need a specific access code?  Even for OAuth 2
> >>>>> flow?  Just pass around the session id.  All information to validate
> >>>>> calls, especially accessCodeToToken[1] should be in the UserSession.
> >>>>> You just have to make absolutely sure you are validating redirect uri
> >>>>> and client-id to guard against swapping.
> >>>>>
> >>>> Actually maybe the access code should be a digitally signed session-id?
> >>>>     Then you're fully protected from people guessing session-ids.
> >>>> Granted, the window to guess is relatively short.  *shrug* I don't know.
> >>>> :)
> >>> It can't just be session-id as there's multiple apps/clients per-session,
> >>> also even multiple logins for a single app. How about session-id +
> >>> client-id + timestamp, and we sign it as well?
> >> Sorry to mention it again, but looks that this is still not enough to
> >> help with the requirement of "Authorization codes MUST be short lived
> >> and single-use." of http://tools.ietf.org/html/rfc6749#section-10.5 :-)
> >
> > Short lived would be covered as there's a timestamp. For single-use we'd
> > have to add the timestamp to the user session or somethin'
> >
> 
> See my last email.  Just store everything within
> ClientUserSessionAssociationEntity and have a
> ClientUserSessionAssociationEntity per access-code.
> 
> class ClientUserSessionAssociationEntity {
> 
>     @Id
>     String accessCode;
> 
>     @ManyToOne
>     UserSessionEntity session;
> 
>     boolean accessCodeActive;
> 
>     long timestamp;
> 
>     String clientId;
> 
> }
> 
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Thu Jul 17 13:09:54 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 19:09:54 +0200
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
	<1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
	<53C67AC5.2000103@redhat.com>
	<453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>
Message-ID: <53C80362.6040202@redhat.com>

On 17.7.2014 17:00, Stian Thorgersen wrote:
> Just started on this. Quick summary of my attack plan:
>
> 1. Remove AccessToken from AccessCode. Instead add List<String> rolesRequested and create AccessToken in TokenService.accessCodeToToken. Any reasons why this wouldn't work?
> 2. Move some info from AccessCode to UserSession, and remove anything redundant. For example username used to login, auth-method (social or form), remember-me.
> 3. Add info from AccessCode to UserSessionProvider and send signed key instead as the code query param.
>
> With regards to the required info here's what I've come up with:
>
> To verify the code:
>
> * Need to know it hasn't been done before - can either be done by having a timestamp on ClientAssociation that is incremented every time a code is requested/used, or by having a ClientAssociation per-code. As we'll need to store more specific to a code than just the fact it has been used or not, I think it's best to just have a ClientAssociation per-code
> * Not expired - no prob
> * Session active - no prob
> * redirect_uri when retrieving code matches redirect_uri query param when swapping for token - we don't do this currently I think, but spec requires it. This would require a ClientAssociation per-code.
> * Correct client_id - no prob, just make sure code belongs to the client_id query param
>
> Then to create the token we need:
>
> * List of roles requested - the union of user roles and app/client scope. This would require a ClientAssociation per-code as the role-mappings/scope could change between user granted the roles to the client and the code is exchanged. Also in the future once we add a scope query param this will be required.
Did you mean intersection rather than union?
> * Realm - no prob, user-session is associated with a realm
> * Client - no prob, ClientAssociation is associated with a client
> * User - no prob, user-session is associated with a user
> * Session - no prob, user-session is a session;)
>
> All in all it seems like a bit more work than I initially considered. Or am I attacking this completely wrong?!?
To me it makes sense and should work.

I wonder about a bit less-time consuming flow to implement, when 
AccessCode is generated together with AccessToken after authentication 
as it's now (in OAuthFlows.processAccessCode) . Only new thing in 
OAuthFlows.processAccessCode will be that ClientAssociation with just 
key-value pair of <signed-codeId>:<base64-encoded-AccessCode> will be 
associated with UserSession. Signed codeId will be then saved as "code" 
parameter .

Then once client will want to exchange code, Keycloak will perform 
lookup of correct UserSession based on codeId (new method on 
UserSessionProvider like: getSessionbyCode). Then when UserSession is 
successfully looked-up, ClientAssociation is immediatelly deleted, so 
that it's not possible to exchange same code twice. In 
TokenService.accessCodeToToken, we will still have AccessCode with 
wrapped AccessToken so we can do all verification is it's done now. Only 
new thing might be redirect_uri verification, which is not currently done.

Defacto it will be same as current flow, only new thing will be:
- ClientAssociation with the pair 
<signed-codeId>:<base64-encoded-AccessCode>, created when code is 
generated and deleted when code is exchanged.
- redirect_uri validation during exchange code to token.

I think that this approach will help us to address 2 main issues, which 
we currently have (long "code" parameter and same code is possible to 
exchange more times). Only thing is, that base64-encoded-AccessCode will 
be quite long and will contain redundant info, but is it big problem? If 
we want later add new info to AccessCode, we don't need to do any 
changes in UserSessionProvider model as it will be still just base64 
encoded string.

Not sure which approach is better, just a though:-)

Marek

From mposolda at redhat.com  Thu Jul 17 13:42:13 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 17 Jul 2014 19:42:13 +0200
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
Message-ID: <53C80AF5.1030603@redhat.com>

One thing, which we discussed before was encoding of privateKey before 
saving to DB? As currently if someone "steal" database record with 
privateKey, he is able to create encoded accessTokens and send requests 
to bearer-only applications.

Or is this still planned for August?

Marek

On 17.7.2014 14:55, Stian Thorgersen wrote:
> As we didn't have enough things to do last minute I come up with more things which I think we should do for 1.0.final:
>
> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>
> This would be super simple to do, and would let us have a single persistence.xml for everything (testsuite, server, project-integrations). Everything worthy of configuring in persistence.xml (including datasource) can be passed in the Map overrides when creating the EntityManagerFactory.
>
>
> 2. Introduce server-dependencies-min and server-dependencies-all poms
>
> We have a few places that includes all the dependencies required (server, testsuite/integration and testsuite/) as well as other project such as AeroGear and LiveOak. Instead of everyone having to list all the dependencies they could have a single dependency on either server-dependencies-min or server-dependencies-all. Min would exclude most if not all provider implementations (such as PicketLink/LDAP, social providers, etc).
>
>
> 3. TOTP SPI
>
> At the moment we only support Google Authenticator, I don't think that's sufficient. We should at the very least add support for one more, and have an SPI so users can add their own. I think this would be related to the UserProvider sync work, as some UserProvider implementations may require both a password and totp to verify a users credentials, while others would only be able to verify the password and then have Keycloak verify the totp.
>
> Also, do we need to support users with more than one totp? Personally I have two for work (one I use daily and another for backup).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Jul 17 14:47:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 14:47:07 -0400
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<851486650.11114682.1405508051158.JavaMail.zimbra@redhat.com>
	<53C67387.3030202@redhat.com> <53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
	<1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
	<53C67AC5.2000103@redhat.com>
	<453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>
Message-ID: <53C81A2B.8030701@redhat.com>



On 7/17/2014 11:00 AM, Stian Thorgersen wrote:
> Just started on this. Quick summary of my attack plan:
>
> 1. Remove AccessToken from AccessCode. Instead add List<String> rolesRequested and create AccessToken in TokenService.accessCodeToToken. Any reasons why this wouldn't work?
> 2. Move some info from AccessCode to UserSession, and remove anything redundant. For example username used to login, auth-method (social or form), remember-me.
> 3. Add info from AccessCode to UserSessionProvider and send signed key instead as the code query param.
>
> With regards to the required info here's what I've come up with:
>
> To verify the code:
>
> * Need to know it hasn't been done before - can either be done by having a timestamp on ClientAssociation that is incremented every time a code is requested/used, or by having a ClientAssociation per-code. As we'll need to store more specific to a code than just the fact it has been used or not, I think it's best to just have a ClientAssociation per-code
> * Not expired - no prob
> * Session active - no prob
> * redirect_uri when retrieving code matches redirect_uri query param when swapping for token - we don't do this currently I think, but spec requires it. This would require a ClientAssociation per-code.
> * Correct client_id - no prob, just make sure code belongs to the client_id query param
>

Create a ClientAssociation per AccessCode.  As there is a refresh token 
created per access code.  What's great is that you have a log of refresh 
token creation times too.

> Then to create the token we need:
>
> * List of roles requested - the union of user roles and app/client scope. This would require a ClientAssociation per-code as the role-mappings/scope could change between user granted the roles to the client and the code is exchanged. Also in the future once we add a scope query param this will be required.
> * Realm - no prob, user-session is associated with a realm
> * Client - no prob, ClientAssociation is associated with a client
> * User - no prob, user-session is associated with a user
> * Session - no prob, user-session is a session ;)
>
> All in all it seems like a bit more work than I initially considered. Or am I attacking this completely wrong?!?
>

It is a lot of work, yes.  Changes to a lot of files too.

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

From bburke at redhat.com  Thu Jul 17 16:36:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 17 Jul 2014 16:36:56 -0400
Subject: [keycloak-dev] more db schema changes
Message-ID: <53C833E8.5050809@redhat.com>

* created @NamedQuery for every creatQuery we have
* Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere. 
names are uppercase with "_".  At least 10+ years ago, this was the 
standard naming convention.
* CredentialEntity now has a generated String ID.  We will want to have 
multiple TOTP entries in the future.

Bill

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

From stian at redhat.com  Fri Jul 18 04:25:10 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jul 2014 04:25:10 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <53C80AF5.1030603@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C80AF5.1030603@redhat.com>
Message-ID: <1098011932.12602826.1405671910380.JavaMail.zimbra@redhat.com>

Last we didn't do it because of the potential headache for admins to deal with it, especially in a cloud environment.

I wonder if it would make sense to always encrypt in the database with a master key for the server. The master key could then be specified in keycloak-server.json. If users need the additional security they could make sure keycloak-server.json (as well as standalone.xml which has the ssl certificate keys) are stored on an encrypted drive. If not stored in keycloak-server.json the user would have to specify it when starting the server, which would have to be done by a prompt I think. Specifying it as an environment variable or system properties is not very safe as that can just as easily be read by an intruder as a file. This would make life a bit harder in a cluster though.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 17 July, 2014 6:42:13 PM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> One thing, which we discussed before was encoding of privateKey before
> saving to DB? As currently if someone "steal" database record with
> privateKey, he is able to create encoded accessTokens and send requests
> to bearer-only applications.
> 
> Or is this still planned for August?
> 
> Marek
> 
> On 17.7.2014 14:55, Stian Thorgersen wrote:
> > As we didn't have enough things to do last minute I come up with more
> > things which I think we should do for 1.0.final:
> >
> > 1. Configure JPA through keycloak-server.json instead of persistence.xml
> >
> > This would be super simple to do, and would let us have a single
> > persistence.xml for everything (testsuite, server, project-integrations).
> > Everything worthy of configuring in persistence.xml (including datasource)
> > can be passed in the Map overrides when creating the EntityManagerFactory.
> >
> >
> > 2. Introduce server-dependencies-min and server-dependencies-all poms
> >
> > We have a few places that includes all the dependencies required (server,
> > testsuite/integration and testsuite/) as well as other project such as
> > AeroGear and LiveOak. Instead of everyone having to list all the
> > dependencies they could have a single dependency on either
> > server-dependencies-min or server-dependencies-all. Min would exclude most
> > if not all provider implementations (such as PicketLink/LDAP, social
> > providers, etc).
> >
> >
> > 3. TOTP SPI
> >
> > At the moment we only support Google Authenticator, I don't think that's
> > sufficient. We should at the very least add support for one more, and have
> > an SPI so users can add their own. I think this would be related to the
> > UserProvider sync work, as some UserProvider implementations may require
> > both a password and totp to verify a users credentials, while others would
> > only be able to verify the password and then have Keycloak verify the
> > totp.
> >
> > Also, do we need to support users with more than one totp? Personally I
> > have two for work (one I use daily and another for backup).
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From stian at redhat.com  Fri Jul 18 04:35:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jul 2014 04:35:33 -0400 (EDT)
Subject: [keycloak-dev] Reset password and verify email links are to long
In-Reply-To: <53C80362.6040202@redhat.com>
References: <891231804.10659774.1405439358837.JavaMail.zimbra@redhat.com>
	<53C67479.3000404@redhat.com>
	<239832188.11182774.1405515369320.JavaMail.zimbra@redhat.com>
	<53C6788B.5040603@redhat.com>
	<1377474670.11192219.1405516177250.JavaMail.zimbra@redhat.com>
	<53C67AC5.2000103@redhat.com>
	<453820441.12136958.1405609230559.JavaMail.zimbra@redhat.com>
	<53C80362.6040202@redhat.com>
Message-ID: <537971842.12613909.1405672533248.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 17 July, 2014 6:09:54 PM
> Subject: Re: [keycloak-dev] Reset password and verify email links are to long
> 
> On 17.7.2014 17:00, Stian Thorgersen wrote:
> > Just started on this. Quick summary of my attack plan:
> >
> > 1. Remove AccessToken from AccessCode. Instead add List<String>
> > rolesRequested and create AccessToken in TokenService.accessCodeToToken.
> > Any reasons why this wouldn't work?
> > 2. Move some info from AccessCode to UserSession, and remove anything
> > redundant. For example username used to login, auth-method (social or
> > form), remember-me.
> > 3. Add info from AccessCode to UserSessionProvider and send signed key
> > instead as the code query param.
> >
> > With regards to the required info here's what I've come up with:
> >
> > To verify the code:
> >
> > * Need to know it hasn't been done before - can either be done by having a
> > timestamp on ClientAssociation that is incremented every time a code is
> > requested/used, or by having a ClientAssociation per-code. As we'll need
> > to store more specific to a code than just the fact it has been used or
> > not, I think it's best to just have a ClientAssociation per-code
> > * Not expired - no prob
> > * Session active - no prob
> > * redirect_uri when retrieving code matches redirect_uri query param when
> > swapping for token - we don't do this currently I think, but spec requires
> > it. This would require a ClientAssociation per-code.
> > * Correct client_id - no prob, just make sure code belongs to the client_id
> > query param
> >
> > Then to create the token we need:
> >
> > * List of roles requested - the union of user roles and app/client scope.
> > This would require a ClientAssociation per-code as the role-mappings/scope
> > could change between user granted the roles to the client and the code is
> > exchanged. Also in the future once we add a scope query param this will be
> > required.
> Did you mean intersection rather than union?
> > * Realm - no prob, user-session is associated with a realm
> > * Client - no prob, ClientAssociation is associated with a client
> > * User - no prob, user-session is associated with a user
> > * Session - no prob, user-session is a session;)
> >
> > All in all it seems like a bit more work than I initially considered. Or am
> > I attacking this completely wrong?!?
> To me it makes sense and should work.
> 
> I wonder about a bit less-time consuming flow to implement, when
> AccessCode is generated together with AccessToken after authentication
> as it's now (in OAuthFlows.processAccessCode) . Only new thing in
> OAuthFlows.processAccessCode will be that ClientAssociation with just
> key-value pair of <signed-codeId>:<base64-encoded-AccessCode> will be
> associated with UserSession. Signed codeId will be then saved as "code"
> parameter .
> 
> Then once client will want to exchange code, Keycloak will perform
> lookup of correct UserSession based on codeId (new method on
> UserSessionProvider like: getSessionbyCode). Then when UserSession is
> successfully looked-up, ClientAssociation is immediatelly deleted, so
> that it's not possible to exchange same code twice. In
> TokenService.accessCodeToToken, we will still have AccessCode with
> wrapped AccessToken so we can do all verification is it's done now. Only
> new thing might be redirect_uri verification, which is not currently done.
> 
> Defacto it will be same as current flow, only new thing will be:
> - ClientAssociation with the pair
> <signed-codeId>:<base64-encoded-AccessCode>, created when code is
> generated and deleted when code is exchanged.
> - redirect_uri validation during exchange code to token.
> 
> I think that this approach will help us to address 2 main issues, which
> we currently have (long "code" parameter and same code is possible to
> exchange more times). Only thing is, that base64-encoded-AccessCode will
> be quite long and will contain redundant info, but is it big problem? If
> we want later add new info to AccessCode, we don't need to do any
> changes in UserSessionProvider model as it will be still just base64
> encoded string.
> 
> Not sure which approach is better, just a though:-)

I think that's still a fair amount of work, but a bit of a "hack".

With regards to changes to UserSessionProvider that doesn't bother me much. I'd say that's more an internal SPI, so doesn't have to be as stable, also upgrading should be trivial as we don't really care about existing data when upgrading to a new KC version. 

> 
> Marek
> 

From mposolda at redhat.com  Fri Jul 18 05:03:38 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 18 Jul 2014 11:03:38 +0200
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <1098011932.12602826.1405671910380.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C80AF5.1030603@redhat.com>
	<1098011932.12602826.1405671910380.JavaMail.zimbra@redhat.com>
Message-ID: <53C8E2EA.90703@redhat.com>

On 18.7.2014 10:25, Stian Thorgersen wrote:
> Last we didn't do it because of the potential headache for admins to deal with it, especially in a cloud environment.
>
> I wonder if it would make sense to always encrypt in the database with a master key for the server. The master key could then be specified in keycloak-server.json. If users need the additional security they could make sure keycloak-server.json (as well as standalone.xml which has the ssl certificate keys) are stored on an encrypted drive. If not stored in keycloak-server.json the user would have to specify it when starting the server, which would have to be done by a prompt I think. Specifying it as an environment variable or system properties is not very safe as that can just as easily be read by an intruder as a file. This would make life a bit harder in a cluster though.
Not sure about prompt, but master key in keycloak-server.json should 
work well and won't be a pain in cluster as long as all cluster nodes 
have same value in keycloak-server.json? Only thing is that if we add 
some default value into keycloak-server.json, then probably 99% of 
people won't change it:-)

But it's better than nothing IMO as people at least have possibility to 
change the master key if they want better security .

Maybe best is to have SPI with encrypt/decrypt methods, which adds best 
flexibility for people (default implementation will just encrypt/decrypt 
with master key from keycloak-server.json)?

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 17 July, 2014 6:42:13 PM
>> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
>>
>> One thing, which we discussed before was encoding of privateKey before
>> saving to DB? As currently if someone "steal" database record with
>> privateKey, he is able to create encoded accessTokens and send requests
>> to bearer-only applications.
>>
>> Or is this still planned for August?
>>
>> Marek
>>
>> On 17.7.2014 14:55, Stian Thorgersen wrote:
>>> As we didn't have enough things to do last minute I come up with more
>>> things which I think we should do for 1.0.final:
>>>
>>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
>>>
>>> This would be super simple to do, and would let us have a single
>>> persistence.xml for everything (testsuite, server, project-integrations).
>>> Everything worthy of configuring in persistence.xml (including datasource)
>>> can be passed in the Map overrides when creating the EntityManagerFactory.
>>>
>>>
>>> 2. Introduce server-dependencies-min and server-dependencies-all poms
>>>
>>> We have a few places that includes all the dependencies required (server,
>>> testsuite/integration and testsuite/) as well as other project such as
>>> AeroGear and LiveOak. Instead of everyone having to list all the
>>> dependencies they could have a single dependency on either
>>> server-dependencies-min or server-dependencies-all. Min would exclude most
>>> if not all provider implementations (such as PicketLink/LDAP, social
>>> providers, etc).
>>>
>>>
>>> 3. TOTP SPI
>>>
>>> At the moment we only support Google Authenticator, I don't think that's
>>> sufficient. We should at the very least add support for one more, and have
>>> an SPI so users can add their own. I think this would be related to the
>>> UserProvider sync work, as some UserProvider implementations may require
>>> both a password and totp to verify a users credentials, while others would
>>> only be able to verify the password and then have Keycloak verify the
>>> totp.
>>>
>>> Also, do we need to support users with more than one totp? Personally I
>>> have two for work (one I use daily and another for backup).
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Fri Jul 18 05:08:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jul 2014 05:08:13 -0400 (EDT)
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <53C8E2EA.90703@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C80AF5.1030603@redhat.com>
	<1098011932.12602826.1405671910380.JavaMail.zimbra@redhat.com>
	<53C8E2EA.90703@redhat.com>
Message-ID: <851382424.12645781.1405674493572.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Friday, 18 July, 2014 10:03:38 AM
> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> 
> On 18.7.2014 10:25, Stian Thorgersen wrote:
> > Last we didn't do it because of the potential headache for admins to deal
> > with it, especially in a cloud environment.
> >
> > I wonder if it would make sense to always encrypt in the database with a
> > master key for the server. The master key could then be specified in
> > keycloak-server.json. If users need the additional security they could
> > make sure keycloak-server.json (as well as standalone.xml which has the
> > ssl certificate keys) are stored on an encrypted drive. If not stored in
> > keycloak-server.json the user would have to specify it when starting the
> > server, which would have to be done by a prompt I think. Specifying it as
> > an environment variable or system properties is not very safe as that can
> > just as easily be read by an intruder as a file. This would make life a
> > bit harder in a cluster though.
> Not sure about prompt, but master key in keycloak-server.json should
> work well and won't be a pain in cluster as long as all cluster nodes
> have same value in keycloak-server.json? Only thing is that if we add
> some default value into keycloak-server.json, then probably 99% of
> people won't change it:-)

We'd have to generate it on the first startup. I guess in a cluster people would have to sync keycloak-server.json between all nodes in either case. 

> 
> But it's better than nothing IMO as people at least have possibility to
> change the master key if they want better security .
> 
> Maybe best is to have SPI with encrypt/decrypt methods, which adds best
> flexibility for people (default implementation will just encrypt/decrypt
> with master key from keycloak-server.json)?

Yep, we may even want to support hardware security modules, which would require some form of an SPI for encryption/decryption. IMO that's not for this round though.

> 
> Marek
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> >> <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, 17 July, 2014 6:42:13 PM
> >> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >>
> >> One thing, which we discussed before was encoding of privateKey before
> >> saving to DB? As currently if someone "steal" database record with
> >> privateKey, he is able to create encoded accessTokens and send requests
> >> to bearer-only applications.
> >>
> >> Or is this still planned for August?
> >>
> >> Marek
> >>
> >> On 17.7.2014 14:55, Stian Thorgersen wrote:
> >>> As we didn't have enough things to do last minute I come up with more
> >>> things which I think we should do for 1.0.final:
> >>>
> >>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
> >>>
> >>> This would be super simple to do, and would let us have a single
> >>> persistence.xml for everything (testsuite, server, project-integrations).
> >>> Everything worthy of configuring in persistence.xml (including
> >>> datasource)
> >>> can be passed in the Map overrides when creating the
> >>> EntityManagerFactory.
> >>>
> >>>
> >>> 2. Introduce server-dependencies-min and server-dependencies-all poms
> >>>
> >>> We have a few places that includes all the dependencies required (server,
> >>> testsuite/integration and testsuite/) as well as other project such as
> >>> AeroGear and LiveOak. Instead of everyone having to list all the
> >>> dependencies they could have a single dependency on either
> >>> server-dependencies-min or server-dependencies-all. Min would exclude
> >>> most
> >>> if not all provider implementations (such as PicketLink/LDAP, social
> >>> providers, etc).
> >>>
> >>>
> >>> 3. TOTP SPI
> >>>
> >>> At the moment we only support Google Authenticator, I don't think that's
> >>> sufficient. We should at the very least add support for one more, and
> >>> have
> >>> an SPI so users can add their own. I think this would be related to the
> >>> UserProvider sync work, as some UserProvider implementations may require
> >>> both a password and totp to verify a users credentials, while others
> >>> would
> >>> only be able to verify the password and then have Keycloak verify the
> >>> totp.
> >>>
> >>> Also, do we need to support users with more than one totp? Personally I
> >>> have two for work (one I use daily and another for backup).
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> 

From stian at redhat.com  Fri Jul 18 06:41:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jul 2014 06:41:50 -0400 (EDT)
Subject: [keycloak-dev] Configuration of database moved to
	keycloak-server.json
Message-ID: <1630759771.12729778.1405680110052.JavaMail.zimbra@redhat.com>

Database configuration is now moved to keycloak-server.json (before it required editing persistence.xml).

See https://github.com/keycloak/keycloak/wiki/keycloak-server.json-options for details. This is just a temporary place holder and the documentation needs to be updated.

From stian at redhat.com  Fri Jul 18 07:23:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 18 Jul 2014 07:23:34 -0400 (EDT)
Subject: [keycloak-dev] Scope param
In-Reply-To: <2099606009.12746712.1405682444574.JavaMail.zimbra@redhat.com>
Message-ID: <1506166864.12748642.1405682614170.JavaMail.zimbra@redhat.com>

Should we add support for the scope param to 1.0.beta4? It can be done as part of the access code work.

To make it OAuth2 friendly I propose we use the following format:

?scope=realm-role1 realm-role2 app/app-role1 app2/app-role2

Basically a "list of space-delimited, case-sensitive strings" as specified in the spec, where each string is either "<realm role name>" or "<app name>/<app role name>"

From ssilvert at redhat.com  Fri Jul 18 09:29:54 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 18 Jul 2014 09:29:54 -0400
Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
Message-ID: <53C92152.5080709@redhat.com>

Hi guys,

My overall goal is to unite JBoss user-facing products via Keycloak 
SSO.  The first major task is make it as easy as possible to use 
Keycloak with the WildFly web console.  I have this working, but it 
takes quite a bit of setup.

Ideally, there should be a simple switch in WildFly that says, "Use 
Keycloak for web console", and it all just works.

So I'm looking for ideas on how to automate these setup tasks:
* Deploy Keycloak auth server and keycloak-ds.xml
* Seed the database with an initial realm, user, roles, and two applications
* Create keycloak.json files or populate keycloak subsystem for the two 
apps.

Thanks in advance,

Stan

From bburke at redhat.com  Fri Jul 18 11:50:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Jul 2014 11:50:29 -0400
Subject: [keycloak-dev] Scope param
In-Reply-To: <1506166864.12748642.1405682614170.JavaMail.zimbra@redhat.com>
References: <1506166864.12748642.1405682614170.JavaMail.zimbra@redhat.com>
Message-ID: <53C94245.2090706@redhat.com>

If you're going to do this, please review OpenID Connect Scope settings.

On 7/18/2014 7:23 AM, Stian Thorgersen wrote:
> Should we add support for the scope param to 1.0.beta4? It can be done as part of the access code work.
>
> To make it OAuth2 friendly I propose we use the following format:
>
> ?scope=realm-role1 realm-role2 app/app-role1 app2/app-role2
>
> Basically a "list of space-delimited, case-sensitive strings" as specified in the spec, where each string is either "<realm role name>" or "<app name>/<app role name>"
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From mposolda at redhat.com  Fri Jul 18 11:51:52 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 18 Jul 2014 17:51:52 +0200
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <53C833E8.5050809@redhat.com>
References: <53C833E8.5050809@redhat.com>
Message-ID: <53C94298.3020302@redhat.com>

Hi,

just wanted to point that all recent DB changes seem to break databases 
(or at least MySQL). Actually when running testsuite with MySQL, then at 
the end of some tests during Hibernate schema cleanup, it hangs. Just 
figured out that it's this SQL command which causes hang of MySQL: alter 
table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;

Actually not sure if it's related to compound primary key of 
AuthenticationLinkEntity or foreign key with UserEntity... Will look at 
it more on Monday, just wanted to point that databases doesn't work ATM.

Marek

On 17.7.2014 22:36, Bill Burke wrote:
> * created @NamedQuery for every creatQuery we have
> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
> names are uppercase with "_".  At least 10+ years ago, this was the
> standard naming convention.
> * CredentialEntity now has a generated String ID.  We will want to have
> multiple TOTP entries in the future.
>
> Bill
>


From bburke at redhat.com  Fri Jul 18 12:03:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Jul 2014 12:03:07 -0400
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <53C94298.3020302@redhat.com>
References: <53C833E8.5050809@redhat.com> <53C94298.3020302@redhat.com>
Message-ID: <53C9453B.1050605@redhat.com>

Ugh.  Might be the double @ManyToOne hack I had to do for auth link.

On 7/18/2014 11:51 AM, Marek Posolda wrote:
> Hi,
>
> just wanted to point that all recent DB changes seem to break databases
> (or at least MySQL). Actually when running testsuite with MySQL, then at
> the end of some tests during Hibernate schema cleanup, it hangs. Just
> figured out that it's this SQL command which causes hang of MySQL: alter
> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
>
> Actually not sure if it's related to compound primary key of
> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
> it more on Monday, just wanted to point that databases doesn't work ATM.
>
> Marek
>
> On 17.7.2014 22:36, Bill Burke wrote:
>> * created @NamedQuery for every creatQuery we have
>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
>> names are uppercase with "_".  At least 10+ years ago, this was the
>> standard naming convention.
>> * CredentialEntity now has a generated String ID.  We will want to have
>> multiple TOTP entries in the future.
>>
>> Bill
>>
>

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

From bburke at redhat.com  Fri Jul 18 12:26:32 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Jul 2014 12:26:32 -0400
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <53C9453B.1050605@redhat.com>
References: <53C833E8.5050809@redhat.com> <53C94298.3020302@redhat.com>
	<53C9453B.1050605@redhat.com>
Message-ID: <53C94AB8.3010102@redhat.com>

Nevermind.  Stian changed it already.  Not sure why now...

On 7/18/2014 12:03 PM, Bill Burke wrote:
> Ugh.  Might be the double @ManyToOne hack I had to do for auth link.
>
> On 7/18/2014 11:51 AM, Marek Posolda wrote:
>> Hi,
>>
>> just wanted to point that all recent DB changes seem to break databases
>> (or at least MySQL). Actually when running testsuite with MySQL, then at
>> the end of some tests during Hibernate schema cleanup, it hangs. Just
>> figured out that it's this SQL command which causes hang of MySQL: alter
>> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
>>
>> Actually not sure if it's related to compound primary key of
>> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
>> it more on Monday, just wanted to point that databases doesn't work ATM.
>>
>> Marek
>>
>> On 17.7.2014 22:36, Bill Burke wrote:
>>> * created @NamedQuery for every creatQuery we have
>>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
>>> names are uppercase with "_".  At least 10+ years ago, this was the
>>> standard naming convention.
>>> * CredentialEntity now has a generated String ID.  We will want to have
>>> multiple TOTP entries in the future.
>>>
>>> Bill
>>>
>>
>

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

From bburke at redhat.com  Fri Jul 18 17:48:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Jul 2014 17:48:21 -0400
Subject: [keycloak-dev] keep exploded war and add exploded themes
Message-ID: <53C99625.5020703@redhat.com>

I want to always keep an exploded WAR.  Additionally, I'd like to 
explode all built-in themes in WEB-INF/classes.  People are going to 
want to see how its done and will need concrete examples.

For example, one of the things I want to do with Federation plugins is 
that users can create their own management page for their plugin.  They 
will need to see examples/templates from the existing admin consoole.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Jul 18 22:05:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 18 Jul 2014 22:05:27 -0400
Subject: [keycloak-dev] AuthProvider refactor details
Message-ID: <53C9D267.5060702@redhat.com>

I reviewed Marek's code.  The refactor is going to be pretty much 
Marek's code except reorganized a little bit.  Hopefully you can follow 
what I'm saying.  I'll try and follow up with code in a few days.

* AuthProvider is going to turn into FederationProvider which is an 
extension of UserProvider

public interface FederationProvider extends UserProvider {
     String getAdminPage();
     Class<? extends FederatonAdmin> getAdminClass();
     UserModel proxy(UserModel localUser);
}

* AuthenticationProviderManager is going to turn into a concrete class 
which implements UserProvider, FederationManager.  It will basically do 
the same algorithm as AuthProviderManager for finding users (looping 
through the realm's configured FederationProviders), except it will be 
using the UserProvider interface and returning UserModels.
- UserModel getXXX() methods will search within "local" storage first 
for a user.
- If exists, it will look at the UserModel.getProvider() attribute to 
learn which provider to use.  Then call FederationProvider.proxy() 
method.  This will allow the FederationProvider to proxy the UserModel 
so it can perform on demand sync.

* KeycloakSession will allocate a FederationManager and wrap it with a 
CacheUserProvider instead of getting the "local" user storage provider.

* LDAP/Picketlink code will turn into a set of abstract classes used to 
build the LDAPFederationProvider.
- getXXX will try to locate in LDAP store.  If exists, it will import 
the user into the "local" storage UserModel.  It will create a proxy to 
this local storage.  This proxy will allow on-demand sync.

Configuration:

* AuthentiationProviderModel will be renamed to FederationProviderModel. 
  RealmModel will also return a list of these
* LDAP code will not use Realm.getLdapConfig().  It will instead use 
FederationProviderModel config.

Management:

* Federation configuration will move from the Realm Settings page, to 
the Users page.
* getAdminPage and getAdminClass exist so that FederationProvider 
plugins can plug-in their own admin console UI and REST API.
* FederationProvider.getAdminPage() will point to a admin console path. 
  When adding a FederationProvider, the admin console will load this 
page for setup/config.
* The FederationProvider.getAdminClass() method will return a JAX-RS 
resource locator class that implements

interface FederationAdmin {
    void setAdmin(UserModel admin);
    void setSession(Keycloak session);
    void setRealm(RealmModel realm);
}
* The admin class will be instantiated when invoking REST calls to
.../realms/{realm}/users/providers/{provider-name}/...

That's it in a nutshell.  I haven't implemented any of this, its just in 
my head and there's probably a lot of details I've overlooked that I'll 
figure out when I code.



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

From bburke at redhat.com  Sun Jul 20 17:05:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Sun, 20 Jul 2014 17:05:19 -0400
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <53C9D267.5060702@redhat.com>
References: <53C9D267.5060702@redhat.com>
Message-ID: <53CC2F0F.8010107@redhat.com>

One thing I'm not sure what do do is getUserCount().  can't really get 
an accurate user count in a federated environment.  I see this is only 
used by export?  Probably not an issue as export would only use local 
Keycloak storage.


On 7/18/2014 10:05 PM, Bill Burke wrote:
> I reviewed Marek's code.  The refactor is going to be pretty much
> Marek's code except reorganized a little bit.  Hopefully you can follow
> what I'm saying.  I'll try and follow up with code in a few days.
>
> * AuthProvider is going to turn into FederationProvider which is an
> extension of UserProvider
>
> public interface FederationProvider extends UserProvider {
>       String getAdminPage();
>       Class<? extends FederatonAdmin> getAdminClass();
>       UserModel proxy(UserModel localUser);
> }
>
> * AuthenticationProviderManager is going to turn into a concrete class
> which implements UserProvider, FederationManager.  It will basically do
> the same algorithm as AuthProviderManager for finding users (looping
> through the realm's configured FederationProviders), except it will be
> using the UserProvider interface and returning UserModels.
> - UserModel getXXX() methods will search within "local" storage first
> for a user.
> - If exists, it will look at the UserModel.getProvider() attribute to
> learn which provider to use.  Then call FederationProvider.proxy()
> method.  This will allow the FederationProvider to proxy the UserModel
> so it can perform on demand sync.
>
> * KeycloakSession will allocate a FederationManager and wrap it with a
> CacheUserProvider instead of getting the "local" user storage provider.
>
> * LDAP/Picketlink code will turn into a set of abstract classes used to
> build the LDAPFederationProvider.
> - getXXX will try to locate in LDAP store.  If exists, it will import
> the user into the "local" storage UserModel.  It will create a proxy to
> this local storage.  This proxy will allow on-demand sync.
>
> Configuration:
>
> * AuthentiationProviderModel will be renamed to FederationProviderModel.
>    RealmModel will also return a list of these
> * LDAP code will not use Realm.getLdapConfig().  It will instead use
> FederationProviderModel config.
>
> Management:
>
> * Federation configuration will move from the Realm Settings page, to
> the Users page.
> * getAdminPage and getAdminClass exist so that FederationProvider
> plugins can plug-in their own admin console UI and REST API.
> * FederationProvider.getAdminPage() will point to a admin console path.
>    When adding a FederationProvider, the admin console will load this
> page for setup/config.
> * The FederationProvider.getAdminClass() method will return a JAX-RS
> resource locator class that implements
>
> interface FederationAdmin {
>      void setAdmin(UserModel admin);
>      void setSession(Keycloak session);
>      void setRealm(RealmModel realm);
> }
> * The admin class will be instantiated when invoking REST calls to
> .../realms/{realm}/users/providers/{provider-name}/...
>
> That's it in a nutshell.  I haven't implemented any of this, its just in
> my head and there's probably a lot of details I've overlooked that I'll
> figure out when I code.
>
>
>

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

From stian at redhat.com  Mon Jul 21 04:28:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jul 2014 04:28:19 -0400 (EDT)
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <53C94AB8.3010102@redhat.com>
References: <53C833E8.5050809@redhat.com> <53C94298.3020302@redhat.com>
	<53C9453B.1050605@redhat.com> <53C94AB8.3010102@redhat.com>
Message-ID: <977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>

I changed it as I couldn't get the composite ids to work. Did I break something?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 18 July, 2014 5:26:32 PM
> Subject: Re: [keycloak-dev] more db schema changes
> 
> Nevermind.  Stian changed it already.  Not sure why now...
> 
> On 7/18/2014 12:03 PM, Bill Burke wrote:
> > Ugh.  Might be the double @ManyToOne hack I had to do for auth link.
> >
> > On 7/18/2014 11:51 AM, Marek Posolda wrote:
> >> Hi,
> >>
> >> just wanted to point that all recent DB changes seem to break databases
> >> (or at least MySQL). Actually when running testsuite with MySQL, then at
> >> the end of some tests during Hibernate schema cleanup, it hangs. Just
> >> figured out that it's this SQL command which causes hang of MySQL: alter
> >> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
> >>
> >> Actually not sure if it's related to compound primary key of
> >> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
> >> it more on Monday, just wanted to point that databases doesn't work ATM.
> >>
> >> Marek
> >>
> >> On 17.7.2014 22:36, Bill Burke wrote:
> >>> * created @NamedQuery for every creatQuery we have
> >>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
> >>> names are uppercase with "_".  At least 10+ years ago, this was the
> >>> standard naming convention.
> >>> * CredentialEntity now has a generated String ID.  We will want to have
> >>> multiple TOTP entries in the future.
> >>>
> >>> 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 mposolda at redhat.com  Mon Jul 21 04:34:30 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Jul 2014 10:34:30 +0200
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <53CC2F0F.8010107@redhat.com>
References: <53C9D267.5060702@redhat.com> <53CC2F0F.8010107@redhat.com>
Message-ID: <53CCD096.3080107@redhat.com>

I am not sure I understand why "getUserCount" is an issue and for 
example "getUsers" or "searchForUser" is not? Am I understand correctly 
that implementor of FederationProvider can choose which method to 
override, so for example if he won't override "getUsers" or 
"getUserCount" then FederationManager just delegates those to "local" 
UserProvider?

If getUserCount() is an issue, I can remove it and refactor export to 
not using it and instead use approach like: "checkout users until 
current page is not full", which would mean that there are no more users 
to export (Like for example if I have 50 users and usersPerPage is 20, 
then page1 has 20 users, page2 has 20 users and page3 has just 10 users, 
so export process can recognize that it is last page).

But still getUserCount() may be useful if we later want to add 
pagination support to admin console (in this case, we may need "count" 
methods also for searchFor** - 
https://issues.jboss.org/browse/KEYCLOAK-564 )

Marek

On 20.7.2014 23:05, Bill Burke wrote:
> One thing I'm not sure what do do is getUserCount().  can't really get
> an accurate user count in a federated environment.  I see this is only
> used by export?  Probably not an issue as export would only use local
> Keycloak storage.
>
>
> On 7/18/2014 10:05 PM, Bill Burke wrote:
>> I reviewed Marek's code.  The refactor is going to be pretty much
>> Marek's code except reorganized a little bit.  Hopefully you can follow
>> what I'm saying.  I'll try and follow up with code in a few days.
>>
>> * AuthProvider is going to turn into FederationProvider which is an
>> extension of UserProvider
>>
>> public interface FederationProvider extends UserProvider {
>>        String getAdminPage();
>>        Class<? extends FederatonAdmin> getAdminClass();
>>        UserModel proxy(UserModel localUser);
>> }
>>
>> * AuthenticationProviderManager is going to turn into a concrete class
>> which implements UserProvider, FederationManager.  It will basically do
>> the same algorithm as AuthProviderManager for finding users (looping
>> through the realm's configured FederationProviders), except it will be
>> using the UserProvider interface and returning UserModels.
>> - UserModel getXXX() methods will search within "local" storage first
>> for a user.
>> - If exists, it will look at the UserModel.getProvider() attribute to
>> learn which provider to use.  Then call FederationProvider.proxy()
>> method.  This will allow the FederationProvider to proxy the UserModel
>> so it can perform on demand sync.
>>
>> * KeycloakSession will allocate a FederationManager and wrap it with a
>> CacheUserProvider instead of getting the "local" user storage provider.
>>
>> * LDAP/Picketlink code will turn into a set of abstract classes used to
>> build the LDAPFederationProvider.
>> - getXXX will try to locate in LDAP store.  If exists, it will import
>> the user into the "local" storage UserModel.  It will create a proxy to
>> this local storage.  This proxy will allow on-demand sync.
>>
>> Configuration:
>>
>> * AuthentiationProviderModel will be renamed to FederationProviderModel.
>>     RealmModel will also return a list of these
>> * LDAP code will not use Realm.getLdapConfig().  It will instead use
>> FederationProviderModel config.
>>
>> Management:
>>
>> * Federation configuration will move from the Realm Settings page, to
>> the Users page.
>> * getAdminPage and getAdminClass exist so that FederationProvider
>> plugins can plug-in their own admin console UI and REST API.
>> * FederationProvider.getAdminPage() will point to a admin console path.
>>     When adding a FederationProvider, the admin console will load this
>> page for setup/config.
>> * The FederationProvider.getAdminClass() method will return a JAX-RS
>> resource locator class that implements
>>
>> interface FederationAdmin {
>>       void setAdmin(UserModel admin);
>>       void setSession(Keycloak session);
>>       void setRealm(RealmModel realm);
>> }
>> * The admin class will be instantiated when invoking REST calls to
>> .../realms/{realm}/users/providers/{provider-name}/...
>>
>> That's it in a nutshell.  I haven't implemented any of this, its just in
>> my head and there's probably a lot of details I've overlooked that I'll
>> figure out when I code.
>>
>>
>>


From stian at redhat.com  Mon Jul 21 04:35:41 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jul 2014 04:35:41 -0400 (EDT)
Subject: [keycloak-dev] keep exploded war and add exploded themes
In-Reply-To: <53C99625.5020703@redhat.com>
References: <53C99625.5020703@redhat.com>
Message-ID: <1578613941.13746625.1405931741907.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 18 July, 2014 10:48:21 PM
> Subject: [keycloak-dev] keep exploded war and add exploded themes
> 
> I want to always keep an exploded WAR.  Additionally, I'd like to
> explode all built-in themes in WEB-INF/classes.  People are going to
> want to see how its done and will need concrete examples.

What's the use-case for the exploded WAR?

I don't see any need in exploding the themes, they're already exploded to standalone/configuration/themes.

> 
> For example, one of the things I want to do with Federation plugins is
> that users can create their own management page for their plugin.  They
> will need to see examples/templates from the existing admin consoole.

I don't think that's a very elegant way to "extend" the console. A much better approach would be to then investigate UberFire or Hawt.

My idea for managing providers was that we'd add a generic mechanism for configuring. That would be much simpler to use for folks than having to create (and maintain) their own additional pages in the admin console. I thought we had agreed that we where doing that for 1.0.beta4?

> --
> 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 Jul 21 04:37:16 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Jul 2014 10:37:16 +0200
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>
References: <53C833E8.5050809@redhat.com>
	<53C94298.3020302@redhat.com>	<53C9453B.1050605@redhat.com>
	<53C94AB8.3010102@redhat.com>
	<977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>
Message-ID: <53CCD13C.7000702@redhat.com>

I don't know if it's this change or some other change. I am going to 
investigate and reverify all databases.

Marek

On 21.7.2014 10:28, Stian Thorgersen wrote:
> I changed it as I couldn't get the composite ids to work. Did I break something?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 18 July, 2014 5:26:32 PM
>> Subject: Re: [keycloak-dev] more db schema changes
>>
>> Nevermind.  Stian changed it already.  Not sure why now...
>>
>> On 7/18/2014 12:03 PM, Bill Burke wrote:
>>> Ugh.  Might be the double @ManyToOne hack I had to do for auth link.
>>>
>>> On 7/18/2014 11:51 AM, Marek Posolda wrote:
>>>> Hi,
>>>>
>>>> just wanted to point that all recent DB changes seem to break databases
>>>> (or at least MySQL). Actually when running testsuite with MySQL, then at
>>>> the end of some tests during Hibernate schema cleanup, it hangs. Just
>>>> figured out that it's this SQL command which causes hang of MySQL: alter
>>>> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
>>>>
>>>> Actually not sure if it's related to compound primary key of
>>>> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
>>>> it more on Monday, just wanted to point that databases doesn't work ATM.
>>>>
>>>> Marek
>>>>
>>>> On 17.7.2014 22:36, Bill Burke wrote:
>>>>> * created @NamedQuery for every creatQuery we have
>>>>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
>>>>> names are uppercase with "_".  At least 10+ years ago, this was the
>>>>> standard naming convention.
>>>>> * CredentialEntity now has a generated String ID.  We will want to have
>>>>> multiple TOTP entries in the future.
>>>>>
>>>>> 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
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Mon Jul 21 04:37:26 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jul 2014 04:37:26 -0400 (EDT)
Subject: [keycloak-dev] Scope param
In-Reply-To: <53C94245.2090706@redhat.com>
References: <1506166864.12748642.1405682614170.JavaMail.zimbra@redhat.com>
	<53C94245.2090706@redhat.com>
Message-ID: <1238415940.13749008.1405931846352.JavaMail.zimbra@redhat.com>

Are you talking about http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims or something else?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 18 July, 2014 4:50:29 PM
> Subject: Re: [keycloak-dev] Scope param
> 
> If you're going to do this, please review OpenID Connect Scope settings.
> 
> On 7/18/2014 7:23 AM, Stian Thorgersen wrote:
> > Should we add support for the scope param to 1.0.beta4? It can be done as
> > part of the access code work.
> >
> > To make it OAuth2 friendly I propose we use the following format:
> >
> > ?scope=realm-role1 realm-role2 app/app-role1 app2/app-role2
> >
> > Basically a "list of space-delimited, case-sensitive strings" as specified
> > in the spec, where each string is either "<realm role name>" or "<app
> > name>/<app role name>"
> > _______________________________________________
> > 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 Jul 21 04:47:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jul 2014 04:47:01 -0400 (EDT)
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <53C9D267.5060702@redhat.com>
References: <53C9D267.5060702@redhat.com>
Message-ID: <2017434014.13756140.1405932421217.JavaMail.zimbra@redhat.com>

Sounds good to me with the exception of the admin console stuff. I don't think adding pages to the admin console this way is very elegant. If we're aiming to make the admin console extensible we should look at UberFire or Hawt to achieve this. However, I think a much simpler way to achieve the same goal is to add a generic configuration mechanism for providers, which would just consist of a key/value map. The provider would also return a list of what keys should be configured.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 19 July, 2014 3:05:27 AM
> Subject: [keycloak-dev] AuthProvider refactor details
> 
> I reviewed Marek's code.  The refactor is going to be pretty much
> Marek's code except reorganized a little bit.  Hopefully you can follow
> what I'm saying.  I'll try and follow up with code in a few days.
> 
> * AuthProvider is going to turn into FederationProvider which is an
> extension of UserProvider
> 
> public interface FederationProvider extends UserProvider {
>      String getAdminPage();
>      Class<? extends FederatonAdmin> getAdminClass();
>      UserModel proxy(UserModel localUser);
> }
> 
> * AuthenticationProviderManager is going to turn into a concrete class
> which implements UserProvider, FederationManager.  It will basically do
> the same algorithm as AuthProviderManager for finding users (looping
> through the realm's configured FederationProviders), except it will be
> using the UserProvider interface and returning UserModels.
> - UserModel getXXX() methods will search within "local" storage first
> for a user.
> - If exists, it will look at the UserModel.getProvider() attribute to
> learn which provider to use.  Then call FederationProvider.proxy()
> method.  This will allow the FederationProvider to proxy the UserModel
> so it can perform on demand sync.
> 
> * KeycloakSession will allocate a FederationManager and wrap it with a
> CacheUserProvider instead of getting the "local" user storage provider.
> 
> * LDAP/Picketlink code will turn into a set of abstract classes used to
> build the LDAPFederationProvider.
> - getXXX will try to locate in LDAP store.  If exists, it will import
> the user into the "local" storage UserModel.  It will create a proxy to
> this local storage.  This proxy will allow on-demand sync.
> 
> Configuration:
> 
> * AuthentiationProviderModel will be renamed to FederationProviderModel.
>   RealmModel will also return a list of these
> * LDAP code will not use Realm.getLdapConfig().  It will instead use
> FederationProviderModel config.
> 
> Management:
> 
> * Federation configuration will move from the Realm Settings page, to
> the Users page.
> * getAdminPage and getAdminClass exist so that FederationProvider
> plugins can plug-in their own admin console UI and REST API.
> * FederationProvider.getAdminPage() will point to a admin console path.
>   When adding a FederationProvider, the admin console will load this
> page for setup/config.
> * The FederationProvider.getAdminClass() method will return a JAX-RS
> resource locator class that implements
> 
> interface FederationAdmin {
>     void setAdmin(UserModel admin);
>     void setSession(Keycloak session);
>     void setRealm(RealmModel realm);
> }
> * The admin class will be instantiated when invoking REST calls to
> .../realms/{realm}/users/providers/{provider-name}/...
> 
> That's it in a nutshell.  I haven't implemented any of this, its just in
> my head and there's probably a lot of details I've overlooked that I'll
> figure out when I code.
> 
> 
> 
> --
> 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 Jul 21 09:24:51 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:24:51 -0400
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>
References: <53C833E8.5050809@redhat.com> <53C94298.3020302@redhat.com>
	<53C9453B.1050605@redhat.com> <53C94AB8.3010102@redhat.com>
	<977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>
Message-ID: <53CD14A3.2070305@redhat.com>

Sorry, I know why you changed it.  I just don't know why it breaks MySQL...

On 7/21/2014 4:28 AM, Stian Thorgersen wrote:
> I changed it as I couldn't get the composite ids to work. Did I break something?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 18 July, 2014 5:26:32 PM
>> Subject: Re: [keycloak-dev] more db schema changes
>>
>> Nevermind.  Stian changed it already.  Not sure why now...
>>
>> On 7/18/2014 12:03 PM, Bill Burke wrote:
>>> Ugh.  Might be the double @ManyToOne hack I had to do for auth link.
>>>
>>> On 7/18/2014 11:51 AM, Marek Posolda wrote:
>>>> Hi,
>>>>
>>>> just wanted to point that all recent DB changes seem to break databases
>>>> (or at least MySQL). Actually when running testsuite with MySQL, then at
>>>> the end of some tests during Hibernate schema cleanup, it hangs. Just
>>>> figured out that it's this SQL command which causes hang of MySQL: alter
>>>> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
>>>>
>>>> Actually not sure if it's related to compound primary key of
>>>> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
>>>> it more on Monday, just wanted to point that databases doesn't work ATM.
>>>>
>>>> Marek
>>>>
>>>> On 17.7.2014 22:36, Bill Burke wrote:
>>>>> * created @NamedQuery for every creatQuery we have
>>>>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
>>>>> names are uppercase with "_".  At least 10+ years ago, this was the
>>>>> standard naming convention.
>>>>> * CredentialEntity now has a generated String ID.  We will want to have
>>>>> multiple TOTP entries in the future.
>>>>>
>>>>> 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
>>

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

From bburke at redhat.com  Mon Jul 21 09:30:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:30:27 -0400
Subject: [keycloak-dev] keep exploded war and add exploded themes
In-Reply-To: <1578613941.13746625.1405931741907.JavaMail.zimbra@redhat.com>
References: <53C99625.5020703@redhat.com>
	<1578613941.13746625.1405931741907.JavaMail.zimbra@redhat.com>
Message-ID: <53CD15F3.4040609@redhat.com>



On 7/21/2014 4:35 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 18 July, 2014 10:48:21 PM
>> Subject: [keycloak-dev] keep exploded war and add exploded themes
>>
>> I want to always keep an exploded WAR.  Additionally, I'd like to
>> explode all built-in themes in WEB-INF/classes.  People are going to
>> want to see how its done and will need concrete examples.
>
> What's the use-case for the exploded WAR?
>
> I don't see any need in exploding the themes, they're already exploded to standalone/configuration/themes.
>

Whoops, forgot about that.

>>
>> For example, one of the things I want to do with Federation plugins is
>> that users can create their own management page for their plugin.  They
>> will need to see examples/templates from the existing admin consoole.
>
> I don't think that's a very elegant way to "extend" the console. A much better approach would be to then investigate UberFire or Hawt.
>
> My idea for managing providers was that we'd add a generic mechanism for configuring. That would be much simpler to use for folks than having to create (and maintain) their own additional pages in the admin console. I thought we had agreed that we where doing that for 1.0.beta4?
>

1) Uberfire/Hawt isn't going to provide a mechanism to plug in a REST 
backend, are they?
2) I'd like LDAP to be treated as a plugin, not a special case, yet, I 
want a nice admin screen for it as it is a feature everybody wants.

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

From bburke at redhat.com  Mon Jul 21 09:30:49 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:30:49 -0400
Subject: [keycloak-dev] Scope param
In-Reply-To: <1238415940.13749008.1405931846352.JavaMail.zimbra@redhat.com>
References: <1506166864.12748642.1405682614170.JavaMail.zimbra@redhat.com>
	<53C94245.2090706@redhat.com>
	<1238415940.13749008.1405931846352.JavaMail.zimbra@redhat.com>
Message-ID: <53CD1609.6000504@redhat.com>

That.

On 7/21/2014 4:37 AM, Stian Thorgersen wrote:
> Are you talking about http://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims or something else?
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 18 July, 2014 4:50:29 PM
>> Subject: Re: [keycloak-dev] Scope param
>>
>> If you're going to do this, please review OpenID Connect Scope settings.
>>
>> On 7/18/2014 7:23 AM, Stian Thorgersen wrote:
>>> Should we add support for the scope param to 1.0.beta4? It can be done as
>>> part of the access code work.
>>>
>>> To make it OAuth2 friendly I propose we use the following format:
>>>
>>> ?scope=realm-role1 realm-role2 app/app-role1 app2/app-role2
>>>
>>> Basically a "list of space-delimited, case-sensitive strings" as specified
>>> in the spec, where each string is either "<realm role name>" or "<app
>>> name>/<app role name>"
>>> _______________________________________________
>>> 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 Jul 21 09:38:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:38:33 -0400
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <2017434014.13756140.1405932421217.JavaMail.zimbra@redhat.com>
References: <53C9D267.5060702@redhat.com>
	<2017434014.13756140.1405932421217.JavaMail.zimbra@redhat.com>
Message-ID: <53CD17D9.4020003@redhat.com>

I said this in other email but:

Positive:

1) I don't know if Hawt/Uberfire have mechanism to plug in a backend 
REST interface,
2) Don't know yet if Hawt/Uberfire can even plug into our theme 
architecture.
3) This way is much easier than bringing in a huge backend framework to 
do something that is really really easy with the small SPI I suggested.
4) Developer doesn't have to learn Hawt/Uberfire. (And neither do we for 
at least 1.0).
5) we can provide a default JAX-RS class and page to do generic properties
6) I want our LDAP provider to be a plugin, but I also want it to have a 
nice config page.


Negative:

1) We're stuck with the API if we move to Hawt/Uberfire.


On 7/21/2014 4:47 AM, Stian Thorgersen wrote:
> Sounds good to me with the exception of the admin console stuff. I don't think adding pages to the admin console this way is very elegant. If we're aiming to make the admin console extensible we should look at UberFire or Hawt to achieve this. However, I think a much simpler way to achieve the same goal is to add a generic configuration mechanism for providers, which would just consist of a key/value map. The provider would also return a list of what keys should be configured.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 19 July, 2014 3:05:27 AM
>> Subject: [keycloak-dev] AuthProvider refactor details
>>
>> I reviewed Marek's code.  The refactor is going to be pretty much
>> Marek's code except reorganized a little bit.  Hopefully you can follow
>> what I'm saying.  I'll try and follow up with code in a few days.
>>
>> * AuthProvider is going to turn into FederationProvider which is an
>> extension of UserProvider
>>
>> public interface FederationProvider extends UserProvider {
>>       String getAdminPage();
>>       Class<? extends FederatonAdmin> getAdminClass();
>>       UserModel proxy(UserModel localUser);
>> }
>>
>> * AuthenticationProviderManager is going to turn into a concrete class
>> which implements UserProvider, FederationManager.  It will basically do
>> the same algorithm as AuthProviderManager for finding users (looping
>> through the realm's configured FederationProviders), except it will be
>> using the UserProvider interface and returning UserModels.
>> - UserModel getXXX() methods will search within "local" storage first
>> for a user.
>> - If exists, it will look at the UserModel.getProvider() attribute to
>> learn which provider to use.  Then call FederationProvider.proxy()
>> method.  This will allow the FederationProvider to proxy the UserModel
>> so it can perform on demand sync.
>>
>> * KeycloakSession will allocate a FederationManager and wrap it with a
>> CacheUserProvider instead of getting the "local" user storage provider.
>>
>> * LDAP/Picketlink code will turn into a set of abstract classes used to
>> build the LDAPFederationProvider.
>> - getXXX will try to locate in LDAP store.  If exists, it will import
>> the user into the "local" storage UserModel.  It will create a proxy to
>> this local storage.  This proxy will allow on-demand sync.
>>
>> Configuration:
>>
>> * AuthentiationProviderModel will be renamed to FederationProviderModel.
>>    RealmModel will also return a list of these
>> * LDAP code will not use Realm.getLdapConfig().  It will instead use
>> FederationProviderModel config.
>>
>> Management:
>>
>> * Federation configuration will move from the Realm Settings page, to
>> the Users page.
>> * getAdminPage and getAdminClass exist so that FederationProvider
>> plugins can plug-in their own admin console UI and REST API.
>> * FederationProvider.getAdminPage() will point to a admin console path.
>>    When adding a FederationProvider, the admin console will load this
>> page for setup/config.
>> * The FederationProvider.getAdminClass() method will return a JAX-RS
>> resource locator class that implements
>>
>> interface FederationAdmin {
>>      void setAdmin(UserModel admin);
>>      void setSession(Keycloak session);
>>      void setRealm(RealmModel realm);
>> }
>> * The admin class will be instantiated when invoking REST calls to
>> .../realms/{realm}/users/providers/{provider-name}/...
>>
>> That's it in a nutshell.  I haven't implemented any of this, its just in
>> my head and there's probably a lot of details I've overlooked that I'll
>> figure out when I code.
>>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Mon Jul 21 09:39:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 21 Jul 2014 09:39:31 -0400 (EDT)
Subject: [keycloak-dev] keep exploded war and add exploded themes
In-Reply-To: <53CD15F3.4040609@redhat.com>
References: <53C99625.5020703@redhat.com>
	<1578613941.13746625.1405931741907.JavaMail.zimbra@redhat.com>
	<53CD15F3.4040609@redhat.com>
Message-ID: <1679396411.13974186.1405949971887.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 21 July, 2014 2:30:27 PM
> Subject: Re: [keycloak-dev] keep exploded war and add exploded themes
> 
> 
> 
> On 7/21/2014 4:35 AM, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 18 July, 2014 10:48:21 PM
> >> Subject: [keycloak-dev] keep exploded war and add exploded themes
> >>
> >> I want to always keep an exploded WAR.  Additionally, I'd like to
> >> explode all built-in themes in WEB-INF/classes.  People are going to
> >> want to see how its done and will need concrete examples.
> >
> > What's the use-case for the exploded WAR?
> >
> > I don't see any need in exploding the themes, they're already exploded to
> > standalone/configuration/themes.
> >
> 
> Whoops, forgot about that.
> 
> >>
> >> For example, one of the things I want to do with Federation plugins is
> >> that users can create their own management page for their plugin.  They
> >> will need to see examples/templates from the existing admin consoole.
> >
> > I don't think that's a very elegant way to "extend" the console. A much
> > better approach would be to then investigate UberFire or Hawt.
> >
> > My idea for managing providers was that we'd add a generic mechanism for
> > configuring. That would be much simpler to use for folks than having to
> > create (and maintain) their own additional pages in the admin console. I
> > thought we had agreed that we where doing that for 1.0.beta4?
> >
> 
> 1) Uberfire/Hawt isn't going to provide a mechanism to plug in a REST
> backend, are they?
> 2) I'd like LDAP to be treated as a plugin, not a special case, yet, I
> want a nice admin screen for it as it is a feature everybody wants.

After thinking about it some more I think it would be cool to have this available. When creating a plugin/provider you can either use:

* Simple configuration - This will provide a simple form which queries the provider for what keys to populate the form with. On the backend this will use a generic rest endpoint that lets you update a map with config for the provider, and is stored in the db.
* Advanced configuration - This will let you add your own REST backend and admin page as you suggested. Not sure how we'd deal with persistence of this data though.

We kinda need the advanced configuration any ways as we'd like built features to be enabled/disabled on the admin endpoints/console.

I'll write a separate mail about the ideas I had with provider configuration then we can carry on the discussion there.

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

From bburke at redhat.com  Mon Jul 21 09:42:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:42:41 -0400
Subject: [keycloak-dev] keep exploded war and add exploded themes
In-Reply-To: <1679396411.13974186.1405949971887.JavaMail.zimbra@redhat.com>
References: <53C99625.5020703@redhat.com>
	<1578613941.13746625.1405931741907.JavaMail.zimbra@redhat.com>
	<53CD15F3.4040609@redhat.com>
	<1679396411.13974186.1405949971887.JavaMail.zimbra@redhat.com>
Message-ID: <53CD18D1.4050508@redhat.com>



On 7/21/2014 9:39 AM, Stian Thorgersen wrote:
> * Advanced configuration - This will let you add your own REST backend and admin page as you suggested. Not sure how we'd deal with persistence of this data though.
>

FederationProviderModel (like AuthProviderModel) will have a property 
map.  For config, users will have to map their config onto the map. 
Another option is to provide storage for your Config class.

> We kinda need the advanced configuration any ways as we'd like built features to be enabled/disabled on the admin endpoints/console.
>
> I'll write a separate mail about the ideas I had with provider configuration then we can carry on the discussion there.
>

I'd like to be able to iterate with just a map 1st then move to a better 
configuration schema.  I'll need a few days to finish the 
AuthProvider->FedProvider refactor.

Bill

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

From bburke at redhat.com  Mon Jul 21 09:46:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 21 Jul 2014 09:46:35 -0400
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <53CCD096.3080107@redhat.com>
References: <53C9D267.5060702@redhat.com> <53CC2F0F.8010107@redhat.com>
	<53CCD096.3080107@redhat.com>
Message-ID: <53CD19BB.60100@redhat.com>

for getUsers/search, I can do a union of local storage and external 
storage.  For getUserCount I can't do this as I would have to iterate 
over every UserModel, which defeats the purpose of optimized, 1-query, 
getUserCount.

On 7/21/2014 4:34 AM, Marek Posolda wrote:
> I am not sure I understand why "getUserCount" is an issue and for
> example "getUsers" or "searchForUser" is not? Am I understand correctly
> that implementor of FederationProvider can choose which method to
> override, so for example if he won't override "getUsers" or
> "getUserCount" then FederationManager just delegates those to "local"
> UserProvider?
>
> If getUserCount() is an issue, I can remove it and refactor export to
> not using it and instead use approach like

It is not an issue as only export uses it.  Export will only be 
exporting local storage.

> : "checkout users until
> current page is not full", which would mean that there are no more users
> to export (Like for example if I have 50 users and usersPerPage is 20,
> then page1 has 20 users, page2 has 20 users and page3 has just 10 users,
> so export process can recognize that it is last page).
>
> But still getUserCount() may be useful if we later want to add
> pagination support to admin console (in this case, we may need "count"
> methods also for searchFor** -
> https://issues.jboss.org/browse/KEYCLOAK-564 )
>

Don't need a count, just if size() < maxRequested, you know you're at 
the end.

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

From mposolda at redhat.com  Mon Jul 21 10:49:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 21 Jul 2014 16:49:33 +0200
Subject: [keycloak-dev] AuthProvider refactor details
In-Reply-To: <53CD19BB.60100@redhat.com>
References: <53C9D267.5060702@redhat.com> <53CC2F0F.8010107@redhat.com>
	<53CCD096.3080107@redhat.com> <53CD19BB.60100@redhat.com>
Message-ID: <53CD287D.9000408@redhat.com>

On 21.7.2014 15:46, Bill Burke wrote:
> for getUsers/search, I can do a union of local storage and external 
> storage. 
hmm... I wonder about the case when you have data like this:
- User "john", which was synced from LDAP to local UserProvider and 
hence now is in both LDAP and local UserProvider
- User "local_foo" which was registered just locally in Keycloak and not 
available in LDAP
- User "ldap_foo" which was recently added directly to LDAP and not yet 
synced in Keycloak ldap UserProvider

So now when admin invokes UserProvider.getUsers() it should return him 3 
users like: "john", "local_foo", "ldap_foo"

But if I understand correctly, with union it returns 4 users like: 
"john", "john", "local_foo", "ldap_foo", because user "john" is in both. 
So how to handle this? Merge both "john" users just during this call? 
Does it scale when we have 10K users in LDAP and 10K users in local 
UserProvider (some shared, some just in either LDAP or local provider)? 
Personally I don't believe that federation will scale well here...
> For getUserCount I can't do this as I would have to iterate over every 
> UserModel, which defeats the purpose of optimized, 1-query, getUserCount.
>
> On 7/21/2014 4:34 AM, Marek Posolda wrote:
>> I am not sure I understand why "getUserCount" is an issue and for
>> example "getUsers" or "searchForUser" is not? Am I understand correctly
>> that implementor of FederationProvider can choose which method to
>> override, so for example if he won't override "getUsers" or
>> "getUserCount" then FederationManager just delegates those to "local"
>> UserProvider?
>>
>> If getUserCount() is an issue, I can remove it and refactor export to
>> not using it and instead use approach like
>
> It is not an issue as only export uses it.  Export will only be 
> exporting local storage.
>
>> : "checkout users until
>> current page is not full", which would mean that there are no more users
>> to export (Like for example if I have 50 users and usersPerPage is 20,
>> then page1 has 20 users, page2 has 20 users and page3 has just 10 users,
>> so export process can recognize that it is last page).
>>
>> But still getUserCount() may be useful if we later want to add
>> pagination support to admin console (in this case, we may need "count"
>> methods also for searchFor** -
>> https://issues.jboss.org/browse/KEYCLOAK-564 )
>>
>
> Don't need a count, just if size() < maxRequested, you know you're at 
> the end.
yeah, it's ok if we support just 3 buttons like "<<"  "<" ">" as it's 
now. If we want to add also ">>" I think we would need to add support 
for counting, so users have possibility to go directly to the last page.

Marek


From mposolda at redhat.com  Tue Jul 22 04:04:41 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Jul 2014 10:04:41 +0200
Subject: [keycloak-dev] more db schema changes
In-Reply-To: <53CD14A3.2070305@redhat.com>
References: <53C833E8.5050809@redhat.com>
	<53C94298.3020302@redhat.com>	<53C9453B.1050605@redhat.com>
	<53C94AB8.3010102@redhat.com>	<977473237.13735417.1405931299425.JavaMail.zimbra@redhat.com>
	<53CD14A3.2070305@redhat.com>
Message-ID: <53CE1B19.3020005@redhat.com>

I've sent PR https://github.com/keycloak/keycloak/pull/545 with the fix. 
In case of MySQL it was just missing transaction commit in 
AbstractKeycloakRule.getUser, which caused that some tables were locked 
and hence was not possible to remove constraint

I've added few other fixes also for PostgreSQL to work and I've added 
@Column, @JoinColumn and @Table annotations to all other places where it 
wasn't yet, so now we should have control on all the names of columns 
and tables.

So ATM PostgreSQL and MySQL work again, I am going to try other DBs.

Marek

On 21.7.2014 15:24, Bill Burke wrote:
> Sorry, I know why you changed it.  I just don't know why it breaks MySQL...
>
> On 7/21/2014 4:28 AM, Stian Thorgersen wrote:
>> I changed it as I couldn't get the composite ids to work. Did I break something?
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 18 July, 2014 5:26:32 PM
>>> Subject: Re: [keycloak-dev] more db schema changes
>>>
>>> Nevermind.  Stian changed it already.  Not sure why now...
>>>
>>> On 7/18/2014 12:03 PM, Bill Burke wrote:
>>>> Ugh.  Might be the double @ManyToOne hack I had to do for auth link.
>>>>
>>>> On 7/18/2014 11:51 AM, Marek Posolda wrote:
>>>>> Hi,
>>>>>
>>>>> just wanted to point that all recent DB changes seem to break databases
>>>>> (or at least MySQL). Actually when running testsuite with MySQL, then at
>>>>> the end of some tests during Hibernate schema cleanup, it hangs. Just
>>>>> figured out that it's this SQL command which causes hang of MySQL: alter
>>>>> table AUTHENTICATION_LINK drop foreign key FK582E5612EF007A6;
>>>>>
>>>>> Actually not sure if it's related to compound primary key of
>>>>> AuthenticationLinkEntity or foreign key with UserEntity... Will look at
>>>>> it more on Monday, just wanted to point that databases doesn't work ATM.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 17.7.2014 22:36, Bill Burke wrote:
>>>>>> * created @NamedQuery for every creatQuery we have
>>>>>> * Use @Column, @JoinColumn, and @JoinTable, and @Table everywhere.
>>>>>> names are uppercase with "_".  At least 10+ years ago, this was the
>>>>>> standard naming convention.
>>>>>> * CredentialEntity now has a generated String ID.  We will want to have
>>>>>> multiple TOTP entries in the future.
>>>>>>
>>>>>> 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  Tue Jul 22 05:17:50 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 05:17:50 -0400 (EDT)
Subject: [keycloak-dev] JPA issue on AS 7.1.1.Final
In-Reply-To: <1137370259.14844291.1406020136587.JavaMail.zimbra@redhat.com>
Message-ID: <1939308156.14853489.1406020670274.JavaMail.zimbra@redhat.com>

Currently master doesn't work on AS 7.1.1.Final (works on EAP 6.2/6.3 and WildFly).

The problem is that Weld tries to load the peristence-unit even though jboss.as.jpa.managed is set to false. Weld is processing the WAR as picketlink-idm-api-2.6.0.CR5.jar and picketlink-idm-simple-schema-2.6.0.CR5.jar include beans.xml. This problem was fixed in 7.1.2.Final (EAP 6.2).

On 7.1.1.Final there seems to be no way to prevent CDI from triggering as all mechanism was added later (exclude-subsystem in jboss-deployment-structure.xml or bean-discovery-mode="none" in beans.xml).

Potential solutions I've found are:

* Get rid of beans.xml in PicketLink jars
* Remove support for AS 7.1.1.Final (isn't this about time any ways?!)

From stian at redhat.com  Tue Jul 22 05:56:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 05:56:49 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <1353816154.14865042.1406021993892.JavaMail.zimbra@redhat.com>
Message-ID: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>

We need to add a generic provider config mechanism. It should be possible to configure providers at two levels:

* Server - through keycloak-server.json
* Realm  - through RealmProvider

With regards to server we already have this. It requires editing the keycloak-server.json and restarting the server. IMO that's fine for now, and we can consider adding support for doing this at runtime through the admin console in the future.

For realm config (which would be needed for ldap) I propose that we add a ProviderConfigModel to RealmProvider. The ProviderConfigModel consists of:

* RealmModel realm 
* String spi
* String provider
* Map<String, String> config

We need to add an admin endpoints to add/update provider configs as well as making it possible to edit these through the admin console. We should add a method to the provider factory:

* List<ConfigOption> getConfigOptions - this will return the configuration options the provider can support

ConfigOption will include (we could also add support for validation):

* String key
* String label

On the admin console I propose we add a Provider config page. The page will list out all available SPIs, once you select an SPI it will list out all available providers. You can then click on individual providers to get a form to edit the provider config. The form will use the getConfigOptions to know what labels/input fields to add.

Further, we need to make some changes to KeycloakSession/ProviderFactory to support realm config. We could change ProviderFactory.create(KeycloakSession session) to ProviderFactory.create(KeycloakSession session, String realmId, Config.Scope realmConfig). This allows a provider to either share resources (i.e. connections) with multiple realms, or if it wants different connections per-realm it can handle that internally (for example in a map using realmId as the key).

From bruno at abstractj.org  Tue Jul 22 07:29:31 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 22 Jul 2014 08:29:31 -0300
Subject: [keycloak-dev] Additional things to consider for 1.0.final
In-Reply-To: <851382424.12645781.1405674493572.JavaMail.zimbra@redhat.com>
References: <965438805.12003129.1405601755561.JavaMail.zimbra@redhat.com>
	<53C80AF5.1030603@redhat.com>
	<1098011932.12602826.1405671910380.JavaMail.zimbra@redhat.com>
	<53C8E2EA.90703@redhat.com>
	<851382424.12645781.1405674493572.JavaMail.zimbra@redhat.com>
Message-ID: <20140722112931.GB43037@abstractj.org>

Late for the discussion, but +1 about the SPI. What if the key on
keycloak-server was a public key for encryption? And the private key for
decryption stays on protected hard drive, TPM or whatever? Is that the
idea?

On 2014-07-18, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Friday, 18 July, 2014 10:03:38 AM
> > Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> >
> > On 18.7.2014 10:25, Stian Thorgersen wrote:
> > > Last we didn't do it because of the potential headache for admins to deal
> > > with it, especially in a cloud environment.
> > >
> > > I wonder if it would make sense to always encrypt in the database with a
> > > master key for the server. The master key could then be specified in
> > > keycloak-server.json. If users need the additional security they could
> > > make sure keycloak-server.json (as well as standalone.xml which has the
> > > ssl certificate keys) are stored on an encrypted drive. If not stored in
> > > keycloak-server.json the user would have to specify it when starting the
> > > server, which would have to be done by a prompt I think. Specifying it as
> > > an environment variable or system properties is not very safe as that can
> > > just as easily be read by an intruder as a file. This would make life a
> > > bit harder in a cluster though.
> > Not sure about prompt, but master key in keycloak-server.json should
> > work well and won't be a pain in cluster as long as all cluster nodes
> > have same value in keycloak-server.json? Only thing is that if we add
> > some default value into keycloak-server.json, then probably 99% of
> > people won't change it:-)
>
> We'd have to generate it on the first startup. I guess in a cluster people would have to sync keycloak-server.json between all nodes in either case.
>
> >
> > But it's better than nothing IMO as people at least have possibility to
> > change the master key if they want better security .
> >
> > Maybe best is to have SPI with encrypt/decrypt methods, which adds best
> > flexibility for people (default implementation will just encrypt/decrypt
> > with master key from keycloak-server.json)?
>
> Yep, we may even want to support hardware security modules, which would require some form of an SPI for encryption/decryption. IMO that's not for this round though.
>
> >
> > Marek
> > >
> > > ----- Original Message -----
> > >> From: "Marek Posolda" <mposolda at redhat.com>
> > >> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev"
> > >> <keycloak-dev at lists.jboss.org>
> > >> Sent: Thursday, 17 July, 2014 6:42:13 PM
> > >> Subject: Re: [keycloak-dev] Additional things to consider for 1.0.final
> > >>
> > >> One thing, which we discussed before was encoding of privateKey before
> > >> saving to DB? As currently if someone "steal" database record with
> > >> privateKey, he is able to create encoded accessTokens and send requests
> > >> to bearer-only applications.
> > >>
> > >> Or is this still planned for August?
> > >>
> > >> Marek
> > >>
> > >> On 17.7.2014 14:55, Stian Thorgersen wrote:
> > >>> As we didn't have enough things to do last minute I come up with more
> > >>> things which I think we should do for 1.0.final:
> > >>>
> > >>> 1. Configure JPA through keycloak-server.json instead of persistence.xml
> > >>>
> > >>> This would be super simple to do, and would let us have a single
> > >>> persistence.xml for everything (testsuite, server, project-integrations).
> > >>> Everything worthy of configuring in persistence.xml (including
> > >>> datasource)
> > >>> can be passed in the Map overrides when creating the
> > >>> EntityManagerFactory.
> > >>>
> > >>>
> > >>> 2. Introduce server-dependencies-min and server-dependencies-all poms
> > >>>
> > >>> We have a few places that includes all the dependencies required (server,
> > >>> testsuite/integration and testsuite/) as well as other project such as
> > >>> AeroGear and LiveOak. Instead of everyone having to list all the
> > >>> dependencies they could have a single dependency on either
> > >>> server-dependencies-min or server-dependencies-all. Min would exclude
> > >>> most
> > >>> if not all provider implementations (such as PicketLink/LDAP, social
> > >>> providers, etc).
> > >>>
> > >>>
> > >>> 3. TOTP SPI
> > >>>
> > >>> At the moment we only support Google Authenticator, I don't think that's
> > >>> sufficient. We should at the very least add support for one more, and
> > >>> have
> > >>> an SPI so users can add their own. I think this would be related to the
> > >>> UserProvider sync work, as some UserProvider implementations may require
> > >>> both a password and totp to verify a users credentials, while others
> > >>> would
> > >>> only be able to verify the password and then have Keycloak verify the
> > >>> totp.
> > >>>
> > >>> Also, do we need to support users with more than one totp? Personally I
> > >>> have two for work (one I use daily and another for backup).
> > >>> _______________________________________________
> > >>> 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
PGP: 0x84DC9914

From bburke at redhat.com  Tue Jul 22 09:04:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 09:04:56 -0400
Subject: [keycloak-dev] Provider config
In-Reply-To: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
Message-ID: <53CE6178.7050909@redhat.com>

Can you keep the KeycloakSesion/Provider SPIs backward compatible while 
you do this?

On 7/22/2014 5:56 AM, Stian Thorgersen wrote:
> We need to add a generic provider config mechanism. It should be possible to configure providers at two levels:
>
> * Server - through keycloak-server.json
> * Realm  - through RealmProvider
>
> With regards to server we already have this. It requires editing the keycloak-server.json and restarting the server. IMO that's fine for now, and we can consider adding support for doing this at runtime through the admin console in the future.
>
> For realm config (which would be needed for ldap) I propose that we add a ProviderConfigModel to RealmProvider. The ProviderConfigModel consists of:
>
> * RealmModel realm
> * String spi
> * String provider
> * Map<String, String> config
>
> We need to add an admin endpoints to add/update provider configs as well as making it possible to edit these through the admin console. We should add a method to the provider factory:
>
> * List<ConfigOption> getConfigOptions - this will return the configuration options the provider can support
>
> ConfigOption will include (we could also add support for validation):
>
> * String key
> * String label
>
> On the admin console I propose we add a Provider config page. The page will list out all available SPIs, once you select an SPI it will list out all available providers. You can then click on individual providers to get a form to edit the provider config. The form will use the getConfigOptions to know what labels/input fields to add.
>
> Further, we need to make some changes to KeycloakSession/ProviderFactory to support realm config. We could change ProviderFactory.create(KeycloakSession session) to ProviderFactory.create(KeycloakSession session, String realmId, Config.Scope realmConfig). This allows a provider to either share resources (i.e. connections) with multiple realms, or if it wants different connections per-realm it can handle that internally (for example in a map using realmId as the key).
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jul 22 09:08:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 09:08:20 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <53CE6178.7050909@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
Message-ID: <932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 2:04:56 PM
> Subject: Re: [keycloak-dev] Provider config
> 
> Can you keep the KeycloakSesion/Provider SPIs backward compatible while
> you do this?

Do we need to? If we do it'll need some more thinking ;)

> 
> On 7/22/2014 5:56 AM, Stian Thorgersen wrote:
> > We need to add a generic provider config mechanism. It should be possible
> > to configure providers at two levels:
> >
> > * Server - through keycloak-server.json
> > * Realm  - through RealmProvider
> >
> > With regards to server we already have this. It requires editing the
> > keycloak-server.json and restarting the server. IMO that's fine for now,
> > and we can consider adding support for doing this at runtime through the
> > admin console in the future.
> >
> > For realm config (which would be needed for ldap) I propose that we add a
> > ProviderConfigModel to RealmProvider. The ProviderConfigModel consists of:
> >
> > * RealmModel realm
> > * String spi
> > * String provider
> > * Map<String, String> config
> >
> > We need to add an admin endpoints to add/update provider configs as well as
> > making it possible to edit these through the admin console. We should add
> > a method to the provider factory:
> >
> > * List<ConfigOption> getConfigOptions - this will return the configuration
> > options the provider can support
> >
> > ConfigOption will include (we could also add support for validation):
> >
> > * String key
> > * String label
> >
> > On the admin console I propose we add a Provider config page. The page will
> > list out all available SPIs, once you select an SPI it will list out all
> > available providers. You can then click on individual providers to get a
> > form to edit the provider config. The form will use the getConfigOptions
> > to know what labels/input fields to add.
> >
> > Further, we need to make some changes to KeycloakSession/ProviderFactory to
> > support realm config. We could change
> > ProviderFactory.create(KeycloakSession session) to
> > ProviderFactory.create(KeycloakSession session, String realmId,
> > Config.Scope realmConfig). This allows a provider to either share
> > resources (i.e. connections) with multiple realms, or if it wants
> > different connections per-realm it can handle that internally (for example
> > in a map using realmId as the key).
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jul 22 09:16:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 09:16:48 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
Message-ID: <564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>

Maybe it'll make sense to have two types of providers? Server-scoped and realm-scoped.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 2:08:20 PM
> Subject: Re: [keycloak-dev] Provider config
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 22 July, 2014 2:04:56 PM
> > Subject: Re: [keycloak-dev] Provider config
> > 
> > Can you keep the KeycloakSesion/Provider SPIs backward compatible while
> > you do this?
> 
> Do we need to? If we do it'll need some more thinking ;)
> 
> > 
> > On 7/22/2014 5:56 AM, Stian Thorgersen wrote:
> > > We need to add a generic provider config mechanism. It should be possible
> > > to configure providers at two levels:
> > >
> > > * Server - through keycloak-server.json
> > > * Realm  - through RealmProvider
> > >
> > > With regards to server we already have this. It requires editing the
> > > keycloak-server.json and restarting the server. IMO that's fine for now,
> > > and we can consider adding support for doing this at runtime through the
> > > admin console in the future.
> > >
> > > For realm config (which would be needed for ldap) I propose that we add a
> > > ProviderConfigModel to RealmProvider. The ProviderConfigModel consists
> > > of:
> > >
> > > * RealmModel realm
> > > * String spi
> > > * String provider
> > > * Map<String, String> config
> > >
> > > We need to add an admin endpoints to add/update provider configs as well
> > > as
> > > making it possible to edit these through the admin console. We should add
> > > a method to the provider factory:
> > >
> > > * List<ConfigOption> getConfigOptions - this will return the
> > > configuration
> > > options the provider can support
> > >
> > > ConfigOption will include (we could also add support for validation):
> > >
> > > * String key
> > > * String label
> > >
> > > On the admin console I propose we add a Provider config page. The page
> > > will
> > > list out all available SPIs, once you select an SPI it will list out all
> > > available providers. You can then click on individual providers to get a
> > > form to edit the provider config. The form will use the getConfigOptions
> > > to know what labels/input fields to add.
> > >
> > > Further, we need to make some changes to KeycloakSession/ProviderFactory
> > > to
> > > support realm config. We could change
> > > ProviderFactory.create(KeycloakSession session) to
> > > ProviderFactory.create(KeycloakSession session, String realmId,
> > > Config.Scope realmConfig). This allows a provider to either share
> > > resources (i.e. connections) with multiple realms, or if it wants
> > > different connections per-realm it can handle that internally (for
> > > example
> > > in a map using realmId as the key).
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul 22 09:43:11 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 09:43:11 -0400
Subject: [keycloak-dev] Provider config
In-Reply-To: <564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
Message-ID: <53CE6A6F.3090204@redhat.com>

Certain providers may have multiple instances/configs of themselves in 
the same realm.  i.e. authentication providers (soon to be federation 
providers) which may be federating multiple different LDAP databases. 
Also, in the future, social may turn into a "federated broker SPI" where 
multiple generic federated broker providers can be configured per realm 
(i.e. SAML or other openid connections).

I honestly don't want a generic "provider" admin console page where you 
generically configure the providers.  I think it is a mistake.  We're 
supposed to be making things easier and we should be making tailored 
console pages for what we ship out of the box.


On 7/22/2014 9:16 AM, Stian Thorgersen wrote:
> Maybe it'll make sense to have two types of providers? Server-scoped and realm-scoped.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 22 July, 2014 2:08:20 PM
>> Subject: Re: [keycloak-dev] Provider config
>>
>>
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 22 July, 2014 2:04:56 PM
>>> Subject: Re: [keycloak-dev] Provider config
>>>
>>> Can you keep the KeycloakSesion/Provider SPIs backward compatible while
>>> you do this?
>>
>> Do we need to? If we do it'll need some more thinking ;)
>>
>>>
>>> On 7/22/2014 5:56 AM, Stian Thorgersen wrote:
>>>> We need to add a generic provider config mechanism. It should be possible
>>>> to configure providers at two levels:
>>>>
>>>> * Server - through keycloak-server.json
>>>> * Realm  - through RealmProvider
>>>>
>>>> With regards to server we already have this. It requires editing the
>>>> keycloak-server.json and restarting the server. IMO that's fine for now,
>>>> and we can consider adding support for doing this at runtime through the
>>>> admin console in the future.
>>>>
>>>> For realm config (which would be needed for ldap) I propose that we add a
>>>> ProviderConfigModel to RealmProvider. The ProviderConfigModel consists
>>>> of:
>>>>
>>>> * RealmModel realm
>>>> * String spi
>>>> * String provider
>>>> * Map<String, String> config
>>>>
>>>> We need to add an admin endpoints to add/update provider configs as well
>>>> as
>>>> making it possible to edit these through the admin console. We should add
>>>> a method to the provider factory:
>>>>
>>>> * List<ConfigOption> getConfigOptions - this will return the
>>>> configuration
>>>> options the provider can support
>>>>
>>>> ConfigOption will include (we could also add support for validation):
>>>>
>>>> * String key
>>>> * String label
>>>>
>>>> On the admin console I propose we add a Provider config page. The page
>>>> will
>>>> list out all available SPIs, once you select an SPI it will list out all
>>>> available providers. You can then click on individual providers to get a
>>>> form to edit the provider config. The form will use the getConfigOptions
>>>> to know what labels/input fields to add.
>>>>
>>>> Further, we need to make some changes to KeycloakSession/ProviderFactory
>>>> to
>>>> support realm config. We could change
>>>> ProviderFactory.create(KeycloakSession session) to
>>>> ProviderFactory.create(KeycloakSession session, String realmId,
>>>> Config.Scope realmConfig). This allows a provider to either share
>>>> resources (i.e. connections) with multiple realms, or if it wants
>>>> different connections per-realm it can handle that internally (for
>>>> example
>>>> in a map using realmId as the key).
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Tue Jul 22 09:53:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 09:53:14 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <53CE6A6F.3090204@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
	<53CE6A6F.3090204@redhat.com>
Message-ID: <775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 2:43:11 PM
> Subject: Re: [keycloak-dev] Provider config
> 
> Certain providers may have multiple instances/configs of themselves in
> the same realm.  i.e. authentication providers (soon to be federation
> providers) which may be federating multiple different LDAP databases.
> Also, in the future, social may turn into a "federated broker SPI" where
> multiple generic federated broker providers can be configured per realm
> (i.e. SAML or other openid connections).

Didn't consider that, we'll definitively need it

> 
> I honestly don't want a generic "provider" admin console page where you
> generically configure the providers.  I think it is a mistake.  We're
> supposed to be making things easier and we should be making tailored
> console pages for what we ship out of the box.

What about we allow configuring specific SPIs in the correct place, but still use a form that is populated with labels/inputs from the providers ConfigOptions?

> 
> 
> On 7/22/2014 9:16 AM, Stian Thorgersen wrote:
> > Maybe it'll make sense to have two types of providers? Server-scoped and
> > realm-scoped.
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 22 July, 2014 2:08:20 PM
> >> Subject: Re: [keycloak-dev] Provider config
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, 22 July, 2014 2:04:56 PM
> >>> Subject: Re: [keycloak-dev] Provider config
> >>>
> >>> Can you keep the KeycloakSesion/Provider SPIs backward compatible while
> >>> you do this?
> >>
> >> Do we need to? If we do it'll need some more thinking ;)
> >>
> >>>
> >>> On 7/22/2014 5:56 AM, Stian Thorgersen wrote:
> >>>> We need to add a generic provider config mechanism. It should be
> >>>> possible
> >>>> to configure providers at two levels:
> >>>>
> >>>> * Server - through keycloak-server.json
> >>>> * Realm  - through RealmProvider
> >>>>
> >>>> With regards to server we already have this. It requires editing the
> >>>> keycloak-server.json and restarting the server. IMO that's fine for now,
> >>>> and we can consider adding support for doing this at runtime through the
> >>>> admin console in the future.
> >>>>
> >>>> For realm config (which would be needed for ldap) I propose that we add
> >>>> a
> >>>> ProviderConfigModel to RealmProvider. The ProviderConfigModel consists
> >>>> of:
> >>>>
> >>>> * RealmModel realm
> >>>> * String spi
> >>>> * String provider
> >>>> * Map<String, String> config
> >>>>
> >>>> We need to add an admin endpoints to add/update provider configs as well
> >>>> as
> >>>> making it possible to edit these through the admin console. We should
> >>>> add
> >>>> a method to the provider factory:
> >>>>
> >>>> * List<ConfigOption> getConfigOptions - this will return the
> >>>> configuration
> >>>> options the provider can support
> >>>>
> >>>> ConfigOption will include (we could also add support for validation):
> >>>>
> >>>> * String key
> >>>> * String label
> >>>>
> >>>> On the admin console I propose we add a Provider config page. The page
> >>>> will
> >>>> list out all available SPIs, once you select an SPI it will list out all
> >>>> available providers. You can then click on individual providers to get a
> >>>> form to edit the provider config. The form will use the getConfigOptions
> >>>> to know what labels/input fields to add.
> >>>>
> >>>> Further, we need to make some changes to KeycloakSession/ProviderFactory
> >>>> to
> >>>> support realm config. We could change
> >>>> ProviderFactory.create(KeycloakSession session) to
> >>>> ProviderFactory.create(KeycloakSession session, String realmId,
> >>>> Config.Scope realmConfig). This allows a provider to either share
> >>>> resources (i.e. connections) with multiple realms, or if it wants
> >>>> different connections per-realm it can handle that internally (for
> >>>> example
> >>>> in a map using realmId as the key).
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bruno at abstractj.org  Tue Jul 22 10:58:04 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 22 Jul 2014 11:58:04 -0300
Subject: [keycloak-dev] Building Keycloak from scratch
Message-ID: <20140722145803.GH43037@abstractj.org>

Good morning guys, has anything changed about how to build KC? The build
complains about the lack of keycloak-parent with the latest change
https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
but everything goes well with the previous commit
https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea

Thanks in advance
--

abstractj

JBoss, a division of Red Hat

From stian at redhat.com  Tue Jul 22 11:11:01 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 11:11:01 -0400 (EDT)
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <20140722145803.GH43037@abstractj.org>
References: <20140722145803.GH43037@abstractj.org>
Message-ID: <481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>

Should still work, can you send me the error message?

I've added some two poms that include all dependencies required to create a server. For an example see:

https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 22 July, 2014 3:58:04 PM
> Subject: [keycloak-dev] Building Keycloak from scratch
> 
> Good morning guys, has anything changed about how to build KC? The build
> complains about the lack of keycloak-parent with the latest change
> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
> but everything goes well with the previous commit
> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
> 
> Thanks in advance
> --
> 
> abstractj
> 
> JBoss, a division of Red Hat
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From mposolda at redhat.com  Tue Jul 22 11:13:47 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Jul 2014 17:13:47 +0200
Subject: [keycloak-dev] JPA issue on AS 7.1.1.Final
In-Reply-To: <1939308156.14853489.1406020670274.JavaMail.zimbra@redhat.com>
References: <1939308156.14853489.1406020670274.JavaMail.zimbra@redhat.com>
Message-ID: <53CE7FAB.7020005@redhat.com>

Had a chat with Anil and Pedro about this. Seems to me that beans.xml 
are not needed inside api and simple-schema picketlink modules as those 
are not using cdi or weld stuff. Will propose them PR once I 
successfully run their integration tests with beans.xml removed.

Next PL version is planned to be released in August and among other 
things, it has also some Active Directory fixes, which I needed to 
workaround in keycloak code. Actually have a branch where I am testing 
AD with picketlink master and things look much cleaner in there. Do you 
think we will be able to update to latest picketlink 2.7. alpha version 
once it's released or do we need to stick with 2.6.5.Final ?

Marek

On 22.7.2014 11:17, Stian Thorgersen wrote:
> Currently master doesn't work on AS 7.1.1.Final (works on EAP 6.2/6.3 and WildFly).
>
> The problem is that Weld tries to load the peristence-unit even though jboss.as.jpa.managed is set to false. Weld is processing the WAR as picketlink-idm-api-2.6.0.CR5.jar and picketlink-idm-simple-schema-2.6.0.CR5.jar include beans.xml. This problem was fixed in 7.1.2.Final (EAP 6.2).
>
> On 7.1.1.Final there seems to be no way to prevent CDI from triggering as all mechanism was added later (exclude-subsystem in jboss-deployment-structure.xml or bean-discovery-mode="none" in beans.xml).
>
> Potential solutions I've found are:
>
> * Get rid of beans.xml in PicketLink jars
> * Remove support for AS 7.1.1.Final (isn't this about time any ways?!)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Tue Jul 22 11:14:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 11:14:02 -0400
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
Message-ID: <53CE7FBA.40001@redhat.com>

The poms in authentication don't have valid relative paths.  That could 
be it.

On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
> Should still work, can you send me the error message?
>
> I've added some two poms that include all dependencies required to create a server. For an example see:
>
> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
>
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
>> Subject: [keycloak-dev] Building Keycloak from scratch
>>
>> Good morning guys, has anything changed about how to build KC? The build
>> complains about the lack of keycloak-parent with the latest change
>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
>> but everything goes well with the previous commit
>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
>>
>> Thanks in advance
>> --
>>
>> abstractj
>>
>> JBoss, a division of Red Hat
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Tue Jul 22 11:22:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 11:22:44 -0400 (EDT)
Subject: [keycloak-dev] JPA issue on AS 7.1.1.Final
In-Reply-To: <53CE7FAB.7020005@redhat.com>
References: <1939308156.14853489.1406020670274.JavaMail.zimbra@redhat.com>
	<53CE7FAB.7020005@redhat.com>
Message-ID: <1067179031.15288817.1406042564008.JavaMail.zimbra@redhat.com>

Awesome, thanks Marek.

I don't see any reason we should stick with 2.6.5.Final, especially as there's fixes for AD in 2.7. It would also solve the issue I'm having which would be great. It looks like they'll release a 2.7.Final before us, so that shouldn't be a problem either.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, 22 July, 2014 4:13:47 PM
> Subject: Re: [keycloak-dev] JPA issue on AS 7.1.1.Final
> 
> Had a chat with Anil and Pedro about this. Seems to me that beans.xml
> are not needed inside api and simple-schema picketlink modules as those
> are not using cdi or weld stuff. Will propose them PR once I
> successfully run their integration tests with beans.xml removed.
> 
> Next PL version is planned to be released in August and among other
> things, it has also some Active Directory fixes, which I needed to
> workaround in keycloak code. Actually have a branch where I am testing
> AD with picketlink master and things look much cleaner in there. Do you
> think we will be able to update to latest picketlink 2.7. alpha version
> once it's released or do we need to stick with 2.6.5.Final ?
> 
> Marek
> 
> On 22.7.2014 11:17, Stian Thorgersen wrote:
> > Currently master doesn't work on AS 7.1.1.Final (works on EAP 6.2/6.3 and
> > WildFly).
> >
> > The problem is that Weld tries to load the peristence-unit even though
> > jboss.as.jpa.managed is set to false. Weld is processing the WAR as
> > picketlink-idm-api-2.6.0.CR5.jar and
> > picketlink-idm-simple-schema-2.6.0.CR5.jar include beans.xml. This problem
> > was fixed in 7.1.2.Final (EAP 6.2).
> >
> > On 7.1.1.Final there seems to be no way to prevent CDI from triggering as
> > all mechanism was added later (exclude-subsystem in
> > jboss-deployment-structure.xml or bean-discovery-mode="none" in
> > beans.xml).
> >
> > Potential solutions I've found are:
> >
> > * Get rid of beans.xml in PicketLink jars
> > * Remove support for AS 7.1.1.Final (isn't this about time any ways?!)
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From mposolda at redhat.com  Tue Jul 22 11:29:03 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Jul 2014 17:29:03 +0200
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <53CE7FBA.40001@redhat.com>
References: <20140722145803.GH43037@abstractj.org>	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com>
Message-ID: <53CE833F.1090905@redhat.com>

hmm... which one? Actually for example 
https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7 
has parent keycloak-authentication-parent, which is really in ../pom.xml 
. AFAIK it should be good practice to reference parent in one upper 
module ? Or are there some issues with it?

For example modules inside "model" references keycloak-parent which is 
under "../../pom.xml" so it works too. I wonder that maybe we should 
unify that (either all modules to use 1 level upper parent with 
relativePath like ../pom.xml or all modules to use keycloak-parent)

Marek

On 22.7.2014 17:14, Bill Burke wrote:
> The poms in authentication don't have valid relative paths.  That could
> be it.
>
> On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
>> Should still work, can you send me the error message?
>>
>> I've added some two poms that include all dependencies required to create a server. For an example see:
>>
>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
>>
>> ----- Original Message -----
>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
>>> Subject: [keycloak-dev] Building Keycloak from scratch
>>>
>>> Good morning guys, has anything changed about how to build KC? The build
>>> complains about the lack of keycloak-parent with the latest change
>>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
>>> but everything goes well with the previous commit
>>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
>>>
>>> Thanks in advance
>>> --
>>>
>>> abstractj
>>>
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From stian at redhat.com  Tue Jul 22 11:36:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 11:36:02 -0400 (EDT)
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <53CE833F.1090905@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
Message-ID: <1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>

As usual it's my fault, fix coming

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 4:29:03 PM
> Subject: Re: [keycloak-dev] Building Keycloak from scratch
> 
> hmm... which one? Actually for example
> https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
> has parent keycloak-authentication-parent, which is really in ../pom.xml
> . AFAIK it should be good practice to reference parent in one upper
> module ? Or are there some issues with it?
> 
> For example modules inside "model" references keycloak-parent which is
> under "../../pom.xml" so it works too. I wonder that maybe we should
> unify that (either all modules to use 1 level upper parent with
> relativePath like ../pom.xml or all modules to use keycloak-parent)
> 
> Marek
> 
> On 22.7.2014 17:14, Bill Burke wrote:
> > The poms in authentication don't have valid relative paths.  That could
> > be it.
> >
> > On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
> >> Should still work, can you send me the error message?
> >>
> >> I've added some two poms that include all dependencies required to create
> >> a server. For an example see:
> >>
> >> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
> >>
> >> ----- Original Message -----
> >>> From: "Bruno Oliveira" <bruno at abstractj.org>
> >>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
> >>> Subject: [keycloak-dev] Building Keycloak from scratch
> >>>
> >>> Good morning guys, has anything changed about how to build KC? The build
> >>> complains about the lack of keycloak-parent with the latest change
> >>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
> >>> but everything goes well with the previous commit
> >>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
> >>>
> >>> Thanks in advance
> >>> --
> >>>
> >>> abstractj
> >>>
> >>> JBoss, a division of Red Hat
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jul 22 11:57:02 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 11:57:02 -0400 (EDT)
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
	<1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
Message-ID: <1023374796.15386092.1406044622259.JavaMail.zimbra@redhat.com>

Fixed

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 4:36:02 PM
> Subject: Re: [keycloak-dev] Building Keycloak from scratch
> 
> As usual it's my fault, fix coming
> 
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 22 July, 2014 4:29:03 PM
> > Subject: Re: [keycloak-dev] Building Keycloak from scratch
> > 
> > hmm... which one? Actually for example
> > https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
> > has parent keycloak-authentication-parent, which is really in ../pom.xml
> > . AFAIK it should be good practice to reference parent in one upper
> > module ? Or are there some issues with it?
> > 
> > For example modules inside "model" references keycloak-parent which is
> > under "../../pom.xml" so it works too. I wonder that maybe we should
> > unify that (either all modules to use 1 level upper parent with
> > relativePath like ../pom.xml or all modules to use keycloak-parent)
> > 
> > Marek
> > 
> > On 22.7.2014 17:14, Bill Burke wrote:
> > > The poms in authentication don't have valid relative paths.  That could
> > > be it.
> > >
> > > On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
> > >> Should still work, can you send me the error message?
> > >>
> > >> I've added some two poms that include all dependencies required to
> > >> create
> > >> a server. For an example see:
> > >>
> > >> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
> > >>
> > >> ----- Original Message -----
> > >>> From: "Bruno Oliveira" <bruno at abstractj.org>
> > >>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
> > >>> Subject: [keycloak-dev] Building Keycloak from scratch
> > >>>
> > >>> Good morning guys, has anything changed about how to build KC? The
> > >>> build
> > >>> complains about the lack of keycloak-parent with the latest change
> > >>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
> > >>> but everything goes well with the previous commit
> > >>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
> > >>>
> > >>> Thanks in advance
> > >>> --
> > >>>
> > >>> abstractj
> > >>>
> > >>> JBoss, a division of Red Hat
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul 22 11:57:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 11:57:37 -0400
Subject: [keycloak-dev] Provider config
In-Reply-To: <775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
	<53CE6A6F.3090204@redhat.com>
	<775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>
Message-ID: <53CE89F1.6020609@redhat.com>



On 7/22/2014 9:53 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 22 July, 2014 2:43:11 PM
>> Subject: Re: [keycloak-dev] Provider config
>>
>> Certain providers may have multiple instances/configs of themselves in
>> the same realm.  i.e. authentication providers (soon to be federation
>> providers) which may be federating multiple different LDAP databases.
>> Also, in the future, social may turn into a "federated broker SPI" where
>> multiple generic federated broker providers can be configured per realm
>> (i.e. SAML or other openid connections).
>
> Didn't consider that, we'll definitively need it
>

In my private fork, I pulled getProviderFactory methods from 
DefaultKeycloakSessionFactory up to KeycloakSessionFactory methods. 
Then defined my own specialized create methods.  I don't use 
KeycloakSession.getProvider() anymore.


>>
>> I honestly don't want a generic "provider" admin console page where you
>> generically configure the providers.  I think it is a mistake.  We're
>> supposed to be making things easier and we should be making tailored
>> console pages for what we ship out of the box.
>
> What about we allow configuring specific SPIs in the correct place, but still use a form that is populated with labels/inputs from the providers ConfigOptions?
>

LDAP config already doesn't fit into pure labels/inputs.  IMO, rendering 
information belongs in HTML :)


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

From bburke at redhat.com  Tue Jul 22 11:59:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 11:59:00 -0400
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
	<1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
Message-ID: <53CE8A44.2000204@redhat.com>

Maybe we should have integrated CI with github like Wildfly does?  We're 
all busy though.

On 7/22/2014 11:36 AM, Stian Thorgersen wrote:
> As usual it's my fault, fix coming
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 22 July, 2014 4:29:03 PM
>> Subject: Re: [keycloak-dev] Building Keycloak from scratch
>>
>> hmm... which one? Actually for example
>> https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
>> has parent keycloak-authentication-parent, which is really in ../pom.xml
>> . AFAIK it should be good practice to reference parent in one upper
>> module ? Or are there some issues with it?
>>
>> For example modules inside "model" references keycloak-parent which is
>> under "../../pom.xml" so it works too. I wonder that maybe we should
>> unify that (either all modules to use 1 level upper parent with
>> relativePath like ../pom.xml or all modules to use keycloak-parent)
>>
>> Marek
>>
>> On 22.7.2014 17:14, Bill Burke wrote:
>>> The poms in authentication don't have valid relative paths.  That could
>>> be it.
>>>
>>> On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
>>>> Should still work, can you send me the error message?
>>>>
>>>> I've added some two poms that include all dependencies required to create
>>>> a server. For an example see:
>>>>
>>>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
>>>>> Subject: [keycloak-dev] Building Keycloak from scratch
>>>>>
>>>>> Good morning guys, has anything changed about how to build KC? The build
>>>>> complains about the lack of keycloak-parent with the latest change
>>>>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
>>>>> but everything goes well with the previous commit
>>>>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
>>>>>
>>>>> Thanks in advance
>>>>> --
>>>>>
>>>>> abstractj
>>>>>
>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>> _______________________________________________
>> 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 Jul 22 12:01:00 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 22 Jul 2014 13:01:00 -0300
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
	<1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
Message-ID: <20140722160100.GB58163@abstractj.org>

Thanks Stian, you rock.

On 2014-07-22, Stian Thorgersen wrote:
> As usual it's my fault, fix coming
>
> ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 22 July, 2014 4:29:03 PM
> > Subject: Re: [keycloak-dev] Building Keycloak from scratch
> >
> > hmm... which one? Actually for example
> > https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
> > has parent keycloak-authentication-parent, which is really in ../pom.xml
> > . AFAIK it should be good practice to reference parent in one upper
> > module ? Or are there some issues with it?
> >
> > For example modules inside "model" references keycloak-parent which is
> > under "../../pom.xml" so it works too. I wonder that maybe we should
> > unify that (either all modules to use 1 level upper parent with
> > relativePath like ../pom.xml or all modules to use keycloak-parent)
> >
> > Marek
> >
> > On 22.7.2014 17:14, Bill Burke wrote:
> > > The poms in authentication don't have valid relative paths.  That could
> > > be it.
> > >
> > > On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
> > >> Should still work, can you send me the error message?
> > >>
> > >> I've added some two poms that include all dependencies required to create
> > >> a server. For an example see:
> > >>
> > >> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
> > >>
> > >> ----- Original Message -----
> > >>> From: "Bruno Oliveira" <bruno at abstractj.org>
> > >>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > >>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
> > >>> Subject: [keycloak-dev] Building Keycloak from scratch
> > >>>
> > >>> Good morning guys, has anything changed about how to build KC? The build
> > >>> complains about the lack of keycloak-parent with the latest change
> > >>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
> > >>> but everything goes well with the previous commit
> > >>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
> > >>>
> > >>> Thanks in advance
> > >>> --
> > >>>
> > >>> abstractj
> > >>>
> > >>> JBoss, a division of Red Hat
> > >>> _______________________________________________
> > >>> keycloak-dev mailing list
> > >>> keycloak-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>>
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >>
> >
> > _______________________________________________
> > 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
PGP: 0x84DC9914

From stian at redhat.com  Tue Jul 22 12:10:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 12:10:35 -0400 (EDT)
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <53CE8A44.2000204@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
	<1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
	<53CE8A44.2000204@redhat.com>
Message-ID: <153763102.15398050.1406045435346.JavaMail.zimbra@redhat.com>

We have CI, not integrated, and it takes forever for scheduled jobs to run :/

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 4:59:00 PM
> Subject: Re: [keycloak-dev] Building Keycloak from scratch
> 
> Maybe we should have integrated CI with github like Wildfly does?  We're
> all busy though.
> 
> On 7/22/2014 11:36 AM, Stian Thorgersen wrote:
> > As usual it's my fault, fix coming
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 22 July, 2014 4:29:03 PM
> >> Subject: Re: [keycloak-dev] Building Keycloak from scratch
> >>
> >> hmm... which one? Actually for example
> >> https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
> >> has parent keycloak-authentication-parent, which is really in ../pom.xml
> >> . AFAIK it should be good practice to reference parent in one upper
> >> module ? Or are there some issues with it?
> >>
> >> For example modules inside "model" references keycloak-parent which is
> >> under "../../pom.xml" so it works too. I wonder that maybe we should
> >> unify that (either all modules to use 1 level upper parent with
> >> relativePath like ../pom.xml or all modules to use keycloak-parent)
> >>
> >> Marek
> >>
> >> On 22.7.2014 17:14, Bill Burke wrote:
> >>> The poms in authentication don't have valid relative paths.  That could
> >>> be it.
> >>>
> >>> On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
> >>>> Should still work, can you send me the error message?
> >>>>
> >>>> I've added some two poms that include all dependencies required to
> >>>> create
> >>>> a server. For an example see:
> >>>>
> >>>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
> >>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
> >>>>> Subject: [keycloak-dev] Building Keycloak from scratch
> >>>>>
> >>>>> Good morning guys, has anything changed about how to build KC? The
> >>>>> build
> >>>>> complains about the lack of keycloak-parent with the latest change
> >>>>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
> >>>>> but everything goes well with the previous commit
> >>>>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
> >>>>>
> >>>>> Thanks in advance
> >>>>> --
> >>>>>
> >>>>> abstractj
> >>>>>
> >>>>> JBoss, a division of Red Hat
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>>
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue Jul 22 12:19:27 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 22 Jul 2014 12:19:27 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <53CE89F1.6020609@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
	<53CE6A6F.3090204@redhat.com>
	<775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>
	<53CE89F1.6020609@redhat.com>
Message-ID: <1337760787.15416633.1406045967429.JavaMail.zimbra@redhat.com>

Sounds like you've thought about this more than me, so I'll leave it with you to sort out ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 4:57:37 PM
> Subject: Re: [keycloak-dev] Provider config
> 
> 
> 
> On 7/22/2014 9:53 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 22 July, 2014 2:43:11 PM
> >> Subject: Re: [keycloak-dev] Provider config
> >>
> >> Certain providers may have multiple instances/configs of themselves in
> >> the same realm.  i.e. authentication providers (soon to be federation
> >> providers) which may be federating multiple different LDAP databases.
> >> Also, in the future, social may turn into a "federated broker SPI" where
> >> multiple generic federated broker providers can be configured per realm
> >> (i.e. SAML or other openid connections).
> >
> > Didn't consider that, we'll definitively need it
> >
> 
> In my private fork, I pulled getProviderFactory methods from
> DefaultKeycloakSessionFactory up to KeycloakSessionFactory methods.
> Then defined my own specialized create methods.  I don't use
> KeycloakSession.getProvider() anymore.
> 
> 
> >>
> >> I honestly don't want a generic "provider" admin console page where you
> >> generically configure the providers.  I think it is a mistake.  We're
> >> supposed to be making things easier and we should be making tailored
> >> console pages for what we ship out of the box.
> >
> > What about we allow configuring specific SPIs in the correct place, but
> > still use a form that is populated with labels/inputs from the providers
> > ConfigOptions?
> >
> 
> LDAP config already doesn't fit into pure labels/inputs.  IMO, rendering
> information belongs in HTML :)
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Tue Jul 22 14:29:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 22 Jul 2014 20:29:45 +0200
Subject: [keycloak-dev] Building Keycloak from scratch
In-Reply-To: <153763102.15398050.1406045435346.JavaMail.zimbra@redhat.com>
References: <20140722145803.GH43037@abstractj.org>
	<481604150.15252642.1406041861309.JavaMail.zimbra@redhat.com>
	<53CE7FBA.40001@redhat.com> <53CE833F.1090905@redhat.com>
	<1479992428.15326201.1406043362442.JavaMail.zimbra@redhat.com>
	<53CE8A44.2000204@redhat.com>
	<153763102.15398050.1406045435346.JavaMail.zimbra@redhat.com>
Message-ID: <53CEAD99.1020506@redhat.com>

I've changed the settings from "Poll changes periodically" to "Build 
when a change is pushed to GitHub" . Hopefully push approach would work 
and builds will be triggered directly after github change.

Marek

On 22.7.2014 18:10, Stian Thorgersen wrote:
> We have CI, not integrated, and it takes forever for scheduled jobs to run :/
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 22 July, 2014 4:59:00 PM
>> Subject: Re: [keycloak-dev] Building Keycloak from scratch
>>
>> Maybe we should have integrated CI with github like Wildfly does?  We're
>> all busy though.
>>
>> On 7/22/2014 11:36 AM, Stian Thorgersen wrote:
>>> As usual it's my fault, fix coming
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 22 July, 2014 4:29:03 PM
>>>> Subject: Re: [keycloak-dev] Building Keycloak from scratch
>>>>
>>>> hmm... which one? Actually for example
>>>> https://github.com/keycloak/keycloak/blob/master/authentication/authentication-api/pom.xml#L7
>>>> has parent keycloak-authentication-parent, which is really in ../pom.xml
>>>> . AFAIK it should be good practice to reference parent in one upper
>>>> module ? Or are there some issues with it?
>>>>
>>>> For example modules inside "model" references keycloak-parent which is
>>>> under "../../pom.xml" so it works too. I wonder that maybe we should
>>>> unify that (either all modules to use 1 level upper parent with
>>>> relativePath like ../pom.xml or all modules to use keycloak-parent)
>>>>
>>>> Marek
>>>>
>>>> On 22.7.2014 17:14, Bill Burke wrote:
>>>>> The poms in authentication don't have valid relative paths.  That could
>>>>> be it.
>>>>>
>>>>> On 7/22/2014 11:11 AM, Stian Thorgersen wrote:
>>>>>> Should still work, can you send me the error message?
>>>>>>
>>>>>> I've added some two poms that include all dependencies required to
>>>>>> create
>>>>>> a server. For an example see:
>>>>>>
>>>>>> https://github.com/keycloak/keycloak/blob/master/project-integrations/aerogear-ups/auth-server/pom.xml
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Tuesday, 22 July, 2014 3:58:04 PM
>>>>>>> Subject: [keycloak-dev] Building Keycloak from scratch
>>>>>>>
>>>>>>> Good morning guys, has anything changed about how to build KC? The
>>>>>>> build
>>>>>>> complains about the lack of keycloak-parent with the latest change
>>>>>>> https://github.com/keycloak/keycloak/commit/64b8a990f9d5614db9559dc56a626d67c95cd5e4,
>>>>>>> but everything goes well with the previous commit
>>>>>>> https://github.com/keycloak/keycloak/commit/824aed773b2fd80f9819a3d42879a92b751e9eea
>>>>>>>
>>>>>>> Thanks in advance
>>>>>>> --
>>>>>>>
>>>>>>> abstractj
>>>>>>>
>>>>>>> JBoss, a division of Red Hat
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>


From bburke at redhat.com  Tue Jul 22 15:49:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 15:49:02 -0400
Subject: [keycloak-dev] Provider config
In-Reply-To: <1337760787.15416633.1406045967429.JavaMail.zimbra@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<53CE6178.7050909@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
	<53CE6A6F.3090204@redhat.com>
	<775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>
	<53CE89F1.6020609@redhat.com>
	<1337760787.15416633.1406045967429.JavaMail.zimbra@redhat.com>
Message-ID: <53CEC02E.1020107@redhat.com>

That's doesn't necessarily my thoughts are any good though.  I'll 
iterate you can reiterate I guess...

On 7/22/2014 12:19 PM, Stian Thorgersen wrote:
> Sounds like you've thought about this more than me, so I'll leave it with you to sort out ;)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 22 July, 2014 4:57:37 PM
>> Subject: Re: [keycloak-dev] Provider config
>>
>>
>>
>> On 7/22/2014 9:53 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 22 July, 2014 2:43:11 PM
>>>> Subject: Re: [keycloak-dev] Provider config
>>>>
>>>> Certain providers may have multiple instances/configs of themselves in
>>>> the same realm.  i.e. authentication providers (soon to be federation
>>>> providers) which may be federating multiple different LDAP databases.
>>>> Also, in the future, social may turn into a "federated broker SPI" where
>>>> multiple generic federated broker providers can be configured per realm
>>>> (i.e. SAML or other openid connections).
>>>
>>> Didn't consider that, we'll definitively need it
>>>
>>
>> In my private fork, I pulled getProviderFactory methods from
>> DefaultKeycloakSessionFactory up to KeycloakSessionFactory methods.
>> Then defined my own specialized create methods.  I don't use
>> KeycloakSession.getProvider() anymore.
>>
>>
>>>>
>>>> I honestly don't want a generic "provider" admin console page where you
>>>> generically configure the providers.  I think it is a mistake.  We're
>>>> supposed to be making things easier and we should be making tailored
>>>> console pages for what we ship out of the box.
>>>
>>> What about we allow configuring specific SPIs in the correct place, but
>>> still use a form that is populated with labels/inputs from the providers
>>> ConfigOptions?
>>>
>>
>> LDAP config already doesn't fit into pure labels/inputs.  IMO, rendering
>> information belongs in HTML :)
>>
>>
>> --
>> 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  Tue Jul 22 18:02:36 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 22 Jul 2014 18:02:36 -0400
Subject: [keycloak-dev] social tokens?
Message-ID: <53CEDF7C.4070104@redhat.com>

Kabir (works at redhat) wanted to use keycloak to log in through github, 
but get a token that can be used to invoke on github too.  We don't have 
a way to do this do we?

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

From psilva at redhat.com  Tue Jul 22 22:27:33 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 22 Jul 2014 22:27:33 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <1296772151.11925888.1406081558696.JavaMail.zimbra@redhat.com>
Message-ID: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>

Hi All,

   Currently, I'm working in a new identity store to handle tokens issued by a specific IdP. KeyCloak is one of them.

   So far, I'm trying to provide an easy way to integrate KC with PL. But it will also be useful for SAML-based apps.

   My first use case is simple. A REST application provides endpoints protected by roles. The client application authenticates using an IdP (eg.: KC) and invoke the REST endpoints by sending the token on every single request. The application then validates, extract user information from the token and creates a security context for a specific request.

   This identity store will operate in two modes:

       1) Stateless. Useful for applications acting only as a Service Provider. In this case, the app only wants to join a SSO session and use all information provided by a token to perform in-house authorization such as RBAC. Tokens are not persisted and are usually short-lived.

       2) Stateful. Useful for applications that want to use a specific token to invoke 3rd party APIs. In this case, the app wants to login using a social provider (eg.: facebook, github or even KC) and store the token and user information locally for later use. Once stored, the app can retrieve the token and use it to invoke an external API.

   What I did so far is related with #1 and the functionality is covering:

       - Usage of keycloak.js to redirect users to login page and renew tokens.
       - Send KC token in every single request to a specific PL filter that knows how to process tokens.
       - Validate the token and create a security context for an user. Considering KC, the validation involves the expiration time, signature, audience, issuer, etc.
       - Extract from the token identity information such as username, roles, realm, etc.
       - Support authorization checks based on the information extracted from a token.

   I still have some gaps to fill, but I would like to know what are your thoughts about how PL and KC can work together. AFAIK, KeyCloak is more about authentication. If the application wants authorization based on the information from a token (eg.: roles) it must do it by itself. Or you guys already have code for that ?

Thanks.
Pedro Igor

From bburke at redhat.com  Wed Jul 23 00:04:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 00:04:31 -0400
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
Message-ID: <53CF344F.5050902@redhat.com>

Keycloak is about authentication *and* authorization.  We currently have 
deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC 
for Servlet apps out of the box.  You can even take an existing WAR, 
without cracking it open, using the Keycloak JBoss/Wildfly Subsystem. 
We have plans for additional adapters post 1.0.Final for Node.js, JIRA, 
Tomcat, and Jetty.

We have both a stateless mode (bearer-only)as well as a stateful mode as 
well (HTTP Sessions).  We have revocation policies.  We have user 
session management.  Single Log Out, etc.  I urge you to try our demos, 
read our docs, and view our screencasts.  We do TONS OF SHIT :)

Right now, everything is OAuth2/OpenID Connect based with a small 
extension to JWT for role mappings.  Starting in September, I'll be 
adding SAML support in addition to OAuth/OpenID Connect.  I hope to 
incorporate much of the SAML modules in Picketlink IDP.  This will 
require a lot of refactoring in Keycloak to pull out all the 
non-protocol specific logic like UI rendering, browser authentication, 
and user management workflows (forgot password, totp setup, 
registration, etc.).  It will probably require refactoring of Picketlink 
as well.

For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our 
Social Provider SPI into a full fledged generic Broker SPI, of which I'd 
like a SAML plugin which could make use of any SAML client modules 
Picketlink has.

We're also missing integration with CDI and other component layers and a 
better application API for injecting and obtaining security metadata.

Other areas Anil and I talked about are pulling out our Social Provider 
code into do-it-yourself APIs.  Really improving and expanding 
Picketlink Social.  I haven't looked at Picketlink Social, but I think 
Keycloak may be much more comprehensive.

Honesty, there is just so much shit to do.  Tons of it.  A lot of 
interesting (and not so interesting) work to go around.  I'd be happy to 
talk to you about it sometime soon.

On 7/22/2014 10:27 PM, Pedro Igor Silva wrote:
> Hi All,
>
>     Currently, I'm working in a new identity store to handle tokens issued by a specific IdP. KeyCloak is one of them.
>
>     So far, I'm trying to provide an easy way to integrate KC with PL. But it will also be useful for SAML-based apps.
>
>     My first use case is simple. A REST application provides endpoints protected by roles. The client application authenticates using an IdP (eg.: KC) and invoke the REST endpoints by sending the token on every single request. The application then validates, extract user information from the token and creates a security context for a specific request.
>
>     This identity store will operate in two modes:
>
>         1) Stateless. Useful for applications acting only as a Service Provider. In this case, the app only wants to join a SSO session and use all information provided by a token to perform in-house authorization such as RBAC. Tokens are not persisted and are usually short-lived.
>
>         2) Stateful. Useful for applications that want to use a specific token to invoke 3rd party APIs. In this case, the app wants to login using a social provider (eg.: facebook, github or even KC) and store the token and user information locally for later use. Once stored, the app can retrieve the token and use it to invoke an external API.
>
>     What I did so far is related with #1 and the functionality is covering:
>
>         - Usage of keycloak.js to redirect users to login page and renew tokens.
>         - Send KC token in every single request to a specific PL filter that knows how to process tokens.
>         - Validate the token and create a security context for an user. Considering KC, the validation involves the expiration time, signature, audience, issuer, etc.
>         - Extract from the token identity information such as username, roles, realm, etc.
>         - Support authorization checks based on the information extracted from a token.
>
>     I still have some gaps to fill, but I would like to know what are your thoughts about how PL and KC can work together. AFAIK, KeyCloak is more about authentication. If the application wants authorization based on the information from a token (eg.: roles) it must do it by itself. Or you guys already have code for that ?
>
> Thanks.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Wed Jul 23 03:31:53 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 23 Jul 2014 03:31:53 -0400 (EDT)
Subject: [keycloak-dev] social tokens?
In-Reply-To: <53CEDF7C.4070104@redhat.com>
References: <53CEDF7C.4070104@redhat.com>
Message-ID: <1826630201.16092447.1406100713072.JavaMail.zimbra@redhat.com>

Not at the moment, it's something we'll need to do at some point. When configuring social providers it should also be possible to configure the requested scope, as well as retrieve the token from Keycloak afterwards. Maybe we could add it to the IDToken with a special claim for it?

It'll need a few changes though, so maybe not something we can achieve for 1.0:

* Configuration of scope
* A mechanism to send token to client - IDToken? with a claim?
* Probably also need to persist the token with the user session or something

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 11:02:36 PM
> Subject: [keycloak-dev] social tokens?
> 
> Kabir (works at redhat) wanted to use keycloak to log in through github,
> but get a token that can be used to invoke on github too.  We don't have
> a way to do this do we?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 23 05:06:00 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 23 Jul 2014 05:06:00 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
Message-ID: <911582521.16140632.1406106360529.JavaMail.zimbra@redhat.com>

As JavaEE security is lacking at best it would be nice to see integration with PL to use PL CDI and permissions. 

I haven't looked at PL for a while, so I'm not 100% up to date with how it all works now. However, this doesn't seem like the correct approach to me. As Bill pointed out our as7/undertow adapters already do this stuff. IMO an application should be secured using the KC adapters, then use PL CDI/permissions when JavaEE security mechanisms are not enough.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 3:27:33 AM
> Subject: [keycloak-dev] PicketLink and KC Integration
> 
> Hi All,
> 
>    Currently, I'm working in a new identity store to handle tokens issued by
>    a specific IdP. KeyCloak is one of them.
> 
>    So far, I'm trying to provide an easy way to integrate KC with PL. But it
>    will also be useful for SAML-based apps.
> 
>    My first use case is simple. A REST application provides endpoints
>    protected by roles. The client application authenticates using an IdP
>    (eg.: KC) and invoke the REST endpoints by sending the token on every
>    single request. The application then validates, extract user information
>    from the token and creates a security context for a specific request.
> 
>    This identity store will operate in two modes:
> 
>        1) Stateless. Useful for applications acting only as a Service
>        Provider. In this case, the app only wants to join a SSO session and
>        use all information provided by a token to perform in-house
>        authorization such as RBAC. Tokens are not persisted and are usually
>        short-lived.
> 
>        2) Stateful. Useful for applications that want to use a specific token
>        to invoke 3rd party APIs. In this case, the app wants to login using
>        a social provider (eg.: facebook, github or even KC) and store the
>        token and user information locally for later use. Once stored, the
>        app can retrieve the token and use it to invoke an external API.
> 
>    What I did so far is related with #1 and the functionality is covering:
> 
>        - Usage of keycloak.js to redirect users to login page and renew
>        tokens.
>        - Send KC token in every single request to a specific PL filter that
>        knows how to process tokens.
>        - Validate the token and create a security context for an user.
>        Considering KC, the validation involves the expiration time,
>        signature, audience, issuer, etc.
>        - Extract from the token identity information such as username, roles,
>        realm, etc.
>        - Support authorization checks based on the information extracted from
>        a token.
> 
>    I still have some gaps to fill, but I would like to know what are your
>    thoughts about how PL and KC can work together. AFAIK, KeyCloak is more
>    about authentication. If the application wants authorization based on the
>    information from a token (eg.: roles) it must do it by itself. Or you
>    guys already have code for that ?
> 
> Thanks.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 23 05:15:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 23 Jul 2014 05:15:14 -0400 (EDT)
Subject: [keycloak-dev] Provider config
In-Reply-To: <53CEC02E.1020107@redhat.com>
References: <838939018.14896654.1406023009196.JavaMail.zimbra@redhat.com>
	<932526175.15092179.1406034500612.JavaMail.zimbra@redhat.com>
	<564031087.15100135.1406035008705.JavaMail.zimbra@redhat.com>
	<53CE6A6F.3090204@redhat.com>
	<775860373.15124732.1406037194982.JavaMail.zimbra@redhat.com>
	<53CE89F1.6020609@redhat.com>
	<1337760787.15416633.1406045967429.JavaMail.zimbra@redhat.com>
	<53CEC02E.1020107@redhat.com>
Message-ID: <1100101369.16144544.1406106914152.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 22 July, 2014 8:49:02 PM
> Subject: Re: [keycloak-dev] Provider config
> 
> That's doesn't necessarily my thoughts are any good though.  I'll
> iterate you can reiterate I guess...

I thought it was implied that I thought your thoughts where good ;)

This will take a few iterations to get correct IMO

> 
> On 7/22/2014 12:19 PM, Stian Thorgersen wrote:
> > Sounds like you've thought about this more than me, so I'll leave it with
> > you to sort out ;)
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 22 July, 2014 4:57:37 PM
> >> Subject: Re: [keycloak-dev] Provider config
> >>
> >>
> >>
> >> On 7/22/2014 9:53 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 22 July, 2014 2:43:11 PM
> >>>> Subject: Re: [keycloak-dev] Provider config
> >>>>
> >>>> Certain providers may have multiple instances/configs of themselves in
> >>>> the same realm.  i.e. authentication providers (soon to be federation
> >>>> providers) which may be federating multiple different LDAP databases.
> >>>> Also, in the future, social may turn into a "federated broker SPI" where
> >>>> multiple generic federated broker providers can be configured per realm
> >>>> (i.e. SAML or other openid connections).
> >>>
> >>> Didn't consider that, we'll definitively need it
> >>>
> >>
> >> In my private fork, I pulled getProviderFactory methods from
> >> DefaultKeycloakSessionFactory up to KeycloakSessionFactory methods.
> >> Then defined my own specialized create methods.  I don't use
> >> KeycloakSession.getProvider() anymore.
> >>
> >>
> >>>>
> >>>> I honestly don't want a generic "provider" admin console page where you
> >>>> generically configure the providers.  I think it is a mistake.  We're
> >>>> supposed to be making things easier and we should be making tailored
> >>>> console pages for what we ship out of the box.
> >>>
> >>> What about we allow configuring specific SPIs in the correct place, but
> >>> still use a form that is populated with labels/inputs from the providers
> >>> ConfigOptions?
> >>>
> >>
> >> LDAP config already doesn't fit into pure labels/inputs.  IMO, rendering
> >> information belongs in HTML :)
> >>
> >>
> >> --
> >> 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 psilva at redhat.com  Wed Jul 23 08:46:49 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 23 Jul 2014 08:46:49 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <53CF344F.5050902@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
Message-ID: <1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, July 23, 2014 1:04:31 AM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> 
> Keycloak is about authentication *and* authorization.  We currently have
> deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC
> for Servlet apps out of the box.  You can even take an existing WAR,
> without cracking it open, using the Keycloak JBoss/Wildfly Subsystem.
> We have plans for additional adapters post 1.0.Final for Node.js, JIRA,
> Tomcat, and Jetty.

What I'm doing is pretty much like what you have in third-party-cdi example. From this example, there is no security-constraint or adapter involved right ?

And looking at the code (from upstream) I can see a org.keycloak.example.oauth.RefreshTokenFilter that does pretty much what PL is doing. Extracting the CODE from the request and configuring an "user" representation which in our case is the Identity bean. Beside that, PL is also validating the token and allowing the application to query roles or any other data from the token.

I've looked others examples as well. From a PL-only perspective, I was looking for an integration 
fully based on PL where all details from a specific IdP is abstracted from developers. For instance, KC from an application perspective is an implementation detail. If you want you can easily switch to another IdP without change a single line of code in your application. But just PL config. So they can still use our built-in authz annotations and injection to deal with the security context for their users.

As far as I can see, most examples from KC are based on a coarse-grained authorization model based on a JEE security-constraint. Is that the authorization you're talking about ? Or KC also provides a more fine-grained mechanism to individual beans ?

> 
> We have both a stateless mode (bearer-only)as well as a stateful mode as
> well (HTTP Sessions).  We have revocation policies.  We have user
> session management.  Single Log Out, etc.  I urge you to try our demos,
> read our docs, and view our screencasts.  We do TONS OF SHIT :)
> 
> Right now, everything is OAuth2/OpenID Connect based with a small
> extension to JWT for role mappings.  Starting in September, I'll be
> adding SAML support in addition to OAuth/OpenID Connect.  I hope to
> incorporate much of the SAML modules in Picketlink IDP.  This will
> require a lot of refactoring in Keycloak to pull out all the
> non-protocol specific logic like UI rendering, browser authentication,
> and user management workflows (forgot password, totp setup,
> registration, etc.).  It will probably require refactoring of Picketlink
> as well.

Anil told me about it. That would be great.

> 
> For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our
> Social Provider SPI into a full fledged generic Broker SPI, of which I'd
> like a SAML plugin which could make use of any SAML client modules
> Picketlink has.
> 
> We're also missing integration with CDI and other component layers and a
> better application API for injecting and obtaining security metadata.

I think that is the area I'm trying to help. Considering that we already provide security for CDI applications,
service providers can still benefit from :

@Inject Identity identity; // representing the authenticated user
@Inject IdentityManager identityManager; // provides ways to query information retrieved from a token

Actually, that was a requirement from WFK. They asked us about how to easily enable KC in a PL application.

Maybe I should also take a look about how to use the adapter to provide all the token handling instead of doing it by my own.

> 
> Other areas Anil and I talked about are pulling out our Social Provider
> code into do-it-yourself APIs.  Really improving and expanding
> Picketlink Social.  I haven't looked at Picketlink Social, but I think
> Keycloak may be much more comprehensive.
> 
> Honesty, there is just so much shit to do.  Tons of it.  A lot of
> interesting (and not so interesting) work to go around.  I'd be happy to
> talk to you about it sometime soon.

Sure :)

> 
> On 7/22/2014 10:27 PM, Pedro Igor Silva wrote:
> > Hi All,
> >
> >     Currently, I'm working in a new identity store to handle tokens issued
> >     by a specific IdP. KeyCloak is one of them.
> >
> >     So far, I'm trying to provide an easy way to integrate KC with PL. But
> >     it will also be useful for SAML-based apps.
> >
> >     My first use case is simple. A REST application provides endpoints
> >     protected by roles. The client application authenticates using an IdP
> >     (eg.: KC) and invoke the REST endpoints by sending the token on every
> >     single request. The application then validates, extract user
> >     information from the token and creates a security context for a
> >     specific request.
> >
> >     This identity store will operate in two modes:
> >
> >         1) Stateless. Useful for applications acting only as a Service
> >         Provider. In this case, the app only wants to join a SSO session
> >         and use all information provided by a token to perform in-house
> >         authorization such as RBAC. Tokens are not persisted and are
> >         usually short-lived.
> >
> >         2) Stateful. Useful for applications that want to use a specific
> >         token to invoke 3rd party APIs. In this case, the app wants to
> >         login using a social provider (eg.: facebook, github or even KC)
> >         and store the token and user information locally for later use.
> >         Once stored, the app can retrieve the token and use it to invoke
> >         an external API.
> >
> >     What I did so far is related with #1 and the functionality is covering:
> >
> >         - Usage of keycloak.js to redirect users to login page and renew
> >         tokens.
> >         - Send KC token in every single request to a specific PL filter
> >         that knows how to process tokens.
> >         - Validate the token and create a security context for an user.
> >         Considering KC, the validation involves the expiration time,
> >         signature, audience, issuer, etc.
> >         - Extract from the token identity information such as username,
> >         roles, realm, etc.
> >         - Support authorization checks based on the information extracted
> >         from a token.
> >
> >     I still have some gaps to fill, but I would like to know what are your
> >     thoughts about how PL and KC can work together. AFAIK, KeyCloak is
> >     more about authentication. If the application wants authorization
> >     based on the information from a token (eg.: roles) it must do it by
> >     itself. Or you guys already have code for that ?
> >
> > Thanks.
> > Pedro Igor
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Wed Jul 23 08:48:13 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 23 Jul 2014 08:48:13 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <911582521.16140632.1406106360529.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<911582521.16140632.1406106360529.JavaMail.zimbra@redhat.com>
Message-ID: <425922692.12115690.1406119693474.JavaMail.zimbra@redhat.com>

Maybe I should also take a look about how to use the adapter to provide all the token handling instead of doing it by my own ...

Just a note, PL just like Spring and Shiro are alternatives to JEE security.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, July 23, 2014 6:06:00 AM
Subject: Re: [keycloak-dev] PicketLink and KC Integration

As JavaEE security is lacking at best it would be nice to see integration with PL to use PL CDI and permissions. 

I haven't looked at PL for a while, so I'm not 100% up to date with how it all works now. However, this doesn't seem like the correct approach to me. As Bill pointed out our as7/undertow adapters already do this stuff. IMO an application should be secured using the KC adapters, then use PL CDI/permissions when JavaEE security mechanisms are not enough.

----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 3:27:33 AM
> Subject: [keycloak-dev] PicketLink and KC Integration
> 
> Hi All,
> 
>    Currently, I'm working in a new identity store to handle tokens issued by
>    a specific IdP. KeyCloak is one of them.
> 
>    So far, I'm trying to provide an easy way to integrate KC with PL. But it
>    will also be useful for SAML-based apps.
> 
>    My first use case is simple. A REST application provides endpoints
>    protected by roles. The client application authenticates using an IdP
>    (eg.: KC) and invoke the REST endpoints by sending the token on every
>    single request. The application then validates, extract user information
>    from the token and creates a security context for a specific request.
> 
>    This identity store will operate in two modes:
> 
>        1) Stateless. Useful for applications acting only as a Service
>        Provider. In this case, the app only wants to join a SSO session and
>        use all information provided by a token to perform in-house
>        authorization such as RBAC. Tokens are not persisted and are usually
>        short-lived.
> 
>        2) Stateful. Useful for applications that want to use a specific token
>        to invoke 3rd party APIs. In this case, the app wants to login using
>        a social provider (eg.: facebook, github or even KC) and store the
>        token and user information locally for later use. Once stored, the
>        app can retrieve the token and use it to invoke an external API.
> 
>    What I did so far is related with #1 and the functionality is covering:
> 
>        - Usage of keycloak.js to redirect users to login page and renew
>        tokens.
>        - Send KC token in every single request to a specific PL filter that
>        knows how to process tokens.
>        - Validate the token and create a security context for an user.
>        Considering KC, the validation involves the expiration time,
>        signature, audience, issuer, etc.
>        - Extract from the token identity information such as username, roles,
>        realm, etc.
>        - Support authorization checks based on the information extracted from
>        a token.
> 
>    I still have some gaps to fill, but I would like to know what are your
>    thoughts about how PL and KC can work together. AFAIK, KeyCloak is more
>    about authentication. If the application wants authorization based on the
>    information from a token (eg.: roles) it must do it by itself. Or you
>    guys already have code for that ?
> 
> Thanks.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Wed Jul 23 10:40:26 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 10:40:26 -0400
Subject: [keycloak-dev] how are model tests run?
Message-ID: <53CFC95A.8060202@redhat.com>

I don't see how/where the model tests are run or how to run them 
individually in my IDE (intellij)
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Jul 23 10:08:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 10:08:12 -0400
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
Message-ID: <53CFC1CC.9000906@redhat.com>



On 7/23/2014 8:46 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, July 23, 2014 1:04:31 AM
>> Subject: Re: [keycloak-dev] PicketLink and KC Integration
>>
>> Keycloak is about authentication *and* authorization.  We currently have
>> deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC
>> for Servlet apps out of the box.  You can even take an existing WAR,
>> without cracking it open, using the Keycloak JBoss/Wildfly Subsystem.
>> We have plans for additional adapters post 1.0.Final for Node.js, JIRA,
>> Tomcat, and Jetty.
>
> What I'm doing is pretty much like what you have in third-party-cdi example. From this example, there is no security-constraint or adapter involved right ?
>



> And looking at the code (from upstream) I can see a org.keycloak.example.oauth.RefreshTokenFilter that does pretty much what PL is doing. Extracting the CODE from the request and configuring an "user" representation which in our case is the Identity bean. Beside that, PL is also validating the token and allowing the application to query roles or any other data from the token.
>
The third-party example is an example of traditional OAuth.  Traditional 
OAuth is not SSO, nor is it anything about identity.  It is about 
getting a temporary token so you can get access to a resource.  Generic 
oauth/openid connect client libraries is another intersection of 
Picketlink and Keycloak that should be shared.  I'm not happy with what 
we got right now.

Our adapters are different than the third-party example.  They are our 
integrated security story:  Single Sign On/Off.  Session management. 
Role mappings.  Component integration, etc.


> I've looked others examples as well. From a PL-only perspective, I was looking for an integration
> fully based on PL where all details from a specific IdP is abstracted from developers. For instance, KC from an application perspective is an implementation detail. If you want you can easily switch to another IdP without change a single line of code in your application. But just PL config. So they can still use our built-in authz annotations and injection to deal with the security context for their users.
>

This is something I'd like to see.  For PIcketlink, Spring security, and 
other security abstractions.  Keycloak 1.0 is 100% focused only on Java 
EE security integration.

> As far as I can see, most examples from KC are based on a coarse-grained authorization model based on a JEE security-constraint. Is that the authorization you're talking about ? Or KC also provides a more fine-grained mechanism to individual beans ?
>

Keycloak is just role based authorization right now.  Roles can be 
scoped at the Realm level, or scoped per application.  We also have some 
claim support (address, phone ,etc.) too.

Keycloak adapters create a principal and populates the Subject with role 
mappings. The adapters also provide REST endpoints for gathering 
management stats, to propagate revocation policies, and also to manage 
Single Sign Off.

>>
>> For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our
>> Social Provider SPI into a full fledged generic Broker SPI, of which I'd
>> like a SAML plugin which could make use of any SAML client modules
>> Picketlink has.
>>
>> We're also missing integration with CDI and other component layers and a
>> better application API for injecting and obtaining security metadata.
>
> I think that is the area I'm trying to help. Considering that we already provide security for CDI applications,
> service providers can still benefit from :
>
> @Inject Identity identity; // representing the authenticated user
> @Inject IdentityManager identityManager; // provides ways to query information retrieved from a token
>

Keycloak has its own specific security model so it will need its own API 
in addition to integration with PL, Spring and other security abstractions.


> Actually, that was a requirement from WFK. They asked us about how to easily enable KC in a PL application.
>
> Maybe I should also take a look about how to use the adapter to provide all the token handling instead of doing it by my own.
>

You don't need to look at the adapter. 
HttpServletRequest.getUserPrincipal() should return an instance of 
KeycloakPrincipal which has a method to get KeycloakSecurityContext 
which has access to the unmarshalled token.  KeycloakSecurityContext is 
also available as a HttpServletRequest attribute:

KeycloakSEcurityContext context = 
(KeycloakSecurityContext)request.getAttribute(KeycloakSecurityContext.class.getName());

Finally, tokens can have any number of claims in them too (address, 
phone, website, blog, picture, etc.).


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

From stian at redhat.com  Wed Jul 23 11:13:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 23 Jul 2014 11:13:29 -0400 (EDT)
Subject: [keycloak-dev] Updates to access code
In-Reply-To: <57608162.16538666.1406127776949.JavaMail.zimbra@redhat.com>
Message-ID: <829185613.16545908.1406128409396.JavaMail.zimbra@redhat.com>

I've completed all the pre-work required before storing AccessCode details in UserSessionProvider.

What's be done to AccessCode is:

* It no longer contains AccessToken. Instead it just contains the list of requested roles (intersection of client scope and user roles). The AccessToken is generated from this in the TokenService.codeToToken
* authMethod, usernameUsed and rememberMe has been moved to UserSessionModel
* list of RequiredActions have been changed to a single action. The action can be one of the required actions, oauth_grant, or nothing. A code can only be used for the action currently set on it. For example if the code is set to VERIFY_EMAIL that is the only thing it's useful for. Also added the oauth_grant action to make sure a user has verified the grants (if client obviously) before the code is active and can be used to obtain a token.
* expiration has been removed. Instead the timestamp and realm.getAccessCodeLifespan/getAccessCodeLifespanUserAction is used directly.

That's it. Next step is to the details in UserSessionProvider and only send the id as the code query param.

Question: is sending UUID + timestamp sufficient as the code, or should we sign it with JWSBuilder as well?

From stian at redhat.com  Wed Jul 23 11:16:11 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 23 Jul 2014 11:16:11 -0400 (EDT)
Subject: [keycloak-dev] how are model tests run?
In-Reply-To: <53CFC95A.8060202@redhat.com>
References: <53CFC95A.8060202@redhat.com>
Message-ID: <1507419132.16547970.1406128571031.JavaMail.zimbra@redhat.com>

They're disabled by purpose at the moment.

Due to the provider updates, and splitting the model, it was quite awkward to get them to work so the plan is to move them to testsuite. This has already been done to UserSessionProviderTest.

I'll start moving the rest right away.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 3:40:26 PM
> Subject: [keycloak-dev] how are model tests run?
> 
> I don't see how/where the model tests are run or how to run them
> individually in my IDE (intellij)
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Wed Jul 23 11:33:06 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 23 Jul 2014 11:33:06 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <53CFC1CC.9000906@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
Message-ID: <1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, July 23, 2014 11:08:12 AM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> 
> 
> 
> On 7/23/2014 8:46 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, July 23, 2014 1:04:31 AM
> >> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> >>
> >> Keycloak is about authentication *and* authorization.  We currently have
> >> deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC
> >> for Servlet apps out of the box.  You can even take an existing WAR,
> >> without cracking it open, using the Keycloak JBoss/Wildfly Subsystem.
> >> We have plans for additional adapters post 1.0.Final for Node.js, JIRA,
> >> Tomcat, and Jetty.
> >
> > What I'm doing is pretty much like what you have in third-party-cdi
> > example. From this example, there is no security-constraint or adapter
> > involved right ?
> >
> 
> 
> 
> > And looking at the code (from upstream) I can see a
> > org.keycloak.example.oauth.RefreshTokenFilter that does pretty much what
> > PL is doing. Extracting the CODE from the request and configuring an
> > "user" representation which in our case is the Identity bean. Beside that,
> > PL is also validating the token and allowing the application to query
> > roles or any other data from the token.
> >
> The third-party example is an example of traditional OAuth.  Traditional
> OAuth is not SSO, nor is it anything about identity.  It is about
> getting a temporary token so you can get access to a resource.  Generic
> oauth/openid connect client libraries is another intersection of
> Picketlink and Keycloak that should be shared.  I'm not happy with what
> we got right now.

Agree on the oAuth stuff. But as I told you there is a pretty common scenario where an application provides a social login. IMO, social logins can be used as follows:

1) Account Linking. In this case, the application may want to provide its own registration (username/password) and only link user's account to a specific social one. Eg.: JBoss Developer Site.
2) Account Linking + Remember-Me. In this case, the application does not store user credentials at all but relies on the social provider to authenticate based on the token retrieved from the social provider. As long the token is valid and your browser has a valid session in a social provider, you're always redirected back to app with a token and authenticated by the application. It is a fake "SSO" :)

There is another scenario that I'm considering that is related with scopes. In this case, the oAuth server authorizes a client application to use a set of scopes (eg.: read public profile). The client application then uses the token to invoke an API provided by another application. I want to use the token to extract the authorized scopes and protect my API.

> 
> Our adapters are different than the third-party example.  They are our
> integrated security story:  Single Sign On/Off.  Session management.
> Role mappings.  Component integration, etc.

Yeah, they remind me PL SAML Authenticators :)

> 
> 
> > I've looked others examples as well. From a PL-only perspective, I was
> > looking for an integration
> > fully based on PL where all details from a specific IdP is abstracted from
> > developers. For instance, KC from an application perspective is an
> > implementation detail. If you want you can easily switch to another IdP
> > without change a single line of code in your application. But just PL
> > config. So they can still use our built-in authz annotations and injection
> > to deal with the security context for their users.
> >
> 
> This is something I'd like to see.  For PIcketlink, Spring security, and
> other security abstractions.  Keycloak 1.0 is 100% focused only on Java
> EE security integration.

I see. I'm preparing some quickstarts to showcase this. Let's see ...

> 
> > As far as I can see, most examples from KC are based on a coarse-grained
> > authorization model based on a JEE security-constraint. Is that the
> > authorization you're talking about ? Or KC also provides a more
> > fine-grained mechanism to individual beans ?
> >
> 
> Keycloak is just role based authorization right now.  Roles can be
> scoped at the Realm level, or scoped per application.  We also have some
> claim support (address, phone ,etc.) too.
> 
> Keycloak adapters create a principal and populates the Subject with role
> mappings. The adapters also provide REST endpoints for gathering
> management stats, to propagate revocation policies, and also to manage
> Single Sign Off.
> 
> >>
> >> For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our
> >> Social Provider SPI into a full fledged generic Broker SPI, of which I'd
> >> like a SAML plugin which could make use of any SAML client modules
> >> Picketlink has.
> >>
> >> We're also missing integration with CDI and other component layers and a
> >> better application API for injecting and obtaining security metadata.
> >
> > I think that is the area I'm trying to help. Considering that we already
> > provide security for CDI applications,
> > service providers can still benefit from :
> >
> > @Inject Identity identity; // representing the authenticated user
> > @Inject IdentityManager identityManager; // provides ways to query
> > information retrieved from a token
> >
> 
> Keycloak has its own specific security model so it will need its own API
> in addition to integration with PL, Spring and other security abstractions.
> 
> 
> > Actually, that was a requirement from WFK. They asked us about how to
> > easily enable KC in a PL application.
> >
> > Maybe I should also take a look about how to use the adapter to provide all
> > the token handling instead of doing it by my own.
> >
> 
> You don't need to look at the adapter.
> HttpServletRequest.getUserPrincipal() should return an instance of
> KeycloakPrincipal which has a method to get KeycloakSecurityContext
> which has access to the unmarshalled token.  KeycloakSecurityContext is
> also available as a HttpServletRequest attribute:
> 
> KeycloakSEcurityContext context =
> (KeycloakSecurityContext)request.getAttribute(KeycloakSecurityContext.class.getName());
> 
> Finally, tokens can have any number of claims in them too (address,
> phone, website, blog, picture, etc.).

Cool. Tks.

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

From ssilvert at redhat.com  Wed Jul 23 11:35:52 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 23 Jul 2014 11:35:52 -0400
Subject: [keycloak-dev] Beta 4 release?
Message-ID: <53CFD658.2020207@redhat.com>

I'm waiting on the next Keycloak release.  Any idea when it will happen?

Stan

From bburke at redhat.com  Wed Jul 23 13:27:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 13:27:54 -0400
Subject: [keycloak-dev] Beta 4 release?
In-Reply-To: <53CFD658.2020207@redhat.com>
References: <53CFD658.2020207@redhat.com>
Message-ID: <53CFF09A.4000501@redhat.com>

August 6th or earlier.  Soon after Beta 4 will be 1.0.Final.

On 7/23/2014 11:35 AM, Stan Silvert wrote:
> I'm waiting on the next Keycloak release.  Any idea when it will happen?
>
> 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 bburke at redhat.com  Wed Jul 23 13:34:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 13:34:00 -0400
Subject: [keycloak-dev] Updates to access code
In-Reply-To: <829185613.16545908.1406128409396.JavaMail.zimbra@redhat.com>
References: <829185613.16545908.1406128409396.JavaMail.zimbra@redhat.com>
Message-ID: <53CFF208.7050003@redhat.com>



On 7/23/2014 11:13 AM, Stian Thorgersen wrote:
> I've completed all the pre-work required before storing AccessCode details in UserSessionProvider.
>
> What's be done to AccessCode is:
>
> * It no longer contains AccessToken. Instead it just contains the list of requested roles (intersection of client scope and user roles). The AccessToken is generated from this in the TokenService.codeToToken
> * authMethod, usernameUsed and rememberMe has been moved to UserSessionModel
> * list of RequiredActions have been changed to a single action. The action can be one of the required actions, oauth_grant, or nothing. A code can only be used for the action currently set on it. For example if the code is set to VERIFY_EMAIL that is the only thing it's useful for. Also added the oauth_grant action to make sure a user has verified the grants (if client obviously) before the code is active and can be used to obtain a token.
> * expiration has been removed. Instead the timestamp and realm.getAccessCodeLifespan/getAccessCodeLifespanUserAction is used directly.
>
> That's it. Next step is to the details in UserSessionProvider and only send the id as the code query param.
>
> Question: is sending UUID + timestamp sufficient as the code, or should we sign it with JWSBuilder as well?

Don't think you need a timestamp as the user session should have a 
timestamp.  Without signature, isn't this another brute force vulnerability?

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

From bburke at redhat.com  Wed Jul 23 17:33:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 23 Jul 2014 17:33:12 -0400
Subject: [keycloak-dev] federation commited need feedback
Message-ID: <53D02A18.3060007@redhat.com>

First iteration is commited.  I still have a lot to do.

* AuthenticationProvider currently co-exists with Federation.  I will 
delete it after the review of FederationProvider.
* UserModel is proxied.  Some updates delegated to LDAP.  Need to expand.
* Still need to do admin console UI for federation
* Still need to implement search and other queries for LDAP
* Still need to test disjoint credential type storage.

Feedback on unimplemented features for LDAP:
* registration supported switch.
* Importing username and email will be required.  Everything else will 
be optional.  That cool?
* Modes for federation will be:  READ_ONLY, SYNCED, and UNSYNCED. 
SYNCED will update LDAP on demand. UNSYNCED will store changes locally 
and require the user to handle synchronization themselves.
* Going to have an import-attributes on/off switch.  A keycloak->ldap 
attribute map will be required to be configured.  If this switch is off, 
UserModel proxy will load attributes on demand.


Questions:
* Is ExternalModelAuthProvider actually a feature requested by users? 
I'd like to not have to do this.  At least for 1.0.

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

From stian at redhat.com  Thu Jul 24 03:34:51 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 03:34:51 -0400 (EDT)
Subject: [keycloak-dev] Updates to access code
In-Reply-To: <53CFF208.7050003@redhat.com>
References: <829185613.16545908.1406128409396.JavaMail.zimbra@redhat.com>
	<53CFF208.7050003@redhat.com>
Message-ID: <1439269102.17102861.1406187291673.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 6:34:00 PM
> Subject: Re: [keycloak-dev] Updates to access code
> 
> 
> 
> On 7/23/2014 11:13 AM, Stian Thorgersen wrote:
> > I've completed all the pre-work required before storing AccessCode details
> > in UserSessionProvider.
> >
> > What's be done to AccessCode is:
> >
> > * It no longer contains AccessToken. Instead it just contains the list of
> > requested roles (intersection of client scope and user roles). The
> > AccessToken is generated from this in the TokenService.codeToToken
> > * authMethod, usernameUsed and rememberMe has been moved to
> > UserSessionModel
> > * list of RequiredActions have been changed to a single action. The action
> > can be one of the required actions, oauth_grant, or nothing. A code can
> > only be used for the action currently set on it. For example if the code
> > is set to VERIFY_EMAIL that is the only thing it's useful for. Also added
> > the oauth_grant action to make sure a user has verified the grants (if
> > client obviously) before the code is active and can be used to obtain a
> > token.
> > * expiration has been removed. Instead the timestamp and
> > realm.getAccessCodeLifespan/getAccessCodeLifespanUserAction is used
> > directly.
> >
> > That's it. Next step is to the details in UserSessionProvider and only send
> > the id as the code query param.
> >
> > Question: is sending UUID + timestamp sufficient as the code, or should we
> > sign it with JWSBuilder as well?
> 
> Don't think you need a timestamp as the user session should have a
> timestamp.  Without signature, isn't this another brute force vulnerability?

Timestamp is needed for the code as it has a shorter lifespan than a user-session.

Yep, my instinct says let's encrypt it to be safe.

> 
> --
> 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  Thu Jul 24 05:31:42 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Jul 2014 11:31:42 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D02A18.3060007@redhat.com>
References: <53D02A18.3060007@redhat.com>
Message-ID: <53D0D27E.2020504@redhat.com>

Great stuff, some feedback inline

On 23.7.2014 23:33, Bill Burke wrote:
> First iteration is commited.  I still have a lot to do.
>
> * AuthenticationProvider currently co-exists with Federation.  I will
> delete it after the review of FederationProvider.
> * UserModel is proxied.  Some updates delegated to LDAP.  Need to expand.
> * Still need to do admin console UI for federation
> * Still need to implement search and other queries for LDAP
> * Still need to test disjoint credential type storage.
>
> Feedback on unimplemented features for LDAP:
> * registration supported switch.
> * Importing username and email will be required.  Everything else will
> be optional.  That cool?
yeah. Not directly related but I wonder if federationLink on UserModel 
is sufficient? For example if user "john" is deleted in LDAP and then 
user with same username "john" is added again to LDAP, it's defacto 
different user but the Keycloak user "john" will be linked to the "new" 
LDAP john. Hence AuthLinkModel had link to provider and also uuid of 
user from LDAP.
> * Modes for federation will be:  READ_ONLY, SYNCED, and UNSYNCED.
> SYNCED will update LDAP on demand. UNSYNCED will store changes locally
> and require the user to handle synchronization themselves.
Is it some difference between READ_ONLY and UNSYNCED? Wonder if 2 modes 
are sufficient for federation and users are free to choose if they 
handle synchronization or not? Am I understand correctly that this is 
just for sync from Keycloak back to LDAP?
> * Going to have an import-attributes on/off switch.  A keycloak->ldap
> attribute map will be required to be configured.  If this switch is off,
> UserModel proxy will load attributes on demand.
>
>
> Questions:
> * Is ExternalModelAuthProvider actually a feature requested by users?
> I'd like to not have to do this.  At least for 1.0.
Probably not needed AFAIK.

Sorry to repeat, but I still have some doubts especially about bulk 
search methods. Example of some corner cases:

* If there are 2 federation providers and firstResult==0, maxResults==10 
and each provider has 10 users, then due to this 
https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/FederationManager.java#L193 
it may be 20 users in final list (even if maxResults is 10)

* If there are 10 users "locally" and 10 completely different users in 
LDAP, and firstResult ==0, maxResults==10 then it will return 10 "local" 
users. Now you want next page so next query will be firstResult==10, 
maxResults==10 . This should return 10 users from LDAP, but actually it 
won't return any user as LDAP query will have firstResult==10, 
maxResults==10, but there are just 10 users in LDAP

* In some cases it may happen the opposite . Like you have user "john" 
in both LDAP and local store. Page1 will return 10 local users with 
"john" between them. Page2 will query LDAP and it may also return "john" 
between them (the case when "john" is on page1 in "local" store but on 
page2 on LDAP store)


Right now, I am looking at changelog stuff, which is supported by 
ActiveDirectory but not by some other LDAP servers. Right now I am 
working with Keycloak on latest Picketlink master, which helped to 
remove ActiveDirectory workarounds needed in 
LDAPKeycloakCredentialHandler and KeycloakLDAPIdentityStore . I will 
also possibly send more PRs to picketlink with missing features 
regarding changelog and pagination .

Marek



From stian at redhat.com  Thu Jul 24 08:54:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 08:54:15 -0400 (EDT)
Subject: [keycloak-dev] how are model tests run?
In-Reply-To: <1507419132.16547970.1406128571031.JavaMail.zimbra@redhat.com>
References: <53CFC95A.8060202@redhat.com>
	<1507419132.16547970.1406128571031.JavaMail.zimbra@redhat.com>
Message-ID: <1885387078.17317248.1406206455951.JavaMail.zimbra@redhat.com>

audit/tests and model/tests have been moved to testsuite/integration

These can be run through your IDE in the usual way with the default server config (jpa realm/users and mem sessions). I found the easiest way to run the tests with a specific model is to edit keycloak-server.json directly, alternatively you can use system properties when running the tests (for example -Dkeycloak.realm.provider=mongo).

In addition to the default server config there's two maven profiles that can be used to run with JPA (everything jpa, including sessions) or Mongo (everything mongo):

# mvn install -Pjpa

or 

# mvn install -Pmongo

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 4:16:11 PM
> Subject: Re: [keycloak-dev] how are model tests run?
> 
> They're disabled by purpose at the moment.
> 
> Due to the provider updates, and splitting the model, it was quite awkward to
> get them to work so the plan is to move them to testsuite. This has already
> been done to UserSessionProviderTest.
> 
> I'll start moving the rest right away.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 23 July, 2014 3:40:26 PM
> > Subject: [keycloak-dev] how are model tests run?
> > 
> > I don't see how/where the model tests are run or how to run them
> > individually in my IDE (intellij)
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jul 24 08:55:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 08:55:10 -0400
Subject: [keycloak-dev] how are model tests run?
In-Reply-To: <1885387078.17317248.1406206455951.JavaMail.zimbra@redhat.com>
References: <53CFC95A.8060202@redhat.com>
	<1507419132.16547970.1406128571031.JavaMail.zimbra@redhat.com>
	<1885387078.17317248.1406206455951.JavaMail.zimbra@redhat.com>
Message-ID: <53D1022E.60806@redhat.com>

Cool!  The tests still work?!?  I was worried...

On 7/24/2014 8:54 AM, Stian Thorgersen wrote:
> audit/tests and model/tests have been moved to testsuite/integration
>
> These can be run through your IDE in the usual way with the default server config (jpa realm/users and mem sessions). I found the easiest way to run the tests with a specific model is to edit keycloak-server.json directly, alternatively you can use system properties when running the tests (for example -Dkeycloak.realm.provider=mongo).
>
> In addition to the default server config there's two maven profiles that can be used to run with JPA (everything jpa, including sessions) or Mongo (everything mongo):
>
> # mvn install -Pjpa
>
> or
>
> # mvn install -Pmongo
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 23 July, 2014 4:16:11 PM
>> Subject: Re: [keycloak-dev] how are model tests run?
>>
>> They're disabled by purpose at the moment.
>>
>> Due to the provider updates, and splitting the model, it was quite awkward to
>> get them to work so the plan is to move them to testsuite. This has already
>> been done to UserSessionProviderTest.
>>
>> I'll start moving the rest right away.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 23 July, 2014 3:40:26 PM
>>> Subject: [keycloak-dev] how are model tests run?
>>>
>>> I don't see how/where the model tests are run or how to run them
>>> individually in my IDE (intellij)
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From bruno at abstractj.org  Thu Jul 24 08:57:38 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 24 Jul 2014 09:57:38 -0300
Subject: [keycloak-dev] Wildfly integration
Message-ID: <20140724125738.GA96564@abstractj.org>

Good morning guys, I'm banging my head against the wall with this issue:
https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm trying to
do is integrate the latest changes on master with UPS on AeroGear.

On AS7 the application runs with no errors, but when I try to deploy on
Wildfly I get HTTP 400 after login.

Probably is some misconfiguration on my end, but I already double checked
project-integrations, checked the examples, tried to debug on IntelliJ and
Chrome.

Here are the steps to reproduce:

git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
clean install -DskipTests=true -Dcheckstyle.skip=true
cd ..
git clone git at github.com:aerogear/aerogear-parent.git && cd
aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
cd ..
git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true

cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
cp auth-server/target/auth-server.war
$JBOSS_HOME/standalone/deployments/
cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments

$JBOSS_HOME/bin/standalone.sh

If you have an idea, let me know.

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Thu Jul 24 09:01:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 09:01:09 -0400 (EDT)
Subject: [keycloak-dev] how are model tests run?
In-Reply-To: <53D1022E.60806@redhat.com>
References: <53CFC95A.8060202@redhat.com>
	<1507419132.16547970.1406128571031.JavaMail.zimbra@redhat.com>
	<1885387078.17317248.1406206455951.JavaMail.zimbra@redhat.com>
	<53D1022E.60806@redhat.com>
Message-ID: <803166005.17327120.1406206869769.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 1:55:10 PM
> Subject: Re: [keycloak-dev] how are model tests run?
> 
> Cool!  The tests still work?!?  I was worried...

Only two things where broken, fixed now:

* Cache didn't check that app/client/roles belong to realm, so returned ById even though the realm wasn't correct
* AuthenticationManager.authenticateInternal didn't check password if totp was enabled, it only checked the totp. Pretty scary! I'm going to add an additional test to LoginTotpTest for this to be doubly sure in the future.

> 
> On 7/24/2014 8:54 AM, Stian Thorgersen wrote:
> > audit/tests and model/tests have been moved to testsuite/integration
> >
> > These can be run through your IDE in the usual way with the default server
> > config (jpa realm/users and mem sessions). I found the easiest way to run
> > the tests with a specific model is to edit keycloak-server.json directly,
> > alternatively you can use system properties when running the tests (for
> > example -Dkeycloak.realm.provider=mongo).
> >
> > In addition to the default server config there's two maven profiles that
> > can be used to run with JPA (everything jpa, including sessions) or Mongo
> > (everything mongo):
> >
> > # mvn install -Pjpa
> >
> > or
> >
> > # mvn install -Pmongo
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 23 July, 2014 4:16:11 PM
> >> Subject: Re: [keycloak-dev] how are model tests run?
> >>
> >> They're disabled by purpose at the moment.
> >>
> >> Due to the provider updates, and splitting the model, it was quite awkward
> >> to
> >> get them to work so the plan is to move them to testsuite. This has
> >> already
> >> been done to UserSessionProviderTest.
> >>
> >> I'll start moving the rest right away.
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, 23 July, 2014 3:40:26 PM
> >>> Subject: [keycloak-dev] how are model tests run?
> >>>
> >>> I don't see how/where the model tests are run or how to run them
> >>> individually in my IDE (intellij)
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ken at kenfinnigan.me  Thu Jul 24 09:21:11 2014
From: ken at kenfinnigan.me (Ken Finnigan)
Date: Thu, 24 Jul 2014 09:21:11 -0400
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <20140724125738.GA96564@abstractj.org>
References: <20140724125738.GA96564@abstractj.org>
Message-ID: <CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>

I think I've also seen that exception when using Keycloak in LiveOak on
WildFly, but I believe it doesn't prevent anything from working, at least
from the tests I've done.

But it would be nice to know what's causing it.

Ken



On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org> wrote:

> Good morning guys, I'm banging my head against the wall with this issue:
> https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what
> I'm trying to
> do is integrate the latest changes on master with UPS on AeroGear.
>
> On AS7 the application runs with no errors, but when I try to deploy on
> Wildfly I get HTTP 400 after login.
>
> Probably is some misconfiguration on my end, but I already double checked
> project-integrations, checked the examples, tried to debug on IntelliJ and
> Chrome.
>
> Here are the steps to reproduce:
>
> git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> clean install -DskipTests=true -Dcheckstyle.skip=true
> cd ..
> git clone git at github.com:aerogear/aerogear-parent.git && cd
> aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> cd ..
> git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
>
> cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> cp auth-server/target/auth-server.war
> $JBOSS_HOME/standalone/deployments/
> cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
>
> $JBOSS_HOME/bin/standalone.sh
>
> If you have an idea, let me know.
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140724/4d12bf39/attachment.html 

From bburke at redhat.com  Thu Jul 24 09:21:37 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 09:21:37 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D0D27E.2020504@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
Message-ID: <53D10861.10709@redhat.com>



On 7/24/2014 5:31 AM, Marek Posolda wrote:
> Great stuff, some feedback inline
>
> On 23.7.2014 23:33, Bill Burke wrote:
>> First iteration is commited.  I still have a lot to do.
>>
>> * AuthenticationProvider currently co-exists with Federation.  I will
>> delete it after the review of FederationProvider.
>> * UserModel is proxied.  Some updates delegated to LDAP.  Need to expand.
>> * Still need to do admin console UI for federation
>> * Still need to implement search and other queries for LDAP
>> * Still need to test disjoint credential type storage.
>>
>> Feedback on unimplemented features for LDAP:
>> * registration supported switch.
>> * Importing username and email will be required.  Everything else will
>> be optional.  That cool?
> yeah. Not directly related but I wonder if federationLink on UserModel
> is sufficient? For example if user "john" is deleted in LDAP and then
> user with same username "john" is added again to LDAP, it's defacto
> different user but the Keycloak user "john" will be linked to the "new"
> LDAP john. Hence AuthLinkModel had link to provider and also uuid of
> user from LDAP.

This is an implementation detail and shouldn't really be exposed through 
the Model API.

>> * Modes for federation will be:  READ_ONLY, SYNCED, and UNSYNCED.
>> SYNCED will update LDAP on demand. UNSYNCED will store changes locally
>> and require the user to handle synchronization themselves.
> Is it some difference between READ_ONLY and UNSYNCED? Wonder if 2 modes
> are sufficient for federation and users are free to choose if they
> handle synchronization or not? Am I understand correctly that this is
> just for sync from Keycloak back to LDAP?


SYNCED means LDAP is writable and there will be on-demand updates back 
to LDAP.

UNSYNCED is when LDAP is read-only but you want to be able to manage the 
user anyways:  update their credentials, address, etc.

READ-ONLY doesn't allow any changes to user.

>> * Going to have an import-attributes on/off switch.  A keycloak->ldap
>> attribute map will be required to be configured.  If this switch is off,
>> UserModel proxy will load attributes on demand.
>>
>>
>> Questions:
>> * Is ExternalModelAuthProvider actually a feature requested by users?
>> I'd like to not have to do this.  At least for 1.0.
> Probably not needed AFAIK.
>
> Sorry to repeat, but I still have some doubts especially about bulk
> search methods. Example of some corner cases:
>
> * If there are 2 federation providers and firstResult==0, maxResults==10
> and each provider has 10 users, then due to this
> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/FederationManager.java#L193
> it may be 20 users in final list (even if maxResults is 10)
>
> * If there are 10 users "locally" and 10 completely different users in
> LDAP, and firstResult ==0, maxResults==10 then it will return 10 "local"
> users. Now you want next page so next query will be firstResult==10,
> maxResults==10 . This should return 10 users from LDAP, but actually it
> won't return any user as LDAP query will have firstResult==10,
> maxResults==10, but there are just 10 users in LDAP
>

I haven't actually tested or even executed searches yet.  Thanks for 
pointing outthe bugs.

> * In some cases it may happen the opposite . Like you have user "john"
> in both LDAP and local store. Page1 will return 10 local users with
> "john" between them. Page2 will query LDAP and it may also return "john"
> between them (the case when "john" is on page1 in "local" store but on
> page2 on LDAP store)
>
>
> Right now, I am looking at changelog stuff, which is supported by
> ActiveDirectory but not by some other LDAP servers. Right now I am
> working with Keycloak on latest Picketlink master, which helped to
> remove ActiveDirectory workarounds needed in
> LDAPKeycloakCredentialHandler and KeycloakLDAPIdentityStore . I will
> also possibly send more PRs to picketlink with missing features
> regarding changelog and pagination .
>

FYI, I forked the picketlink code under federation/ldap.  Mainly to keep 
AuthProvider stuff alive and working until the switch is ready.


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

From ssilvert at redhat.com  Thu Jul 24 09:23:33 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 24 Jul 2014 09:23:33 -0400
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
References: <20140724125738.GA96564@abstractj.org>
	<CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
Message-ID: <53D108D5.4020706@redhat.com>

My guess is that something is wrong with your keycloak.json.

On 7/24/2014 9:21 AM, Ken Finnigan wrote:
> I think I've also seen that exception when using Keycloak in LiveOak 
> on WildFly, but I believe it doesn't prevent anything from working, at 
> least from the tests I've done.
>
> But it would be nice to know what's causing it.
>
> Ken
>
>
>
> On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org 
> <mailto:bruno at abstractj.org>> wrote:
>
>     Good morning guys, I'm banging my head against the wall with this
>     issue:
>     https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically
>     what I'm trying to
>     do is integrate the latest changes on master with UPS on AeroGear.
>
>     On AS7 the application runs with no errors, but when I try to
>     deploy on
>     Wildfly I get HTTP 400 after login.
>
>     Probably is some misconfiguration on my end, but I already double
>     checked
>     project-integrations, checked the examples, tried to debug on
>     IntelliJ and
>     Chrome.
>
>     Here are the steps to reproduce:
>
>     git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
>     clean install -DskipTests=true -Dcheckstyle.skip=true
>     cd ..
>     git clone git at github.com:aerogear/aerogear-parent.git && cd
>     aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
>     cd ..
>     git clone git at github.com:aerogear/aerogear-unifiedpush-server.git
>     && cd
>     aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
>     install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
>
>     cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
>     cp auth-server/target/auth-server.war
>     $JBOSS_HOME/standalone/deployments/
>     cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
>
>     $JBOSS_HOME/bin/standalone.sh
>
>     If you have an idea, let me know.
>
>     --
>
>     abstractj
>     PGP: 0x84DC9914
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From bburke at redhat.com  Thu Jul 24 09:24:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 09:24:15 -0400
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
References: <20140724125738.GA96564@abstractj.org>
	<CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
Message-ID: <53D108FF.8070901@redhat.com>

This exception happens when you have an old cookie and it is expired or 
the realm's keys have changed.  Clear your persistent cookies and shut 
down your browser to remove session cookies.  Or, just put up with the 
message.

On 7/24/2014 9:21 AM, Ken Finnigan wrote:
> I think I've also seen that exception when using Keycloak in LiveOak on
> WildFly, but I believe it doesn't prevent anything from working, at
> least from the tests I've done.
>
> But it would be nice to know what's causing it.
>
> Ken
>
>
>
> On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>> wrote:
>
>     Good morning guys, I'm banging my head against the wall with this issue:
>     https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically
>     what I'm trying to
>     do is integrate the latest changes on master with UPS on AeroGear.
>
>     On AS7 the application runs with no errors, but when I try to deploy on
>     Wildfly I get HTTP 400 after login.
>
>     Probably is some misconfiguration on my end, but I already double
>     checked
>     project-integrations, checked the examples, tried to debug on
>     IntelliJ and
>     Chrome.
>
>     Here are the steps to reproduce:
>
>     git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
>     clean install -DskipTests=true -Dcheckstyle.skip=true
>     cd ..
>     git clone git at github.com:aerogear/aerogear-parent.git && cd
>     aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
>     cd ..
>     git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
>     aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
>     install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
>
>     cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
>     cp auth-server/target/auth-server.war
>     $JBOSS_HOME/standalone/deployments/
>     cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
>
>     $JBOSS_HOME/bin/standalone.sh
>
>     If you have an idea, let me know.
>
>     --
>
>     abstractj
>     PGP: 0x84DC9914
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Thu Jul 24 09:25:19 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 09:25:19 -0400 (EDT)
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D02A18.3060007@redhat.com>
References: <53D02A18.3060007@redhat.com>
Message-ID: <134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>

Looks good. Only two comments from me:

1. FederationManager.getFederationProvider uses factories directly

Why is this? This will cause the provider instance not to be registered with the session, so won't be closed automatically when the session is closed, nor will it be able to attach to the transaction.

2. TOTP SPI (just related)

Once I've finished access code work I was going to start on TOTP SPI. I think a UserProvider should only be able to verify password credentials, and TOTP providers should be used to verify TOTP. I'll send a separate email about this tomorrow so we can discuss it in more detail, just a heads up.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 23 July, 2014 10:33:12 PM
> Subject: [keycloak-dev] federation commited need feedback
> 
> First iteration is commited.  I still have a lot to do.
> 
> * AuthenticationProvider currently co-exists with Federation.  I will
> delete it after the review of FederationProvider.
> * UserModel is proxied.  Some updates delegated to LDAP.  Need to expand.
> * Still need to do admin console UI for federation
> * Still need to implement search and other queries for LDAP
> * Still need to test disjoint credential type storage.
> 
> Feedback on unimplemented features for LDAP:
> * registration supported switch.
> * Importing username and email will be required.  Everything else will
> be optional.  That cool?
> * Modes for federation will be:  READ_ONLY, SYNCED, and UNSYNCED.
> SYNCED will update LDAP on demand. UNSYNCED will store changes locally
> and require the user to handle synchronization themselves.
> * Going to have an import-attributes on/off switch.  A keycloak->ldap
> attribute map will be required to be configured.  If this switch is off,
> UserModel proxy will load attributes on demand.
> 
> 
> Questions:
> * Is ExternalModelAuthProvider actually a feature requested by users?
> I'd like to not have to do this.  At least for 1.0.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 24 09:27:18 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 09:27:18 -0400 (EDT)
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <53D108FF.8070901@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
	<53D108FF.8070901@redhat.com>
Message-ID: <916366031.17379168.1406208438755.JavaMail.zimbra@redhat.com>

If the realm's keys change should we not invalidate the cookies?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 2:24:15 PM
> Subject: Re: [keycloak-dev] Wildfly integration
> 
> This exception happens when you have an old cookie and it is expired or
> the realm's keys have changed.  Clear your persistent cookies and shut
> down your browser to remove session cookies.  Or, just put up with the
> message.
> 
> On 7/24/2014 9:21 AM, Ken Finnigan wrote:
> > I think I've also seen that exception when using Keycloak in LiveOak on
> > WildFly, but I believe it doesn't prevent anything from working, at
> > least from the tests I've done.
> >
> > But it would be nice to know what's causing it.
> >
> > Ken
> >
> >
> >
> > On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org
> > <mailto:bruno at abstractj.org>> wrote:
> >
> >     Good morning guys, I'm banging my head against the wall with this
> >     issue:
> >     https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically
> >     what I'm trying to
> >     do is integrate the latest changes on master with UPS on AeroGear.
> >
> >     On AS7 the application runs with no errors, but when I try to deploy on
> >     Wildfly I get HTTP 400 after login.
> >
> >     Probably is some misconfiguration on my end, but I already double
> >     checked
> >     project-integrations, checked the examples, tried to debug on
> >     IntelliJ and
> >     Chrome.
> >
> >     Here are the steps to reproduce:
> >
> >     git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> >     clean install -DskipTests=true -Dcheckstyle.skip=true
> >     cd ..
> >     git clone git at github.com:aerogear/aerogear-parent.git && cd
> >     aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> >     cd ..
> >     git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> >     aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> >     install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> >
> >     cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> >     cp auth-server/target/auth-server.war
> >     $JBOSS_HOME/standalone/deployments/
> >     cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> >
> >     $JBOSS_HOME/bin/standalone.sh
> >
> >     If you have an idea, let me know.
> >
> >     --
> >
> >     abstractj
> >     PGP: 0x84DC9914
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jul 24 09:47:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 09:47:57 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
Message-ID: <53D10E8D.4020207@redhat.com>



On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
> Looks good. Only two comments from me:
>
> 1. FederationManager.getFederationProvider uses factories directly
>
> Why is this? This will cause the provider instance not to be registered with the session, so won't be closed automatically when the session is closed, nor will it be able to attach to the transaction.
>

FederationProviders are not singletons within KeycloakSession like 
RealmProvider, UserProvider, and UserSessionProvider are.  You can have 
multiple FederationProvider instances per realm.


public interface FederationProviderFactory extends 
ProviderFactory<FederationProvider> {
     FederationProvider getInstance(KeycloakSession session, 
FederationProviderModel model);
}


FederationProviders implementations have the option to enlist themselves 
with the KeycloakSession transaction manager.  LDAP (really Picketlink) 
doesn't have the concept of a session or transaction, so it doesn't 
enlist itself.

I guess we do need a enlistForClose() method on KeycloakSession though.


> 2. TOTP SPI (just related)
>
> Once I've finished access code work I was going to start on TOTP SPI. I think a UserProvider should only be able to verify password credentials, and TOTP providers should be used to verify TOTP. I'll send a separate email about this tomorrow so we can discuss it in more detail, just a heads up.
>

UserProvider.validCredentials() should still continue to exist as the 
primary high-level call.  With federation, credential validation may be 
executed in different places (and even within non-Keycloak code) 
depending on the capabilities of the FederationProvider.

In fact, IMO, there should be no changes needed to any of our APIs/SPIs. 
  The CredentialValidation class is used by all UserProviders now and 
you can plug in any credential validation SPI you want there along with 
adding additional credential types to UserCredentialModel i.e. 
TOTP_GOOGLE, TOTP_FREEOTP

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

From bruno at abstractj.org  Thu Jul 24 09:49:47 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 24 Jul 2014 10:49:47 -0300
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <53D108FF.8070901@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
	<53D108FF.8070901@redhat.com>
Message-ID: <20140724134947.GA6885@abstractj.org>

Hi Bill, I did a full clean up and the shutdown on Chrome and Firefox,
HTTP 400 persists, now with no server side errors but the session is
still null take a look:
https://gist.github.com/anonymous/f8b58b93e478b5505db2#file-log-txt-L28



On 2014-07-24, Bill Burke wrote:
> This exception happens when you have an old cookie and it is expired or
> the realm's keys have changed.  Clear your persistent cookies and shut
> down your browser to remove session cookies.  Or, just put up with the
> message.
>
> On 7/24/2014 9:21 AM, Ken Finnigan wrote:
> > I think I've also seen that exception when using Keycloak in LiveOak on
> > WildFly, but I believe it doesn't prevent anything from working, at
> > least from the tests I've done.
> >
> > But it would be nice to know what's causing it.
> >
> > Ken
> >
> >
> >
> > On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org
> > <mailto:bruno at abstractj.org>> wrote:
> >
> >     Good morning guys, I'm banging my head against the wall with this issue:
> >     https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically
> >     what I'm trying to
> >     do is integrate the latest changes on master with UPS on AeroGear.
> >
> >     On AS7 the application runs with no errors, but when I try to deploy on
> >     Wildfly I get HTTP 400 after login.
> >
> >     Probably is some misconfiguration on my end, but I already double
> >     checked
> >     project-integrations, checked the examples, tried to debug on
> >     IntelliJ and
> >     Chrome.
> >
> >     Here are the steps to reproduce:
> >
> >     git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> >     clean install -DskipTests=true -Dcheckstyle.skip=true
> >     cd ..
> >     git clone git at github.com:aerogear/aerogear-parent.git && cd
> >     aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> >     cd ..
> >     git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> >     aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> >     install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> >
> >     cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> >     cp auth-server/target/auth-server.war
> >     $JBOSS_HOME/standalone/deployments/
> >     cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> >
> >     $JBOSS_HOME/bin/standalone.sh
> >
> >     If you have an idea, let me know.
> >
> >     --
> >
> >     abstractj
> >     PGP: 0x84DC9914
> >     _______________________________________________
> >     keycloak-dev mailing list
> >     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From bruno at abstractj.org  Thu Jul 24 09:51:02 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 24 Jul 2014 10:51:02 -0300
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <53D108D5.4020706@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<CAKeeVe7bjwWoaVvMUuhmTo1=9kWWoRzT+e3s__hk6Y2SsBy8ag@mail.gmail.com>
	<53D108D5.4020706@redhat.com>
Message-ID: <20140724135102.GB6885@abstractj.org>

Hi Stan, this is my json file
https://github.com/aerogear/aerogear-unifiedpush-server/blob/KeycloakBeta4/server/src/main/webapp/keycloak.json#L1


On 2014-07-24, Stan Silvert wrote:
> My guess is that something is wrong with your keycloak.json.
>
> On 7/24/2014 9:21 AM, Ken Finnigan wrote:
> >I think I've also seen that exception when using Keycloak in LiveOak on
> >WildFly, but I believe it doesn't prevent anything from working, at least
> >from the tests I've done.
> >
> >But it would be nice to know what's causing it.
> >
> >Ken
> >
> >
> >
> >On Thu, Jul 24, 2014 at 8:57 AM, Bruno Oliveira <bruno at abstractj.org
> ><mailto:bruno at abstractj.org>> wrote:
> >
> >    Good morning guys, I'm banging my head against the wall with this
> >    issue:
> >    https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically
> >    what I'm trying to
> >    do is integrate the latest changes on master with UPS on AeroGear.
> >
> >    On AS7 the application runs with no errors, but when I try to
> >    deploy on
> >    Wildfly I get HTTP 400 after login.
> >
> >    Probably is some misconfiguration on my end, but I already double
> >    checked
> >    project-integrations, checked the examples, tried to debug on
> >    IntelliJ and
> >    Chrome.
> >
> >    Here are the steps to reproduce:
> >
> >    git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> >    clean install -DskipTests=true -Dcheckstyle.skip=true
> >    cd ..
> >    git clone git at github.com:aerogear/aerogear-parent.git && cd
> >    aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> >    cd ..
> >    git clone git at github.com:aerogear/aerogear-unifiedpush-server.git
> >    && cd
> >    aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> >    install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> >
> >    cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> >    cp auth-server/target/auth-server.war
> >    $JBOSS_HOME/standalone/deployments/
> >    cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> >
> >    $JBOSS_HOME/bin/standalone.sh
> >
> >    If you have an idea, let me know.
> >
> >    --
> >
> >    abstractj
> >    PGP: 0x84DC9914
> >    _______________________________________________
> >    keycloak-dev mailing list
> >    keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >    https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> >_______________________________________________
> >keycloak-dev mailing list
> >keycloak-dev at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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


--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Thu Jul 24 10:32:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 10:32:15 -0400 (EDT)
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D10E8D.4020207@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
	<53D10E8D.4020207@redhat.com>
Message-ID: <1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 2:47:57 PM
> Subject: Re: [keycloak-dev] federation commited need feedback
> 
> 
> 
> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
> > Looks good. Only two comments from me:
> >
> > 1. FederationManager.getFederationProvider uses factories directly
> >
> > Why is this? This will cause the provider instance not to be registered
> > with the session, so won't be closed automatically when the session is
> > closed, nor will it be able to attach to the transaction.
> >
> 
> FederationProviders are not singletons within KeycloakSession like
> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
> multiple FederationProvider instances per realm.
> 
> 
> public interface FederationProviderFactory extends
> ProviderFactory<FederationProvider> {
>      FederationProvider getInstance(KeycloakSession session,
> FederationProviderModel model);
> }
> 
> 
> FederationProviders implementations have the option to enlist themselves
> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
> doesn't have the concept of a session or transaction, so it doesn't
> enlist itself.
> 
> I guess we do need a enlistForClose() method on KeycloakSession though.

As long as the lifespan of a FederationProvider is the same as the KeycloakSession they should be created through the KeycloakSession IMO. We just need to add an additional createProvider that can create a instance tied to a specific realm.

> 
> 
> > 2. TOTP SPI (just related)
> >
> > Once I've finished access code work I was going to start on TOTP SPI. I
> > think a UserProvider should only be able to verify password credentials,
> > and TOTP providers should be used to verify TOTP. I'll send a separate
> > email about this tomorrow so we can discuss it in more detail, just a
> > heads up.
> >
> 
> UserProvider.validCredentials() should still continue to exist as the
> primary high-level call.  With federation, credential validation may be
> executed in different places (and even within non-Keycloak code)
> depending on the capabilities of the FederationProvider.
> 
> In fact, IMO, there should be no changes needed to any of our APIs/SPIs.
>   The CredentialValidation class is used by all UserProviders now and
> you can plug in any credential validation SPI you want there along with
> adding additional credential types to UserCredentialModel i.e.
> TOTP_GOOGLE, TOTP_FREEOTP
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Thu Jul 24 10:52:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 10:52:48 -0400 (EDT)
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <20140724125738.GA96564@abstractj.org>
References: <20140724125738.GA96564@abstractj.org>
Message-ID: <1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>

Got the same issue here, looking into it now

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 24 July, 2014 1:57:38 PM
> Subject: [keycloak-dev] Wildfly integration
> 
> Good morning guys, I'm banging my head against the wall with this issue:
> https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm
> trying to
> do is integrate the latest changes on master with UPS on AeroGear.
> 
> On AS7 the application runs with no errors, but when I try to deploy on
> Wildfly I get HTTP 400 after login.
> 
> Probably is some misconfiguration on my end, but I already double checked
> project-integrations, checked the examples, tried to debug on IntelliJ and
> Chrome.
> 
> Here are the steps to reproduce:
> 
> git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> clean install -DskipTests=true -Dcheckstyle.skip=true
> cd ..
> git clone git at github.com:aerogear/aerogear-parent.git && cd
> aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> cd ..
> git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> 
> cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> cp auth-server/target/auth-server.war
> $JBOSS_HOME/standalone/deployments/
> cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> 
> $JBOSS_HOME/bin/standalone.sh
> 
> If you have an idea, let me know.
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jul 24 10:56:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 10:56:35 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
	<53D10E8D.4020207@redhat.com>
	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>
Message-ID: <53D11EA3.9090208@redhat.com>



On 7/24/2014 10:32 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 24 July, 2014 2:47:57 PM
>> Subject: Re: [keycloak-dev] federation commited need feedback
>>
>>
>>
>> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
>>> Looks good. Only two comments from me:
>>>
>>> 1. FederationManager.getFederationProvider uses factories directly
>>>
>>> Why is this? This will cause the provider instance not to be registered
>>> with the session, so won't be closed automatically when the session is
>>> closed, nor will it be able to attach to the transaction.
>>>
>>
>> FederationProviders are not singletons within KeycloakSession like
>> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
>> multiple FederationProvider instances per realm.
>>
>>
>> public interface FederationProviderFactory extends
>> ProviderFactory<FederationProvider> {
>>       FederationProvider getInstance(KeycloakSession session,
>> FederationProviderModel model);
>> }
>>
>>
>> FederationProviders implementations have the option to enlist themselves
>> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
>> doesn't have the concept of a session or transaction, so it doesn't
>> enlist itself.
>>
>> I guess we do need a enlistForClose() method on KeycloakSession though.
>
> As long as the lifespan of a FederationProvider is the same as the KeycloakSession they should be created through the KeycloakSession IMO. We just need to add an additional createProvider that can create a instance tied to a specific realm.
>

I disagree.  Its really up to the implementation on whether the provider 
is managed by KeycloakSession or not or whether its lifespan is tied to 
KeycloakSession or not.

We already manage transactions in this manner.  For example 
JpaUserProvider does not enlist its own KeycloakTransaction and its 
close() method is a no-op.  CacheUserProvider and JpaConnectionProvider 
enlist their own transaction objects manually.  JpaConnectionProvider's 
close() method actually does something.

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

From stian at redhat.com  Thu Jul 24 11:02:35 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 11:02:35 -0400 (EDT)
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D11EA3.9090208@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
	<53D10E8D.4020207@redhat.com>
	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>
	<53D11EA3.9090208@redhat.com>
Message-ID: <602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 3:56:35 PM
> Subject: Re: [keycloak-dev] federation commited need feedback
> 
> 
> 
> On 7/24/2014 10:32 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 24 July, 2014 2:47:57 PM
> >> Subject: Re: [keycloak-dev] federation commited need feedback
> >>
> >>
> >>
> >> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
> >>> Looks good. Only two comments from me:
> >>>
> >>> 1. FederationManager.getFederationProvider uses factories directly
> >>>
> >>> Why is this? This will cause the provider instance not to be registered
> >>> with the session, so won't be closed automatically when the session is
> >>> closed, nor will it be able to attach to the transaction.
> >>>
> >>
> >> FederationProviders are not singletons within KeycloakSession like
> >> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
> >> multiple FederationProvider instances per realm.
> >>
> >>
> >> public interface FederationProviderFactory extends
> >> ProviderFactory<FederationProvider> {
> >>       FederationProvider getInstance(KeycloakSession session,
> >> FederationProviderModel model);
> >> }
> >>
> >>
> >> FederationProviders implementations have the option to enlist themselves
> >> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
> >> doesn't have the concept of a session or transaction, so it doesn't
> >> enlist itself.
> >>
> >> I guess we do need a enlistForClose() method on KeycloakSession though.
> >
> > As long as the lifespan of a FederationProvider is the same as the
> > KeycloakSession they should be created through the KeycloakSession IMO. We
> > just need to add an additional createProvider that can create a instance
> > tied to a specific realm.
> >
> 
> I disagree.  Its really up to the implementation on whether the provider
> is managed by KeycloakSession or not or whether its lifespan is tied to
> KeycloakSession or not.
> 

Why would a provider not be tied to a session? IMO there should always be a session.

> We already manage transactions in this manner.  For example
> JpaUserProvider does not enlist its own KeycloakTransaction and its
> close() method is a no-op.  CacheUserProvider and JpaConnectionProvider
> enlist their own transaction objects manually.  JpaConnectionProvider's
> close() method actually does something.

Commit transactions and closing providers are tied to the session, that's the whole point. With your code you're creating providers that are never closed.

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

From bburke at redhat.com  Thu Jul 24 11:25:59 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 11:25:59 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
	<53D10E8D.4020207@redhat.com>
	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>
	<53D11EA3.9090208@redhat.com>
	<602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>
Message-ID: <53D12587.5070004@redhat.com>



On 7/24/2014 11:02 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 24 July, 2014 3:56:35 PM
>> Subject: Re: [keycloak-dev] federation commited need feedback
>>
>>
>>
>> On 7/24/2014 10:32 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 24 July, 2014 2:47:57 PM
>>>> Subject: Re: [keycloak-dev] federation commited need feedback
>>>>
>>>>
>>>>
>>>> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
>>>>> Looks good. Only two comments from me:
>>>>>
>>>>> 1. FederationManager.getFederationProvider uses factories directly
>>>>>
>>>>> Why is this? This will cause the provider instance not to be registered
>>>>> with the session, so won't be closed automatically when the session is
>>>>> closed, nor will it be able to attach to the transaction.
>>>>>
>>>>
>>>> FederationProviders are not singletons within KeycloakSession like
>>>> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
>>>> multiple FederationProvider instances per realm.
>>>>
>>>>
>>>> public interface FederationProviderFactory extends
>>>> ProviderFactory<FederationProvider> {
>>>>        FederationProvider getInstance(KeycloakSession session,
>>>> FederationProviderModel model);
>>>> }
>>>>
>>>>
>>>> FederationProviders implementations have the option to enlist themselves
>>>> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
>>>> doesn't have the concept of a session or transaction, so it doesn't
>>>> enlist itself.
>>>>
>>>> I guess we do need a enlistForClose() method on KeycloakSession though.
>>>
>>> As long as the lifespan of a FederationProvider is the same as the
>>> KeycloakSession they should be created through the KeycloakSession IMO. We
>>> just need to add an additional createProvider that can create a instance
>>> tied to a specific realm.
>>>
>>
>> I disagree.  Its really up to the implementation on whether the provider
>> is managed by KeycloakSession or not or whether its lifespan is tied to
>> KeycloakSession or not.
>>
>
> Why would a provider not be tied to a session? IMO there should always be a session.
>

It might be expensive to create the provider and/or the provider may 
have no concept of a session.  For example, Picketlink PartitionManagers 
are not tied to a KeycloakSession

>> We already manage transactions in this manner.  For example
>> JpaUserProvider does not enlist its own KeycloakTransaction and its
>> close() method is a no-op.  CacheUserProvider and JpaConnectionProvider
>> enlist their own transaction objects manually.  JpaConnectionProvider's
>> close() method actually does something.
>
> Commit transactions and closing providers are tied to the session, that's the whole point. With your code you're creating providers that are never closed.
>

Whether or not a transaction is enlisted is up to the implementation 
though.  Also different provider factories may have differing create() 
methods with different parameters, so it doesn't make sense for the 
KeycloakSession to manage Provider creation all the time.

FYI I added an "enlistForClose()" method to KeycloakSession.

>>
>> --
>> 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 stian at redhat.com  Thu Jul 24 11:36:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 11:36:58 -0400 (EDT)
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D12587.5070004@redhat.com>
References: <53D02A18.3060007@redhat.com>
	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>
	<53D10E8D.4020207@redhat.com>
	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>
	<53D11EA3.9090208@redhat.com>
	<602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>
	<53D12587.5070004@redhat.com>
Message-ID: <2011939160.17486850.1406216218412.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 4:25:59 PM
> Subject: Re: [keycloak-dev] federation commited need feedback
> 
> 
> 
> On 7/24/2014 11:02 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 24 July, 2014 3:56:35 PM
> >> Subject: Re: [keycloak-dev] federation commited need feedback
> >>
> >>
> >>
> >> On 7/24/2014 10:32 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, 24 July, 2014 2:47:57 PM
> >>>> Subject: Re: [keycloak-dev] federation commited need feedback
> >>>>
> >>>>
> >>>>
> >>>> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
> >>>>> Looks good. Only two comments from me:
> >>>>>
> >>>>> 1. FederationManager.getFederationProvider uses factories directly
> >>>>>
> >>>>> Why is this? This will cause the provider instance not to be registered
> >>>>> with the session, so won't be closed automatically when the session is
> >>>>> closed, nor will it be able to attach to the transaction.
> >>>>>
> >>>>
> >>>> FederationProviders are not singletons within KeycloakSession like
> >>>> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
> >>>> multiple FederationProvider instances per realm.
> >>>>
> >>>>
> >>>> public interface FederationProviderFactory extends
> >>>> ProviderFactory<FederationProvider> {
> >>>>        FederationProvider getInstance(KeycloakSession session,
> >>>> FederationProviderModel model);
> >>>> }
> >>>>
> >>>>
> >>>> FederationProviders implementations have the option to enlist themselves
> >>>> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
> >>>> doesn't have the concept of a session or transaction, so it doesn't
> >>>> enlist itself.
> >>>>
> >>>> I guess we do need a enlistForClose() method on KeycloakSession though.
> >>>
> >>> As long as the lifespan of a FederationProvider is the same as the
> >>> KeycloakSession they should be created through the KeycloakSession IMO.
> >>> We
> >>> just need to add an additional createProvider that can create a instance
> >>> tied to a specific realm.
> >>>
> >>
> >> I disagree.  Its really up to the implementation on whether the provider
> >> is managed by KeycloakSession or not or whether its lifespan is tied to
> >> KeycloakSession or not.
> >>
> >
> > Why would a provider not be tied to a session? IMO there should always be a
> > session.
> >
> 
> It might be expensive to create the provider and/or the provider may
> have no concept of a session.  For example, Picketlink PartitionManagers
> are not tied to a KeycloakSession

That's exactly why a ProviderFactory has application scope. Anything that is expensive to create should be stored in the ProviderFactory and reused in Provider instances.

For example JpaConnectionProviderFactory creates one EntityManagerFactory (which is expensive) and reuses it to create a EntityManager for each JpaConnectionProvider.

> 
> >> We already manage transactions in this manner.  For example
> >> JpaUserProvider does not enlist its own KeycloakTransaction and its
> >> close() method is a no-op.  CacheUserProvider and JpaConnectionProvider
> >> enlist their own transaction objects manually.  JpaConnectionProvider's
> >> close() method actually does something.
> >
> > Commit transactions and closing providers are tied to the session, that's
> > the whole point. With your code you're creating providers that are never
> > closed.
> >
> 
> Whether or not a transaction is enlisted is up to the implementation
> though.  Also different provider factories may have differing create()
> methods with different parameters, so it doesn't make sense for the
> KeycloakSession to manage Provider creation all the time.
> 
> FYI I added an "enlistForClose()" method to KeycloakSession.

Exactly, but that's what we already do with the transaction. The factory is responsible for enlisting it if it wants to.

See above - Provider instances should be created and closed per session, while factories can if they want reuse resources for multiple providers and then manage closing these itself.

> 
> >>
> >> --
> >> 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 stian at redhat.com  Thu Jul 24 12:30:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 24 Jul 2014 12:30:24 -0400 (EDT)
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
Message-ID: <1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>

The problem was down to the fact that the unified-push application wasn't set to bearer-only and Undertow seems to invoke the authentication mechanism even though it's a non-secured resource.

What happens in details are:

1. /index.html is loaded
2. keycloak.js redirects to login page
3. Keycloak returns ?code=...
4. Undertow invokes authentication mechanism (even though /index.html is not secured), sees the code, checks for a state cookie, doesn't find one, returns 400

One AS7 it works because AS7 doesn't invoke the authentication mechanism at all for /index.html (which seems the correct way to me, as the resource is not part of a secured-constraint).

Setting unified-push to bearerOnly (which it should be in any case as it's used for jax-rs endpoints) works around the issue as our Undertow adapter will only look for bearer token and not do anything else.

Question: is this a bug in Undertow? is it something we have to add a solution to our Undertow adapter?

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bruno Oliveira" <bruno at abstractj.org>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 24 July, 2014 3:52:48 PM
> Subject: Re: [keycloak-dev] Wildfly integration
> 
> Got the same issue here, looking into it now
> 
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Thursday, 24 July, 2014 1:57:38 PM
> > Subject: [keycloak-dev] Wildfly integration
> > 
> > Good morning guys, I'm banging my head against the wall with this issue:
> > https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm
> > trying to
> > do is integrate the latest changes on master with UPS on AeroGear.
> > 
> > On AS7 the application runs with no errors, but when I try to deploy on
> > Wildfly I get HTTP 400 after login.
> > 
> > Probably is some misconfiguration on my end, but I already double checked
> > project-integrations, checked the examples, tried to debug on IntelliJ and
> > Chrome.
> > 
> > Here are the steps to reproduce:
> > 
> > git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> > clean install -DskipTests=true -Dcheckstyle.skip=true
> > cd ..
> > git clone git at github.com:aerogear/aerogear-parent.git && cd
> > aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> > cd ..
> > git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> > aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> > install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> > 
> > cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> > cp auth-server/target/auth-server.war
> > $JBOSS_HOME/standalone/deployments/
> > cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> > 
> > $JBOSS_HOME/bin/standalone.sh
> > 
> > If you have an idea, let me know.
> > 
> > --
> > 
> > abstractj
> > PGP: 0x84DC9914
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Jul 24 12:49:22 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 12:49:22 -0400
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
References: <20140724125738.GA96564@abstractj.org>	<1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
	<1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
Message-ID: <53D13912.9080203@redhat.com>

What version of Wildfly?  The Undertow auth should not be called for non 
secured URLs.

On 7/24/2014 12:30 PM, Stian Thorgersen wrote:
> The problem was down to the fact that the unified-push application wasn't set to bearer-only and Undertow seems to invoke the authentication mechanism even though it's a non-secured resource.
>
> What happens in details are:
>
> 1. /index.html is loaded
> 2. keycloak.js redirects to login page
> 3. Keycloak returns ?code=...
> 4. Undertow invokes authentication mechanism (even though /index.html is not secured), sees the code, checks for a state cookie, doesn't find one, returns 400
>
> One AS7 it works because AS7 doesn't invoke the authentication mechanism at all for /index.html (which seems the correct way to me, as the resource is not part of a secured-constraint).
>
> Setting unified-push to bearerOnly (which it should be in any case as it's used for jax-rs endpoints) works around the issue as our Undertow adapter will only look for bearer token and not do anything else.
>
> Question: is this a bug in Undertow? is it something we have to add a solution to our Undertow adapter?
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "Bruno Oliveira" <bruno at abstractj.org>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Thursday, 24 July, 2014 3:52:48 PM
>> Subject: Re: [keycloak-dev] Wildfly integration
>>
>> Got the same issue here, looking into it now
>>
>> ----- Original Message -----
>>> From: "Bruno Oliveira" <bruno at abstractj.org>
>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Thursday, 24 July, 2014 1:57:38 PM
>>> Subject: [keycloak-dev] Wildfly integration
>>>
>>> Good morning guys, I'm banging my head against the wall with this issue:
>>> https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm
>>> trying to
>>> do is integrate the latest changes on master with UPS on AeroGear.
>>>
>>> On AS7 the application runs with no errors, but when I try to deploy on
>>> Wildfly I get HTTP 400 after login.
>>>
>>> Probably is some misconfiguration on my end, but I already double checked
>>> project-integrations, checked the examples, tried to debug on IntelliJ and
>>> Chrome.
>>>
>>> Here are the steps to reproduce:
>>>
>>> git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
>>> clean install -DskipTests=true -Dcheckstyle.skip=true
>>> cd ..
>>> git clone git at github.com:aerogear/aerogear-parent.git && cd
>>> aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
>>> cd ..
>>> git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
>>> aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
>>> install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
>>>
>>> cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
>>> cp auth-server/target/auth-server.war
>>> $JBOSS_HOME/standalone/deployments/
>>> cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
>>>
>>> $JBOSS_HOME/bin/standalone.sh
>>>
>>> If you have an idea, let me know.
>>>
>>> --
>>>
>>> abstractj
>>> PGP: 0x84DC9914
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> 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  Thu Jul 24 13:09:19 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 24 Jul 2014 14:09:19 -0300
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <53D13912.9080203@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
	<1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
	<53D13912.9080203@redhat.com>
Message-ID: <20140724170919.GA25297@abstractj.org>

Hi Bill, Wildfly 8.0.0 Final

On 2014-07-24, Bill Burke wrote:
> What version of Wildfly?  The Undertow auth should not be called for non
> secured URLs.
>
> On 7/24/2014 12:30 PM, Stian Thorgersen wrote:
> > The problem was down to the fact that the unified-push application wasn't set to bearer-only and Undertow seems to invoke the authentication mechanism even though it's a non-secured resource.
> >
> > What happens in details are:
> >
> > 1. /index.html is loaded
> > 2. keycloak.js redirects to login page
> > 3. Keycloak returns ?code=...
> > 4. Undertow invokes authentication mechanism (even though /index.html is not secured), sees the code, checks for a state cookie, doesn't find one, returns 400
> >
> > One AS7 it works because AS7 doesn't invoke the authentication mechanism at all for /index.html (which seems the correct way to me, as the resource is not part of a secured-constraint).
> >
> > Setting unified-push to bearerOnly (which it should be in any case as it's used for jax-rs endpoints) works around the issue as our Undertow adapter will only look for bearer token and not do anything else.
> >
> > Question: is this a bug in Undertow? is it something we have to add a solution to our Undertow adapter?
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bruno Oliveira" <bruno at abstractj.org>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, 24 July, 2014 3:52:48 PM
> >> Subject: Re: [keycloak-dev] Wildfly integration
> >>
> >> Got the same issue here, looking into it now
> >>
> >> ----- Original Message -----
> >>> From: "Bruno Oliveira" <bruno at abstractj.org>
> >>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Thursday, 24 July, 2014 1:57:38 PM
> >>> Subject: [keycloak-dev] Wildfly integration
> >>>
> >>> Good morning guys, I'm banging my head against the wall with this issue:
> >>> https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm
> >>> trying to
> >>> do is integrate the latest changes on master with UPS on AeroGear.
> >>>
> >>> On AS7 the application runs with no errors, but when I try to deploy on
> >>> Wildfly I get HTTP 400 after login.
> >>>
> >>> Probably is some misconfiguration on my end, but I already double checked
> >>> project-integrations, checked the examples, tried to debug on IntelliJ and
> >>> Chrome.
> >>>
> >>> Here are the steps to reproduce:
> >>>
> >>> git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> >>> clean install -DskipTests=true -Dcheckstyle.skip=true
> >>> cd ..
> >>> git clone git at github.com:aerogear/aerogear-parent.git && cd
> >>> aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> >>> cd ..
> >>> git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> >>> aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> >>> install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> >>>
> >>> cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> >>> cp auth-server/target/auth-server.war
> >>> $JBOSS_HOME/standalone/deployments/
> >>> cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> >>>
> >>> $JBOSS_HOME/bin/standalone.sh
> >>>
> >>> If you have an idea, let me know.
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> PGP: 0x84DC9914
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > 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
PGP: 0x84DC9914

From mposolda at redhat.com  Thu Jul 24 13:42:58 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Jul 2014 19:42:58 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <2011939160.17486850.1406216218412.JavaMail.zimbra@redhat.com>
References: <53D02A18.3060007@redhat.com>	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>	<53D10E8D.4020207@redhat.com>	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>	<53D11EA3.9090208@redhat.com>	<602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>	<53D12587.5070004@redhat.com>
	<2011939160.17486850.1406216218412.JavaMail.zimbra@redhat.com>
Message-ID: <53D145A2.1050606@redhat.com>

On 24.7.2014 17:36, Stian Thorgersen wrote:
>>> Why would a provider not be tied to a session? IMO there should always be a
>>> > >session.
>>> > >
>> >
>> >It might be expensive to create the provider and/or the provider may
>> >have no concept of a session.  For example, Picketlink PartitionManagers
>> >are not tied to a KeycloakSession
> That's exactly why a ProviderFactory has application scope. Anything that is expensive to create should be stored in the ProviderFactory and reused in Provider instances.
>
> For example JpaConnectionProviderFactory creates one EntityManagerFactory (which is expensive) and reuses it to create a EntityManager for each JpaConnectionProvider.
>
IMO we need something like "global" providers or "global" components. 
Right now just ProviderFactories are supposed to be global (application 
scoped) and providers are supposed to be session scoped, but there may 
be usecases for having "global" component, which is itself not 
ProviderFactory.

Usually it's needed when the component itself needs access to 
KeycloakSessionFactory because it needs to perform some long-running 
task, when it manages multiple session/transaction lifecycles. Example 
is export/import (or in the future ChronJob for sync many thousand users 
from LDAP to local store)

Right now what I am doing for export/import is creating session just for 
retrieving ExportProvider or ImportProvider and then particular 
ExportProvider or ImportProvider is starting it's own 
session/transaction lifecycles whenever it needs them - 
https://github.com/keycloak/keycloak/blob/master/export-import/export-import-api/src/main/java/org/keycloak/exportimport/ExportImportManager.java#L34 
. It's kind of a hack IMO...

Maybe we can have concept of multiple transactions per single 
KeycloakSession (for example JPA supports multiple transactions per 
single EntityManager but not sure if it doesn't have performance 
penalties as some objects are cached per EntityManager etc)


Not sure what is best solution for this, but I wonder if we have Spi for 
"global" components, ie. something like this on KeycloakSessionFactory:

<T extends GlobalProvider> T getGlobalProvider(Class<T> clazz);
<T extends GlobalProvider> T getGlobalProvider(Class<T> clazz, String id);


And GlobalProvider itself will have method for injecting 
KeycloakSessionFactory:

public interface GlobalProvider {

   public void setKeycloakSessionFactory(KeycloakSessionFactory 
sessionFactory);
   public void init(Config.Scope config);
   public void close();
   public String getId();

}

Marek

From mposolda at redhat.com  Thu Jul 24 13:51:15 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 24 Jul 2014 19:51:15 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D10861.10709@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com>
Message-ID: <53D14793.4030406@redhat.com>

On 24.7.2014 15:21, Bill Burke wrote:
>
>
> On 7/24/2014 5:31 AM, Marek Posolda wrote:
>> Great stuff, some feedback inline
>>
>> On 23.7.2014 23:33, Bill Burke wrote:
>>> First iteration is commited.  I still have a lot to do.
>>>
>>> * AuthenticationProvider currently co-exists with Federation. I will
>>> delete it after the review of FederationProvider.
>>> * UserModel is proxied.  Some updates delegated to LDAP.  Need to 
>>> expand.
>>> * Still need to do admin console UI for federation
>>> * Still need to implement search and other queries for LDAP
>>> * Still need to test disjoint credential type storage.
>>>
>>> Feedback on unimplemented features for LDAP:
>>> * registration supported switch.
>>> * Importing username and email will be required.  Everything else will
>>> be optional.  That cool?
>> yeah. Not directly related but I wonder if federationLink on UserModel
>> is sufficient? For example if user "john" is deleted in LDAP and then
>> user with same username "john" is added again to LDAP, it's defacto
>> different user but the Keycloak user "john" will be linked to the "new"
>> LDAP john. Hence AuthLinkModel had link to provider and also uuid of
>> user from LDAP.
>
> This is an implementation detail and shouldn't really be exposed 
> through the Model API.
Ok, but how you would handle the case when user "john" is deleted in 
LDAP and then different user with same username "john" created again? 
Current LDAPFederationProvider will treat them in Keycloak as same user 
even if they are not.
>
>>> * Modes for federation will be: READ_ONLY, SYNCED, and UNSYNCED.
>>> SYNCED will update LDAP on demand. UNSYNCED will store changes locally
>>> and require the user to handle synchronization themselves.
>> Is it some difference between READ_ONLY and UNSYNCED? Wonder if 2 modes
>> are sufficient for federation and users are free to choose if they
>> handle synchronization or not? Am I understand correctly that this is
>> just for sync from Keycloak back to LDAP?
>
>
> SYNCED means LDAP is writable and there will be on-demand updates back 
> to LDAP.
>
> UNSYNCED is when LDAP is read-only but you want to be able to manage 
> the user anyways:  update their credentials, address, etc.
>
> READ-ONLY doesn't allow any changes to user.
>
>>> * Going to have an import-attributes on/off switch.  A keycloak->ldap
>>> attribute map will be required to be configured.  If this switch is 
>>> off,
>>> UserModel proxy will load attributes on demand.
>>>
>>>
>>> Questions:
>>> * Is ExternalModelAuthProvider actually a feature requested by users?
>>> I'd like to not have to do this.  At least for 1.0.
>> Probably not needed AFAIK.
>>
>> Sorry to repeat, but I still have some doubts especially about bulk
>> search methods. Example of some corner cases:
>>
>> * If there are 2 federation providers and firstResult==0, maxResults==10
>> and each provider has 10 users, then due to this
>> https://github.com/keycloak/keycloak/blob/master/model/api/src/main/java/org/keycloak/models/FederationManager.java#L193 
>>
>> it may be 20 users in final list (even if maxResults is 10)
>>
>> * If there are 10 users "locally" and 10 completely different users in
>> LDAP, and firstResult ==0, maxResults==10 then it will return 10 "local"
>> users. Now you want next page so next query will be firstResult==10,
>> maxResults==10 . This should return 10 users from LDAP, but actually it
>> won't return any user as LDAP query will have firstResult==10,
>> maxResults==10, but there are just 10 users in LDAP
>>
>
> I haven't actually tested or even executed searches yet.  Thanks for 
> pointing outthe bugs.
I don't know if bug is correct word. IMO Federation+pagination can't 
never properly work (without syncing all LDAP users into local storage 
first). I would be happy if I am wrong:-)

Marek
>
>> * In some cases it may happen the opposite . Like you have user "john"
>> in both LDAP and local store. Page1 will return 10 local users with
>> "john" between them. Page2 will query LDAP and it may also return "john"
>> between them (the case when "john" is on page1 in "local" store but on
>> page2 on LDAP store)
>>
>>
>> Right now, I am looking at changelog stuff, which is supported by
>> ActiveDirectory but not by some other LDAP servers. Right now I am
>> working with Keycloak on latest Picketlink master, which helped to
>> remove ActiveDirectory workarounds needed in
>> LDAPKeycloakCredentialHandler and KeycloakLDAPIdentityStore . I will
>> also possibly send more PRs to picketlink with missing features
>> regarding changelog and pagination .
>>
>
> FYI, I forked the picketlink code under federation/ldap.  Mainly to 
> keep AuthProvider stuff alive and working until the switch is ready.
>
>


From bruno at abstractj.org  Thu Jul 24 14:07:16 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 24 Jul 2014 15:07:16 -0300
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
	<1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
Message-ID: <20140724180716.GB25297@abstractj.org>

Thank you guys, the latest changes on UPS fixed the issue.

On 2014-07-24, Stian Thorgersen wrote:
> The problem was down to the fact that the unified-push application wasn't set to bearer-only and Undertow seems to invoke the authentication mechanism even though it's a non-secured resource.
>
> What happens in details are:
>
> 1. /index.html is loaded
> 2. keycloak.js redirects to login page
> 3. Keycloak returns ?code=...
> 4. Undertow invokes authentication mechanism (even though /index.html is not secured), sees the code, checks for a state cookie, doesn't find one, returns 400
>
> One AS7 it works because AS7 doesn't invoke the authentication mechanism at all for /index.html (which seems the correct way to me, as the resource is not part of a secured-constraint).
>
> Setting unified-push to bearerOnly (which it should be in any case as it's used for jax-rs endpoints) works around the issue as our Undertow adapter will only look for bearer token and not do anything else.
>
> Question: is this a bug in Undertow? is it something we have to add a solution to our Undertow adapter?
>
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Bruno Oliveira" <bruno at abstractj.org>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Thursday, 24 July, 2014 3:52:48 PM
> > Subject: Re: [keycloak-dev] Wildfly integration
> >
> > Got the same issue here, looking into it now
> >
> > ----- Original Message -----
> > > From: "Bruno Oliveira" <bruno at abstractj.org>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Thursday, 24 July, 2014 1:57:38 PM
> > > Subject: [keycloak-dev] Wildfly integration
> > >
> > > Good morning guys, I'm banging my head against the wall with this issue:
> > > https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what I'm
> > > trying to
> > > do is integrate the latest changes on master with UPS on AeroGear.
> > >
> > > On AS7 the application runs with no errors, but when I try to deploy on
> > > Wildfly I get HTTP 400 after login.
> > >
> > > Probably is some misconfiguration on my end, but I already double checked
> > > project-integrations, checked the examples, tried to debug on IntelliJ and
> > > Chrome.
> > >
> > > Here are the steps to reproduce:
> > >
> > > git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> > > clean install -DskipTests=true -Dcheckstyle.skip=true
> > > cd ..
> > > git clone git at github.com:aerogear/aerogear-parent.git && cd
> > > aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> > > cd ..
> > > git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> > > aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> > > install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> > >
> > > cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> > > cp auth-server/target/auth-server.war
> > > $JBOSS_HOME/standalone/deployments/
> > > cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> > >
> > > $JBOSS_HOME/bin/standalone.sh
> > >
> > > If you have an idea, let me know.
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Thu Jul 24 14:59:38 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 14:59:38 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D14793.4030406@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
Message-ID: <53D1579A.4000507@redhat.com>



On 7/24/2014 1:51 PM, Marek Posolda wrote:
> On 24.7.2014 15:21, Bill Burke wrote:
>>
>>
>> On 7/24/2014 5:31 AM, Marek Posolda wrote:
>>> Great stuff, some feedback inline
>>>
>>> On 23.7.2014 23:33, Bill Burke wrote:
>>>> First iteration is commited.  I still have a lot to do.
>>>>
>>>> * AuthenticationProvider currently co-exists with Federation. I will
>>>> delete it after the review of FederationProvider.
>>>> * UserModel is proxied.  Some updates delegated to LDAP.  Need to
>>>> expand.
>>>> * Still need to do admin console UI for federation
>>>> * Still need to implement search and other queries for LDAP
>>>> * Still need to test disjoint credential type storage.
>>>>
>>>> Feedback on unimplemented features for LDAP:
>>>> * registration supported switch.
>>>> * Importing username and email will be required.  Everything else will
>>>> be optional.  That cool?
>>> yeah. Not directly related but I wonder if federationLink on UserModel
>>> is sufficient? For example if user "john" is deleted in LDAP and then
>>> user with same username "john" is added again to LDAP, it's defacto
>>> different user but the Keycloak user "john" will be linked to the "new"
>>> LDAP john. Hence AuthLinkModel had link to provider and also uuid of
>>> user from LDAP.
>>
>> This is an implementation detail and shouldn't really be exposed
>> through the Model API.
> Ok, but how you would handle the case when user "john" is deleted in
> LDAP and then different user with same username "john" created again?
> Current LDAPFederationProvider will treat them in Keycloak as same user
> even if they are not.

So, you're saying we're supposed to check and verify with the LDAP 
server every time the UserModel is referenced to make sure the uid 
hasn't changed since the last time we accessed it?  In your current 
implementation you only do this when validating password or updating the 
credential.

FYI, if this happens with the AuthenticationProvider, that particular 
user is hosed and can never log in again.  The user needs to be deleted 
if this occurs (probably in a separate transaction).



>> I haven't actually tested or even executed searches yet.  Thanks for
>> pointing outthe bugs.
> I don't know if bug is correct word. IMO Federation+pagination can't
> never properly work (without syncing all LDAP users into local storage
> first). I would be happy if I am wrong:-)
>

You're right.  The API would have to change to note the provider that 
was last used and how many were consumed for that provider.

class Result {

    List<UserModel> results;

    String lastProvider;
    int lastIndex;

}

then UserProvider search would need these methods:

Result search(criteria..., int maxResults);  // start from beginning
Result search(criteria..., String lastProvider, int lastIndex, int 
maxResults);

As a side effect of this, I don't think FederationProvider extending 
UserProvider is going to work anymore. There were already some add 
methods that didn't make sense and would never be called.  Now 
pagination needs a different API between UserProvider and 
FederationProvider.

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

From bburke at redhat.com  Thu Jul 24 15:13:06 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 15:13:06 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D145A2.1050606@redhat.com>
References: <53D02A18.3060007@redhat.com>	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>	<53D10E8D.4020207@redhat.com>	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>	<53D11EA3.9090208@redhat.com>	<602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>	<53D12587.5070004@redhat.com>
	<2011939160.17486850.1406216218412.JavaMail.zimbra@redhat.com>
	<53D145A2.1050606@redhat.com>
Message-ID: <53D15AC2.6090707@redhat.com>



On 7/24/2014 1:42 PM, Marek Posolda wrote:
> Right now what I am doing for export/import is creating session just for
> retrieving ExportProvider or ImportProvider and then particular
> ExportProvider or ImportProvider is starting it's own
> session/transaction lifecycles whenever it needs them -
> https://github.com/keycloak/keycloak/blob/master/export-import/export-import-api/src/main/java/org/keycloak/exportimport/ExportImportManager.java#L34
> . It's kind of a hack IMO...
>

KeycloakSessionFactory now has:

     <T extends Provider> ProviderFactory<T> getProviderFactory(Class<T> 
clazz);
     <T extends Provider> ProviderFactory<T> getProviderFactory(Class<T> 
clazz, String id);

So you could use them instead of creating a session.   Maybe there 
should be a separate FactoryFinder interface? If you want to pull those 
methods into a FactoryFinder interface I guess that could be done.

Honestly, I don't understand why we need all these component layers for 
export/import.  Seems a bit over-engineered in that regards, IMO, and 
now you want to add even more component layers to manage something that 
should be pretty straightforward.


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

From bburke at redhat.com  Thu Jul 24 19:55:19 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 19:55:19 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D02A18.3060007@redhat.com>
References: <53D02A18.3060007@redhat.com>
Message-ID: <53D19CE7.3060004@redhat.com>



On 7/23/2014 5:33 PM, Bill Burke wrote:
> * Going to have an import-attributes on/off switch.  A keycloak->ldap
> attribute map will be required to be configured.  If this switch is off,
> UserModel proxy will load attributes on demand.


I'm not going to do anything with attributes that doesn't already exist. 
  Picketlink requires property mappings to actual properties on an 
actual class (User).  Our LDAP federation will be a bit limited :( 
Hopefully what we have is good enough.  We can look at improving this 
after 1.0.Final.  Honestly I'd just like to write our own LDAP 
abstraction.  Once users start wanting to deal with claims, there's 
going to be some stored in LDAP some stored in our store.  Picketlink 
just can handle this scenario dynamically.  Everything must be 
statically defined in a Java class and mapped with annotations.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Jul 24 21:33:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 24 Jul 2014 21:33:31 -0400
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D19CE7.3060004@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D19CE7.3060004@redhat.com>
Message-ID: <53D1B3EB.90600@redhat.com>



On 7/24/2014 7:55 PM, Bill Burke wrote:
>
>
> On 7/23/2014 5:33 PM, Bill Burke wrote:
>> * Going to have an import-attributes on/off switch.  A keycloak->ldap
>> attribute map will be required to be configured.  If this switch is off,
>> UserModel proxy will load attributes on demand.
>
>
> I'm not going to do anything with attributes that doesn't already exist.
>    Picketlink requires property mappings to actual properties on an
> actual class (User).  Our LDAP federation will be a bit limited :(
> Hopefully what we have is good enough.  We can look at improving this
> after 1.0.Final.  Honestly I'd just like to write our own LDAP
> abstraction.  Once users start wanting to deal with claims, there's
> going to be some stored in LDAP some stored in our store.  Picketlink
> just can handle this scenario dynamically.  Everything must be
> statically defined in a Java class and mapped with annotations.
>

Correction: Picketlink just *cannot* handle dynamic things.

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

From mposolda at redhat.com  Fri Jul 25 03:20:48 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 25 Jul 2014 09:20:48 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D1579A.4000507@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com>
Message-ID: <53D20550.1070802@redhat.com>

On 24.7.2014 20:59, Bill Burke wrote:
>
>
> On 7/24/2014 1:51 PM, Marek Posolda wrote:
>> On 24.7.2014 15:21, Bill Burke wrote:
>>>
>>>
>>> On 7/24/2014 5:31 AM, Marek Posolda wrote:
>>>> Great stuff, some feedback inline
>>>>
>>>> On 23.7.2014 23:33, Bill Burke wrote:
>>>>> First iteration is commited.  I still have a lot to do.
>>>>>
>>>>> * AuthenticationProvider currently co-exists with Federation. I will
>>>>> delete it after the review of FederationProvider.
>>>>> * UserModel is proxied.  Some updates delegated to LDAP. Need to
>>>>> expand.
>>>>> * Still need to do admin console UI for federation
>>>>> * Still need to implement search and other queries for LDAP
>>>>> * Still need to test disjoint credential type storage.
>>>>>
>>>>> Feedback on unimplemented features for LDAP:
>>>>> * registration supported switch.
>>>>> * Importing username and email will be required. Everything else will
>>>>> be optional.  That cool?
>>>> yeah. Not directly related but I wonder if federationLink on UserModel
>>>> is sufficient? For example if user "john" is deleted in LDAP and then
>>>> user with same username "john" is added again to LDAP, it's defacto
>>>> different user but the Keycloak user "john" will be linked to the 
>>>> "new"
>>>> LDAP john. Hence AuthLinkModel had link to provider and also uuid of
>>>> user from LDAP.
>>>
>>> This is an implementation detail and shouldn't really be exposed
>>> through the Model API.
>> Ok, but how you would handle the case when user "john" is deleted in
>> LDAP and then different user with same username "john" created again?
>> Current LDAPFederationProvider will treat them in Keycloak as same user
>> even if they are not.
>
> So, you're saying we're supposed to check and verify with the LDAP 
> server every time the UserModel is referenced to make sure the uid 
> hasn't changed since the last time we accessed it? 
I would say yes if we want to do it properly? I am not sure how big 
issue is it, fact is that if someone with admin access to LDAP server 
(and without admin access to Keycloak) can delete user and then recreate 
same user in LDAP just with different password, he would then be able to 
login to Keycloak with this new password. But maybe it's extreme case? I 
am not sure...

> In your current implementation you only do this when validating 
> password or updating the credential.
yep, as AuthenticationProvider was supposed to handle just 
validating/updating credentials or just initially registering users . If 
UserModel.setFirstName etc. is called, the UserModel is updated just 
locally. It was supposed to be sync SPI to handle periodic updates 
to/from LDAP.
>
> FYI, if this happens with the AuthenticationProvider, that particular 
> user is hosed and can never log in again.  The user needs to be 
> deleted if this occurs (probably in a separate transaction).
yes, also the case when user is just deleted directly in LDAP (not 
through Keycloak) could happen IMO as for example Windows domain admins 
are supposed to edit ActiveDirectory LDAP directly IMO. In this case 
linked Keycloak user should be likely deleted? I've noticed that you are 
throwing IllegalStateException in LDAPUserModelDelegate... Maybe it's 
sufficient to have it like this and handle direct LDAP removals just 
with periodic sync?

I don't know, there are quite many corner cases here:-)
>
>
>>> I haven't actually tested or even executed searches yet.  Thanks for
>>> pointing outthe bugs.
>> I don't know if bug is correct word. IMO Federation+pagination can't
>> never properly work (without syncing all LDAP users into local storage
>> first). I would be happy if I am wrong:-)
>>
>
> You're right.  The API would have to change to note the provider that 
> was last used and how many were consumed for that provider.
>
> class Result {
>
>    List<UserModel> results;
>
>    String lastProvider;
>    int lastIndex;
>
> }
>
> then UserProvider search would need these methods:
>
> Result search(criteria..., int maxResults);  // start from beginning
> Result search(criteria..., String lastProvider, int lastIndex, int 
> maxResults);
Sorry, I still have doubts;-)

For example there are 10 users in Keycloak and just 5 of them are mapped 
to LDAP. In LDAP there are just those 5 users. Then you want to search 
for page1 with (lastIndex 0, maxResults 10) and you will retrieve those 
10 Keycloak Users. Then you want page2, so you call (lastIndex 10, 
maxResults 10) and now you retrieve those 5 users from LDAP, but those 
are same users, which were already retrieved on page1.

Marek
>
> As a side effect of this, I don't think FederationProvider extending 
> UserProvider is going to work anymore. There were already some add 
> methods that didn't make sense and would never be called.  Now 
> pagination needs a different API between UserProvider and 
> FederationProvider.
>


From mposolda at redhat.com  Fri Jul 25 03:41:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 25 Jul 2014 09:41:45 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D15AC2.6090707@redhat.com>
References: <53D02A18.3060007@redhat.com>	<134449705.17377133.1406208319187.JavaMail.zimbra@redhat.com>	<53D10E8D.4020207@redhat.com>	<1415296697.17428235.1406212335927.JavaMail.zimbra@redhat.com>	<53D11EA3.9090208@redhat.com>	<602081466.17466744.1406214155626.JavaMail.zimbra@redhat.com>	<53D12587.5070004@redhat.com>
	<2011939160.17486850.1406216218412.JavaMail.zimbra@redhat.com>
	<53D145A2.1050606@redhat.com> <53D15AC2.6090707@redhat.com>
Message-ID: <53D20A39.3000108@redhat.com>

On 24.7.2014 21:13, Bill Burke wrote:
>
>
> On 7/24/2014 1:42 PM, Marek Posolda wrote:
>> Right now what I am doing for export/import is creating session just for
>> retrieving ExportProvider or ImportProvider and then particular
>> ExportProvider or ImportProvider is starting it's own
>> session/transaction lifecycles whenever it needs them -
>> https://github.com/keycloak/keycloak/blob/master/export-import/export-import-api/src/main/java/org/keycloak/exportimport/ExportImportManager.java#L34 
>>
>> . It's kind of a hack IMO...
>>
>
> KeycloakSessionFactory now has:
>
>     <T extends Provider> ProviderFactory<T> 
> getProviderFactory(Class<T> clazz);
>     <T extends Provider> ProviderFactory<T> 
> getProviderFactory(Class<T> clazz, String id);
>
> So you could use them instead of creating a session.
yes, however ProviderFactory has "create" method, which wants 
KeycloakSession... IMO couple ProviderFactory/Provider works well for 
providers, which are supposed to be session scoped. For application 
scoped providers, which doesn't need KeycloakSession, it would work 
better if these can be retrieved directly from KeycloakSessionFactory 
and there is not couple but just "global provider" like this:


public interface GlobalProvider {

   public void init(Config.Scope config, KeycloakSessionFactory 
sessionFactory);
   public void close();
   public String getId();

}


Some other example from current code is TimerProvider, which actually 
creates KeycloakSession just for the purpose of retrieve the current 
instance of TimerProvider: 
https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/KeycloakApplication.java#L147 
. This is similar case as IMO TimerProvider component is not supposed to 
be session scoped but application scoped.
> Maybe there should be a separate FactoryFinder interface? If you want 
> to pull those methods into a FactoryFinder interface I guess that 
> could be done.
>
> Honestly, I don't understand why we need all these component layers 
> for export/import.  Seems a bit over-engineered in that regards, IMO, 
> and now you want to add even more component layers to manage something 
> that should be pretty straightforward.
Actually I want that to be simpler instead:-)
Instead of ProviderFactory/Provider couple, it would need just single 
GlobalProvider to avoid boilerplate code needed for ProviderFactory and 
creating KeycloakSession instance just for retrieve Provider.

Actually export/import supports exporting to zip, single JSON file or 
directory and it suits well to handle it with different providers IMO.

Marek


From mposolda at redhat.com  Fri Jul 25 04:01:31 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 25 Jul 2014 10:01:31 +0200
Subject: [keycloak-dev] federation commited need feedback
In-Reply-To: <53D1B3EB.90600@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D19CE7.3060004@redhat.com>
	<53D1B3EB.90600@redhat.com>
Message-ID: <53D20EDB.7030203@redhat.com>

yeah, would be nice if Picketlink can support this and I think it's not 
so big problem to implement that. I've created JIRA 
https://issues.jboss.org/browse/PLINK-533 .

I believe that now it's good time to fill potential gaps in Picketlink .

Marek

On 25.7.2014 03:33, Bill Burke wrote:
>
> On 7/24/2014 7:55 PM, Bill Burke wrote:
>>
>> On 7/23/2014 5:33 PM, Bill Burke wrote:
>>> * Going to have an import-attributes on/off switch.  A keycloak->ldap
>>> attribute map will be required to be configured.  If this switch is off,
>>> UserModel proxy will load attributes on demand.
>>
>> I'm not going to do anything with attributes that doesn't already exist.
>>     Picketlink requires property mappings to actual properties on an
>> actual class (User).  Our LDAP federation will be a bit limited :(
>> Hopefully what we have is good enough.  We can look at improving this
>> after 1.0.Final.  Honestly I'd just like to write our own LDAP
>> abstraction.  Once users start wanting to deal with claims, there's
>> going to be some stored in LDAP some stored in our store.  Picketlink
>> just can handle this scenario dynamically.  Everything must be
>> statically defined in a Java class and mapped with annotations.
>>
> Correction: Picketlink just *cannot* handle dynamic things.
>


From stian at redhat.com  Fri Jul 25 05:05:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 05:05:54 -0400 (EDT)
Subject: [keycloak-dev] Wildfly integration
In-Reply-To: <53D13912.9080203@redhat.com>
References: <20140724125738.GA96564@abstractj.org>
	<1882870772.17448062.1406213568900.JavaMail.zimbra@redhat.com>
	<1851065729.17515950.1406219424547.JavaMail.zimbra@redhat.com>
	<53D13912.9080203@redhat.com>
Message-ID: <406118840.17890446.1406279154081.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 5:49:22 PM
> Subject: Re: [keycloak-dev] Wildfly integration
> 
> What version of Wildfly?  The Undertow auth should not be called for non
> secured URLs.

I used 8.1.0.Final

> 
> On 7/24/2014 12:30 PM, Stian Thorgersen wrote:
> > The problem was down to the fact that the unified-push application wasn't
> > set to bearer-only and Undertow seems to invoke the authentication
> > mechanism even though it's a non-secured resource.
> >
> > What happens in details are:
> >
> > 1. /index.html is loaded
> > 2. keycloak.js redirects to login page
> > 3. Keycloak returns ?code=...
> > 4. Undertow invokes authentication mechanism (even though /index.html is
> > not secured), sees the code, checks for a state cookie, doesn't find one,
> > returns 400
> >
> > One AS7 it works because AS7 doesn't invoke the authentication mechanism at
> > all for /index.html (which seems the correct way to me, as the resource is
> > not part of a secured-constraint).
> >
> > Setting unified-push to bearerOnly (which it should be in any case as it's
> > used for jax-rs endpoints) works around the issue as our Undertow adapter
> > will only look for bearer token and not do anything else.
> >
> > Question: is this a bug in Undertow? is it something we have to add a
> > solution to our Undertow adapter?
> >
> > ----- Original Message -----
> >> From: "Stian Thorgersen" <stian at redhat.com>
> >> To: "Bruno Oliveira" <bruno at abstractj.org>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Thursday, 24 July, 2014 3:52:48 PM
> >> Subject: Re: [keycloak-dev] Wildfly integration
> >>
> >> Got the same issue here, looking into it now
> >>
> >> ----- Original Message -----
> >>> From: "Bruno Oliveira" <bruno at abstractj.org>
> >>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>> Sent: Thursday, 24 July, 2014 1:57:38 PM
> >>> Subject: [keycloak-dev] Wildfly integration
> >>>
> >>> Good morning guys, I'm banging my head against the wall with this issue:
> >>> https://gist.github.com/abstractj/b5b79bf3a5eb77e7989a, basically what
> >>> I'm
> >>> trying to
> >>> do is integrate the latest changes on master with UPS on AeroGear.
> >>>
> >>> On AS7 the application runs with no errors, but when I try to deploy on
> >>> Wildfly I get HTTP 400 after login.
> >>>
> >>> Probably is some misconfiguration on my end, but I already double checked
> >>> project-integrations, checked the examples, tried to debug on IntelliJ
> >>> and
> >>> Chrome.
> >>>
> >>> Here are the steps to reproduce:
> >>>
> >>> git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn
> >>> clean install -DskipTests=true -Dcheckstyle.skip=true
> >>> cd ..
> >>> git clone git at github.com:aerogear/aerogear-parent.git && cd
> >>> aerogear-parent && git checkout KeycloakBeta4 && mvn clean install
> >>> cd ..
> >>> git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd
> >>> aerogear-unifiedpush-server && git checkout KeycloakBeta4 && mvn clean
> >>> install -Pwildfly -DskipTests=true -Dcheckstyle.skip=true
> >>>
> >>> cp databases/unifiedpush-h2-ds.xml $JBOSS_HOME/standalone/deployments
> >>> cp auth-server/target/auth-server.war
> >>> $JBOSS_HOME/standalone/deployments/
> >>> cp server/target/ag-push.war $JBOSS_HOME/standalone/deployments
> >>>
> >>> $JBOSS_HOME/bin/standalone.sh
> >>>
> >>> If you have an idea, let me know.
> >>>
> >>> --
> >>>
> >>> abstractj
> >>> PGP: 0x84DC9914
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Jul 25 08:34:32 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 08:34:32 -0400 (EDT)
Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
In-Reply-To: <53C92152.5080709@redhat.com>
References: <53C92152.5080709@redhat.com>
Message-ID: <1653632070.18016797.1406291672350.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-dev at lists.jboss.org, "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
> Sent: Friday, 18 July, 2014 2:29:54 PM
> Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
> 
> Hi guys,
> 
> My overall goal is to unite JBoss user-facing products via Keycloak
> SSO.  The first major task is make it as easy as possible to use
> Keycloak with the WildFly web console.  I have this working, but it
> takes quite a bit of setup.
> 
> Ideally, there should be a simple switch in WildFly that says, "Use
> Keycloak for web console", and it all just works.
> 
> So I'm looking for ideas on how to automate these setup tasks:
> * Deploy Keycloak auth server and keycloak-ds.xml

Is the plan eventually to deploy Keycloak as an extension instead of a WAR? I reckon that would solve a fair amount of issues. Could even go as far as creating KeycloakDS with a persistent H2 db from within the subsystem if it's not available?

> * Seed the database with an initial realm, user, roles, and two applications

What about defining a boostrap-realm.json file. We already have mechanisms in place for importing a file at startup, which is only imported if the realm doesn't already exist.

> * Create keycloak.json files or populate keycloak subsystem for the two
> apps.

Would be cool if you had an option to automatically create Keycloak subsystem definitions for apps as they're creating in KC. Could have some sort of co-located option or something.

> 
> Thanks in advance,
> 
> 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 Jul 25 09:43:29 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 09:43:29 -0400
Subject: [keycloak-dev] federated pagination Re: federation commited need
 feedback
In-Reply-To: <53D20550.1070802@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
Message-ID: <53D25F01.1060601@redhat.com>



On 7/25/2014 3:20 AM, Marek Posolda wrote:
>> You're right.  The API would have to change to note the provider that
>> was last used and how many were consumed for that provider.
>>
>> class Result {
>>
>>    List<UserModel> results;
>>
>>    String lastProvider;
>>    int lastIndex;
>>
>> }
>>
>> then UserProvider search would need these methods:
>>
>> Result search(criteria..., int maxResults);  // start from beginning
>> Result search(criteria..., String lastProvider, int lastIndex, int
>> maxResults);
> Sorry, I still have doubts;-)
>
> For example there are 10 users in Keycloak and just 5 of them are mapped
> to LDAP. In LDAP there are just those 5 users. Then you want to search
> for page1 with (lastIndex 0, maxResults 10) and you will retrieve those
> 10 Keycloak Users. Then you want page2, so you call (lastIndex 10,
> maxResults 10) and now you retrieve those 5 users from LDAP, but those
> are same users, which were already retrieved on page1.
>

Solved by searching for local users where federation link is null only? 
  The side effect is that the federation provider would also have to 
check the database to make sure the user hasn't already been imported. 
This could suck as 1 pagination query could turn into MAX_RESULTS local 
storage queries.


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

From stian at redhat.com  Fri Jul 25 10:08:28 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 10:08:28 -0400 (EDT)
Subject: [keycloak-dev] Use relative auth-server-url and redirect-uris in
	the demo
In-Reply-To: <1758315323.18104442.1406297281755.JavaMail.zimbra@redhat.com>
Message-ID: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>

I propose we update the demo and examples to use relative urls. This is to make it easier for people that want to try these on OpenShift, Docker or EC2 (or anything else non-localhost).

Any objections?

From bburke at redhat.com  Fri Jul 25 10:28:33 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 10:28:33 -0400
Subject: [keycloak-dev] Use relative auth-server-url and redirect-uris
 in the demo
In-Reply-To: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>
References: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>
Message-ID: <53D26991.8030407@redhat.com>

Weird, I thought I had already done that.  Maybe it was just for the 
Aerogear demo.

On 7/25/2014 10:08 AM, Stian Thorgersen wrote:
> I propose we update the demo and examples to use relative urls. This is to make it easier for people that want to try these on OpenShift, Docker or EC2 (or anything else non-localhost).
>
> Any objections?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Fri Jul 25 11:10:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 11:10:33 -0400 (EDT)
Subject: [keycloak-dev] Use relative auth-server-url and redirect-uris
 in the demo
In-Reply-To: <53D26991.8030407@redhat.com>
References: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>
	<53D26991.8030407@redhat.com>
Message-ID: <1313828963.18165727.1406301033660.JavaMail.zimbra@redhat.com>

Oki, I'll sort it out now.. I was mainly wondering if there was a specific reason it hadn't been done, or if it was just forgotten ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 25 July, 2014 3:28:33 PM
> Subject: Re: [keycloak-dev] Use relative auth-server-url and redirect-uris in the demo
> 
> Weird, I thought I had already done that.  Maybe it was just for the
> Aerogear demo.
> 
> On 7/25/2014 10:08 AM, Stian Thorgersen wrote:
> > I propose we update the demo and examples to use relative urls. This is to
> > make it easier for people that want to try these on OpenShift, Docker or
> > EC2 (or anything else non-localhost).
> >
> > Any objections?
> > _______________________________________________
> > 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  Fri Jul 25 11:25:54 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 11:25:54 -0400
Subject: [keycloak-dev] Use relative auth-server-url and redirect-uris
 in the demo
In-Reply-To: <1313828963.18165727.1406301033660.JavaMail.zimbra@redhat.com>
References: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>
	<53D26991.8030407@redhat.com>
	<1313828963.18165727.1406301033660.JavaMail.zimbra@redhat.com>
Message-ID: <53D27702.9030900@redhat.com>

Only thing I can think of is that the demos will be coded to assume that 
everything is running on one machine.  There needs to be comments 
stating that the developer should change the code if things move to a 
different machine.

On 7/25/2014 11:10 AM, Stian Thorgersen wrote:
> Oki, I'll sort it out now.. I was mainly wondering if there was a specific reason it hadn't been done, or if it was just forgotten ;)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 25 July, 2014 3:28:33 PM
>> Subject: Re: [keycloak-dev] Use relative auth-server-url and redirect-uris in the demo
>>
>> Weird, I thought I had already done that.  Maybe it was just for the
>> Aerogear demo.
>>
>> On 7/25/2014 10:08 AM, Stian Thorgersen wrote:
>>> I propose we update the demo and examples to use relative urls. This is to
>>> make it easier for people that want to try these on OpenShift, Docker or
>>> EC2 (or anything else non-localhost).
>>>
>>> Any objections?
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Fri Jul 25 11:27:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 11:27:22 -0400 (EDT)
Subject: [keycloak-dev] Use relative auth-server-url and redirect-uris
 in the demo
In-Reply-To: <53D27702.9030900@redhat.com>
References: <1304927905.18104764.1406297308552.JavaMail.zimbra@redhat.com>
	<53D26991.8030407@redhat.com>
	<1313828963.18165727.1406301033660.JavaMail.zimbra@redhat.com>
	<53D27702.9030900@redhat.com>
Message-ID: <601725247.18178722.1406302042853.JavaMail.zimbra@redhat.com>

Was just thinking about that. We should add instructions on running the demo on a separate WF instance to KC.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, 25 July, 2014 4:25:54 PM
> Subject: Re: [keycloak-dev] Use relative auth-server-url and redirect-uris in the demo
> 
> Only thing I can think of is that the demos will be coded to assume that
> everything is running on one machine.  There needs to be comments
> stating that the developer should change the code if things move to a
> different machine.
> 
> On 7/25/2014 11:10 AM, Stian Thorgersen wrote:
> > Oki, I'll sort it out now.. I was mainly wondering if there was a specific
> > reason it hadn't been done, or if it was just forgotten ;)
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 25 July, 2014 3:28:33 PM
> >> Subject: Re: [keycloak-dev] Use relative auth-server-url and redirect-uris
> >> in the demo
> >>
> >> Weird, I thought I had already done that.  Maybe it was just for the
> >> Aerogear demo.
> >>
> >> On 7/25/2014 10:08 AM, Stian Thorgersen wrote:
> >>> I propose we update the demo and examples to use relative urls. This is
> >>> to
> >>> make it easier for people that want to try these on OpenShift, Docker or
> >>> EC2 (or anything else non-localhost).
> >>>
> >>> Any objections?
> >>> _______________________________________________
> >>> 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  Fri Jul 25 11:29:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 11:29:14 -0400
Subject: [keycloak-dev] import/export should only use local storage
Message-ID: <53D277CA.1010509@redhat.com>

Import/export should only use local user storage correct?

FYI, there's going to end up being 3 interfaces for users.

* UserFederation -> top level API and entrypoint that will be used by 
services
* UserProvider -> used for local storage
* UserFederationProvider -> used for federation.


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

From stian at redhat.com  Fri Jul 25 11:36:06 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 25 Jul 2014 11:36:06 -0400 (EDT)
Subject: [keycloak-dev] import/export should only use local storage
In-Reply-To: <53D277CA.1010509@redhat.com>
References: <53D277CA.1010509@redhat.com>
Message-ID: <1059587509.18184191.1406302566725.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 25 July, 2014 4:29:14 PM
> Subject: [keycloak-dev] import/export should only use local storage
> 
> Import/export should only use local user storage correct?

Yes (assuming by local user storage you mean Keycloaks user db)

> 
> FYI, there's going to end up being 3 interfaces for users.
> 
> * UserFederation -> top level API and entrypoint that will be used by
> services
> * UserProvider -> used for local storage
> * UserFederationProvider -> used for federation.

I take it we can't fully hide the federation behind UserProvider?

> 
> 
> --
> 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 Jul 25 12:14:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 12:14:57 -0400
Subject: [keycloak-dev] import/export should only use local storage
In-Reply-To: <1059587509.18184191.1406302566725.JavaMail.zimbra@redhat.com>
References: <53D277CA.1010509@redhat.com>
	<1059587509.18184191.1406302566725.JavaMail.zimbra@redhat.com>
Message-ID: <53D28281.3010403@redhat.com>



On 7/25/2014 11:36 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, 25 July, 2014 4:29:14 PM
>> Subject: [keycloak-dev] import/export should only use local storage
>>
>> Import/export should only use local user storage correct?
>
> Yes (assuming by local user storage you mean Keycloaks user db)
>
>>
>> FYI, there's going to end up being 3 interfaces for users.
>>
>> * UserFederation -> top level API and entrypoint that will be used by
>> services
>> * UserProvider -> used for local storage
>> * UserFederationProvider -> used for federation.
>
> I take it we can't fully hide the federation behind UserProvider?
>

No :( all 3 interfaces are starting to diverge because of pagination. 
There's also some methods that may not make sense for FederationProvider.

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

From mposolda at redhat.com  Fri Jul 25 12:18:08 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 25 Jul 2014 18:18:08 +0200
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D25F01.1060601@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com>
Message-ID: <53D28340.7030607@redhat.com>

Just to have things a bit more complicated, the LDAP doesn't support 
"classic" pagination model with offset/limit like JPA, but the 
pagination model with cookie/limit (each search returns "cookie", which 
can be used to search for next page). Some details here 
http://www.ietf.org/rfc/rfc2696.txt...

It is not a problem for the Sync usecase though, as sync process will 
have full control and can process all the pages gradually. However it 
looks that it will affect FederationProvider though? I guess "Result" 
object you proposed would need to store cookie in some property as well. 
For picketlink I've added paginationContext to Picketlink IdentityQuery 
to handle this 
https://github.com/picketlink/picketlink/blob/master/modules/idm/api/src/main/java/org/picketlink/idm/query/IdentityQuery.java#L43 
.

Marek

On 25.7.2014 15:43, Bill Burke wrote:
>
>
> On 7/25/2014 3:20 AM, Marek Posolda wrote:
>>> You're right.  The API would have to change to note the provider that
>>> was last used and how many were consumed for that provider.
>>>
>>> class Result {
>>>
>>>    List<UserModel> results;
>>>
>>>    String lastProvider;
>>>    int lastIndex;
>>>
>>> }
>>>
>>> then UserProvider search would need these methods:
>>>
>>> Result search(criteria..., int maxResults);  // start from beginning
>>> Result search(criteria..., String lastProvider, int lastIndex, int
>>> maxResults);
>> Sorry, I still have doubts;-)
>>
>> For example there are 10 users in Keycloak and just 5 of them are mapped
>> to LDAP. In LDAP there are just those 5 users. Then you want to search
>> for page1 with (lastIndex 0, maxResults 10) and you will retrieve those
>> 10 Keycloak Users. Then you want page2, so you call (lastIndex 10,
>> maxResults 10) and now you retrieve those 5 users from LDAP, but those
>> are same users, which were already retrieved on page1.
>>
>
> Solved by searching for local users where federation link is null 
> only?  The side effect is that the federation provider would also have 
> to check the database to make sure the user hasn't already been 
> imported. This could suck as 1 pagination query could turn into 
> MAX_RESULTS local storage queries

From bburke at redhat.com  Fri Jul 25 12:40:00 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 12:40:00 -0400
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D28340.7030607@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com> <53D28340.7030607@redhat.com>
Message-ID: <53D28860.90503@redhat.com>

Even worse, this "paginationContext" needs to be exportable as a URL 
parameter.  So it looks like we can't support federated pagination until 
we get a new Picketlink release.  How should we proceed?  Looks like 
we're stuck with only doing searches on imported users for now.

search(String someRandomString) could be:

Do the following to get things synced up on-demand:
ldap.getUserByUsername(someRandomString)
ldap.getUserByEmail(someRandomString)

Then just do a search on local storage:
local.search(someRandomString)

FederationProvider just doesn't support random searches.  Which is why 
you did what you did for AuthenticationProvider.  I'm starting to feel 
like an idiot.


On 7/25/2014 12:18 PM, Marek Posolda wrote:
> Just to have things a bit more complicated, the LDAP doesn't support
> "classic" pagination model with offset/limit like JPA, but the
> pagination model with cookie/limit (each search returns "cookie", which
> can be used to search for next page). Some details here
> http://www.ietf.org/rfc/rfc2696.txt...
>
> It is not a problem for the Sync usecase though, as sync process will
> have full control and can process all the pages gradually. However it
> looks that it will affect FederationProvider though? I guess "Result"
> object you proposed would need to store cookie in some property as well.
> For picketlink I've added paginationContext to Picketlink IdentityQuery
> to handle this
> https://github.com/picketlink/picketlink/blob/master/modules/idm/api/src/main/java/org/picketlink/idm/query/IdentityQuery.java#L43
> .
>
> Marek
>
> On 25.7.2014 15:43, Bill Burke wrote:
>>
>>
>> On 7/25/2014 3:20 AM, Marek Posolda wrote:
>>>> You're right.  The API would have to change to note the provider that
>>>> was last used and how many were consumed for that provider.
>>>>
>>>> class Result {
>>>>
>>>>    List<UserModel> results;
>>>>
>>>>    String lastProvider;
>>>>    int lastIndex;
>>>>
>>>> }
>>>>
>>>> then UserProvider search would need these methods:
>>>>
>>>> Result search(criteria..., int maxResults);  // start from beginning
>>>> Result search(criteria..., String lastProvider, int lastIndex, int
>>>> maxResults);
>>> Sorry, I still have doubts;-)
>>>
>>> For example there are 10 users in Keycloak and just 5 of them are mapped
>>> to LDAP. In LDAP there are just those 5 users. Then you want to search
>>> for page1 with (lastIndex 0, maxResults 10) and you will retrieve those
>>> 10 Keycloak Users. Then you want page2, so you call (lastIndex 10,
>>> maxResults 10) and now you retrieve those 5 users from LDAP, but those
>>> are same users, which were already retrieved on page1.
>>>
>>
>> Solved by searching for local users where federation link is null
>> only?  The side effect is that the federation provider would also have
>> to check the database to make sure the user hasn't already been
>> imported. This could suck as 1 pagination query could turn into
>> MAX_RESULTS local storage queries

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

From mposolda at redhat.com  Fri Jul 25 14:19:51 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 25 Jul 2014 20:19:51 +0200
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D28860.90503@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com> <53D28340.7030607@redhat.com>
	<53D28860.90503@redhat.com>
Message-ID: <53D29FC7.9040403@redhat.com>

I am already on picketlink master and trying to address the issues we 
have. Right now mapping of dynamic attributes aka 
https://issues.jboss.org/browse/PLINK-533 . I don't know when exactly is 
picketlink release planned, but maybe we can ask Pedro to do at least 
timestamped release somewhen next week?

I wonder that random searches with FederationProvider might work for 
implementations, which supports offset/limit (like external database 
provided by customer) with your idea of omit local users with federation 
link? There are more tricky things though, like if user "john" available 
in in both local and LDAP store, and then directly deleted in LDAP, 
won't be returned if queries even if he is still in Keycloak database. 
Not sure if it's good or bad as he may not be able to login anyway...

However for LDAP it's tricky... I've tested with ActiveDirectory that I 
can query with same cookie to random LDAP pages (next page or any page 
which I already previously visited), but looks that just next page is 
always guaranteed to work but previous pages are not guaranteed 
according to http://www.ietf.org/rfc/rfc2696.txt sentence:
"Returning cookies from previous searchResultDone responses besides the 
last one is undefined, as the server implementation may restrict cookies 
from being reused."

Marek

On 25.7.2014 18:40, Bill Burke wrote:
> Even worse, this "paginationContext" needs to be exportable as a URL 
> parameter.  So it looks like we can't support federated pagination 
> until we get a new Picketlink release.  How should we proceed? Looks 
> like we're stuck with only doing searches on imported users for now.
>
> search(String someRandomString) could be:
>
> Do the following to get things synced up on-demand:
> ldap.getUserByUsername(someRandomString)
> ldap.getUserByEmail(someRandomString)
>
> Then just do a search on local storage:
> local.search(someRandomString)
>
> FederationProvider just doesn't support random searches.  Which is why 
> you did what you did for AuthenticationProvider.  I'm starting to feel 
> like an idiot.
>
>
> On 7/25/2014 12:18 PM, Marek Posolda wrote:
>> Just to have things a bit more complicated, the LDAP doesn't support
>> "classic" pagination model with offset/limit like JPA, but the
>> pagination model with cookie/limit (each search returns "cookie", which
>> can be used to search for next page). Some details here
>> http://www.ietf.org/rfc/rfc2696.txt...
>>
>> It is not a problem for the Sync usecase though, as sync process will
>> have full control and can process all the pages gradually. However it
>> looks that it will affect FederationProvider though? I guess "Result"
>> object you proposed would need to store cookie in some property as well.
>> For picketlink I've added paginationContext to Picketlink IdentityQuery
>> to handle this
>> https://github.com/picketlink/picketlink/blob/master/modules/idm/api/src/main/java/org/picketlink/idm/query/IdentityQuery.java#L43 
>>
>> .
>>
>> Marek
>>
>> On 25.7.2014 15:43, Bill Burke wrote:
>>>
>>>
>>> On 7/25/2014 3:20 AM, Marek Posolda wrote:
>>>>> You're right.  The API would have to change to note the provider that
>>>>> was last used and how many were consumed for that provider.
>>>>>
>>>>> class Result {
>>>>>
>>>>>    List<UserModel> results;
>>>>>
>>>>>    String lastProvider;
>>>>>    int lastIndex;
>>>>>
>>>>> }
>>>>>
>>>>> then UserProvider search would need these methods:
>>>>>
>>>>> Result search(criteria..., int maxResults);  // start from beginning
>>>>> Result search(criteria..., String lastProvider, int lastIndex, int
>>>>> maxResults);
>>>> Sorry, I still have doubts;-)
>>>>
>>>> For example there are 10 users in Keycloak and just 5 of them are 
>>>> mapped
>>>> to LDAP. In LDAP there are just those 5 users. Then you want to search
>>>> for page1 with (lastIndex 0, maxResults 10) and you will retrieve 
>>>> those
>>>> 10 Keycloak Users. Then you want page2, so you call (lastIndex 10,
>>>> maxResults 10) and now you retrieve those 5 users from LDAP, but those
>>>> are same users, which were already retrieved on page1.
>>>>
>>>
>>> Solved by searching for local users where federation link is null
>>> only?  The side effect is that the federation provider would also have
>>> to check the database to make sure the user hasn't already been
>>> imported. This could suck as 1 pagination query could turn into
>>> MAX_RESULTS local storage queries
>


From ssilvert at redhat.com  Fri Jul 25 14:01:04 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 25 Jul 2014 14:01:04 -0400
Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
In-Reply-To: <1653632070.18016797.1406291672350.JavaMail.zimbra@redhat.com>
References: <53C92152.5080709@redhat.com>
	<1653632070.18016797.1406291672350.JavaMail.zimbra@redhat.com>
Message-ID: <53D29B60.4070305@redhat.com>

On 7/25/2014 8:34 AM, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Stan Silvert" <ssilvert at redhat.com>
>> To: keycloak-dev at lists.jboss.org, "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
>> Sent: Friday, 18 July, 2014 2:29:54 PM
>> Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
>>
>> Hi guys,
>>
>> My overall goal is to unite JBoss user-facing products via Keycloak
>> SSO.  The first major task is make it as easy as possible to use
>> Keycloak with the WildFly web console.  I have this working, but it
>> takes quite a bit of setup.
>>
>> Ideally, there should be a simple switch in WildFly that says, "Use
>> Keycloak for web console", and it all just works.
>>
>> So I'm looking for ideas on how to automate these setup tasks:
>> * Deploy Keycloak auth server and keycloak-ds.xml
> Is the plan eventually to deploy Keycloak as an extension instead of a WAR? I reckon that would solve a fair amount of issues. Could even go as far as creating KeycloakDS with a persistent H2 db from within the subsystem if it's not available?
Interesting idea.  What issues are you thinking this will solve?
>
>> * Seed the database with an initial realm, user, roles, and two applications
> What about defining a boostrap-realm.json file. We already have mechanisms in place for importing a file at startup, which is only imported if the realm doesn't already exist.
How does the mechanism work?  I don't see the doco for it.  This might 
solve much of my problem.  But I need to let it generate new keys for 
the realm.  It should also generate a new secret for each application.  
Otherwise, everyone's installation would be the same.

Can I get a callback to know when the import is complete?  After all 
that is done, I need to create the subsystem definitions for the 
applications.  So I have to query Keycloak to find out what the 
installation parameters are.  Is all that doable?
>
>> * Create keycloak.json files or populate keycloak subsystem for the two
>> apps.
> Would be cool if you had an option to automatically create Keycloak subsystem definitions for apps as they're creating in KC. Could have some sort of co-located option or something.
Actually, you don't even need the co-located option.  It could issue a 
CLI command to any server that has a Keycloak subsystem.  Not only that, 
you could even deploy the WAR from Keycloak Admin if you wanted to.  But 
I don't think you want Keycloak to be in the business of managing 
deployments.

This is where true integration with our other tools comes in. Keycloak 
manages security.  Web Console and JON manage deployments. All three 
should work together.  So when I want to deploy something, I should be 
able to do all this from an integrated UI:
* Scan the WAR to find out its roles.
* Auto-populate Keycloak with the application and role definitions.
* Auto-populate Keycloak with the application's Redirect URI, Base URL, etc.
* Create the Keycloak subsystem entries
* Decide which WildFly instances the app will be deployed to.
* Upload and deploy the WAR
>
>> Thanks in advance,
>>
>> 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 Jul 25 15:28:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 15:28:44 -0400
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D29FC7.9040403@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com> <53D28340.7030607@redhat.com>
	<53D28860.90503@redhat.com> <53D29FC7.9040403@redhat.com>
Message-ID: <53D2AFEC.4010707@redhat.com>



On 7/25/2014 2:19 PM, Marek Posolda wrote:
> I am already on picketlink master and trying to address the issues we
> have. Right now mapping of dynamic attributes aka
> https://issues.jboss.org/browse/PLINK-533 . I don't know when exactly is
> picketlink release planned, but maybe we can ask Pedro to do at least
> timestamped release somewhen next week?
>
> I wonder that random searches with FederationProvider might work for
> implementations, which supports offset/limit (like external database
> provided by customer) with your idea of omit local users with federation
> link? There are more tricky things though, like if user "john" available
> in in both local and LDAP store, and then directly deleted in LDAP,
> won't be returned if queries even if he is still in Keycloak database.
> Not sure if it's good or bad as he may not be able to login anyway...
>

Was going to change it in that if a returned UserModel is linked, to 
check that it is still valid for the federation and delete it if it is not.

> However for LDAP it's tricky... I've tested with ActiveDirectory that I
> can query with same cookie to random LDAP pages (next page or any page
> which I already previously visited), but looks that just next page is
> always guaranteed to work but previous pages are not guaranteed
> according to http://www.ietf.org/rfc/rfc2696.txt sentence:
> "Returning cookies from previous searchResultDone responses besides the
> last one is undefined, as the server implementation may restrict cookies
> from being reused."
>

for now the federation interface for queries will be:

UserModel getUserByUsername(RealmModel realm, String username)
UserModel getUserByEmail(RealmModel realm, String email)
List<UserModel> getUserByLastName((RealmModel realm, String last)
List<UserModel> getUserByFullName((RealmModel realm, String first, 
String last);

No pagination.  No paginated getAllUsers() and thus, no sync API.  If 
you can figure out something reliable in the next week *AND* get us a 
new Picketlink release, we can use it in 1.0.Final.   Otherwise, it is 
just going to have to wait I guess.


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

From harit.subscriptions at gmail.com  Fri Jul 25 17:04:07 2014
From: harit.subscriptions at gmail.com (Harit Himanshu)
Date: Fri, 25 Jul 2014 14:04:07 -0700
Subject: [keycloak-dev] Oauth Register and Token Validation Example
In-Reply-To: <CADYyO+X_0xuUjYr9D1awpbYLt5xmMjKJapKz5cw0BYN+p-+q=Q@mail.gmail.com>
References: <CADYyO+X_0xuUjYr9D1awpbYLt5xmMjKJapKz5cw0BYN+p-+q=Q@mail.gmail.com>
Message-ID: <CADYyO+VKC0cSkbHvmY2vJerB9PJ_J_h4fmdc3bsLy1VtamYMFw@mail.gmail.com>

Hey Team,

I am been looking for answer to
http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis
and
found that keycloak is suitable for securing REST APIs using OAuth 2.0.

I am looking for example where the following is demonstrated
a.) Third-party app registers and gets Access Token
b.) Third-Party app accesses Resource Server to access protected resource
by sending Access Token to REST API
c.) and How Token is validated.


It is mentioned in features of keycloak as

   - OAuth Bearer token auth for REST Services
   - OAuth 2.0 Grant requests
   - CORS Support

Can you please guide me through examples?

Thank you


On Fri, Jul 25, 2014 at 2:00 PM, Harit Himanshu <
harit.subscriptions at gmail.com> wrote:

> Hey Team,
>
> I am been looking for answer to
> http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis
> and found that keycloak is suitable for securing REST APIs using OAuth 2.0.
>
> I am looking for example where the following is demonstrated
> a.) Third-party app registers and gets Access Token
> b.) Third-Party app accesses Resource Server to access protected resource
> by sending Access Token to REST API
> c.) and How Token is validated.
>
>
> It is mentioned in features of keycloak as
>
>    - OAuth Bearer token auth for REST Services
>    - OAuth 2.0 Grant requests
>    - CORS Support
>
> Can you please guide me through examples?
>
> Thank you
> + Harit Himanshu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140725/097da1b4/attachment.html 

From psilva at redhat.com  Fri Jul 25 17:58:28 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 25 Jul 2014 17:58:28 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
	<1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
Message-ID: <1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>

Hi All,

    I had some progress with PL and Federation Protocols support. I've provided implementations for both KC and PL SAML support. I think that would be a nice feature for our users, so they can use our stuff all together.

    Basically, what we have is a federated identity store on PL side, which knows how to consume a specific token from a federation protocol and extract its information to properly integrate with PL identity model. From a SPI perspective, federation providers must implement a Token Consumer and an Custom Authentication Scheme.

    The Token Consumer is responsible for understand how to parse a specific token and extract identity information from it (eg.: claims or any other kind of attributes). The Authentication Scheme is responsible for providing a entry point in order to extract the token from the request or in some other way. For instance, when using KC adapter the custom scheme uses the KeycloakSecurityContext to get the token.

    One of the most interest thing about this support in PL is that you can switch from different federation providers without change the rest of your application. In other words, if you are already using PL to protected/authorize your beans and using the Identity bean to handle the authenticated user, you still use it in the same way as a "regular" PL application.

    Another aspect is the possibility to provide a deep integration with a specific IdP in order to properly manage tokens by a consumer application. This is specially useful when your application does not use KC adapter, but only keycloak.js or something else to update and send tokens in every single request to the server.

    With that in mind, I would like to know if we can provide the KC related implementation from KC itself. The motivation is that in order to properly handle KC tokens we need some KC libraries and I think the best place to put this is in KC. Any change to API or something we get during KC build. KC users looking for PL integration just get it from KC OOTB.

    As I said, that would be 2 or 3 simple classes. Something like:

        https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakToken.java (See, we can use KC API to properly parse and handle tokens. Instead of PL-JSON)
 
        https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakAuthenticationScheme.java (Used only KC adapter is present. Otherwise users can just use our TokenAuthenticationScheme when sending tokens to the server)

        https://github.com/pedroigor/jboss-wfk-quickstarts/blob/token-store-without-js/contacts-mobile-picketlink-secured/src/main/java/org/jboss/quickstarts/wfk/contacts/security/authentication/KeyCloakTokenConsumer.java

    I'm still changing code. But those three core concepts (Token, Scheme and Consumer) are almost consolidated. Just need to test some other scenarios to make sure we're on the right path.

    Any thoughts ?

----- Original Message -----
From: "Pedro Igor Silva" <psilva at redhat.com>
To: "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, July 23, 2014 12:33:06 PM
Subject: Re: [keycloak-dev] PicketLink and KC Integration

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, July 23, 2014 11:08:12 AM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> 
> 
> 
> On 7/23/2014 8:46 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, July 23, 2014 1:04:31 AM
> >> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> >>
> >> Keycloak is about authentication *and* authorization.  We currently have
> >> deep integration plugins for AS7/EAP6/Wildfly to provide auth and RBAC
> >> for Servlet apps out of the box.  You can even take an existing WAR,
> >> without cracking it open, using the Keycloak JBoss/Wildfly Subsystem.
> >> We have plans for additional adapters post 1.0.Final for Node.js, JIRA,
> >> Tomcat, and Jetty.
> >
> > What I'm doing is pretty much like what you have in third-party-cdi
> > example. From this example, there is no security-constraint or adapter
> > involved right ?
> >
> 
> 
> 
> > And looking at the code (from upstream) I can see a
> > org.keycloak.example.oauth.RefreshTokenFilter that does pretty much what
> > PL is doing. Extracting the CODE from the request and configuring an
> > "user" representation which in our case is the Identity bean. Beside that,
> > PL is also validating the token and allowing the application to query
> > roles or any other data from the token.
> >
> The third-party example is an example of traditional OAuth.  Traditional
> OAuth is not SSO, nor is it anything about identity.  It is about
> getting a temporary token so you can get access to a resource.  Generic
> oauth/openid connect client libraries is another intersection of
> Picketlink and Keycloak that should be shared.  I'm not happy with what
> we got right now.

Agree on the oAuth stuff. But as I told you there is a pretty common scenario where an application provides a social login. IMO, social logins can be used as follows:

1) Account Linking. In this case, the application may want to provide its own registration (username/password) and only link user's account to a specific social one. Eg.: JBoss Developer Site.
2) Account Linking + Remember-Me. In this case, the application does not store user credentials at all but relies on the social provider to authenticate based on the token retrieved from the social provider. As long the token is valid and your browser has a valid session in a social provider, you're always redirected back to app with a token and authenticated by the application. It is a fake "SSO" :)

There is another scenario that I'm considering that is related with scopes. In this case, the oAuth server authorizes a client application to use a set of scopes (eg.: read public profile). The client application then uses the token to invoke an API provided by another application. I want to use the token to extract the authorized scopes and protect my API.

> 
> Our adapters are different than the third-party example.  They are our
> integrated security story:  Single Sign On/Off.  Session management.
> Role mappings.  Component integration, etc.

Yeah, they remind me PL SAML Authenticators :)

> 
> 
> > I've looked others examples as well. From a PL-only perspective, I was
> > looking for an integration
> > fully based on PL where all details from a specific IdP is abstracted from
> > developers. For instance, KC from an application perspective is an
> > implementation detail. If you want you can easily switch to another IdP
> > without change a single line of code in your application. But just PL
> > config. So they can still use our built-in authz annotations and injection
> > to deal with the security context for their users.
> >
> 
> This is something I'd like to see.  For PIcketlink, Spring security, and
> other security abstractions.  Keycloak 1.0 is 100% focused only on Java
> EE security integration.

I see. I'm preparing some quickstarts to showcase this. Let's see ...

> 
> > As far as I can see, most examples from KC are based on a coarse-grained
> > authorization model based on a JEE security-constraint. Is that the
> > authorization you're talking about ? Or KC also provides a more
> > fine-grained mechanism to individual beans ?
> >
> 
> Keycloak is just role based authorization right now.  Roles can be
> scoped at the Realm level, or scoped per application.  We also have some
> claim support (address, phone ,etc.) too.
> 
> Keycloak adapters create a principal and populates the Subject with role
> mappings. The adapters also provide REST endpoints for gathering
> management stats, to propagate revocation policies, and also to manage
> Single Sign Off.
> 
> >>
> >> For the Keycloak 2.0 timeframe (2015), I'd also like to evolve our
> >> Social Provider SPI into a full fledged generic Broker SPI, of which I'd
> >> like a SAML plugin which could make use of any SAML client modules
> >> Picketlink has.
> >>
> >> We're also missing integration with CDI and other component layers and a
> >> better application API for injecting and obtaining security metadata.
> >
> > I think that is the area I'm trying to help. Considering that we already
> > provide security for CDI applications,
> > service providers can still benefit from :
> >
> > @Inject Identity identity; // representing the authenticated user
> > @Inject IdentityManager identityManager; // provides ways to query
> > information retrieved from a token
> >
> 
> Keycloak has its own specific security model so it will need its own API
> in addition to integration with PL, Spring and other security abstractions.
> 
> 
> > Actually, that was a requirement from WFK. They asked us about how to
> > easily enable KC in a PL application.
> >
> > Maybe I should also take a look about how to use the adapter to provide all
> > the token handling instead of doing it by my own.
> >
> 
> You don't need to look at the adapter.
> HttpServletRequest.getUserPrincipal() should return an instance of
> KeycloakPrincipal which has a method to get KeycloakSecurityContext
> which has access to the unmarshalled token.  KeycloakSecurityContext is
> also available as a HttpServletRequest attribute:
> 
> KeycloakSEcurityContext context =
> (KeycloakSecurityContext)request.getAttribute(KeycloakSecurityContext.class.getName());
> 
> Finally, tokens can have any number of claims in them too (address,
> phone, website, blog, picture, etc.).

Cool. Tks.

> 
> 
> --
> 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 Jul 25 21:20:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 21:20:03 -0400
Subject: [keycloak-dev] federation iteration 2
Message-ID: <53D30243.3080500@redhat.com>

* UserProvider interface stayed the same
* Didn't add a UserFederation interface like I said I was going to, 
didn't have to.
* UserFederationProvider interface no longer extends UserProvider and is 
smaller
* UserFederationProvider no longer supports pagination
* UserFederationProvider no longer supports getUsers().  This is a very 
dangerous method for large databases since we can't reliable support 
pagination.

How does pagination work now?

* getUsers() only queries local storage
* search() methods will call searchByAttributes() on every provider. 
Then paginate based on local storage.  This may result in long query 
times (and database inserts) depending how many people of the same name 
there are.  In a database of 1 million, not sure what the distribution 
will be.  For example, the most popular US name is "Smith" there are 2.8 
million which is less than 1% of the USA.

But, I'm not sure what to do.  Admins *MUST* be able to search based on 
names.  What would reduce the search would be to require both first and 
last name.

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

From bburke at redhat.com  Fri Jul 25 21:44:47 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 25 Jul 2014 21:44:47 -0400
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
	<1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
	<1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>
Message-ID: <53D3080F.3060307@redhat.com>

Good work.  This is precisely the type of integration with Picketlink I 
was hoping for.

On 7/25/2014 5:58 PM, Pedro Igor Silva wrote:
>      Another aspect is the possibility to provide a deep integration with a specific IdP in order to properly manage tokens by a consumer application. This is specially useful when your application does not use KC adapter, but only keycloak.js or something else to update and send tokens in every single request to the server.
>

This could work for Bearer token requests, but not for the oauth 
redirection protocol.  Unless Picketlink has a pure-servlet 
authentication SPI that we could write an adapter for.

I want to write a pure-servlet adapter and a pure-jaxrs adapter just 
haven't had the time yet.

BTW, take a look at Ubefire security SPIs.  It might be interesting to 
get them to move it to Picketlink.  Then Picketlink could have a 
pure-servlet, portable authentication layer.  I don't know anything 
about Spring Security, but maybe this is in the same area.

>      With that in mind, I would like to know if we can provide the KC related implementation from KC itself. The motivation is that in order to properly handle KC tokens we need some KC libraries and I think the best place to put this is in KC. Any change to API or something we get during KC build. KC users looking for PL integration just get it from KC OOTB.
>

I don't care where the code lives.  Up to you.  We can maintain it so 
long as you provide some unit tests.  (it would go under integration/)


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

From psilva at redhat.com  Fri Jul 25 22:00:21 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 25 Jul 2014 22:00:21 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <53D3080F.3060307@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
	<1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
	<1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>
	<53D3080F.3060307@redhat.com>
Message-ID: <274006442.13606222.1406340021870.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, July 25, 2014 10:44:47 PM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> 
> Good work.  This is precisely the type of integration with Picketlink I
> was hoping for.
> 
> On 7/25/2014 5:58 PM, Pedro Igor Silva wrote:
> >      Another aspect is the possibility to provide a deep integration with a
> >      specific IdP in order to properly manage tokens by a consumer
> >      application. This is specially useful when your application does not
> >      use KC adapter, but only keycloak.js or something else to update and
> >      send tokens in every single request to the server.
> >
> 
> This could work for Bearer token requests, but not for the oauth
> redirection protocol.  Unless Picketlink has a pure-servlet
> authentication SPI that we could write an adapter for.

I think we have that. Today we provide an AuthenticationFilter (which we want to review and provide a better servlet-security support) that is based
on different authentication schemes to provided different methods of authentication. Currently we support BASIC, DIGEST, FORM, CLIENT-CERT and TOKEN.
You can provide your own custom scheme too.

Regarding oAuth, that is one of the scenarios I testing. I think we can use oAuth redirection considering what we have. Let's see ...

> 
> I want to write a pure-servlet adapter and a pure-jaxrs adapter just
> haven't had the time yet.
> 
> BTW, take a look at Ubefire security SPIs.  It might be interesting to
> get them to move it to Picketlink.  Then Picketlink could have a
> pure-servlet, portable authentication layer.  I don't know anything
> about Spring Security, but maybe this is in the same area.

I'll, thanks for the heads up. And yes, PL and Spring Security are in the same area. But as I said, we have a big TODO here:

https://gist.github.com/pedroigor/5852028

Anil and I wrote that some time ago, but you can have an idea about our plans for servlet security.

> 
> >      With that in mind, I would like to know if we can provide the KC
> >      related implementation from KC itself. The motivation is that in
> >      order to properly handle KC tokens we need some KC libraries and I
> >      think the best place to put this is in KC. Any change to API or
> >      something we get during KC build. KC users looking for PL integration
> >      just get it from KC OOTB.
> >
> 
> I don't care where the code lives.  Up to you.  We can maintain it so
> long as you provide some unit tests.  (it would go under integration/)

Cool. We can also support that.

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

From bburke at redhat.com  Sat Jul 26 09:02:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 26 Jul 2014 09:02:15 -0400
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <274006442.13606222.1406340021870.JavaMail.zimbra@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<53CF344F.5050902@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
	<1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
	<1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>
	<53D3080F.3060307@redhat.com>
	<274006442.13606222.1406340021870.JavaMail.zimbra@redhat.com>
Message-ID: <53D3A6D7.9040307@redhat.com>



On 7/25/2014 10:00 PM, Pedro Igor Silva wrote:
> I'll, thanks for the heads up. And yes, PL and Spring Security are in the same area. But as I said, we have a big TODO here:
>
> https://gist.github.com/pedroigor/5852028
>
> Anil and I wrote that some time ago, but you can have an idea about our plans for servlet security.
>

That would be interesting if it was cross-platform and did tight 
integration with each platform (i.e. AS7, EAP, Wildfly 8-9, Jetty, 
Tomcat, etc...) as well with Java EE security.  Then Keycloak could get 
out of the adapter business.  At least for Java...



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

From stian at redhat.com  Mon Jul 28 04:39:43 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 28 Jul 2014 04:39:43 -0400 (EDT)
Subject: [keycloak-dev] federation iteration 2
In-Reply-To: <53D30243.3080500@redhat.com>
References: <53D30243.3080500@redhat.com>
Message-ID: <1324371108.18912250.1406536783359.JavaMail.zimbra@redhat.com>

Here's a thought, what about dropping pagination and instead returning a maximum number of users.

If an admin is looking for a specific user the admin is not going to want to page through 10K users. So we could return say 50 users, with a message saying "your search returned to many results, please refine your search". Then we can improve the search feature to give better control on finding a specific user. This could include:

* Separate fields for first, last, username and email
* Registration date
* Other fields once we add customized profiles (for example DOB)
* By social username
* By role

That should make much it easier to aggregate the results from the internal db and federated stores.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, 26 July, 2014 2:20:03 AM
> Subject: [keycloak-dev] federation iteration 2
> 
> * UserProvider interface stayed the same
> * Didn't add a UserFederation interface like I said I was going to,
> didn't have to.
> * UserFederationProvider interface no longer extends UserProvider and is
> smaller
> * UserFederationProvider no longer supports pagination
> * UserFederationProvider no longer supports getUsers().  This is a very
> dangerous method for large databases since we can't reliable support
> pagination.
> 
> How does pagination work now?
> 
> * getUsers() only queries local storage
> * search() methods will call searchByAttributes() on every provider.
> Then paginate based on local storage.  This may result in long query
> times (and database inserts) depending how many people of the same name
> there are.  In a database of 1 million, not sure what the distribution
> will be.  For example, the most popular US name is "Smith" there are 2.8
> million which is less than 1% of the USA.
> 
> But, I'm not sure what to do.  Admins *MUST* be able to search based on
> names.  What would reduce the search would be to require both first and
> last name.
> 
> --
> 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 Jul 28 05:17:44 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 28 Jul 2014 11:17:44 +0200
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D2AFEC.4010707@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com> <53D28340.7030607@redhat.com>
	<53D28860.90503@redhat.com> <53D29FC7.9040403@redhat.com>
	<53D2AFEC.4010707@redhat.com>
Message-ID: <53D61538.4060208@redhat.com>

On 25.7.2014 21:28, Bill Burke wrote:
>
>
> On 7/25/2014 2:19 PM, Marek Posolda wrote:
>> I am already on picketlink master and trying to address the issues we
>> have. Right now mapping of dynamic attributes aka
>> https://issues.jboss.org/browse/PLINK-533 . I don't know when exactly is
>> picketlink release planned, but maybe we can ask Pedro to do at least
>> timestamped release somewhen next week?
>>
>> I wonder that random searches with FederationProvider might work for
>> implementations, which supports offset/limit (like external database
>> provided by customer) with your idea of omit local users with federation
>> link? There are more tricky things though, like if user "john" available
>> in in both local and LDAP store, and then directly deleted in LDAP,
>> won't be returned if queries even if he is still in Keycloak database.
>> Not sure if it's good or bad as he may not be able to login anyway...
>>
>
> Was going to change it in that if a returned UserModel is linked, to 
> check that it is still valid for the federation and delete it if it is 
> not.
+1
>
>> However for LDAP it's tricky... I've tested with ActiveDirectory that I
>> can query with same cookie to random LDAP pages (next page or any page
>> which I already previously visited), but looks that just next page is
>> always guaranteed to work but previous pages are not guaranteed
>> according to http://www.ietf.org/rfc/rfc2696.txt sentence:
>> "Returning cookies from previous searchResultDone responses besides the
>> last one is undefined, as the server implementation may restrict cookies
>> from being reused."
>>
>
> for now the federation interface for queries will be:
>
> UserModel getUserByUsername(RealmModel realm, String username)
> UserModel getUserByEmail(RealmModel realm, String email)
> List<UserModel> getUserByLastName((RealmModel realm, String last)
> List<UserModel> getUserByFullName((RealmModel realm, String first, 
> String last);
>
> No pagination.  No paginated getAllUsers() and thus, no sync API. If 
> you can figure out something reliable in the next week *AND* get us a 
> new Picketlink release, we can use it in 1.0.Final. Otherwise, it is 
> just going to have to wait I guess.
+1 to skip pagination from FederationProvider.

But I think that at least one way sync from LDAP to Keycloak database 
should be possible. We already have support for ScheduledTask, which 
allow to do periodic syncs. IMO the tricky parts are:

* pagination --- It might be needed as for example with 1 million users 
in LDAP, you will need multiple transaction to sync them all into 
Keycloak database. Some LDAP servers supports it and some not (generally 
said some Sync providers may support but some may not. It must be 
possible to configure if particular Sync Provider supports it).

Regarding pagination, note that it's quite an issue for 
federationProvider, but not for sync as sync process have full control 
when to begin/commit transactions and also have access to all needed 
info (like cookies from LDAP)

* Changelogs --- More tricky, but at least Active Directory (which seems 
to be major LDAP vendor) has support for it. The tricky part (also in 
AD) seems to be tracking of removed users (those which were directly 
removed in LDAP). So from time to time, it may be always good to do full 
sync

* Configuration in admin console - It should be possible to choose Sync 
provider and then to configure:
- if pagination will be used or not
- if changelogs (partial sync) will be used or not
- if to use periodic sync
- how often to do full sync, how often to do partial sync (if supported) 
etc...
- Possibility to trigger full or partial sync directly from admin 
console etc.

I hope to figure it out more during this week as you suggested..

Marek



From bburke at redhat.com  Mon Jul 28 07:24:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 28 Jul 2014 07:24:10 -0400
Subject: [keycloak-dev] federation iteration 2
In-Reply-To: <1324371108.18912250.1406536783359.JavaMail.zimbra@redhat.com>
References: <53D30243.3080500@redhat.com>
	<1324371108.18912250.1406536783359.JavaMail.zimbra@redhat.com>
Message-ID: <53D632DA.6020008@redhat.com>

Can't drop pagination indefinitely.  Background sync will need it.  But 
for now, all of your suggestions are great.

On 7/28/2014 4:39 AM, Stian Thorgersen wrote:
> Here's a thought, what about dropping pagination and instead returning a maximum number of users.
>
> If an admin is looking for a specific user the admin is not going to want to page through 10K users. So we could return say 50 users, with a message saying "your search returned to many results, please refine your search". Then we can improve the search feature to give better control on finding a specific user. This could include:
>
> * Separate fields for first, last, username and email
> * Registration date
> * Other fields once we add customized profiles (for example DOB)
> * By social username
> * By role
>
> That should make much it easier to aggregate the results from the internal db and federated stores.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Saturday, 26 July, 2014 2:20:03 AM
>> Subject: [keycloak-dev] federation iteration 2
>>
>> * UserProvider interface stayed the same
>> * Didn't add a UserFederation interface like I said I was going to,
>> didn't have to.
>> * UserFederationProvider interface no longer extends UserProvider and is
>> smaller
>> * UserFederationProvider no longer supports pagination
>> * UserFederationProvider no longer supports getUsers().  This is a very
>> dangerous method for large databases since we can't reliable support
>> pagination.
>>
>> How does pagination work now?
>>
>> * getUsers() only queries local storage
>> * search() methods will call searchByAttributes() on every provider.
>> Then paginate based on local storage.  This may result in long query
>> times (and database inserts) depending how many people of the same name
>> there are.  In a database of 1 million, not sure what the distribution
>> will be.  For example, the most popular US name is "Smith" there are 2.8
>> million which is less than 1% of the USA.
>>
>> But, I'm not sure what to do.  Admins *MUST* be able to search based on
>> names.  What would reduce the search would be to require both first and
>> last name.
>>
>> --
>> 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 Jul 28 07:29:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 28 Jul 2014 07:29:01 -0400
Subject: [keycloak-dev] federated pagination Re: federation commited
 need feedback
In-Reply-To: <53D61538.4060208@redhat.com>
References: <53D02A18.3060007@redhat.com> <53D0D27E.2020504@redhat.com>
	<53D10861.10709@redhat.com> <53D14793.4030406@redhat.com>
	<53D1579A.4000507@redhat.com> <53D20550.1070802@redhat.com>
	<53D25F01.1060601@redhat.com> <53D28340.7030607@redhat.com>
	<53D28860.90503@redhat.com> <53D29FC7.9040403@redhat.com>
	<53D2AFEC.4010707@redhat.com> <53D61538.4060208@redhat.com>
Message-ID: <53D633FD.4000909@redhat.com>



On 7/28/2014 5:17 AM, Marek Posolda wrote:
> On 25.7.2014 21:28, Bill Burke wrote:
>>
>>
>> On 7/25/2014 2:19 PM, Marek Posolda wrote:
>>> I am already on picketlink master and trying to address the issues we
>>> have. Right now mapping of dynamic attributes aka
>>> https://issues.jboss.org/browse/PLINK-533 . I don't know when exactly is
>>> picketlink release planned, but maybe we can ask Pedro to do at least
>>> timestamped release somewhen next week?
>>>
>>> I wonder that random searches with FederationProvider might work for
>>> implementations, which supports offset/limit (like external database
>>> provided by customer) with your idea of omit local users with federation
>>> link? There are more tricky things though, like if user "john" available
>>> in in both local and LDAP store, and then directly deleted in LDAP,
>>> won't be returned if queries even if he is still in Keycloak database.
>>> Not sure if it's good or bad as he may not be able to login anyway...
>>>
>>
>> Was going to change it in that if a returned UserModel is linked, to
>> check that it is still valid for the federation and delete it if it is
>> not.
> +1
>>
>>> However for LDAP it's tricky... I've tested with ActiveDirectory that I
>>> can query with same cookie to random LDAP pages (next page or any page
>>> which I already previously visited), but looks that just next page is
>>> always guaranteed to work but previous pages are not guaranteed
>>> according to http://www.ietf.org/rfc/rfc2696.txt sentence:
>>> "Returning cookies from previous searchResultDone responses besides the
>>> last one is undefined, as the server implementation may restrict cookies
>>> from being reused."
>>>
>>
>> for now the federation interface for queries will be:
>>
>> UserModel getUserByUsername(RealmModel realm, String username)
>> UserModel getUserByEmail(RealmModel realm, String email)
>> List<UserModel> getUserByLastName((RealmModel realm, String last)
>> List<UserModel> getUserByFullName((RealmModel realm, String first,
>> String last);
>>
>> No pagination.  No paginated getAllUsers() and thus, no sync API. If
>> you can figure out something reliable in the next week *AND* get us a
>> new Picketlink release, we can use it in 1.0.Final. Otherwise, it is
>> just going to have to wait I guess.
> +1 to skip pagination from FederationProvider.
>
> But I think that at least one way sync from LDAP to Keycloak database
> should be possible. We already have support for ScheduledTask, which
> allow to do periodic syncs. IMO the tricky parts are:
>
> * pagination --- It might be needed as for example with 1 million users
> in LDAP, you will need multiple transaction to sync them all into
> Keycloak database. Some LDAP servers supports it and some not (generally
> said some Sync providers may support but some may not. It must be
> possible to configure if particular Sync Provider supports it).
>
> Regarding pagination, note that it's quite an issue for
> federationProvider, but not for sync as sync process have full control
> when to begin/commit transactions and also have access to all needed
> info (like cookies from LDAP)
>
> * Changelogs --- More tricky, but at least Active Directory (which seems
> to be major LDAP vendor) has support for it. The tricky part (also in
> AD) seems to be tracking of removed users (those which were directly
> removed in LDAP). So from time to time, it may be always good to do full
> sync
>
> * Configuration in admin console - It should be possible to choose Sync
> provider and then to configure:
> - if pagination will be used or not
> - if changelogs (partial sync) will be used or not
> - if to use periodic sync
> - how often to do full sync, how often to do partial sync (if supported)
> etc...
> - Possibility to trigger full or partial sync directly from admin
> console etc.
>

Sync's should be configured directly with the federation provider.  Or, 
when defining a sync, you can link it to a federation provider.  I don't 
want to have to specify configuration twice.

All of those configuration options are all LDAP specific and should be 
configured with the LDAP provider.

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

From stian at redhat.com  Mon Jul 28 08:13:16 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 28 Jul 2014 08:13:16 -0400 (EDT)
Subject: [keycloak-dev] federation iteration 2
In-Reply-To: <53D632DA.6020008@redhat.com>
References: <53D30243.3080500@redhat.com>
	<1324371108.18912250.1406536783359.JavaMail.zimbra@redhat.com>
	<53D632DA.6020008@redhat.com>
Message-ID: <1973712227.19030192.1406549596275.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 28 July, 2014 12:24:10 PM
> Subject: Re: [keycloak-dev] federation iteration 2
> 
> Can't drop pagination indefinitely.  Background sync will need it.  But
> for now, all of your suggestions are great.

I was only thinking about dropping pagination for admin console/endpoints.

For background sync wouldn't it be up to the federation provider to handle it? For example for LDAP if you need a cookie to manage the pagination the LDAP federation provider can just hold that internally while syncing.

> 
> On 7/28/2014 4:39 AM, Stian Thorgersen wrote:
> > Here's a thought, what about dropping pagination and instead returning a
> > maximum number of users.
> >
> > If an admin is looking for a specific user the admin is not going to want
> > to page through 10K users. So we could return say 50 users, with a message
> > saying "your search returned to many results, please refine your search".
> > Then we can improve the search feature to give better control on finding a
> > specific user. This could include:
> >
> > * Separate fields for first, last, username and email
> > * Registration date
> > * Other fields once we add customized profiles (for example DOB)
> > * By social username
> > * By role
> >
> > That should make much it easier to aggregate the results from the internal
> > db and federated stores.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Saturday, 26 July, 2014 2:20:03 AM
> >> Subject: [keycloak-dev] federation iteration 2
> >>
> >> * UserProvider interface stayed the same
> >> * Didn't add a UserFederation interface like I said I was going to,
> >> didn't have to.
> >> * UserFederationProvider interface no longer extends UserProvider and is
> >> smaller
> >> * UserFederationProvider no longer supports pagination
> >> * UserFederationProvider no longer supports getUsers().  This is a very
> >> dangerous method for large databases since we can't reliable support
> >> pagination.
> >>
> >> How does pagination work now?
> >>
> >> * getUsers() only queries local storage
> >> * search() methods will call searchByAttributes() on every provider.
> >> Then paginate based on local storage.  This may result in long query
> >> times (and database inserts) depending how many people of the same name
> >> there are.  In a database of 1 million, not sure what the distribution
> >> will be.  For example, the most popular US name is "Smith" there are 2.8
> >> million which is less than 1% of the USA.
> >>
> >> But, I'm not sure what to do.  Admins *MUST* be able to search based on
> >> names.  What would reduce the search would be to require both first and
> >> last name.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From psilva at redhat.com  Mon Jul 28 09:37:08 2014
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 28 Jul 2014 09:37:08 -0400 (EDT)
Subject: [keycloak-dev] PicketLink and KC Integration
In-Reply-To: <53D3A6D7.9040307@redhat.com>
References: <142955219.11927742.1406082453260.JavaMail.zimbra@redhat.com>
	<1655560233.12115214.1406119609606.JavaMail.zimbra@redhat.com>
	<53CFC1CC.9000906@redhat.com>
	<1333503184.12288625.1406129586141.JavaMail.zimbra@redhat.com>
	<1245327733.13568276.1406325508805.JavaMail.zimbra@redhat.com>
	<53D3080F.3060307@redhat.com>
	<274006442.13606222.1406340021870.JavaMail.zimbra@redhat.com>
	<53D3A6D7.9040307@redhat.com>
Message-ID: <1332813675.14183918.1406554628569.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Saturday, July 26, 2014 10:02:15 AM
> Subject: Re: [keycloak-dev] PicketLink and KC Integration
> 
> 
> 
> On 7/25/2014 10:00 PM, Pedro Igor Silva wrote:
> > I'll, thanks for the heads up. And yes, PL and Spring Security are in the
> > same area. But as I said, we have a big TODO here:
> >
> > https://gist.github.com/pedroigor/5852028
> >
> > Anil and I wrote that some time ago, but you can have an idea about our
> > plans for servlet security.
> >
> 
> That would be interesting if it was cross-platform and did tight
> integration with each platform (i.e. AS7, EAP, Wildfly 8-9, Jetty,
> Tomcat, etc...) as well with Java EE security.  Then Keycloak could get
> out of the adapter business.  At least for Java...

Interesting. We can consider that. In theory, JASPI can help here. Problem is how it is currently offered by those different platforms.

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

From vivsriva at cisco.com  Mon Jul 28 10:45:03 2014
From: vivsriva at cisco.com (Vivek Srivastav (vivsriva))
Date: Mon, 28 Jul 2014 14:45:03 +0000
Subject: [keycloak-dev] Error while logging in through the demo application
Message-ID: <CFFBDA39.3BA7E%vivsriva@cisco.com>


Hi,
I am getting error while logging into to access customer-list in the demo application. Is there a problem in my configuration, or is there a fix/workaround available.

Environment:
keycloak appliance 1.0-beta-3.

Settings:
Using the default datastore.
Configured the customer-app and product-app as per the instructions and deployed in the keyclock server.

Steps/Actions:

Apps: unconfigured-demo apps built and deployed using maven.
When logging into keycloak I am getting ?Forbidden?
JBWEB000065: HTTP Status 403 -
________________________________

JBWEB000309: type JBWEB000067: Status report

JBWEB000068: message

JBWEB000069: description JBWEB000123: Access to the specified resource has been forbidden.

________________________________
JBoss Web/7.2.2.Final-redhat-1

Following is the error I get on the keycloak console:


10:29:45,968 ERROR [io.undertow.request] (default task-45) UT005023: Exception handling request to /auth/realms/demo/tokens/access/codes: java.lang.RuntimeException: request path: /auth/realms/demo/tokens/access/codes

at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:56) [keycloak-services-1.0-beta-3.jar:]

at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]

at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException

at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]

at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0-beta-3.jar:]

at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:42) [keycloak-services-1.0-beta-3.jar:]

... 28 more

Caused by: java.lang.NullPointerException

at org.keycloak.models.jpa.ClientAdapter.validateSecret(ClientAdapter.java:142) [keycloak-model-jpa-1.0-beta-3.jar:]

at org.keycloak.services.resources.TokenService.authorizeClient(TokenService.java:779) [keycloak-services-1.0-beta-3.jar:]

at org.keycloak.services.resources.TokenService.accessCodeToToken(TokenService.java:665) [keycloak-services-1.0-beta-3.jar:]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]

at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]

at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]

... 39 more


10:29:45,978 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) failed to turn code into token

10:29:45,979 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) status from server: 500

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

From stian at redhat.com  Mon Jul 28 12:14:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 28 Jul 2014 12:14:21 -0400 (EDT)
Subject: [keycloak-dev] Access code length
In-Reply-To: <266235904.19252736.1406563028336.JavaMail.zimbra@redhat.com>
Message-ID: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>

I've made the changes to access code, but I'm still not happy with the length.

The old access code containing all the details (including access token and id token) was at least 1000 characters long (with more roles and id token details that would have been even bigger!).

The new access code length is 259 characters. I think this is still to big and would like to reduce it. The way I'm currently creating it is taking the ID (UUID.randomUUID() + System.currentTimeMillis()) and using JWSBuilder to add a signature. Example:

  eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM

I checked Google it's just:

  4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI

Suggestions welcome ;)

From mposolda at redhat.com  Mon Jul 28 12:59:51 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 28 Jul 2014 18:59:51 +0200
Subject: [keycloak-dev] Access code length
In-Reply-To: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>
References: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>
Message-ID: <53D68187.7060805@redhat.com>

Something, which comes to my mind:

* Omit the header part with algorithm info and instead assume that code 
is always signed with rsa-256 (or whatever different algorithm)

* Is it really needed to have System.currentTimeMillis() info here? I 
wonder if this timestamp info can be extracted to server side as well, 
so when code is later looked-up, you will also have info about the time 
when it was created without the need of pass this info as part of the code

* It seems that the biggest part (around 170 characters) is signature. I 
wonder that it can be reduced by either:
** Use not so strong algorithm to sign the code (not sure if it's 
security issue as code is one time usage though and it's better than 
avoid signature at all...)
** Actually it's keycloak itself, which verifies signature. So I wonder 
if instead of passing the whole signature around, it can just pass the 
hash of signature (just few characters). Then later during verification 
phase, it has access to whole accessCode content, so it can sign the 
content again and compute again the hash of signature and compare it 
with the hash passed from code parameter.

Marek

On 28.7.2014 18:14, Stian Thorgersen wrote:
> I've made the changes to access code, but I'm still not happy with the length.
>
> The old access code containing all the details (including access token and id token) was at least 1000 characters long (with more roles and id token details that would have been even bigger!).
>
> The new access code length is 259 characters. I think this is still to big and would like to reduce it. The way I'm currently creating it is taking the ID (UUID.randomUUID() + System.currentTimeMillis()) and using JWSBuilder to add a signature. Example:
>
>    eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM
>
> I checked Google it's just:
>
>    4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI
>
> Suggestions welcome ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From vivsriva at cisco.com  Mon Jul 28 14:17:31 2014
From: vivsriva at cisco.com (Vivek Srivastav (vivsriva))
Date: Mon, 28 Jul 2014 18:17:31 +0000
Subject: [keycloak-dev] Error while logging in through the demo
 application
Message-ID: <CFFC0B69.3BAA9%vivsriva@cisco.com>

After changing the access_type to ?public" from "confidential", the error went away.

From: Vivek Srivastav <vivsriva at cisco.com<mailto:vivsriva at cisco.com>>
Date: Monday, July 28, 2014 at 10:45 AM
To: "keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>" <keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>>
Subject: [keycloak-dev] Error while logging in through the demo application


Hi,
I am getting error while logging into to access customer-list in the demo application. Is there a problem in my configuration, or is there a fix/workaround available.

Environment:
keycloak appliance 1.0-beta-3.

Settings:
Using the default datastore.
Configured the customer-app and product-app as per the instructions and deployed in the keyclock server.

Steps/Actions:

Apps: unconfigured-demo apps built and deployed using maven.
When logging into keycloak I am getting ?Forbidden?
JBWEB000065: HTTP Status 403 -
________________________________

JBWEB000309: type JBWEB000067: Status report

JBWEB000068: message

JBWEB000069: description JBWEB000123: Access to the specified resource has been forbidden.

________________________________
JBoss Web/7.2.2.Final-redhat-1

Following is the error I get on the keycloak console:


10:29:45,968 ERROR [io.undertow.request] (default task-45) UT005023: Exception handling request to /auth/realms/demo/tokens/access/codes: java.lang.RuntimeException: request path: /auth/realms/demo/tokens/access/codes

at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:56) [keycloak-services-1.0-beta-3.jar:]

at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]

at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]

Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException

at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]

at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]

at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0-beta-3.jar:]

at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:42) [keycloak-services-1.0-beta-3.jar:]

... 28 more

Caused by: java.lang.NullPointerException

at org.keycloak.models.jpa.ClientAdapter.validateSecret(ClientAdapter.java:142) [keycloak-model-jpa-1.0-beta-3.jar:]

at org.keycloak.services.resources.TokenService.authorizeClient(TokenService.java:779) [keycloak-services-1.0-beta-3.jar:]

at org.keycloak.services.resources.TokenService.accessCodeToToken(TokenService.java:665) [keycloak-services-1.0-beta-3.jar:]

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_45]

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_45]

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]

at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]

at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103) [resteasy-jaxrs-3.0.8.Final.jar:]

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]

... 39 more


10:29:45,978 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) failed to turn code into token

10:29:45,979 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-46) status from server: 500

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

From bburke at redhat.com  Mon Jul 28 14:48:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 28 Jul 2014 14:48:34 -0400
Subject: [keycloak-dev] Access code length
In-Reply-To: <53D68187.7060805@redhat.com>
References: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>
	<53D68187.7060805@redhat.com>
Message-ID: <53D69B02.3030204@redhat.com>

Smaller hash (sha1 or md5) is really the only thing you can do beyond 
removing the JWS header.  But, if you're going to do that, might as well 
just ditch the signature altogether.  If anything, over time, we'd be 
using larger hashes not smaller ones.

HMAC is smaller, but that would require a realm secret key.

With a HMAC header and computing the JWS of:

         String uuid = UUID.randomUUID().toString();


156 chars for HMAC 512 secret key
113 chars for HMAC 256 key
99 chars for HMAC SHA1 (We'd have to implement SHA1 which would be easy 
to add)


Header is 20+ characters.  uuid is 36 chars.

My bet is that Google is using HMAC + SHA-1





On 7/28/2014 12:59 PM, Marek Posolda wrote:
> Something, which comes to my mind:
>
> * Omit the header part with algorithm info and instead assume that code
> is always signed with rsa-256 (or whatever different algorithm)
>
> * Is it really needed to have System.currentTimeMillis() info here? I
> wonder if this timestamp info can be extracted to server side as well,
> so when code is later looked-up, you will also have info about the time
> when it was created without the need of pass this info as part of the code
>
> * It seems that the biggest part (around 170 characters) is signature. I
> wonder that it can be reduced by either:
> ** Use not so strong algorithm to sign the code (not sure if it's
> security issue as code is one time usage though and it's better than
> avoid signature at all...)
> ** Actually it's keycloak itself, which verifies signature. So I wonder
> if instead of passing the whole signature around, it can just pass the
> hash of signature (just few characters). Then later during verification
> phase, it has access to whole accessCode content, so it can sign the
> content again and compute again the hash of signature and compare it
> with the hash passed from code parameter.
>
> Marek
>
> On 28.7.2014 18:14, Stian Thorgersen wrote:
>> I've made the changes to access code, but I'm still not happy with the length.
>>
>> The old access code containing all the details (including access token and id token) was at least 1000 characters long (with more roles and id token details that would have been even bigger!).
>>
>> The new access code length is 259 characters. I think this is still to big and would like to reduce it. The way I'm currently creating it is taking the ID (UUID.randomUUID() + System.currentTimeMillis()) and using JWSBuilder to add a signature. Example:
>>
>>     eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM
>>
>> I checked Google it's just:
>>
>>     4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI
>>
>> Suggestions welcome ;)
>> _______________________________________________
>> 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 bburke at redhat.com  Mon Jul 28 14:49:23 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 28 Jul 2014 14:49:23 -0400
Subject: [keycloak-dev] Error while logging in through the demo
	application
In-Reply-To: <CFFC0B69.3BAA9%vivsriva@cisco.com>
References: <CFFC0B69.3BAA9%vivsriva@cisco.com>
Message-ID: <53D69B33.9000307@redhat.com>

It has to match (public or confidential) with  whatever you configured 
the application to be in the admin console

On 7/28/2014 2:17 PM, Vivek Srivastav (vivsriva) wrote:
> After changing the access_type to ?public" from "confidential", the
> error went away.
>
> From: Vivek Srivastav <vivsriva at cisco.com <mailto:vivsriva at cisco.com>>
> Date: Monday, July 28, 2014 at 10:45 AM
> To: "keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>"
> <keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>>
> Subject: [keycloak-dev] Error while logging in through the demo application
>
>
> Hi,
> I am getting error while logging into to access customer-list in the
> demo application. Is there a problem in my configuration, or is there a
> fix/workaround available.
>
> *Environment:*
> keycloak appliance 1.0-beta-3.
>
> *Settings:*
> Using the default datastore.
> Configured the customer-app and product-app as per the instructions and
> deployed in the keyclock server.
>
> *Steps/Actions:*
>
> Apps: unconfigured-demo apps built and deployed using maven.
> When logging into keycloak I am getting ?Forbidden?
>
>
>   JBWEB000065: HTTP Status 403 -
>
> ------------------------------------------------------------------------
>
> *JBWEB000309: type* JBWEB000067: Status report
>
> *JBWEB000068: message*__
>
> *JBWEB000069: description* _JBWEB000123: Access to the specified
> resource has been forbidden._
>
> ------------------------------------------------------------------------
>
>
>       JBoss Web/7.2.2.Final-redhat-1
>
>
> Following is the error I get on the keycloak console:
>
> 10:29:45,968 ERROR [io.undertow.request] (default task-45) UT005023:
> Exception handling request to /auth/realms/demo/tokens/access/codes:
> java.lang.RuntimeException: request path:
> /auth/realms/demo/tokens/access/codes
>
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:56)
> [keycloak-services-1.0-beta-3.jar:]
>
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_45]
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_45]
>
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
>
> Caused by: org.jboss.resteasy.spi.UnhandledException:
> java.lang.NullPointerException
>
> at
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>
> at
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41)
> [keycloak-services-1.0-beta-3.jar:]
>
> at
> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132)
> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>
> at
> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:42)
> [keycloak-services-1.0-beta-3.jar:]
>
> ... 28 more
>
> Caused by: java.lang.NullPointerException
>
> at
> org.keycloak.models.jpa.ClientAdapter.validateSecret(ClientAdapter.java:142)
> [keycloak-model-jpa-1.0-beta-3.jar:]
>
> at
> org.keycloak.services.resources.TokenService.authorizeClient(TokenService.java:779)
> [keycloak-services-1.0-beta-3.jar:]
>
> at
> org.keycloak.services.resources.TokenService.accessCodeToToken(TokenService.java:665)
> [keycloak-services-1.0-beta-3.jar:]
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.7.0_45]
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [rt.jar:1.7.0_45]
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.7.0_45]
>
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
>
> at
> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:140)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:103)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> at
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356)
> [resteasy-jaxrs-3.0.8.Final.jar:]
>
> ... 39 more
>
>
> 10:29:45,978 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
> (default task-46) failed to turn code into token
>
> 10:29:45,979 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
> (default task-46) status from server: 500
>
>
>
>
> _______________________________________________
> 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 vivsriva at cisco.com  Mon Jul 28 16:04:18 2014
From: vivsriva at cisco.com (Vivek Srivastav (vivsriva))
Date: Mon, 28 Jul 2014 20:04:18 +0000
Subject: [keycloak-dev] Error while logging in through the demo
 application
In-Reply-To: <53D69B33.9000307@redhat.com>
References: <CFFC0B69.3BAA9%vivsriva@cisco.com> <53D69B33.9000307@redhat.com>
Message-ID: <CFFC24D7.3BABC%vivsriva@cisco.com>

Hi Bill,
Got it. Thanks. It is working with both ?public? and ?confidential?.
Regards,
Vivek

On 7/28/14, 2:49 PM, "Bill Burke" <bburke at redhat.com> wrote:

>It has to match (public or confidential) with  whatever you configured
>the application to be in the admin console
>
>On 7/28/2014 2:17 PM, Vivek Srivastav (vivsriva) wrote:
>> After changing the access_type to ?public" from "confidential", the
>> error went away.
>>
>> From: Vivek Srivastav <vivsriva at cisco.com <mailto:vivsriva at cisco.com>>
>> Date: Monday, July 28, 2014 at 10:45 AM
>> To: "keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>"
>> <keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>>
>> Subject: [keycloak-dev] Error while logging in through the demo
>>application
>>
>>
>> Hi,
>> I am getting error while logging into to access customer-list in the
>> demo application. Is there a problem in my configuration, or is there a
>> fix/workaround available.
>>
>> *Environment:*
>> keycloak appliance 1.0-beta-3.
>>
>> *Settings:*
>> Using the default datastore.
>> Configured the customer-app and product-app as per the instructions and
>> deployed in the keyclock server.
>>
>> *Steps/Actions:*
>>
>> Apps: unconfigured-demo apps built and deployed using maven.
>> When logging into keycloak I am getting ?Forbidden?
>>
>>
>>   JBWEB000065: HTTP Status 403 -
>>
>> ------------------------------------------------------------------------
>>
>> *JBWEB000309: type* JBWEB000067: Status report
>>
>> *JBWEB000068: message*__
>>
>> *JBWEB000069: description* _JBWEB000123: Access to the specified
>> resource has been forbidden._
>>
>> ------------------------------------------------------------------------
>>
>>
>>       JBoss Web/7.2.2.Final-redhat-1
>>
>>
>> Following is the error I get on the keycloak console:
>>
>> 10:29:45,968 ERROR [io.undertow.request] (default task-45) UT005023:
>> Exception handling request to /auth/realms/demo/tokens/access/codes:
>> java.lang.RuntimeException: request path:
>> /auth/realms/demo/tokens/access/codes
>>
>> at
>> 
>>org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(Keycl
>>oakSessionServletFilter.java:56)
>> [keycloak-services-1.0-beta-3.jar:]
>>
>> at
>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.ja
>>va:85)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRe
>>quest(ServletSecurityRoleHandler.java:61)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(Serv
>>letDispatchingHandler.java:36)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>org.wildfly.extension.undertow.security.SecurityContextAssociationHandler
>>.handleRequest(SecurityContextAssociationHandler.java:78)
>>
>> at
>> 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:25)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.ha
>>ndleRequest(SSLInformationAssociationHandler.java:113)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.ha
>>ndleRequest(ServletAuthenticationCallHandler.java:56)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:25)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.security.handlers.AbstractConfidentialityHandler.handleReques
>>t(AbstractConfidentialityHandler.java:45)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHan
>>dler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.security.handlers.AuthenticationMechanismsHandler.handleReque
>>st(AuthenticationMechanismsHandler.java:58)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.h
>>andleRequest(CachedAuthenticatedSessionHandler.java:70)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.security.handlers.SecurityInitialHandler.handleRequest(Securi
>>tyInitialHandler.java:76)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:25)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleR
>>equest(JACCContextIdHandler.java:61)
>>
>> at
>> 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:25)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandl
>>er.java:25)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(Ser
>>vletInitialHandler.java:240)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(Servle
>>tInitialHandler.java:227)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInit
>>ialHandler.java:73)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(Servle
>>tInitialHandler.java:146)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
>> [undertow-core-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java
>>:1145)
>> [rt.jar:1.7.0_45]
>>
>> at
>> 
>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav
>>a:615)
>> [rt.jar:1.7.0_45]
>>
>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
>>
>> Caused by: org.jboss.resteasy.spi.UnhandledException:
>> java.lang.NullPointerException
>>
>> at
>> 
>>org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(Excep
>>tionHandler.java:76)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler
>>.java:212)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousD
>>ispatcher.java:149)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>r.java:372)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>r.java:179)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.serv
>>ice(ServletContainerDispatcher.java:220)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>ttpServletDispatcher.java:56)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(H
>>ttpServletDispatcher.java:51)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>> [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.
>>java:85)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:130)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConne
>>ctionFilter.java:41)
>> [keycloak-services-1.0-beta-3.jar:]
>>
>> at
>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(Filte
>>rHandler.java:132)
>> [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
>>
>> at
>> 
>>org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(Keycl
>>oakSessionServletFilter.java:42)
>> [keycloak-services-1.0-beta-3.jar:]
>>
>> ... 28 more
>>
>> Caused by: java.lang.NullPointerException
>>
>> at
>> 
>>org.keycloak.models.jpa.ClientAdapter.validateSecret(ClientAdapter.java:1
>>42)
>> [keycloak-model-jpa-1.0-beta-3.jar:]
>>
>> at
>> 
>>org.keycloak.services.resources.TokenService.authorizeClient(TokenService
>>.java:779)
>> [keycloak-services-1.0-beta-3.jar:]
>>
>> at
>> 
>>org.keycloak.services.resources.TokenService.accessCodeToToken(TokenServi
>>ce.java:665)
>> [keycloak-services-1.0-beta-3.jar:]
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> [rt.jar:1.7.0_45]
>>
>> at
>> 
>>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
>>:57)
>> [rt.jar:1.7.0_45]
>>
>> at
>> 
>>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
>>mpl.java:43)
>> [rt.jar:1.7.0_45]
>>
>> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]
>>
>> at
>> 
>>org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java
>>:137)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMeth
>>odInvoker.java:296)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoke
>>r.java:250)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(Resou
>>rceLocatorInvoker.java:140)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvo
>>ker.java:103)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> at
>> 
>>org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatche
>>r.java:356)
>> [resteasy-jaxrs-3.0.8.Final.jar:]
>>
>> ... 39 more
>>
>>
>> 10:29:45,978 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>> (default task-46) failed to turn code into token
>>
>> 10:29:45,979 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator]
>> (default task-46) status from server: 500
>>
>>
>>
>>
>> _______________________________________________
>> 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 mposolda at redhat.com  Tue Jul 29 03:25:06 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 29 Jul 2014 09:25:06 +0200
Subject: [keycloak-dev] Oauth Register and Token Validation Example
In-Reply-To: <CADYyO+VKC0cSkbHvmY2vJerB9PJ_J_h4fmdc3bsLy1VtamYMFw@mail.gmail.com>
References: <CADYyO+X_0xuUjYr9D1awpbYLt5xmMjKJapKz5cw0BYN+p-+q=Q@mail.gmail.com>
	<CADYyO+VKC0cSkbHvmY2vJerB9PJ_J_h4fmdc3bsLy1VtamYMFw@mail.gmail.com>
Message-ID: <53D74C52.2090805@redhat.com>

Hi,

the best is to start with documentation 
http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html 
and also look at existing examples 
https://github.com/keycloak/keycloak/tree/master/examples . Probably 
most useful for you might be 
https://github.com/keycloak/keycloak/tree/master/examples/demo-template 
. It has restful application "database-service", where you can send 
secured REST requests with the bearer token attached to them. Other 
applications in the directory are web applications, which obtain bearer 
token from the Keycloak login . Product-portal and customer-portal are 
JEE applications secured by Keycloak itself, third-party and 
third-party-cdi is more traditional OAuth where token is used just to 
retrieve the secured data from "database-service" . See the README for 
more info.

Example for CORS support is here: 
https://github.com/keycloak/keycloak/tree/master/examples/cors

Marek

On 25.7.2014 23:04, Harit Himanshu wrote:
> Hey Team,
>
> I am been looking for answer to 
> http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis and 
> found that keycloak is suitable for securing REST APIs using OAuth 2.0.
>
> I am looking for example where the following is demonstrated
> a.) Third-party app registers and gets Access Token
> b.) Third-Party app accesses Resource Server to access protected 
> resource by sending Access Token to REST API
> c.) and How Token is validated.
>
>
> It is mentioned in features of keycloak as
>
>   * OAuth Bearer token auth for REST Services
>   * OAuth 2.0 Grant requests
>   * CORS Support
>
> Can you please guide me through examples?
>
> Thank you
>
>
> On Fri, Jul 25, 2014 at 2:00 PM, Harit Himanshu 
> <harit.subscriptions at gmail.com <mailto:harit.subscriptions at gmail.com>> 
> wrote:
>
>     Hey Team,
>
>     I am been looking for answer to
>     http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis
>     and found that keycloak is suitable for securing REST APIs using
>     OAuth 2.0.
>
>     I am looking for example where the following is demonstrated
>     a.) Third-party app registers and gets Access Token
>     b.) Third-Party app accesses Resource Server to access protected
>     resource by sending Access Token to REST API
>     c.) and How Token is validated.
>
>
>     It is mentioned in features of keycloak as
>
>       * OAuth Bearer token auth for REST Services
>       * OAuth 2.0 Grant requests
>       * CORS Support
>
>     Can you please guide me through examples?
>
>     Thank you
>     + Harit Himanshu
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

From stian at redhat.com  Tue Jul 29 05:53:58 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 05:53:58 -0400 (EDT)
Subject: [keycloak-dev] Access code length
In-Reply-To: <53D69B02.3030204@redhat.com>
References: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>
	<53D68187.7060805@redhat.com> <53D69B02.3030204@redhat.com>
Message-ID: <945694568.19717091.1406627638484.JavaMail.zimbra@redhat.com>

Thanks for suggestions.

Now the code looks like:

  xuAZKwa2EkX_WBHp-LPHXXQYKc0.YjUzMmRhODAtZTFkZS00MTZjLTk1ZjktNGJlMGYxMDNmNGE2LTE0MDY2Mjc0NDg4NjE

This consists of two parts (both Base64 url-encoded):

  <Hashed Signature>.<ID>

The hashed signature is the SHA-1 digest of the SHA256withRSA signature of ID + timestamp + action

To verify a code the details for the AccessCode is retrieved using the first part of the code. Then the hashed signature is created from the stored details and compared to the first part of the code.

This provides both brute force protection, and also protects against UUID collisions (which should be very unlikely, but still).

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 28 July, 2014 7:48:34 PM
> Subject: Re: [keycloak-dev] Access code length
> 
> Smaller hash (sha1 or md5) is really the only thing you can do beyond
> removing the JWS header.  But, if you're going to do that, might as well
> just ditch the signature altogether.  If anything, over time, we'd be
> using larger hashes not smaller ones.
> 
> HMAC is smaller, but that would require a realm secret key.
> 
> With a HMAC header and computing the JWS of:
> 
>          String uuid = UUID.randomUUID().toString();
> 
> 
> 156 chars for HMAC 512 secret key
> 113 chars for HMAC 256 key
> 99 chars for HMAC SHA1 (We'd have to implement SHA1 which would be easy
> to add)
> 
> 
> Header is 20+ characters.  uuid is 36 chars.
> 
> My bet is that Google is using HMAC + SHA-1
> 
> 
> 
> 
> 
> On 7/28/2014 12:59 PM, Marek Posolda wrote:
> > Something, which comes to my mind:
> >
> > * Omit the header part with algorithm info and instead assume that code
> > is always signed with rsa-256 (or whatever different algorithm)
> >
> > * Is it really needed to have System.currentTimeMillis() info here? I
> > wonder if this timestamp info can be extracted to server side as well,
> > so when code is later looked-up, you will also have info about the time
> > when it was created without the need of pass this info as part of the code
> >
> > * It seems that the biggest part (around 170 characters) is signature. I
> > wonder that it can be reduced by either:
> > ** Use not so strong algorithm to sign the code (not sure if it's
> > security issue as code is one time usage though and it's better than
> > avoid signature at all...)
> > ** Actually it's keycloak itself, which verifies signature. So I wonder
> > if instead of passing the whole signature around, it can just pass the
> > hash of signature (just few characters). Then later during verification
> > phase, it has access to whole accessCode content, so it can sign the
> > content again and compute again the hash of signature and compare it
> > with the hash passed from code parameter.
> >
> > Marek
> >
> > On 28.7.2014 18:14, Stian Thorgersen wrote:
> >> I've made the changes to access code, but I'm still not happy with the
> >> length.
> >>
> >> The old access code containing all the details (including access token and
> >> id token) was at least 1000 characters long (with more roles and id token
> >> details that would have been even bigger!).
> >>
> >> The new access code length is 259 characters. I think this is still to big
> >> and would like to reduce it. The way I'm currently creating it is taking
> >> the ID (UUID.randomUUID() + System.currentTimeMillis()) and using
> >> JWSBuilder to add a signature. Example:
> >>
> >>     eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM
> >>
> >> I checked Google it's just:
> >>
> >>     4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI
> >>
> >> Suggestions welcome ;)
> >> _______________________________________________
> >> 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  Tue Jul 29 08:51:09 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 08:51:09 -0400 (EDT)
Subject: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
In-Reply-To: <1141263251.19768638.1406638033474.JavaMail.zimbra@redhat.com>
Message-ID: <295865000.19770918.1406638269823.JavaMail.zimbra@redhat.com>

Due to there being quite a lot of work to do the required updates to properly do a TOTP SPI I propose we post-pone this to 1.1.0.

The work would include:

* A TOTP SPI
* Account management needs to support multiple TOTPs
* Select TOTP provider to configure if required to setup TOTP on login
* Select TOTP provider to use at login if user has multiple
* Configure what TOTP are permitted for a realm
* Remember TOTP option (don't ask for TOTP in 30 days on this machine)
* Email implementation (send a OTP through email)
* SMS implementation (use an example SMS cloud service to send OTP) - this would also require additional fields to registration
* At least one other TOTP implementation (FreeOTP and Yubikey)
* ...

From bburke at redhat.com  Tue Jul 29 11:01:28 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:01:28 -0400
Subject: [keycloak-dev] Disable application scope by default?
Message-ID: <53D7B748.5060408@redhat.com>

Should applications (non oauth clients) scope be disabled by default? 
This would mean that any roles assigned to the user would be added to 
the token.

I just think there will be tons of user questions on why doesn't 
keycloak work for their application.

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

From bburke at redhat.com  Tue Jul 29 11:03:43 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:03:43 -0400
Subject: [keycloak-dev] resolving theme files
Message-ID: <53D7B7CF.6090108@redhat.com>

Are all theme files required to be in the same JAR as the original 
theme?  I'd like to have my provider admin console html/javascript files 
in a separate jAR and I can't seem to resolve them at the moment.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Jul 29 11:07:24 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 11:07:24 -0400 (EDT)
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7B748.5060408@redhat.com>
References: <53D7B748.5060408@redhat.com>
Message-ID: <678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>

Not sure I fully understand.

At the moment an application has scope on all it's own roles. I assume you mean that you're proposing that it should have a "scope" on all roles a user has?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 4:01:28 PM
> Subject: [keycloak-dev] Disable application scope by default?
> 
> Should applications (non oauth clients) scope be disabled by default?
> This would mean that any roles assigned to the user would be added to
> the token.
> 
> I just think there will be tons of user questions on why doesn't
> keycloak work for their application.
> 
> --
> 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 matzew at apache.org  Tue Jul 29 11:11:54 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 29 Jul 2014 17:11:54 +0200
Subject: [keycloak-dev] Beta 4 release?
In-Reply-To: <53CFF09A.4000501@redhat.com>
References: <53CFD658.2020207@redhat.com>
	<53CFF09A.4000501@redhat.com>
Message-ID: <CAAg5f2ScN1Hw_EL2kyk7U=qXV5_KjF4rKP1CwZzh-GdygiaHBQ@mail.gmail.com>

Hello Bill,

do you know the exact date for beta4? I was wondering if we should contain
the beta4 in our beta2 (planed for August7th)

-Matthias


On Wed, Jul 23, 2014 at 7:27 PM, Bill Burke <bburke at redhat.com> wrote:

> August 6th or earlier.  Soon after Beta 4 will be 1.0.Final.
>
> On 7/23/2014 11:35 AM, Stan Silvert wrote:
> > I'm waiting on the next Keycloak release.  Any idea when it will happen?
> >
> > 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
> _______________________________________________
> 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/20140729/720809b2/attachment-0001.html 

From stian at redhat.com  Tue Jul 29 11:17:20 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 11:17:20 -0400 (EDT)
Subject: [keycloak-dev] resolving theme files
In-Reply-To: <53D7B7CF.6090108@redhat.com>
References: <53D7B7CF.6090108@redhat.com>
Message-ID: <2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>

If the theme is loaded using the class-loader it should be. On the appliance the themes are extracted to standalone/configuration/themes though, so they are loaded by the file loader instead.

Maybe it would be better to add a separate theme type for the providers? That way the theme won't be overridden.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 4:03:43 PM
> Subject: [keycloak-dev] resolving theme files
> 
> Are all theme files required to be in the same JAR as the original
> theme?  I'd like to have my provider admin console html/javascript files
> in a separate jAR and I can't seem to resolve them at the moment.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Jul 29 11:20:56 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 11:20:56 -0400 (EDT)
Subject: [keycloak-dev] Access code length
In-Reply-To: <945694568.19717091.1406627638484.JavaMail.zimbra@redhat.com>
References: <849680095.19265486.1406564061745.JavaMail.zimbra@redhat.com>
	<53D68187.7060805@redhat.com> <53D69B02.3030204@redhat.com>
	<945694568.19717091.1406627638484.JavaMail.zimbra@redhat.com>
Message-ID: <297700744.19882472.1406647256283.JavaMail.zimbra@redhat.com>

Access code work completed.

UserSessionProvider now has a ClientSessionModel that represents a clients access to a users sessions. This contains all the details that used to be in the access code itself, with the exception of what was already moved to UserSessionModel.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 10:53:58 AM
> Subject: Re: [keycloak-dev] Access code length
> 
> Thanks for suggestions.
> 
> Now the code looks like:
> 
>   xuAZKwa2EkX_WBHp-LPHXXQYKc0.YjUzMmRhODAtZTFkZS00MTZjLTk1ZjktNGJlMGYxMDNmNGE2LTE0MDY2Mjc0NDg4NjE
> 
> This consists of two parts (both Base64 url-encoded):
> 
>   <Hashed Signature>.<ID>
> 
> The hashed signature is the SHA-1 digest of the SHA256withRSA signature of ID
> + timestamp + action
> 
> To verify a code the details for the AccessCode is retrieved using the first
> part of the code. Then the hashed signature is created from the stored
> details and compared to the first part of the code.
> 
> This provides both brute force protection, and also protects against UUID
> collisions (which should be very unlikely, but still).
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Monday, 28 July, 2014 7:48:34 PM
> > Subject: Re: [keycloak-dev] Access code length
> > 
> > Smaller hash (sha1 or md5) is really the only thing you can do beyond
> > removing the JWS header.  But, if you're going to do that, might as well
> > just ditch the signature altogether.  If anything, over time, we'd be
> > using larger hashes not smaller ones.
> > 
> > HMAC is smaller, but that would require a realm secret key.
> > 
> > With a HMAC header and computing the JWS of:
> > 
> >          String uuid = UUID.randomUUID().toString();
> > 
> > 
> > 156 chars for HMAC 512 secret key
> > 113 chars for HMAC 256 key
> > 99 chars for HMAC SHA1 (We'd have to implement SHA1 which would be easy
> > to add)
> > 
> > 
> > Header is 20+ characters.  uuid is 36 chars.
> > 
> > My bet is that Google is using HMAC + SHA-1
> > 
> > 
> > 
> > 
> > 
> > On 7/28/2014 12:59 PM, Marek Posolda wrote:
> > > Something, which comes to my mind:
> > >
> > > * Omit the header part with algorithm info and instead assume that code
> > > is always signed with rsa-256 (or whatever different algorithm)
> > >
> > > * Is it really needed to have System.currentTimeMillis() info here? I
> > > wonder if this timestamp info can be extracted to server side as well,
> > > so when code is later looked-up, you will also have info about the time
> > > when it was created without the need of pass this info as part of the
> > > code
> > >
> > > * It seems that the biggest part (around 170 characters) is signature. I
> > > wonder that it can be reduced by either:
> > > ** Use not so strong algorithm to sign the code (not sure if it's
> > > security issue as code is one time usage though and it's better than
> > > avoid signature at all...)
> > > ** Actually it's keycloak itself, which verifies signature. So I wonder
> > > if instead of passing the whole signature around, it can just pass the
> > > hash of signature (just few characters). Then later during verification
> > > phase, it has access to whole accessCode content, so it can sign the
> > > content again and compute again the hash of signature and compare it
> > > with the hash passed from code parameter.
> > >
> > > Marek
> > >
> > > On 28.7.2014 18:14, Stian Thorgersen wrote:
> > >> I've made the changes to access code, but I'm still not happy with the
> > >> length.
> > >>
> > >> The old access code containing all the details (including access token
> > >> and
> > >> id token) was at least 1000 characters long (with more roles and id
> > >> token
> > >> details that would have been even bigger!).
> > >>
> > >> The new access code length is 259 characters. I think this is still to
> > >> big
> > >> and would like to reduce it. The way I'm currently creating it is taking
> > >> the ID (UUID.randomUUID() + System.currentTimeMillis()) and using
> > >> JWSBuilder to add a signature. Example:
> > >>
> > >>     eyJhbGciOiJSUzI1NiJ9.MTVhMjFiNWMtNjcxYy00YzYyLWEyOGMtNmFmMzE4YzE0NjkzMTQwNjU2MzMwNzQyMw.djN2v1Egz1Fime-2bVvYyv529KNMChYh3e0rY5UU4TImv53ppwNhrmWaZRNzO0xLULRC8IeixrH6K3nR1cMyHZb9Ef8Vr46YvNmE8Q_qac821GAWMNzEKjYcXt87AhSSz8BY54CcbKIPLfxFC8smI-KDA1Mr5SrJ_Ch-zdLDbdM
> > >>
> > >> I checked Google it's just:
> > >>
> > >>     4/YJcHpG7-DcoVcwNH_8D-NDQKcP_Y.MijWXLPgpOwToiIBeO6P2m9c72_7jgI
> > >>
> > >> Suggestions welcome ;)
> > >> _______________________________________________
> > >> keycloak-dev mailing list
> > >> keycloak-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Jul 29 11:27:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:27:02 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
References: <53D7B748.5060408@redhat.com>
	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
Message-ID: <53D7BD46.7040904@redhat.com>



On 7/29/2014 11:07 AM, Stian Thorgersen wrote:
> Not sure I fully understand.
>
> At the moment an application has scope on all it's own roles. I assume you mean that you're proposing that it should have a "scope" on all roles a user has?
>

Yes exactly.

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

From bburke at redhat.com  Tue Jul 29 11:32:42 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:32:42 -0400
Subject: [keycloak-dev] resolving theme files
In-Reply-To: <2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>
References: <53D7B7CF.6090108@redhat.com>
	<2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>
Message-ID: <53D7BE9A.6080705@redhat.com>

Nevermind, I think I forgot to clear my browser cache and was loading 
old javascript files.

On 7/29/2014 11:17 AM, Stian Thorgersen wrote:
> If the theme is loaded using the class-loader it should be. On the appliance the themes are extracted to standalone/configuration/themes though, so they are loaded by the file loader instead.
>
> Maybe it would be better to add a separate theme type for the providers? That way the theme won't be overridden.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 29 July, 2014 4:03:43 PM
>> Subject: [keycloak-dev] resolving theme files
>>
>> Are all theme files required to be in the same JAR as the original
>> theme?  I'd like to have my provider admin console html/javascript files
>> in a separate jAR and I can't seem to resolve them at the moment.
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

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

From stian at redhat.com  Tue Jul 29 11:34:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 11:34:47 -0400 (EDT)
Subject: [keycloak-dev] resolving theme files
In-Reply-To: <53D7BE9A.6080705@redhat.com>
References: <53D7B7CF.6090108@redhat.com>
	<2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>
	<53D7BE9A.6080705@redhat.com>
Message-ID: <324974618.19892074.1406648087760.JavaMail.zimbra@redhat.com>

There's still the issue I mentioned though. 

If the theme is loaded from the file-loader none of the resources from the providers will be available, as a theme is either loaded from a folder or the class-loader, not a combination. As we extract the themes on the appliance, all themes will always be loaded from standalone/configuration/themes.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 4:32:42 PM
> Subject: Re: [keycloak-dev] resolving theme files
> 
> Nevermind, I think I forgot to clear my browser cache and was loading
> old javascript files.
> 
> On 7/29/2014 11:17 AM, Stian Thorgersen wrote:
> > If the theme is loaded using the class-loader it should be. On the
> > appliance the themes are extracted to standalone/configuration/themes
> > though, so they are loaded by the file loader instead.
> >
> > Maybe it would be better to add a separate theme type for the providers?
> > That way the theme won't be overridden.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 29 July, 2014 4:03:43 PM
> >> Subject: [keycloak-dev] resolving theme files
> >>
> >> Are all theme files required to be in the same JAR as the original
> >> theme?  I'd like to have my provider admin console html/javascript files
> >> in a separate jAR and I can't seem to resolve them at the moment.
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Tue Jul 29 11:40:04 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 29 Jul 2014 11:40:04 -0400 (EDT)
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7BD46.7040904@redhat.com>
References: <53D7B748.5060408@redhat.com>
	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
	<53D7BD46.7040904@redhat.com>
Message-ID: <640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>

Other than potentially larger tokens I don't see any issue with that.

Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 4:27:02 PM
> Subject: Re: [keycloak-dev] Disable application scope by default?
> 
> 
> 
> On 7/29/2014 11:07 AM, Stian Thorgersen wrote:
> > Not sure I fully understand.
> >
> > At the moment an application has scope on all it's own roles. I assume you
> > mean that you're proposing that it should have a "scope" on all roles a
> > user has?
> >
> 
> Yes exactly.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Jul 29 11:40:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:40:35 -0400
Subject: [keycloak-dev] resolving theme files
In-Reply-To: <324974618.19892074.1406648087760.JavaMail.zimbra@redhat.com>
References: <53D7B7CF.6090108@redhat.com>
	<2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>
	<53D7BE9A.6080705@redhat.com>
	<324974618.19892074.1406648087760.JavaMail.zimbra@redhat.com>
Message-ID: <53D7C073.1020406@redhat.com>

Hmmm, that's problematic.  The federation provider UIs can't be in a 
separate theme as they are part of the admin console and need to inherit 
from that.  Create an admin theme manager that is a file/classloader hybrid?

On 7/29/2014 11:34 AM, Stian Thorgersen wrote:
> There's still the issue I mentioned though.
>
> If the theme is loaded from the file-loader none of the resources from the providers will be available, as a theme is either loaded from a folder or the class-loader, not a combination. As we extract the themes on the appliance, all themes will always be loaded from standalone/configuration/themes.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 29 July, 2014 4:32:42 PM
>> Subject: Re: [keycloak-dev] resolving theme files
>>
>> Nevermind, I think I forgot to clear my browser cache and was loading
>> old javascript files.
>>
>> On 7/29/2014 11:17 AM, Stian Thorgersen wrote:
>>> If the theme is loaded using the class-loader it should be. On the
>>> appliance the themes are extracted to standalone/configuration/themes
>>> though, so they are loaded by the file loader instead.
>>>
>>> Maybe it would be better to add a separate theme type for the providers?
>>> That way the theme won't be overridden.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 29 July, 2014 4:03:43 PM
>>>> Subject: [keycloak-dev] resolving theme files
>>>>
>>>> Are all theme files required to be in the same JAR as the original
>>>> theme?  I'd like to have my provider admin console html/javascript files
>>>> in a separate jAR and I can't seem to resolve them at the moment.
>>>> --
>>>> 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  Tue Jul 29 11:47:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 11:47:34 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
References: <53D7B748.5060408@redhat.com>
	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
	<53D7BD46.7040904@redhat.com>
	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
Message-ID: <53D7C216.8030309@redhat.com>



On 7/29/2014 11:40 AM, Stian Thorgersen wrote:
> Other than potentially larger tokens I don't see any issue with that.
>
> Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.
>

A few people have specifically wanted application specific roles.  Plus 
once you go to the scheme you're suggesting the adapters would more than 
likely require a keycloak role -> application role mapping facility.


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

From ssilvert at redhat.com  Tue Jul 29 12:06:34 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 29 Jul 2014 12:06:34 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
References: <53D7B748.5060408@redhat.com>
	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
	<53D7BD46.7040904@redhat.com>
	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
Message-ID: <53D7C68A.1080804@redhat.com>

Sorry to veer off topic and onto general usability, but this brings up 
something I've been meaning to mention for awhile.

I'm sure that I don't understand all the use cases very well, but I can 
attest that the whole "scope" thing is rather confusing. From the UI, it 
was never clear to me what "Scope" actually did. I never seemed to need 
it so I never read the doco on it.  Now I've read "Permission Scopes" 
section of the doc and I still don't understand.  I'd probably have to 
read it a few more times to really get it.

I suggest that you add a short sentence to each screen that explains 
what the screen is for.   That would improve usability tremendously.

There are many other places where a few words would improve 
understanding.  For instance, what does "Direct Grant API" mean? I 
shouldn't have to look it up in the doc to find out.

Stan

On 7/29/2014 11:40 AM, Stian Thorgersen wrote:
> Other than potentially larger tokens I don't see any issue with that.
>
> Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 29 July, 2014 4:27:02 PM
>> Subject: Re: [keycloak-dev] Disable application scope by default?
>>
>>
>>
>> On 7/29/2014 11:07 AM, Stian Thorgersen wrote:
>>> Not sure I fully understand.
>>>
>>> At the moment an application has scope on all it's own roles. I assume you
>>> mean that you're proposing that it should have a "scope" on all roles a
>>> user has?
>>>
>> Yes exactly.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From ssilvert at redhat.com  Tue Jul 29 12:17:40 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 29 Jul 2014 12:17:40 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7C216.8030309@redhat.com>
References: <53D7B748.5060408@redhat.com>
	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>
	<53D7BD46.7040904@redhat.com>
	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
	<53D7C216.8030309@redhat.com>
Message-ID: <53D7C924.5030609@redhat.com>

On 7/29/2014 11:47 AM, Bill Burke wrote:
>
> On 7/29/2014 11:40 AM, Stian Thorgersen wrote:
>> Other than potentially larger tokens I don't see any issue with that.
>>
>> Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.
>>
> A few people have specifically wanted application specific roles.  Plus
> once you go to the scheme you're suggesting the adapters would more than
> likely require a keycloak role -> application role mapping facility.
+1.  I'd actually assume that application roles would be more 
prevalent.  You design an application with specific roles in mind. 
Rarely would you design a family of applications with roles that are 
common to the family.

On the other hand, how do we deal with name collisions today?  You could 
easily have an application role named "admin" and also have a realm role 
named "admin".  Is the application able to tell the difference if it 
needs to?

Stan

From bburke at redhat.com  Tue Jul 29 13:08:14 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 13:08:14 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7C68A.1080804@redhat.com>
References: <53D7B748.5060408@redhat.com>	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>	<53D7BD46.7040904@redhat.com>	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
	<53D7C68A.1080804@redhat.com>
Message-ID: <53D7D4FE.8030204@redhat.com>

I've been looking or a good way to explain scope.  It is the roles an 
application or oauth client is allowed to ask for.

A user could have the "admin", "buyer" and "seller" roles, but an 
application with the scope of { "buyer" and "seller" } would only get a 
token that contained the "buyer" and "seller" role mappings for that 
user.  Does that make sense at all?

Its an extra security measure to limit the privileges

On 7/29/2014 12:06 PM, Stan Silvert wrote:
> Sorry to veer off topic and onto general usability, but this brings up
> something I've been meaning to mention for awhile.
>
> I'm sure that I don't understand all the use cases very well, but I can
> attest that the whole "scope" thing is rather confusing. From the UI, it
> was never clear to me what "Scope" actually did. I never seemed to need
> it so I never read the doco on it.  Now I've read "Permission Scopes"
> section of the doc and I still don't understand.  I'd probably have to
> read it a few more times to really get it.
>
> I suggest that you add a short sentence to each screen that explains
> what the screen is for.   That would improve usability tremendously.
>
> There are many other places where a few words would improve
> understanding.  For instance, what does "Direct Grant API" mean? I
> shouldn't have to look it up in the doc to find out.
>
> Stan
>
> On 7/29/2014 11:40 AM, Stian Thorgersen wrote:
>> Other than potentially larger tokens I don't see any issue with that.
>>
>> Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 29 July, 2014 4:27:02 PM
>>> Subject: Re: [keycloak-dev] Disable application scope by default?
>>>
>>>
>>>
>>> On 7/29/2014 11:07 AM, Stian Thorgersen wrote:
>>>> Not sure I fully understand.
>>>>
>>>> At the moment an application has scope on all it's own roles. I assume you
>>>> mean that you're proposing that it should have a "scope" on all roles a
>>>> user has?
>>>>
>>> Yes exactly.
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From ssilvert at redhat.com  Tue Jul 29 13:33:41 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 29 Jul 2014 13:33:41 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7D4FE.8030204@redhat.com>
References: <53D7B748.5060408@redhat.com>	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>	<53D7BD46.7040904@redhat.com>	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>
	<53D7C68A.1080804@redhat.com> <53D7D4FE.8030204@redhat.com>
Message-ID: <53D7DAF5.6020500@redhat.com>

On 7/29/2014 1:08 PM, Bill Burke wrote:
> I've been looking or a good way to explain scope.  It is the roles an
> application or oauth client is allowed to ask for.
>
> A user could have the "admin", "buyer" and "seller" roles, but an
> application with the scope of { "buyer" and "seller" } would only get a
> token that contained the "buyer" and "seller" role mappings for that
> user.  Does that make sense at all?
>
> Its an extra security measure to limit the privileges
Yes, that makes sense.  I think your sentence, "The roles an application 
or oauth client is allowed to ask for." should appear in a smaller font 
right after the heading "Scope Mappings".

Also, put your example in the doc.

If nothing is assigned in Scope Mappings, then user just gets all the 
roles assigned in Users --> username --> Role Mappings, right?

If so, then I agree that your original thought about showing Scope 
Mappings as disabled by default makes sense.  As it is now in the UI, it 
looks like having no Scope Mappings means that the client is not allowed 
to ask for any roles.
>
> On 7/29/2014 12:06 PM, Stan Silvert wrote:
>> Sorry to veer off topic and onto general usability, but this brings up
>> something I've been meaning to mention for awhile.
>>
>> I'm sure that I don't understand all the use cases very well, but I can
>> attest that the whole "scope" thing is rather confusing. From the UI, it
>> was never clear to me what "Scope" actually did. I never seemed to need
>> it so I never read the doco on it.  Now I've read "Permission Scopes"
>> section of the doc and I still don't understand.  I'd probably have to
>> read it a few more times to really get it.
>>
>> I suggest that you add a short sentence to each screen that explains
>> what the screen is for.   That would improve usability tremendously.
>>
>> There are many other places where a few words would improve
>> understanding.  For instance, what does "Direct Grant API" mean? I
>> shouldn't have to look it up in the doc to find out.
>>
>> Stan
>>
>> On 7/29/2014 11:40 AM, Stian Thorgersen wrote:
>>> Other than potentially larger tokens I don't see any issue with that.
>>>
>>> Although, lately I've been thinking that only having a single list of roles for a realm would be simpler, instead of realm roles and application roles. We could still provide some form of a hierarchy using '/' for example 'myapp/admin'. It's a pretty big shift, but I think it would remove a lot of confusion.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, 29 July, 2014 4:27:02 PM
>>>> Subject: Re: [keycloak-dev] Disable application scope by default?
>>>>
>>>>
>>>>
>>>> On 7/29/2014 11:07 AM, Stian Thorgersen wrote:
>>>>> Not sure I fully understand.
>>>>>
>>>>> At the moment an application has scope on all it's own roles. I assume you
>>>>> mean that you're proposing that it should have a "scope" on all roles a
>>>>> user has?
>>>>>
>>>> Yes exactly.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From bburke at redhat.com  Tue Jul 29 13:43:01 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 13:43:01 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7DAF5.6020500@redhat.com>
References: <53D7B748.5060408@redhat.com>	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>	<53D7BD46.7040904@redhat.com>	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>	<53D7C68A.1080804@redhat.com>
	<53D7D4FE.8030204@redhat.com> <53D7DAF5.6020500@redhat.com>
Message-ID: <53D7DD25.6070207@redhat.com>



On 7/29/2014 1:33 PM, Stan Silvert wrote:
> On 7/29/2014 1:08 PM, Bill Burke wrote:
>> I've been looking or a good way to explain scope.  It is the roles an
>> application or oauth client is allowed to ask for.
>>
>> A user could have the "admin", "buyer" and "seller" roles, but an
>> application with the scope of { "buyer" and "seller" } would only get a
>> token that contained the "buyer" and "seller" role mappings for that
>> user.  Does that make sense at all?
>>
>> Its an extra security measure to limit the privileges
> Yes, that makes sense.  I think your sentence, "The roles an application
> or oauth client is allowed to ask for." should appear in a smaller font
> right after the heading "Scope Mappings".
>
> Also, put your example in the doc.
>
> If nothing is assigned in Scope Mappings, then user just gets all the
> roles assigned in Users --> username --> Role Mappings, right?
>

This is for token creation.  If no scope is defined (right now), then 
the token only gets populated for user role mappings of roles that are 
defined in the application.  I want to change it so that if no scope is 
defined, then all role mappings would populate the token.

Maybe a switch "All user's roles" -> ON/OFF

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

From ssilvert at redhat.com  Tue Jul 29 14:38:42 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 29 Jul 2014 14:38:42 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7DD25.6070207@redhat.com>
References: <53D7B748.5060408@redhat.com>	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>	<53D7BD46.7040904@redhat.com>	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>	<53D7C68A.1080804@redhat.com>
	<53D7D4FE.8030204@redhat.com> <53D7DAF5.6020500@redhat.com>
	<53D7DD25.6070207@redhat.com>
Message-ID: <53D7EA32.8070006@redhat.com>

On 7/29/2014 1:43 PM, Bill Burke wrote:
>
> On 7/29/2014 1:33 PM, Stan Silvert wrote:
>> On 7/29/2014 1:08 PM, Bill Burke wrote:
>>> I've been looking or a good way to explain scope.  It is the roles an
>>> application or oauth client is allowed to ask for.
>>>
>>> A user could have the "admin", "buyer" and "seller" roles, but an
>>> application with the scope of { "buyer" and "seller" } would only get a
>>> token that contained the "buyer" and "seller" role mappings for that
>>> user.  Does that make sense at all?
>>>
>>> Its an extra security measure to limit the privileges
>> Yes, that makes sense.  I think your sentence, "The roles an application
>> or oauth client is allowed to ask for." should appear in a smaller font
>> right after the heading "Scope Mappings".
>>
>> Also, put your example in the doc.
>>
>> If nothing is assigned in Scope Mappings, then user just gets all the
>> roles assigned in Users --> username --> Role Mappings, right?
>>
> This is for token creation.  If no scope is defined (right now), then
> the token only gets populated for user role mappings of roles that are
> defined in the application.  I want to change it so that if no scope is
> defined, then all role mappings would populate the token.
>
> Maybe a switch "All user's roles" -> ON/OFF
>
Maybe, but if I'm just looking at the switch I will have no idea what it 
does.  This is a really hard usability problem because the concepts are 
hard to grasp.   Furthermore, "role" means something slightly different 
to an application than it does to an OAuth client.

From bburke at redhat.com  Tue Jul 29 14:58:03 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 14:58:03 -0400
Subject: [keycloak-dev] Disable application scope by default?
In-Reply-To: <53D7EA32.8070006@redhat.com>
References: <53D7B748.5060408@redhat.com>	<678900254.19872756.1406646444594.JavaMail.zimbra@redhat.com>	<53D7BD46.7040904@redhat.com>	<640680698.19895705.1406648404253.JavaMail.zimbra@redhat.com>	<53D7C68A.1080804@redhat.com>	<53D7D4FE.8030204@redhat.com>
	<53D7DAF5.6020500@redhat.com>	<53D7DD25.6070207@redhat.com>
	<53D7EA32.8070006@redhat.com>
Message-ID: <53D7EEBB.4000802@redhat.com>



On 7/29/2014 2:38 PM, Stan Silvert wrote:
> On 7/29/2014 1:43 PM, Bill Burke wrote:
>>
>> On 7/29/2014 1:33 PM, Stan Silvert wrote:
>>> On 7/29/2014 1:08 PM, Bill Burke wrote:
>>>> I've been looking or a good way to explain scope.  It is the roles an
>>>> application or oauth client is allowed to ask for.
>>>>
>>>> A user could have the "admin", "buyer" and "seller" roles, but an
>>>> application with the scope of { "buyer" and "seller" } would only get a
>>>> token that contained the "buyer" and "seller" role mappings for that
>>>> user.  Does that make sense at all?
>>>>
>>>> Its an extra security measure to limit the privileges
>>> Yes, that makes sense.  I think your sentence, "The roles an application
>>> or oauth client is allowed to ask for." should appear in a smaller font
>>> right after the heading "Scope Mappings".
>>>
>>> Also, put your example in the doc.
>>>
>>> If nothing is assigned in Scope Mappings, then user just gets all the
>>> roles assigned in Users --> username --> Role Mappings, right?
>>>
>> This is for token creation.  If no scope is defined (right now), then
>> the token only gets populated for user role mappings of roles that are
>> defined in the application.  I want to change it so that if no scope is
>> defined, then all role mappings would populate the token.
>>
>> Maybe a switch "All user's roles" -> ON/OFF
>>
> Maybe, but if I'm just looking at the switch I will have no idea what it
> does.  This is a really hard usability problem because the concepts are
> hard to grasp.   Furthermore, "role" means something slightly different
> to an application than it does to an OAuth client.

Not really.  OAuth has the concept of scope which is where this came 
from to begin with.


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

From ssilvert at redhat.com  Tue Jul 29 15:55:16 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 29 Jul 2014 15:55:16 -0400
Subject: [keycloak-dev] keycloak.org down?
Message-ID: <53D7FC24.4020907@redhat.com>

I can get to www.jboss.org OK.

keycloak.org redirects to keycloak.jboss.org which hangs.

Anyone else having trouble?

From bburke at redhat.com  Tue Jul 29 17:13:16 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 17:13:16 -0400
Subject: [keycloak-dev] keycloak.org down?
In-Reply-To: <53D7FC24.4020907@redhat.com>
References: <53D7FC24.4020907@redhat.com>
Message-ID: <53D80E6C.2040407@redhat.com>

resteasy is unreachable too.

On 7/29/2014 3:55 PM, Stan Silvert wrote:
> I can get to www.jboss.org OK.
>
> keycloak.org redirects to keycloak.jboss.org which hangs.
>
> Anyone else having trouble?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Jul 29 17:33:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 17:33:24 -0400
Subject: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
In-Reply-To: <295865000.19770918.1406638269823.JavaMail.zimbra@redhat.com>
References: <295865000.19770918.1406638269823.JavaMail.zimbra@redhat.com>
Message-ID: <53D81324.4030809@redhat.com>

Could this TOTP SPI turn into a general authentication plugin SPI?  Just 
had an inquiry for that type of SPI.

On 7/29/2014 8:51 AM, Stian Thorgersen wrote:
> Due to there being quite a lot of work to do the required updates to properly do a TOTP SPI I propose we post-pone this to 1.1.0.
>
> The work would include:
>
> * A TOTP SPI
> * Account management needs to support multiple TOTPs
> * Select TOTP provider to configure if required to setup TOTP on login
> * Select TOTP provider to use at login if user has multiple
> * Configure what TOTP are permitted for a realm
> * Remember TOTP option (don't ask for TOTP in 30 days on this machine)
> * Email implementation (send a OTP through email)
> * SMS implementation (use an example SMS cloud service to send OTP) - this would also require additional fields to registration
> * At least one other TOTP implementation (FreeOTP and Yubikey)
> * ...
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Tue Jul 29 17:36:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 17:36:50 -0400
Subject: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
In-Reply-To: <53D81324.4030809@redhat.com>
References: <295865000.19770918.1406638269823.JavaMail.zimbra@redhat.com>
	<53D81324.4030809@redhat.com>
Message-ID: <53D813F2.1020604@redhat.com>

By authentication plugin SPI, I actually mean a credential type plugin 
SPI.  Have a user requesting that they be able to plug in their own 
client-cert verification mechanism.

On 7/29/2014 5:33 PM, Bill Burke wrote:
> Could this TOTP SPI turn into a general authentication plugin SPI?  Just
> had an inquiry for that type of SPI.
>
> On 7/29/2014 8:51 AM, Stian Thorgersen wrote:
>> Due to there being quite a lot of work to do the required updates to properly do a TOTP SPI I propose we post-pone this to 1.1.0.
>>
>> The work would include:
>>
>> * A TOTP SPI
>> * Account management needs to support multiple TOTPs
>> * Select TOTP provider to configure if required to setup TOTP on login
>> * Select TOTP provider to use at login if user has multiple
>> * Configure what TOTP are permitted for a realm
>> * Remember TOTP option (don't ask for TOTP in 30 days on this machine)
>> * Email implementation (send a OTP through email)
>> * SMS implementation (use an example SMS cloud service to send OTP) - this would also require additional fields to registration
>> * At least one other TOTP implementation (FreeOTP and Yubikey)
>> * ...
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Tue Jul 29 18:42:56 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 29 Jul 2014 18:42:56 -0400
Subject: [keycloak-dev] need feedback on pluggable fed console UI
Message-ID: <53D82370.2000201@redhat.com>

I'm kind of at a block with providing an SPI to plugin federation 
provider console UIs.

I would need to:

1. Provide a way to dynamically load the javascript of the plug
- index.html could be processed with Freemarker or some other brute 
force means to add the appropriate <script> elements
- Could add <script> tags within javascript (not sure about this, see 
$routeProvider

2. $routeProvider can only be set up once it seems?  Function pointers 
need to already be established for controllers.

3. We have to worry about name clashes with other admin console angular 
components?

I'm just not sure I want to create a full-fledged "portlet" spi at this 
late juncture.  My thinking is to hard code LDAP and any other provider 
has to be configured through keycloak_server.json or via a generic 
properties page.

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

From harit.subscriptions at gmail.com  Tue Jul 29 20:51:45 2014
From: harit.subscriptions at gmail.com (Harit Himanshu)
Date: Tue, 29 Jul 2014 17:51:45 -0700
Subject: [keycloak-dev] Oauth Register and Token Validation Example
In-Reply-To: <53D74C52.2090805@redhat.com>
References: <CADYyO+X_0xuUjYr9D1awpbYLt5xmMjKJapKz5cw0BYN+p-+q=Q@mail.gmail.com>
	<CADYyO+VKC0cSkbHvmY2vJerB9PJ_J_h4fmdc3bsLy1VtamYMFw@mail.gmail.com>
	<53D74C52.2090805@redhat.com>
Message-ID: <CADYyO+UCZXBqTQdn3HBR-sM0zWUUdgfu3tv802tsxs5WV=M2PQ@mail.gmail.com>

Thanks Marek

I saw here
<https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java#L54>
app
gains the accessToken, but did not see where this `/auth` api is
implemented. I want to learn how to I do the same thing of exposing `/auth`
api to generate tokens

I did not see anything in pom.xml
<https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/pom.xml>
either. seems like magic to me at the moment. Any guidance here?

Thanks


On Tue, Jul 29, 2014 at 12:25 AM, Marek Posolda <mposolda at redhat.com> wrote:

>  Hi,
>
> the best is to start with documentation
> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html
> and also look at existing examples
> https://github.com/keycloak/keycloak/tree/master/examples . Probably most
> useful for you might be
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template .
> It has restful application "database-service", where you can send secured
> REST requests with the bearer token attached to them. Other applications in
> the directory are web applications, which obtain bearer token from the
> Keycloak login . Product-portal and customer-portal are JEE applications
> secured by Keycloak itself, third-party and third-party-cdi is more
> traditional OAuth where token is used just to retrieve the secured data
> from "database-service" . See the README for more info.
>
> Example for CORS support is here:
> https://github.com/keycloak/keycloak/tree/master/examples/cors
>
> Marek
>
>
> On 25.7.2014 23:04, Harit Himanshu wrote:
>
> Hey Team,
>
>  I am been looking for answer to
> http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis and
> found that keycloak is suitable for securing REST APIs using OAuth 2.0.
>
>  I am looking for example where the following is demonstrated
>  a.) Third-party app registers and gets Access Token
> b.) Third-Party app accesses Resource Server to access protected resource
> by sending Access Token to REST API
> c.) and How Token is validated.
>
>
>  It is mentioned in features of keycloak as
>
>    - OAuth Bearer token auth for REST Services
>    - OAuth 2.0 Grant requests
>    - CORS Support
>
>  Can you please guide me through examples?
>
>  Thank you
>
>
> On Fri, Jul 25, 2014 at 2:00 PM, Harit Himanshu <
> harit.subscriptions at gmail.com> wrote:
>
>> Hey Team,
>>
>>  I am been looking for answer to
>> http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis
>> and found that keycloak is suitable for securing REST APIs using OAuth 2.0.
>>
>>  I am looking for example where the following is demonstrated
>> a.) Third-party app registers and gets Access Token
>> b.) Third-Party app accesses Resource Server to access protected resource
>> by sending Access Token to REST API
>> c.) and How Token is validated.
>>
>>
>>  It is mentioned in features of keycloak as
>>
>>    - OAuth Bearer token auth for REST Services
>>    - OAuth 2.0 Grant requests
>>    - CORS Support
>>
>>  Can you please guide me through examples?
>>
>>  Thank you
>>  + Harit Himanshu
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140729/0814787e/attachment.html 

From mposolda at redhat.com  Wed Jul 30 01:50:17 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 30 Jul 2014 07:50:17 +0200
Subject: [keycloak-dev] Oauth Register and Token Validation Example
In-Reply-To: <CADYyO+UCZXBqTQdn3HBR-sM0zWUUdgfu3tv802tsxs5WV=M2PQ@mail.gmail.com>
References: <CADYyO+X_0xuUjYr9D1awpbYLt5xmMjKJapKz5cw0BYN+p-+q=Q@mail.gmail.com>	<CADYyO+VKC0cSkbHvmY2vJerB9PJ_J_h4fmdc3bsLy1VtamYMFw@mail.gmail.com>	<53D74C52.2090805@redhat.com>
	<CADYyO+UCZXBqTQdn3HBR-sM0zWUUdgfu3tv802tsxs5WV=M2PQ@mail.gmail.com>
Message-ID: <53D88799.8090502@redhat.com>

On 30.7.2014 02:51, Harit Himanshu wrote:
> Thanks Marek
>
> I saw here 
> <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java#L54> app 
> gains the accessToken, but did not see where this `/auth` api is 
> implemented. I want to learn how to I do the same thing of exposing 
> `/auth` api to generate tokens
This is example for Direct Grant API. It allows you to send POST request 
to Keycloak including username and password and Keycloak will directly 
returns you accessToken without even displaying Keycloak login screen. 
Direct Grant API has some limitations though (password must be known to 
your application, SSO won't work, User won't be able to login if he 
needs to do some required action (like change password) etc.). So it's 
usually better to use proper login flow instead of Direct Grant API. See 
here for more info 
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java#L54 
.

Marek
>
> I did not see anything in pom.xml 
> <https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/pom.xml> 
> either. seems like magic to me at the moment. Any guidance here?
>
> Thanks
>
>
> On Tue, Jul 29, 2014 at 12:25 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi,
>
>     the best is to start with documentation
>     http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html
>     and also look at existing examples
>     https://github.com/keycloak/keycloak/tree/master/examples .
>     Probably most useful for you might be
>     https://github.com/keycloak/keycloak/tree/master/examples/demo-template
>     . It has restful application "database-service", where you can
>     send secured REST requests with the bearer token attached to them.
>     Other applications in the directory are web applications, which
>     obtain bearer token from the Keycloak login . Product-portal and
>     customer-portal are JEE applications secured by Keycloak itself,
>     third-party and third-party-cdi is more traditional OAuth where
>     token is used just to retrieve the secured data from
>     "database-service" . See the README for more info.
>
>     Example for CORS support is here:
>     https://github.com/keycloak/keycloak/tree/master/examples/cors
>
>     Marek
>
>
>     On 25.7.2014 23:04, Harit Himanshu wrote:
>>     Hey Team,
>>
>>     I am been looking for answer to
>>     http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis and
>>     found that keycloak is suitable for securing REST APIs using
>>     OAuth 2.0.
>>
>>     I am looking for example where the following is demonstrated
>>     a.) Third-party app registers and gets Access Token
>>     b.) Third-Party app accesses Resource Server to access protected
>>     resource by sending Access Token to REST API
>>     c.) and How Token is validated.
>>
>>
>>     It is mentioned in features of keycloak as
>>
>>       * OAuth Bearer token auth for REST Services
>>       * OAuth 2.0 Grant requests
>>       * CORS Support
>>
>>     Can you please guide me through examples?
>>
>>     Thank you
>>
>>
>>     On Fri, Jul 25, 2014 at 2:00 PM, Harit Himanshu
>>     <harit.subscriptions at gmail.com
>>     <mailto:harit.subscriptions at gmail.com>> wrote:
>>
>>         Hey Team,
>>
>>         I am been looking for answer to
>>         http://stackoverflow.com/questions/24769691/what-are-some-ways-to-secure-rest-apis
>>         and found that keycloak is suitable for securing REST APIs
>>         using OAuth 2.0.
>>
>>         I am looking for example where the following is demonstrated
>>         a.) Third-party app registers and gets Access Token
>>         b.) Third-Party app accesses Resource Server to access
>>         protected resource by sending Access Token to REST API
>>         c.) and How Token is validated.
>>
>>
>>         It is mentioned in features of keycloak as
>>
>>           * OAuth Bearer token auth for REST Services
>>           * OAuth 2.0 Grant requests
>>           * CORS Support
>>
>>         Can you please guide me through examples?
>>
>>         Thank you
>>         + Harit Himanshu
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

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

From stian at redhat.com  Wed Jul 30 04:34:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 04:34:48 -0400 (EDT)
Subject: [keycloak-dev] resolving theme files
In-Reply-To: <53D7C073.1020406@redhat.com>
References: <53D7B7CF.6090108@redhat.com>
	<2004738515.19880649.1406647040902.JavaMail.zimbra@redhat.com>
	<53D7BE9A.6080705@redhat.com>
	<324974618.19892074.1406648087760.JavaMail.zimbra@redhat.com>
	<53D7C073.1020406@redhat.com>
Message-ID: <2141500257.20265772.1406709288696.JavaMail.zimbra@redhat.com>

I think it would be cleaner to add a separate admin-providers theme type, and have a special ThemeProvider for it.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 4:40:35 PM
> Subject: Re: [keycloak-dev] resolving theme files
> 
> Hmmm, that's problematic.  The federation provider UIs can't be in a
> separate theme as they are part of the admin console and need to inherit
> from that.  Create an admin theme manager that is a file/classloader hybrid?
> 
> On 7/29/2014 11:34 AM, Stian Thorgersen wrote:
> > There's still the issue I mentioned though.
> >
> > If the theme is loaded from the file-loader none of the resources from the
> > providers will be available, as a theme is either loaded from a folder or
> > the class-loader, not a combination. As we extract the themes on the
> > appliance, all themes will always be loaded from
> > standalone/configuration/themes.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 29 July, 2014 4:32:42 PM
> >> Subject: Re: [keycloak-dev] resolving theme files
> >>
> >> Nevermind, I think I forgot to clear my browser cache and was loading
> >> old javascript files.
> >>
> >> On 7/29/2014 11:17 AM, Stian Thorgersen wrote:
> >>> If the theme is loaded using the class-loader it should be. On the
> >>> appliance the themes are extracted to standalone/configuration/themes
> >>> though, so they are loaded by the file loader instead.
> >>>
> >>> Maybe it would be better to add a separate theme type for the providers?
> >>> That way the theme won't be overridden.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Tuesday, 29 July, 2014 4:03:43 PM
> >>>> Subject: [keycloak-dev] resolving theme files
> >>>>
> >>>> Are all theme files required to be in the same JAR as the original
> >>>> theme?  I'd like to have my provider admin console html/javascript files
> >>>> in a separate jAR and I can't seem to resolve them at the moment.
> >>>> --
> >>>> 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 stian at redhat.com  Wed Jul 30 04:53:08 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 04:53:08 -0400 (EDT)
Subject: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
In-Reply-To: <53D813F2.1020604@redhat.com>
References: <295865000.19770918.1406638269823.JavaMail.zimbra@redhat.com>
	<53D81324.4030809@redhat.com> <53D813F2.1020604@redhat.com>
Message-ID: <1898417657.20272595.1406710388769.JavaMail.zimbra@redhat.com>

A general authentication plugin SPI for clients should be relatively straightforward, not sure about users though.

Credentials for users requires changes to the login flow as well as account management pages, so could be tricky to do it in a generic way.

Worth a try though! So let's wait until after 1.0.final with the TOTP work.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 10:36:50 PM
> Subject: Re: [keycloak-dev] Postpone TOTP SPI to after 1.0.final
> 
> By authentication plugin SPI, I actually mean a credential type plugin
> SPI.  Have a user requesting that they be able to plug in their own
> client-cert verification mechanism.
> 
> On 7/29/2014 5:33 PM, Bill Burke wrote:
> > Could this TOTP SPI turn into a general authentication plugin SPI?  Just
> > had an inquiry for that type of SPI.
> >
> > On 7/29/2014 8:51 AM, Stian Thorgersen wrote:
> >> Due to there being quite a lot of work to do the required updates to
> >> properly do a TOTP SPI I propose we post-pone this to 1.1.0.
> >>
> >> The work would include:
> >>
> >> * A TOTP SPI
> >> * Account management needs to support multiple TOTPs
> >> * Select TOTP provider to configure if required to setup TOTP on login
> >> * Select TOTP provider to use at login if user has multiple
> >> * Configure what TOTP are permitted for a realm
> >> * Remember TOTP option (don't ask for TOTP in 30 days on this machine)
> >> * Email implementation (send a OTP through email)
> >> * SMS implementation (use an example SMS cloud service to send OTP) - this
> >> would also require additional fields to registration
> >> * At least one other TOTP implementation (FreeOTP and Yubikey)
> >> * ...
> >> _______________________________________________
> >> 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 matzew at apache.org  Wed Jul 30 06:53:16 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 30 Jul 2014 12:53:16 +0200
Subject: [keycloak-dev] Keycloak Beta4 release
Message-ID: <CAAg5f2QHiYLgWpAnNBG0PLKSwosYGTicxAE_1c0PDCMDogiXcQ@mail.gmail.com>

Hi,

do you have concrete dates for the beta4?

At the moment we, in AeroGear, plan to wait for your beta4.
We plan to release our own 1.0.0.beta2 around August 7th, which will
include the KC beta4.

If the date stays on 6th, or earlier, I think we should be fine w/ our
planing!

Thanks!

-- 
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/20140730/a5f33b76/attachment.html 

From stian at redhat.com  Wed Jul 30 07:24:42 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 07:24:42 -0400 (EDT)
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <53D82370.2000201@redhat.com>
References: <53D82370.2000201@redhat.com>
Message-ID: <876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>

I think it's perfectly fine to configure these through keycloak-server.json for now. It's an advanced use-case after all.

Providing this feature properly is going to be quite tricky and time consuming I think. A few thoughts about this:

* We should at least look at UberFire
* If we do this - bootstrapping of providers should be done by retrieving the config for the console from the server (list of SPIs, providers, etc.) then this should be used to load scripts (through js) and add config to the routeprovider
* I'm still not convinced that this can't be achieved in a generic way - creating jax-rs, js scripts and html files for a provider is a big overhead (and would require developers to learn a lot of new tech)
* Resources/connections such as email servers, ldap servers, databases, etc. should be configured globally and referenced from the realm - basically what datasources do in an app server

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 29 July, 2014 11:42:56 PM
> Subject: [keycloak-dev] need feedback on pluggable fed console UI
> 
> I'm kind of at a block with providing an SPI to plugin federation
> provider console UIs.
> 
> I would need to:
> 
> 1. Provide a way to dynamically load the javascript of the plug
> - index.html could be processed with Freemarker or some other brute
> force means to add the appropriate <script> elements
> - Could add <script> tags within javascript (not sure about this, see
> $routeProvider
> 
> 2. $routeProvider can only be set up once it seems?  Function pointers
> need to already be established for controllers.
> 
> 3. We have to worry about name clashes with other admin console angular
> components?
> 
> I'm just not sure I want to create a full-fledged "portlet" spi at this
> late juncture.  My thinking is to hard code LDAP and any other provider
> has to be configured through keycloak_server.json or via a generic
> properties page.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Wed Jul 30 07:25:39 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 07:25:39 -0400 (EDT)
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
References: <53D82370.2000201@redhat.com>
	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
Message-ID: <1916430055.20327652.1406719539591.JavaMail.zimbra@redhat.com>

By the way I did a prototype of a very basic extendible console a while back, maybe something useful in there:

https://github.com/stianst/experiments/tree/master/console

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 30 July, 2014 12:24:42 PM
> Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
> 
> I think it's perfectly fine to configure these through keycloak-server.json
> for now. It's an advanced use-case after all.
> 
> Providing this feature properly is going to be quite tricky and time
> consuming I think. A few thoughts about this:
> 
> * We should at least look at UberFire
> * If we do this - bootstrapping of providers should be done by retrieving the
> config for the console from the server (list of SPIs, providers, etc.) then
> this should be used to load scripts (through js) and add config to the
> routeprovider
> * I'm still not convinced that this can't be achieved in a generic way -
> creating jax-rs, js scripts and html files for a provider is a big overhead
> (and would require developers to learn a lot of new tech)
> * Resources/connections such as email servers, ldap servers, databases, etc.
> should be configured globally and referenced from the realm - basically what
> datasources do in an app server
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 29 July, 2014 11:42:56 PM
> > Subject: [keycloak-dev] need feedback on pluggable fed console UI
> > 
> > I'm kind of at a block with providing an SPI to plugin federation
> > provider console UIs.
> > 
> > I would need to:
> > 
> > 1. Provide a way to dynamically load the javascript of the plug
> > - index.html could be processed with Freemarker or some other brute
> > force means to add the appropriate <script> elements
> > - Could add <script> tags within javascript (not sure about this, see
> > $routeProvider
> > 
> > 2. $routeProvider can only be set up once it seems?  Function pointers
> > need to already be established for controllers.
> > 
> > 3. We have to worry about name clashes with other admin console angular
> > components?
> > 
> > I'm just not sure I want to create a full-fledged "portlet" spi at this
> > late juncture.  My thinking is to hard code LDAP and any other provider
> > has to be configured through keycloak_server.json or via a generic
> > properties page.
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From bburke at redhat.com  Wed Jul 30 08:11:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Jul 2014 08:11:41 -0400
Subject: [keycloak-dev] Keycloak Beta4 release
In-Reply-To: <CAAg5f2QHiYLgWpAnNBG0PLKSwosYGTicxAE_1c0PDCMDogiXcQ@mail.gmail.com>
References: <CAAg5f2QHiYLgWpAnNBG0PLKSwosYGTicxAE_1c0PDCMDogiXcQ@mail.gmail.com>
Message-ID: <53D8E0FD.4030403@redhat.com>

we were shooting for Aug 6th.  Too late?

On 7/30/2014 6:53 AM, Matthias Wessendorf wrote:
> Hi,
>
> do you have concrete dates for the beta4?
>
> At the moment we, in AeroGear, plan to wait for your beta4.
> We plan to release our own 1.0.0.beta2 around August 7th, which will
> include the KC beta4.
>
> If the date stays on 6th, or earlier, I think we should be fine w/ our
> planing!
>
> Thanks!
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
>
> _______________________________________________
> 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  Wed Jul 30 08:51:42 2014
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 30 Jul 2014 14:51:42 +0200
Subject: [keycloak-dev] Keycloak Beta4 release
In-Reply-To: <53D8E0FD.4030403@redhat.com>
References: <CAAg5f2QHiYLgWpAnNBG0PLKSwosYGTicxAE_1c0PDCMDogiXcQ@mail.gmail.com>
	<53D8E0FD.4030403@redhat.com>
Message-ID: <CAAg5f2TGQuX5ovtn-P4=FkpHmnKqPPg0UHDHnQz+1c4YnkaYSw@mail.gmail.com>

Nope, I think August 6 works for us. That means we can release on 8th
(Friday) and get the announcement out on 11th

-Matthias

On Wed, Jul 30, 2014 at 2:11 PM, Bill Burke <bburke at redhat.com> wrote:

> we were shooting for Aug 6th.  Too late?
>
> On 7/30/2014 6:53 AM, Matthias Wessendorf wrote:
> > Hi,
> >
> > do you have concrete dates for the beta4?
> >
> > At the moment we, in AeroGear, plan to wait for your beta4.
> > We plan to release our own 1.0.0.beta2 around August 7th, which will
> > include the KC beta4.
> >
> > If the date stays on 6th, or earlier, I think we should be fine w/ our
> > planing!
> >
> > Thanks!
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
> >
> > _______________________________________________
> > 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/20140730/d5488a88/attachment.html 

From bruno at abstractj.org  Wed Jul 30 08:54:48 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 30 Jul 2014 09:54:48 -0300
Subject: [keycloak-dev] Keycloak Beta4 release
In-Reply-To: <CAAg5f2TGQuX5ovtn-P4=FkpHmnKqPPg0UHDHnQz+1c4YnkaYSw@mail.gmail.com>
References: <CAAg5f2QHiYLgWpAnNBG0PLKSwosYGTicxAE_1c0PDCMDogiXcQ@mail.gmail.com>
	<53D8E0FD.4030403@redhat.com>
	<CAAg5f2TGQuX5ovtn-P4=FkpHmnKqPPg0UHDHnQz+1c4YnkaYSw@mail.gmail.com>
Message-ID: <20140730125448.GC96403@abstractj.org>

+1 on it

On 2014-07-30, Matthias Wessendorf wrote:
> Nope, I think August 6 works for us. That means we can release on 8th
> (Friday) and get the announcement out on 11th
>
> -Matthias
>
> On Wed, Jul 30, 2014 at 2:11 PM, Bill Burke <bburke at redhat.com> wrote:
>
> > we were shooting for Aug 6th.  Too late?
> >
> > On 7/30/2014 6:53 AM, Matthias Wessendorf wrote:
> > > Hi,
> > >
> > > do you have concrete dates for the beta4?
> > >
> > > At the moment we, in AeroGear, plan to wait for your beta4.
> > > We plan to release our own 1.0.0.beta2 around August 7th, which will
> > > include the KC beta4.
> > >
> > > If the date stays on 6th, or earlier, I think we should be fine w/ our
> > > planing!
> > >
> > > Thanks!
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > twitter: http://twitter.com/mwessendorf
> > >
> > >
> > > _______________________________________________
> > > 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

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


--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Wed Jul 30 09:37:27 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Jul 2014 09:37:27 -0400
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
References: <53D82370.2000201@redhat.com>
	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
Message-ID: <53D8F517.1020206@redhat.com>



On 7/30/2014 7:24 AM, Stian Thorgersen wrote:
> I think it's perfectly fine to configure these through keycloak-server.json for now. It's an advanced use-case after all.
>

If somebody wants to integrate something (highly unlikely), our 
javascript files are provided by the theme.  They can edit index.html 
and app.js to add their <script> entries and their $routes.

> Providing this feature properly is going to be quite tricky and time consuming I think. A few thoughts about this:
>
> * We should at least look at UberFire

Or Hawt.io.  Which is why I didn't really want to do anything crazy here.

> * If we do this - bootstrapping of providers should be done by retrieving the config for the console from the server (list of SPIs, providers, etc.) then this should be used to load scripts (through js) and add config to the routeprovider
> * I'm still not convinced that this can't be achieved in a generic way - creating jax-rs, js scripts and html files for a provider is a big overhead (and would require developers to learn a lot of new tech)
> * Resources/connections such as email servers, ldap servers, databases, etc. should be configured globally and referenced from the realm - basically what datasources do in an app server
>

I don't agree that ldap servers and email servers would be or should be 
configured globally.

LDAP will be an often used feature.  It should have a nice UI and 
integrate real nice with the admin console.  Haven't you seen the 
numerous inquiries on federating multiple ldap stores too?  I just don't 
see ldap ever being configured globally.

For email, while the same email server might be used for different 
realms, there is a high probability that the settings will be different 
per realm  i.e.:

Subject header, email username/password, From, reply-to, email template, 
etc.


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

From stian at redhat.com  Wed Jul 30 09:55:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 09:55:31 -0400 (EDT)
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <53D8F517.1020206@redhat.com>
References: <53D82370.2000201@redhat.com>
	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
	<53D8F517.1020206@redhat.com>
Message-ID: <16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 30 July, 2014 2:37:27 PM
> Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
> 
> 
> 
> On 7/30/2014 7:24 AM, Stian Thorgersen wrote:
> > I think it's perfectly fine to configure these through keycloak-server.json
> > for now. It's an advanced use-case after all.
> >
> 
> If somebody wants to integrate something (highly unlikely), our
> javascript files are provided by the theme.  They can edit index.html
> and app.js to add their <script> entries and their $routes.
> 
> > Providing this feature properly is going to be quite tricky and time
> > consuming I think. A few thoughts about this:
> >
> > * We should at least look at UberFire
> 
> Or Hawt.io.  Which is why I didn't really want to do anything crazy here.
> 
> > * If we do this - bootstrapping of providers should be done by retrieving
> > the config for the console from the server (list of SPIs, providers, etc.)
> > then this should be used to load scripts (through js) and add config to
> > the routeprovider
> > * I'm still not convinced that this can't be achieved in a generic way -
> > creating jax-rs, js scripts and html files for a provider is a big
> > overhead (and would require developers to learn a lot of new tech)
> > * Resources/connections such as email servers, ldap servers, databases,
> > etc. should be configured globally and referenced from the realm -
> > basically what datasources do in an app server
> >
> 
> I don't agree that ldap servers and email servers would be or should be
> configured globally.
> 
> LDAP will be an often used feature.  It should have a nice UI and
> integrate real nice with the admin console.  Haven't you seen the
> numerous inquiries on federating multiple ldap stores too?  I just don't
> see ldap ever being configured globally.
> 
> For email, while the same email server might be used for different
> realms, there is a high probability that the settings will be different
> per realm  i.e.:
> 
> Subject header, email username/password, From, reply-to, email template,
> etc.

We'd still need realm specific config, but configuring the connection itself should be globally IMO.

You'd configure your email server globally (server address, etc.). Then you'd go to email settings for your realm, under there you'd be able to select an email server, then you'd set from/reply-to and that stuff there.

The data-source comparison is a pretty good comparison. For the data-source you configure url, pool-size, etc. you don't configure tables, etc.

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

From bburke at redhat.com  Wed Jul 30 11:18:24 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Jul 2014 11:18:24 -0400
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>
References: <53D82370.2000201@redhat.com>
	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
	<53D8F517.1020206@redhat.com>
	<16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>
Message-ID: <53D90CC0.4030203@redhat.com>



On 7/30/2014 9:55 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, 30 July, 2014 2:37:27 PM
>> Subject: Re: [keycloak-dev] need feedback on pluggable fed console UI
>>
>>
>>
>> On 7/30/2014 7:24 AM, Stian Thorgersen wrote:
>>> I think it's perfectly fine to configure these through keycloak-server.json
>>> for now. It's an advanced use-case after all.
>>>
>>
>> If somebody wants to integrate something (highly unlikely), our
>> javascript files are provided by the theme.  They can edit index.html
>> and app.js to add their <script> entries and their $routes.
>>
>>> Providing this feature properly is going to be quite tricky and time
>>> consuming I think. A few thoughts about this:
>>>
>>> * We should at least look at UberFire
>>
>> Or Hawt.io.  Which is why I didn't really want to do anything crazy here.
>>
>>> * If we do this - bootstrapping of providers should be done by retrieving
>>> the config for the console from the server (list of SPIs, providers, etc.)
>>> then this should be used to load scripts (through js) and add config to
>>> the routeprovider
>>> * I'm still not convinced that this can't be achieved in a generic way -
>>> creating jax-rs, js scripts and html files for a provider is a big
>>> overhead (and would require developers to learn a lot of new tech)
>>> * Resources/connections such as email servers, ldap servers, databases,
>>> etc. should be configured globally and referenced from the realm -
>>> basically what datasources do in an app server
>>>
>>
>> I don't agree that ldap servers and email servers would be or should be
>> configured globally.
>>
>> LDAP will be an often used feature.  It should have a nice UI and
>> integrate real nice with the admin console.  Haven't you seen the
>> numerous inquiries on federating multiple ldap stores too?  I just don't
>> see ldap ever being configured globally.
>>
>> For email, while the same email server might be used for different
>> realms, there is a high probability that the settings will be different
>> per realm  i.e.:
>>
>> Subject header, email username/password, From, reply-to, email template,
>> etc.
>
> We'd still need realm specific config, but configuring the connection itself should be globally IMO.
>
> You'd configure your email server globally (server address, etc.). Then you'd go to email settings for your realm, under there you'd be able to select an email server, then you'd set from/reply-to and that stuff there.
>

How is that user friendly?

* You have to go to and have permission to edit a global settings file 
or global admin non-realm (or master realm) specific UI screen.
* You then finish configuring the LDAP or EMAIL server in a separate 
realm-specific UI screen.

All this so that you might be able to share an EMAIL server's ip 
address/port.  And when you probably won't be sharing any LDAP config 
between realms?

As it is, I don't think we're going to have many multi-realm deployments 
and the master realm might end up being disabled (like in Aerogear).

> The data-source comparison is a pretty good comparison. For the data-source you configure url, pool-size, etc. you don't configure tables, etc.
>

Data-source is different than email.  Email can be set up at runtime as 
you don't need it to boot up the server.  A datasource has to be 
configured prior to boot time because you can't run Keycloak without it. 
  Changing datasource config will usually require a server restart.

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

From bburke at redhat.com  Wed Jul 30 11:29:39 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Jul 2014 11:29:39 -0400
Subject: [keycloak-dev] remove picketlink model too?
Message-ID: <53D90F63.2050202@redhat.com>

Can I remove picketlink model too?  We're not mainting it and the code 
is available under beta-3 or earlier tag.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed Jul 30 11:39:33 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 30 Jul 2014 11:39:33 -0400 (EDT)
Subject: [keycloak-dev] remove picketlink model too?
In-Reply-To: <53D90F63.2050202@redhat.com>
References: <53D90F63.2050202@redhat.com>
Message-ID: <199507303.20564628.1406734773659.JavaMail.zimbra@redhat.com>

+1 Was going to ask the same ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 30 July, 2014 4:29:39 PM
> Subject: [keycloak-dev] remove picketlink model too?
> 
> Can I remove picketlink model too?  We're not mainting it and the code
> is available under beta-3 or earlier tag.
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Wed Jul 30 11:53:22 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 30 Jul 2014 11:53:22 -0400
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <53D90CC0.4030203@redhat.com>
References: <53D82370.2000201@redhat.com>
	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>
	<53D8F517.1020206@redhat.com>
	<16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>
	<53D90CC0.4030203@redhat.com>
Message-ID: <53D914F2.7010104@redhat.com>

On 7/30/2014 11:18 AM, Bill Burke wrote:
> As it is, I don't think we're going to have many multi-realm deployments
> and the master realm might end up being disabled (like in Aerogear).
>
Why did they disable master realm?  Is there any reason not to use the 
master realm for single-realm deployments?

From bburke at redhat.com  Wed Jul 30 12:00:10 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 30 Jul 2014 12:00:10 -0400
Subject: [keycloak-dev] need feedback on pluggable fed console UI
In-Reply-To: <53D914F2.7010104@redhat.com>
References: <53D82370.2000201@redhat.com>	<876753459.20327433.1406719482459.JavaMail.zimbra@redhat.com>	<53D8F517.1020206@redhat.com>	<16223750.20459030.1406728531747.JavaMail.zimbra@redhat.com>	<53D90CC0.4030203@redhat.com>
	<53D914F2.7010104@redhat.com>
Message-ID: <53D9168A.5090400@redhat.com>



On 7/30/2014 11:53 AM, Stan Silvert wrote:
> On 7/30/2014 11:18 AM, Bill Burke wrote:
>> As it is, I don't think we're going to have many multi-realm deployments
>> and the master realm might end up being disabled (like in Aerogear).
>>
> Why did they disable master realm?  Is there any reason not to use the
> master realm for single-realm deployments?

The did it to make aerogear look like one product.  Keycloak admin, 
Aerogear admin, and Aerogear user console are all managed under one 
realm.  The idea is to hide keycloak's multi-realm capabilities.


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

From stian at redhat.com  Thu Jul 31 04:54:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 04:54:46 -0400 (EDT)
Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
In-Reply-To: <53D29B60.4070305@redhat.com>
References: <53C92152.5080709@redhat.com>
	<1653632070.18016797.1406291672350.JavaMail.zimbra@redhat.com>
	<53D29B60.4070305@redhat.com>
Message-ID: <1612048176.21152266.1406796886809.JavaMail.zimbra@redhat.com>

Hi Stan,

Sorry for late reply, got lost in my todo list.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org, "Juraci Paix?o Kr?hling" <jpkroehling at redhat.com>
> Sent: Friday, 25 July, 2014 7:01:04 PM
> Subject: Re: [keycloak-dev] Need advice on bootstrapping Keycloak
> 
> On 7/25/2014 8:34 AM, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org, "Juraci Paix?o Kr?hling"
> >> <jpkroehling at redhat.com>
> >> Sent: Friday, 18 July, 2014 2:29:54 PM
> >> Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
> >>
> >> Hi guys,
> >>
> >> My overall goal is to unite JBoss user-facing products via Keycloak
> >> SSO.  The first major task is make it as easy as possible to use
> >> Keycloak with the WildFly web console.  I have this working, but it
> >> takes quite a bit of setup.
> >>
> >> Ideally, there should be a simple switch in WildFly that says, "Use
> >> Keycloak for web console", and it all just works.
> >>
> >> So I'm looking for ideas on how to automate these setup tasks:
> >> * Deploy Keycloak auth server and keycloak-ds.xml
> > Is the plan eventually to deploy Keycloak as an extension instead of a WAR?
> > I reckon that would solve a fair amount of issues. Could even go as far as
> > creating KeycloakDS with a persistent H2 db from within the subsystem if
> > it's not available?
> Interesting idea.  What issues are you thinking this will solve?

If Keycloak is an extension rather than a WAR would we not be able to have all the modules there ready to go. Then there could be a simple one click button (maybe even in the WF console itself) to enable Keycloak, which would use DMR to enable the extension and also create the required datasource for KC.

It should also make it easier to update Keycloak as we could leverage the patching mechanism in WF right?

Our configuration mechanism (keycloak-server.json) is pluggable enough so that we could even make it possible to configure it through standalone.xml instead. Also, maybe we could leverage domains to manage a cluster of Keycloak nodes to make sure they all have the same config.

> >
> >> * Seed the database with an initial realm, user, roles, and two
> >> applications
> > What about defining a boostrap-realm.json file. We already have mechanisms
> > in place for importing a file at startup, which is only imported if the
> > realm doesn't already exist.
> How does the mechanism work?  I don't see the doco for it.  This might
> solve much of my problem.  But I need to let it generate new keys for
> the realm.  It should also generate a new secret for each application.
> Otherwise, everyone's installation would be the same.

At the moment you can either to it with a system property keycloak.import or servlet context-param keycloak.import.realm.resources to specify a json file with the contents of the realm and applications.

AeroGear guys use this to bootstrap their realm:

  https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/web.xml#L9

Haven't tested this, but I believe it'll be done before the WAR is marked as deployed.

It generates new keys for the realm, but not for applications, but that's something we could add easily enough. Also I think it would be worth to make sure it only runs on the first time, at the moment it just checks to see if the realm is there. Would also be nice to be able to add some bootstrapping to the master realm as well with this mechanism (which obviously wouldn't work ATM due to it would just see the master realm and ignore it)

> 
> Can I get a callback to know when the import is complete?  After all
> that is done, I need to create the subsystem definitions for the
> applications.  So I have to query Keycloak to find out what the
> installation parameters are.  Is all that doable?
> >
> >> * Create keycloak.json files or populate keycloak subsystem for the two
> >> apps.
> > Would be cool if you had an option to automatically create Keycloak
> > subsystem definitions for apps as they're creating in KC. Could have some
> > sort of co-located option or something.
> Actually, you don't even need the co-located option.  It could issue a
> CLI command to any server that has a Keycloak subsystem.  Not only that,
> you could even deploy the WAR from Keycloak Admin if you wanted to.  But
> I don't think you want Keycloak to be in the business of managing
> deployments.
> 
> This is where true integration with our other tools comes in. Keycloak
> manages security.  Web Console and JON manage deployments. All three
> should work together.  So when I want to deploy something, I should be
> able to do all this from an integrated UI:
> * Scan the WAR to find out its roles.
> * Auto-populate Keycloak with the application and role definitions.
> * Auto-populate Keycloak with the application's Redirect URI, Base URL, etc.
> * Create the Keycloak subsystem entries
> * Decide which WildFly instances the app will be deployed to.
> * Upload and deploy the WAR

Sounds great, but will we ever be able to achieve an integrated UI at this level? A simpler solution may be to deploy a WAR in the standard way to WF. Then to go to a Keycloak WildFly extension UI to do the other steps you listed above.

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


From stian at redhat.com  Thu Jul 31 05:40:31 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 05:40:31 -0400 (EDT)
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <722933141.21177882.1406799542586.JavaMail.zimbra@redhat.com>
Message-ID: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>

To make sure no-one goes of and uses Keycloak in production without HTTPS we should require SSL by default. To still allow developers to play with Keycloak without having to configure HTTPS first we should allow non-HTTPS if accessed via localhost only.

From bruno at abstractj.org  Thu Jul 31 06:11:44 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 31 Jul 2014 07:11:44 -0300
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
References: <722933141.21177882.1406799542586.JavaMail.zimbra@redhat.com>
	<1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
Message-ID: <20140731101144.GB24892@abstractj.org>

+1 on enforcing it. Do we have any plans around HSTS? Or this is
something that sysadmins should configure into their servers?

On 2014-07-31, Stian Thorgersen wrote:
> To make sure no-one goes of and uses Keycloak in production without HTTPS we should require SSL by default. To still allow developers to play with Keycloak without having to configure HTTPS first we should allow non-HTTPS if accessed via localhost only.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

--

abstractj
PGP: 0x84DC9914

From stian at redhat.com  Thu Jul 31 06:27:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 06:27:15 -0400 (EDT)
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <20140731101144.GB24892@abstractj.org>
References: <722933141.21177882.1406799542586.JavaMail.zimbra@redhat.com>
	<1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
	<20140731101144.GB24892@abstractj.org>
Message-ID: <658229952.21239700.1406802435811.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, 31 July, 2014 11:11:44 AM
> Subject: Re: [keycloak-dev] Enable SSL by default
> 
> +1 on enforcing it. Do we have any plans around HSTS? Or this is
> something that sysadmins should configure into their servers?

Currently we have an option to disable SSL for each realm (enabled by default), adding HSTS could be tricky as we'd need to know what the option in KC.

I'm not convinced we should have the option to disable SSL per-realm, instead we could make it into a global option for the whole server. A server is either in dev or production mode, I don't see a use-case to have one secure realm and one unsecure at the same time. That would make it a lot simpler to set the HSTS header in a jax-rs filter, also make it easier for us to check if SSL (for all requests) is enabled in the jax-rs filter.

> 
> On 2014-07-31, Stian Thorgersen wrote:
> > To make sure no-one goes of and uses Keycloak in production without HTTPS
> > we should require SSL by default. To still allow developers to play with
> > Keycloak without having to configure HTTPS first we should allow non-HTTPS
> > if accessed via localhost only.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> 

From mposolda at redhat.com  Thu Jul 31 07:33:35 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 13:33:35 +0200
Subject: [keycloak-dev] Sync + federation
Message-ID: <53DA298F.7020901@redhat.com>

Hi,

at this moment I have Sync with LDAP working (one way sync for importing 
LDAP users into Keycloak). I tested with ActiveDirectory and OpenDS. On 
both I have paginated and also full/partial periodic sync working. Also 
UserFederationProvider seems to be working with Active Directory now!

Pedro mentioned that he will do timestamped picketlink release once we 
need it. So far all the LDAP related issues should be fixed, so I've 
asked him for doing one. Let me know if you are aware of more issues.

The question is how to properly incorporate sync with current federation 
stuff? It looks that both should work together (for example if customer 
is going to write his FederationProvider to retrieve data from his DB, 
he will also likely want to sync users from same DB). Also sync process 
would likely need access to the federation configuration in 
UserFederationProviderModel, but some configuration of Sync will be 
common for all FederationProviders (For example pagination, periodic for 
full/partial sync etc). So I wonder if we can add properties like this 
directly into UserFederationProviderModel:

boolean enablePagination;
int pageSize;
long fullSyncPeriod;      // -1 if periodic fullSync should be disabled
long partialSyncPeriod;   // -1 if perodic partialSync should be disabled

And for Admin console UI, we can have some common template, which can be 
added into page of particular Federation Provider. For example on 
federated-ldap.html or federated-generic.html there can be checkbox on 
the bottom of the page like "enable synchronization of users" and when 
people check it, it will display other settings (pagination, period for 
full/partial sync, button for trigger sync directly from admin console etc).

Also not sure how to properly incorporate it into UserFederationProvider 
API... Actually UserFederationProvider is supposed to be per-session 
component whenever Sync process may actually use more 
session/transaction lifecycles. So adding methods for sync directly into 
UserFederationProvider may not work though... I wonder if we can have 
method on UserFederationProviderFactory:

UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory, 
UserFederationProviderModel model);

And UserSyncProvider being something like this:

public interface UserSyncProvider {
   void syncAllUsers(KeycloakSessionFactory sessionFactory, 
UserFederationProviderFactory fedFactory, String realmId, 
UserFederationProviderModel fedModel)
   void syncChangedUsers(KeycloakSessionFactory sessionFactory, 
UserFederationProviderFactory fedFactory, String realmId, 
UserFederationProviderModel fedModel, Date lastSync);
}

UserFederationProviderFactory may not be needed though as it can be 
retrieved from KeycloakSessionFactory+UserFederationProviderModel, just 
a convenience as UserSyncProvider will likely almost always need it. wdyt?

Note that I already have sync working with LDAP, so once we decide on 
API+configuration and once we have picketlink release, I can easily 
incorporate it.

Marek

From bruno at abstractj.org  Thu Jul 31 07:44:27 2014
From: bruno at abstractj.org (Bruno Oliveira)
Date: Thu, 31 Jul 2014 08:44:27 -0300
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <658229952.21239700.1406802435811.JavaMail.zimbra@redhat.com>
References: <722933141.21177882.1406799542586.JavaMail.zimbra@redhat.com>
	<1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
	<20140731101144.GB24892@abstractj.org>
	<658229952.21239700.1406802435811.JavaMail.zimbra@redhat.com>
Message-ID: <20140731114426.GA23684@abstractj.org>

+1 on make it global, I don't see any use case for disabling SSL per
realm.

On 2014-07-31, Stian Thorgersen wrote:
> ----- Original Message -----
> > From: "Bruno Oliveira" <bruno at abstractj.org>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Thursday, 31 July, 2014 11:11:44 AM
> > Subject: Re: [keycloak-dev] Enable SSL by default
> >
> > +1 on enforcing it. Do we have any plans around HSTS? Or this is
> > something that sysadmins should configure into their servers?
>
> Currently we have an option to disable SSL for each realm (enabled by default), adding HSTS could be tricky as we'd need to know what the option in KC.
>
> I'm not convinced we should have the option to disable SSL per-realm, instead we could make it into a global option for the whole server. A server is either in dev or production mode, I don't see a use-case to have one secure realm and one unsecure at the same time. That would make it a lot simpler to set the HSTS header in a jax-rs filter, also make it easier for us to check if SSL (for all requests) is enabled in the jax-rs filter.
>
> >
> > On 2014-07-31, Stian Thorgersen wrote:
> > > To make sure no-one goes of and uses Keycloak in production without HTTPS
> > > we should require SSL by default. To still allow developers to play with
> > > Keycloak without having to configure HTTPS first we should allow non-HTTPS
> > > if accessed via localhost only.
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
> >

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Thu Jul 31 08:53:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 08:53:48 -0400
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
References: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
Message-ID: <53DA3C5C.2070507@redhat.com>

So hardcode the localhost requirement?  That would work.  The switch 
would be "require ssl" or "non-encrypted localhost only"

On 7/31/2014 5:40 AM, Stian Thorgersen wrote:
> To make sure no-one goes of and uses Keycloak in production without HTTPS we should require SSL by default. To still allow developers to play with Keycloak without having to configure HTTPS first we should allow non-HTTPS if accessed via localhost only.
> _______________________________________________
> 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 Jul 31 09:04:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 09:04:47 -0400 (EDT)
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <53DA3C5C.2070507@redhat.com>
References: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
	<53DA3C5C.2070507@redhat.com>
Message-ID: <60163932.21324605.1406811887582.JavaMail.zimbra@redhat.com>

I propose we remove the SSL required switch on the Realm. Instead we have an option to configure SSL requirement in keycloak-server.json, which also allows excluding IP addresses.

Default config would be:

  {
    "https": {
       "required" : true,
       "exclude": [ "localhost", "127.0.0.1" ]
    }
  }

If someone wants to allow local network traffic without https they could change it to:

  {
    "https": {
       "required" : true,
       "exclude": [ "localhost", "127.0.0.1", "10.9.10.*" ]
    }
  }

And of course if someone really wants to they can disable it altogether with:

  {
    "https": {
       "required" : false,
       "exclude": [ "localhost", "127.0.0.1", "10.9.10.*" ]
    }
  }

If no config is specified I think it should default to required: true, with empty exclude.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 31 July, 2014 1:53:48 PM
> Subject: Re: [keycloak-dev] Enable SSL by default
> 
> So hardcode the localhost requirement?  That would work.  The switch
> would be "require ssl" or "non-encrypted localhost only"
> 
> On 7/31/2014 5:40 AM, Stian Thorgersen wrote:
> > To make sure no-one goes of and uses Keycloak in production without HTTPS
> > we should require SSL by default. To still allow developers to play with
> > Keycloak without having to configure HTTPS first we should allow non-HTTPS
> > if accessed via localhost only.
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 31 09:24:55 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 09:24:55 -0400 (EDT)
Subject: [keycloak-dev] Remaining work for beta-4
In-Reply-To: <1908534976.21334115.1406812467028.JavaMail.zimbra@redhat.com>
Message-ID: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>

Outstanding work for beta-4:

* User federation - what's the status?
* Require SSL by default - see previous email, I think we should add this for beta-4
* Access token validation endpoint (KEYCLOAK-585)
* Rename AuditListener/Provider to EventListener/Provider (KEYCLOAK-586, KEYCLOAK-587) - should we do this?
* Support HttpServletRequest.authenticate() (KEYCLOAK-575) - should be simple enough?
* Turn off cookie cache for all http clients (KEYCLOAK-537) - not sure I understand this issue? isn't sticky sessions something that's configured by the load balancer?
* RealmModel should have a link to realm admin app (KEYCLOAK-486) - I don't think the admin console should refer to the app by name, instead it should either have a link or at least the id of the app associated with the realm
* Issue with deploying on AS7 (KEYCLOAK-572) - should be fixed with new PL release, but do we really care about supporting AS7? 

Issues I propose we push to beta-5:

* LDAP sync - should this go into beta-5? or even wait until after final?
* Stress tests (KEYCLOAK-514) - we still haven't tested with a large amount of users
* DB optimizations (KEYCLOAK-515) - maybe push this to after final?
* "Transaction not active" while performing a shutdown (KEYCLOAK-470) - I can't replicate this, do we close or just set to no fix version?
* Login with totp includes password in clear text (KEYCLOAK-576) - afaik it's not good to include the password in plain-text in the html set to the client, which we do atm

Anything else?


As a reminder, I'm on PTO next week and Marek is on PTO tomorrow.

From bburke at redhat.com  Thu Jul 31 09:32:07 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 09:32:07 -0400
Subject: [keycloak-dev] Sync + federation
In-Reply-To: <53DA298F.7020901@redhat.com>
References: <53DA298F.7020901@redhat.com>
Message-ID: <53DA4557.2090307@redhat.com>



On 7/31/2014 7:33 AM, Marek Posolda wrote:
> Hi,
>
> at this moment I have Sync with LDAP working (one way sync for importing
> LDAP users into Keycloak). I tested with ActiveDirectory and OpenDS. On
> both I have paginated and also full/partial periodic sync working. Also
> UserFederationProvider seems to be working with Active Directory now!
>

What is the different between a partial and full sync?  Wouldn't there 
just be one background periodic sync job?


> Pedro mentioned that he will do timestamped picketlink release once we
> need it. So far all the LDAP related issues should be fixed, so I've
> asked him for doing one. Let me know if you are aware of more issues.
>
> The question is how to properly incorporate sync with current federation
> stuff? It looks that both should work together (for example if customer
> is going to write his FederationProvider to retrieve data from his DB,
> he will also likely want to sync users from same DB). Also sync process
> would likely need access to the federation configuration in
> UserFederationProviderModel, but some configuration of Sync will be
> common for all FederationProviders (For example pagination, periodic for
> full/partial sync etc). So I wonder if we can add properties like this
> directly into UserFederationProviderModel:
>
> boolean enablePagination;
> int pageSize;

Why would these ever need to be configured.  Either the provider 
supports pagination or it doesn't.



> long fullSyncPeriod;      // -1 if periodic fullSync should be disabled
> long partialSyncPeriod;   // -1 if perodic partialSync should be disabled
>

Another option is to let the UserFederationProviderFactory handle 
synchronization and be configured through keycloak-server.json.  Then 
there is no UI to do and no changes to the SPIs.

Keycloak would have a generic Job scheduler (does it already?) and in 
the UserFederationProviderFactory.init() method it would just schedule 
the appropriate jobs.


> And for Admin console UI, we can have some common template, which can be
> added into page of particular Federation Provider. For example on
> federated-ldap.html or federated-generic.html there can be checkbox on
> the bottom of the page like "enable synchronization of users" and when
> people check it, it will display other settings (pagination, period for
> full/partial sync, button for trigger sync directly from admin console etc).
>
> Also not sure how to properly incorporate it into UserFederationProvider
> API... Actually UserFederationProvider is supposed to be per-session
> component whenever Sync process may actually use more
> session/transaction lifecycles. So adding methods for sync directly into
> UserFederationProvider may not work though... I wonder if we can have
> method on UserFederationProviderFactory:
>
> UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
> UserFederationProviderModel model);
>
> And UserSyncProvider being something like this:
>
> public interface UserSyncProvider {
>     void syncAllUsers(KeycloakSessionFactory sessionFactory,
> UserFederationProviderFactory fedFactory, String realmId,
> UserFederationProviderModel fedModel)
>     void syncChangedUsers(KeycloakSessionFactory sessionFactory,
> UserFederationProviderFactory fedFactory, String realmId,
> UserFederationProviderModel fedModel, Date lastSync);
> }


What is the difference between syncAllUsers() and syncChangedUsers()? 
Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in 
LDAP store?  Is synchChangedUsers() only a synchronization from LDAP to 
Keycloak of only users that are currently imported into Keycloak?



Depending on the answers to above questions, maybe 
UserFederationProviderFactory would have the appropriate sync methods 
instead?  Then there would be one less interface that needs to be 
implemented.

UserFederationProviderFactory {

     void sync(KeycloakSessionFactory sessionFactory, String realmId, 
UserFederationProviderModel model);

}

Depending on the above answer to questions, the UI should have a manual 
sync button(s) so that the admin can trigger the sync if desired. 
Period synchronization should be OFF be default.

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

From stian at redhat.com  Thu Jul 31 09:43:21 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 09:43:21 -0400 (EDT)
Subject: [keycloak-dev] Sync + federation
In-Reply-To: <53DA4557.2090307@redhat.com>
References: <53DA298F.7020901@redhat.com> <53DA4557.2090307@redhat.com>
Message-ID: <149462987.21413697.1406814201742.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 31 July, 2014 2:32:07 PM
> Subject: Re: [keycloak-dev] Sync + federation
> 
> 
> 
> On 7/31/2014 7:33 AM, Marek Posolda wrote:
> > Hi,
> >
> > at this moment I have Sync with LDAP working (one way sync for importing
> > LDAP users into Keycloak). I tested with ActiveDirectory and OpenDS. On
> > both I have paginated and also full/partial periodic sync working. Also
> > UserFederationProvider seems to be working with Active Directory now!
> >
> 
> What is the different between a partial and full sync?  Wouldn't there
> just be one background periodic sync job?
> 
> 
> > Pedro mentioned that he will do timestamped picketlink release once we
> > need it. So far all the LDAP related issues should be fixed, so I've
> > asked him for doing one. Let me know if you are aware of more issues.
> >
> > The question is how to properly incorporate sync with current federation
> > stuff? It looks that both should work together (for example if customer
> > is going to write his FederationProvider to retrieve data from his DB,
> > he will also likely want to sync users from same DB). Also sync process
> > would likely need access to the federation configuration in
> > UserFederationProviderModel, but some configuration of Sync will be
> > common for all FederationProviders (For example pagination, periodic for
> > full/partial sync etc). So I wonder if we can add properties like this
> > directly into UserFederationProviderModel:
> >
> > boolean enablePagination;
> > int pageSize;
> 
> Why would these ever need to be configured.  Either the provider
> supports pagination or it doesn't.
> 
> 
> 
> > long fullSyncPeriod;      // -1 if periodic fullSync should be disabled
> > long partialSyncPeriod;   // -1 if perodic partialSync should be disabled
> >
> 
> Another option is to let the UserFederationProviderFactory handle
> synchronization and be configured through keycloak-server.json.  Then
> there is no UI to do and no changes to the SPIs.
> 
> Keycloak would have a generic Job scheduler (does it already?) and in
> the UserFederationProviderFactory.init() method it would just schedule
> the appropriate jobs.

Yep, it has a TimerProvider:

  https://github.com/keycloak/keycloak/blob/master/services/src/main/java/org/keycloak/services/resources/KeycloakApplication.java#L144

> 
> 
> > And for Admin console UI, we can have some common template, which can be
> > added into page of particular Federation Provider. For example on
> > federated-ldap.html or federated-generic.html there can be checkbox on
> > the bottom of the page like "enable synchronization of users" and when
> > people check it, it will display other settings (pagination, period for
> > full/partial sync, button for trigger sync directly from admin console
> > etc).
> >
> > Also not sure how to properly incorporate it into UserFederationProvider
> > API... Actually UserFederationProvider is supposed to be per-session
> > component whenever Sync process may actually use more
> > session/transaction lifecycles. So adding methods for sync directly into
> > UserFederationProvider may not work though... I wonder if we can have
> > method on UserFederationProviderFactory:
> >
> > UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
> > UserFederationProviderModel model);
> >
> > And UserSyncProvider being something like this:
> >
> > public interface UserSyncProvider {
> >     void syncAllUsers(KeycloakSessionFactory sessionFactory,
> > UserFederationProviderFactory fedFactory, String realmId,
> > UserFederationProviderModel fedModel)
> >     void syncChangedUsers(KeycloakSessionFactory sessionFactory,
> > UserFederationProviderFactory fedFactory, String realmId,
> > UserFederationProviderModel fedModel, Date lastSync);
> > }
> 
> 
> What is the difference between syncAllUsers() and syncChangedUsers()?
> Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in
> LDAP store?  Is synchChangedUsers() only a synchronization from LDAP to
> Keycloak of only users that are currently imported into Keycloak?
> 
> 
> 
> Depending on the answers to above questions, maybe
> UserFederationProviderFactory would have the appropriate sync methods
> instead?  Then there would be one less interface that needs to be
> implemented.
> 
> UserFederationProviderFactory {
> 
>      void sync(KeycloakSessionFactory sessionFactory, String realmId,
> UserFederationProviderModel model);
> 
> }
> 
> Depending on the above answer to questions, the UI should have a manual
> sync button(s) so that the admin can trigger the sync if desired.
> Period synchronization should be OFF be default.
> 
> --
> 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 Jul 31 09:50:40 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 09:50:40 -0400
Subject: [keycloak-dev] Remaining work for beta-4
In-Reply-To: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>
References: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>
Message-ID: <53DA49B0.3000002@redhat.com>

We MUST release by Wednesday.  All commits after Friday need to be done 
very carefully.  This means that you've run a full build and tested the 
distribution and demos.  Aerogear and Stan (among others) need a release...

On 7/31/2014 9:24 AM, Stian Thorgersen wrote:
> Outstanding work for beta-4:
>
> * User federation - what's the status?

Still working on UI and small issues.  Should be done Friday.

> * Turn off cookie cache for all http clients (KEYCLOAK-537) - not sure I understand this issue? isn't sticky sessions something that's configured by the load balancer?

Push this to 1.0.Final release.  The Apache HTTP Client instance is 
shared by the Adapter.  Cookie caching is on by default.  IIRC, sticky 
sessions by mod-jk are done via a cookie.  Thus accessCodeToToken 
requests will not be load balanced.

> * RealmModel should have a link to realm admin app (KEYCLOAK-486) - I don't think the admin console should refer to the app by name, instead it should either have a link or at least the id of the app associated with the realm

Can be pushed to 1.0.Final release, IMO.

> * Issue with deploying on AS7 (KEYCLOAK-572) - should be fixed with new PL release, but do we really care about supporting AS7?
>

Yes we care about AS7.  We need a release from Picketlink on Monday so 
we can test on Tuesday.  We will have to make sure that picketlink 
modules are excluded in jboss-deployment-structure.xml and we include 
the picketlink modules directly.  Patching picketlink modules directly 
is not an option.

> Issues I propose we push to beta-5:
>

I don't think we'll have a beta-5.  Next release will be 1.0.Final, ASAP 
after beta-4.

> * LDAP sync - should this go into beta-5? or even wait until after final?

+1 Marek is close, but should wait until after beta-4 is out.

> * Stress tests (KEYCLOAK-514) - we still haven't tested with a large amount of users
> * DB optimizations (KEYCLOAK-515) - maybe push this to after final?
> * "Transaction not active" while performing a shutdown (KEYCLOAK-470) - I can't replicate this, do we close or just set to no fix version?

close.  I coudln't replicate either.



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

From bburke at redhat.com  Thu Jul 31 10:05:31 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 10:05:31 -0400
Subject: [keycloak-dev] delete users on federation removal?
Message-ID: <53DA4D2B.5090404@redhat.com>

I'm assuming that if a UserFederationProvider is removed from a realm, 
then all users imported from that provider should be deleted?

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

From stian at redhat.com  Thu Jul 31 10:09:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 10:09:46 -0400 (EDT)
Subject: [keycloak-dev] delete users on federation removal?
In-Reply-To: <53DA4D2B.5090404@redhat.com>
References: <53DA4D2B.5090404@redhat.com>
Message-ID: <327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>

I think it should be optional.

Someone may for example migrate from LDAP to using Keycloak. Once they've migrated all apps they'll want to decommission the LDAP server, but they would still want to keep the users.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 31 July, 2014 3:05:31 PM
> Subject: [keycloak-dev] delete users on federation removal?
> 
> I'm assuming that if a UserFederationProvider is removed from a realm,
> then all users imported from that provider should be deleted?
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 31 11:15:40 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 11:15:40 -0400 (EDT)
Subject: [keycloak-dev] Enable SSL by default
In-Reply-To: <60163932.21324605.1406811887582.JavaMail.zimbra@redhat.com>
References: <1346103619.21178655.1406799631863.JavaMail.zimbra@redhat.com>
	<53DA3C5C.2070507@redhat.com>
	<60163932.21324605.1406811887582.JavaMail.zimbra@redhat.com>
Message-ID: <1193209595.21486920.1406819740132.JavaMail.zimbra@redhat.com>

This is pretty tricky if we want a nice error page. Especially as we need to know the realm to know the login theme.

I'm dropping this, and instead adding RealmModel.isSslNotRequiredLocalRequest. By default isSslNotRequired will be false, while isSslNotRequiredLocalRequest will be true.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 31 July, 2014 2:04:47 PM
> Subject: Re: [keycloak-dev] Enable SSL by default
> 
> I propose we remove the SSL required switch on the Realm. Instead we have an
> option to configure SSL requirement in keycloak-server.json, which also
> allows excluding IP addresses.
> 
> Default config would be:
> 
>   {
>     "https": {
>        "required" : true,
>        "exclude": [ "localhost", "127.0.0.1" ]
>     }
>   }
> 
> If someone wants to allow local network traffic without https they could
> change it to:
> 
>   {
>     "https": {
>        "required" : true,
>        "exclude": [ "localhost", "127.0.0.1", "10.9.10.*" ]
>     }
>   }
> 
> And of course if someone really wants to they can disable it altogether with:
> 
>   {
>     "https": {
>        "required" : false,
>        "exclude": [ "localhost", "127.0.0.1", "10.9.10.*" ]
>     }
>   }
> 
> If no config is specified I think it should default to required: true, with
> empty exclude.
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Thursday, 31 July, 2014 1:53:48 PM
> > Subject: Re: [keycloak-dev] Enable SSL by default
> > 
> > So hardcode the localhost requirement?  That would work.  The switch
> > would be "require ssl" or "non-encrypted localhost only"
> > 
> > On 7/31/2014 5:40 AM, Stian Thorgersen wrote:
> > > To make sure no-one goes of and uses Keycloak in production without HTTPS
> > > we should require SSL by default. To still allow developers to play with
> > > Keycloak without having to configure HTTPS first we should allow
> > > non-HTTPS
> > > if accessed via localhost only.
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > >
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Jul 31 11:17:13 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 31 Jul 2014 11:17:13 -0400 (EDT)
Subject: [keycloak-dev] Remaining work for beta-4
In-Reply-To: <53DA49B0.3000002@redhat.com>
References: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>
	<53DA49B0.3000002@redhat.com>
Message-ID: <528168403.21487770.1406819833024.JavaMail.zimbra@redhat.com>

Should we not at least do an RC before final?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, 31 July, 2014 2:50:40 PM
> Subject: Re: [keycloak-dev] Remaining work for beta-4
> 
> We MUST release by Wednesday.  All commits after Friday need to be done
> very carefully.  This means that you've run a full build and tested the
> distribution and demos.  Aerogear and Stan (among others) need a release...
> 
> On 7/31/2014 9:24 AM, Stian Thorgersen wrote:
> > Outstanding work for beta-4:
> >
> > * User federation - what's the status?
> 
> Still working on UI and small issues.  Should be done Friday.
> 
> > * Turn off cookie cache for all http clients (KEYCLOAK-537) - not sure I
> > understand this issue? isn't sticky sessions something that's configured
> > by the load balancer?
> 
> Push this to 1.0.Final release.  The Apache HTTP Client instance is
> shared by the Adapter.  Cookie caching is on by default.  IIRC, sticky
> sessions by mod-jk are done via a cookie.  Thus accessCodeToToken
> requests will not be load balanced.
> 
> > * RealmModel should have a link to realm admin app (KEYCLOAK-486) - I don't
> > think the admin console should refer to the app by name, instead it should
> > either have a link or at least the id of the app associated with the realm
> 
> Can be pushed to 1.0.Final release, IMO.
> 
> > * Issue with deploying on AS7 (KEYCLOAK-572) - should be fixed with new PL
> > release, but do we really care about supporting AS7?
> >
> 
> Yes we care about AS7.  We need a release from Picketlink on Monday so
> we can test on Tuesday.  We will have to make sure that picketlink
> modules are excluded in jboss-deployment-structure.xml and we include
> the picketlink modules directly.  Patching picketlink modules directly
> is not an option.
> 
> > Issues I propose we push to beta-5:
> >
> 
> I don't think we'll have a beta-5.  Next release will be 1.0.Final, ASAP
> after beta-4.
> 
> > * LDAP sync - should this go into beta-5? or even wait until after final?
> 
> +1 Marek is close, but should wait until after beta-4 is out.
> 
> > * Stress tests (KEYCLOAK-514) - we still haven't tested with a large amount
> > of users
> > * DB optimizations (KEYCLOAK-515) - maybe push this to after final?
> > * "Transaction not active" while performing a shutdown (KEYCLOAK-470) - I
> > can't replicate this, do we close or just set to no fix version?
> 
> close.  I coudln't replicate either.
> 
> 
> 
> --
> 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 Jul 31 11:32:50 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 11:32:50 -0400
Subject: [keycloak-dev] Remaining work for beta-4
In-Reply-To: <528168403.21487770.1406819833024.JavaMail.zimbra@redhat.com>
References: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>
	<53DA49B0.3000002@redhat.com>
	<528168403.21487770.1406819833024.JavaMail.zimbra@redhat.com>
Message-ID: <53DA61A2.3080103@redhat.com>

I guess we could.  Like a one or two week "last chance!" period.  I just 
want to get started on the 1.1 features ASAP.

On 7/31/2014 11:17 AM, Stian Thorgersen wrote:
> Should we not at least do an RC before final?
>


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

From bburke at redhat.com  Thu Jul 31 14:23:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 14:23:45 -0400
Subject: [keycloak-dev] Can I remove AuthenticationProvider now?
Message-ID: <53DA89B1.3040407@redhat.com>


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

From bburke at redhat.com  Thu Jul 31 14:54:08 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 14:54:08 -0400
Subject: [keycloak-dev] Can I remove AuthenticationProvider now?
In-Reply-To: <53DA89B1.3040407@redhat.com>
References: <53DA89B1.3040407@redhat.com>
Message-ID: <53DA90D0.50500@redhat.com>

As well as LDAP config from RealmModel and admin console?

On 7/31/2014 2:23 PM, Bill Burke wrote:
>

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

From mposolda at redhat.com  Thu Jul 31 15:00:25 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 21:00:25 +0200
Subject: [keycloak-dev] Sync + federation
In-Reply-To: <53DA4557.2090307@redhat.com>
References: <53DA298F.7020901@redhat.com> <53DA4557.2090307@redhat.com>
Message-ID: <53DA9249.70408@redhat.com>

On 31.7.2014 15:32, Bill Burke wrote:
>
> On 7/31/2014 7:33 AM, Marek Posolda wrote:
>> Hi,
>>
>> at this moment I have Sync with LDAP working (one way sync for importing
>> LDAP users into Keycloak). I tested with ActiveDirectory and OpenDS. On
>> both I have paginated and also full/partial periodic sync working. Also
>> UserFederationProvider seems to be working with Active Directory now!
>>
> What is the different between a partial and full sync?  Wouldn't there
> just be one background periodic sync job?
I was thinking that "full" sync is checking all "remote" (ldap) users 
and adding or updating them in Keycloak DB. When "partial" will be just 
checking users, which were added or updated from previous sync. 
Basically "partial" will leverage changelogs, but "full" will always 
sync all users.

Also with LDAP, you can ask (with both Active Directory and OpenDS) for 
ldap users, which were added/updated in last N hours, but you can't 
easily track deleted users. So I was also thinking that during "full" 
sync, you will verify all "local" users with federationLink and check 
that they are still exists ((basically what 
UserFederationProvider.isValid is doing) and delete them if not.

Or do you think it's not needed? Maybe we can do full sync just when 
calling for the first time and then periodically do just periodic 
"partial" syncs? And removed users will be checked just "on demand" (ie. 
when UserFederationManager.validateAndProxyUser is called from Keycloak) ?
>
>
>> Pedro mentioned that he will do timestamped picketlink release once we
>> need it. So far all the LDAP related issues should be fixed, so I've
>> asked him for doing one. Let me know if you are aware of more issues.
>>
>> The question is how to properly incorporate sync with current federation
>> stuff? It looks that both should work together (for example if customer
>> is going to write his FederationProvider to retrieve data from his DB,
>> he will also likely want to sync users from same DB). Also sync process
>> would likely need access to the federation configuration in
>> UserFederationProviderModel, but some configuration of Sync will be
>> common for all FederationProviders (For example pagination, periodic for
>> full/partial sync etc). So I wonder if we can add properties like this
>> directly into UserFederationProviderModel:
>>
>> boolean enablePagination;
>> int pageSize;
> Why would these ever need to be configured.  Either the provider
> supports pagination or it doesn't.
It's tricky to rely just on implementation though. For example LDAP 
implementation generally supports pagination, but some LDAP servers 
support it, some are not. But you will use same implementation (aka 
LDAPFederationProvider) for both. So I believe that it should be a way 
to disable pagination if you are for example on ApacheDS. Also 
configuring pageSize might be useful too according to environment? And 
for unit test, you usually want to test with small pageSize just to 
verify that it works;-)

Right now, I already have configurable pageSize and each "page" from 
LDAP is synced into Keycloak DB in separate transaction.
>
>
>
>> long fullSyncPeriod;      // -1 if periodic fullSync should be disabled
>> long partialSyncPeriod;   // -1 if perodic partialSync should be disabled
>>
> Another option is to let the UserFederationProviderFactory handle
> synchronization and be configured through keycloak-server.json.  Then
> there is no UI to do and no changes to the SPIs.
>
> Keycloak would have a generic Job scheduler (does it already?) and in
> the UserFederationProviderFactory.init() method it would just schedule
> the appropriate jobs.
Do we want to support the usecase, when you have 2 realms and you want 
sync from LDAP on "realm1" each 1 hour and on "realm2" each 5 hours? 
Also you may want to use different pageSize for each LDAP server (or you 
may have ActiveDirectory on "realm1" which supports pagination and 
"ApacheDS" on "realm2" which doesn't etc). In this case generic 
configuration in keycloak-server.json won't work though?

>
>
>> And for Admin console UI, we can have some common template, which can be
>> added into page of particular Federation Provider. For example on
>> federated-ldap.html or federated-generic.html there can be checkbox on
>> the bottom of the page like "enable synchronization of users" and when
>> people check it, it will display other settings (pagination, period for
>> full/partial sync, button for trigger sync directly from admin console etc).
>>
>> Also not sure how to properly incorporate it into UserFederationProvider
>> API... Actually UserFederationProvider is supposed to be per-session
>> component whenever Sync process may actually use more
>> session/transaction lifecycles. So adding methods for sync directly into
>> UserFederationProvider may not work though... I wonder if we can have
>> method on UserFederationProviderFactory:
>>
>> UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
>> UserFederationProviderModel model);
>>
>> And UserSyncProvider being something like this:
>>
>> public interface UserSyncProvider {
>>      void syncAllUsers(KeycloakSessionFactory sessionFactory,
>> UserFederationProviderFactory fedFactory, String realmId,
>> UserFederationProviderModel fedModel)
>>      void syncChangedUsers(KeycloakSessionFactory sessionFactory,
>> UserFederationProviderFactory fedFactory, String realmId,
>> UserFederationProviderModel fedModel, Date lastSync);
>> }
>
> What is the difference between syncAllUsers() and syncChangedUsers()?
> Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in
> LDAP store?
yes. And likely also checking all "local" users with federation link, 
that link is still valid (ie. user wasn't deleted in LDAP, basically 
what UserFederationProvider.isValid is doing) and delete if not.

>   Is synchChangedUsers() only a synchronization from LDAP to
> Keycloak of only users that are currently imported into Keycloak?
It will leverage changelogs and sync just those "remote" users, which 
were added/updated (or removed if supported, but it's tricky for LDAP as 
I mentioned) remotely from the last sync.

>
>
>
> Depending on the answers to above questions, maybe
> UserFederationProviderFactory would have the appropriate sync methods
> instead?  Then there would be one less interface that needs to be
> implemented.
>
> UserFederationProviderFactory {
>
>       void sync(KeycloakSessionFactory sessionFactory, String realmId,
> UserFederationProviderModel model);
>
> }
I am fine with adding the methods directly on the factory. Was also 
thinking about it, but wasn't sure if having methods on "factory" class 
is not a workaround though;-)

Marek
>
> Depending on the above answer to questions, the UI should have a manual
> sync button(s) so that the admin can trigger the sync if desired.
> Period synchronization should be OFF be default.
>


From mposolda at redhat.com  Thu Jul 31 15:05:16 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 21:05:16 +0200
Subject: [keycloak-dev] delete users on federation removal?
In-Reply-To: <327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>
References: <53DA4D2B.5090404@redhat.com>
	<327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>
Message-ID: <53DA936C.6090609@redhat.com>

+1 for having it optional.

However if you remove LDAP UserFederationProvider, the users from LDAP 
won't be able to login with their passwords until admin change them...

Marek

On 31.7.2014 16:09, Stian Thorgersen wrote:
> I think it should be optional.
>
> Someone may for example migrate from LDAP to using Keycloak. Once they've migrated all apps they'll want to decommission the LDAP server, but they would still want to keep the users.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 31 July, 2014 3:05:31 PM
>> Subject: [keycloak-dev] delete users on federation removal?
>>
>> I'm assuming that if a UserFederationProvider is removed from a realm,
>> then all users imported from that provider should be deleted?
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Thu Jul 31 15:16:22 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 21:16:22 +0200
Subject: [keycloak-dev] Remaining work for beta-4
In-Reply-To: <53DA49B0.3000002@redhat.com>
References: <1881643549.21352506.1406813095491.JavaMail.zimbra@redhat.com>
	<53DA49B0.3000002@redhat.com>
Message-ID: <53DA9606.60704@redhat.com>

On 31.7.2014 15:50, Bill Burke wrote:
> We MUST release by Wednesday.  All commits after Friday need to be done
> very carefully.  This means that you've run a full build and tested the
> distribution and demos.  Aerogear and Stan (among others) need a release...
>
> On 7/31/2014 9:24 AM, Stian Thorgersen wrote:
>> Outstanding work for beta-4:
>>
>> * User federation - what's the status?
> Still working on UI and small issues.  Should be done Friday.
>
>> * Turn off cookie cache for all http clients (KEYCLOAK-537) - not sure I understand this issue? isn't sticky sessions something that's configured by the load balancer?
> Push this to 1.0.Final release.  The Apache HTTP Client instance is
> shared by the Adapter.  Cookie caching is on by default.  IIRC, sticky
> sessions by mod-jk are done via a cookie.  Thus accessCodeToToken
> requests will not be load balanced.
>
>> * RealmModel should have a link to realm admin app (KEYCLOAK-486) - I don't think the admin console should refer to the app by name, instead it should either have a link or at least the id of the app associated with the realm
> Can be pushed to 1.0.Final release, IMO.
>
>> * Issue with deploying on AS7 (KEYCLOAK-572) - should be fixed with new PL release, but do we really care about supporting AS7?
>>
> Yes we care about AS7.  We need a release from Picketlink on Monday so
> we can test on Tuesday.  We will have to make sure that picketlink
> modules are excluded in jboss-deployment-structure.xml and we include
> the picketlink modules directly.  Patching picketlink modules directly
> is not an option.
>
>> Issues I propose we push to beta-5:
>>
> I don't think we'll have a beta-5.  Next release will be 1.0.Final, ASAP
> after beta-4.
>
>> * LDAP sync - should this go into beta-5? or even wait until after final?
> +1 Marek is close, but should wait until after beta-4 is out.
+1, Pedro is releasing picketlink today, but I am on PTO tomorrow. I can 
finish sync on Monday though, but looks that it's too late for the 
release...
>
>> * Stress tests (KEYCLOAK-514) - we still haven't tested with a large amount of users
I've tested with max 3000 users so far. I think I will need to setup 
jenkins job for add big amount of users into DB and then test them.

Marek
>> * DB optimizations (KEYCLOAK-515) - maybe push this to after final?
>> * "Transaction not active" while performing a shutdown (KEYCLOAK-470) - I can't replicate this, do we close or just set to no fix version?
> close.  I coudln't replicate either.
>
>
>


From mposolda at redhat.com  Thu Jul 31 15:26:23 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 21:26:23 +0200
Subject: [keycloak-dev] Can I remove AuthenticationProvider now?
In-Reply-To: <53DA90D0.50500@redhat.com>
References: <53DA89B1.3040407@redhat.com> <53DA90D0.50500@redhat.com>
Message-ID: <53DA985F.90602@redhat.com>

+1, I've did some testing of ActiveDirectory with latest picketlink and 
UserFederationProvider and works fine.

But do you also want to remove picketlink modules? I would personally 
keep them to allow people to init picketlink PartitionManager from 
different location ? Good thing on LDAPFederationProvider is, that it's 
defacto not tightly coupled to LDAP but it's using picketlink, so it can 
be used to federate users from any picketlink IdentityStore.

So far in my local "picketlink-master" fork, I've changed 
UserFederationProvider to use those to obtain PartitionManager and I 
removed stuff you copied before from it (like PartitionManagerRegistry 
etc). I hope to merge it early on Monday before you join online. wdyt?

Marek

On 31.7.2014 20:54, Bill Burke wrote:
> As well as LDAP config from RealmModel and admin console?
>
> On 7/31/2014 2:23 PM, Bill Burke wrote:


From bburke at redhat.com  Thu Jul 31 15:51:58 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 15:51:58 -0400
Subject: [keycloak-dev] Can I remove AuthenticationProvider now?
In-Reply-To: <53DA985F.90602@redhat.com>
References: <53DA89B1.3040407@redhat.com> <53DA90D0.50500@redhat.com>
	<53DA985F.90602@redhat.com>
Message-ID: <53DA9E5E.7070904@redhat.com>



On 7/31/2014 3:26 PM, Marek Posolda wrote:
> +1, I've did some testing of ActiveDirectory with latest picketlink and
> UserFederationProvider and works fine.
>
> But do you also want to remove picketlink modules?

We don't have to remove them, but the non-abstract classes are LDAP 
specific.

> I would personally
> keep them to allow people to init picketlink PartitionManager from
> different location ? Good thing on LDAPFederationProvider is, that it's
> defacto not tightly coupled to LDAP but it's using picketlink, so it can
> be used to federate users from any picketlink IdentityStore.
>

It is tightly coupled with LDAP at least what is in trunk.

> So far in my local "picketlink-master" fork, I've changed
> UserFederationProvider to use those to obtain PartitionManager and I
> removed stuff you copied before from it (like PartitionManagerRegistry
> etc). I hope to merge it early on Monday before you join online. wdyt?
>

I've been doing some work with LDAPFederationProvider today.  If you 
don't think it can be done by Monday, then it can hold off until after 
Beta 4 release.



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

From bburke at redhat.com  Thu Jul 31 16:01:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 16:01:15 -0400
Subject: [keycloak-dev] Sync + federation
In-Reply-To: <53DA9249.70408@redhat.com>
References: <53DA298F.7020901@redhat.com> <53DA4557.2090307@redhat.com>
	<53DA9249.70408@redhat.com>
Message-ID: <53DAA08B.9010808@redhat.com>



On 7/31/2014 3:00 PM, Marek Posolda wrote:
>>> boolean enablePagination;
>>> int pageSize;
>> Why would these ever need to be configured.  Either the provider
>> supports pagination or it doesn't.
> It's tricky to rely just on implementation though. For example LDAP
> implementation generally supports pagination, but some LDAP servers
> support it, some are not. But you will use same implementation (aka
> LDAPFederationProvider) for both. So I believe that it should be a way
> to disable pagination if you are for example on ApacheDS. Also
> configuring pageSize might be useful too according to environment? And
> for unit test, you usually want to test with small pageSize just to
> verify that it works;-)
>
> Right now, I already have configurable pageSize and each "page" from
> LDAP is synced into Keycloak DB in separate transaction.

I just don't want the general SPI polluted with implementation details 
of one adapter.

>>
>>
>>
>>> long fullSyncPeriod;      // -1 if periodic fullSync should be disabled
>>> long partialSyncPeriod;   // -1 if perodic partialSync should be
>>> disabled
>>>
>> Another option is to let the UserFederationProviderFactory handle
>> synchronization and be configured through keycloak-server.json.  Then
>> there is no UI to do and no changes to the SPIs.
>>
>> Keycloak would have a generic Job scheduler (does it already?) and in
>> the UserFederationProviderFactory.init() method it would just schedule
>> the appropriate jobs.
> Do we want to support the usecase, when you have 2 realms and you want
> sync from LDAP on "realm1" each 1 hour and on "realm2" each 5 hours?
> Also you may want to use different pageSize for each LDAP server (or you
> may have ActiveDirectory on "realm1" which supports pagination and
> "ApacheDS" on "realm2" which doesn't etc). In this case generic
> configuration in keycloak-server.json won't work though?
>

It was just an idea...

>>
>>
>>> And for Admin console UI, we can have some common template, which can be
>>> added into page of particular Federation Provider. For example on
>>> federated-ldap.html or federated-generic.html there can be checkbox on
>>> the bottom of the page like "enable synchronization of users" and when
>>> people check it, it will display other settings (pagination, period for
>>> full/partial sync, button for trigger sync directly from admin
>>> console etc).
>>>
>>> Also not sure how to properly incorporate it into UserFederationProvider
>>> API... Actually UserFederationProvider is supposed to be per-session
>>> component whenever Sync process may actually use more
>>> session/transaction lifecycles. So adding methods for sync directly into
>>> UserFederationProvider may not work though... I wonder if we can have
>>> method on UserFederationProviderFactory:
>>>
>>> UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
>>> UserFederationProviderModel model);
>>>
>>> And UserSyncProvider being something like this:
>>>
>>> public interface UserSyncProvider {
>>>      void syncAllUsers(KeycloakSessionFactory sessionFactory,
>>> UserFederationProviderFactory fedFactory, String realmId,
>>> UserFederationProviderModel fedModel)
>>>      void syncChangedUsers(KeycloakSessionFactory sessionFactory,
>>> UserFederationProviderFactory fedFactory, String realmId,
>>> UserFederationProviderModel fedModel, Date lastSync);
>>> }
>>
>> What is the difference between syncAllUsers() and syncChangedUsers()?
>> Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in
>> LDAP store?
> yes. And likely also checking all "local" users with federation link,
> that link is still valid (ie. user wasn't deleted in LDAP, basically
> what UserFederationProvider.isValid is doing) and delete if not.
>
>>   Is synchChangedUsers() only a synchronization from LDAP to
>> Keycloak of only users that are currently imported into Keycloak?
> It will leverage changelogs and sync just those "remote" users, which
> were added/updated (or removed if supported, but it's tricky for LDAP as
> I mentioned) remotely from the last sync.

Ya, those separate methods soound good.

>
>>
>>
>>
>> Depending on the answers to above questions, maybe
>> UserFederationProviderFactory would have the appropriate sync methods
>> instead?  Then there would be one less interface that needs to be
>> implemented.
>>
>> UserFederationProviderFactory {
>>
>>       void sync(KeycloakSessionFactory sessionFactory, String realmId,
>> UserFederationProviderModel model);
>>
>> }
> I am fine with adding the methods directly on the factory. Was also
> thinking about it, but wasn't sure if having methods on "factory" class
> is not a workaround though;-)
>

I say put them on factory.


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

From mposolda at redhat.com  Thu Jul 31 16:38:46 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 22:38:46 +0200
Subject: [keycloak-dev] Sync + federation
In-Reply-To: <53DAA08B.9010808@redhat.com>
References: <53DA298F.7020901@redhat.com> <53DA4557.2090307@redhat.com>
	<53DA9249.70408@redhat.com> <53DAA08B.9010808@redhat.com>
Message-ID: <53DAA956.6040303@redhat.com>

On 31.7.2014 22:01, Bill Burke wrote:
>
>
> On 7/31/2014 3:00 PM, Marek Posolda wrote:
>>>> boolean enablePagination;
>>>> int pageSize;
>>> Why would these ever need to be configured.  Either the provider
>>> supports pagination or it doesn't.
>> It's tricky to rely just on implementation though. For example LDAP
>> implementation generally supports pagination, but some LDAP servers
>> support it, some are not. But you will use same implementation (aka
>> LDAPFederationProvider) for both. So I believe that it should be a way
>> to disable pagination if you are for example on ApacheDS. Also
>> configuring pageSize might be useful too according to environment? And
>> for unit test, you usually want to test with small pageSize just to
>> verify that it works;-)
>>
>> Right now, I already have configurable pageSize and each "page" from
>> LDAP is synced into Keycloak DB in separate transaction.
>
> I just don't want the general SPI polluted with implementation details 
> of one adapter.
Ok, it can be part of the LDAP FederationProvider configuration then.
>
>>>
>>>
>>>
>>>> long fullSyncPeriod;      // -1 if periodic fullSync should be 
>>>> disabled
>>>> long partialSyncPeriod;   // -1 if perodic partialSync should be
>>>> disabled
>>>>
>>> Another option is to let the UserFederationProviderFactory handle
>>> synchronization and be configured through keycloak-server.json.  Then
>>> there is no UI to do and no changes to the SPIs.
>>>
>>> Keycloak would have a generic Job scheduler (does it already?) and in
>>> the UserFederationProviderFactory.init() method it would just schedule
>>> the appropriate jobs.
>> Do we want to support the usecase, when you have 2 realms and you want
>> sync from LDAP on "realm1" each 1 hour and on "realm2" each 5 hours?
>> Also you may want to use different pageSize for each LDAP server (or you
>> may have ActiveDirectory on "realm1" which supports pagination and
>> "ApacheDS" on "realm2" which doesn't etc). In this case generic
>> configuration in keycloak-server.json won't work though?
>>
>
> It was just an idea...
>
>>>
>>>
>>>> And for Admin console UI, we can have some common template, which 
>>>> can be
>>>> added into page of particular Federation Provider. For example on
>>>> federated-ldap.html or federated-generic.html there can be checkbox on
>>>> the bottom of the page like "enable synchronization of users" and when
>>>> people check it, it will display other settings (pagination, period 
>>>> for
>>>> full/partial sync, button for trigger sync directly from admin
>>>> console etc).
>>>>
>>>> Also not sure how to properly incorporate it into 
>>>> UserFederationProvider
>>>> API... Actually UserFederationProvider is supposed to be per-session
>>>> component whenever Sync process may actually use more
>>>> session/transaction lifecycles. So adding methods for sync directly 
>>>> into
>>>> UserFederationProvider may not work though... I wonder if we can have
>>>> method on UserFederationProviderFactory:
>>>>
>>>> UserSyncProvider getInstance(KeycloakSessionFactory sessionFactory,
>>>> UserFederationProviderModel model);
>>>>
>>>> And UserSyncProvider being something like this:
>>>>
>>>> public interface UserSyncProvider {
>>>>      void syncAllUsers(KeycloakSessionFactory sessionFactory,
>>>> UserFederationProviderFactory fedFactory, String realmId,
>>>> UserFederationProviderModel fedModel)
>>>>      void syncChangedUsers(KeycloakSessionFactory sessionFactory,
>>>> UserFederationProviderFactory fedFactory, String realmId,
>>>> UserFederationProviderModel fedModel, Date lastSync);
>>>> }
>>>
>>> What is the difference between syncAllUsers() and syncChangedUsers()?
>>> Is syncAllUsers() an import/sync from LDAP to Keycloak of all users in
>>> LDAP store?
>> yes. And likely also checking all "local" users with federation link,
>> that link is still valid (ie. user wasn't deleted in LDAP, basically
>> what UserFederationProvider.isValid is doing) and delete if not.
>>
>>>   Is synchChangedUsers() only a synchronization from LDAP to
>>> Keycloak of only users that are currently imported into Keycloak?
>> It will leverage changelogs and sync just those "remote" users, which
>> were added/updated (or removed if supported, but it's tricky for LDAP as
>> I mentioned) remotely from the last sync.
>
> Ya, those separate methods soound good.
>
>>
>>>
>>>
>>>
>>> Depending on the answers to above questions, maybe
>>> UserFederationProviderFactory would have the appropriate sync methods
>>> instead?  Then there would be one less interface that needs to be
>>> implemented.
>>>
>>> UserFederationProviderFactory {
>>>
>>>       void sync(KeycloakSessionFactory sessionFactory, String realmId,
>>> UserFederationProviderModel model);
>>>
>>> }
>> I am fine with adding the methods directly on the factory. Was also
>> thinking about it, but wasn't sure if having methods on "factory" class
>> is not a workaround though;-)
>>
>
> I say put them on factory.
>
>
Great, will do.

Marek


From mposolda at redhat.com  Thu Jul 31 16:42:16 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 31 Jul 2014 22:42:16 +0200
Subject: [keycloak-dev] Can I remove AuthenticationProvider now?
In-Reply-To: <53DA9E5E.7070904@redhat.com>
References: <53DA89B1.3040407@redhat.com>
	<53DA90D0.50500@redhat.com>	<53DA985F.90602@redhat.com>
	<53DA9E5E.7070904@redhat.com>
Message-ID: <53DAAA28.30006@redhat.com>

On 31.7.2014 21:51, Bill Burke wrote:
>
> On 7/31/2014 3:26 PM, Marek Posolda wrote:
>> +1, I've did some testing of ActiveDirectory with latest picketlink and
>> UserFederationProvider and works fine.
>>
>> But do you also want to remove picketlink modules?
> We don't have to remove them, but the non-abstract classes are LDAP
> specific.
>
>> I would personally
>> keep them to allow people to init picketlink PartitionManager from
>> different location ? Good thing on LDAPFederationProvider is, that it's
>> defacto not tightly coupled to LDAP but it's using picketlink, so it can
>> be used to federate users from any picketlink IdentityStore.
>>
> It is tightly coupled with LDAP at least what is in trunk.
>
>> So far in my local "picketlink-master" fork, I've changed
>> UserFederationProvider to use those to obtain PartitionManager and I
>> removed stuff you copied before from it (like PartitionManagerRegistry
>> etc). I hope to merge it early on Monday before you join online. wdyt?
>>
> I've been doing some work with LDAPFederationProvider today.  If you
> don't think it can be done by Monday, then it can hold off until after
> Beta 4 release.
I can easily update picketlink and do this on Monday. Not sure if will 
be able to finish sync by Monday or rather from Monday focus on testing 
/ bugfixing?

Marek

From bburke at redhat.com  Thu Jul 31 17:57:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 17:57:02 -0400
Subject: [keycloak-dev] almost done with my UserFederation work
Message-ID: <53DABBAE.4080405@redhat.com>

General changes:

* method signatures have changed a little on UserFederationProvider
* UserFederationProviderModel exposes priority and display name. 
Display name is what will be shown in the federation provider list in 
the admin console.  It defaults to the id of the provider.
* UserFederationProviderFactory now has a getOptions() method.  This 
lists attributes available for configuration on generic html page. 
(Same as auth provider did).

LDAP changes:

* LDAPFederationProvider has new config option called EditMode
- READ_ONLY mode.   Exception will be thrown if UserModel.setFirst, 
Last, Email, or Username is called.  Also, if update of password is 
performed
- WRITEABLE mode.  Calls LDAP server to update those 4 attributes and 
password
- UNSYNCED mode.  Doesn't callback to LDAP server to update.  Password 
can be overridden locally.
* LDAPFederationProvider has new config option syncRegistrations 
true/false.  If set to true, if the provider has priority, any addUser() 
call will add the user to LDAP too.



UI work:
* There is an LDAP specific screen
* There is a generic user federation provider configuration screen
* Searches now query user providers and should show up on user list page.
* View user page will show a link back to the User Federation Provider 
if the user has been loaded via federation.

Left to be done:
* Behavior on when a provider is deleted.


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

From bburke at redhat.com  Thu Jul 31 18:01:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 18:01:12 -0400
Subject: [keycloak-dev] delete users on federation removal?
In-Reply-To: <53DA936C.6090609@redhat.com>
References: <53DA4D2B.5090404@redhat.com>	<327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>
	<53DA936C.6090609@redhat.com>
Message-ID: <53DABCA8.7000107@redhat.com>

Ya, this is quite hairy.  You'll have to set the REQUIRED ACTION to 
reset all credentials handled by the federation provider.

Unfortunately, you can now only set one required action per user :(

On 7/31/2014 3:05 PM, Marek Posolda wrote:
> +1 for having it optional.
>
> However if you remove LDAP UserFederationProvider, the users from LDAP
> won't be able to login with their passwords until admin change them...
>
> Marek
>
> On 31.7.2014 16:09, Stian Thorgersen wrote:
>> I think it should be optional.
>>
>> Someone may for example migrate from LDAP to using Keycloak. Once they've migrated all apps they'll want to decommission the LDAP server, but they would still want to keep the users.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, 31 July, 2014 3:05:31 PM
>>> Subject: [keycloak-dev] delete users on federation removal?
>>>
>>> I'm assuming that if a UserFederationProvider is removed from a realm,
>>> then all users imported from that provider should be deleted?
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From bburke at redhat.com  Thu Jul 31 18:03:17 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 18:03:17 -0400
Subject: [keycloak-dev] need multiple required actions
Message-ID: <53DABD25.6030001@redhat.com>

admin may want to force the user to reset *ALL* credentials.  Currently 
can only force the user to reset one at a time.

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

From bburke at redhat.com  Thu Jul 31 18:16:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 18:16:15 -0400
Subject: [keycloak-dev] delete users on federation removal?
In-Reply-To: <53DABCA8.7000107@redhat.com>
References: <53DA4D2B.5090404@redhat.com>	<327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>	<53DA936C.6090609@redhat.com>
	<53DABCA8.7000107@redhat.com>
Message-ID: <53DAC02F.1090806@redhat.com>

Even more hairy, you can't reset a password without knowing (and 
verifying) the old one.



On 7/31/2014 6:01 PM, Bill Burke wrote:
> Ya, this is quite hairy.  You'll have to set the REQUIRED ACTION to
> reset all credentials handled by the federation provider.
>
> Unfortunately, you can now only set one required action per user :(
>
> On 7/31/2014 3:05 PM, Marek Posolda wrote:
>> +1 for having it optional.
>>
>> However if you remove LDAP UserFederationProvider, the users from LDAP
>> won't be able to login with their passwords until admin change them...
>>
>> Marek
>>
>> On 31.7.2014 16:09, Stian Thorgersen wrote:
>>> I think it should be optional.
>>>
>>> Someone may for example migrate from LDAP to using Keycloak. Once they've migrated all apps they'll want to decommission the LDAP server, but they would still want to keep the users.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 31 July, 2014 3:05:31 PM
>>>> Subject: [keycloak-dev] delete users on federation removal?
>>>>
>>>> I'm assuming that if a UserFederationProvider is removed from a realm,
>>>> then all users imported from that provider should be deleted?
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

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

From bburke at redhat.com  Thu Jul 31 18:41:12 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 18:41:12 -0400
Subject: [keycloak-dev] release timelines
Message-ID: <53DAC608.9060600@redhat.com>

I set up the release timelines.  IMO, the dates are set with no moving 
of them unless there is a blocker bug.

Beta-4:  August 6th.  This can't be delayed.  Whatever is not done by 
EOD Monday is deferred.

1.0-RC-1: August 21st.

1.0.0.Final: September 9th.


We have 34 outstanding issues.

There should only be bug fixes, example/docs, and minor look and feel 
changes after RC1.  The week before the final release, I'll be updating 
all the screencasts so there should be no visual changes please!


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

From bburke at redhat.com  Thu Jul 31 18:52:45 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 31 Jul 2014 18:52:45 -0400
Subject: [keycloak-dev] delete users on federation removal?
In-Reply-To: <53DAC02F.1090806@redhat.com>
References: <53DA4D2B.5090404@redhat.com>	<327201677.21432840.1406815786960.JavaMail.zimbra@redhat.com>	<53DA936C.6090609@redhat.com>	<53DABCA8.7000107@redhat.com>
	<53DAC02F.1090806@redhat.com>
Message-ID: <53DAC8BD.5020207@redhat.com>

HOnestly I think we should just delete all users that have the link and 
deferr the rest until after 1.1.  This will take a lot of work and there 
is a lot of little things that need to be done.

On 7/31/2014 6:16 PM, Bill Burke wrote:
> Even more hairy, you can't reset a password without knowing (and
> verifying) the old one.
>
>
>
> On 7/31/2014 6:01 PM, Bill Burke wrote:
>> Ya, this is quite hairy.  You'll have to set the REQUIRED ACTION to
>> reset all credentials handled by the federation provider.
>>
>> Unfortunately, you can now only set one required action per user :(
>>
>> On 7/31/2014 3:05 PM, Marek Posolda wrote:
>>> +1 for having it optional.
>>>
>>> However if you remove LDAP UserFederationProvider, the users from LDAP
>>> won't be able to login with their passwords until admin change them...
>>>
>>> Marek
>>>
>>> On 31.7.2014 16:09, Stian Thorgersen wrote:
>>>> I think it should be optional.
>>>>
>>>> Someone may for example migrate from LDAP to using Keycloak. Once they've migrated all apps they'll want to decommission the LDAP server, but they would still want to keep the users.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, 31 July, 2014 3:05:31 PM
>>>>> Subject: [keycloak-dev] delete users on federation removal?
>>>>>
>>>>> I'm assuming that if a UserFederationProvider is removed from a realm,
>>>>> then all users imported from that provider should be deleted?
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>

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