Authoriserende plugins voor XML documentoverdracht

De afgelopen maanden is het Internet enorm opgeleefd, met als gevolg dat zelfs veel oma's hun breipennen verruilen voor een muis. Deze populariteit bij het grote publiek is ondermeer te danken aan de mogelijkheden om informatie te onttrekken en transacties te volvoeren op het Internet, een mogelijkheid waar vaak databases onder liggen.

De meeste systemen van vandaag leveren informatie aan als layout, namelijk in HTML, maar moderne ontwikkelingen aan XML maken het mogelijk om conceptuele informatie af te leveren voor locale verwerking en opmaak. XML is niet (zoals HTML) per se op een bepaalde plek in de interactie tussen browser en database aanwezig, maar kan op allerlei plaatsen voorkomen.

Door deze eigenschappen van XML wordt het zinnig om componenten te bouwen die met elkaar communiceren in XML. Het zou buitengewoon zinnig zijn een component te bouwen om tussen twee normaalgesproken goed communicerende componenten te prikken, die aan de communicatie een authorisatiemechanisme toevoegt, ofwel alleen datgene doorlaat wat toegestaan is op basis van login status. Iemand die alleen bepaalde informatie mag zien of wijzigen, krijgt hierdoor een beperkte view op de database (of andere XML service) aangeboden.

We zien dit probleem graag generiek opgelost, dus niet specifiek voor databases, maar voor XML services in het algemeen. We wensen eveneens diverse authorisatie modellen, bijvoorbeeld zowel read-only als writeable-for-subscribers.

Binnen deze opdracht valt niet alleen het ontwerp van een authorisatiemodel, maar ook een implementatie daarvan, en een redelijke casus. Als casus denken we aan een wat ingewikkelder model, zoals een waarbij iedereen mag lezen, en desgewenst na subscriben write-access krijgen op bepaalde delen van de XML service. Bijvoorbeeld: Een centrale database waarin iedereen ter wereld ervaringen met al dan niet ondersteunde hardware onder Linux kan delen.

Voor deze afstudeeropdracht wordt zowel een student als een begeleider gezocht. Dat is omdat de bedenker (Rick) de tijd niet heeft om eerste begeleider te zijn bij deze opdracht. Pas dus op, er is geen garantie dat deze opdracht daadwerkelijk leven ingeblazen gaat worden!