ldap
LDAP slaat personen, groepen en rollen op volgens een zelfde stramien. Het is altijd een reeks van attributen met waarden, de volgorde is relevant. Elk attribuut heeft een betekenis. LDAP kent er hier heel veel van, maar de volgende zijn het belangrijkst.
- cn staat voor common name
- ou staat voor organisational unit ofwel afdeling
- dc staat voor domain component ofwel een definitie van het hoogste niveau
- o staat voor organisatie
- uid staat voor unieke identificatie
- sn staat voor achternaam
- memberOf staat voor een rol/groep waar iemand lid van is
- uniqueMember staat voor een persoon welke lid is van rol/groep
Om een persoon, groep of rol (record) precies te identificeren binnen een LDAP hiërarchie wordt distinguished name (DN) gebruikt. Deze heeft bv de volgende vorm: cn=jaap,ou=medewerkers,dc=b3p,dc=nl Dit is Jaap die een medewerker is van een bedrijf dat b3p heet in Nederland. De hier gebruikte attributen zijn de meest gebruikte om een persoon, groep of rol te definiëren, maar in principe kan elk willekeurige reeks gebruikt worden zolang het uiteindelijk verwijst naar een uniek record. Je zou Jaap dus ook kunnen vinden door: uid=9001,ou=medewerkers,dc=b3p,dc=nl
Er zijn allerlei regels mbt de attributen, maar dat voert hier te ver. Attributen kunnen meerdere keren voorkomen in één record.
Het record dat Jaap definieert kan er als volgt uitzien:
- cn: jaap
- uid: 9001
- ou: medewerkers
- dc: b3p
- dc: nl
- emailNickname: jaap@domain.com
- memberOf: beheerder
Via LDAP kunnen ook rollen gedefinieerd worden. Feitelijk is dit ook een record en kan er als volgt uitzien:
- cn: beheerder
- ou: rollen
- dc: b3p
- dc: nl
- uniqueMember: cn=jaap,ou=medewerkers,dc=b3p,dc=nl
- uniqueMember: cn=kees,ou=medewerkers,dc=b3p,dc=nl
De DN van deze rol is dan cn=beheerder,ou=rollen,dc=b3p,dc=nl en Jaap en Kees hebben die rol.
Tot slot kunnen ook groepen gebruikt worden, bv: ou=medewerkers, dc=b3p,dc=nl Soms kan/moet aangegeven worden dat alleen binnen een bepaalde groep gezocht moet worden. Dan kan dus de DN van zo’n groep gebruikt worden.
Via de context van een tomcat applicatie kan ingeregeld worden hoe bij inloggen opgezocht moet worden of de gebruiker het juiste wachtwoord invuld en welke rollen bij zijn inlog horen. Het volgende xml-blok moet worden toegevoegd:
Eerst gaat de gebruiker zich authenticeren. Dit wil zeggen zijn gebruikersnaam en wachtwoord invullen om te bewijzen dat hij is wie hij zegt dat hij is. Daarvoor zijn de volgende regels van de context van belang. [A] geeft aan waar de LDAP server staat en hoe ingelogd moet worden. Onder connectionName moet de echte DN worden ingevuld van iemand die de LDAP mag bevragen. Dit kan het beste een (speciale) gebruiker zijn die niet elke maand zijn wachtwoord hoeft te veranderen. Als inloggen niet nodig is dan kunnen connectionName en connectionPassword weggelaten worden.
[B] geeft aan hoe medewerkers gevonden moeten worden in de LDAP. Userbase geeft aan in welk deel van de hiërarchie gezocht moet worden. userSubtree geeft aan dat ook nog diepere niveaus moeten worden doorzocht. Het kan zijn dat er nog subgroepen (ou) bestaan van de medewerkers, bv per afdeling. True betekent subgroepen ook doorzoeken.
UserSearch heeft aan wat de gebruiker moet intypen bij gebruikersnaam in het inlogscherm. In het voorbeeld staat emailNickname. Dit betekent dat in het record van de gebruiker een attribuut staat met die naam (wel controleren, want dit is per LDAP anders). We gaan er van uit dat als het attribuut bestaat hier het emailadres van de gebruiker is ingevuld. De gebruiker moet dan met zijn emailadres inloggen. Als hier ipv emailNickname cn had gestaan dan moet Jaap niet met jaap@domain.com inloggen maar met jaap, zijn common name. Op deze manier wordt een gebruiker geauthenticeerd.
Let op: als inloggen met de verkeerde gebruikersnaam en wachtwoord resulteert in een NullPointerException in JNDIRealm.getUser, kan het beste de Tomcat versie geupdatet worden; dit is een bug in o.a. Tomcat 7.0.57 en 8.0.15.
Na authenticatie volgt autorisatie. Er wordt vastgesteld welke rollen de gebruiker heeft. Hier zijn 3 manieren mogelijk. Ze kunnen allemaal tegelijk worden gebruikt en dan worden de gevonden rollen bij elkaar opgeteld.
[1] geeft aan dat het record van de gebruiker wordt geïnspecteerd en als daar een attribuut staat met de naam memberOf dan wordt de waarde van dat veld als rol toegevoegd. Elk willekeurige attribuut kan worden gebruikt. Zoals het nu in de context staat wordt als rol beheerder toegevoegd.
[2] geeft dat in het deel van de LDAP dat ou=rollen,dc=b3p,dc=nl heeft gezocht wordt naar records waar in het attribuut uniqueMember de DN van de gebruiker die ingelogt wordt staat. Dit kunnen er meerdere zijn. Als dit record wordt gevonden dan wordt de cn van dat record toegevoegd als rol. In die geval krijgt Jaap de rol beheerder. [3] geeft aan dat ieder gebruiker die geauthenticeerd is automatisch de rol gebruiker krijgt.
Als je Jaap nu zou inloggen en je vraagt op welke rollen hij heeft dan krijg je het volgende resultaat:
- beheerder (via [1])
- beheerder (via [2])
- ExtendedUser (via [3]) Alle rollen uit [1], [2] en [3] worden bij elkaar opgeteld.
Bij de configuratie moet wel rekening worden gehouden dat meestal bij het definiëren van een memberOf attribuut van een gebruiker bij [1] wordt afgedwongen om de volledige DN te gebruiken. In dat geval zal het rollen lijstje er als volgt uitzien:
- cn=beheerder,ou=rollen,dc=b3p,dc=nl (via [1])
- beheerder (via [2])
- ExtendedUser (via [3]) Via [1] en [2] komt dus de zelfde rol binnen, maar de schrijfwijze is anders. Dit heeft consequenties voor de configuratie later.
De gebruiker komt na authenticatie en autorisatie aan bij Flamingo. Daar worden de rollen vergeleken met de beschikbare gebruikersgroepen. Een standaard gebruikersgroep is ExtendedUser. Als in de vorige paragraaf als commonRole ExtendedUser is gebruikt dan is er een match en krijgt de gebruiker de bijbehorende rechten. Het is ook mogelijk andere groepen in Flamingo aan te maken en dan dus ook vegelijkbare rollen via LDAP toe te wijzen.
B3Partners 29-8-2017