[keycloak-dev] Progress on LDAP enhancements

[Marek Posolda]

I think I am finished with step 1 prototype on LDAP enhancements. Right 
now it's just in my local fork 
https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as 
model and admin console are kind of broken in my fork (ATM I am testing 
with some hardcoded configs).

What I did so far:

- Refactoring and simplifying of forked picketlink LDAP code and removed 
some abstractions to make it easier to use

- Added UserFederationMapper SPI. The plan is to be in line with already 
existing ProtocolMappers and IdentityProviderMappers.

- Added LDAPFederationMapper. This mapper is invoked from 
LDAPFederationProvider and provides some callbacks and extension points. 
For more details, see methods and javadoc: 
https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java 
. I have 3 implementations right now:
-- UserAttributeLDAPFederationMapper - This is used to map LDAP 
attributes to UserModel attributes/properties .
-- FullNameLDAPFederationMapper - Many LDAP deployments store fullName 
of user in single LDAP attribute (usually "cn" attribute). So this 
allows to map fullName from LDAP to firstName and lastName on UserModel
-- RoleLDAPFederationMapper - allows to map LDAP roles and user role 
mappings from some DN in LDAP tree to either realm roles or client roles 
of some client. Of course it's not a problem to plug more mappers, so 
it's not an issue to map for example LDAP roles from tree 
"ou=finance,dc=myorg,dc=org" to client roles of client "finance" and 
roles from tree "ou=development,dc=myorg,dc=org" to client roles of 
client "development" etc.

- Minor refactoring of some methods on UserFederationProvider interface. 
I needed to add RealmModel as parameter to some methods (it was already 
in most of them) because RealmModel will be used to retrieve list of 
configured UserFederationMapperModels .


Next planned steps:
- Model - I plan to add CRUD for UserFederationMapperModel to RealmModel 
(similarly like IdentityProviderMapperModel)

- Admin console - I've been thinking about new tab "Mappers" under "User 
Federation". The tab will be active when you have some Federation 
provider chosen and it will allow to add/update/remove mappers for 
particular provider. Again something very similar to already existing 
broker mappers. WDYT?

- Address remaining subtasks of 
https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be 
addressed by mappers. For example there is performance issue 
https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about 
adding some caching at LDAPIdentityStore level, but also I am thinking 
about some simple per-request caching at UserFederationManager level, 
which might help with federation performance in general (not just 
specific to LDAP). Maybe combination of both? But I am not sure atm...

- DB migration

Question: I wonder if we can put RealmModel accessible from 
UserFederationProviderModel? It shouldn't be a problem from 
implementation perspective as UserFederationProviderModel CRUD methods 
are on RealmModel, so realm can just inject itself before return 
UserFederationProviderModel. Since UserFederationProvider instances are 
created by method "getInstance" on UserFederationProviderFactory, which 
has UserFederationProviderModel as one of parameters, it will make 
RealmModel accessible in UserFederationProvider and hence it won't be 
needed to have RealmModel in signature of methods on UserFederationProvider.

WDYT?

Marek