Hello,
I actually got OCIS to work with Authentik as my IDP and my OIDC provider on my Kubernetes cluster a few days ago. It is possible but it requires some tweaks both on the Authentik- and OCIS-side.
First of all, Authentik is an Identity Provider with LDAP capabilities. So, it comes with a few limitations:
- Adding a custom LDAP schema is not possible. So, having custom ObjectClass is out of the question. But you can customize the LDAP responses from Authentik using LDAP specific property mapping.
- Groups in Authentik donât have mail addresses. Hence, the
mail attribute in the LDAP response will be empty. However that attribute can be customized as well. I havenât tested that but according to the Authentik docs, that attribute can overwritten.
- Changes through LDAP is not supported. Any modification, like a password reset, must be done directly through Authentik. Again, I havenât tested this but the Authentik docs donât mention it and I didnât look further into it because, in my setup, I want everything related to accounts to be managed by Authentik. So, my OCIS setup assumes the used IDP is read-only.
- GDPR reports are not implemented for Authentik.
To begin, youâll need to create an LDAP provider in Authentik. For that, the instructions in the Authentik docs did the job for me. To use LDAPS, take in account that the LDAP communication happens through an LDAP Outpost created by Authentik. On Kubernetes, LDAP queries must be sent to a dedicated pod, created by Authentik, named ak-outpost-ldap. If OCIS and Authentik run on the same cluster, your certificate should at least have ak-outpost-ldap.<authentik-namespace>.svc.<cluster-domain> listed as SAN.
Next, letâs make sure that any required custom attribute is returned in the LDAP response. In my setup, these are ownCloudUserType and ownCloudUserEnabled. It can be hard-coded for each user through the attribute section or LDAP.
Finally, I created four groups: OwnCloud Admins, OwnCloud Space Admins, OwnCloud Users and OwnCloud Guests. I used these groups for role provisioning but Iâll go later into that.
Eventually, youâll want your LDAPsearch query response to look as follow:
Summary
~/$ ldapsearch -xLLL -H ldaps:// -D âcn=nathan,ou=users,DC=ldap,DC=goauthentik,DC=ioâ -W -b âou=users,DC=ldap,DC=goauthentik,DC=ioâ â(&(objectclass=user)(memberOf=cn=owncloud*))â
Enter LDAP Password:
dn: cn=nathan,ou=users,dc=ldap,dc=goauthentik,dc=io
ownCloudUserType: Member
ownCloudUserEnabled: true
ak-active: TRUE
sAMAccountName: nathan
mail:
uidNumber: 2005
createTimestamp: 20250708080458Z
name: Nathan
gidNumber: 2005
homeDirectory: /home/nathan
sn: Nathan
pwdChangedTime: 20250708080506Z
modifyTimestamp: 20251005170627Z
ak-superuser: TRUE
uid:
memberOf: cn=OwnCloud Admins,ou=groups,dc=ldap,dc=goauthentik,dc=io
cn: nathan
displayName: Nathan
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: user
objectClass: posixAccount
objectClass: goauthentik io ldap user
That LDAP response brings me to the next thing to do: mapping the schema to OCIS. For this, here is an excerpt of my Helm file:
Summary
features:
externalUserManagement:
enabled: true
ldap:
bindDN: cn=ldap-authenticator,ou=users,dc=ldap,dc=goauthentik,dc=io
disableUsers:
disableMechanism: none
disabledUsersGroupDN: cn=DisabledUsersGroup,ou=groups,dc=ldap,dc=goauthentik,dc=io
userEnabledAttribute: ownCloudUserEnabled
group:
baseDN: ou=groups,dc=ldap,dc=goauthentik,dc=io
filter: (&(objectclass=group)(memberOf=cn=owncloud*))
objectClass: groupOfNames
schema:
displayName: displayName
groupName: cn
id: uid
mail: mail
member: member
insecure: false
uri: ldaps://ak-outpost-ldap.authentik.svc.k8s.internal.atclios.com:636
user:
baseDN: ou=users,dc=ldap,dc=goauthentik,dc=io
filter: (&(objectclass=user)(memberOf=cn=owncloud*))
objectClass: inetOrgPerson
schema:
displayName: displayName
id: uid
mail: mail
userName: cn
userType: ownCloudUserType
writeable: false
A few things to note from that excerpt:
- The default base domain is dc=ldap,dc=goauthentik,dc=io but this can be changed in the LDAP provider settings.
- I changed the filter so that only users and groups who are members of the four OwnCloud groups I created earlier are listed. That way, I can control who get an OCIS account and who doesnât from directly Authentik.
- The disableMechanism is still set to none because I havenât figured out which one of the two mechanism I want to use (Still, if you are going for the Group mechanism, make sure that the corresponding group exists as well).
- The Graph is configured to view to the LDAP server as read-only.
Now, weâve come the OIDC. If you are familiar with the Helm value file, youâll have noticed that no adminUUID value is set. This is because I rely on an OIDC claim to define the roles in OCIS. As stated earlier, I created four groups in Authentik. To define which role will be assigned according to the users group membership, I created a new property mapping of type Scope Mapping that I called owncloud_usage in Authentik. For that entry, I used the following expression:
Summary
if ak_is_group_member(request.user, name=âOwnCloud Adminsâ):
return {
âocis_roleâ: âocisAdminâ
}
elif ak_is_group_member(request.user, name=âOwnCloud Space Adminsâ):
return {
âocis_roleâ: âocisSpaceAdminâ
}
elif ak_is_group_member(request.user, name=âOwnCloud Usersâ):
return {
âocis_roleâ: âocisUserâ
}
elif ak_is_group_member(request.user, name=âOwnCloud Guestsâ):
return {
âocis_roleâ: âocisGuestâ
}
return None
This allowed me to perform the role provisioning through OIDC using the following settings in Helm:
Summary
features:
oidc:
accessTokenVerifyMethod: jwt
issuerURI:
roleAssignment:
claim: ocis_role
enabled: true
mapping:
* claim_value: ocisAdmin
role_name: admin
* claim_value: ocisSpaceAdmin
role_name: spaceadmin
* claim_value: ocisUser
role_name: user
* claim_value: ocisGuest
role_name: guest
userIDClaim: sub
userIDClaimAttributeMapping: userid
At that point, youâll want to create the OwnCloud Application along with the OIDC provider in Authentik. The authentik: Configure OpenID Connect IdP section from Helge Kleinâs blogpost did Make sure to select Public client type and to add the owncloud_usage scope as Selected Scopes. Depending on the Subject Mode youâve chosen in Authentik, youâll need to change the userIDClaim and the userIDClaimAttributeMapping values. If you use the same values as I document here, you should be fine.
Here is an example of the JWT youâll get from Authentik:
Summary
{
âissâ: ââ,
âsubâ: ââ,
âaudâ: ââ,
âexpâ: 1761401541,
âiatâ: 1761399741,
âauth_timeâ: 1761399741,
âacrâ: âgoauthentik io/providers/oauth2/defaultâ,
âemailâ: ââ,
âemail_verifiedâ: true,
âocis_roleâ: âocisAdminâ,
ânameâ: âNathanâ,
âgiven_nameâ: âNathanâ,
âpreferred_usernameâ: ânathanâ,
ânicknameâ: ânathanâ,
âgroupsâ: [
âOwnCloud Adminsâ
]
}
The very last component to configure is the Web service. Here are the values I used in Helm:
Summary
services:
web:
config:
oidc:
webClientID:
webClientScope: openid profile email offline_access owncloud_usage
To ensure that the ocis_role attribute is included in the OIDC token, I added owncloud_usage as an additional webClientScope.
The Helm values file still needed additional CORS and CSP values to be added. But atfer that, all that must to be done was to install the Helm charts using these values. And that is how I go OCIS to work with Authentik on Kubernetes. I leave it to you at to how to translate all of this into Docker Compose. In general, Iâm sure there are a few thing that needs some polishing. But kudos to the OwnCloud team! Without their work and their documentation, I wouldnât have gone for so far!
Now, for your remaining two questions: Authentik has the capability to connect to an external user directory such as an LDAP-based IDP. With that in mind, what Iâm gonna say is all speculation:
- It should be possible to map the LDAP attributes from the IDP service to Authentik through LDAP Source Property Mapping. That opens up the possibilty for Authentik to use the IDP service as an LDAP source and to get into a scenario where Authentik can take care to Authentication and where OCIS accounts can be managed through OCIS.
- Authentik should be able to connect multiple sources to one LDAP provider⌠If true, it should be possible to get Authentik to authenticate an user that is registered in either the IDP service or in its own database (or another IDP). That could pave the way for a migration path.
