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(a)redhat.com>
To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev