Is it doable/feasible at all and how it could be achieved?
The idea is to have simple/lightweight/readonly custom UserStorageProvider (done already), but everything what is related to the password (storage, policies, etc.) to leave for KC.
You can still stick to
AbstractUserAdapterFederatedStorage and build your provider with
when it comes to storing parts of the data to Keycloak, use local storage provider.
May you elaborate more on this?
By reading KC documentation I understand that AbstractUserAdapterFederatedStorage differs from AbstractUserAdapter on the number of attributes/properties that could be overridden. Seems that I may need help from it in case I would like to load also my custom roles assigned to the user (not even sure yet how).
But my first thoughts on how to integrate with KC was to tell that it should read/query/look for user data (except password as it doesn’t exist) in my custom storage (already done), but when performing actual authentication it should use it’s own logics.
public class CustomUserStorageProvider implements
UserStorageProvider, // Ok
UserLookupProvider, // Ok
UserQueryProvider // Ok
//CredentialInputValidator — this one I would like to leave for KC to take care of
But is this achievable and logical at all?
As prior KC somehow should already know about existing users in my custom storage and have created storage for credentials in it’s own. But maybe this could be achieved by special KC API call from my application after I create a new user there?
All ideas are welcome as I am at early stages of integrating with KC. Anything makes sense.