Gitlabintegration in UCS

UCS - Univention Corporate Server
, ,
1

Nachdem GitLAB schon länger nicht mehr im UCS-Appcenter verfügbar ist, hab ich ein kleines HowTo verfasst, dass dieselbe Integration mit einem manuell installierten GitLAB in UCS beschreibt.

Zum HowTo gehts hier.

2 Likes
2

Gutes Howto, aber ich würde Dienste nach Möglichkeit nicht mehr über LDAP sondern über OpenID / SAML anbinden. Dann gibt man Anwendungen nämlich nicht Zugriff auf die Paßwörter.

3

Bin ich voll bei dir. Keycloak ist Mega :slight_smile: Geht das leicht in der Community Version von Gitlab auch schon? Kann mich erinnern das dies immer nur ein Feature von der Enterprise Edition war. Aber sieht so aus als gäbe es das nun auch für die Community Variante.

4

Ja das ist in der kostenlosen Variante verfügbar.

1 Like
5

Wirklich gutes HowTo! Mir gefällt gerade daran das es ein “Simple LDAP” Howto ist.

Anmerkungen:

  • Der Hinweis von @SirTux mit “OpenID / SAML anbinden” ist schon sehr gut, würde ich heutzutage tendenziell auch so machen. Ich sehe die Anbindung via Keycloak jedoch ehe als eine Variante. @boospy was vielleicht noch gemacht werden könnte ist klar zu stellen das es hier speziell um LDAP geht und einen Link zu keycloak zu setzen, das entsprechende howto gibt es ja schon.

  • Ich sehe manuell gepflegte LDAP-Schema Erweiterungen als etwas was ich wenn möglich gerne vermeide, wenn es denn Alternativen gibt. Vor allem wenn die Erweiterungen nicht (mehr) durch UCS maintained werden. Eine Variante die ich persönlich bevorzuge bei jeglicher LDAP Eigenbau-Integration ist die Benutzung von memberOf - und dann entsprechende Gruppen anzulegen und die Benutzer gemäß Ihrer Rolle hinzuzufügen. Vorteil davon ist das RBAC über Gruppen abgebildet werden kann, also eine spätere Migration zo Keycloak, “OIDC for RBAC” und auch ein policy enforcement deutlich einfacher wird. Die user_filter sind dabei weiterhin möglich, und lassen sich auch auf mehrere Gruppen (Abteilungen) ausweiten.

Also anstelle LDAP-Schema Erweiterungen und Filter:

(&(univentionObjectType=users/user)(gitlabActivated=TRUE))

Würde bei Benutzung von memberOf wie folgt aussehen:

(|(memberOf=cn=gitlab_users,cn=groups,dc=tux2,dc=lan)(memberOf=cn=Abteilung_2,cn=groups,dc=tux2,dc=lan)(memberOf=cn=Gruppe_3,cn=groups,dc=tux2,dc=lan))

Wie gesagt, alle Anmerkungen sind alles nur Varianten. Welche davon jetzt besser ist, hängt sehr stark von den persönlichen Vorlieben und den Umständen ab. Danke für die Zeit und Mühe die ganze Doku zu schreiben, zu testen, und zu pflegen!

2 Likes
6

Danke für eure Antworten. Ich hab die Infos auch gleich ins HowTo eingebaut. Macht absolut Sinn :slight_smile: .

7

Ja das würde ich auch unterschreiben. Ich finde es auch nicht gut, daß die Apps so sorglos mit Schema-Erweiterungen umgehen, nicht selten nur für einen simplen Anmeldefilter. Dabei wird man dieses später kaum wieder los selbst wenn die App schon lange entfernt wurde.

8

Ich hab da einige Leichen im Keller wo ich damals mit UCS begonnen habe. Leider wusste ich es damals noch nicht besser. Die Schemas kann man mit einem gewissen Aufwand wohl loswerden. Habs aber noch nicht versucht. Aber wenn sie nicht benutzt werden, sollte das ja keine Probleme machen, denk ich.

Auf jeden Fall sollte man sie nicht einfach mal so löschen :wink: .

9

Ich habs schonmal probiert. Faktisch mußt dann immer noch der Fortsetzung folgen:

Der Aufwand rechtfertig es echt nicht für jeden Quatsch eine Schema-Erweiterung reinzuhauen.