Some additional thoughts:
* All user and realm metadata (group, roles, etc..) needs to be referenced by a URI. URI would have a schema like this: {provider}:{identifier}. Identifier can be anything. A keycloak datastore would just be a primary key id, for LDAP it might be the username, rolename, group name. You get the picture. Then a manager service ould be used to resolve the URI into an actual Model interface. User reference URIs could point to a broker (social or parent IDP),an LDAP store, local keycloak db, etc.
* For social login and brokering you would assign a user storage mechanism to import the user into. We would have 3 possible built-in options, JPA or Mongo, and Infinispan clustered in-memory cache.
On 3/3/2016 2:09 PM, Stian Thorgersen wrote:
I've written up some thoughts on improving the model for 2.x at https://docs.google.com/a/redhat.com/document/d/1ZmPjlJYvk_fwYvnWxz1E49ioZFZa3kfYCI1xE5gVClc/pub
_______________________________________________ keycloak-dev mailing list keycloak-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev