[keycloak-dev] in-memory only federated users

[Bill Burke]

On 12/2/2015 10:53 PM, Adam Young wrote:
>> 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}
>
> I'd recommend this, and increasing the size of the Database column.
>

We have many deployments already and some have quite large user 
databases.  Was really concerned that expanding the column size would 
piss a lot of people off because of the DB migration required.


We were talking a few weeks ago about ALL of our IDs becoming URIs. 
roles, groups, realms, clients, etc.  It would give us the flexibility 
of federating anything we wanted going further.    For example, 
currently admins have to define roles and groups in keycloak.  This 
sucks if they are already defined and controlled someplace else.

> Keystoen did this, but then SHA256 hashed it, makuing it a 64 character
> string. We found we were OK so long as we stayed under 255, as that was
> the limit mysql imposed for the string columns.
>
>>
>> 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.
>
> It gets trickier:  you don;'t want one federation provider to step on
> the login from an other:  ayoung at coke is a different user from
> ayoung at pepsi.  Having the Id be something issued by Keycloak + something
> that comes from the Federated IdP is necessary.
>

Not really.  This is no different than a user logging into the 
user/password screen.  Keycloak allows you to specify the order of 
federation providers, but doesn't handle conflicts, i.e. one LDAP server 
has the same username as another.

>
> I like in memory, but there are many questions to answer, when a user
> comes back a second time, what happens with their Id.  I pushed for
> ephemeral for Keystone, and we couldn't make it work.
>

We track sessions, have offline sessions, and track consents.  So an ID 
cannot be temporary.

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