[keycloak-dev] triple abstraction?

[Stian Thorgersen]

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
>