5:33 p.m.
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/j...
. 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