In the logs of Authelia, I can see the request for authentication, and I believe its sucessful:
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:58+02:00" level=debug msg="Authorization Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' is being processed" method=GET path=/api/oidc/authorization remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:58+02:00" level=debug msg="Authorization Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' was successfully processed, proceeding to build Authorization Response" method=GET path=/api/oidc/authorization remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:58+02:00" level=trace msg="Authorization Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' creating session for Authorization Response for subject '7fb390be-962c-4c9e-9763-929b6cf1be7e' with username 'myuser' with claims: &{JTI: Issuer:https://authelia.mydomain.com Subject:7fb390be-962c-4c9e-9763-929b6cf1be7e Audience:[ocis] Nonce: ExpiresAt:0001-01-01 00:00:00 +0000 UTC IssuedAt:2023-06-23 16:33:58.194999747 +0200 CEST m=+65.511327822 RequestedAt:2023-06-23 14:33:56.207546906 +0000 UTC AuthTime:2023-06-23 16:33:55 +0200 CEST AccessTokenHash: AuthenticationContextClassReference: AuthenticationMethodsReferences:[pwd] CodeHash: Extra:map[azp:ocis client_id:ocis email:myemail@gmail.com email_verified:true name:My Name preferred_username:myuser]}" method=GET path=/api/oidc/authorization remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:58+02:00" level=trace msg="Replied (status=303)" method=GET path=/api/oidc/authorization remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=trace msg="Request hit" method=GET path=/.well-known/openid-configuration remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=trace msg="Replied (status=200)" method=GET path=/.well-known/openid-configuration remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=trace msg="Request hit" method=POST path=/api/oidc/token remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=debug msg="Access Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' is being processed" method=POST path=/api/oidc/token remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=trace msg="Access Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' response is being generated for session with type '*model.OpenIDSession'" method=POST path=/api/oidc/token remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=debug msg="Access Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' has successfully been processed" method=POST path=/api/oidc/token remote_ip=192.168.0.1
authelia_server.1.6kmn4jfxt0e6@wyse1 | time="2023-06-23T16:33:59+02:00" level=trace msg="Access Request with id '2024b675-5f82-467d-a6f0-1153a048a392' on client with id 'ocis' produced the following claims: map[access_token:authelia_at_9luwIltVkaKqA7F5nlKTQZcN_cAUmdEFayV7BRGffJY.4TWGwpGmwje4SBpLRQLkf3zw7d6799B1Bcx1vPmgtIc expires_in:3600 id_token:eyJhbGciOiJSUzI1NiIsImtpZCI6ImM4NTgzMyIsInR5cCI6IkpXVCJ9.eyJhbXIiOlsicHdkIl0sImF0X2hhc2giOiJnR0VaNHJuSWx2ZW85N0x6Ulo3dVFRIiwiYXVkIjpbIm9jaXMiXSwiYXV0aF90aW1lIjoxNjg3NTMwODM1LCJhenAiOiJvY2lzIiwiY2xpZW50X2lkIjoib2NpcyIsImVtYWlsIjoiYmVyZWN6a2ltOEBnbWFpbC5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiZXhwIjoxNjg3NTM0NDM5LCJpYXQiOjE2ODc1MzA4MzksImlzcyI6Imh0dHBzOi8vcG9ydGFzLjNkb3JhLmV1IiwianRpIjoiNmZmN2ZjNWUtYTBmZS00YWNjLWE0NGMtZDcyOWY1ODljZDczIiwibmFtZSI6IkJlcmVjemtpIE1paMOhbHkiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJtcW1xMCIsInJhdCI6MTY4NzUzMDgzNiwic3ViIjoiN2ZiMzkwYmUtOTYyYy00YzllLTk3NjMtOTI5YjZjZjFiZTdlIn0.GTPcCLAonjEczTut9EA5OOWmgZTj7kmGlHZJaXZhJfLo4nTiPUZWazSz7DzpBVx0O0ZZRHiJCR7ikP9cF6jRWyY7RnSCPvTdv7umor-qdpqn3T1urvBoVy6snKLB-wVieksrsj_nPQkcG_V8QDyudFvjaBmH8--l4ZvV7vWaBcMvuPjTjurXg4i9nmABH2c9xD4F5y0ab3fSRWeGkfG5j0OOVehdVdcuyBw0X-mqyYJ3EyvLUoODHhTG5DUaDiaYkfN2lVTsR7vkLC8rpFJOnpTrBGWejrkJb1etlJ1Rt821LOJBRi_fixGlVOJ0TZTdoFseU6MxcKY4Mu0BtZVc4g scope:openid profile email token_type:bearer]" method=POST path=/api/oidc/token remote_ip=192.168.0.1
version: "3.7"
services:
ocis:
container_name: "ocis_owncloud"
image: owncloud/ocis:${OCIS_DOCKER_TAG:-latest}
ports:
- 9300:9200
networks:
- proxy
entrypoint:
- /bin/sh
# run ocis init to initialize a configuration file with random secrets
# it will fail on subsequent runs, because the config file already exists
# therefore we ignore the error and then start the ocis server
command: ["-c", "ocis init || true; ocis server"]
environment:
OCIS_OIDC_ISSUER: "https://auth.<mydomain.tld>"
PROXY_OIDC_ISSUER: "https://auth.<mydomain.tld>"
PROXY_OIDC_INSECURE: "false"
PROXY_USER_OIDC_CLAIM: "preferred_username"
WEB_OIDC_SCOPE: "openid profile email groups"
WEB_OIDC_CLIENT_ID: "cloud.<mydomain.tld>"
PROXY_OIDC_REWRITE_WELLKNOWN: "true"
WEB_OIDC_METADATA_URL: "https://auth.<mydomain.tld>"
WEB_OIDC_AUTHORITY: "https://auth.<mydomain.tld>"
OCIS_OIDC_CLIENT_ID: "cloud.<mydomain.tld>"
# Without this, I got the following errors in the ownCloud log:
# Authentik: failed to verify access token: the JWT has an invalid kid: could not find kid in JWT header
# Authelia: failed to verify access token: token contains an invalid number of segments
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD: none
# general config
DEMO_USERS: "false"
OCIS_URL: "https://cloud.<mydomain.tld>"
PROXY_HTTP_ADDR: "0.0.0.0:9200" # listen on all available interfaces
OCIS_LOG_LEVEL: ${OCIS_LOG_LEVEL:-info}
OCIS_LOG_COLOR: "${OCIS_LOG_COLOR:-false}"
PROXY_TLS: "false" # do not use SSL between Traefik and oCIS
PROXY_AUTOPROVISION_ACCOUNTS: "true"
PROXY_USER_CS3_CLAIM: "username"
# INSECURE: needed if oCIS / Traefik is using self-generated certificates
OCIS_INSECURE: "false"
OCIS_ADMIN_USER_ID: "<MyUserName>"
SETTINGS_ADMIN_USER_ID: "<MyUserName>"
IDM_ADMIN_USER_ID: "<MyUserName>"
OCIS_EXCLUDE_RUN_SERVICES: "idp"
GRAPH_ASSIGN_DEFAULT_USER_ROLE: "false"
GRAPH_USERNAME_MATCH: "none"
# Storage
STORAGE_OIDC_ISSUER: https://auth.<mydomain.tld>
volumes:
- /owncloud/ocis/ocis-config:/etc/ocis
- /mnt/nas/owncloud/ocis-data:/var/lib/ocis
logging:
driver: ${LOG_DRIVER:-local}
restart: always
networks:
proxy:
external:
name: proxy
On authelia the config section for OCIS looks like this:
For the admin rigths I manage to remove Authelia, then connect with the admin using the default authentification method, and change the admin email with my Authelia user email.
And unfortunately for the logout it is an issue between Authelia and OCIS.
i would actually love a guide on how to get authelia working with OCIS properly. Right now it is unusable for me because logout is not working and i do not have admin rights.
Okay, so, Authelia doesn’t work with OCIS because Authelia doesn’t support the RP-initiated logout extension to OIDC yet hxxps://www.authelia.com/roadmap/active/openid-connect/
Authelia does have a nonstandard logout endpoint, which could optionally be called with a redirect parameter (but, in my experience, the redirect doesn’t actually work): hxxps://authelia.example.com/logout?rd=hxxps://owncloud.example.com
So… as a stopgap measure, would it be possible to specify a nonstandard logout endpoint for OCIS to call (or redirect the user to) after logging out? This would support the use of Authelia as it is today (barring other issues), as well as other IdP’s that only implement the core specification.
Hello the Team,
I have a proxmox server with containers Authelia / OCIS / Portainer / Jellyfin …
I don’t use proxy because I use Cloudflare Tunnels.
If i don’t use Authelia, OCIS work perfect via web - Desktop sync and IOS.
When I use authelia, juste web acces is ok, I can’t connect Ocis Desktop client and IOS.
If you can help me, I will appreciated.
Thanks Fred
Got it working somewhat with Authelia, though only with PROXY_ROLE_ASSIGNMENT_DRIVER: default
but then my role would be user.
if i set it to PROXY_ROLE_ASSIGNMENT_DRIVER: oidc i cannot login and get **ERR** Error mapping role names to role ids error="no roles in user claims"
in the logs.
I am not sure how to claim a certain role, i guess this has to be done in authelia’s config? But i am not sure how.
Hi, been bashing my head against this wall for a few days now
I believe that this is down to authelia not sending or ocis not receiving the groups scope/claim
On the OCIS side, my .well-known/openid-configuration says it supports groups in both scopes_supported and claims_supported
Authelia side, I’ve set the scopes to openid, groups, profile, email and offline_access
OCIS debug shows me that it’s only recieved openid, profile and email claims
OCIS needs to look up a user in the backend with one of the claims given in the userinfo / access token.
PROXY_USER_OIDC_CLAIM=preferred_username configures which claim to read from oidc, here the preferred_username.
PROXY_USER_CS3_CLAIM=username configures which user property to use.
You could also use PROXY_USER_OIDC_CLAIM=email and PROXY_USER_CS3_CLAIM=mail
Since Authelia has no LDAP api ocis has to maintain its own userdatabase and create accounts on the fly with PROXY_AUTOPROVISION_ACCOUNTS=true.
After logging in once you can use the generated UUID of that user to set OCIS_ADMIN_USER_ID to make him an admin account. If you want to manage the roles from authelia you have to configure it to send a claim to ocis and then look into the PROXY_ROLE_ASSIGNMENT_DRIVER env var.
I double checked the auth code. We really log all claims that are minted in the token. If you take the JWT from the browser and decode it manually you should find the same claims (if authelia sends a JWT and not a opaque access token). In any case, we can’t map what isn’t there. I do wonder why your JWT contains the aud twice but has no exp. That smells fishy. Technically, oCIS will accept the token but as you said: the groups claim is missing.
Your authelia config does not use the correct id and secret for the desktop, android and iOS clients. You neet to use the default ones as in IDP Service Configuration unless you compile your own clients. Only the ocis web client id can be configured, as oCIS serves it itself.
Can you login in the web ui?
hm
oCIS web only requests openid profile email scopes by default. You can tell oCIS web to also request groups by setting WEB_OIDC_SCOPE="openid profile email groups". But the desktop and mobile clients don’t do that. In Keycloak you can configure to always senda certain claim. In any case using oCIS web to log in will case the users to get the correct role based on the groups claim.
TYSM! WEB_OIDC_SCOPE="openid profile email groups" solved it for me
I will set the clients correctly now, thanks
I’d just been testing with web for now, I hadn’t even looked at the other clients yet
