[keycloak-dev] redesign of federation

[Marek Posolda]

On 30/10/15 23:13, Bill Burke wrote:
> In doing group model, I was thinking more about federation.  Our SPI
> kinda sucks.  I was thinking that local storage (Model API) and
> UserFederation should be the same exact SPI.  Instead of just
> RealmProvider and UserProvider, we might break it up into:
>
> * RealmProvider - holds realms and clients
> * UserProvider - holds username and attributes about the user
> * UserRelationshipProvider - holds user role mappings, user group membership
> * UserCredentialProvider - stores and authenticates credentials
> * GroupProvider - holds group definitions
> * RoleProvider - holds role definitions
+1 for adding GroupProvider and RoleProvider. That seems to me like big 
limitation of current federation provider, that it's not able to handle 
CRUD of roles into the external storage.

But I might be missing why we need 3 separate "user" providers? It seems 
that current model can handle well the user attributes, relationships 
and credentials? Once UserFederationProvider returns the proxy object, 
you can implement CRUD of relationships and credentials in the proxy 
object itself?
>
> One of the big problems we have is that roles and groups have to be
> defined within Keycloak DB even though they might live in one or more
> external stores.
>
> Admin console would have to change too.  You'd have to pick which
> database you wanted to manage.  i.e. if you wanted to add a role you
> might want to add it to an LDAP store and not local storage.
Hmm... shouldn't we have same pattern like for user federation? So the 
role and group will be always added to "local" DB, but additionally 
synced to the external DB? Thing is that external storage may not be 
able to save all the metadata we have for roles and groups. Also we need 
some reference (roleID, groupID) to be available in Keycloak.

 From my LDAP experience, the CRUD of relationships is not a problem, as 
you can return UserModel proxy where you can override the relationship 
CRUD methods (grantRole, deleteRoleMapping, getRoleMappings, 
hasRole...). The problem is the CRUD of roles itself. When you create 
new role in Keycloak admin console, it's saved into LDAP during first 
call of "grantRole" . So this direction is quite fine. But the LDAP to 
Keycloak direction is much worse. In other words,when new role is added 
in LDAP, there is no way to notify Keycloak about it.

Marek
>
> This is something we'd really have to map out and design.  I would love
> to be able to do it before product, but I don't think we'll have enough
> time to bake it in community.  Maybe something we'll have to wait for
> Keycloak 2.0.
>