[keycloak-dev] Connecting to an external database for a ProtocolMapper

[Marc Guillemot]

Hi Thomas,

funny, I've implemented something really similar for my client as a poc
for a few days. I can't say whether it is the best way to do it but I've
found that a LDAPStorageMapper [1] was better suited than a
ProtocolMapper. A EAR allows you to package the needed libraries.

Cheers
Marc

[1]
https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main/resources/META-INF/services/org.keycloak.storage.ldap.mappers.LDAPStorageMapperFactory

Le 31/08/2019 ?? 00:22, Thomas a ??crit??:
> I need help finding the correct direction of creating a ProtocolMapper that
> reads from an external database.
> 
> We currently have a Spring microservice application that uses Spring OAuth2
> secured services with a Spring OAuth2 server that adds claims to the access
> token to implement extra claims for security.  The application also reads
> the extra claims from the user service database.  This database doesn't
> store user authentication credentials. User authentication data is in an
> enterprise LDAP/AD that is read only.  I will never be able to change the
> read only LDAP.  We would like to get rid of the Spring OAuth2 server.
> 
> So far, I've been able to import users into Keycloak from the LDAP and get
> every microservice to respond correctly to a request from a valid token
> from Keycloak once a login has happened.  I've also been able to get a
> ProtocolMapper running that adds hard coded claims to the user's access
> token.
> 
> I would like to use a few custom Spring libraries that we have created for
> other services to read data from the User Service Database.  The libraries
> all ready have implemented a ReadOnly Repository that has custom SQL
> types.  Particularly,  arrays of strings and ints.  As well as the Domain
> model.
> 
> Should I create an EAR that includes the ProtocolMapper as a jar module?
> What is the correct way to structure the EAR?  Will using my other
> libraries that use Spring work?
> 
> Thanks,
> Thomas