How to synchronize Alfresco users with KeyCloak? (share, not APS)

[3kwagner]

Hello,

I am using Alfresco 6.1 with share in docker containers and want to manage users in KeyCloak only. I already managed to get the possibility of creating users in KeyCloak in loggin in with These credentials in share. Here is my docker-compose.yml:

version: "3.7"

services:
    alfresco:
        image: alfresco/alfresco-content-repository-community:6.1.2-ga
        environment:
            JAVA_OPTS : "
                -Ddb.driver=org.postgresql.Driver
                -Ddb.username=alfresco
                -Ddb.password=alfresco
                -Ddb.url=jdbcostgresql://postgres:5432/alfresco
                -Dsolr.host=solr6
                -Dsolr.port=8983
                -Dsolr.secureComms=none
                -Dsolr.base.url=/solr
                -Dindex.subsystem.name=solr6
                -Dshare.host=localhost
                -Dalfresco.port=8082
                -Daos.baseUrlOverwrite=http://localhost:8082/alfresco/aos
                -Dmessaging.broker.url=\"failovernio://activemq:61616)?timeout=3000&jms.useCompression=true\"
                -Ddeployment.method=DOCKER_COMPOSE
                -Dcsrf.filter.enabled=false
                -Xms1g -Xmx1g
                -Dauthentication.chain=identity-service1:identity-service,alfrescoNtlm1:alfrescoNtlm
                -Didentity-service.enable-basic-auth=true
                -Didentity-service.authentication.validation.failure.silent=false
                -Didentity-service.auth-server-url=https://mydomainforkeycloak/auth
                -Didentity-service.realm=alfresco
                -Didentity-service.resource=activiti
                -Didentity-service.public-client=true
                -Didentity-service.ssl-required=none
                "
        ports:
            - 8080 #Browser port
        restart: always

    share:
        image: alfresco/alfresco-share:6.1.0
        environment:
            - REPO_HOST=alfresco
            - REPO_PORT=8080
            - "CATALINA_OPTS= -Xms500m -Xmx500m"
        ports:
            - 8080
        restart: always
        links:
           - "alfresco:alfresco"

After Login a new user will be created in Alfresco, but only with ist username. No email or other Information ist beeing synchronized. Furthermore, when I delete a user in KeyCloak it will be still existent in Alfresco.

How can I configure Alfresco to do a full sync with KeyCloak? Thank you!

[heiko_robert · Accepted solution]

Interesting. There seems to be no documentation about and I'm afraid there isn't anything like that yet and you have to use the ldap sync, wire that up with keycloak. It looks like with Alfresco 7 and up we need 26 containers and 12 admins to cover all the required components and knowledge to maintain that ...

If I remembr right Alfresco isn't sure to keep users/groups/permission in Alfresco.

[afaust]

Heiko is right - there is no sync (yet) with Keycloak, and going forward, Alfresco may add something in their Alfresco Identity Service component to deal with this, albeit in a potentially non-Keycloak-standard kind of way. I have recently set up a 6.0 system with Keycloak to integrate an Azure Domain Services directory, and this included configuring identity-service subsystem for auth, and ldap-ad subsystem for synchronization (Keycloak itself was synching users via LDAP from Azure).

Also, Share currently does not specifically support Keycloak and SSO via OpenID Connect. Alfresco has publicly stated during the last DevCon that they are interested in adding this, and I have also been in contact with a product manager about this, but so far, nothing has materialised apart from some internal mails like "hey, Axel is interested in working with us on this, please keep him informed" (without any actual follow up / synch up).

I am considering using the existing identity-service subsystem implementation to create a minor fork as a "keycloak" subsystem which would include user/group synch using the Keycloak Rest API, since my client is considering future deployment scenarios where we might not actually have an LDAP-enabled central directory.