Auto provisioned user created with "NULL" mail thus recreated as new user on each login

ksk0 commented 2 days ago

Problem

I have setup owncloud server a year ago. Authentication is done using OpenID Connect app/module, and users are auto provisioned. As OIDC server Microsoft Azure AD is used, for technical reasons, authentication is proxy-ed through keycloak server. owncloud server is dockerised version. Initial instalation was 10.13.2.3. Everything was working fine.

I have regulary upgraded owncloud as well as OpenID Connect app. Current owncloud version is 10.15.0.2, and OpenID Connect app version is 2.3.0 At certain point of time, new users have started to be auto provisioned, with email set to NULL value, thus each new login of a user, resulted with creation of a new account. User would be issued new user_id and email would be again set to NULL, thus preventing users to use owncloud server (files created in one session, would not be accessible in new session).

Problem persists even if i authenticate directly with Microsoft Azure AD bypassing keycloak server.

I don't know after which upgrade of owncloud or OpenID Connect this happened, i was informed of the problems by users only recently.

Thank you in advance for any help/suggestions. More details follow bellow.

Details

Short extract from mariaDB oc_accounts table looks as follows:

 id  email                     user_id                                     display_name         creation_time
 -------------------------------------------------------------------------------------------------------------------
 55  ok_user_01@my-domain.net  oidc-user-489c7480fbcd1260f2c75dedf5a53c18  Ok_user_01 Name      2024-06-12 11:57:01
 56  ok_user_02@my-domain.net  oidc-user-62008bc4e8074a91d9521ca2ef7af7f1  Ok_user_02 Name      2024-06-20 14:34:42
 57  ok_user_03@my-domain.net  oidc-user-3c565c3e7c0aa8b5ecd961b4926ea745  Ok_user_03 Name      2024-06-27 13:31:03
 58  NULL                      oidc-user-aXV1OOINJKEqGypp                  Bad_user_01 Name     2024-08-08 09:37:40
 59  NULL                      oidc-user-5mXqqjgZ7PuGBriC                  Bad_user_01 Name     2024-08-08 09:41:43
 60  NULL                      oidc-user-o8llzUNGMY8KgG9W                  Bad_user_01 Name     2024-08-08 10:43:32
 61  NULL                      oidc-user-Mgz0Rbs7PwEzvJ0p                  Bad_user_01 Name     2024-08-08 10:45:28
117  NULL                      oidc-user-EjaweCac1aIMtDwp                  Bad_user_02 Name     2024-10-14 14:24:51

As is visible _Bad_user_01_ was created 4 times. It is also visible, that problems started somewhere about end of june.

OpenID Connect php config is as follows:

{
  "redirect-url": "https://cloud.my-domain.net/apps/openidconnect/redirect",
  "provider-url": "https://keycloak.my-domain.net/realms/cloud",
  "client-id": "owncloud",
  "client-secret": "***REMOVED SENSITIVE VALUE***",
  "auto-provision": {
    "enabled": true,
    "email-claim": "email",
    "display-name-claim": "name",
    "groups": [
      "employees",
    ]
  },
  "loginButtonName": "User account",
  "autoRedirectOnLoginPage": false,
  "post_logout_redirect_uri": "https://cloud.my-domain.net/login",
  "mode": "email",
  "search-attribute": "email",
  "use-access-token-payload-for-user-info": true
}

If i modify OpenID Connect php config with:

"mode": "userid",

New entries in mariaDB oc_accounts table, would look like this:

 id  email                     user_id                   display_name         creation_time
 -------------------------------------------------------------------------------------------------
 55  ok_user_xx@my-domain.net  ok_user_xx@my-domain.net  Ok_user_xx Name      2024-10-14 20:23:07

i.e. user would be assigned an email in database, thus only one login is needed, but this way, existing users, are redefined, and can't access already uploaded files.

Comunication with OIDC seems to work fine. Manually testing OIDC authentication, shows that content of received token is as follows:

{
  "access_token": "*** ACCESS TOKEN ***",
  "expires_in": 300,
  "refresh_expires_in": 1800,
  "refresh_token": "*** REFRESH TOKEN ***",
  "token_type": "Bearer",
  "id_token": "*** ID TOKEN ***",
  "not-before-policy": 0,
  "session_state": "",
  "scope": "openid email profile"
}
{
  "exp": 1728905108,
  "iat": 1728904808,
  "auth_time": 1728904759,
  "jti": "*** JTI ***",
  "iss": "https://keycloak.my-domain.net/realms/cloud",
  "aud": "owncloud",
  "sub": "*** SUB ***",
  "typ": "ID",
  "azp": "owncloud",
  "nonce": "678910",
  "sid": "*** SID ***",
  "at_hash": "*** AT HASH ***",
  "acr": "1",
  "email_verified": false,
  "name": "Delboy Trotter",
  "preferred_username": "delboy.trotter@my-domain.net",
  "given_name": "Delboy",
  "family_name": "Trotter",
  "email": "delboy.trotter@my-domain.net"
}

Full config of docker container, done with docker compose is as follows:

volumes:
  clam-config:
    driver: local

services:
  owncloud:
    image: owncloud/server:10.15
    container_name: owncloud_server
    restart: always
    ports:
      - 127.0.0.1:8080
    depends_on:
      - mariadb
      - redis
    environment:
      - OWNCLOUD_DOMAIN=localhost:8080
      - OWNCLOUD_TRUSTED_DOMAINS=localhost,cloud.my-domain.net
      - OWNCLOUD_DB_TYPE=mysql
      - OWNCLOUD_DB_NAME=owncloud
      - OWNCLOUD_DB_USERNAME=owncloud
      - OWNCLOUD_DB_PASSWORD="***PASSWORD***"
      - OWNCLOUD_DB_HOST=mariadb
      - OWNCLOUD_MYSQL_UTF8MB4=true
      - OWNCLOUD_REDIS_ENABLED=true
      - OWNCLOUD_REDIS_HOST=redis
    healthcheck:
      test: ["CMD", "/usr/bin/healthcheck"]
      interval: 30s
      timeout: 10s
      retries: 5
    extra_hosts:
      - "host.docker.internal:host-gateway"
    volumes:
      - /mnt/data/oc-cloud:/mnt/data

  clamav:
    image: clamav/clamav:1.1_base
    container_name: owncloud_clamav
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "clamdcheck.sh"]
      interval: 30s
      timeout: 10s
      retries: 5
    ports:
      - 172.17.0.1:3310:3310
    volumes:
      - ./clamav/clamd.conf:/etc/clamav/clamd.conf
      - /mnt/data/oc-clamav:/var/lib/clamav

  mariadb:
    image: mariadb:10.11
    container_name: owncloud_mariadb
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD="***PASSWORD***"
      - MYSQL_USER=owncloud
      - MYSQL_PASSWORD="***PASSWORD***"
      - MYSQL_DATABASE=owncloud
      - MARIADB_AUTO_UPGRADE=1
    command: ["--max-allowed-packet=128M", "--innodb-log-file-size=64M"]
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-u", "root", "--password=***PASSWORD***"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - /mnt/data/oc-mysql:/var/lib/mysql

  redis:
    image: redis:6
    container_name: owncloud_redis
    restart: always
    command: ["--databases", "1"]
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - /mnt/data/oc-redis:/data

keycloak proxying

If of interest, the reason I am using keycloak between owncloud and Microsoft Azure AD, stems from the fact that i had problems with owcloud clients for desktop, Android and iOS. Microsoft Azure AD would reject authentication request, and after long battling with (some sort) of debugging, i found that in request sent to Microsoft Azure AD argument prompt had to be rewritten, to be accepted (I am not in any way master of OIDC, thus my problem and solution was the best i could do).

For that reason, i added keycloak server, which is containerized, and served by nginx web server which in turn, does request rewriting. For flexibility it offers, lua is used for the purpose of rewriting the arguments of request.

But, as i have said above, problem with new account with NULL email address, persists even if i authenticate directly with Microsoft Azure AD bypassing keycloak server.

Below is lua code in nginx configuration used for rewriting:

   # forward proxy for non-CONNECT request
   #
   location /{
      proxy_pass http://127.0.0.1:8080;

      # rewrite "prompt" argument for desktop, android
      # and iOS clients authentiaction (otherwise Azure
      # AD will reject request).
      #
      rewrite_by_lua_block {
        local clients = {
          ["xdXOt13JKxym1B1QcEncf2XDkLAexMBFwiT9j6EfhhHFJhs2KM9jbjTmf8JBXE69"] = true,
          ["e4rAsNUSIUs0lF4nbv9FmCeUkTlV9GdgTLDH1b5uie7syb90SzEVrbN7HIpmWJeD"] = true,
          ["mxd5OQDk6es5LzOzRvidJNfXLUZS2oN3oUFeXPP8LpPrhx3UroJFduGEYIBOxkY1"] = true,
        }

        if (ngx.var.arg_client_id and ngx.var.arg_prompt) then
          if (clients[ngx.var.arg_client_id]) then
            local args = ngx.req.get_uri_args()
            args.prompt= "select_account"

            ngx.req.set_uri_args(args)
          end
        end

      }
   }

   location = /realms/cloud/protocol/openid-connect/logout {
      proxy_pass http://127.0.0.1:8080;

      # add "client_id" argument to facilitate succesfule
      # logout.
      #
      rewrite_by_lua_block {
        local args = ngx.req.get_uri_args()
    args.client_id = "owncloud"

        ngx.req.set_uri_args(args)
      }
   }

RubenGarcia2081 commented 9 hours ago

Hey @ksk0 , thank you for your input. I have noticed the very same issue on my end. Quite similar setup, Azure AD as OIDC server and auto provision, but without a keycloak server in between.

The issue with the blank email field and the recreation of exisitung users started to show when I upgraded my owncloud instance from 10.13.3 directly to 10.5.0, OpenID Connect simultaneously upgraded from 2.2.0 to 2.3.0

A possible workaround as you mentioned could be to change the mode from email to userid, but this doesn't help already provisioned users. For now I have restored a backup with owncloud version 10.13.3 but this isn't exactly a solution as that version is a year old.

Can anyone replicate that issue too?

DeepDiver1975 commented 8 hours ago

This change is most probably causing your trouble: https://github.com/owncloud/openidconnect/pull/282/files#diff-018c95ee4f1caae96378b051d301d4bf0967c1f673322950a0d92661cd9bdc3dR166

owncloud / openidconnect