@ventures. Erhvervsakademiet. Århus Købmandsskole DATANOM SPECIALE. Authentific. Et Generisk Autentifikationsmodul til Web-Applikationer

Transkript

1 @ventures og Erhvervsakademiet Århus Købmandsskole DATANOM SPECIALE Authentific Et Generisk Autentifikationsmodul til Web-Applikationer af Niels Müller Larsen 19th July 2004 Vejleder: Jørgen Leth

2

3 Copyright c 2004 Niels Müller Larsen. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Forord Baggrund For mange, mange år siden læste forfatteren til nærværende specialeopgave Økonomi på Århus Universitet. Det var af flere grunde et dårligt valg, og efter et par forsøg på 1. dels-eksamen afsluttede jeg den æra. Man skal ikke kaste god tid efter dårlig, kan man sige med en let omskrivning af en kendt talemåde. Jeg tog imod et stående tilbud om at starte på at arbejde med edb, som programmør og systemplanlægger, som det hed dengang. Derefter var mit liv programmeret. Siden har jeg beskæftiget mig med edb. Edb var så udbredt og anvendt som akronym, så dansk sprognævnt ophøjede det til et ord i sproget, hvorefter vi måtte skrive det med små bogstaver. Efter at have nået dette høje niveau, skiftede vi betegnelsen ud med IT. Afskeden med den akademiske løbebane var aldrig en hemsko. Først mange år senere, da jeg som lærer ved en edb-skole fandt stor tilfredsstillelse ved fordybelsen i de faglige emner, faldt det mig ind at genoptage universitetsstudierne. Det blev til en Master of Science i Networked Information Engineering fra Sheffield Hallam University i England, min alma mater. Datanomspeciale? Hvorfor så overhovedet kaste sig over datanomuddannelsens specialeopgave? I de mange mellemliggende år fra universitet i Århus til universitet i Sheffield, var jeg optaget af edb-arbejde, og det indebar konstant efteruddannelse. Noget af det bedste heraf var de datanommoduler jeg tog, fordelt over en nu årig periode og under vistnok tre forskellige datanom-bekendtgørelser. Jeg er i gang med det ottende og niende modul i øjeblikket. Da datanomuddannelsen nu er under omdefinering igen, denne gang til VVU, Videregående Voksenuddannelse, følte jeg trang til at runde uddannelsen af. En anden årsag til specialet, og måske specielt valget af emne, er at det passer ind i en konkret undervisningsmæssig periode på flere af de emner jeg underviser i på Multimediedesigneruddannelsen. Det hører også med til historien, at gennem egen erfaring og arbejde med hovedopgaveog specialevejledning er der opstået en vis fascination af denne arbejdsform og dens afrapportering af intellektuelt arbejde. iii

4 iv Læsevejledning Enhver forfatter ser sikkert helst, at alle læser hvert ord. Skulle en enkelt læser have meget travlt, indeholder rapporten et resume umiddelbart herefter. Det vil kort introducere ide, arbejde og løsning. Giver læseren sig lidt mere tid, men ikke nok til en komplet gennemlæsning, kan det anbefales at læse kapitel 1 og konklusionen i kapitel 8. Alle andre vil finde det nyttigt at læse hele teksten i den skrevne rækkefølge. Bilagene i rapportens appendices er ikke egentligt læsestof, men kan bruges som reference. Blandt andet vil den komplette kildekode findes her. Copyleft Dette dokument er forfatterens intellektuelle ejendom. Det stilles, sammen med den i dokumentet beskrevne software, til rådighed for andre under GNU Free Documentation License 1, se venligst appendiks E. Den beskrevne software skal samlet kendes under navnet Authentific. Der vil blive taget initiativ til at softwaren gøres tilgængelig i elektronisk form, og at hvert delprogram af den beskyttes i overensstemmelse med GPL 2. Tak til I et forord er det passende at vedgå arv og gæld til dem, der direkte og indirekte har betydet noget for arbejdet. Derfor en særlig tak til de forfattere, der, uden af give køb på seriøsiteten, har overskud til at bringe ironisk distance og humor ind i behandlingen af selv svære emner. Især Tanenbaum (2003) har sin øjeblikke. En særlig tak også til Zandstra (2000), der under arbejdet med dette projekt åbnede min øjne for et aspekt af PHP, hvis nytte trods adskillige års arbejde med sproget ikke var gået op for mig tidligere. Se rapportens appendiks D. En tak også til de kollegaer, der har gidet høre på og diskutere med mig. Og familien! Og... Niels Müller Larsen

5 Resume At internettet skulle være kommet for at blive turde være århundredets underdrivelse. Vi synonymiserer ofte internettet med dets to killer applications elektronisk post og World Wide Web. Det indeholder den sandhed, at mange virksomheder i stigende grad anser WWW for en god platform for systemer, der tidligere ville have været interne systemer. Denne rapport beskriver et projekt, der håndterer nogle sikkerhedsaspekter af denne situation. Bruges WWW som basis for en applikation, selv en intranetapplikation, må man forudse, at man får flere interesserede brugere, fordi alle har basisteknologien til rådighed. Det betyder, at applikationen selv må sikre, at den ikke kan misbruges af brugere, der kun bør have tilskuerens rolle, eller eventuelt ingen rolle overhovedet i forhold til applikationen. For at opnå dette formål har projektet udviklet et system til autentifikation, det vil sige sikring af, at kun vedkommende har adgang. Produktet dokumenterer, at dette kan gøres på en måde, så systemet med minimale omkostninger kan implementeres i allerede eksisterende webapplikationer, og uden ekstra omkostninger kan integreres i ny udvikling af webapplikationer. Det udviklede autentifikationssystem, Authentific, er uafhængigt af, hvilket databasesystem de beskyttede applikationer måtte anvende, idet Authentific foretager sit eget valg af databasesystem. Samtidigt dokumenterer projektet sandsynligheden af, at systemet kan tilpasses ethvert databasesystem, som virksomheden måtte have i forvejen. Authentific har med succes været afprøvet på to gængse databasesystemer, der begge vedkender sig SQL-standarden. v

6

7 Indhold Forord Resume ii v 1 Domæne og problem Domænebeskrivelse Problembaggrund Sikkerhedsmæssige omgivelser Administrative omgivelser Problemformulering Problemer omkring udvikling og implementering Problemer omkring den administrative brugergrænseflade Autentifikationsgrænsefladen Afgrænsninger Litteratur Foreløbig tidsplan Metodeovervejelser Projektmodeller Paradigmer, kort Konkrete valg Analyse af relevante sikkerhedsmodeller Platforme Kryptering Konventionel (Symmetrisk) kryptering Moderne (Asymmetrisk) kryptering Nøglerne Anvendelse Definition af sikkerhedsproblematikken Platformenes generelle tilbud Webserverne Databasesystemerne Programmeringssprog Autentifikation Analyse og udvikling af løsning Authentifics ide og datamodel Den første skitse En anden mulighed Normalisering Authentifics data dictionary Authentifics anvendelsesarkitektur vii

8 viii INDHOLD 4.3 Authentifics tre hovedkomponenter Autentifikations-stub auth implement.inc Autentifikationsmodulet authenticate.php Deautentifikationsmodulet deauthenticate.php Databaseabstraktion Evaluering af metode b-modellen Rønnow/Jacobsen metoden Evaluering af proces Uforudsete problemstillinger Sikkerhed omkring passwords Beskyttelse af programmer På vejen til Rom Hvor går vi hen herfra? Man kunne for eksempel Integration med et eksisterende personalesystem Single Sign On Fra prototype til produkt Konklusion Problemformuleringen genbesøgt Et nuanceret billede Kærnespørgsmålene De andre spørgsmål Svar på det ikke stillede spørgsmål A Authentific database 49 A.1 SQL-script: DDL til oprettelse af authentific B Authentifics kærnekomponenter og deres anvendelse 51 B.1 Script: authenticate.php B.2 Script: deauthenticate.php B.3 Script: auth implement.inc B.4 Authentific, vigtigste include-filer B.5 Authentific, anvendelseseksempler B.5.1 bruger vis.php B.5.2 klasse vis.php C Authentific, baggrundskode 57 C.1 Authentific, supporting scripts C.1.1 Øvrige include-filer C.2 Authentific administrative scripts C.2.1 Databasetabellen program C.2.2 Databasetabellen bruger C.2.3 Databasetabellen gruppe C.2.4 Databasetabellen berig, bruger-er-i-gruppe D PHP Objektorientering 71 D.1 PHP-classes E GNU Free Documentation License 79

9 INDHOLD ix Litteratur 85

10

11 Kapitel 1 Domæne og problem Truth is stranger than fiction, because fiction has to make sense. UNIX Fortune 1.1 Domænebeskrivelse Problembaggrund Multimediedesigneruddannelsens specialiseringsprofil Design og Interaktion beskæftiger sig med udvikling af databasedrevne, web-baserede IT-applikationer, samt med skabelse af grænseflader hertil. Da Deres hengivne underviser i programmering og databaseteknologi på denne profil, er der både en akademisk og en praktisk interesse i software- og databaseteknologi indenfor dette problemområde. Set i sin helhed ud fra en datadrevet synsvinkel kan man hævde, at web-applikationer, ligesom mere traditionelle applikationer, har til opgave at varetage nogle grundfunktioner omkring en virksomheds data. Disse grundfunktioner er oprettelse, ajourføring, sletning og fremvisning af data. Lad mig gruppere de tre førstnævnte som vedligeholdelse af data. Fortolker vi fremvisning af data bredt, kan det siges, at det inkluderer anvendelse af data i diverse operationelle sammenhænge såsom til ren information, viden, mentalt beslutningsgrundlag, eller det kunne være anvendelse i forbindelse med, at data indgår i andre delsystemer som en del af grundlaget for vedligeholdelsen af data her. Vælger vi at betragte systemudvikling som tilvejebringelse af funktionalitet til henholdsvis vedligeholdelse og anvendelse af data med et konkret formål, kan vi lidt firkantet sige, at vedligeholdelsen af data sker for disse datas egen skyld, mens anvendelse beskriver formål og baggrund for disse data. Rent abstrakt bør man forestille sig, at vedligeholdelsen af data foretages af en brugergruppe, mens anvendelsen af data foretages af en anden brugergruppe. Dette kan eksemplificeres ved en handelsskoles web-site, hvor skolen, eller nogle ansatte på skolen, vedligeholder data vedrørende uddannelser, deres fag, semesterstart og -slut, adgangskrav, ansøgningsfrister mv. Heroverfor står brugerne, studerende og potentielle studerende, der anvender disse data som information til planlægning af deres studium. Det turde være klart, at førstnævnte gruppe skal have privilegier i forhold til applikationen, der tillader, at de kan vedligeholde disse data, mens brugerne ikke skal have sådanne privilegier. De skal alene være brugere af data. Heraf følger således et afledt behov for at adgang til en applikations funktionalitet i form af programmer, evt delprogrammer skal kunne styres, så integriteten af data bevares. Sagt på en anden og mere kontant måde, kan vi sige, at det handler om, at data, hvis formål vi implicit anerkender, kun skal kunne vedligeholdes af autoriserede personer. 11

12 12 Kapitel 1: Domæne og problem Sikkerhedsmæssige omgivelser Forskningsministeriet skriver i sin rapport Informationssamfundet år 2000 Bilag 6. Det offentliges arkiv- og journalsystemer 1. Kryptering opfylder 4 sikkerhedskrav, som er nødvendige: Autenticitet, integritet, uafviselighed og konfidentialitet. Autenticitet betyder at kun en afsender kan have sendt dokumentet. Citatet retter sig særligt mod dokumenter, der udveksles over nettet, men det væsentlige i denne sammenhæng er de 4 nævnte nødvendige krav. Begrebet autenticitets betydning er nævnt i citatet. Autenticitet betyder i forhold til adgang til et system også, at kan man godtgøre at være den, man udgiver sig for, så får man adgang. Autentifikation betyder, kort og uformelt defineret, at man identificerer sig med et bruger-id og beviser sin identitet ved at kende et kodeord, et password. Dette vil blive præciseret i afsnit Administrative omgivelser Et system skal sikres, eller dele af et system skal sikres. Det kan alle blive enige om. Samtidig må det ikke koste meget, og det må ikke være besværligt. Modsat rettede mål må man vel sige. Et system til sikring af adgang til andre systemer og virksomhedens følsomme data må ikke være udformet på en sådan måde, at det virker prohibitivt for anvendelsen. Hverken med hensyn til økonomiske eller praktiske omkostninger. Dette betyder, at det er i alles interesse, at vedligeholdelse af autentifikationssystemets indhold skal være let. Registrering og vedligeholdelse af brugere skal føles som en naturlig arbejdsopgave. Registrering og vedligeholdelse af applikationernes sikkerhedsprofil ligeledes. Samtidigt kan det vel siges, at vil man sikkerhed omkring sine data, så er denne sikkerhed en arbejdsopgave, og ikke noget der også lige skal huskes ved siden af en række andre ting. 1.2 Problemformulering Det ønskes undersøgt om det er muligt at udvikle et autonomt og generisk autentifikationssystem til brug for web-applikationer, der har brug for beskyttelse af hele eller dele af applikationen og dens data. Det skal ske ud fra en grundfilosofi om, at et program beskytter sig selv, fordi det er det nærmeste til at gøre det. At systemet skal være autonomt, betyder her, at det skal være programmeret på en sådan måde, at det ikke er en integreret del af en konkret applikation. Det skal kunne anvendes af enhver webapplikation, der ønsker det. At systemet skal være generisk, betyder netop dette sidstnævnte, at det skal kunne anvendes af enhver webapplikation, fordi det passer til enhver webapplikation. Dette indebærer besvarelse af en række spørgsmål Problemer omkring udvikling og implementering Kan autentifikation isoleres fra generel sikkerhed omkring datakommunikation og netværk på en måde, så der logisk og praktisk kan skrives software til dens håndtering i en World Wide Web-sammenhæng? Det skal undersøges om kendte metoder omkring adgangssikkerhed findes i tilknytning til de platforme som de teknologiske omgivelser, operativsystemer, webservere og databasesystemer, frembyder, og det skal overvejes, om disse er tilstrækkelige. 1 Forskningsministeriets hjemmeside:

13 1.3: Afgrænsninger 13 Kan et autentifikationssystem udformes på en måde, så det vil være naturligt at anvende i fremtidig systemudvikling uden store ekstraomkostninger? Det er ligeledes en væsentlig faktor at få undersøgt om eksisterende applikationer let kan upgraderes til at anvende et nyt autentifikationssystem Problemer omkring den administrative brugergrænseflade Det skal afklares om en brugers status fra ansættelse i en organisation, over omrokeringer til evt. fratræden, vil kunne håndteres af systemet på en enkel måde. På samme måde skal det overvejes, om tilføjelser og ændringer i de systemer, der skal beskyttes kan afspejles af systemet uden for store manuelle arbejdsopgaver. Brugerindflydelse på systemet skal belyses, eksempelvis i forbindelse med egen indflydelse på passwords og deres kvalitet Autentifikationsgrænsefladen Autentifikation betyder som nævnt, at brugeren blive afkrævet en brugeridentifikation og et password. Det skal afklares om autentifikationsprocessen selv er tilstrækkeligt sikret, og hvad denne sikring kræver. Problemt er her, om det er muligt for uvedkommende at aflure kombinationer af bruger-id, password. 1.3 Afgrænsninger Kombinationsmulighederne, når der skal vælges operativsystem, databasesystem, webserver og programmeringssprog, er legio. Det er derfor nødvendigt at foretage nogle valg og dermed afgrænse sig fra andre muligheder. Udvikling og implementering (jf ) Udvikling og implementering på baggrund af en grundig analyse er projektets primære fokusområde. Det foreløbige valg er at udvikle en løsning baseret på anvendelse af et operativsystem- og webserver-uafhængigt programmeringssprog. Valget er PHP, og dette valg vil der blive argumenteret for senere. Hertil kommer, at det er forfatterens ønske, at en løsning skal kunne være databasesystemuafhængig. Dette medfører, at en løsning skal programmeres således, at databasegrænsefladen er udskiftelig. Løsningen vil i første omgang blive afprøvet på mindst to forskellige databasesystemer. Al programfunktionalitet vil blive testet i både en af Mozilla-varianterne, Opera og Internet Explorer. Administrativ grænseflade (jf ) Dette område er projektets sekundære fokus, men af hensyn til test af projektets primære problemstillinger vil der blive udarbejdet web-programmel også til håndtering af autentifikationsdatabasens relationer (tabeller). 1.4 Litteratur Af generelle værker om sikkerhed skal nævnes Pfleeger and Pfleeger (2002). Indenfor kommunikationsområdet kommer nødvendigvis også Stallings (2000), Tanenbaum (2003), Garfinkel and Spafford (2002) og Garfinkel, Schwartz and Spafford (2003). I øvrigt vil der blive trukket på viden fra en lang række andre værker og websteder.

14 14 Kapitel 1: Domæne og problem 1.5 Foreløbig tidsplan Forskellige aspekter af en mulig løsning har været afprøvet i forbindelse med udarbejdning af cases til undervisningsbrug. Det kan derfor forventes, at løsningens primære fokusområde kan udvikles, testes og afrapporteres i løbet af foråret Med start i marts måned.

15 Kapitel 2 Metodeovervejelser And it should be the law: If you use the word paradigm without knowing what the dictionary says it means, you go to jail. No exceptions. David Jones 2.1 Projektmodeller Paradigmer, kort En kilde indenfor organisering af projekter, Christensen, Kjær, Skriver and Staunstrup (2002), tør ikke bruge bruge ordet paradigme uden reference. Når man betænker ovenstående citat, der kommer ud af en UNIX Fortune Cookie, forstår man det jo godt. Det hævdes i kilden, at der findes to grundlæggende former for projektmodeller, den sekventielle og den iterative. Den terminologi skulle passe godt i en systemudviklers begrebsapparat, idet den afspejler nogle fundamentale metoder i programmering og programafvikling. De to nævnte former kaldes også henholdsvis vandfaldsmodeller og inkrementelle modeller. I valget af vandfald som term for en projektmodel ligger det, at ligesom Victoria Falls ikke pludselig begynder at gå den anden vej, så udvikler et projekt sig i en bestemt retning, og når en fase er afsluttet, vender man ikke senere tilbage til denne. Metoden indebærer oftest, at man ved afslutningen af hver fase indgår en aftale med sin opdragsgiver, om at denne fase er tilfredsstillende afsluttet. Modellen forudsætter oftest en velafgrænset problemstilling og klar tidsramme. Iterative modeller indebærer at projektet kan gentage en cyklus og derved får mulighed for at genbesøge faser, og revurdere og eventuelt forfine det arbejde, der er gjort i fasen. I iterative modeller er kunden ofte direkte involveret i projektforløbet, mens det foregår. De iterative modeller anvendes med fordel, hvor der er plads til at projektets problemstilling kan tilpasse sig under projektforløbet, og hvor den løbende kundeinvolvering er vigtig for succes. Figur viser vandfaldsmodellen (1), og to forskellige iterative modeller, der, som det ses, får udseende af spiraler i hele (2) eller del af udviklingsforløbet (3) Konkrete valg Projektmodel I nærværende projekt, hvis problemstilling indebærer ikke blot at udvikle et produkt, men også udforskning af dets konkrete udseende og placering i omgivelser givet fra eksisterende systemer, skønnes det, at valget står mellem de to illustrerede iterative projektformer. Da man ofte, Christensen et al. (2002), kendetegner spiralmodellen (2) ved, at hverken 1 Figuren er tegnet frit efter figur i Christensen et al. (2002). 15

16 16 Kapitel 2: Metodeovervejelser Figur 2.1: Projekt-/udviklingsmodeller. mål eller midler er klart definerede på forhånd, er den måske mindre egnet i det konkrete tilfælde, hvor i hvert fald målet kendes. Illustrationens b-model (3) starter med indledende forundersøgelse, fase 1 og 2, hvorefter spiralformen tillader eksperimenter indtil resultaterne er tilfredsstillende. Til trods for at det i denne model kan være svært at beslutte sig for, hvornår man er færdig, må den skønnes bedst egnet til at kunne opfylde projektets problemformulering. Datamodel I forbindelse med den egentlige systemudvikling af Authentifics datamodel og moduler, vil blive anvendt en datadrevet udviklingsmodel som først er beskrevet af Rønnow and Jacobsen (1989). Rønnow og Jacobsen detaljerer en metodik med henblik på udviklingsprocessen. Den består af 8 trin som følger: 1. Kategorisering. Gennemgå foreliggende materiale om organisationens datagrundlag, og kategoriser ord/dataobjekter i kategorierne entiteter, relationer og attributter. 2. Udkast til ER-diagram. Fremstil et første udkast til et ER-diagram 3. Tabelskitser. Udarbejd tabelskitser for de entiteter og relationer, som indgår i det første udkast til ER-diagrammet. 4. Reducering. Reducer om muligt antallet af tabelskitser. 5. Specialisering/generalisering. Overvej om der bør introduceres specialiserings og/eller generaliserings-hierarkier i ER-diagrammet.

17 2.1: Projektmodeller Transaktionsafprøvning. Opstil en liste over de transaktioner, som datamodellen skal understøtte. Kontroller, at alle transaktioner understøttes. 7. Fremtidige informationskrav. Overvej fremtidige informationskrav og juster eventuelt datamodellen. 8. Eliminering af overflødige entiteter. Slet eventuelle overflødige entiteter. Metoden virker omstændelig og formel til et projekt af denne størrelse, men det er forfatterens erfaring, at de 8 trin er en glimrende checkliste for udviklingen. En erfaren udvikler kan ofte udføre flere af processens trin i en enkelt arbejdsgang og måske samtidigt gøre det mentalt, så der ikke altid kommer papirdokumentation ud af det. Det er dog en klar erfaring, at det er overordentligt nyttigt at have et godt resulterende ER-diagram 2 efter punkt 8. Det er en ligeså klar erfaring, at man bør bevare ER-modellen som en begrebsmæssig model, således som den er tænkt, og ikke misbruge det til at illustrere implementeringsmodellen. Her kommer det alligevel til kort, idet en række constraints 3 ikke kan afbildes, jf. Badia (2004). Når trin 8 er afsluttet kan det egentlige manuelle arbejde starte. Det vil bestå i skrivning af den nødvendige SQL 4 til oprettelse af databasen i det valgte databasesystem. Dette er implementeringen, den fysiske model om man vil, udarbejdet på baggrund af ER-diagram og tabelskitser. Herefter kommer kodning af programmerne, der skal udføre de transaktioner, der omtales i punkt 6. I metoden forestiller man sig punkt 6 som en mental sikring af at datamodellen kan levere de resultater, som virkeligheden ønsker fra databasen. 2 Entity-Relationship. ER uddybes i kapitel 4. 3 Constraints oversættes her bedst ved regler. 4 Structured Query Language. SQL uddybes i kapitel 3.

18

19 Kapitel 3 Analyse af relevante sikkerhedsmodeller Det vil sige, at du - med velberåd hu - ville ændre rute midt på rejsen. Men det er denne bestemte rute, du har ændret på, og ikke en ikke-eksisterende rute. Umberto Eco Platforme Har man valgt World Wide Web som medium for sin applikation, har man samtidigt valgt et medium, hvor vedligeholdere og brugere, autoriserede og uautoriserede har samme teknologi til rådighed. WWW er en gigantisk client/server-applikation, der trives på internettets teknologi, og hvor, bredt sagt, alle har adgang. Dette betyder i praksis, at enhver med en browser, klientprogrammet på WWW, har mulighed for at komme i kontakt med WWWs services, idet disse kan nås af enhver som kender internetadressen, DNS-navnet eller IP-nummeret for den pågældende service. De værktøjer, der udgør omgivelserne for applikationer på web er på klientsiden browseren, og på serversiden er der tale om såvel en webserver som en databaseserver. Browsere Da WWW i denne sammenhæng er tilstede som et begreb, der ligger under den konkrete problemstilling kan det være nyttigt at se på WWWs overordnede programmel. Som netop nævnt er den generelle klient en browser. Den oprindelige grafiske webbrowser Mosaic er næppe værd at nævne i vore dage bortset fra det historiske perspektiv, der i websammenhæng er ganske få år. Efter Mosaic var Netscape Navigator browseren, men den blev overhalet af Microsofts Internet Explorer, der i dag er langt mere udbredt end de øvrige. Netop nu tales der dog om en opbremsning i udviklingen af Internet Explorer. Samtidig er udviklingen omkring Netscape Navigator overført til en Open Source organisation Mozilla, der laver sin egen eksperimentelle browser, der funktionelt ligner Internet Explorer en hel del og som leverer kærnen til Netscape Navigator. Men med Mozillas nye trimmede variant Firefox og den norske Opera er der et par up and coming browsere med potentiale til at tage solide markedsandele. Især Firefox spås i fagpressen en lysende fremtid. De nævnte browsere findes i en række udgaver til forskellige operativsystemplatforme, dog findes Internet Explorer vistnok kun til Windows og Macintosh. Det er selvfølgeligt væsentligt, at den ønskede beskyttelse af funktionalitet og data kan finde sted uanset brugerens valg af klient. Browserens væsentligste rolle i forbindelse med autentifikation ligger i, at den er i stand til at samarbejde med webserverens trufne valg 1 Kunsten at skrive speciale. Eco (1997). Originaludgaven er på italiensk og fra

20 20 Kapitel 3: Analyse af relevante sikkerhedsmodeller med hensyn til for eksempel kryptering af HTTP-pakkerne, jf. Fielding, Gettys, Mogul, Frystyk, Masinter, Leach and Berners-Lee (1999). I en anden sammenhæng er det selvfølgelig interessant sikkerhedsmæssigt, at en browser kan misbruges til at skaffe sig adgang til dens hostsystem, dvs brugerens computer. Webservere Ligesom på browsersiden findes der en række forskellige webservere at vælge imellem. Der er også her en dominerende aktør med hensyn til antal, nemlig Apache, der stammer fra Open Source-miljøet. Hertil kommer en række andre, hvoraf Microsofts Internet Information Server har en vis udbredelse. I hvert fald Apache findes til en række forskellige platforme, men skulle i et overvejende antal tilfælde køre på UNIX-varianterne Linux og x-bsd. Nogle af verdens allermest benyttede webservere, tilhørende de store søgeservices, kører Apache med Linux eller BSD-varianter som hostsystemer. Webserverne har nogle autentifikationsmuligheder og understøtter i øvrigt andre sikkerhedsmuligheder, som er interessante for os. Vi skal se nærmere på disse. Database Management Systemer Taler vi dataintegritet, taler vi om struktureret opbevaring af data i Database Management Systemer, DBMS. Oftest relationelle, RDBMS er. De traditionelle udbydere indenfor betalingssoftware er Oracle, Sybase og Microsoft, mens der i takt med internettets udbredelse er kommet nogle meget anvendte Open Source-produkter på banen. Af de sidstnævnte er MySQL nok mest udbredt, mens de ud fra en teoretisk betragtning langt mere komplette produkter PostgreSQL og Interbase (nu Firebird) er under stigende udbredelse. PostgreSQL er fra Berkeley University, mens Interbase er fra Borland 2. Open Sourceefterfølgeren til Interbase, Firebird, har sin oprindelse hos softwarehuset IBPhoenix. Databasesystemerne er gennem deres understøttelse af det standardiserede sprog SQL 3 også udstyret med muligheder for at begrænse adgangen til hele eller dele af databaser. Ligesom på webserverens muligheder i den retning skal vi også se nærmere på databasesystemets og SQLs faciliteter. Programmeringssprog I World Wide Web-sammenhæng findes en række forskellige programmeringsprog/systemer til rådighed. Med henblik på skabelse af dynamik og til aflusning af data lokalt på browseren inden de sendes ud på nettet er JavaScript og VB-script de mest udbredte. På serversiden er der i tilknytning til webserverne nogle udbredte valgmuligheder, ASP, der ikke er et sprog men et system, bruges meget i Windows/IIS-miljøer, mens Perl og PHP, begge programmeringssprog og begge udsprunget af Open Source-miljøet, er ægte platformsuafhængige. Vi har valgt at bruge PHP i undervisningen på grund af sprogets kvalitet, dets udbredelse, platformuafhængigheden, prisen, samt at det har interface til snart sagt alle mulige DBMS er. Af de samme grunde er det valgt til dette projekt. Programmeringssprogene stiller gennem standardbiblioteker funktioner til rådighed ikke bare for adgang til databasesystemerne, men også til kryptering af data til passwordbrug. Operativsystemer Operativsystemerne er ikke i sig selv interessante med hensyn til sikring af web-applikationers dataintegritet. Indirekte er de selvfølgeligt i fokus fordi de kan være ofre for indtrængen 2 Kendt amerikansk softwarefirma. Leverer udover Interbase bl. a. programmeringssproget Delphi. 3 Structured Query Language, hvis kapacitet dog rækker langt ud over blot forespørgsler.

21 3.2: Kryptering 21 selv, og dermed potentielt danne base for et således lokalt angreb på en servers databasesystemer. I forhold til autentifikation af den direkte databaseadgang gennem web er dette imidlertid også kun af sekundær interesse i dette projekt. 3.2 Kryptering Når sikkerhedsproblematikkerne om et øjeblik skal diskuteres, er det nyttigt at have en løsningsreference på plads. Læseren vil derfor tilgive en digression 4 om kryptografi eller kryptering, som det også kaldes. Müller Larsen (2002) har et kapitel 5 om dette. Kryptering består i at forvanske en tekst, klartekst, til en form, som uvedkommende ikke umiddelbart kan tyde. Den krypterede tekst kaldes ciffertekst. Processen består i, at klarteksten udsættes for en behandling af et program eller en funktion indeholdende en algoritme 6, der foretager en eller anden beregning, der som resultat har cifferteksten. Algoritmen er en standardfunktion, der kræver to argumenter for at kunne udføre sin rolle; en klartekst og en krypteringsnøgle. Dekryptering er den proces en dekrypteringsalgoritme udfører for at forvandle cifferteksten til den rigtige klartekst. Dens argumenter er cifferteksten og en nøgle. Kvaliteten af en given kryptering afhænger af to ting, algoritmens og nøglens kvalitet. Da algoritmen ligger indeholdt i et stykke software er denne ikke hemmelig, så i praksis er nøglens kvalitet altafgørende. Kvalitet betyder her, at den skal være svær/umulig at gætte for uvedkommende Konventionel (Symmetrisk) kryptering Cæsar sendte i sin tid meddelelser ud til sine armeer. For at de ikke skulle kunne læses, hvis de faldt i fjendens hænder, var hvert bogstav/tegn i en meddelelse udskiftet med et tegn fra en anden position i alfabetet. Algoritmen var her forskydning et antal pladser og nøglen var antallet af pladser, fx Forudsætningen for at modtageren kan læse meddelelsen er således, at han har adgang til den spejlvendte algoritme, dekrypteringsalgoritmen, og at han kender nøglen. Symmetrisk kryptering, også kaldet hemmelig-nøgle kryptering, som eksemplet med Cæsars Cipher er et eksempel på, er karakteriseret ved, at afsender og modtager skal have hvert sit eksemplar af samme nøgle. En meget udbredt og anerkendt udgave at symmetrisk krypteringsalgoritme er the Data Encryption Standard, DES. En fordel ved hemmelig-nøgle kryptering er at den er meget hurtig selv ved store datamængder. På grund af fordelen med datamængder er den også særligt anvendelig ved data, der ikke nødvendigvis skal transporteres over et net, idet transporten jo også tager tid. Ulempen ved hemmelig-nøgle er nøgledistributionen selv. Den kan selvsagt ikke ske sikkert over et elektronisk medie, men må ske ved personligt møde. Det fremgår også heraf, at udveksling af hemmelige meddelelser kun kan ske efter forudgående udveksling af nøgler Moderne (Asymmetrisk) kryptering Når der er nævnt et begreb som hemmelig-nøgle kryptering, så fremgår det indirekte, at man også kan kryptere med nøgler der ikke er hemmelige, dvs offentlige nøgler. Det lyder 7. 4 Afstikker. 5 IT kommunikation, kapitel 5. 6 Forenklet betyder algoritme regneregel. Her er det snarere et kompleks af regneregler. 7 Man kan eksperimentere med Cæsars Cipher på klik Lektioner uge

22 22 Kapitel 3: Analyse af relevante sikkerhedsmodeller som en selvmodsigelse, men vi skal se, at vi har et særdeles avanceret og stærkt værktøj i denne asymmetriske kryptering, der også kaldes offentlig-nøgle kryptering. Principperne bag offentlig-nøgle kryptering tilskrives oftest Diffie and Hellman (1976), men nyere information viser, at Ellis (1970) havde arbejdet med det allerede 5 år tidligere. Sidstnævnte kilde var en militær, hemmelig kilde, så der er ingen grund til at tvivle på Diffie og Hellman s originalitet. Efter installation af software til offentlig-nøgle kryptering genererer man et nøglepar, en offentlig nøgle og en privat nøgle. Disse placeres i hver sin fil på computeren. Derefter skal man sørge for at få den offentlige nøgle offentliggjort. I det mindste selvfølgelig til dem, som man ønsker skal kommunikere hemmeligt med en. Der findes et verdensomspændende sæt af servere, der yder den service at opbevare offentlige nøgler. Disse servere indgår i PKI, Public Key Infrastructure. Her kan man forespørge på andres offentlige nøgler. Den offentlige nøgle kan være offentlig af en eneste grund. Den kan alene bruges til at kryptere meddelelser til dens ejermand. En meddelelse krypteret med en offentlig nøgle kan kun dekrypteres med netop den private nøgle, som den blev genereret sammen med. Denne private nøgle holder ejermanden for alt i verden hemmelig. Da den heller ikke skal være kendt af andre skal den ikke formidles til nogen anden. Den forbliver på ejermandens computer, og er beskyttet, ikke bare af et password, men oftest af en hel sætning, en såkaldt pass phrase. Den mest kendte offentlig-nøgle krypteringsalgoritme er måske RSA fra 1978, opkaldt efter sine opfindere, Ron Rivest, Adi Shamir og Leonard Adelmann 8. Fordelen ved denne type kryptering er, udover dens ide, at der netop ingen sikkerhedsproblemer er omkring nøgledistributionen. Den kan ske elektronisk og ubeskyttet. Ulempen er, at offentlig-nøgle kryptering er langsommere end hemmelig-nøgle kryptering. Det kan også vises matematisk, at den er mindre sikker end sit alternativ. Der skal længere nøgler til denne form for at nå samme sikkerhedsniveau som ved hemmelig-nøgle kryptering. Fordelene anses normalt for at overskygge ulemperne. I øvrigt er det muligt at effektivisere omkring hastighed i datakommunikationssammenhæng ved at kombinere hemmelig- og offentlig-nøgle kryptering Nøglerne Forenklet beskrevet består nøglegenereringen i at danne et meget stort tal ved multiplikation af to meget store primtal. Produktet er naturligvis ikke et primtal. En velkendt matematisk læresætning siger, at alle tal, der ikke er primtal kan opløses, dvs udtrykkes som et produkt af et antal primtal. Hvis produktet er den offentlige nøgle, så består den matematiske nød, der skal knækkes, i at gætte hvilken primtalsopløsning, den skal udsættes for, for at få præcist de to store primfaktorer. Den komplette og let forståelige algoritme findes forklaret på web, jf adressen i fodnoten vedrørende RSA. Den private nøgle kan være en af de store primfaktorer, idet den anden så let kan beregnes. I følge Singh (1999) skal vi have primtal i størrelsesordenen for at give tilstrækkelig sikkerhed mod brute force 9 angreb med nutidens computerkapacitet. Den offentlige nøgle vil så blive et tal i størrelsesordenen Dette giver en ide om, hvor store store primtal egentlig skal være. Singhs bog er 5 år gammel, og med udviklingen i processorhastigheder siden da, må det antages at tallene i dag skal være endnu større Anvendelse Meget kort kan det siges, at et moderne krypteringssystem nu kan anvendes til kryptering på tre måder: Systematisk afprøvning af alle muligheder.

23 3.3: Definition af sikkerhedsproblematikken Kryptering med en andens offentlige nøgle. Kan kun dekrypteres af ejeren af den tilsvarende private nøgle. Dette sikrer hemmelighed, konfidentialitet. 2. Kryptering med egen hemmelige nøgle. Kan dekrypteres af alle med adgang til ens offentlige nøgle. Kan den dekrypteres kan den kun hidrøre fra den rigtige private nøgle. Dette er en elektronisk signatur. 3. En kombination af 1 og Definition af sikkerhedsproblematikken I afsnit citeredes en forskningsministeriel rapport for at de fire nødvendige sikkerhedsmæssige krav i netværkssamfundet er: integritet autentifikation uafviselighed konfidentialitet I Stallings (2000) nævnes yderligere: adgangskontrol tilgængelighed Integritet betyder at ingen uautoriserede har ændret de data, der vises for en bruger. Brugerens tillid til integriteten kan sikres på flere måder. Brugeren kan vælge at stole på, at når han er på den web-adresse, så tror han også, at dens data er korrekte. Dette kan suppleres med, at de viste data kan være elektronisk signerede, jf Kan signaturen verificeres, har man lov at stole på datas integritet. Autentifikation som krav omkring retten til at opdatere en databases data skal medvirke til at sikre netop integriteten af disse data. Autentifikation er imidlertid kun en delvis beskyttelse af integriteten. Som nævnt i afsnittet om integritet kan opnåelsen af integritet ske med elektronisk signatur. Det kunne også ske ved kryptering af data med et moderne krypteringssystem. I så fald skulle modtageren igennem en dekrypteringsproces for at kunne få glæde af de modtagne data. Dette vil normalt ikke blive brugt i forbindelse med offentligt tilgængelige data på World Wide Web, men måske snarere i en en-til-en kommunikation af fortroligt materiale fx via elektronisk post. Uafviselighed er ikke her et problem, idet det system, der viser sine data frem, og så identificerer sig selv og altså ikke prøver af nægte at stå bag sine data. Uafviseligheden kan som nævnt bestyrkes ved brug af elektronisk signatur. Konfidentialitet eller hemmeligholdelse er ikke forudsat i den skitserede problembaggrund, snarere netop det modsatte, at en bred kreds skal kunne se data, men kun en snæver kreds kunne rette i data. I nogle web-baserede systemer kan konfidentialitet dog være et ønske. I så fald sikrer autentifikation kun mod, at det ved brug af normale midler kun er autoriserede øjne, der ser data. Ligesom nævnt herover under begrebet integritet, ville vi være nødt til at kryptere data for at sikre os mod at nogle læser over skulderen. De gængse webservere og -browsere understøtter Secure Socket Layer, SSL, en internet-standardiseret metode til kryptering af data, mens de transporteres over internettet, se herunder.

24 24 Kapitel 3: Analyse af relevante sikkerhedsmodeller Adgangskontrol handler om at kunne begrænse og især styre adgangen til de følsomme data på en server. Dette sikres normalt ved autentifikation, som kort blev defineret i Datas tilgængelighed er en forudsætning i et World Wide Web system. Da de leveres af en webserver, med støtte fra en databaseserver, er tilgængeligheden vedrørende disse to servere essentiel. Angreb på tilgængeligheden kan medføre at den går tabt, eller at den reduceres. Dette projekts formål er, som beskrevet i problemformuleringen, at finde en lempelig måde, programmeringsmæssigt og administrativt, hvorpå det kan sikres at kun autentificerede personer kan manipulere data - hemmelige eller ej. Det vil sige, at vi vil regulere tilgængeligheden af vores dataservice afhængigt af brugerens formål med adgang. 3.4 Platformenes generelle tilbud Webserverne Adgangskontrol Man kan sige at webservernes egne muligheder for sikkerhed er, at der kan etableres en slags zoneopdækning, det vil sige, at programmer placeret i bestemte directories, er beskyttede, fx. gennem.htaccess 10, se Garfinkel et al. (2003). Denne beskyttelse er ikke eller kun indirekte dataintegritetsbeskyttelse, det er derimod adgangsbeskyttelse. En bruger får således kun lov til at bruge funktionaliteten, som programmet tilbyder, hvis brugeren gennem fx.htaccess har rettigheder svarende til den zone, hvori programmet er placeret. Denne beskyttelse, som egentlig er afkoblet fra selve programmet, er tvivlsom, idet den kan omgås, hvis programmet kopieres eller flyttes til et ubeskyttet område, som alle har rettigheder til. Secure Socket Layer, SSL Internettets standardisering på området kryptering med HTTP hedder TLS, Tranport Layer Security, specificeret i Dierks and Allen (1999) 11, som den mere officielle efterfølger til SSL, et Netscape produkt der udviklede sig til en industristandard. SSL og TLS er teknikker, der benyttes til at sikre kryptering af trafikken mellem klient og webserver. Web-security og brug af SSL behandles grundigt teoretisk hos både Tanenbaum (2003) og Stallings (2000), samt ud fra en mere praktisk synsvinkel hos Gagne (2002). Netscape udviklede SSL til og med version 3.0 og stillede det til internettets disposition. The Internet Engineering Task Force har siden udviklet TLS, der ofte i daglig tale betegnes som SSL V3.1. I figur 3.1 ses hvordan SSL passer ind i TCP/IP-arkitekturens opbygning. Det skal bemærkes, at figuren benytter de oprindelige danske betegnelser for de enkelte lag i stedet for de tilsvarende betegnelser fra OSI-modellen, der af og til bruges også på TCP/IP. SSL består af nogle underprotokoller. Tanenbaum har en lidt enklere forklaring end Stallings, og nævner to sub-protokoller, en til etablering af en sikker forbindelse mellem klient og server, og en anden til at bruge denne forbindelse. Et resultat af etableringen er, at parterne er udstyret med hver sin udgave af en nøgle, der bruges til henholdsvis kryptering og dekryptering af det som HTTP skal sende. Da netop nøgleudvekslingen i forbindelse med symmetrisk kryptering er en kritisk fase for hemmeligheden, sker denne etablering af den sikre forbindelse under udnyttelse af asymmetrisk kryptering. Dette kan 10 En fil, der beskriver rettigheder. Står vel egentlig for hypertext access. Se fx: 1.html# En glimrende kilde til læsning af Requests For Comments er

25 3.4: Platformenes generelle tilbud 25 Figur 3.1: Illustration af sikkerhedslagets strukturelle placering i protokolstakken gøres fordi alle browsere i følge Tanenbaum har ca 100 offentlige nøgler, som en webserver kan bruge i sit handshake 12 med browseren. Nu kunne man måske fristes til at tro, at når denne proces er ovre, så er det vel autentifikation nok. Men det er selvfølgelig utilstrækkeligt i og med at browseren jo nok er autentificeret gennem denne indledende handshake, men det er brugeren af browseren, som vi er interesserede i. Derfor følger nu den egentlige autentifikation på applikationens betingelser. Det er her, at Authentific skal spille sin rolle. En internet-kommunikation understøttet af SSL eller TLS muliggør brug af HTTPS 13, jf. bl. a. Rescorla (2000) og Fielding et al. (1999). HTTPS er dog reelt ikke en særskilt protokol, men betegnelsen dækker brugen af HTTP over SSL, der oftest sker på serveren ved anvendelse af en anden port (443) end den normale (80). Forudsætningen for at dette nytter er imidlertid, at programmøren er bevidst om samspillet mellem HTTP, dennes metoder GET og POST, og SSL. World Wide Web Consortium har nogle tommelfingerregler 14 desangående, som det kan være nyttigt at referere til, både specifikt sikkerhedsmæssigt og generelt. Med disse hjælpemidler er der ingen undskyldning for ikke at beskytte både en brugers personlige data under transport, og virksomhedens data mod at nogen får udbytte af at lytte med på nettet. Til almindelig informationsbrug af offentligt tilgængelig information er der ingen grund til at kryptere. Da, bredt sagt, alle browsere understøtter SSL, er det et server- og applikationsanliggende om det kan udnyttes. Serverne understøtter det, men det skal aktiveres i serveren. Applikationen skal vide, at det er der, og så benytte benytte det eller tilbyde brugeren valget af at benytte det. Ethvert sikkerhedssystem er ikke stærkere end sit svageste led. I forbindelse med autentifikation er det svage led transport af bruger-id og password fra de er indtastede på klienten indtil de er fremme hos serveren. Dette kan og bør ske med SSL. Sker det ikke vil denne transport fremstå som autentifikationssystemets Achilles-hæl. 12 Etablering af forbindelse, herunder aftaler om metoder. 13 Secure HTTP 14

26 26 Kapitel 3: Analyse af relevante sikkerhedsmodeller Databasesystemerne Standardmuligheder for rettigheder Ved definition af tabeller i en relationel database ved hjælp af SQLs CREATE TABLE sætningen opnås automatisk mulighed for adgang til forekomsterne i den oprettede tabel, men kun for den bruger, der opretter tabellen. Skal andre have rettigheder i forhold til en tabel, må ejeren uddele sådanne rettigheder. Der sker ved hjælp af en anden SQL-sætning, nemlig GRANT. Lad os se et eksempel: 1: CREATE ROLE ADMINBRUGER; 2: CREATE ROLE GEMENBRUGER; 3: GRANT ADMINBRUGER TO NML; 4: GRANT GEMENBRUGER TO NOBODY; 5: GRANT ALL ON GRUPPE to NOBODY; 6: GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON BERIG TO ROLE ADMIN- BRUGER; 7: GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON BERIG TO ROLE GEMEN- BRUGER; Nummereringen af linierne er ikke en del af SQL-koden, men alene tilføjet for referencens skyld. En helt almindelig GRANT-sætning ses i eksemplets linie 5. Nøgleordet ALL ses fx. i linie 6 og 7 oversat til DELETE, INSERT, SELECT, UPDATE, REFERENCES. Det er muligt at nøjes med at tildele enkelte af disse 5 rettigheder i en GRANT-sætning. Rettigheder kan i stedet for en bruger tildeles en ROLE, som er SQLs gruppebegreb. Er det sket opnår enkeltbrugere rettigheder enten ved en yderligere GRANT af rettigheder i forhold til tabellen, eller ved at brugeren meldes ind i en ROLE. Dette kan ske ved en GRANT med en lidt anden syntaks, nemlig som vist i linierne 3 og 4. Disse to linier er eksempler på at NML og NOBODY meldes ind i henholdsvis ADMINBRUGER og GEMENBRUGER. Disse to ROLEs skal i forvejen været oprettede, hvilket i eksemplet er sket i linie 1 og 2. I eksemplet har både NML og NOBODY alle rettigheder til tabellen BERIG i begge tilfælde gennem deres medlemsskab af de nævnte ROLEs. Både ROLEs, GRANT og REVOKE, der bruges til at fratage rettigheder, er, jf. Kline and Kline (2001), standardiserede elementer af SQL:1999 standarden. SQL. Den nyeste, SQL:2003, laver ikke om på dette. Imidlertid er ROLE ikke introduceret i mange af DBMS erne, hvilket kan gøre den administrative byrde tungere for en databaseadministrator, der så må styre flere individuelle adgangsrettigheder. DBMS-klientadgang, native adgang Ved en DBMS-klient forstås et program, der har direkte terminaladgang til DBMS ets SQL-fortolker og ad den vej til manipulation af en databases data. På baggrund af mulighederne med ROLE, GRANT og REVOKE er det også muligt at sikre, at kun den, der i et DBMS-klientprogram kan autentificeres som en bruger (user) med rettigheder, kan få adgang til at manipulere tabellernes data i overensstemmelse med disse rettigheder. I den type drift er det således muligt at give en bruger særlige administrator-rettigheder, mens en anden bruger fx kun har læse (SELECT)-adgang til data. Det kan nævnes, at Date (2000b) behandler GRANT i sit kapitel om sikkerhed 15, og kun der. En tilsvarende holdning finder vi hos Elmasri and Navathe (2000). I begge disse 15 Kapitel 16.

27 3.5: Autentifikation 27 værker diskuteres også anvendelsen af VIEWs til at skjule visse følsomme attributter i tabeller fra nogle brugere. Dette er i denne sammenhæng kun af sekundær interesse, da det primære formål er at begrænse adgangen til at manipulere data, ikke til at få data vist frem. Da adgang gennem et databasesystems klientprogram ikke er forbeholdt brugere, der er lokale i forhold til en given installation, men sagtens kan forekomme via en internet-adgang, er der et behov for beskyttelse mod netadgang via klientprogrammet. Dette kan etableres ved beskyttelse mod adgang via det portnummer, som klientadgangen kræver, undtagen fra visse arbejdsstationer identificeret ved fx. IP-nummer. Denne beskyttelse er derfor en adgangsbeskyttelse, der etableres via netværksadministrative sikkerhedsaktiviteter, og den vedrører altså ikke den konkrete web-applikations data eller funktionalitet Programmeringssprog Web-klientadgang Web-klienten er en browser, der også kan kaldes en general-klient på World Wide Web, idet den jo ikke er knyttet til en bestemt applikation, men benyttes i alle mulige applikationer. Web-klienten har kun indirekte adgang til en database. Adgangen går gennem et program, der afvikles på en web-server, oftest programmeret i et moderne script-sprog, fx PHP. Web-programmet skal imidlertid for at opnå adgang til en database foretage en såkaldt connect til databaseserveren, DBMS et. Denne connect svarer helt til den autentifikation, der blev nævnt ovenfor i afsnittet om DBMS-klientadgang. Man kan sige, at webprogrammet ikke er andet end en umenneskelig bruger med en autentifikation, som jo nødvendigvis må være skrevet i programmet, hvis ikke hver bruger skulle have sit eget program. Fordelen ved dette er, at der kun skal skrives et enkelt program til at foretage en bestemt databasetransaktion, og ikke et per bruger. Ulempen er herefter, at den der har adgang til programmet, har adgang til databasen og kan foretage den transaktion, som programmet kan foretage. Da afstanden til et web-program jo ikke er større end kendskab til en URI 16, kan man lidt bredt sige, at alle principielt har adgang. Med andre ord er det hermed godtgjort, at databasesystemets sikkerhedsmekanisme med GRANT ede rettigheder, eventuelt gennem ROLEs, ikke er en tilstrækkelig beskyttelse mod uautoriseret adgang til en web-tilgængelig database. Der må mere til. Der er altså brug for yderligere et sikkerhedslag, og det skal tilvejebringes gennem et programmeret og selv databasebaseret autentifikationssystem. 3.5 Autentifikation I problemformuleringen defineredes autentifikation således: Autentifikation betyder, kort og uformelt defineret, at man identificerer sig med et bruger-id og beviser sin identitet ved at kende et kodeord, et password. I dette kapitel er definitionen sat ind i en sikkerhedsmæssig ramme. Vi har set at webservernes generelle tilbud ikke er finmasket nok til vores formål, og derved har vi godtgjort behovet for en programspecifik autentifikation. På tilsvarende vis har vi set andre muligheders mangler i forhold til et egentligt autentifikationsmodul. Et autentifikationsmodul skylder hertil brugeren, at han kan have tillid til, at det password, som han får udleveret, eller det som han senere ændrer det til, bliver behandlet på betryggende vis. Det betyder to ting. 16 URI: Uniform Resource Identifier, identifikationen af en ressource på WWW. Tidligere kaldet URL, jf

28 28 Kapitel 3: Analyse af relevante sikkerhedsmodeller Passwords transporteres ikke i klartekst, så uvedkommende ved sniffing 17 kan få kendskab til dem. Autentifikationssystemet er selv sikret. Authentific bør kunne sikre sig selv. Førstnævnte har vi allerede set på, idet det kan håndteres ved at anvende SSL på webserveren, og samtidig sikre, at webapplikationen bruger HTTPS på autentifikations-siden. Sidstnævnte vil produktet demonstrere. Brugeren har hertil også et par praktiske krav: 1. Når brugeren har autentificeret sig, så gælder autentifikationen indtil han selv ophæver den ved at logge ud. 2. Autentifikationen skal ophæves automatisk, hvis brugeren glemmer at logge ud. Punkt 1 indebærer, at programmeringen må imødegå det man kalder World Wide Webs Statelessness, det at en webside ingen ide har om, at man var der for et øjeblik siden, og at man måske kommer tilbage om et øjeblik. Dette kan sikres ved anvendelse af såkaldte sessions-variabler, en hukommelsesmekanisme hvor information opbevares på server og klient i cookies på tværs af en række dialogskridt. Denne mekanisme understøttes af både HTTP og det valgte programmeringssprog PHP 18 jf Lerdorf (2004) og afsnittet om sessioner i Det andet punkt løses ved at give de under punkt 1 nævnte cookies en forældelsetid, der skal sættes til et niveau, der gør at man kan være borte fra terminalen et par minutter, men samtidig ikke støtter, at terminalen kan stå længe med autentifikation uden at blive brugt af den rette bruger. En sådan mekanisme er understøttest af programmeringssproget PHP. 17 Uberettiget medlytning på en internetforbindelse. 18 Se om PHPs Session Handling Functions.

29 Kapitel 4 Analyse og udvikling af løsning Do not simplify the design of a program if a way can be found to make it complex and wonderful. Unknown (UNIX Fortune) 4.1 Authentifics ide og datamodel Det blev nævnt i afsnit 3.4.3, at autentifikationssystemet vi er i gang med, skal være databasebaseret. Da vi taler om brugerautentifikation skal vi have opstillet en model, der afspejler både brugere og de programmer, hvis datahåndtering vi vil beskytte. Dette er projektets ene hovedopgave. Den anden hovedopgave er at sikre, at ethvert program, der skal beskyttes, kan opnå denne beskyttelse ved at kunne referere til selve autentifikationsfunktionaliteten, der selv bygger på en database. Man kan sige, at målgruppen for Authentific er programmer, der stiller sig under Authentifics beskyttelse ved at indbygge dens funktionalitet, herunder også programmer, der permanent eller midlertidigt tillader adgang for alle. Heroverfor står programmer, der ikke indbygger Authentific. Sådanne programmer nyder ingen beskyttelse gennem dette system. Sikring med autentifikation af Authentifics egen funktionalitet er måske en selvfølge. Kun en sluttet kreds skal have adgang til Authentifics data. Der er dog en delvis undtagelse hertil. Der skal tilvejebringes et modul, hvorfra brugeren kan ændre sit eget password. Dette skal brugeren kun kunne gøre mod autentifikation med sit gamle password Den første skitse Skal vi se på en organisation, der har webapplikationer, som en integreret del at sine ITapplikationer, så er der et antal medlemmer af organisationen. Disse medlemmer har hver især gennem sine arbejdsopgaver adgang til en række programmer i disse applikationer. Da samtidig hvert program muligvis kan udføres af en række medarbejdere, har vi den klassiske mange-til-mange situation. Diagrammet i figur 4.1 viser situationen, der logisk set er ganske simpel. Diagrammet er et ER-diagram, et Entity-Relationship-diagram. ER er en metode til begrebsmæssig datamodellering, der stammer fra Chen (1976). Teorien om overgang fra ER-model til relationel model tilsiger at en N-M-relation altid vil blive afbildet som en tabel. Denne afbildning undgår både null-værdier og redundans i den resulterende database. Da samtidigt de to entiteter, Bruger og Program bliver til tabeller i relationsdatabase, ender dette udsnit af den med at indeholde tre tabeller. Teorien bag mapning af ER-modellen til den relationelle model er beskrevet i Elmasri and Navathe (2000) og også, under navnet reduktion, i Rønnow and Jacobsen (1989), en holdbar dansk kilde til begrebsmæssig datamodellering. 29

30 30 Kapitel 4: Analyse og udvikling af løsning Figur 4.1: Den første ide. Navnet reduktion sigter til, at ikke alle ER-diagrammets relationer ender som tabeller i databasen. De reduceres væk, idet deres semantik afspejles på anden vis i databasen. Har vores web-applikationen 50 programmer, der hver især har 10 brugere vil der i tabelafbildningen af MaaUdfoere være 500 tupler (rækker). Den afbildede del af databasen vil altså i alt have mindst 560 rækker i de tre tabeller, mindst 10 brugere, 500 i MaaUdfoere og 50 programmer. Hvis brugertabellen indgår i andre relationer kan denne have flere rækker, der ikke har deltagere i MaaUdfoere En anden mulighed Med tanke på nuanceringen af rettigheder. som de findes i DBMS ets ROLEs og users, altså brugere og grupper, mangler den første skitse et gruppebegreb. Lad os derfor prøve en anden mulighed. Ideen om gruppering af brugere i forhold til rettigheder til objekter er ikke unik for databasers tabeller. Vi genfinder den blandt andet i operativsystemet UNIX filsystem. En fil i UNIX, og således også i de nye UNIX-varianter, Linux og BSD-varianterne, har et lignende rettighedsmønster. Da programmer i UNIX blot er filer, var det nærliggende at prøve at modellere rettighederne for webprogrammer på lignende måde. Se på følgende: -rwxr-xr-x 1 nml admin Nov 6 14:21 prove Det interessante her er de fire fremhævede områder. Længst til højre har vi prove, programmets navn. Længst til venstre har vi ti tegn, der grupperet læses som følger: Først et -, der siger, at vi har med en almindelig fil at gøre. Almindelig i forhold til et directory eller en specialfil, fx en device-driver. Dernæst har vi tre gange tre tegn, der hver kan være rwx, evt en - på en af pladserne. Tegnet r betyder read, læse-rettighed, filen må læses. Tegnet w betyder write, skrive-rettighed. Filen må ændres. Sidst og i denne kontekst vigtigst, x betyder execute. Ret til at udføre filen som et program. De tre grupper af rwx refererer til henholdsvis ejer, gruppe og andre fra venstre mod højre. De sidste to fremhævelser er identifikation af henholdsvis ejerskab og gruppetilhørsforhold. Brugeren nml ejer programmet, og dets grupperettigheder er associeret til gruppen admin. Figur 4.2 viser en konceptuel datamodel, der er bygget op over disse ideer. Program tilhører henholdsvis gennem relationerne gtilp og btilp en gruppe og en bruger (ejer). Brugere kan være medlemmer af fra nul til flere grupper, og en gruppe kan have fra nul til mange medlemmer. Således er berig (bruger er i gruppe) en mange-til-mange relation som vi også så et eksempel på i figur 4.1. I dette diagram er også tegnet en svag entitet glpword, beregnet til brugte passwords. Den er relateret til bruger gennem en identificerende relation havde. Denne del af diagram-

31 4.1: Authentifics ide og datamodel 31 Figur 4.2: ER-diagram over authentific -datamodellen. met kunne også have været anvendt i den første ide. Tanken bag er, at systemet skulle kunne opbevare tidligere anvendte passwords, så der er en praktisk mulighed for at hindre brugerne i at genanvende passwords. I og med at en brugerentitet er forsynet med en dato for oprettelse af password, upwdato, er det muligt at kombinere dette med en levetid for passwords, og derved tvinge brugerne til regelmæssige skift af passwords. I overensstemmelse med teorien for overgang fra ER- til relationel model får vi fem tabeller ud af diagrammet, nemlig program, gruppe, berig, bruger og glpword. De fire førstnævnte er nødvendige for en implementering, der skal afspejle projektets ide, mens man kunne udskille implementeringen af upwdato til en senere lejlighed. Skal vi se på tallene for at sammenligne med den første ide, kan vi holde fast i de 50 programmer og de 10 brugere. Lad os antage, lidt urealistisk, at vi har de 10 brugere grupperet i 10 grupper. Det medfører at databasen får 50 programmer, 10 grupper 100 berig -er og 10 brugere, i alt 170 rækkeforekomster. Samtidig er modellen mere nuanceret end den første ide, idet de 10 brugere gennem gruppejerskab kan have rettigheder til de samme 50 programmer som i første ide, og det for en lavere databasemæssig omkostning. Betydelig færre forekomster giver betydeligt mindre administration af adgangssikkerheden. Selv om sikkerhed er så vigtig, at det er en selvstændig opgave, må opgaven gerne kunne løses omkostningsbevidst. Det er på den baggrund valgt at implementere den anden mulighed Normalisering En sund database hævder Elmasri and Navathe (2000), er en database, hvor relationerne, tabellerne, er normaliserede på mindst 3. normalform. Men vi er i den valgte model i stand til at opfylde 5. NF. Normalisering er en kompleks procedure, der sigter mod at undgå redundans og null-værdier i databasen, idet disse begrebers forekomst ville give anledning til henholdsvis unødig ekstra administration af databasens indhold og usikkerhed

32 32 Kapitel 4: Analyse og udvikling af løsning om betydningen af dele af databasens indhold. Der findes seks normalformer, der medfører stigende designkrav til databasens tabeller. De seks normalformer er nummereret fra 1-5(!) Grunden til denne anomali, der at der mellem 3. og 4. NF er placeret BCNF. Boyce-Codd Normal Form, BCNF, opstod på et tidspunkt som et forsøg på at forbedre formuleringen af 3. normalform. Det viste sig så at den nye formulering faktisk kan vises at være et strengere designkrav end 3. normalform. Date (2000a) har historien om dette. Enhver normalform stiller nogle krav til tabeller, således at disse tabeller som overholder en normalform er en ægte delmængde af de tabeller, der opfylder en lavere normalform. De tre første normalformers definitioner bygger hver på sin forgængers definition og stiller yderligere et strengere krav end denne til tabellens design. Derimod er Boyce-Codd normalformen enkeltstående, og dens definition, at alle determinant-attributter skal være kandidatnøgler, er oprindeligt opstået som en fornyet definition af 3. normalform, men man har senere kunne vise, at den er et strengere krav. Med andre ord hvis tabellerne overholder BCNF, er databasen godt designet. At vi kan nå op på 5. normalform her skyldes en vis automatik, idet 4. og 5. normalform omhandler problemer med tabeller med sammensatte og indbyrdes overlappende kandidatnøgler, og da vi ikke har sådanne, har vi heller ikke disse eventuelle problemer. De tabelskitser, som normaliseringen er foretaget på, fremgår af figur 4.2 idet attributnavnene er indført i diagrammet Authentifics data dictionary Den konkrete implementering af ER-diagrammet mappet til en relationsdatabase fremgår af SQL-koden i appendiks A. Dette appendiks viser de definerede domæner og tabeller. Da attributnavne og deres datatype er en lidt abstrakt præsentation skal felterne her opremses med en kort forklaring til hver: CREATE DOMAIN ADR AS VARCHAR(64); // -adresse, 64 tegn CREATE DOMAIN KOMMENTARER AS VARCHAR(256); // tekstfelt, 256 tegn CREATE DOMAIN NAVNEFELT AS VARCHAR(40); // tekstfelt, 40 tegn CREATE DOMAIN PASSWD AS VARCHAR(40); // felt til password i SHA1-format CREATE DOMAIN PROGRAMNAVNE AS VARCHAR(32); // felt til programnavne, 32 tegn CREATE DOMAIN RWX AS INTEGER // rettigheder til fil check (value between 0 and 7); // 1=execute, 2=write, 4=read. Kan kombineres. CREATE DOMAIN STINAVNE AS VARCHAR(48); // felt til stinavne, 48 tegn CREATE DOMAIN TEGNID AS VARCHAR(8); // tekstfelt til nøgle CREATE DOMAIN TIDSSTEMPEL AS TIMESTAMP; // datotidsgruppe for fødsel af password CREATE TABLE BRUGER ( UID TEGNID NOT NULL, UPWORD PASSWD NOT NULL, UPWDATOTID TIDSSTEMPEL NOT NULL, UFORNAVN NAVNEFELT NOT NULL, UEFTERNAVN NAVNEFELT NOT NULL, U ADR NOT NULL, PRIMARY KEY (UID) ); // primærnøgle, tekst, eneste kandidatnøgle // dato for oprettelse/ændring af password CREATE TABLE GRUPPE ( GID TEGNID NOT NULL, GNAVN NAVNEFELT NOT NULL, PRIMARY KEY (GID) ); // primærnøgle, tekst, eneste kandidatnøgle CREATE TABLE BERIG ( GID TEGNID NOT NULL, // del af primærnøgle, tekst UID TEGNID NOT NULL, // del af primærnøgle, tekst PRIMARY KEY (GID, UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID), // GID er også fremmednøgle, peger på gruppe

33 4.2: Authentifics anvendelsesarkitektur 33 FOREIGN KEY (UID) REFERENCES BRUGER (UID) ); // UID er også fremmednøgle, peger på bruger CREATE TABLE PROGRAM ( PATH STINAVNE NOT NULL, // primærnøgle 1, programmets sti på webserver PID PROGRAMNAVNE NOT NULL, // primærnøgle 2, programmets navn UID TEGNID NOT NULL, // programmets ejer (user) URWX RWX NOT NULL, // ejerens rettigheder, jf domæne RWX GID TEGNID NOT NULL, // gruppeejerskab GRWX RWX NOT NULL, // gruppens rettigheder ORWX RWX NOT NULL, // rettigheder for alle andre BESKRIVELSE KOMMENTARER NOT NULL, // tekstbeskrivelse PRIMARY KEY (PATH, PID), FOREIGN KEY (UID) REFERENCES BRUGER (UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID) ); // en brugers brugte passwords // del af primærnøgle, bruger-id // del af primærnøgle, gyldig fra- // det gamle password i SHA1-format // fremmednøgle peger på bruger CREATE TABLE GLPWORD ( UID TEGNID NOT NULL, UPWDATOTID TIDSSTEMPEL NOT NULL, dato for gl password UPWORD PASSWD NOT NULL, PRIMARY KEY (UID,UPWORD), FOREIGN KEY (UID) REFERENCES BRUGER (UID) ); De ukommenterede linier er forklarede i de tilsvarende domænedefinitioner øverst i listen. 4.2 Authentifics anvendelsesarkitektur I navigationsdiagrammet i figur 4.3 er givet en skematisk fremstilling af Authentifics virkemåde. Fra en menu vælges et program ved tryk på en knap eller et link. Det kaldte program nås via stien (1). Dette program ved nu selv, i kraft af sin kode, om det kræver autentifikation, identifikation af bruger med brugerid og password. Kræves autentifikation (2) vil Authentific konstatere gennem sin anvendelse af cookies, om brugeren allerede har afgivet bruger-id og password. Er dette tilfældet forsøges med disse informationer, ellers afkræves autentifikation (3). Kan brugeren autentificeres, returneres til det ønskede program (4), og programmet udføres (5). Kan brugeren ikke autentificeres, forblives i autentifikationsmodulet (3). Applikationen kan evt forlades herfra. Kræver programmet ingen autentifikation vil det blot blive udført. Ønsker en bruger at logge ud (6) udføres deautentifikationsprogrammet, der ophæver aktuelle cookies, hvorefter brugeren sendes retur til menuen (7). Authentifics centrale komponenter er således den kodestub, der skal anbringes i ethvert program, der skal kræve autentifikation, selvfølgelig selve autentifikationsmodulet, og dets modstykke deautentifikationsmodulet. De 3 komponenter gennemgås her, De vises (også) i deres helhed i bilaget i appendiks B. 4.3 Authentifics tre hovedkomponenter Autentifikations-stub auth implement.inc Dokumentet auth implement.inc, der herunder vises i sin helhed, er den kode der er nødvendig i hvert PHP-program, der skal beskyttes af Authentific. Med henblik på at gøre implementeringen endnu mere praktisk end at kopiere den viste kode ind i alle ønskede programmer, er koden samlet i en såkaldt include-fil, hvorfor kun følgende skal indsættes som de første 3 linier i hvert program, der ønskes beskyttet:

34 34 Kapitel 4: Analyse og udvikling af løsning Figur 4.3: Skematisk navigation. include (../support_auth/auth_implement.inc ); Færre kodelinier kan man næppe forestille sig. De viste PHP-tags kan selvfølgelig udelades, hvis starten af de relevante programsourcefil i forvejen er i PHP-tags. En så simpel tilføjelse af kode vil uden besvær kunne udføres automatisk af en streng-editor. auth implement.inc indeholder følgende kode: session_name("authentific_nml"); session_start(); if(!isset($_session[ authenticated ]) $_SESSION[ authenticated ]!= TRUE) { //authenticated? $nyqs = "?target="; //no, go and do it $nyqs.= $PHP_SELF; $nyqs.= "&"; $nyqs.= $_SERVER[ QUERY_STRING ]; header("location: $nyqs); $_SESSION[ authenticated ] = FALSE; //yes, reset and use it Koden starter med at påkalde sig den session 1, som den måtte være en del af. Er der ikke oprettet nogen session med det viste navn, sker det herved. Autentifikationen skal principielt altid kalde autentifikationsmodulet authenticate.php, se afsnit Der er dog den ene undtagelse, at kommer vi lige netop derfra med en autentifikation i hånden, så skal programmet selvfølgelig blot afvikles. De parametre, som programmet selv modtog, gemmes i en variabel, så de kan genetableres gennem returneringen fra autentifikationsmodulet, idet de ellers ville gå tabt under omvejen omkring autentifikationsmodulet. Den sidste linie i auth implement.inc nulstiller switchen, der godtgør, at der er autentificeret. Dette gøres med henblik på at sikre, at et eventuelt senere program ikke 1 Sessioner i PHP er yderligere forklaret i afsnit

35 4.3: Authentifics tre hovedkomponenter 35 automatisk arver en autentifikation, som der måske ikke er belæg for i autentifikationsdatabasen Autentifikationsmodulet authenticate.php Når de programmer, der skal kræve autentifikation har fået indsat den netop beskrevne kodestub, er det herefter selve autentifikationsmodulet authenticate.php, der foretager det hårde arbejde. Modulet er ikke specielt omfattende, men dog trods alt af en størrelse og især af en karakter, der tilsiger, at den komplette kode bedst kan læses i bilaget i appendiks B, mens det her skønnes mere overskueligt at gennemgå modulets logik i form af følgende pseudokode: 0. Start den navngivne (authenticate_nml) session, og inkluder filer med database-abstraktionslag, og database-funktioner. Det kaldte programs navn opdeles i sti og navn. Med henblik på at lette databaseopslag. Sæt autentifikations-switch til ikke autentificeret Forbindelse etableres til authentific databasen. 1. Læs i databasen om programmet er tilgængeligt for alle Er dette tilfældet sættes autentifikations-switch til autentificeret. Hvis programmet har bruger-id og password. gemmes disse, ellers bruges dummy-værdierne nobody og test. 2. Opnåedes autentifikation under 1 springes til punkt 5. Opnåedes ikke autentifikation under 1. læses i databasen om den givne bruger-id/password har adgang til programmet som ejer. Er dette tilfældes sættes autentifikations-switch til autentificeret. Bruger-id og password gemmes. 3. Opnåedes ikke autentifikation under 2. læses i databasen om den givne bruger-id/password har adgang til programmet gennem et gruppemedlemsskab. Er dette tilfældet sættes autentifikations-switch til autentificeret. Bruger-id og password gemmes. 4. Opnåede vi ikke autentifikation gennem 2. eller 3. slettes autentifikations-switch og evt. gemte bruger-id og password. 5. Dette sted i programmet nås fra enten punkt 1. eller punkt 4. Det konstateres om der er opnået autentifikation. Hvis der er autentificeret, returneres til det kaldende program, der kan udføres. Hvis der ikke er autentificeret: 6. En XHTML-formular sendes til brugeren med opfordring til at indtaste bruger-id og password. Når brugeren har svaret returneres til starten af dette modul (authenticate.php), der så vil gentage den her beskrevne procedure. Sessioner Sessionsmekanismen er som tidligere nævnt et fænomen, der sikrer, at en dialog mellem bruger og webserver kan opfattes som stateful i modsætning til WWWs normale state-

36 36 Kapitel 4: Analyse og udvikling af løsning lessness. Stateful betyder her, at hele dialogen fra første program, der udsteder en session start() funktion, og indtil denne session afsluttes, kan tildeles en fælles hukommelse, hvilket ikke er standardopførslen i WWW. Denne fælles hukommelse realiseres gennem såkaldte sessions-variabler, der i det valgte server-side-programmeringssprog, PHP, opbevares samlet i et array under navnet $ SESSION. Ved session start() oprettes en cookie på både server og klient. På serveren er denne cookie et objekt i serverens filsystem, identificeret så webserveren kan genfinde det. I denne fil findes $ SESSION. Hos klienten opbevares en partner til den nævnte cookie. Dennes formål er at sikre forbindelsen til den rette server-cookie. De er identificeret ens. Opbevaringsmåden hos klienten varierer fra browser til browser. PHP forsyner per default sine session-cookies med en levetid, der rækker indtil browseren lukkes. Standardindstillingen kan konfigureres, ligesom indstillingen kan ændres programmatisk. Når en session lukkes med session destroy() vil serverens cookie blive slettet. Klientens modpart hertil må afvente en brugeroprydning. Da den ikke længere har en modpart på serveren er den nytteløs og indebærer ikke nogen sikkerhedsrisiko Deautentifikationsmodulet deauthenticate.php En del af sikkerheden omkring autentifikation tilvejebringes af brugerens vilje til at udføre en logout, når han i en periode ikke sidder ved sin arbejdsstation. Efter logout kan en tilfældig forbipasserende ikke benytte den login, der måtte være foretaget på arbejdsstationen. Foretages ikke en eksplicit logout, vil PHP-installationen på den givne webserver skulle bruge sin tilbagefaldsværdi for levetid for sessioner. Det vil være formålstjenligt, at denne levetid ikke er sat for højt, og under alle omstændigheder, at den ikke er sat til uendeligt, hvilket vil sige indtil browseren lukkes. session_name("authentific_nml"); session_start(); $_SESSION = array(); session_destroy(); header("location: //don t forget the name //connect to session //kill its vars //kill session //redirect to menu Koden påkalder sig den session, som den er en del af. Dennes sessionsvariabler slettes, hvorefter sessionen fjernes. Processen afsluttes med at deautenticate.php redirigerer brugeren til et menubillede. Arbejdsstationen kan herefter ikke komme i kontakt med programmet uden en fornyet autentifikation fra brugeren Databaseabstraktion I starten af pseudokoden for authenticate.php nævnedes et database-abstraktionslag. Vi skal i dette afsnit diskutere mulighederne for at opnå denne abstraktion. Det skal dog først slås fast, at med databaseabstraktion menes, at det skal være muligt at skifte databaseserveren, DBMS et, ud med en anden, uden at det må få indflydelse på hverken det beskyttede programs eller authentificate.phps funktionalitet, og uden at der skal foretages ændringer i programkoden. En af PHPs styrker er, at sproget har native support for en lang række DBMS er. Native support betyder, at der er særlige funktioner til hvert DBMS. Funktionerne til arbejdet med Interbase/Firebird databaser benævnt med ibase som præfix, ibase query(), hvor den tilsvarende til brug med PostgreSQL hedder pg query(). Det er klart, at bruger man denne kode til databaseaktiviteten fra programmet, så er man nødt til at ændre koden, hvis DBMS et skiftes ud.

37 4.3: Authentifics tre hovedkomponenter 37 Den valgte metode I dette projekt er der indskudt et databaseabstraktionslag i koden. Det fungerer på den måde, at alle native support databasefunktioner er fjernet fra den egentlige programkode, hvor de er erstattet med kald til egne funktioner. Med andre ord, hvor man ellers ville finde et funktionskald, som ibase query($sql), vil man i stedet finde kald til query($sql). Funktionen query() er af egen tilvirkning, og i denne funktion vil man finde det egentlige databasekald. Funktionen query() er en del af databaseabstraktionslaget. Alle nødvendige databasefunktioner er således samlede i egne tilsvarende funktioner, der samlet stilles til rådighed for authenticate.php som databaseabstraktionslag implementeret gennem en include-fil. Ideen er nu, at der etableres et antal includefiler til hver sin af et ønsket antal DBMS er. I projektet er i første omgang kun etableret grænseflade til Interbase/Firebird og til PostgreSQL. I en eventuel leverance af Authentific skal valget mellem disse DBMS er realiseres gennem konfigurering af det herunder viste stykke kode dbauth setup.inc: $DBMSa = "firebird"; // navn på DBMS $DBMSb = "postgresql"; // navn på DBMS $implemnt = $DBMSb; // valgt DBMS $dbnml = "authentific"; $path = "localhost:/usr/local/webroot/databases/"; $username = "nobody"; $password = "test"; if ($implemnt == $DBMSa) { // inkluder valgt abstraktionslag $host = $path. $dbnml; include("../support_auth/db_funktioner_firebird.inc"); else if ($implemnt == $DBMSb) { $host = $dbnml; include("../support_auth/db_funktioner_postgresql.inc"); else { $host = ""; Der er, som allerede nævnt, indtil videre kun realiseret de i koden viste to abstraktionslag. Deres indhold er vist i bilag i appendiks B.4. En alternativ mulighed En alternativ mulighed til den netop beskrevne form for databaseabstraktion vil være at vælge ODBC som middleware 2. ODBC, som betyder Open Database Connectivity, er en industristandard, og et eksempel på serverspecifik middleware, idet det kun understøtter databaseaktivitet. I den konkrete situation er der imidlertid to aspekter, der går imod valget af ODBC, selvom både PHP og de to nævnte DBMSer understøtter det. ODBC er leverandørspecifik, og netop derfor kun en industristandard. Den har vundet vid udbredelse, men ingen kan garantere for at Microsoft, som er leverandøren, ikke finder på at ændre ODBC. Det andet punkt er, at et af dette projekts mål netop var at undersøge muligheden for selv at etablere databaseabstraktion. 2 Middelware is a vague term that covers all the distributed software needed to support interactions between clients and servers. Citat fra Orfali, Harkey and Edwards (1996).

38

39 Kapitel 5 Evaluering af metode In retrospect, lacking that theory and that language hampered us in two ways. First: we couldn t think systematically about how to improve our own methods. Second: we couldn t explain or sell the method to anyone else. Eric S. Raymond 1 Da valget af projektmodel er beskrevet i kapitel 2, skal her kort redegøres for forløbet med b-modellen, og herunder også med den af Rønnow and Jacobsen (1989) beskrevne datadrevne systemudviklingsmetode. 5.1 b-modellen Formuleringen af domænebeskrivelsen og problemformuleringen kan betragtes som svarende til b-modellens første faser, 1 og 2, jf det nævnte kapitel. Disse aktiviteter kan siges at udgøre forundersøgelsen. Fra og med fase 3, i figurens sprogbrug, er fulgt en spiralformet bevægelse, hvor hver iteration af spiralen har indeholdt overvejelser, der enten direkte er formuleret i nærværende rapport, eller i stikordsform som arbejdspapir. Denne klargøring er i hver iteration fulgt af en udviklingsfase, en implementeringsfase i testmiljøet og derefter en test. I det omfang en test har afsløret konkrete programmeringsmæssige problemer er disse rettet med det samme. Har analysen af testresultaterne vist andre end programmeringsproblemer, har projektet begivet sig ud i en ny iteration på baggrund af analysen. Den første hovedrunde gennem spiralen bestod i etablering af en ordentlig datamodel og begrundelserne for den. Modellen blev implementeret og aftestet gennem DBMS ets lokale klientprogram. Næste iteration var etablering af Authentifics administrative programmel, der var nødvendigt på det tidspunkt for at have materiale til den systemtest, der skulle komme senere. Allerede i denne iteration skete en ændring af datamodellen foranlediget af en brugerovervejelse af helt praktisk art. I anden runde opstod også erkendelsen af nytten af at anvende PHPs objektorienterede muligheder til effektivisering af programmeringen, jf afsnit 6.2 og bilaget i appendiks D. En yderligere følge af denne erkendelse blev, at et testscenario etableredes med et lille webbaseret system, der også siden vil kunne bruges i en konkret undervisningssituation med andre formål end at undervise i autentifikation og sikkerhed. Tredie iteration var klargøringen af de tre elementer, der er kaldt Authentifics kærnekomponenter. Fjerde iteration var en systemtest, der i øvrigt afslørede at foranalysen af autentifikationssekvensen i authenticate.php havde været for lemfældig, hvorfor denne kom- 1 Citeret fra Memes and Mythmaking. Se esr/writings/cathedral-bazaar/hackerrevenge/ar01s03.html 39

40 40 Kapitel 5: Evaluering af metode ponent måtte nytænkes og reprogrammeres på væsentlige punkter. Herved kan man sige, at fjerde iteration indebar en femte. Valget af b-modellen må klart siges, at have givet rum for de eksperimenter, der viste sig nødvendige for at leve op til problemformuleringens og dermed projektets mål for udvikling og implementering. Man kan sige, at modellen til et projekt af dette projekts størrelse har været en succes. De nødvendige eksperimenter og digressioner har kunnet gennemføres uden at overblikket er forsvundet. Det er ikke muligt på baggrund af denne erfaring alene, at sige noget om modellens værdi til store projekter med mange involverede projektdeltagere. 5.2 Rønnow/Jacobsen metoden Et af de væsentlige argumenter for at vælge en overvejende datadrevet systemudviklingsmodel er, jf. Rønnow and Jacobsen (1989), at sikre beskrivelsen af datas indre sammenhænge, det vil sige at data har en værdi i sig selv, løsrevet fra den konkrete brug. Teorien siger, at vi derved bedre bliver i stand til at være fleksible i forhold til behov, der opstår undervejs i et projekt eller eventuelt efter projektets afslutning. Det er klart, at både det konkrete systems behov, der afprøves i metodens punkt 6, jf. kapitel 2, og metodens punkt 7 spiller en rolle i forhold til målet om fleksibilitet. I nærværende projekt kunne transaktionsafprøvningen, både som den egentlige autentifikation, og som de administrative processer omkring datavedligeholdelsen, klares af både datamodellen fra første skitse, afsnit 4.1.1, og den valgte, beskrevet i afsnit Grundene til valg af løsning skal findes i en forestilling om et generelt skønnet behov for gruppering af brugere mere end et konkret behov i testopstillingen. Da vi samtidigt kunne opnå en praktisk administrativ forenkling med færre rækkeforekomster at administrere, kan man sige, at metoden støttede valget. På et andet punkt har metodens punkt 7 om de fremtidige behov også spillet en rolle. Valget af opdeling af primærnøglen i program-entiteten i to elementer, sti og program, er foretaget ud fra en forventning om, at det herved vil blive lettere at foretage en omflytning af en webapplikation, hvis dette skulle blive nødvendigt. Ved en omstrukturering kunne det være særdeles praktisk for en sikkerhedsadministrator at kunne sige, at alle programmer med stien x flyttes til stien y uden at øvrige egenskaber ved programmerne ændres. Dette er lettere at udføre med opsplitning af primærnøglen i to attributter. Problemet kan let løses i SQL, men når det endnu ikke er implementeret i den administrative brugergænseflade til Authentific, er det fordi, det ikke har været nødvendigt for at kunne implementere og bruge systemet. Med andre ord, metodens mulighed for at tage hensyn til et fremtidigt behov har spillet en positiv rolle. Det skal selvfølgelig nævnes, som det blev antydet i kapitlet om metodevalg, at med et projekt af denne størrelse er det muligt, at være mindre formel end hvis det var et stort projekt med mange projektdeltagere, der var afhængige af hinandens arbejde. Der er dog ikke noget, der tyder på, at man ikke med den fornødne formalisme kunne bruge denne metode også i store projekter.

41 Kapitel 6 Evaluering af proces Noise proves nothing. Often a hen who has merely laid an egg cackles as if she laid an asteroid. Mark Twain Da rapportens konklusion vil behandle resultatet i forhold til hvert af problemformuleringens områder, skal der i dette kapitel ganske kort diskuteres nogle emner, der ikke allerede er diskuteret i kraft af overvejelserne om metoden. 6.1 Uforudsete problemstillinger Sikkerhed omkring passwords Det er klart, at et autentifikationssystem, der af natur er et sikkerhedssystem, skal søge selv at være så sikkert som muligt. Kvaliteten af den analyse, der er lagt til grund for udviklingen, vil have afsløret, om dette mål er nået. Et banalt sikkerhedshul, veldokumenteret på internettet, er det at man i mange applikationer der kræver indtastning af password, kan indtaste x OR 1 = 1 (uden anførselstegnene). Dette ville medføre, at et opslag i en autentifikationsdatabase programmeret således: select brugerid, passwd from bruger where bid = $brugerid and pwd = $pwd ; ville kunne resultere i udførelsen af:... and pwd = x or 1 = 1; Da en logisk or-konstruktion er sand, blot en af betingelserne er sand, så ville dette medføre autentifikation. Ikke heldigt. Nogle få forsøg på internettet viser, at dette sikkerhedshul faktisk eksisterer. Hvor udbredt det er vides ikke. Således opmærksom, viser det sig, at når man overholder en sikkerhedsgrundregel, som at passwords altid opbevares krypterede, så tager man ikke ovenstående dilemma op. Man undgår det automatisk, idet ovennævnte indtastede $pwd ikke kontrolleres som vist, men efter at have gennemgået en kryptering: $cryptpwd = sha1($pwd); and pwd = $cryptpwd ; 41

42 42 Kapitel 6: Evaluering af proces og $cryptpwd ikke er let at få til at vise legal SQL-syntaks. På trods af at dette potentielle problem er undgået, er der i Authentific indprogrammeret en kontrol af, at passwords indeholder gyldige tegn, jf. afsnit 7.1. Denne kontrol udføres i forbindelse med brugerens egen opdatering af passwords og ved sikkerhedsadministratorens tilsvarende funktion for alle brugere Beskyttelse af programmer Ved implementering af en webapplikation bør det altid være en overvejelse, om applikationens programmer skal sikkerhedsbeskyttes. I forhold til Authentific opstod en overvejelse i den anledning. Vælger man ikke at indføre Authentifics kodestub i starten af et program, er programmet helt ude af kontakt med Authentific. Men vælger man at indføre kodestubben er programmet beskyttet. Imidlertid vil der være programmer, som stilles under Authentifics beskyttelse, men som, måske fra starten, måske senere i deres eksistens, skal lade alle bruge sig. Altså egentlig beskyttede programmer, der blot ikke skal kræve bruger-id og password som autentifikation. Den umiddelbare holdning i foranalysen var ikke tilstrækkeligt grundigt analyseret. Testen afslørede dette. Denne erkendelse medførte en reprogrammering af authenticate.php som allerede nævnt i afsnit 5.1. At alle skal kunne bruge et program, betyder alle uden afgivelse af bruger-id og password, som allerede nævnt, måske også fordi en lang række af disse menige brugere eventuelt ikke er optaget i Authentifics brugerregister. Sidstnævnte gælder jo i hvert fald alle eksterne brugere fra internettet. 6.2 På vejen til Rom 1 På vejen til Rom mødte jeg Zandstra (2000). I forbindelse med deltagelse i uddannelse omkring objektorientering og programkonstruktion, blev min interesse genvakt for at undersøge PHPs muligheder i den pt stabile version, version 4.3.x. Resultatet af læsning i et relevant kapitel i Matts bog og nogle efterfølgende eksperimenter var overvældende. Uden at dette skal gøres til noget hovedemne i denne rapport, er det mig alligevel magtpåliggende at prøve at åbne læserens øjne for den nytteværdi, der kan opstå ved at overveje objektorientering allerede i PHP V4. PHP skulle ellers først blive rigtigt objektorienteret i V5, men der er altså allerede effektivisering at hente. Den konkrete anvendelse er beskrevet ved et klassediagram og kodeeksempler i appendiks D. 1 Den danske titel på et Fibonacci-problem. Måske mere kendt som det engelske børnerim: St. Ives: As I was going to St. Ives I met a man with seven wives. Every wife had seven sacks, every sack had seven cats, every cat had seven kits. Kits, cats, sacks and wives. How many were going to St. Ives.

43 Kapitel 7 Hvor går vi hen herfra? Cheshire Puss,... Would you tell me, please, which way I ought to go from here? That depends a good deal on where you want to get to, said the Cat. Lewis Carrol Man kunne for eksempel... Mange års undersøgelser og forskning er lagt i forbindelse med årsager og muligheder ved brugeres valg af passwords, når de får muligheden for selv at vælge. Grundlæggende er konklusionen nok, at det er nødvendigt at have en god portion forståelse og velvilje fra brugeren for nødvendigheden af svære passwords. Dette projekt har valgt at imødekomme brugerens mulighed for indflydelse ved at levere et program, hvormed brugeren selv kan ændre sit password. Det eneste kvalitetskrav, som systemet sætter i sin nuværende udformning er at password skal være mindst 14 (højst 42) tegn langt. Det må også kun indeholde nogle bestemte tegn, små og store bogstaver, alle cifre og enkelte specialtegn, ialt 67 forskellige muligheder for tegn. Reglerne er de samme som for passwords i UNIX-systemer. Vel vidende at brugere generelt vælger for dårlige passwords, rejser der sig nogle udviklingsmuligheder for Authetific. 1. Der kunne etableres en forældelsesmekanisme for passwords, så de udløber efter en konfigurerbar tid. 2. Der kunne etableres en form for kvalitetskontrol af valgte passwords. 3. Måske en kombination af de første punkter. Både Garfinkel et al. (2003) og en spritny artikel Ives, Walsh and Schneider (2004) behandler emnet, som mange viger tilbage fra at påtvinge brugerne. Authentifics datamodel indeholder allerede databasefaciliteter til implementering af en passwordforældelsesmekanisme. En opfølgning på nærværende projekt kunne være, at foretage implementeringen. Denne kunne bestå i at selve autentifikationskomponenten, authenticate.php, kontrollerede passwords alder, og sendte brugeren over til passwordvedligejoldelsesprogrammet, når det gamle password blev for gammelt. Det ville i denne sammenhæng også være nyttigt at tænke på en restriktion med hensyn til genbrug af et antal generationer af de senest brugte passwords. Det andet punkt, kvalitetskontrol, kunne bestå i, at de to programmer, hvor passwords kan etableres, afprøvede alle forsøgte passwords i forhold til en af de ordlister, som crack- 1 Alice in Wonderland. Carrol (1965). 43

44 44 Kapitel 7: Hvor går vi hen herfra? erne 2 normalt bruger ved forsøg på indbrud. Disse ordlister er meget omfattende, og kan let skaffes fra nettet. Ord fra ordlisterne skulle være forbudte som passwords. 7.2 Integration med et eksisterende personalesystem Det er en væsentlig sikkerhedsmæssig pointe, at oprettelse af en ny medarbejder i en organisations personaledatabase bør medføre automatisk oprettelse af vedkommende i Authentifics brugerrelation. Man kunne eventuelt oprette brugeren uden særlige autentifikationskendetegn eller rettigheder. En simpel udviklingsopgave, der består i, at når organisationens database tilføres en forekomst af en ny medarbejder, skal der etableres forbindelse til Authentific og der automatisk oprettes en ny bruger. Det er dog sikkert endnu vigtigere, at sletningen af en medarbejder, logisk eller fysisk, fra personalesystemet, medfører automatisk suspension af denne bruger i autentifikationssystemet. Sammenbindingen til personalesystemet kan ikke være en del af et generisk autentifikationssystem. Det bør etableres, og det skal gøres af den brugende organisation. 7.3 Single Sign On Single-sign-on er et begreb, der betyder at en enkelt login-proces skal gælde alle systemer. Dette er implementeret per default i Authentific, idet sessionen bevares, så længe den bruges, og i alle programmer, hvor den bruges. 7.4 Fra prototype til produkt Det er blevet nævnt allerede i forordet, at der vil blive taget initiativ til at stille projektets Authentific til rådighed som et produkt. Projektet beskrevet her bygger ovenpå nogle tidligere eksperimenter med især simplere udgaver af komponenten authenticate.php, hvor databasedelen har været integreret i den eller de databaser fra det konkrete system. I den forstand kan man sige, at disse tidligere eksperimenter har haft karakter af prototyper, og at dette projekt i en vis forstand har tilstræbt at producere en produktionsudgave på baggrund af disse prototyper. Det arbejde, der skal gøres for at produktmodne Authentific, vil således primært bestå i at udvikle og afteste Authentific installationspakker, der skal sikre effektiv og fleksibel indplacering i et produktionsmiljø omkring en webserver. De uafklarede faktorer er her først og fremmest etablering af den nødvendige bruger i det valgte DBMS. Den anonyme webbruger, hvor Authentific i overensstemmelse med UNIX/Apache-tradition bruger nobody som identifikation for webprogrammerne, skal være oprettet i DBMS et. Hertil kommer at der skal findes en fornuftig måde, hvorpå en initial load af authentificdatabasen kan ske. Dette skal være under hensyntagen til både muligheden for en selvstændig database, og en brugervalgt integration i en anden database. Det sidste vil gøre Authentific mindre generel og mindre autonom. I nærværende arbejde er der udviklet SQL-sætninger til initial load af en sikkerhedsadministrator og en sikkerhedsadministratorgruppe, samt en øvrig gruppe. Hertil kommer selvfølgelig SQL til sikkerhedsoprettelse af Authentifics egne administrative programmer. 2 Det ofte brugte ord hacker er fejlagtigt anvendt i denne sammenhæng. Derfor det andet ordvalg. Se fx. Eric Raymonds opfattelse på esr/faqs/hacker-howto.html/#what is

45 Kapitel 8 Konklusion... at skrive speciale vil sige at have det sjovt, og det er med et speciale som med en gris, man kasserer ikke noget af det. Umberto Eco Problemformuleringen genbesøgt Piller vi spørgsmålene ud af problemformuleringen for projektet, se kapitel 1, havde vi med nogle omformuleringer følgende spørgsmål: 1. Er det muligt at udvikle et autonomt og generisk autentifikationssystem til brug for web-applikationer, der har brug for beskyttelse? 2. Kan autentifikation isoleres fra generel sikkerhed omkring datakommunikation og netværk på en måde, så der logisk og praktisk kan skrives software til dens håndtering i en World Wide Web-sammenhæng? 3. Kan et autentifikationssystem udformes på en måde, så det vil være naturligt at anvende i fremtidig systemudvikling uden store ekstraomkostninger? 4. Kan eksisterende applikationer let upgraderes til at anvende et nyt autentifikationssystem? 5. Kan en brugers bevægelser i en organisation håndteres af systemet på en enkel måde? 6. Kan tilføjelser og ændringer i de systemer, der skal beskyttes kan afspejles af systemet uden besvær? 7. Kan brugerne gives indflydelse på egne passwords? 8. Er autentifikationsprocessen selv tilstrækkeligt sikret? Spørgsmålene er selvfølgelig stillet anderledes i problemformuleringen alene af den grund, at med formuleringen her kan de alle rent logisk besvares med ja eller nej. Det ville der være kommet en meget kort rapport ud af. Når det er sagt, så er den meget korte version, at projektet har besvaret alle disse spørgsmål med ja! 1 Kunsten at skrive speciale. Eco (1997). Originaludgaven er på italiensk og fra

46 46 Kapitel 8: Konklusion 8.2 Et nuanceret billede Kærnespørgsmålene Authentific dokumenterer, at der kan skrives et både autonomt og generisk autentifikationssystem til webapplikationer. I sig selv er Authentific et eksempel på et lille webbaseret system, der drives af en database, og hvis grænseflade er traditionelt udseende webprogrammer. Da systemet sikrer sig selv ved at anvende sine egne informationer til sikring af sit indholds integritet, har projektet dermed besvaret spørgsmål 1 og spørgsmål 8 bekræftende. For så vidt kunne man sige, at der så var produceret et lille system, der kunne bruges til eksemplificering i en undervisningssituation, hvori indgik client-side og server-side webprogrammering, datamodellering og databaseteknologi med relationsdatabaser. Analyserer man hvordan Authentific beskytter sig selv med hensyn til autentifikation, nemlig ved at dets administrative programmer alle har en enkelt kodelinie, som første kodelinie, der etablerer beskyttelsesmekanismen, så har vi herved også svarene på spørgsmål 3 og 4. Begge bekræftende. For spørgsmål 3s vedkommende skal udvikleren være klar over at han i sin værktøjskasse har den include-komponent, der etablerer beskyttelsen. I forhold til spørgsmål 4 skal vedligeholderen på samme måde kende til det enkle i at indføre denne ene kodelinie i starten af hvert program, der skal beskyttes. Ser vi spørgsmål 6 sammen med de to netop nævnte, kan det siges, at opnåelsen af autentifikation på denne enkle måde stiller som krav, at udviklerne ikke unødigt sammenblander funktionalitet om data, der skal integritetsbeskyttes, med funktionalitet, der ikke behøver beskyttelse. Den gamle tommelfingerregel om keep it simple, gælder stadig, og hvis man vil overholde den, er Authentific ikke til besvær, og spørgsmål 6 kan også besvares med et ja De andre spørgsmål Herefter resterer tre spørgsmål, der har en lidt anden karakter end de ovenfor besvarede. For spørgsmål 2s vedkommende er en del af svaret, at da Authentific er autonomt, så kan vi dermed også sige, at autentifikationsspørgsmålet kan løses adskilt fra de webapplikationer, som det skal bidrage til beskyttelsen af. Samtidig må vi dog konstatere, at løsning af autentifikationsproblemet ikke kan ske tilstrækkeligt sikkert uden bidrag udefra. Projektet og rapporten har gjort rede for nødvendigheden af en mekanisme som TLS/SSL, installeret på webserveren, for ikke at kompromittere de passwords, der er nødvendige for autentifikationen. På dette punkt deler Authentific vilkår med både webapplikationer, der skal autentifikationsbeskyttes og med evt. andre webapplikationer, hvor transmitterede data skal hemmeligholdes, for eksempel e-handelsapplikationer med kreditkortoplysninger, overførsel af cpr-numre etc. Spørgsmål 5 kan Authentific ikke løse selv, men projektet har antydet en enkel sammenbinding mellem en organisations personalesystem og Authentific. Denne sammenbinding bør udføres, hvis man ikke skal ende med, at medarbejdere, der ikke længere er i organisationen, og måske nok er slettede i personaleregistret, bevarer deres plads i autentifikationssystemet. En uheldig situation, al den stund at nogle af disse medarbejdere måske er fjendtligt indstillede. Brugerindflydelse, og måske derigennem brugerengagement, kan i Authentific tilvejebringes gennem skrivning af et webprogram, hvor brugeren selv kan ændre sit password. Naturligvis kun mod autentifikation med det gamle password. Dette program er skrevet som svar på spørgsmål 7, og viden herom må formidles til brugerne.

47 8.2: Et nuanceret billede Svar på det ikke stillede spørgsmål I forbindelse med afgrænsningen blev opstillet det ekstra mål, at projektet skulle afprøves med henblik på uafhængighed af valg af konkret DBMS til Authentific. Projektet har etableret og testet uafhængigheden i forhold til to udvalgte DBMS er. Begge virkede som forventet. De testede blev udvalgt på baggrund af deres høje grad af support for gældende SQL-standard. Når der ved installation er valgt, hvilket DBMS Authentific skal anvende, er det efterfølgende transparent for både bruger og programmør, hvilket system, der blev valgt.

48

49 Bilag A Authentific database I dette appendiks det SQL-script, der kan oprette indhold i databasen authentific. Den viste SQL kan bruges i både Firebird og PostgreSQL. Forudsætningen er, at man på hver sin måde i de to DBMS er får udført en CREATE DATABASE inden SQL-scriptet udføres. A.1 SQL-script: DDL til oprettelse af authentific. /* start dbms-klienten og udfør nærværende sql-script */ CREATE DOMAIN ADR AS VARCHAR(64); CREATE DOMAIN KOMMENTARER AS VARCHAR(256); CREATE DOMAIN NAVNEFELT AS VARCHAR(40); CREATE DOMAIN PASSWD AS VARCHAR(40); CREATE DOMAIN PROGRAMNAVNE AS VARCHAR(32); CREATE DOMAIN RWX AS INTEGER check (value between 0 and 7); CREATE DOMAIN STINAVNE AS VARCHAR(48); CREATE DOMAIN TEGNID AS VARCHAR(16); CREATE DOMAIN TIDSSTEMPEL AS TIMESTAMP; CREATE TABLE BRUGER ( UID TEGNID NOT NULL, UPWORD PASSWD NOT NULL, UPWDATOTID TIDSSTEMPEL NOT NULL, UFORNAVN NAVNEFELT NOT NULL, UEFTERNAVN NAVNEFELT NOT NULL, U ADR NOT NULL, PRIMARY KEY (UID) ); CREATE TABLE GRUPPE ( GID TEGNID NOT NULL, GNAVN NAVNEFELT NOT NULL, PRIMARY KEY (GID) ); CREATE TABLE BERIG ( GID TEGNID NOT NULL, UID TEGNID NOT NULL, PRIMARY KEY (GID, UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID), FOREIGN KEY (UID) REFERENCES BRUGER (UID) ); CREATE TABLE PROGRAM ( PATH STINAVNE NOT NULL, PID PROGRAMNAVNE NOT NULL, UID TEGNID NOT NULL, URWX RWX NOT NULL, GID TEGNID NOT NULL, 49

50 50 Appendiks A: Authentific database GRWX RWX NOT NULL, ORWX RWX NOT NULL, BESKRIVELSE KOMMENTARER NOT NULL, PRIMARY KEY (PATH, PID), FOREIGN KEY (UID) REFERENCES BRUGER (UID), FOREIGN KEY (GID) REFERENCES GRUPPE (GID) ); CREATE TABLE GLPWORD ( UID TEGNID NOT NULL, UPWDATOTID TIDSSTEMPEL NOT NULL, UPWORD PASSWD NOT NULL, PRIMARY KEY (UID,UPWDATOTID), FOREIGN KEY (UID) REFERENCES BRUGER (UID) ); GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON BERIG TO NOBODY; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON BRUGER TO NOBODY; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON GRUPPE TO NOBODY; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON PROGRAM TO NOBODY; GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON GLPWORD TO NOBODY;

51 Bilag B Authentifics kærnekomponenter og deres anvendelse B.1 Script: authenticate.php session_name("authentific_nml"); session_start(); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); // $target into $path and $pid $row = explode("/", $_GET["target"]); $pid = $row[count($row)-1]; $path = "/"; for ($i = 1; $i < count($row) - 1; $i++) // start m 1, da path starts with an "/" $path.= $row[$i]. "/"; $_SESSION[ authenticated ] = FALSE; // case insensitive (manual) $db = connect($host, $username, $password); // check for others execute right $sql = "SELECT orwx"; $sql.= " from program"; $sql.= " where path = $path "; $sql.= " and pid = $pid "; $result = query($sql); if ($result) { $arrow = row_at_a_time($result); if ($arrow[0] and 5) { $_SESSION[ authenticated ] = TRUE; if (!isset($_session[ userid ])!isset($_session[ userpw_crypt ])) { $_SESSION[ userid ] = $username; $_SESSION[ userpw_crypt ] = sha1($password); if ($_SESSION[ authenticated ]!= TRUE) { // auth thru orwx? $tmpuserid = ""; $tmpuserpw_crypt = ""; if (isset($_session[ userid ]) && isset($_session[ userpw_crypt ])) { // no, try possible user $tmpuserid = $_SESSION[ userid ]; $tmpuserpw_crypt = $_SESSION[ userpw_crypt ]; else if (isset($_post[ sel_userid ]) && isset($_post[ sel_userpw ])) { // else try new entry $tmpuserid = $_POST[ sel_userid ]; $tmpuserpw_crypt = sha1($_post[ sel_userpw ]); $sql = "SELECT urwx"; // check as urwx? $sql.= " from program, bruger"; $sql.= " where path = $path "; $sql.= " and pid = $pid "; $sql.= " and program.uid = $tmpuserid "; $sql.= " and upword = $tmpuserpw_crypt "; $sql.= " and program.uid = bruger.uid;"; $result = query($sql); 51

52 52 Appendiks B: Authentifics kærnekomponenter og deres anvendelse if ($result) { $arrow = row_at_a_time($result); if ($arrow[0] and 5) { $_SESSION[ authenticated ] = TRUE; $_SESSION[ userid ] = $tmpuserid; $_SESSION[ userpw_crypt ] = $tmpuserpw_crypt; if ($_SESSION[ authenticated ]!= TRUE) { // if urwx ok, use it else $sql = "SELECT grwx"; // check as grwx $sql.= " from program, gruppe, bruger, berig"; $sql.= " where path = $path "; $sql.= " and pid = $pid "; $sql.= " and gruppe.gid = program.gid"; $sql.= " and gruppe.gid = berig.gid"; $sql.= " and berig.uid = $tmpuserid "; $sql.= " and upword = $tmpuserpw_crypt "; $sql.= " and bruger.uid = berig.uid;"; $result = query($sql); if ($result) { $arrow = row_at_a_time($result); if ($arrow[0] and 5) { $_SESSION[ authenticated ] = TRUE; $_SESSION[ userid ] = $tmpuserid; $_SESSION[ userpw_crypt ] = $tmpuserpw_crypt; if (!isset($_session[ authenticated ]) $_SESSION[ authenticated ]!= TRUE) { $_SESSION = array(); // no success as user or group session_destroy(); // destroy session vars and kill session if (isset($_session[ authenticated ]) && $_SESSION[ authenticated ] == TRUE) { $quovadis = $path. $pid. "?". $_SERVER[ QUERY_STRING ]; //do we have auth? header("location: $quovadis"); //go to the wanted program else { $_SESSION = array(); //else prepare for auth screen include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Authentification module"; htmlhead($titel); print("<body>\n"); print("<h1>".$titel."</h1>\n\n"); print("<h2>den ønskede funktion kræver adgangstilladelse</h2>\n"); print("<h3>legitimer dig venligst:</h3>\n\n"); print("<table>\n"); $action = $PHP_SELF. "?". $_SERVER[ QUERY_STRING ]; print("<form id=\"form22\" method=\"post\" action=\"$action\">\n"); print("<tr><td>bruger Id:</td>\n"); print("<td><input type= text name= sel_userid size= 16 maxlength= 16 /></td></tr>\n"); print("<tr><td>password:</td>"); print("<td><input type= password name= sel_userpw size= 45 maxlength= 42 /></td></tr>\n"); print("<tr><td></td><td><input type= submit value= Login /></td>\n"); print("</form>\n\n"); print("<form action=../index.php method= post >\n"); print("<td><input type= submit value= Retur til menu /></td>\n"); print("</form>\n"); print("<form action=\"#\" method=\"post\">\n"); print("<td><input type= button value= Website hjem onclick=window.location= /></td></tr>\n"); print("</form>\n"); print("</table>\n"); print("</body>\n"); print("</html>\n");

53 B.2: Script: deauthenticate.php 53 B.2 Script: deauthenticate.php session_name("authentific_nml"); session_start(); $_SESSION = array(); session_destroy(); header("location: //don t forget the name //connect to session //kill its vars //kill session //redirect to menu B.3 Script: auth implement.inc //au- session_name("authentific_nml"); session_start(); if(!isset($_session[ authenticated ]) $_SESSION[ authenticated ]!= TRUE) { thenticated $nyqs = "?target="; //no, go and do it //yes, re- $nyqs.= $PHP_SELF; $nyqs.= "&"; $nyqs.= $_SERVER[ QUERY_STRING ]; header("location: $nyqs); $_SESSION[ authenticated ] = FALSE; set and use it B.4 Authentific, vigtigste include-filer dbauth setup.inc $DBMSa = "firebird"; $DBMSb = "postgresql"; $implemnt = $DBMSb; $dbnml = "authentific"; $path = "localhost:/usr/local/webroot/databases/"; $username = "nobody"; $password = "test"; if ($implemnt == $DBMSa) { $host = $path. $dbnml; include("../support_auth/db_funktioner_firebird.inc"); else if ($implemnt == $DBMSb) { $host = $dbnml; include("../support_auth/db_funktioner_postgresql.inc"); else { $host = ""; db funktioner firebird.inc function connect($db, $us, $pw) { if (!$database = ibase_connect($db, $us, $pw)) { print("<h2>fejl: Ingen forbindelse opnået til databasen!</h2>"); exit; return true; function query($sql_stmt) { if (!$rel = ibase_query($sql_stmt)) { print("<h2>fejl: Dataoperation kikset!</h2>". $sql_stmt); exit; return $rel; function row_at_a_time($relvar) {

54 54 Appendiks B: Authentifics kærnekomponenter og deres anvendelse if (!$tuple = ibase_fetch_row($relvar)) return false; return $tuple; function tael($relvar) { $i = 0; while ($x = ibase_fetch_row($relvar)) $i++; return $i; db funktioner postgresql.inc function connect($db, $us, $pw) { $conn_string = "dbname=".$db." user=".$us." password=".$pw; if (!$database = pg_connect($conn_string)) { print("<h2>fejl: Ingen forbindelse opnået til databasen!</h2>"); exit; return true; function query($sql_stmt) { if (!$rel = pg_query($sql_stmt)) { print("<h2>fejl: Dataoperation kikset!</h2>". $sql_stmt); exit; return $rel; function row_at_a_time($relvar) { if (!$tuple = pg_fetch_row($relvar)) return false; return $tuple; function tael($relvar) { return pg_num_rows($relvar); B.5 Authentific, anvendelseseksempler B.5.1 bruger vis.php Sikkerhedsadministratorens program til display af Authentific-brugere: include("../support_auth/auth_implement.inc"); // her, og kun her, påkaldes Authentific include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/ajourfør brugere"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select uid, ufornavn uefternavn as navn, upwdatotid, u "; $sql.= " from bruger"; $sql.= " order by ufornavn;"; $result = query($sql); $user_table = new TableHTMLupd(array("Bruger-id", "Navn", "Password fra", " ")); while ($arrow = row_at_a_time($result)) { $temp = strtotime($arrow[2]); $arrow[2] = date("d/m/y H:i:s", $temp); $user_table->addrow($arrow); $user_table->display_table(./bruger_form.php?funktion=upd, bruid );

55 B.5: Authentific, anvendelseseksempler 55 print("<h2>klik på bruger-id for at ajourføre!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> B.5.2 klasse vis.php et tilfældigt valgt program fra testscenariet. Programmet laver display af klasser på en uddannelse: include("../support_auth/auth_implement.inc"); // her, og kun her, påkaldes Authentific include("../support/xhtml11_top.inc"); include("../support/db_setup.inc"); include("../support/faelles_funktioner.inc"); include("../support/table_class.inc"); include("../support/table_class_html_upd.inc"); $titel = "Skole: Vis/ajourfør fag"; htmlhead($titel); print("<body class=\"grey\">\n"); connect_role($host, $username, $password, $role1); echo "<h1>".$titel."</h1>\n"; $sql = "SELECT * FROM klasse order by klasse_id;"; $result = query($sql); $user_table = new TableHTMLupd(array("Klasse", "Uddannelseskode", "Startdato")); while ($arrow = row_at_a_time($result)) { $temp = strtotime($arrow[2]); $arrow[2] = date("d/m/y", $temp); $user_table->addrow($arrow); $user_table->display_table(./klasse_form.php?funktion=upd, klasse_id ); print("<h2>klik på klasse for at ajourføre!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html>

56

57 Bilag C Authentific, baggrundskode C.1 Authentific, supporting scripts C.1.1 Øvrige include-filer xhtml11 top.inc <?xml version="1.0" encoding="iso " <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" " <html xmlns=" xml:lang="da"> faelles funktioner.inc function sidefod($hjem, $visigen, $xhtml) { print(" <form action=\"#\">\n"); print(" <table><tr>\n"); if ($hjem) printf(" <td><input type=\"button\" value=\"hjem\" onclick=\"window.location= %s \" /></td> if ($visigen) printf(" <td><input type=\"button\" value=\"vis\" onclick=\"window.location= %s \" /></td>\n", $v gen); print(" </tr>\n"); if ($xhtml) { print(" <tr><td> </td><tr><td>\n"); print(" <a href=\" print(" onclick=\"window.open(this.href, _blank );return false;\">\n"); print(" <img src=\" print(" alt=\"valid XHTML 1.1!\" height=\"31\" width=\"88\" />\n"); print(" </a>\n"); print(" </td></tr>\n"); print(" </table>\n"); print(" </form>\n"); function selector($res, $kls, $hit) { $selected = ""; print(" <select name= $kls >\n"); while ($arrow = row_at_a_time($res)) { if ($hit == $arrow[0]) $selected = "selected"; printf(" <option value= %s $selected>%s</option>\n", $arrow[0], $arrow[0]); $selected = ""; print(" </select>\n"); return; // slut selector function function htmlhead($title) { 57

58 58 Appendiks C: Authentific, baggrundskode print(" print(" print(" print(" <head>\n"); <title>".$title."</title>\n"); <link rel=\"stylesheet\" type=\"text/css\" href=\"../support_auth/style.css\" />\n"); </head>\n"); C.2 Authentific administrative scripts C.2.1 Databasetabellen program program form.php, inddatering og ajourføring af programmer include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Program, inddata"; <head> <title> echo $titel </title> <link rel="stylesheet" type="text/css" href="../support_auth/style.css" /> <script type="text/javascript"><!-- function valider() { if (document.forms[ iform ].pathid.value.length < 1) { alert("fejl: Program-sti SKAL være mindst 1 tegn langt!"); document.forms[ iform ].pathid.focus(); return false; if (document.forms[ iform ].pid.value.length < 6) { alert("fejl: Program-id SKAL være mindst 6 tegn langt!"); document.forms[ iform ].pid.focus(); return false; if (document.forms[ iform ].bruid.value.length < 2) { alert("fejl: Brugernavn SKAL være mindst 2 tegn langt!"); document.forms[ iform ].bruid.focus(); return false; if (!(document.forms[ iform ].urwx.value >=0 document.iform.urwx.value <=7)) { alert("fejl: urwx skal være mellem 0 og 7!"); document.forms[ iform ].urwx.focus(); return false; if (document.forms[ iform ].grpid.value.length < 2) { alert("fejl: Gruppenavn SKAL være mindst 2 tegn langt!"); document.forms[ iform ].grpid.focus(); return false; if (!(document.forms[ iform ].grwx.value >=0 document.iform.grwx.value <=7)) { alert("fejl: grwx skal være mellem 0 og 7!"); document.forms[ iform ].grwx.focus(); return false; if (!(document.forms[ iform ].orwx.value >=0 document.iform.orwx.value <=7)) { alert("fejl: orwx skal være mellem 0 og 7!"); document.forms[ iform ].orwx.focus(); return false; wfelt = document.forms[ iform ].beskrivelse.value; if (wfelt.length < 6 ) { alert("fejl: Beskrivelse skal være på mindst 6 tegn!"); document.forms[ iform ].beskrivelse.focus(); return false;

59 C.2: Authentific administrative scripts 59 return true; --></script> </head> <body class="gray" onload="document.forms[ iform ].pid.focus();"> <h1>authentific: Program, inddata formular</h1> if (isset($funktion) && $funktion == "upd") { connect($host, $username, $password); $sql = "select *"; $sql.= " from program"; $sql.= " where path = ". $_GET[ pathid ]. " "; $sql.= " and pid = ". $_GET[ pid ]. " ;"; $result = query($sql); $matrix = row_at_a_time($result); $readonly = "readonly = \"readonly\""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./program_db.php?funktion=upd\""; $streng.= " onsubmit=\"return valider();\">"; else { $funktion = "ins"; $matrix[0] = ""; $matrix[1] = ""; $matrix[2] = ""; $matrix[3] = ""; $matrix[4] = ""; $matrix[5] = ""; $matrix[6] = ""; $matrix[7] = ""; $readonly = ""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./program_db.php?funktion=ins\""; $streng.= " onsubmit=\"return valider();\">"; printf("%s\n", $streng); <table> <tr> <td align="right">sti: </td> <td> <input type="text" name="pathid" size="32" maxlength="64" value=" echo $matrix[0]" /></td> </tr> <tr> <td align="right">program: </td> <td> <input type="text" name="pid" size="32" maxlength="64" value=" echo $matrix[1]" /></td> </tr> <tr> <td align="right">bruger: </td> <td> connect($host, $username, $password); $sql = "select uid from bruger order by uid;"; $resultat = query($sql); selector($resultat, bruid, $matrix[2]); </td> </tr> <tr> <td align="right">rettigheder: </td> <td><input type="text" name="urwx" size="2" maxlength="1" value=" echo $matrix[3]"></td> </tr> <tr> <td align="right">gruppe: </td> <td> connect($host, $username, $password); $sql = "select gid from gruppe order by gid;";

60 60 Appendiks C: Authentific, baggrundskode $resultat = query($sql); selector($resultat, grpid, $matrix[4]); </td> </tr> <tr> <td align="right">rettigheder: </td> <td><input type="text" name="grwx" size="2" maxlength="1" value=" echo $matrix[5]"></td> </tr> <tr> <td align="right">andres rettigheder: </td> <td><input type="text" name="orwx" size="2" maxlength="1" value=" echo $matrix[6]"></td> </tr> <tr> <td align="right">programbeskrivelse: </td> <td><textarea name="beskrivelse" rows="8" cols="32"> echo $matrix[7]</textarea></td> </tr> <tr> <td><input type="hidden" name="funktion" value=" echo $funktion "></td> <td><input type="submit" value="ok"></td> </tr> </table> </form> sidefod(false, false, xhtml ); </body> </html> program vis.php, vis programmer i tabelform, udvælg til ajourføring include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_program_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/ajourfør programmer"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select * from program order by path, pid;"; $result = query($sql); $user_table = new TableHTMLprogramupd(array("Sti", "Program", "Bruger", "URWX", "Gruppe", "GRWX", "ORWX", "Beskrivelse")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./program_form.php?funktion=upd, pid, pathid ); print("<h2>klik på program-id for at ajourføre!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> program vis slet.php, vis programmer i tabelform, udvælg til sletning include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_program_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/slet programmer"; htmlhead($titel); print("<body class=\"yellow\">\n"); connect($host, $username, $password);

61 C.2: Authentific administrative scripts 61 echo "<h1>".$titel."</h1>\n"; $sql = "select * from program order by path, pid;"; $result = query($sql); $user_table = new TableHTMLprogramupd(array("Sti", "Program", "Bruger", "URWX", "Gruppe", "GRWX", "ORWX", "Beskrivelse")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./program_db.php?funktion=del, pid, pathid ); print("<h2>klik på program-id for at slette!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> program db.php, databasemodul til programmer include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Ajourf~A re database, program"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); if ($_GET[ funktion ] == "ins") { $sql = "insert into program"; $sql.= " (path, pid, uid, urwx, gid, grwx, orwx, beskrivelse)"; $sql.= " values( $pathid, $pid, $bruid, $urwx, $grpid, $grwx, $orwx, $beskrivelse );"; elseif ($_GET[ funktion ] == "upd") { $sql = "select * from program where path = $path and pid = $pid ;"; $rel = query($sql); $arrow = row_at_a_time($rel); $sql = "update program set "; $sql.= "path = $pathid, pid = $pid "; $sql.= ", uid = $bruid "; $sql.= ", urwx = $urwx "; $sql.= ", gid = $grpid "; $sql.= ", grwx = $grwx "; $sql.= ", orwx = $orwx "; $sql.= ", beskrivelse = $beskrivelse "; $sql.= " where path = $pathid and pid = $pid ;"; elseif ($_GET[ funktion ] == "del") $sql = "delete from program where path = $pathid and pid = $pid ;"; query($sql); header("location:../index.php"); </body> </html> C.2.2 Databasetabellen bruger bruger form.php, inddatering og ajourføring af brugere include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Bruger, inddata"; <head> <title> echo $titel </title> <link rel="stylesheet" type="text/css" href="../support_auth/style.css" /> <script type="text/javascript"><!-- function valider() { if (document.forms[ iform ].bruid.value.length < 2) { alert("fejl: Bruger-id SKAL være mindst 2 tegn langt!"); document.forms[ iform ].bruid.focus();

62 62 Appendiks C: Authentific, baggrundskode return false; if (document.forms[ iform ].passwd0.value.length < 14) { alert("fejl: Password SKAL være mindst 14 tegn langt!"); document.forms[ iform ].passwd0.focus(); return false; pattern = /[\w\d\+\.\-\&]{14,/g; if (!pattern.test(document.forms[ iform ].passwd0.value)) { alert("forkerte tegn i password. Følgende er tilladte:\na-z, A-Z, 0-9 og +._-&"); document.forms[ iform ].passwd0.focus(); return false; if (document.forms[ iform ].passwd0.value!= document.forms[ iform ].passwd1.value) { alert("fejl: De to passwords er IKKE ens!"); document.forms[ iform ].passwd0.focus(); return false; if (document.forms[ iform ].ufornavn.value.length < 2) { alert("fejl: Fornavn SKAL være mindst 2 tegn langt!"); document.forms[ iform ].ufornavn.focus(); return false; if (document.forms[ iform ].uefternavn.value.length < 2) { alert("fejl: Efternavn SKAL være mindst 2 tegn langt!"); document.forms[ iform ].uefternavn.focus(); return false; wfelt = document.forms[ iform ].u .value; if (wfelt.length < 6 ) { alert("fejl: adresse skal være på mindst 6 tegn!"); document.forms[ iform ].u .focus(); return false; return true; --></script> </head> <body class="gray" onload="document.forms[ iform ].bruid.focus();"> <h1> echo $titel </h1> if (isset($funktion) && $funktion == "upd") { connect($host, $username, $password); $sql = "select *"; $sql.= " from bruger"; $sql.= " where uid = ". $_GET[ bruid ]. " ;"; $result = query($sql); $matrix = row_at_a_time($result); $readonly = "readonly = \"readonly\""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./bruger_db.php?funktion=upd\""; $streng.= " onsubmit=\"return valider();\">"; else { $funktion = "ins"; $matrix[0] = ""; $matrix[1] = ""; $matrix[3] = ""; $matrix[4] = ""; $matrix[5] = ""; $readonly = ""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./bruger_db.php?funktion=ins\""; $streng.= " onsubmit=\"return valider();\">"; printf("%s\n", $streng); <table>

63 C.2: Authentific administrative scripts 63 <tr> <td align="right">bruger-id: </td> <td><input type="text" name="bruid" size="20" maxlength="16" value=" echo $matrix[0]" echo " ".$readonly /></td> </tr> <tr> <td align="right">password: </td> <td><input type="password" name="passwd0" size="45" maxlength="42" value=" echo $matrix[1]" /></td> </tr> <tr> <td align="right">gentag password: </td> <td><input type="password" name="passwd1" size="45" maxlength="42" value=" echo $matrix[1]" /></td> </tr> <tr> <td align="right">fornavn: </td> <td><input type="text" name="ufornavn" size="40" maxlength="40" value=" echo $matrix[3]" /></td> </tr> <tr> <td align="right">efternavn: </td> <td><input type="text" name="uefternavn" size="40" maxlength="40" value=" echo $matrix[4]" /></td> </tr> <tr> <td align="right"> </td> <td><input type="text" name="u " size="12" maxlength="12" value=" echo $matrix[5]" /></td> </tr> <tr> <td><input type="hidden" name="funktion" value=" echo $funktion " /></td> <td><input type="submit" value="ok" /></td> </tr> </table> </form> sidefod(false, false, xhtml ); </body> </html> bruger vis.php, vis brugere i tabelform, udvælg til ajourføring include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/ajourfør brugere"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select uid, ufornavn uefternavn as navn, upwdatotid, u "; $sql.= " from bruger"; $sql.= " order by ufornavn;"; $result = query($sql); $user_table = new TableHTMLupd(array("Bruger-id", "Navn", "Password fra", " ")); while ($arrow = row_at_a_time($result)) { $temp = strtotime($arrow[2]); $arrow[2] = date("d/m/y H:i:s", $temp); $user_table->addrow($arrow); $user_table->display_table(./bruger_form.php?funktion=upd, bruid ); print("<h2>klik på bruger-id for at ajourføre!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html>

64 64 Appendiks C: Authentific, baggrundskode bruger udpeg.php, vælg bruger til egen-ajourføring include("../support_auth/dbauth_setup.inc"); // bemærk at dette program include("../support_auth/faelles_funktioner.inc"); // autentificerer på anden vis! $meddelelse = ""; if (isset($_post[ submit ])) { // læse indtastede credentials oh hvis de ikke findes vis en fejlmedd + flg if (!($_POST[ sel_userid ] && $_POST[ sel_userpw ])) $meddelelse = "FEJL: Kombinationen bruger - password findes ikke."; else { // hvis fundet gå til bruger_form.php m header + brugerid upd connect($host, $username, $password); $sql = "select uid, upword"; $sql.= " from bruger"; $sql.= " where uid = ". $_POST[ sel_userid ]. " "; $sql.= " and upword = ". sha1($_post[ sel_userpw ]). " ;"; $rel = query($sql); if (tael($rel) == 1) header("location:./bruger_form.php?bruid=". $_POST[ sel_userid ]. "&funktion=upd"); else $meddelelse = "FEJL: Kombinationen bruger - password findes ikke."; // echo "<br /> ". sha1($_post[ sel_userpw ]). " <br />"; include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Bruger udpeges"; htmlhead($titel); print("<body class=gray>\n"); print(" <h1>".$titel."</h1>\n\n"); print(" <h2>brugervedligeholdelse af brugeroplysninger</h2>\n"); printf(" <p>%s</p>\n", $meddelelse); print(" <h3>legitimer dig venligst:</h3>\n\n"); print(" <table>\n"); print(" <form id= form22 method= post action= $PHP_SELF >\n"); print(" <tr><td>bruger Id:</td>\n"); print(" <td><input type= text name= sel_userid size= 20 maxlength= 16 /></td></tr>\n"); print(" <tr><td>password:</td>\n"); print(" <td><input type= password name= sel_userpw size= 45 maxlength= 42 /></td></tr>\n"); print(" <tr><td></td><td><input type= submit name= submit value= OK ></td>\n"); print(" </form>\n\n"); print(" </table>\n"); print("</body>\n"); print("</html>\n"); bruger vis slet.php, vis bruger i tabelform, udvælg til sletning include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/slet brugere"; htmlhead($titel); print("<body class=\"yellow\">\n"); connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select uid, ufornavn uefternavn as navn, upwdatotid, u "; $sql.= " from bruger"; $sql.= " order by ufornavn;"; $result = query($sql); $user_table = new TableHTMLupd(array("Bruger-id", "Navn", "Password fra", " ")); while ($arrow = row_at_a_time($result)) { $temp = strtotime($arrow[2]); $arrow[2] = date("d/m/y H:i:s", $temp); $user_table->addrow($arrow); $user_table->display_table(./bruger_db.php?funktion=del, bruid );

65 C.2: Authentific administrative scripts 65 print("<h2>klik på bruger-id for at slette!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> bruger db.php, databasemodul til brugere include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Ajourføre database, bruger"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); if ($_GET[ funktion ] == "ins") { $pwd = sha1($passwd0); $now = strftime(("%y-%m-%d %H:%M:%S"), mktime()); $sql = "insert into bruger"; $sql.= " (uid, upword, upwdatotid, ufornavn, uefternavn, u )"; $sql.= " values( $bruid, $pwd, $now, $ufornavn, $uefternavn, $u );"; elseif ($_GET[ funktion ] == "upd") { $sql = "select * from bruger where uid = $bruid ;"; $rel = query($sql); $arrow = row_at_a_time($rel); $sql = "UPDATE bruger set "; $sql.= "uid = $bruid "; if ($arrow[1]!= $passwd0) { // tester hash-pw med indt-pw $now = strftime(("%y-%m- %d %H:%M:%S"), mktime()); // men ved update er det krypterede vist i form $pwd = sha1($passwd0); // ændres det, krypteres det indtastede $sql.= ", upword = $pwd "; $sql.= ", upwdatotid = $now "; $sql.= ", ufornavn = $ufornavn "; $sql.= ", uefternavn = $uefternavn "; $sql.= ", u = $u "; $sql.= " where uid = $bruid ;"; elseif ($_GET[ funktion ] == "del") $sql = "delete from bruger where uid = $bruid ;"; query($sql); header("location:../index.php"); </body> </html> C.2.3 Databasetabellen gruppe gruppe form.php, inddatering og ajourføring af grupper include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Gruppe, inddata"; <head> <title> echo $titel </title> <link rel="stylesheet" type="text/css" href="../support_auth/style.css" /> <script type="text/javascript"><!-- function valider() { if (document.forms[ iform ].gid.value.length < 2) { alert("fejl: Gruppe-id SKAL være mindst 2 tegn langt!"); document.forms[ iform ].gid.focus(); return false;

66 66 Appendiks C: Authentific, baggrundskode if (document.forms[ iform ].gnavn.value.length < 2) { alert("fejl: Gruppenavn SKAL være mindst 2 tegn langt!"); document.forms[ iform ].gnavn.focus(); return false; return true; --></script> </head> <body class="gray" onload="document.forms[ iform ].gid.focus();"> <h1> echo $titel </h1> if (isset($funktion) && $funktion == "upd") { connect($host, $username, $password); $sql = "select *"; $sql.= " from gruppe"; $sql.= " where gid = ". $_GET[ gid ]. " ;"; $result = query($sql); $matrix = row_at_a_time($result); $readonly = "readonly = \"readonly\""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./gruppe_db.php?funktion=upd\""; $streng.= " onsubmit=\"return valider();\">"; else { $funktion = "ins"; $matrix[0] = ""; $matrix[1] = ""; $readonly = ""; $streng = "<form id=\"iform\""; $streng.= " method=\"post\""; $streng.= " action=\"./gruppe_db.php?funktion=ins\""; $streng.= " onsubmit=\"return valider();\">"; printf("%s\n", $streng); <table> <tr> <td align="right">gruppe-id: </td> <td><input type="text" name="gid" size="9" maxlength="8" value=" echo $matrix[0]"></td> </tr> <tr> <td align="right">gruppenavn: </td> <td><input type="text" name="gnavn" size="40" maxlength="40" value=" echo $matrix[1]"></td> </tr> <tr> <td><input type="hidden" name="funktion" value=" echo $funktion "></td> <td><input type="submit" value="ok"></td> </tr> </table> </form> </form> sidefod(false, false, xhtml ); </body> </html> gruppe vis.php, vis grupper i tabelform, udvælg til ajourføring include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/ajourfør grupper"; htmlhead($titel); print("<body class=\"grey\">\n");

67 C.2: Authentific administrative scripts 67 connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select gid, gnavn from gruppe order by gnavn;"; $result = query($sql); $user_table = new TableHTMLupd(array("Gruppe-id", "Navn")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./gruppe_form.php?funktion=upd, gid ); print("<h2>klik på gruppe-id for at ajourføre!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> gruppe vis slet.php, vis grupper i tabelform, udvælg til sletning include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/slet grupper"; htmlhead($titel); print("<body class=\"yellow\">\n"); connect($host, $username, $password); echo "<h1>".$titel."</h1>\n"; $sql = "select gid, gnavn from gruppe order by gnavn;"; $result = query($sql); $user_table = new TableHTMLupd(array("Gruppe-id", "Navn")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./gruppe_db.php?funktion=del, gid ); print("<h2>klik på gruppe-id for at slette!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html> gruppe db.php, databasemodul til grupper include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Ajourf~A re database, gruppe"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); if ($_GET[ funktion ] == "ins") { $sql = "insert into gruppe"; $sql.= " values( $gid, $gnavn );"; elseif ($_GET[ funktion ] == "upd") { $sql = "select * from gruppe where gid = $gid ;"; $rel = query($sql); $arrow = row_at_a_time($rel); $sql = "update gruppe set "; $sql.= "gid = $gid "; $sql.= ", gnavn = $gnavn "; $sql.= " where gid = $gid ;"; elseif ($_GET[ funktion ] == "del") $sql = "delete from gruppe where gid = $gid ;"; query($sql); header("location:../index.php"); </body> </html>

68 68 Appendiks C: Authentific, baggrundskode C.2.4 Databasetabellen berig, bruger-er-i-gruppe berig gruppe sel.php, udvælg gruppe til ajourføring af dens medlemmer include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: BeriG, Bruger er i gruppe"; htmlhead($titel); <body class="gray"> <h1> echo $titel; </h1> <h2>vælg gruppe</h2> <form action="berig_redirect.php" method="post"> <table> <tr> <td align="right">gruppe-id: </td> <td> connect($host, $username, $password); $sql = "select gid from gruppe order by gid;"; $resultat = query($sql); selector($resultat, grpid, false); </td> </tr> <tr> <td></td> </tr> <tr> <td><input type="submit" name="funktion" value="bruger ind"></td> <td><input type="submit" name="funktion" value="bruger ud"></td> </tr> </table> </form> </form> sidefod(false, false, xhtml ); </body> </html> berig vis.php, vis gruppemedlemmer i tabelform include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis brugere i grupper"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); print("<h1>".$titel."</h1>\n"); $sql = "select gruppe.gid, gnavn, ufornavn uefternavn as navn, u "; $sql.= " from berig, gruppe, bruger"; $sql.= " where gruppe.gid = berig.gid"; $sql.= " and bruger.uid = berig.uid"; $sql.= " order by gnavn;"; $result = query($sql); $user_table = new TableHTML(array("Gruppe", "Gruppenavn", "Bruger", " ")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./index.php, gid ); print("<p></p>");

69 C.2: Authentific administrative scripts 69 sidefod(../index.php, false, xhtml ); </body> </html> berig vis ind.php, vis /tilføj gruppemedlemmer include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Vis/tilføj gruppemedlemmer"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); print("<h1>".$titel."</h1>\n"); $sql = "select uid from berig where gid = ".$_GET[ grpid ]." order by uid;"; $result = query($sql); $user_table = new TableHTML(array($_GET[ grpid ]." s brugere")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(); print(" <form action=\"./berig_db.php?funktion=ins\" method=\"post\">\n"); print(" <p>\n"); $sql = "select uid from bruger order by uid;"; $resultat = query($sql); selector($resultat, uid, false); print(" <input type=\"hidden\" name=\"grpid\" value=\"". $_GET[ grpid ]."\" />\n"); print(" <input type=\"submit\" value=\"indsæt\" />\n"); print(" </p>\n"); print(" </form>\n"); print(" <p> </p>\n"); sidefod(../index.php, false, xhtml ); </body> </html> berig vis slet.php, vis/slet gruppemedlemmer include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/table_class.inc"); include("../support_auth/table_class_html_upd.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Slet gruppemedlemmer fra gruppen"; htmlhead($titel); print("<body class=\"yellow\">\n"); $gid = $_GET[ grpid ]; connect($host, $username, $password); print("<h1>".$titel."</h1>\n"); $sql = "select uid from berig where gid = ".$gid." order by uid;"; $result = query($sql); $user_table = new TableHTMLupd(array($gid." s brugere")); while ($arrow = row_at_a_time($result)) $user_table->addrow($arrow); $user_table->display_table(./berig_db.php?funktion=del&grpid=.$gid, uid ); print("<h2>klik på bruger-id for at slette!</h2>"); sidefod(../index.php, false, xhtml ); </body> </html>

70 70 Appendiks C: Authentific, baggrundskode berig db.php, databasemodul til bruger-er-i-gruppe include("../support_auth/auth_implement.inc"); include("../support_auth/dbauth_setup.inc"); include("../support_auth/faelles_funktioner.inc"); include("../support_auth/xhtml11_top.inc"); $titel = "Authentific: Ajourf~A re database, berig"; htmlhead($titel); print("<body class=\"grey\">\n"); connect($host, $username, $password); if ($_GET[ funktion ] == "ins") { $sql = "insert into berig"; $sql.= " values( $grpid, $uid );"; elseif ($_GET[ funktion ] == "del") $sql = "delete from berig where gid = $grpid and uid = $uid ;"; query($sql); header("location:../index.php"); </body> </html>

71 Bilag D PHP Objektorientering Det blev nævnt i rapporten, at et biprodukt af udviklingsprocessen var et særdeles nyttigt koncept omkring et klassehierarki til beskrivelse af tabeller. Anvendelsesområdet er databaserelationer, tabeller, der skal vises frem som (X)HTML-tabeller. Der skabes en tabelklasse med nogle feltvariabler, en konstruktør til instantiering af objekter hørende til klassen, samt et antal metoder til henholdsvis indsættelse og fremvisning af objekter af tabel-klassen. Æren for den fundamentale ide tilkommer Matt Zandstra, idet den stammer fra Zandstra (2000). Herunder ses et UML 1 -klassediagram til beskrivelse af de derefter følgende klasser. Figur D.1: Klassediagram over tabelklassehierarkiet med nedarvning. Det fremgår af diagrammet, at de tre subklasser til Table, alle redefinerer metoden displaytable(). Det betyder, at hver implementering af en XHTML-tabel har sin egen display-metode, valgt blandt tre varianter. Table-klassens egen variant vil vise tabellen som en.csv-fil, kommaseparerede linier. Dette kan fx. benyttes til export af data, der siden fx. kan importeres af et regnearksprogram. 1 Unified Modelling Language 71

72 72 Appendiks D: PHP Objektorientering Enhver af de tre varianter kan generere XHTML til fremvisning af en hvilken som helst tupel læst i en database. Det betyder indirekte, at en programmør kan producere programmer til fremvisning af databaserelationer i XHTML på samlebånd med en særdeles lav udviklingstid. Med andre ord har objektorienteringen i PHP bidraget til effektivisering af udviklingsprocessen. D.1 PHP-classes table class.inc class Table { var $table_array = array(); var $column_headers = array(); var $columns; function Table($headers) { $this->column_headers = $headers; $this->columns = count($headers); function addrow($row) { if (count($row)!= $this->columns) return false; array_push($this->table_array, $row); return true; function addrowassoc($row_assoc) { if (count($row)!= $this->columns) return false; $row = array(); foreach ($this->column_headers as $header) { if (!isset($row_assoc[$header])) $row_assoc[$header] = " "; $row[] = $row_assoc[$header]; array_push($this->table_array, $row); return true; function display_table() { print("<pre>"); $sep = ""; foreach ($this->column_headers as $header) { printf("%s<b>\"%s\"</b>", $sep, $header); if ($sep == "") $sep = ","; print("\n"); foreach ($this->table_array as $y) { $sep = ""; foreach ($y as $x) { printf("%s\"%s\"", $sep, $x); if ($sep == "") $sep = ","; print("\n"); print("</pre>"); table class html.inc class TableHTML extends Table { function TableHTML($headers) { Table::Table($headers);

73 D.1: PHP-classes 73 function display_table() { print("\n<table class=\"borders\"><tr>\n"); foreach ($this->column_headers as $header) printf("<th class=\"borders\">%s</th>\n", $header); print("</tr>\n"); foreach ($this->table_array as $row=>$cells) { print("<tr>\n"); foreach ($cells as $cell) printf("<td class=\"borders\">%s</td>\n", $cell); print("</tr>\n"); print("</table>\n"); table class html upd.inc class TableHTMLupd extends Table { function TableHTMLupd($headers) { Table::Table($headers); function display_table($prog,$key) { print("\n<table class=\"borders\"><tr>\n"); foreach ($this->column_headers as $header) printf("<th class=\"borders\">%s</th>\n", $header); print("</tr>\n"); foreach ($this->table_array as $row=>$cells) { print("<tr>\n"); $first = true; foreach ($cells as $cell) if ($first == true) { printf("<td class=\"borders\"><a href=\"%s&%s=%s\">%s</a></td>\n", $prog, $key, $cell, $ce $first = false; else printf("<td class=\"borders\">%s</td>\n", $cell); print("</tr>\n"); print("</table>\n"); table class html program upd.inc class TableHTMLprogramupd extends Table { function TableHTMLprogramupd($headers) { Table::Table($headers); function display_table($prog,$key1, $key2) { print("\n<table class=\"borders\"><tr>\n"); foreach ($this->column_headers as $header) printf("<th class=\"borders\">%s</th>\n", $header); print("</tr>\n"); foreach ($this->table_array as $row=>$cells) { print("<tr>\n"); $sw = 1; foreach ($cells as $cell) { if ($sw == 1) { $pathid = $cell; else if ($sw == 2) { $pid = $cell; printf("<td class=\"borders\"><a href=\"%s&%s=%s&%s=%s\">%s</a></td>\n", $prog, $key2, $pa if ($sw!= 2) printf("<td class=\"borders\">%s</td>\n", $cell); $sw++; print("</tr>\n");

74 74 Appendiks D: PHP Objektorientering print("</table>\n"); Et eksempel på anvendelse På baggrund af klasserne i dette hierarki, kan produceres webprogrammer til fremvisning af tabeller. Her skal vises et par eksempler. Først person vis uop.php fra testscenariet: include("../support/db_setup.inc"); include("../support/faelles_funktioner.inc"); include("../support/table_class.inc"); // include tabelklassedefinitionen include("../support/table_class_html.inc"); // include htmlextension af class table include("../support/xhtml11_top.inc"); $titel = "Skole: Vis person"; htmlhead($titel); print("<body class=\"grey\">\n"); connect_role($host, $username, $password, $role1); echo "<h1>".$titel."</h1>\n"; $sql = "SELECT * FROM person order by person_id;"; $result = query($sql); $user_table = new TableHTML(array("Person", "Cprnr", "Fornavn", "Efternavn", "Adresse", "Postnr", "Land", "Lærer", "Stud.")); // instantiering af ny tablehtml while ($arrow = row_at_a_time($result)) { switch ($arrow[7]) { case B : $arrow[7] = X ; $arrow[8] = $arrow[7]; break; case L : $arrow[7] = X ; $arrow[8] = ; break; case S : $arrow[7] = ; $arrow[8] = X ; break; default: $arrow[7] = ; $arrow[8] = ; break; $user_table- >addrow($arrow); // tilføj databaseindhold til tablehtml $user_table- >display_table(); // anvend tablehtmls metode til display!! sidefod(../index.php, false, xhtml ); </body> </html> Den viste kode viser, når den bliver udført, skærmbilledet i figur D.2: Simpel kode, der, bortset fra toppen af programmet til produktion af XHTML-headeren, ikke skjuler nogen kompleksitet. Et andet eksempel til sammenligning Bruger vi i stedet grundklassen table sammen med en anden nedarvning, som i følgende eksempel fra person vis.php: include("../support_auth/auth_implement.inc"); include("../support/db_setup.inc");

75 D.1: PHP-classes 75 Figur D.2: Display fra program med brug af standardiseret tabel-klasse.

76 76 Appendiks D: PHP Objektorientering include("../support/faelles_funktioner.inc"); include("../support/table_class.inc"); // include table class include("../support/table_class_html_upd.inc"); // include variant til update include("../support/xhtml11_top.inc"); $titel = "Skole: Vis/ajourfør person"; htmlhead($titel); print("<body class=\"grey\">\n"); connect_role($host, $username, $password, $role1); echo "<h1>".$titel."</h1>\n"; $sql = "SELECT * FROM person order by person_id;"; $result = query($sql); $user_table = new TableHTMLupd(array("Person", "Cprnr", "Fornavn", "Efternavn", "Adresse", "Postnr", "Land", "Lærer", "Stud.")); // instantiering af tabel while ($arrow = row_at_a_time($result)) { switch ($arrow[7]) { case B : $arrow[7] = X ; $arrow[8] = $arrow[7]; break; case L : $arrow[7] = X ; $arrow[8] = ; break; case S : $arrow[7] = ; $arrow[8] = X ; break; default: $arrow[7] = ; $arrow[8] = ; break; $user_table->addrow($arrow); // fyld op fra databasen $user_table- >display_table(./person_form.php?funktion=upd, person_id ); // display med links print("<h2>klik på person for at ajourføre!</h2>"); // til update sidefod(../index.php, false, xhtml ); </body> </html> Denne kode giver skærmbilledet, der ses i figur: D.3 Det kræver et lidt nærmere eftersyn Figur D.3: Display fra program med brug af en anden standardiseret tabel-klasse. Her med links til opdateringsprogrammet. for at opdage, at den eneste forskel på de to figurer er, at person-feltet i den anden er et