FACULTEIT INGENIEURSWETENSCHAPPEN EN ARCHITECTUUR Vakgroep Industriële Technologie en Constructie Uitgebreid voorstel Masterproef Informatica Titel van het project : Ontwerp en ontwikkeling van een flexibele authentication engine Datum indienen : Naam student : Wim Verdonck Interne promotor: German Hurtado In samenwerking met : Bedrijf / IMinds / vakgroep Informatica Algemene informatie voor extern bedrijf: Naam van het bedrijf : VASCO Data Security NV/SA Adres: Koningin Astridlaan 164 1780 Wemmel • Is dit de 1e masterproef in het bedrijf in samenwerking met onze opleiding? Ja/Nee • Is er in het bedrijf inhoudelijke en technische begeleiding mogelijk ? Ja/Nee • Kan de student in het tweede semester (februari-mei) 3 dagen per week in het bedrijf/onderzoekscentrum aanwezig zijn om te werken aan de masterproef? Ja/Nee Begeleiding : Externe promotoren – andere begeleiders : ing. Wim Abraham (externe promotor, director services ) Matthew Van Kuyk (begeleider, senior integration engineer) Bespreking door de werkgroep Beslissing: (niet invullen bij indienen van een voorstel) goedgekeurd - herwerken tegen …/… Minimale uitbreidingen: Opmerkingen: Advies van collega’s: Faculteit Ingenieurswetenschappen en Architectuur Vakgroep Industriële Technologie en Constructie Campus Schoonmeersen, Valentin Vaerwyckweg 1, B-9000 Gent www.ugent.be/ea/it-c Doelstelling van het project : De doelstelling van deze masterproef is het ontwerpen en ontwikkelen van een authentication engine die aan de hand van een API kan aangeroepen worden op meerdere platformen (Microsoft Windows, Linux). Deze engine zal de authenticatieaanvraag versturen naar bestaande authenticatieservers en -services, gebruik makende van standaard protocols (SOAP, REST). De engine moet zo ontworpen worden dat nieuwe authenticatieservers en services eenvoudig geconfigureerd kunnen worden. Nieuwe authenticatiemethodes moeten op een flexibele manier toegevoegd kunnen worden (plugin). Bestaande situatie en probleemstelling : Vandaag bied VASCO een brede waaier aan authenticatieproducten, elk product met zijn eigen specifieke eigenschappen op gebied van implementatie, beheer, etc. Ook zijn de producten doelgroepgericht, welke interne en/of externe gebruikers kunnen zijn. Wat wij echter merken, als VASCO, is dat de business vandaag zeer veranderlijk en zeer veeleisend is. Zo zien wij dat een klant meerdere authenticatiemogelijkheden ter beschikking wil hebben, dit alles in 1 implementatie van die verschillende authenticatiemogelijkheden. VASCO is een bedrijf dat niet stilstaat en er komen dus op termijn ook nieuwe producten uit. Indien de klant deze producten dan zou willen gebruiken als authenticatieserver, dan zou de klant een volledig nieuwe implementatie moeten doen. Dit is tijdrovend en meestal een grote drempel, vooral voor kleine bedrijven. Een voorbeeld beschrijft de huidige situatie: bedrijf X heeft zowel interne als externe medewerkers. Voor authenticatie van zijn interne medewerkers gebruikt hij ‘Identikey Authentication Server’ (IAS). Deze IAS is een softwarepakket die hij installeert op een eigen server en zelf beheert. Er wordt wel voorzien in ondersteuning voor VASCO. Voor de externe medewerkers, tewerk gesteld in bedrijven A,B,C,… wil bedrijf X echter het beheer van de geauthentiseerde gebruikers niet in eigen handen nemen. Daarom legt hij de externe bedrijven op om het ‘DIGIPASS as a Service’ platform (DPS) te gebruiken. Zo kan de firma van de externe medewerkers alles omtrent gebruikers en Digipassen op een uniforme manier beheren. Uit het voorbeeld is duidelijk dat als bedrijf X de authenticatieservice wil aanbieden aan zijn interne en externe medewerkers er twee producten moeten gebruikt worden. Daarom zal er een authentication engine ontworpen en ontwikkeld worden, die beide functionaliteiten in 1 implementatie zal aanbieden en waarvan een klant (bedrijf) gebruik kan maken. Hiermee wordt een centraal aanspreekpunt gecreëerd, bedoeld voor authenticatie van zowel de interne als externe medewerkers. IAS is zelf een software die een extra authenticatie kan doen (back-end authentication). Vandaag dient men een ontwikkeling te doen per extra back-end en dit ook voor onze eigen producten. IAS voorziet in de mogelijk om een ‘Two-Factor’ authenticatie uit te voeren. Hierbij zijn een username en OneTimePassword (OTP) vereist. Een OTP is een genereert paswoord, dat éénmalig kan gebruikt worden om een authenticatie uit te voeren en dat maar geldig is in een nader bepaald tijdsframe. VASCO biedt verschillende systemen aan die OTP’s genereren, zowel hardware als softwaregebaseerde systemen. Tevens bestaan er mobiele toepassingen van VASCO op bijvoorbeeld smartphones waarmee ook een authenticatie kan uitgevoerd worden. Deze kunnen allemaal gebruikt worden om o.a. OTP’s te generen, die voldoen aan bepaalde voorwaarden en specificaties, zoals bijvoorbeeld geldigheid van het gegenereerde OTP. Bij het tweede luik in de gedetailleerde beschrijving van de masterproef kan dit ook gebruikt worden (zie lager). De authentication engine die het onderwerp is van deze masterproef zal ingezet worden in volgende situaties: - Integratie in producten van 3de partijen (partners) aan de hand van de API van de engine. Op deze wijze kan de partner, zonder additionele ontwikkeling, eenvoudig kiezen uit de verschillende authenticatieservers/-services van VASCO die de engine aanbiedt. - Ontwikkeling van een VASCO plugin die moet toelaten om een authenticatievraag van IDENTIKEY Authentication Server naar het DIGIPASS as a Service platform te sturen. 2 Gedetailleerde omschrijving van de opdracht die minimaal moet worden verwezenlijkt: De masterproefopdracht is een tweeluik. Deze zijn ten eerste het ontwerp en ontwikkeling van de authentication engine en als tweede deel het ontwikkelen van een testapplicatie, bedoeld om de engine op verschillende manieren te testen. De eerste opdracht gaat over het ontwerpen en ontwikkelen van de authentication engine. Deze kan gebruikt worden op verschillende Operating Systems (Windows, Linux). De authentication engine kan aangeroepen worden via een API die de functionaliteit van de engine aanbiedt. Bij voorkeur wordt de API in C++ aangesproken en geïmplementeerd. De bedoeling van de engine is om binnenkomende authenticatieaanvragen achter de schermen af te handelen zonder dat het aanvragende systeem zelf een authenticatieprocedure moet doorlopen. Hierdoor moet het systeem zelf niet de authenticatieprocedure implementeren. Op deze manier kunnen verschillende systemen op een uniforme manier een authenticatieaanvraag doen via de API van de engine. Deze systemen moeten dus gewoon de interface kennen van de engine om authenticatie in te bouwen. De authenticatieprocedure van aanvraag van een systeem tot eventuele authenticatie door een VASCO authenticatieserver of service verloopt als volgt. Het systeem roept de gewenste API-functie van de authentication engine op met de nodige parameters. Als gevolg hiervan verstuurt de engine de aanvraag tot authenticatie van het aanvragende systeem naar een VASCO authenticatieserver of service (back-end). Deze VASCO server of service blijft weliswaar verantwoordelijk voor de authenticatie van het aanvragende systeem. Vervolgens ontvangt de engine van deze VASCO authenticatieserver of -service een antwoord op de authenticatieaanvraag, gestuurd door de engine op vraag van het aanvragende systeem. Tenslotte levert de engine aan het aanvragende systeem een antwoord op zijn originele authenticatieaanvraag. De authentication engine die in deze opdracht moet verwezenlijkt worden, fungeert dus als intermediaire station die de authenticatieprocedure afhandelt en een antwoord levert, op basis van een VASCO authenticatieserver of -service. Systemen die authenticatie willen gebruiken van VASCO moeten zich dus eenvoudig richten tot deze engine en hoeven van het volledig achterliggend authenticatieproces niets af te weten. De authentication engine is een modulair opgebouwd geheel en moet in het kader van de masterproefopdracht minimaal de volgende twee back-end authenticatiemodules implementeren – welke gebruik maken van verschillende protocols: - Authenticatie via een VASCO authenticatieserver (IDENTIKEY Authentication Server/IDENTKEY Appliance) via SOAP over HTTP/HTTPS - Authenticatie via een VASCO authenticatieservice (DIGIPASS as a Service) via REST over HTTP/HTTPS Als men dit linkt aan de probleembeschrijving hogerop, kan men volgende vaststellingen doen. IAS is ontwikkeld op basis van SOAP. In het kader van de masterproef zal de authentication engine met deze IAS moeten communiceren. Het te implementeren protocol hiervoor is dan natuurlijk ook SOAP. Voor implementatie van de externe medewerkers via DPS zal REST gebruikt worden. De architectuur van de authentication engine moet zo opgebouwd worden dat er later, op een eenvoudige wijze, andere authenticatiemethoden kunnen toegevoegd worden (modulair / plugin). Aan de hand van een configuratiebestand moet het gedrag van de authentication engine kunnen beïnvloed worden, alsook alle nodige configuratieparameters ingesteld worden. Bij voorkeur moet het mogelijk zijn om kleine aanpassingen in het protocol op te vangen via configuratie en niet via codering. De authentication engine moet ook voorzien in de nodige auditing, logging en tracing. Hierdoor wordt het mogelijk gemaakt informatie te verzamelen die troubleshooting en debugging toelaten wanneer de engine gebruikt wordt door VASCO partners en klanten. De authentication engine moet tevens voorzien worden van voldoende documentatie, zodat latere uitbreidingen door VASCO of 3de partijen ontwikkeld kunnen worden. Het tweede luik van de masterproefopdracht gaat over een testapplicatie. Die testapplicatie met bijhorende testscenario’s, die bij voorkeur geautomatiseerd uitgevoerd worden, dient ook ontwikkeld te worden. De testapplicatie moet toelaten om de authentication engine functioneel te testen en om loaden performantietesten uit te voeren. Hierdoor kunnen de parameters van de authentication engine bijgesteld worden. Deze testapplicatie gaat automatisch zoveel mogelijk aspecten van de 3 authentication engine testen, zowel negatief als positief. De bedoeling is dat de engine de verwachte gedragingen heeft. Zo mag bijvoorbeeld bij een geweigerde authenticatie de authentication engine geen OK-status geven. Aan de hand van de verschillende testen die men zou willen uitvoeren, wordt een testplan opgesteld. Dit is de beste strategie om deze testen op een gecoördineerde manier aan te pakken. Het testen wordt opgedeeld op 2 aspecten, functionaliteit en load. Bij het testen op functionaliteit wordt nagegaan of de authentication engine reageert zoals verwacht wordt. De verschillende functies worden dus nauwkeurig getest en output geanalyseerd, zowel in positieve als negatieve scenario’s. Enkele voorbeelden: geslaagde authenticatie, niet geslaagde authenticatie, time-out van de authenticatieserver. Bij load-testen ligt de focus op het aantal aanvragen dat de engine kan verwerken, zonder dat de stabiele werking van de engine in het gedrang komt. Hierbij is de configuratie van de omgeving waarin de engine opereert van heel groot belang. Beide testen leveren een evaluatierapport waar alle bevindingen op te vinden zijn. Bij de load-testen moeten ook de belangrijkste specificaties van de machine vermeld staan, zoals bijvoorbeeld welke machine gebruikt werd, welke hardware de machine bevat,… Als uitbreiding voor de testapplicatie kunnen verschillende soorten manieren van authenticatie uitgevoerd worden. Zo kan de combinatie username & password gecheckt worden, maar ook username & OneTimePassword (OTP). Dit geldt voor beide types van testen. Het gebruik van 3de partij bibliotheken (open source) is toegelaten – commerciële bibliotheken kunnen niet gebruikt worden. Problemen die moeten opgelost worden (niet te gedetailleerd): - Module moet kunnen functioneren op verschillende OS (Windows/Linux) Hoge mate van configureerbaarheid, zodat het niet steeds noodzakelijk is om code te wijzigen indien er aanpassingen aan het protocol gebeuren Technologieën die aan bod komen : - Software ontwikkeling o C++ (voor performante code, cross-platform – Windows/Linux) - Operating Systems o Linux o Microsoft Windows - Protocols o SOAP over HTTP/HTTPS o REST over HTTP/HTTPS - Andere o XML Mogelijke uitbreidingen en opties : - - Veilige opslag van configuratie gegevens Algemene veiligheid van authentication engine (hoe manipulatie van configuratie vermijden) Uitwerken van mogelijkheden om authentication engine aan te roepen vanaf andere ontwikkel omgevingen (e.g. C#, Java, php …) Ontwikkeling van module voor authenticatie via SAML Ontwikkeling van module voor authenticatie via OAuth Ontwikkeling van modules voor andere authenticatiemethodes (LDAP, AD, RADIUS …) Meer keuze tussen authenticatiemethode-testen bij de testapplicatie (username & password en username & OneTimePassword (OTP) Vernieuwende aspecten : - - Modulaire aanpak om verschillende authenticaties eenvoudig toe te kunnen voegen / verwijderen, zonder de code aan te passen Aanpassen van het gedrag van de engine via een configuratiebestand Authenticatieproces op low-level implementeren Automatiseren van testen en analyserapport opstellen, aangevuld met systeemspecifieke informatie Authenticatiesysteem op basis van ‘Two-Factor authentication’ 4
© Copyright 2025 ExpyDoc
