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.