DEF-nøglen. Forslag til realisering af fælles brugervalidering til DEF-tjenester

DEF-nøglen Forslag til realisering af fælles brugervalidering til DEF-tjenester UNI C August 1999

DEF-nøglen Forslag til realisering af fælles brugervalidering til DEF-tjenester UNI C August 1999 Version 1.1 Af Erik Bertelsen, Anders Bandholm K:\ENH\MM\SBT\3039 defnøgle\def-nøgle-rapport.doc

1 Introduktion 1 Indhold 1 Introduktion... 3 1.1 Undersøgelsens baggrund og formål... 3 1.2 Undersøgelsens indhold... 3 1.3 Ønsker til DEF-nøglen... 4 2 Anvendelse af on-line ressourcer i DEF... 6 2.1 Bibliotekernes tjenester... 6 2.2 Web-tjenester og andre tjenester på nettet... 6 2.3 DEF-nøglen... 7 3 Begreber og protokoller... 10 3.1 AAA... 10 3.2 Client-server begrebet... 13 3.3 Cookies... 15 3.4 Certifikater... 15 3.5 Proxy-løsningen... 16 3.6 LDAP... 18 4 Mulige løsningskomponenter... 19 4.1 Cookies... 19 4.2 Digitale certifikater... 20 4.3 Proxy... 21 4.4 LDAP... 22 4.5 SkoDa... 22 4.6 ISOS/Athens... 23 4.7 IBM SecureWay Policy Director... 23 4.8 Delkonklusioner... 24 5 Systemmodel... 27 5.1 DEF-nøglen i en proxy-løsning... 27 5.2 Den decentraliserede model... 28

1 Introduktion 2 5.3 Den centrale model... 29 5.4 Sammenligning af de to modeller... 31 6 Opsamling... 34 6.1 Hovedkonklusioner... 34 6.2 Omkostninger... 35 7 Bilag... 38

1 Introduktion 3 1 Introduktion I denne rapport præsenterer vi nogle anbefalinger til etablering af DEF-nøglen, dvs. en samlet adgangskontrol til de Web-ressourcer, som DEF-bibliotekerne tilbyder deres samlede brugerskare. Efter en beskrivelse af rapportens baggrund (kap. 1) og forskningsbibliotekernes tilbud af tjenester på og via nettet (kap. 2) giver vi en oversigt over de begreber (kap. 3), som er vigtige for at forstå den systemmodel, som foreslås i kap. 5 baseret på nogle konklusioner i kap. 4. Endelig gives nogle samlede anbefalinger i kap. 6. 1.1 Undersøgelsens baggrund og formål Undersøgelsen skal med udgangspunkt i tidligere udarbejdede rapporter give DEF et beslutningsgrundlag for, hvordan man ønsker at implementere en for brugerne sammenhængende adgangskontrol (DEF-Nøglen) til ressourcer tilbudt via DEF. Denne rapportering er foretaget af UNI C i maj og juni 1999 baseret på foreliggende rapport og notater, møder i DEF-nøglegruppen, samt interviews med repræsentanter for nogle af de store forskningsbiblioteker. Ved DEF-nøglen forstår vi her den mekanisme, der anvendes af de onlinesystemer, der udgør DEF, således at brugerne i hver anvendelsessession af DEFtjenester kun skal identificere sig en gang, og således at bibliotekerne får de nødvendige oplysninger til den økonomiske håndtering, samt til ekspedition af papirbaserede dokumenter. 1.2 Undersøgelsens indhold Ifølge aftalen om denne udredning skal rapporteringen omfatte følgende: 1. Hvilke tekniske muligheder er der for at realisere en løsning, der opfylder de konceptuelle krav? Det skal således undersøges, hvilke eksisterende metoder og værktøjer, der kan anvendes til at realisere DEF-nøglen, og hvilken yderligere udvikling, der eventuelt vil være nødvendig. Det skal således beskrives, om der er forskellige mulige løsninger, og i givet fald hvilke. 2. Der skal redegøres for, om en løsning kan virkeliggøres i flere trin, fra en mere enkel løsning til en komplet, og hvordan. Der er et presserende behov for at få en styring af adgang til fx elektroniske fuldtekster. En trinvis realisering af DEF-nøglen kan tage udgangspunkt i opfyldelsen af dette behov. - Der skal redegøres for tidsrammerne for virkeliggørelsen af de løsninger, der foreslås.

1 Introduktion 4 3. Det skal undersøges, hvordan de deltagende biblioteker med de IT-systemer, de råder over, er i stand til at medvirke ved realiseringen af DEF-nøglen, og hvad der eventuelt skal til af ekstra investeringer. Som et særligt problem skal det udredes, hvordan små forskningsbiblioteker med beskedent eget ITudstyr kan deltage i en sådan fælles brugeradministration. 4. Der ønskes så vidt muligt et økonomisk overslag over omkostningerne ved de foreslåede løsninger. 1.3 Ønsker til DEF-nøglen Adgangen til ressourcerne i DEF styres vha. en fælles brugervalidering, DEFnøglen. Listen nedenfor er baseret på et udkast til design af DEF-nøglen udarbejdet af Karl Krarup: 1. DEF-nøglen bygger på et fælles format, som på sikker måde identificerer brugeren og giver: brugerens institutionelle tilhørsforhold, kategori af brugerrettighed, som pågældende institution meddeler, DEF kategori, som bestemmer adgang til DEF ressourcer i henhold til aftaler mellem udbydere. DEF-brugerkategorier kan fx betyde, at alle, der tilhører en kreds af institutioner, har visse rettigheder på alle disse institutioner. Ydelserne kan være differentierede efter brugerens institutionstilknytning fx beroende på samarbejdsaftaler mellem to eller flere institutioner. De enkelte centre og biblioteker fastlægger selv adgangsrettigheder med relation til DEF-nøglens brugerkategorier for de informationsressourcer, som pågældende center selv giver adgang til direkte eller indirekte. 2. Adgang til DEF-ressourcer skal kunne ske vha. DEF nøglen uanset brugerens arbejdssted eller opholdssted. 3. Alle DEF-biblioteker og centre vil fremover kræve validering via DEFnøglen. 4. DEF-nøglen understøttes af alle DEF-anerkendte biblioteker, dvs. registreringen sker decentralt i overensstemmelse med gældende format og fælles anerkendte adgangskategorier. 5. Den udstedende institution kan bruge DEF-nøglen på samme måde, som den aktuelle lokale brugerregistering og dermed afgrænse adgang til betalingsbaserede ressourcer som kun er betalt for brugere med tilknytning til pågældende institution/campus/bibliotek. 6. Fastlæggelsen af adgangsrettigheder beror på centret selv, de bevillingsmæssige forudsætninger og kontraktforhold knyttet til de enkelte informationsressourcer.

1 Introduktion 5 7. Adgangsrettigheder på de enkelte centre beskrevet ved brugerkategori og institutionstilknytning skal være offentligt tilgængelige på centrets web.

2 Anvendelse af on-line ressourcer i DEF 6 2 Anvendelse af on-line ressourcer i DEF Her beskriver vi nogle anvendelsesscenarier og nogle forudsætninger, hvorpå forslaget til DEF-nøglen bygger. DEF-samarbejdet er et samarbejde mellem forskningsbibliotekerne i Danmark, og i første omgang ser vi på de 12 store forskningsbiblioteker, deres brugere og deres tjenester. Samarbejdet skal efterfølgende kunne udbygges til at dække en betydeligt større del af forskningsbibliotekerne, og desuden skal samarbejdet med andre bibliotekstyper og tjenesteudbydere i Danmark samt med biblioteker i udlandet også passe ind i modellen. 2.1 Bibliotekernes tjenester Forskningsbibliotekerne udbyder forskellige typer tjenester, som skal integreres i DEF, bl.a. OPAC-tjenester, dvs. adgang til de egentlige bibliotekssystemer med kataloger, beholdningsoplysninger og lånefunktioner mv. Elektroniske tjenester, der udbydes fra biblioteket, fx databaser. Tjenester, som udbydes fra andre leverandører (fx forlag), men som formidles gennem biblioteket. Endvidere kan netværkstjenesterne anvendes til at formidle tjenester, som ikke i sig selv formidles via nettet, fx bestilling af dokumenter, der skal sendes med posten eller bringes til brugeren. Ud fra de gennemførte interviews danner der sig et billede af, at en del af bibliotekerne i fremtiden selv vil udbyde færre on-line tjenester end i dag, idet disse ofte vil blive formidlet af bibliotekerne direkte fra leverandørerne af disse tjenester. Dette billede suppleres ved, at der på enkelte biblioteker og andre institutioner tilbydes nye elektroniske tjenester, fx artikeldatabaser (som DADS) og Webindekser. 2.2 Web-tjenester og andre tjenester på nettet Det er også vigtigt for etableringen af et samlet udbud af netværkstjenester, som forventes at skulle indgå i DEF, at man er klar over, hvilke adgangsprotokoller, der anvendes i kommunikationen mellem brugerens arbejdsplads og tjenesterne, samt hvilket programmel, der skal installeres på brugerens arbejdspladsmaskine. I denne rapport beskriver vi efter aftale med DEF Nøglegruppen specifikt Webapplikationer, hvor brugeren fra sin arbejdspladsmaskine anvender en Web-

2 Anvendelse af on-line ressourcer i DEF 7 browser som klientprogrammellet i kommunikationen med servere, og hvor vi anvender http som bæreprotokol på nettet. Derfor behandler vi ikke de af bibliotekernes netværkstjenester, som i dag formidles vha. telnet-protokollen. Vi går her ud fra, at disse typisk ældre tjenester vil blive afløst af Web-baserede tjenester i fremtiden, og at de derfor ikke vil indgå i den fremtidige DEF-løsning. Desuden findes der et antal andre netværksprotokoller, som bibliotekerne senere kan overveje betydningen af som protokoller mellem slutbrugerarbejdspladserne og det forreste lag af servere. Her kan vi nævne protokoller som Z39.50, som helt klart har en væsentlig rolle at spille i servernettet bag de Web-servere, som har den direkte forbindelse med brugerne, men hvis rolle i den direkte klientkommunikation ikke er helt så oplagt. 2.3 DEF-nøglen En del af bibliotekernes netværkstjenester vil være frit tilgængelige for alle, medens andre kræver, at brugeren har identificeret sig over for systemet og at denne identifikation anvendes til at beslutte, om brugeren har adgang. Metoden til at gennemføre denne identifikation og validering kalder vi DEF-nøglen. Fra nogle sider fremføres det, at mange netværkssessioner med DEF kun vil resultere i søgning i og visning af dokumenter, som er frit tilgængelige for alle. Det er her et åbent spørgsmål, om brugere af DEF skal validere sig ved starten af en DEF-session og måske dermed kunne nyde godt af en personlig startside i portalen eller andre personligt definerede opsætninger, eller om brugeren først skal afkræves valideringsoplysninger, når han eller hun forsøger at få adgang til ressourcer, som er underlagt adgangskontrol. Validering vha. DEF-nøglen styrer adgang til at se og hente digitale ressourcer hos bibliotekerne, men forudses også anvendt til at validere adgangen til at modtage ikke-digitale tjenester, fx bestilling af fjernlån og fremsendelse af kopier af tidsskriftartikler. 2.3.1 Brugerkategorier Når en bruger er defineret som bruger af ét bibliotek, vil denne brugeridentifikation også via DEF-nøglen kunne anvendes til at tillade brugeren adgang til tjenester hos andre biblioteker, som indgår i DEF-netværket. Det forventes, at hvert deltagende bibliotek vil dele sine brugere op i et mindre antal kategorier 1, og at det vil indgå bilaterale aftaler med andre biblioteker om, hvilke tjenester på de andre biblioteker, som er tilgængelige for medlemmer af de enkelte brugerkategorier. Ud fra de gennemførte samtaler med nogle af de invol- 1 Når vi i denne rapport anvender begrebet kategori, mener vi konkret de kategorier (DEF-kategorier), som anvendes i definitionen af adgangsaftalerne bibliotekerne imellem. Disse kategorier behøver således ikke at afspejle de kategorier direkte, som anvendes i de lokale bibliotekssystemer.

2 Anvendelse af on-line ressourcer i DEF 8 verede biblioteker forventer vi ikke, at alle bibliotekerne vil anvende de samme kategorier, og systemet skal derfor kunne håndtere, at hvert bibliotek selv definerer sine egne kategorier. Afhængigt af kategorien af tjenesterne og af de indgåede aftaler, vil det tjenesteudbydende bibliotek i en del tilfælde kunne afgøre adgangsvalideringen på basis af oplysninger om brugerens hjemmebibliotek og brugerkategori uden at skulle differentiere på basis af den enkelte brugers identifikation. Systemet skal ideelt kunne håndtere, at en bruger kan være låner ved flere biblioteker, men da det er en del af konceptet for DEF-nøglen, at en bruger tilhører præcis én kategori for hvert bibliotek, vil konsekvensen ofte være, at en bruger må gennemføre en ny login, hvis vedkommende ønsker at få adgang til ressourcer ud fra en anden kategori end den i øjeblikket aktive. 2.3.2 Adgangskontrol og betaling I denne rapport beskriver vi primært anvendelse af brugervalidering og dermed af DEF-nøglen som en metode til at identificere brugeren og til at afgøre, om brugeren har adgang til en given ressource. Hvis anvendelsen af disse ressourcer udløser en forbrugsafhængig betaling, kan DEF-nøglen (udvides til at) anvendes til at generere forbrugsoversigter og dermed fakturaer, men det indgår ikke i dette udredningsarbejde. Det er ikke på nuværende tidspunkt klart, hvor mange netværksydelser, som vil være tilgængelige på fastprisvilkår (herunder gratis) og hvor mange, som skal afregnes efter aktuelt forbrug. 2.3.3 Single Sign-on DEF-nøglen er et forsøg på at realisere den mekanisme, som andetsteds også bliver kaldt Single Sign-on. I denne rapport benyttes begrebet Single Sign-on kun om rigtig eller en komplet Single Sign-on, som vi forstår som en mekanisme, hvor brugeren kun identificerer sig én gang i en netværkssession, selv om den omfatter kommunikation med flere servere, evt. fordelt på flere institutioner. Single Sign-on i denne betydning kan selvfølgelig kun etableres mellem samarbejdende tjenesteudbydere, men DEF er jo netop et eksempel på et sådant samarbejde. Se afsnit 3.1.4 for en uddybelse af begrebet Single Sign-on. Opgaven går derfor ud på at definere DEF-nøglen i forhold til Mængden af samarbejdende tjenesteudbydere og deres tjenester fordelt på servere og institutioner. Mængden af understøttede netværksprotokoller.

2 Anvendelse af on-line ressourcer i DEF 9 Mængden af understøttede server- og klientplatforme, både mht. hardware og software. Valideringsteknikker, både som set af brugeren og som implementeret teknisk. Brugernes placering i forhold til deres arbejdsplads, bibliotek eller andre steder. 2.3.4 Adgangskontrolteknikker I biblioteksverdenen er IP-nummerbaseret validering meget udbredt i dag, da den tilbyder et sikkerhedsniveau, som er acceptabelt for informationsudbyderne, fx forlag. Denne valideringsform er dog meget ufleksibel, idet den ikke tillader en person at anvende bibliotekstjenesterne fra andre fysiske steder end de, hvis IPnumre er på positivlisten bl.a. er adgang fra hjemmet oftest blokeret. Det er et krav fra DEF, at adgangskontrollen fremover baserer sig på identifikation af personen uafhængigt af vedkommendes placering, og derfor fokuserer vi på brugernavnsvalidering, og IP-nummerbaseret validering indgår ikke i den overordnede definition af DEF-nøglen. Dog kan vi forvente, at den del af de lokale systemer fortsat vil anvende IP-nummerbaseret validering lokalt.

3 Begreber og protokoller 10 3 Begreber og protokoller For at give et fælles grundlag for vurdering af de konklusioner og anbefalinger, som gives i denne rapport, er det vigtigt, at alle har et fælles begrebsmæssigt grundlag at vurdere disse konklusioner ud fra. I dette kapitel beskriver vi nogle begreber, standarder og protokoller, som er relevante for at konstruere DEF-nøglen. 3.1 AAA I forbindelse med adgangskontrol til netværksressourcer er der 3 begreber, som er i fokus (her angivet med de engelske termer): Authentication Authorisation Accounting Samlet kendes disse begreber også som AAA ( Triple-A ) 2. I denne rapport bruger vi denne betegnelse for de tilhørende begreber, men ikke som identifikation af konkrete produkter. I denne rapport beskæftiger vi os især med de to første af A erne, dvs. Authentication og Authorisation, men vi anvender alligevel den gængse term AAA, også selv om ikke alle 3 A-begreber er relevante i den givne sammenhæng. Disse begreber er de bærende begreber, når vi skal definere DEF-nøglen og dens anvendelse. Mange af de øvrige begreber beskriver mekanismer, som kan indgå som byggeklodser til at realisere AAA-funktionaliteten af DEF-nøglen. Når vi i resten af dette kapitel nævner AAA-services eller AAA-tjenester, tænker vi på autentificerings- og/eller autorisationsservere, uanset om de er distribuerede eller centrale og uafhængigt af, om de står hos bibliotekerne eller andre steder på nettet. Når vi senere beskriver mulige systemmodeller for DEF-nøglen, vil disse spørgsmål dukke op igen og være væsentlige for vurderingen af de forskellige modeller. 2 Det kan nævnes, at IETF (som er det forum, hvor de fleste Internet-standarder er udviklet) har etableret en AAA-arbejdsgruppe, som arbejder med at afklare begreberne og evt. definere protokoller til generel håndtering af AAA-problematikkerne. Denne gruppe har i juni 1999 produceret et arbejdsdokument ( work in progress ) under titlen AAA Authorization Architecture and Requirements.

3 Begreber og protokoller 11 3.1.1 Authentication Det helt basale begreb for at realisere DEF-nøglen er Authentication, på halvgodt dansk: autentificering. Kernen i dette begreb er, at brugeren identificerer sig over for et edb-system, fx ved at opgive et brugernavn eller ved at besidde et bevis på sin identitet (fx certifikat), samt at brugeren beviser sin identitet, fx ved at oplyse kodeord (password) eller PIN-kode. Autentificering af brugeren kan foregå på flere måder, men hvis sikkerheden for korrekt autentificering skal være bare nogenlunde til stede, snakker vi bl.a. om autentificering vha. brugernavn og kodeord, stærk autentificering, fx vha. digitale certifikater, smartcards eller lignende. Når et system har autentificeret brugeren (og dermed tilladt adgang til systemet), kan det efterfølgende anvende brugerens autentificerede identitet til at realisere authorisation eller accounting. 3.1.1.1 Brugernavne og kodeord Sikkerhedsniveauet i denne teknik afhænger i høj grad af, om brugerne er omhyggelige med at holde kodeordet hemmeligt, og at de ikke vælger kodeord, som er lette at gætte. Hvis brugerne anvender deres brugernavn og kodeord omhyggeligt, giver denne form for autentificering et middel sikkerhedsniveau. Hvis et særligt højt sikkerhedsniveau er krævet, må andre teknikker tages i anvendelse. Anvendelse af brugernavne og kodeord er bl.a. problematisk, hvis det er muligt for uautoriserede personer at aflytte netværkstrafikken, hvorfor der kan være et argument for, at de sendes over krypterede netværksforbindelser, hvilket i Websammenhæng kan være anvendelse af SSL 3, som har været og er den mest udbredte standard for krypteret adgang til Web-servere. I forbindelse med Web-tjenester ser vi ofte begrebet Basic Authentication anvendt. Dette er en mekanisme, hvormed Web-serveren for visse eller alle ressourcer på serveren kan kræve brugeren autentificeret med brugernavn og kodeord. For brugeren ses dette ved, at browseren viser en dialogboks, hvor brugeren skal angive sit brugernavn og kodeord. Hvorledes serveren kontrollerer gyldigheden af det oplyste brugernavn og kodeord er ikke specificeret som en del af Basic Authentication. I simpleste tilfælde sker det ved opslag i en simpel password-fil, men opslag i directories og andre databaser er også mulige. Stort set alle Webservere understøtter Basic Authentication, men de konkrete opslagsteknikker kan variere fra server til server. 3 SSL (Secure Socket Layer) er i dag den fremherskende protokol, når der skal foretages sikker kommunikation mellem browsere og Web-servere. SSL giver kryptering af datatransmissionen samt autentificering af serveren (og evt. klienten).

3 Begreber og protokoller 12 Basic Authentication virker kun over for en enkelt server (ved skift til en ny server kommer der altid en ny brugernavnsdialog), og derfor er den primært relevant i forbindelse med DEF-nøglen, hvis der satses på en stram udgave af proxyløsningen, hvor al kommunikation med brugeren foregår gennem samme server, nemlig proxy en. Ved denne teknik kender serveren brugerens brugernavn og må selv slå andre oplysninger om brugeren op i den tilhørende brugerdatabase eller AA-server (fx kategori(er) eller forsendelsesadresse). 3.1.1.2 Stærk autentificering En anden måde at autentificere brugeren på bygger på digitale certifikater. Dette kaldes undertiden stærk autentificering. Det digitale certifikat indeholder en identifikation af brugeren samt evt. øvrige oplysninger. Det hele er underskrevet digitalt af en certificeringsmyndighed. Ud over besiddelse af certifikatet, skal brugeren normalt også give en PIN-kode eller et kodeord for at aktivere certifikatet. Hvis certifikatet opbevares digitalt i en fil i brugerens PC, kan brugeren kun anvende dette certifikat fra andre maskiner, hvis certifikatet installeres der. En sikrere måde at opbevare certifikatet på er at placere det på et magnet- eller chipkort, idet brugeren så dels skal besidde dette kort og samtidig kende kodeordet for at kunne anvende certifikatet. I denne situation kan man ikke bruge (en kopi af) en andens chipkort uden også at kende kodeordet. Det største og umiddelbart blokerende problem ved denne metode er, at den kræver hardwareudstyr installeret i alle maskiner, hvorfra brugerne ønsker at anvende systemerne. 3.1.2 Authorisation Når en bruger er blevet autentificeret over for et system (en server), kan denne server efterfølgende anvende den autentificerede identitet til at afgøre, hvorvidt og hvilken adgang, brugeren har til givne ressourcer på serveren. Denne proces kaldes authorisation. Sådanne autorisationer kan implementeres meget bredt eller meget specifikt over flere dimensioner: Alle brugere har adgang til en given ressource, specifikke navngivne brugere har det, eller visse grupper af brugere har det. I DEF-sammenhæng forstår vi, at den hyppigste form vil være den sidste, idet brugerne inddeles i kategorier, som er grundlaget for DEF s autorisationsaftaler. Autorisationen kan gælde alle, enkelte eller grupper af ressourcer på serveren, idet der kan tilknyttes autorisation til directorystrukturer, filer eller helt ned til poster og felter i databaser. De rettigheder, som brugeren autoriseres til, fx læsning, overførsel, opdatering, tilføjelse af nye ressourcer, ændring af autorisationsreglerne, osv.

3 Begreber og protokoller 13 Ofte beskrives autorisationsmekanismen i form af autorisationspolitikker, som igen er opbygget af såkaldte Access Control Lists (ACL). En sådan ACL består overordnet set af en kombination af elementerne i ovenstående liste, dvs. den udtrykker, hvem der må gøre hvad ved hvilke ressourcer. Disse ACL er kan opbevares og vedligeholdes i de enkelte servere eller i særskilte autorisationsservere, som evt. betjener flere servere. 3.1.3 Accounting Accounting er det at opsamle statistikker om brugernes autentificerede eller anonyme anvendelse af systemerne, som kan danne grundlag for forbrugsopgørelser og dermed beregning af betalingsgrundlaget for tjenesten. Accounting behandles ikke i nærmere detalje i denne rapport, og en implementation heraf vil ske i de enkelte systemer under indtryk af anvendelsesaftalerne mellem bibliotekerne. 3.1.4 Single Sign-on Ved Single Sign-on forstår vi i denne rapport det, at en bruger kun skal identificere sig (autentificeres) én gang i en Web-session for at kunne anvende DEF s tjenester, også selv om de i virkeligheden er spredt over flere servere hos flere deltagende institutioner. Formålet med DEF-nøglen er kort sagt at kunne realisere en Single Sign-on over for DEF s netformidlede ressourcer. Single Sign-on kan implementeres i en skrabet udgave, hvor brugeren på alle tjenesteudbydere (servere) i det samarbejdende netværk logger sig ind til alle tjenester (som kræver brugervalidering) med det samme brugernavn og kodeord. I denne rapport vil denne form for adgangskontrol blive kaldt Single Account. Selvom Single Account altså kan betegnes som en skrabet udgave af Single Signon, er det stadig et fremskridt fra den situation, som vi ofte ser i dag, hvor brugeren skal have oprettet et nyt brugernavn med kodeord, når han eller hun ønsker at anvende en ny tjeneste. 3.2 Client-server begrebet Vi anvender begreberne klient og server gentagne gange i denne rapport som betegnelse for de programmer/systemer, som beder om og modtager tjenester, og de, der leverer disse tjenester. Denne begrebsdannelse kan anvendes i flere niveauer, idet et serverprogram (f.eks. en Web-server) selv kan optræde som klient over for andre tjenester, fx andre Web-servere, databaseservere mm.

3 Begreber og protokoller 14 Når vi nævner client-server i forbindelse med DEF-nøglen og brugervalidering, tænker vi primært på samspillet mellem brugerens klientprogram (en browser) og den Web-server, som browseren henvender sig direkte til. Det er denne kommunikation, som DEF-nøglen skal være med til at regulere. Dette kan vi også kalde det forreste client-server lag, og den pågældende server den forreste server. Forreste client-server lag: (Med autentificering) Deltagende Servere og services Proxy 2 Server 1 Proxy 1 Forreste servere Proxy n Server 2 Server 4 Server 3 Ofte vil de servere, som fungerer som servere over for de forreste servere ikke tillade kommunikation direkte fra brugerne og deres browsere. Ansvaret for at autentificere brugerens adgang ligger hos den forreste server (der derfor ofte, men ikke altid vil fungere som en proxy), og de bagvedliggende servere stoler på at denne autentificering er sket. Derfor kan de ofte køre med en enklere sikkerhedskontrol, idet de fx tillader alle forespørgsler fra de forreste servere, men afviser klientforespørgsler fra alle andre. Dette kan også være med til at etablere services på systemer, som ikke selv kan implementere den ønskede autentificering. Et vigtig konsekvens af at anvende client-serverteknikker i flere lag er, at selv om brugerens arbejdsstation kun anvender en browser til at nå de forreste servere (http), kan disse henvende sig til bagvedliggende servere med samme eller med andre protokoller. På tegningen ovenfor vil kommunikationen mellem brugeren og Proxy 1 og mellem Proxy 1 og Server 2 måske være med http, medens protokollen mellem Server 2 og Server 3 kan være noget andet (fx Z39.50 eller LDAP). Dette er princippet i de mange Web-Z39.50 gateways, som findes på nettet. Vi har heller ikke her angivet, hvilke af serverne, som leverer data, som brugeren vil få præsenteret direkte eller indirekte, og hvilke, der kun har interne tjenester.

3 Begreber og protokoller 15 Et eksempel kan være, at Server 4 kun fungerer som AAA-server, medens de øvrige bagvedliggende servere indeholder de informationer, som institutionen tilbyder (nogle af) sine brugere. Når serverne i DEF (både de forreste og de bagvedliggende) har brug for yderligere oplysninger om brugerne, end de allerede måtte have i form af DEF-nøglen eller et brugernavn, kan de kommunikere med nogle servere, hvis rolle primært (for denne diskussion) er at tillade godkendte servere at lave forespørgsler om de brugere, hvis oplysninger, de bestyrer. Sådanne AAA-services etableres for alle de biblioteker, som indgår i DEF-samarbejdet. Dette bevirker, at oplysningerne om brugerne vedligeholdes i disse servere (som evt. kan være en del af de egentlige bibliotekssystemer) lokalt for hvert enkelt bibliotek. Mindre biblioteker, som ikke selv ønsker eller kan drive denne tjeneste kan evt. få den leveret af andre biblioteker eller institutioner i DEF-samarbejde. Vi beskriver her ikke i detaljer, hvilke oplysninger, disse AAA-servere kan tilbyde til andre servere inden eller uden for det pågældende bibliotek, og dette forhold kan reguleres af en blanding af tekniske krav og administrative aftaler bibliotekerne imellem. 3.3 Cookies I web-sammenhæng er en cookie en lille stump data, som en server kan sende til en browser, og som browseren efterfølgende sender uændret med i alle efterfølgende henvendelser til samme eller i visse situationer til andre servere. Indholdet af cookien vælges af serveren, der også sætter nogle retningslinier for, hvor længe klienten skal opbevare og fremsende den pågældende cookie, og hvem den skal sendes til. Cookies er specificeret i en internetstandard (ftp://ftp.nordu.net/rfc/rfc2109.txt), der er baseret på en specifikation og implementation fra Netscape. 3.4 Certifikater Moderne browsere understøtter sikker (krypteret) kommunikation via SSLstandarden, og i den forbindelse er det nødvendigt for (primært servere) at kunne bevise deres identitet, og ægtheden (egentlig ejerskabet af) deres offentlige krypteringsnøgle. Men som en del af SSL-standarden er der også udviklet muligheden for, at klienten kan identificere sig over for serveren ved hjælp af et certifikat. I modsætning til cookies kan certifikater sættes af én server, og siden efter brugerens valg præsenteres for en vilkårlig anden server. Certifikater ser ud til at være godt understøttet af browserne (dog ikke på helt samme måde), således at browseren mere eller mindre automatisk kan generere et nøglepar, sende den offentlige nøgle til en server, få et underskrevet certifikat tilbage, og automatisk installere dette i browserens certifikat-database.

3 Begreber og protokoller 16 Selvom moderne browsere altså understøtter certifikater, ser det ud til, at de gør det på en lidt forskellig måde, således at certifikater til brug i de forskellige browsere skal laves på hver sin måde. Der findes dog eksempler på servere, som kan lave certifikater til en række forskellige browsere (fx http://www.thawte.com/). 3.5 Proxy-løsningen Denne løsningsmodel bygger på, at al adgang til tjenesterne sker gennem nogle såkaldte proxy-servere, jf. nedenstående figur. Proxy 2 Proxy 3 Proxy n def.dtv.dk Proxy 1 Figur 1. Proxy-modellen DEF server DEF server DEF server DEF service DEF server def.dtv.dk/dtvkat/søg.html kat.dtv.dk/søg.html ( user=17, pw=xx) def.dtv.dk/sol/sma/søg.html xxx.sb.aau.dk/sma/søg.html ( bruger-id) Brugerid: uder=zz, pw=ww user=dtv/17, pw=xx user=dtv, pw=yy Brugeren sidder ved sin arbejdsplads, som kan være på arbejdspladsen, hjemme, på rejsen eller på biblioteket. Brugeren ønsker at anvende tjenester, som udbydes af en eller flere DEF-servere. I denne model har brugeren ikke direkte adgang til den egentlige tjenestebærende server (som er placeret inde i cirklen på figuren), idet det ser ud som om tjenesten udbydes på proxy-serveren. Der kan være en eller flere proxy-servere, som alle har samme funktionalitet. For en given session foregår al kommunikation mellem brugerens arbejdspladsmaskine og DEF-serverne gennem den samme proxy, og derfor taler vi efterfølgende om proxy en, også selv om der kan være flere. Vi forventer, at brugeren får adgang til proxy en gennem DEF-portalen, men også at man kan gå direkte til den. For brugeren ser det ud som om tjenesterne udbydes direkte af proxy en, idet denne har følgende funktioner:

3 Begreber og protokoller 17 1. Autentificering. Brugerne logger ind på proxy en, og proxy en stiller oplysninger om denne validering til rådighed for de bagvedliggende servere, som bærer de egentlige tjenester. Da al kommunikation mellem brugerens maskine og DEF-serverne foregår gennem proxy en, kan Basic Authentication anvendes. En forskel fra anvendelsen af Basic Authentication for en enkelt server er, at brugernavnet formentligt skal indeholde en kombination (sammenskrivning) af en biblioteksidentifikation og lokalt bruger-id. 2. Gennemstilling af brugerens Web-forespørgsler til den relevante server. Proxy en omskriver URL er til sig selv til nye URL er til de rigtige servere og sender brugerens forespørgsel videre til disse servere. 3. Videresende Web-sider fra serverne til brugerne. Under denne videresendelse skal indholdet skannes og alle henvisninger (URL er), som peger på DEFservere, skal skrives om, således at de peger på proxy en. 4. Når proxy en sender brugerens (omskrevne) Web-forespørgsel videre til en bagvedliggende server, skal den om fornødent også sende valideringsoplysninger videre til pågældende server. Dette kan dreje sig om de oprindelige login-oplysninger fra brugerens egen session med proxy en eller om omskrevne login-oplysninger, der fx blot indeholder biblioteks-id, evt. med brugerkategori. Dette kan baseres på oplysninger i proxy en selv eller ved opslag i en autorisationsservice. Punkt 2 og 3 herover svarer til de opgaver, som en almindelig Web-proxy har, og det har lagt navn til hele løsningsmodellen. Det bemærkes dog, at i denne model er proxy en aktiv i den forstand, at den manipulerer både Web-forespørgsler og de resulterende svar. Den er altså ikke en traditionel transparent proxy, og den skal ikke lægges ind i brugerens browseropsætning som generel proxy. Hvis en server i DEF har brug for yderligere oplysninger om en bruger, fx en postadresse, kan serveren hente disse oplysninger hos enten proxy-serveren eller en AAA-server. 3.5.1 Variationer af Proxy-modellen Herover har vi beskrevet proxy-løsningen i sin rene udgave, hvor al kommunikation mellem brugerne og serverne sker gennem én proxy. Hvis serverne er sat op, således at de ikke tillader brugere at forbinde direkte til serveren, men kræver, at al kommunikationen går gennem proxy en, får vi en adgangskontrol, hvor de enkelte servere ikke selv har ansvaret for at autentificere brugerne. Når det kommer til at afgøre, om brugerne skal have adgang til de enkelte ressourcer, har man i princippet valget mellem at lade denne kontrol foregå i de enkelte servere, eller i proxy en (typisk ved at benytte en autorisationsservice). Det kommer bl.a. an på, hvor let det er at lave adgangsregler, som kan kontrolleres ud fra URL-strukturen.

3 Begreber og protokoller 18 Hvis et bibliotek har tjenester, som ikke kræver adgangskontrol, og hvis disse ligger på servere, som udelukkende har sådanne tjenester, behøver kommunikationen ikke at gå gennem proxy en, og brugerne kan gå direkte til disse tjenester. Hvis et bibliotek på samme server har tjenester, som ikke kræver adgangskontrol, og andre tjenester, som kræver det og derfor skal gå gennem proxy en skal tjenesterne på denne server konfigureres, således at konflikter og omgåelser af sikkerheden ikke er mulige, fx ved at alle henvisninger til kontrollerede tjenester sker via links gennem proxy en. 3.6 LDAP LDAP Light-weight Directory Access Protocol er en internetstandard, der i dag støttes af mange softwareleverandører. LDAP er en generel opslagsprotokol til opslag og søgning i directories (vejvisere), dvs. databaser, der anvendes til at opbevare og vedligeholde oversigter over og oplysninger om fysiske objekter (fx personer og bygninger) og begrebsmæssige objekter (fx services eller rettigheder). I en LDAP-database kan der være forskellige objekttyper, hver med sine attributter. De enkelte poster er navngivet med et såkaldt Distinguished Name, der er opbygget hierarkisk, fx efter en organisatorisk struktur. LDAP-tjenesten kan distribueres på forskellige servere, hvis de skiller på de grænser, som afspejler strukturen i Distinguished Names. Betegnelsen LDAP anvendes sommetider til angive en directory service, hvis data vedligeholdes i en LDAP-struktureret database (server) og om den netværksprotokol, hvormed en klient slår oplysninger op i et directory (uanset om dataene vedligeholdes i selve LDAP-serveren).