Radius en Kerberos voor niet-webgebaseerde toepassingen
Probleemstelling
Traditioneel wordt de toegang van gebruikers tot ICT-toepassingen in de toepassing zelf gecontroleerd op
basis van gebruikersnaam en wachtwoord. Hierdoor hebben gebruikers voor elke toepassing een gebruikersnaam
en bijhorend wachtwoord. Het wachtwoord is vaak verschillend naargelang de toepassing, en dit is niet gebruikersvriendelijk.
Er is een vraag naar toegangscontrole via een centraal systeem op basis van één unieke combinatie van gebruikersnaam
en wachtwoord.
Samenwerkingsverbanden met andere onderwijsinstellingen (b.v. de Associatie K.U.Leuven) en onderzoekscentra (bv.
Europese onderzoeksprojecten) waarin ICT-toepassingen gemeenschappelijk gebruikt worden, creëren de nood aan
toegangscontrole van gebruikers die behoren tot andere instellingen.
Wat is het verschil tussen authenticatie en autorisatie? Als een gebruiker succesvol geauthenticeerd is, betekent dit niet dat de
gebruiker ook automatisch toegang krijgt tot alle applicaties. Hierdoor dient er voor elke gebruiker centraal ook
informatie bijgehouden te worden over de autorisatie of toegelaten toegang tot applicaties (dit is verschillend van de autorisaties
of rechten binnen een applicatie). De autorisatie of toegang tot een applicatie na authenticatie gebeurt aan de hand van
classificatie van de gebruikers (bv. als een gebruiker personeelslid of student is van de K.U.Leuven mag deze gebruik
maken van Toledo of KotNet) of aan de hand van een specifieke eigenschap die aangeeft dat de gebruiker toegangsrechten
heeft tot een bepaalde toepassing.
Concept van de centrale authenticatie- en autorisatie-infrastructuur (AAI)
Toegangscontrole tot ICT-toepassingen wordt geregeld via een centrale authenticatie- en autorisatie-infrastructuur (AAI)
die gebaseerd wordt op een federale architectuur. Dit betekent dat de toegangscontrole van elke gebruiker door zijn eigen
instelling uitgevoerd wordt.
Voor toepassingen die niet webgebaseerd zijn, zullen andere authenticatie infrastructuren zoals Kerberos of
Radius gebruikt worden naargelang het type toepassing.
In de toekomst zullen ook andere toegangscontroletechnieken geïmplementeerd worden die niet op een wachtwoord gebaseerd
zijn (b.v. Digipass, elektronische identiteitskaart) om de beveiliging van gevoelige toepassingen te verbeteren.
Veiligheidsaspecten
Naarmate de toegang tot meer toepassingen via het centrale wachtwoord gecontroleerd wordt, worden de veiligheidseisen voor
het centrale wachtwoord noodzakelijkerwijze strenger.
Het bewaren van het centrale wachtwoord in direct leesbare vorm is een potentieel veiligheidsrisico.
Het intikken van een wachtwoord in minder veilige omgevingen betekent een potentieel veiligheidsrisico:
het wachtwoord kan er gecapteerd worden door het afluisteren van het toetsenbord. Deze overweging is een bezwaar
vanuit de beveiligingscommissie om het centrale wachtwoord te gebruiken voor zeer gevoelige toepassingen.
Tijdens het uitvoeren van de toegangscontrole passeert het centrale wachtwoord in de toepassing en is er een
potentieel veiligheidsrisico dat het centrale wachtwoord er gecapteerd wordt.
Consequenties
Het aanmaken, de eerste uitreiking en het regelmatig vernieuwen van het “centrale wachtwoord”
zal aan strengere regels onderworpen worden. Het GeBu heeft het advies van de ICTS-raad hierover goedgekeurd.
Het centrale wachtwoord zal in de toekomst uitsluitend onder versleutelde vorm bewaard worden.
Centrale en decentrale toepassingen, die in de toekomst de toegangscontrole uitvoeren op basis van het centrale
wachtwoord, zullen worden aangepast zodat uiteindelijk het wachtwoord niet meer in de toepassing voorbijkomt.
In een overgangsfase zal toegestaan worden dat, indien er toepassingen zijn waarvoor dit op korte termijn onmogelijk blijkt,
in deze toepassingen het wachtwoord versleuteld passeert.
