sync/federation requirements/ideas
by Bill Burke
To expand on our discussion around AuthenticationProvider. With the
currrent implementation of AuthenticationProvider, Keycloak admin
console cannot be used to manage external users until the user has
logged in and a UserModel creation has happened. We would need to
duplicate the "import" logic that is within AuthenticationManager
wherever UserProvider.getUserByXXXX() is invoked. Not only that, but
role mappings and other claim data may be contained in external storage.
The authentictionProvider interface is inadequate for these scenarios.
My thinking is that for federation and sync would come in three flavors:
* Keycloak storage. What we currently implement.
* Full external storage. The app developer will use their own
persistence model to store and manage users. In this case, they need to
fully implement the UserProvider interface. Handle social links,
required actions, role mappings etc.
* A sync/import model. In this case, keycloak is augmenting an existing
user storage. This would require partially or fully importing the user
from the external store into Keycloak UserModel/Provider storage. The
import is required so that Keycloak can managed REQUIRED ACTIONS, social
links, and add additional or manage existing credential types. We also
need the import to establish relationships between the user and
UserSession metadata. We may also have to handle role mappings within
Keycloak. A sync/import model example could be an LDAP store that just
contains username, email, first/last, and password. And the admin wants
to add role mappings and totp.
How would it work?
I think all this should be done through a common UserProvider interface.
Initially be able to federate only 1 additional external store as I'm
worried that there may be the possibility of duplicate user names if you
allow more than one and you'd need a way at login to pick which one to
log in from.
UserProviderFactory would specify its feature set:
Query Capabilities:
REGISTRATION
QUERY_BY_USER_ID
QUERY_BY_USERNAME
QUERY_BY_EMAIL
QUERY_BY_ATTRIBUTES
And its supported credential validation:
PASSWORD_VALIDATION
TOTP_VALIDATION
CERT_VALIDATION
And its supported credential storage:
PASSWORD_STORAGE
TOTP_STORAGE
CERT_STORAGE
There would a FederatedUserProvider to manage local and federated storage.
*Locating a user:*
1. FederatedUserProvider queries local storage first.
2. Check realm to see if federated storage configured
3. Load that provider
4. See if that provider supports query method, if not return null
5. Call query method on provider
Provider performs the following on user location:
6. Do custom query to find user
7. Get a local storage session and create a user within local storage
importing whatever can be imported.
8. Mark in local user storage which provider loaded it.
9. return the local user
*Required Actions and Credential management*
1. Find provider used to load user
2. Check credential storage options
3. If provider doesn't support credential update/storage, then store in
local storage
*Authentication*
1. Find user in local storage
2. See if credential is stored in local storage, validate from there if so.
3. If not stored, check provider validation options. Abort if not supported
4. Invoke on external provider to validate credentials supported by that
provider
Did I cover everything?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
triple abstraction?
by Bill Burke
Geez,
We now have a 6 levels of indirection:
KeycloakSession->ModelProvider->Model API->Hybrid API->Adapter->Entity
Too...much...abstraction.... It needs to be consolidated. When you're
done with the mongo store, I'd like to refactor and merge the model and
hybrid apis and get services/ to use it. We need this done before
beta-4 and beyond. I can't really finish my cache work until the
underlying API is on a solid foundation, and right now, IMO, it isn't.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
How would you handle an external user store?
by Bill Burke
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
12 years
Hybrid store committed
by Stian Thorgersen
I've committed the hybrid store including jpa store implementations. It's enabled by default for the testsuite and the server, using jpa for realms and users, and mem for sessions.
By default the JPA stores all use the same persistence-unit, but it's possible to split into multiple persistence-units and configure through keycloak-server.json if someone wants to for example store realms in one db and users in another.
Remaining work includes:
* Mongo stores
* Updates to Keycloak session - remove model methods and add an enlist transaction feature for providers
* EntityManager and Mongo connection providers - I'm going to add providers for retrieving EntityManager instances and Mongo clients. The main reason for this is so that multiple stores can share the same connection/transaction when possible
* Delete JPA and Mongo model providers
* Update tests
12 years
AdminAPITest
by Bill Burke
FYI:
Developing a testsuite that takes a RealmRepresentation and tries to
invoke/generate as many Admin REST api cals as possible based on that
RealmRepresentation. Goal is to attain 100% coverage on the Admin REST API.
Just in case somebody else might be thinking of working on it.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12 years
