8:44 a.m.
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.