We will deprecate LDAP/AD as security provider and remove it in 5.x

[derTobsch]

We want to reduce the complexity of the authentication/authorization in the Urlaubsverwaltung and only provide OpenId Connect (OIDC) as security provider.

To get a better feeling how many of you are using ldap, active directory or oidc please vote. So we know if we should provide migration guides for each security provider.

[systemofapwne]

Dropping LDAP or AD will introduce great inconveniences for the HR department: The automatic user sync would be gone and to my knowledge, apps that purely rely on OIDC (or SSO in general) are only aware about new users, once a user authenticates against the system the first time. Since an employee generally will not apply for holidays on his first day in office, he will not be added to the UV until he does apply for holidays. But HR department might want to edit his group association, eligible holidays and so on, before he applies for a leave.

If the decision about dropping LDAP or AD is final, there should be at least an API to fully manage users (create, edit, set (in)active, ...), so an external script can take care for this. At least I would like to not being required to mess around with the database directly.

[derTobsch]

Thanks for your Feedback!

[systemofapwne]

Are there already decisions or even implementations about how to enable user-syncs (e.g. via AD/LDAP) while relying purely on SSO for auth?

The reason why I ask is, that I am currently in the process to migrate several of our web-services to SSO and of course I quickly tested it against the current 4.x Version of the UV. While SSO auth works flawless, moving from "activedirectory" auth to "oidc" disables the sync feature, that we heavily rely on.

IMHO, leaving a rudimentary LDAP/AD backend just for sync might be most convenient for many of us. But that is some sort of against your decision to reduce code complexity by dropping LDAP/AD in the first place.

[zlex650]

is there any detailed migration documentation on how to migrate from LDAP (samAccountName) to e.g. Azure (UPN) Authentication without losing user mappings?

We have some users who authenticate only with the last name as samAccountName. in OIDC (Azure) it will be the UPN.
So presumably the users will be recreated?

[derTobsch]

The Urlaubsverwaltung does the match automatically via the E-Mail-Address. So when the user has the same address in azure ad it will use the same account.

[derTobsch]

and here is the link to the E-Mail-Address fallback https://github.com/urlaubsverwaltung/urlaubsverwaltung/blob/main/src/main/java/org/synyx/urlaubsverwaltung/security/oidc/OidcPersonAuthoritiesMapper.java#L57

[meik1337]

Hallo das klingt leider nicht so schön, da wir lediglich LDAP nutzen, könnt Ihr mit Tipps geben, wir man einen OIDC Provider aufbaut der LDAP als Quelle hat?
Danke,

[systemofapwne]

Hallo das klingt leider nicht so schön, da wir lediglich LDAP nutzen, könnt Ihr mit Tipps geben, wir man einen OIDC Provider aufbaut der LDAP als Quelle hat? Danke,

Eine Möglichkeit wäre hier z.B. über keycloak.

[bekanne]

Noch besser finde ich https://goauthentik.io/
Dort kann man ebenfalls einen LDAP-Outpost erstellen, für Anwendungen, die nur LDAP unterstützen (und da gibt es noch einige).

Leider habe ich es noch nicht hinbekommen die Urlaubsverwaltung an Authentik anzubinden.

[derTobsch]

Was hat denn nicht funktioniert? Kannst du ein paar Informationen teilen?

[bekanne]

Ich habe es doch noch hinbekommen.
Das sind meine Einstellungen in der docker-compose.yml:

SPRING_SECURITY_OAUTH2_RESOURCESERVER_JWT_ISSUER-URI: https://authentik.my-domain.de/application/o/urlaubsverwaltung/
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_CLIENT-ID: ********
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_CLIENT-SECRET: "**********"
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_PROVIDER: default
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_SCOPE: openid,profile,email,roles
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_AUTHORIZATION-GRANT-TYPE: authorization_code
SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_DEFAULT_REDIRECT-URI: https://urlaubsverwaltung.my-domain.de/login/oauth2/code/{registrationId}
SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_DEFAULT_ISSUER-URI: https://authentik.my-domain.de/application/o/urlaubsverwaltung/

Allerdings musste ich noch wegen dem Fehler "Can not retrieve the family name for oidc person mapping" in Authentik ein "Property Mapping" anlegen, damit auch family_name mitgegeben wird.

Property Mapping für den Scope "profile":

return {
    "family_name": "",
}

Das mapping muss dann noch im Provider für die Urlaubsverwaltung hinzugefügt werden.

Das ist eigentlich unnötiger Aufwand, weil family_name wie es scheint gar nicht verwendet wird?

[q16marvin]

Hey, vielen Dank! Dank dir hab ich es auch mit authentik hinbekommen :) ABER wenn ich auf logout gehe bekomme ich ein 403 weil er also parameter post_logout_redirect_uri=http://urlaub.my-domain.com mit gibt statt korrekter weise post_logout_redirect_uri=https://urlaub.my-domain.com. also warum auch immer http statt https. weisst du wo ich das fixen kann?

[astapelfeld]

What authentication methods will be available for the API?

[derTobsch]

oidc

[derTobsch]

Um es noch ein wenig zu konkretisieren. Wir haben die Authentifizierung mit einem JWT Bearer Token abgesichert. Dies wir mit der 5.0.0-M5 verfügbar sein.

[zinsmeik]

Dropping LDAP will affect our installation too. I would prefer that LDAP will be still available.

[derTobsch]

can you switch to oidc via keycloak e.g.?

[JPustkuchen]

FYI: We're using LDAP through a Synology NAS, which is quite convenient. Do other users use the same? Any alternatives there at the same level?

[systemofapwne]

If I'm not mistaken, Synology supports Docker by default. You could spin up a Keycloak container and use your LDAP as "User Federation" (User DB) for Keycloak. Keycloak then supplies the Identity Provider backend via OIDC for the UV.