[keycloak-dev] in-memory only federated users

[Bill Burke]

Some are balking at importing every user when doing federation with 
backends like ldap even though only minimal import is needed (i.e. 
username/providerID).

On 12/2/2015 12:27 PM, Scott Rossillo wrote:
> What problem does this solve? It seems like an uncommon use case.
>
>
> Scott Rossillo
> Smartling | Senior Software Engineer
> srossillo at smartling.com <mailto:srossillo at smartling.com>
>
>
>> On Dec 2, 2015, at 11:48 AM, Bill Burke <bburke at redhat.com
>> <mailto:bburke at redhat.com>> wrote:
>>
>> I'm looking into in-memory only no-import federated users.  What we
>> would want to do is allow the UserFederationProvider to create an
>> in-memory UserModel and allow for that UserModel to be cached via our
>> current architecture.
>>
>> The current design assumes that all federated users are imported.  This
>> includes our caching layer too!  To add to that, the user isn't cached
>> until the 2nd request i.e.:
>>
>> 1. username/password page would hit the UserFederationProvider and the
>> user would be imported into Keycloak.  This imported user is not cached,
>> only imported into the database for this request's KeycloakSession
>> 2. OTP Page or code 2 token would then want to lookup the user by id as
>> that is what is stored in the ClientSession.  It would hit the keycloak
>> database as it is not cached yet.  This lookup loads the cache for the
>> user.
>>
>> Getting in-memory zero-import to work is even more tricky.  The issue is
>> that ClientSession and UserSession need to lookup clients by id.  If the
>> user is not in cache, then the cache needs to lookup the user by id
>> within storage.  This lookup also needs to happen if a write operation
>> is performed on a cache user (getDelegateForUpdate()).  So, Keycloak
>> needs to know that that ID is not in local storage and must be looked up
>> from a fed provider.  The ID must be formed so that the provider fed
>> provider can resolve the lookup.  I could use a URI for the ID i.e.
>>
>> fed:{providerId}:{login-name}
>>
>> The problem with this is that this id would need to be larger than 36
>> characters which is the current column size for UserEntity.id and any
>> other table that references users.   I could possibly do:
>>
>> fed:{providerAlias}:{login-name}
>>
>> But its quite possible that combination would be larger than 36
>> characters.  We could also just shrink it to:
>>
>> fed:{login-name}
>>
>> But then we would have to iterate over every federation provider to find
>> and load the user.
>>
>> So in summary:
>> * IDs need to expand from 36 characters to something larger. (255
>> maybe).  Don't some DBs have constraints on string primary key size?  DB
>> scripts could possibly be
>> * CachedUserProvider and UserFederationManager interfaces would need to
>> be refactored
>> * I don't think UserFederationProvider interface would need to change.
>> But users would have to code for in-memory rather than throwing a switch
>> to just turn it on.
>>
>>
>>
>> --
>> 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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com