[keycloak-dev] How would you handle an external user store?

Stian Thorgersen stian at redhat.com
Tue Jul 8 11:42:12 EDT 2014


Cut/paste from previous email:


AuthProvider is trying to achieve something different than storing users, and the combination of the two is quite flexible. Someone could still achieve what they can achieve with AuthProvider by creating a UserProvider impl that delegates to another UserProvider impl for storage, so maybe we could respin the AuthProvider SPI into a UserProvider that can use another UserProvider for storing users, and one or more UserProviders for authentication. That way we'd still have the capability, but with it less hard-coded into the core code.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | AuthUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Authenticate  +--------------------+


Same again with Sync SPI, that could be done as a delegating UserProvider store.

                                         +--------------------+
                           Store         |                    |
                            +------------>  JpaUserProvider   |
                            |            |                    |
                            |            +--------------------+
         +------------------+
         |                  |
         | SyncUserProvider |            +--------------------+
         |                  |            |                    |
         +------------------+            |  LDAPUserProvider  |
                            +------------>                    |
                           Sync          +--------------------+



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:21:46 PM
> Subject: [keycloak-dev] How would you handle an external user store?
> 
> It is not very clear going forward the relationship between
> AuthenticationProvider and UserProvider.  My understanding was that
> UserProvider split was implemented to help users handle the case where
> they have an existing user store they want to use.  IMO,
> AuthenticationProvider have overlapping concerns and should be merged.
> 
> Let's say we have LdAP that stores
> 
> username,
> password,
> address
> phone
> 
> But no role mappings.  How would you handle both authentication and
> implementing the UserProvider with role mapping support?
> 
> I just think our current way/split of UserProvider,
> AuthenticationProvider, and UserModel just isn't going to cut it going
> forward.  Think of federation too where one Keycloak server might have
> to federate multiple user stores.  Each of those stores might have
> static data models which don't fully support Keycloak metadata which may
> require us to store some user information in Keycloak's storage.
> 
> I think a UserProvider needs to tell keycloak:
> 
> * What user metadata it stores
> * What credential types does the UserProvider store?
> * What credential types should the store validate?
> * What credential types should Keycloak validate?
> 
> Keycloak needs a reference to local storage to the UserProvider so it
> can create local UserModels if necessary.  The local UserModel needs to
> have metadata that answers all the above questions.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


More information about the keycloak-dev mailing list