[keycloak-dev] sync/federation requirements/ideas

[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