Projektrapport. Etablering og aftestning af LDAP-infrastruktur som grundlag for realisering af DEF-nøglen

Transkript

1 Projektrapport Etablering og aftestning af LDAP-infrastruktur som grundlag for realisering af DEF-nøglen Projektperiode: Oktober 2001 til December 2002

2 Resumé Projektet er gennemført i perioden oktober 2001 til december Det markante og positive resultat af projektet har været at det er nu er muligt for de danske forskningsbiblioteker at tilbyde hjemmeadgang (ip-nr. uafhængig adgang) til licensbelagte elektroniske ressourcer. Projektets ambitioner om at udvikle og afteste en DEF-nøgle som et generelt adgangsstyringssystem for de områder forskningsbibliotekerne dækker er ligeledes blevet opfyldt. Der er dog på væsentlige punkter ikke gennemført en udvikling og afprøvning af det totale koncept: der er ikke gennemført forsøg med egentlige autorisationsmekanismer og accounting. databaseleverandører har ikke været direkte involverede i projektet. Adgangsstyring på ip-nummerniveau er nok fjernet fra brugeren, men foregår stadig mellem bibliotekernes særlige proxyer og leverandørerne. projektdeltagerne har anvendt kræfterne på at få adgangen til de elektroniske tidsskrifter til at virke. Det betyder at der reelt ikke har været udført egentlige forsøg med andre af de i projektansøgningen anførte tillægsprojekter udover et lille forsøg hos Statsbiblioteket med støtte for låneroprettelse i DEFlån direkte. Datasikkerheden vedr. brugernavn/password udgør et særligt problemområde, som ikke er fuldt afklaret. Der har i projektet været en udpræget velvilje fra alle universiteter uanset om de er egentlige moderinstitutioner for bibliotekerne eller ej, således at matrikeldata kunne indgå direkte i datagrundlaget. Men når projektet åbner for en bredere anvendelse af disse persondata opstår der visse naturlige betænkeligheder mange steder. Dette er mest tydeligt kommet til udtryk ved implementeringen af den fælles tidsskriftsadgang i DEF-portalen. Projektdeltagerne mener at den implementerede struktur udgør et tilstrækkeligt sikkert grundlag for at disse bekymringer kan afkræftes. Til det formål kræves dog en tydelig formuleret sikkerhedspolitik og tydeligt markerede ansvarsområder. Til det formål har projektet opstillet et regelsæt (Appendiks A). Regelsættet vil blive drøftet med Datatilsynet. Internationalt har projektet haft kontakt med det engelske EduServe (Athens projektet). Ligeledes har udviklingen i USA i Internet2 Shibboleth projektet været studeret. Begge disse initiativer er på vej med løsninger af meget generel karakter. En evt. fortsættelse og fuld realisering af DEF-nøglen på det nuværende grundlag bør ske under skyldig hensyntagen til de nyeste resultater i disse projekter og initiativer. Endelig er der på nationalt plan i bibliotekssektoren under DanZIG et initiativ om udveksling af låneroplysninger via Z Her bør der også ske en koordinering af aktiviteterne. Samlet set vil vi betegne projektet som en succes: Der er etableret en væsentlig bedre service for brugerne med hjemmeadgang til elektroniske ressourcer, og der er etableret en teknologisk infrastruktur som vil kunne udnyttes af den danske forskningsbibliotekssektor fremover. Rapporten starter med et uddrag af projektets formål. Dernæst beskrives den faktiske løsning og der er en status fra hver af de 12 deltagere. Endelig er der en oversigt over økonomien og et appendiks med det foreslåede regelsæt. Projektrapport 2 LDAP-infrastruktur

3 Deltagerne Projekt deltagerne er de 12 store forskningsbiblioteker i Danmark: AUB Aalborg Universitetsbibliotek CBS Handelshøjskolens Bibliotek og IT-service DNLB Danmarks Natur- og Lægevidenskabelige bibliotek DPB Danmarks Pædagogiske Bibliotek DVJB Danmarks Veterinær- og Jordbrugsbibliotek DTV Danmarks Tekniske Videncenter HBA Handelshøjskolens Bibliotek i Århus KB Det Kongelige Bibliotek RUB Roskilde Universitetsbibliotek SDUB Syddansk Universitetsbibliotek RISØ Forskningscenter Risø SB Statsbiblioteket (projektansvarlig) Formål Formålet med projektet har været at opbygge et netværk af servere med brugeroplysninger baseret på anvendelsen af LDAP-standarden Lightweight Directory Access Protocol og hermed realisere første version af det som i DEF-arkitektursammenhæng er benævnt DEFnøglen. Baseret på det opbyggede LDAP-netværk etableres og idriftsættes en service som giver alle forskningsbiblioteksbrugere adgang til licenserede elektroniske tidsskrifter uafhængig af brugerens fysiske placering og udelukkende baseret på at brugeren qua sin rolle som studerende eller medarbejder ifølge licensaftalerne har adgang til det pågældende tidsskrift. DEF-nøglen Rapporten DEF-nøglen Forslag til realisering af fælles brugervalidering til DEF-tjenester udarbejdet for DEF af UNI-C i August 1999 er på mange måder fortsat dækkende såvel hvad angår begrebsapparat, krav til løsningen som mulige løsningsmetoder. Her beskrives AAA, Autentifikation, Autorisation og Accounting, som er de fundamentale elementer en nøgleløsning skal indeholde. I forlængelse af UNI-C-rapporten udarbejdede DEF-nøglegruppen rapporten: Scenarier for DEF nøglens implementering medio 2000, der præciserer og videreudbygger UNI-C-rapporten. LDAP-projektets løsning er ikke så omfattende som skitseret i sidstnævnte rapport idet der udelukkende sigtes mod adgang til elektroniske tidsskrifter. UNI-C-rapporten anbefaler en løsning baseret på en active proxy. Rapporten peger samtidig på permanente certifikater som fremtidens løsning. LDAP-projektet har fokuseret sin implementering omkring active proxy samtidig med at det sikres, at adgangen også vil kunne formidles gennem en gateway. Nyt i forhold til situationen i 1999 er at vi nu har en fungerende DEF-fællesportal ( og massiv brug i forskningsbiblioteksverdenen af elektroniske tidsskrifter. Der er via DEF opnået aftaler om nationale licenser, men også de enkelte biblioteker (og institutbiblioteker) indkøber egne licenser. DEF-arkitekturgruppen har defineret 3-lagsmodellen som grundlag for samspillet mellem det centrale og det decentrale. Projektrapport 3 LDAP-infrastruktur

4 I konsekvens heraf er der udviklet en kombineret central/decentral nøgleløsning i ovennævnte UNI-C-rapport (side 36) benævnt hybrid-løsningen. Et afgørende princip i løsningen er at data vedligeholdes ved kilden autentificering baseres på en decentral struktur hvor det enkelte forskningsbibliotek har ansvaret for vedligeholdelse af egne brugerdata og står som garant for overholdelse af den aftalte politik for brugerdata. Det enkelte forskningsbibliotek kan lokalt indgå aftale med værtsuniversitet/matrikel om yderligere decentralisering af ansvaret for brugerdata. Det vil dog være afgørende for (nationale) licensaftaler at ovennævnte politik overholdes og garanteres (af juridiske personer). autorisation baseres på en distribueret model hvor autorisationsdata vedligeholdes der hvor licensaftalerne er indgået, men hvor den konkrete autorisation af adgang til en ressource sker ved forespørgsel fra den active proxy eller portal som styrer adgangen. Dvs. vedligeholdelse af autorisationsdata for tidsskrifter omfattet af nationale licenser sker hos DEF medens vedligeholdelse af autorisationsdata for tidsskrifter omfattet af lokale licenser sker lokalt. Igen kan der ske en yderligere decentralisering i tilfælde af lokale institutter/biblioteket med egne licenser. Opbygningen af autorisations- og andre DEF-tjenester på tidsskriftområdet varetages udenfor LDAP-projektet, der derfor kan nøjes med at bidrage til definitionen af netværksinterfacet mellem autorisationstjenester og portal/proxy. I projektet kan det dog være relevant at implementere en lokal ad-hoc autorisationsfunktion for ikke at være afhængig af en ekstern udvikling, hvis tidsplan pt. er ukendt. Gennem datareplikering fra decentral til central (for autentificeringsdata) og fra central til decentral (for autorisationsdata) kan der ske forskydninger mellem det centrale og det decentrale fx som led i performanceoptimering. Det gælder fx for autorisationsdata jf bemærkningerne ovenfor. Der bør i disse overvejelser tages hensyn til at autentifikation er en relativ sjælden operation, medens autorisation kan være en meget hyppig operation. som systemplatform foreslås i første omgang anvendt samme type udstyr og programmel. Herigennem gives det bedste grundlag for forsøg med datareplikering, centralisering og decentralisering og der etableres en referenceplatform som senere kan anvendes af det enkelte bibliotek til en tættere integration (og evt. sammenfald) af det lokale bibliotekssystems lånerregister med DEF-nøglens AAA-baser. Det skal dog samtidigt sikres at løsningen bliver åben, modulær og leverandøruafhængig, således at bibliotekerne og deres systemleverandører frit kan vælge at erstatte en, flere eller alle af referencekomponenterne: portal, autentificeringstjeneste, autorisationstjeneste og proxy så længe deres indbyrdes kommunikation over nettet fortsat følger de samme retningslinier. biblioteker som ikke ønsker selv at drive DEF-nøglestrukturens basale komponenter (active proxy, autentificeringsservice, autorisationsservice) tilbydes at få afviklet disse komponenter på service/hosting-basis centralt hos DEF eller hos andet bibliotek. En sådan hosting metode fritager dog ikke det pågældende bibliotek for ansvaret for de relevante autentificerings- og autorisationsdata og overholdelse af politik for brugerdata. Adgang til E-tidsskrifter Anvendelse af active proxy som nøgleløsning har den umiddelbare fordel at den passer sammen med tidsskriftsleverandørernes krav om at tilgang til de elektroniske tidsskrifter skal ske fra bestemte IP-numre. Projektrapport 4 LDAP-infrastruktur

5 En systemarkitektur hvor der etableres et fælles, decentralt funderet netværk af LDAPbrugerdatabaser vil i sammenhæng med aktive proxy-servere kunne løse et af de væsentligste problemer p.t. forbundet med udnyttelsen af licenserne til de elektroniske tidsskrifter, nemlig spørgsmålet om fjernadgang fra PC'ere udenfor universiteternes netværk. Det vil hermed blive muligt for alle forskere og studerende at få adgang til deres institutions elektroniske tidsskrifter fra hjemme-pc'en, fra udstationering i udlandet og hvor de ellers måtte befinde sig. I kombination med en fælles database over de elektroniske tidsskrifter og licenserne til disse - vil løsningen samtidig give brugeren et overblik over de elektroniske tidsskrifter, deres emnemæssige fordeling, de licensmæssige rettigheder osv. Denne fælles database over de elektroniske tidsskrifter er dog en selvstændig sag i DEF-sammenhæng, der integreres med Nøglen via DEF-Systemarkitekturen og således ikke en del af det udvidede LDAP-projekt. Systemarkitektur Den ovenfor skitserede løsning er illustreret i nedenstående figur. De komponenter som realiseres i LDAP-projektet er Autentifikationsstrukturen (I), Autorisationsstrukturen (A) og strukturen med Active Proxy (X). Bemærk at alle disse komponenter vil findes i flere inkarnationer i strukturen. LDAP-projektet og DEF-nøglen I I I I I A P:Portal { X:Active Proxy I:Autentifikation A:Autorisation C:Accounting D:Dataser, forlag A P A A A X D Let trafik Tung trafik Distribueret database (evt. replikering) C D D Den faktiske løsning Der er valgt en løsning med en LDAP-server (I) pr. forskningsbibliotek + en central for DEF. Antallet af active proxy er behøver ikke følge antallet af autentifikationsservere. Teknisk set vil man kunne nøjes med 1 fælles for alle (som en fælles tjeneste i 3-lagsmodellens ånd), men der kan være tekniske grunde hos dataudbyderne til at fordele proxy-funktionen over flere Projektrapport 5 LDAP-infrastruktur

6 servere. Ligeledes kan det af performancehensyn være nyttigt at fordele tjenesten over flere servere og de store forskningsbiblioteker har fundet det sikrest at anvende lokale proxyer. Autorisationsstrukturen kan næsten ignoreres for e-tidsskrifternes vedkommende da kriteriet simpelthen er adgang/ikke adgang baseret på resultatet af opslaget i autentifikationsstrukturen. Det betyder desværre, at løsningen i sin nuværende udformning er uden en egentlig, generel autorisationsstruktur. Et typisk anvendelsesscenarie er: Brugeren henvender sig til portalen (P) hvor hun fremsøger det ønskede elektroniske tidsskrift. Ved hjælp af et opslag med brugernavn/password i I- strukturen autentificeres hun og accept af identiteten gives tilbage til hendes browser (fx som en cookie) og til proxyen (X). Proxyen kontrollerer ved opslag i autorisationsstrukturen at hun har lov til at tilgå det pågældende tidsskrift og skaber forbindelsen til forlaget (D). Der sker nu en dynamisk transmission og link-konvertering af data mellem bruger og forlag i proxyen (derfor begrebet active proxy) som sikrer brugeren komplet adgang til den elektroniske ressource (evt. netværk af elektroniske ressourcer).. Alternativt foretager portalen såvel autentifikation som autorisation ved opslag i henholdsvis I- og A-strukturerne og anvender udelukkende proxyen som slave til at forbinde brugeren med forlaget eller databaseudbyderen. (D). Accounting funktionen er ikke etableret. Dette udgør dog ikke noget principielt problem, men vil som den egentlige autorisationsunderstøttelse være et krav i en generel løsning. Dog er der mulighed for opgørelser til statistikformål. Nogle af implementeringerne sender alle brugere gennem proxyen uanset om de pågældende allerede er på et ip-nummer der giver adgang. I disse tilfælde er det derfor muligt at genere præcise statistikker over brugen af ressourcerne uden at være afhængig af oplysninger fra leverandøren af tidsskriftet/databasen. Den første udgave, der kommer til at køre, ser således lidt anderledes ud end den generelle løsning. Ligesom adgangen i første omgang er begrænset til elektroniske tidsskrifter og visse andre databaser, så er modellen blevet simplificeret noget. Den aktuelle model er vist i figuren neden for, og hvor den største forskel ses i sammenfletning af autorisationen og bibliotekets proxy. Serviceløsningen (base13-løsningen) giver hvert bibliotek sin egen virtuelle LDAP-server og proxy. Disse er gengivet som henholdsvis en af knuderne (I) og en fra stakken (X). Funktionelt betyder det, at biblioteket blot skal vedligeholde dataene, der beskrevet i afsnit 4, mens software og maskiner varetages af Statsbiblioteket, som aftalen er lavet med. Serviceløsningen har reelt samme funktionalitet som de individuelle implementeringer de 12 projektdeltagere har anvendt. En faktisk forskel er at serviceløsningen i alle tilfælde anvender DEFportalen som adgang til tidsskrifterne. Som systemløsning er i projektet valgt en in-a-box løsning bestående af et Linux Redhat system og software produkterne Open Ldap og proxyprogrammellet EzProzy. Eneste undtagelse er KB som i stedet for EzProxy anvender det lidt mere komplekse (men lidt mere generelle) LibProxy programmel. Projektrapport 6 LDAP-infrastruktur

7 LDAP-projektet og DEF-nøglen I I I I I P:Portal { X:Active Proxy +Autorisation I:Autentifikation C:Accounting D:Dataser, forlag P Faktisk løsning X D Let trafik Tung trafik Distribueret database (evt. replikering) D D Figur 1: Første versions arkitektur Projektrapport 7 LDAP-infrastruktur

8 Status for de enkelte deltagere Samtlige deltagere har en lokal LDAP og en lokal proxy kørende og det er muligt at indlægge data i LDAP en og det er muligt at styre adgangen til elektroniske ressourcer via systemet. Projektet har således løst sin opgave hvad angår den tekniske løsning af adgangen til e- tidsskrifter. Enkelte af deltagerne har stadig uafklarede problemer vedr. datasikkerhed. På den ene side er der både vilje og ønsker om at kunne integrere LDAP-basernes indhold med lokale matrikeldata, på den anden side en vis usikkerhed overfor den samlede datasikkerhed i projektet når mange institutioner (herunder den centrale DEF-portal) tilsammen skal garantere sikkerheden. Den eneste fungerende tværgående anvendelse af LDAP-strukturen er DEF-portalens adgang til autentifikation hos den enkelte institutioners LDAP, men tanken har været at der gensidigt blandt partnerne skulle være en tilsvarende mulighed. Projektet har til det formål udarbejdet et forslag Regler for DEF-nøglen (Appendiks A) som tydeligt viser deltagernes ret og pligt i forbindelse med anvendelsen af LDAP-strukturen. Reglerne er planlagt forelagt Datatilsynet. I efteråret 2002 og igen i forbindelse med projektafslutningen har de enkelte deltagere afgivet en statusrapport for implementeringen af de aftalte løsninger. Tabellen på næste side giver statusoversigten som afleveret til DEF i november 2002, opdateret med faktuelle hændelser siden da. Dernæst følger en status pr. institution i tekstform, hvor hver deltager er blevet bedt om at gøre rede for 4 punkter: 1) Status for den lokale installation 2) 3) Ønsker og villighed til at deltage i evt. kommende driftsaftale 4) Udnyttelsesplan: Hvad er planerne for udnyttelse ud over tidsskriftsadgang Det kan bemærkes at samtlige 12 deltagere udtrykker tilfredshed med projektets resultater herunder specielt den opnåede adgang til elektroniske tidsskrifter næsten alle udtrykker en interesse for at der etableres en form for driftsaftale hos nogle deltagere er der betænkeligheder datasikkerheden alle deltagere har planer om at fortsætte driften af systemet og har planer og ønsker om flere anvendelser. Projektrapport 8 LDAP-infrastruktur

9 LDAP tilslutning status 20. december 2002 Institution Status Dato for login via eget website Dato for login via DEF tidsskrift-vejviser SB ok juni DTV ok august 02 via deff.dk august 02 KB ok HBA ok april DNLB ok Væsentlige kommentarer fra institutionen Risø ok 1/10 (test) 24/ Anvender vanlig LDAP-base direkte på LDAP/Proxy-serveren i stedet for Active Directory aht. sikkerhed for matrikeldata SDUB ok DVJB ok AUB forsk. marts02 stud december 02/ januar 03 CBS ? Vurdering af login-/password-sikkerhed til høring på CBS (i dag kun testbrugere via deff.dk) RUB ? Afventer afklaring af sikkerhedsproblem ved direkte anvendelse af matrikeldata DPB ? Anvender Active Directory til adgangskontrol og kan derfor nok ikke deltage i den nationale løsning Sammenfattende gælder for de 12 store: 8 i fuld drift 1 forventes i fuld drift i november 02 2 vurderer sikkerhed og må alternativt finde andre veje for login via deff.dk 1 er for tiden blot forsinket De andre (base 13): 2 i drift 17 under indlægning af SB Projektrapport 9 LDAP-infrastruktur

10 AUB Forskere har haft fjernadgang via AUB's website fra marts 2002, Studerende fra ca. 10. oktober I skrivende stund er DEFlogin til AUB s LDAP endnu ikke etableret. Sagen har 1. prioritet at få løst, p.t. afventes svar på spørgsmål sendt til DTV. I november/december 2002 er alle URL er til de relevante ressourcer rettet i Auboline (AUB s katalog) og på AUB s websider, således at disse peger på vores proxyserver. Hermed udnyttes EzProxy s funktionalitet med hensyn til en integreret anvendelse i opbygningen af bibliotekets site og katalog, som består i, at EZProxy automatisk viderestiller interne IPadresser til direkte adgang til ressourcerne, mens der promptes for LDAP-login, når brugeren kommer fra ekstern IP-adresse. AUB s LDAP-database er en kopi af Aalborg Universitets LDAP-database, som alle studerende har adgang til at aktivere sin matrikelbaserede profil i, med henblik på bl.a. adresse og STADS-selvbetjening. For de studerendes vedkommende er systemet således fuldt integreret med matriklen. Der findes ikke p.t. en tilfredsstillende lignende database over ansatte ved Aalborg Universitet. AUB s LDAP-database indeholder således p.t. de AUB-lånere, der er registreret som ansatte ved Aalborg Universitet. Vi er i forskellige sammenhænge engageret i tilvejebringelsen af en tilfredsstillende database over ansatte og håber at kunne integrere en sådan i fjernadgangssystemet i løbet af Deltagelse i kommende driftsaftale AUB betragter LDAP-systemet som vitalt, såvel for biblioteket isoleret set som for fremtidsperspektiverne for IT-infrastrukturen for det samarbejdende biblioteksvæsen. Vi er derfor fortsat interesseret i at deltage aktivt i udvikling og drift af den fælles LDAP-infrastruktur som en naturlig del af Danmarks Elektroniske Forskningsbibliotek. Udnyttelsesplan De videre udnyttelsesplaner for LDAP er, lokalt set: Automatiseret import af matrikeldata til lånerdatabase i bibliotekssystem Opkobling af låneres egne bærbare pc ere på biblioteket til internet Personalisering af AUB s website koblet med studieretningskoder fra matrikel og med mulighed for at gemme personlig opsætning På sigt at overgå til LDAP-baseret lånerdatabase i bibliotekssystem LDAP-databaser som fundament for kommende AAU-portal, med services som dem der p.t. kendes fra systemer som f.eks. CampusNet (DTU) I regi af Danmarks Elektroniske Forskningsbibliotek er det efter vores mening oplagt, hvis LDAP anvendes til at afløse den nyligt etablerede samarbejdsmodel i Bøger til døren med en ordning, hvor LDAP-brugerdata udnyttes til formidling af udlån direkte til lånere indmeldt Projektrapport 10 LDAP-infrastruktur

11 ved andre biblioteker. LDAP-brugergenkendelse i bibliotekssystemerne på tværs af bibliotekerne vil kunne gøre det meget lettere for brugerne, idet de så kun behøver at være indmeldt hos deres lokale forskningsbibliotek. Tilsvarende med de lokale planer er det selvfølgelig også oplagt at lave personalisering af DEF-portalen ved hjælp af LDAP-netværket. En vigtig fremtidig mulighed er at DEF-portalen på sigt skal kunne integrere brugerrettigheder for den enkelte person, i de tilfælde hvor brugeren har tilknytning til flere institutioner. Eksempelvis læger på Aalborg Sygehus, der bedriver forskning tilknyttet sygehusets funktion som en del af Århus Universitetshospital og som evt. samtidig er tilknyttet som forsker/underviser ved Aalborg Universitet. I dette eksempel skal rettigheder fra 3 institutioner (Århus Universitet, Aalborg Sygehus Medicinske Bibliotek og Aalborg Universitet) kunne integreres f.eks. til en samlet tidsskriftsliste. CBS CBS har haft en lokal løsning kørende siden november Den oprindelige løsning baserede sig på EzProxy på en WIN2000 platform med autentificering til personale- og studenter- LDAP s på CBS. Platformen er i september 2002 bragt i overensstemmelse med den standard, der blev udviklet i LDAP-projektet under DEF. For lokal adgang fra CBS lokaliteter baseres autorisation alene på ip-nummer autentificering. For adgang fra andre lokaliteter baseres autorisation på autentificering op mod CBS LDAP s. Vi har i september 2002 afprøvet integration med projektets fælles LDAP-struktur. Matrikeldata har via lokale CBS-LDAP s været overført til projektets særlige LDAP og dennes integrering med den fælles LDAP-struktur er bevist at kunne fungere. Vi er således i stand til teknisk at indløse projektets krav om LDAP-samspil. Imidlertid er der rejst spørgsmål ved datasikkerheden i løsningen; specielt sikkerheden omkring portalserveren. CBS holdning til dette sikkerhedsproblem er ikke endeligt afklaret. Der er nedsat en arbejdsgruppe, der skal gennemgå alle relevante dataflows omkring matrikler, LDAP s og øvrige directories på CBS, herunder også tilknyttede sikkerhedsproblemer. Det er vores absolutte holdning, at der skal findes en acceptabel løsning. Deltagelse i kommende driftsaftale CBS finder det vigtigt, at der opretholdes et samarbejde omkring de etablerede løsninger. Et sådant samarbejde er vigtigt for sikring af erfaringsudveksling omkring løbende driftproblemer, koordinering af test og implementering af nye versioner af det anvendte programmel etc. Den konkrete udformning af dette samarbejde må afhænge af de involverede bibliotekers villighed til at bidrage med ressourcer hertil. Projektrapport 11 LDAP-infrastruktur

12 Udnyttelsesplan Umiddelbart vil CBS anvende LDAP-samarbejdet som autentificeringsgrundlag for laptoptilslutninger i bibliotekets publikumsområder. CBS har gennem sin deltagelse i projektgruppen og ved støtte til implementering på andre biblioteker ydet en betragtelig indsats i forhold til det samlede projekt. DNLB Den 1. oktober blev LDAP-løsningen sat i drift. Brugerdatabasen bestod af et udtræk fra matriklen ved Københavns Universitet. Den 24. oktober blev det muligt at logge ind via DEFportalen. Den 29. november blev synkroniseringen med Matriklen færdig, således at der foretages automatisk opdatering hver nat. Deltagelse i kommende driftsaftale Hvis der med kommende driftsaftale menes test og udvikling af nye versioner samt support ved installation mm. vil DNLB gerne deltage. Udnyttelsesplan 1. Vi bruger allerede LDAP til mere end online tidsskrifter, idet vi også giver proxyadgang til nogle reference databaser. Herudover har et par ideer under overvejelse: Videreudvikling af vores bestillingsfunktion, så denne trækker oplysninger fra LDAP til verificering/udfyldelse af låner nr., adresse mm. Udvikling af Web-script, som kan søge på låneroplysninger, der ikke er søgbare i Aleph. DPB Den 1. januar 2003 åbnede DPB for fjernadgang via Ezproxy for studerende og ansatte ved DPU. P.g.a. DPU s valg af Active Directory som adgangskontrol til e-learningsystem, webmail mm og ønsket om at kunne bruge samme brugernavn/passord, har DPB valgt også at bruge AD som adgangskontrol til Ezproxy. Projektrapport 12 LDAP-infrastruktur

13 Deltagelse i kommende driftsaftale På grund af valget af AD til autentificering er det uklart om DPB kan deltage i det nationale samarbejde. DPB vil dog gerne deltage i udvikling af den eksisterende løsning. Udnyttelsesplan Da off-campus adgangen er perfekt til fjernstuderende og til brug sammen med e- learningssystemer satser DPB på at vedligeholde og supportere proxy-adgang vha. Ezproxy eller andet proxy-programmel fremover. Vi har i første omgang valgt ikke at lade links i opac pege på proxy-serveren men lavet en side med links til ressourcer. DPB bruger proxyen til fjernadgang til ip-adgangskontrolerede tidsskrifter og databaser DVJB Sommeren 2002 fik vi serveren installeret, og fik i løbet af sommeren vores elektroniske tidsskrifter lagt ind i ezproxy. Der foregik derefter test og justering af denne, og i august var den klar til drift. Indlæggelse af brugere sker hos os fra låner-basen i bibliotekssystemet Aleph. Definition af hvilke felter der skulle ud blev lavet i juni/juli, og første forsøg med at lægge alle brugere ind blev gjort i august, og virkede. Der er endnu ikke lavet en automatisk overførsel af data fra lånerregistret endnu, og vi laver pt en ugentlig manuel opdatering. 15. september ændrede vi url på vores elektroniske tidsskrifter i vores bibliotekssystem, og LDAP en har i forbindelse med vores egen base virket siden. Vi får rigtig mange positive tilbagemeldinger tilbage fra vore brugere, hvor de giver udtryk for hvor glade de er for at de nu ikke mere er afhængig af at befinde sig på campus for at få adgang til vores elektroniske tilbud. LDAP certifikat fra SB virker fra uge 49 og besked er sendt til DTV vi har ikke fået noget svar. Derfor virker LDAP-netværket (til tidsskrifter via DEF) endnu ikke. Verisign certifkat har vi endnu ikke fået til at virke, men vi håber at det sker i år. I fremtiden kan vi se en fordel i at bruge data fra Matriklen som hos KVL indeholder data om både studenter og ansatte til LDAP, og det vil vi arbejde videre på. Deltagelse i kommende driftsaftale DVJB er villige til at deltage i en kommende driftsaftale. Udnyttelsesplan Projektrapport 13 LDAP-infrastruktur

14 Udover adgang til e-tidsskrifter bruger vi LDAP til adgang til 7 bibliografiske databaser, som ligger på en server hos DVJB, til adgang til web of science og til adgang til DADS. Projektrapport 14 LDAP-infrastruktur

15 DTV Såvel Proxy som LDAP server har været i drift på DTU/DTV siden august Den 1. september 2002 gik integrationen med DEF Portalen i drift. Installationen er baseret på LDAP in a box og installeret under Debian Linux. Brugerdata er de samme, som anvendes i DTU s studieintranet, CampusNet, og i DTUs databarer. De stammer dels fra DTUs matrikel og dels fra DTUs personalesystem og telefonbog. I praksis flyttes de pt. fra CampusNet til LDAP via en SOAP forbindelse. Deltagelse i kommende driftsaftale DTV vil fortsat gerne indgå i et samarbejde om den videre udvikling og support af systemet. Udnyttelsesplan DTV etablerer i første kvartal af 2003 en lokal portal til tidsskrift- og databaseadgang med udnyttelse af LDAP/proxy installationen. Det er herefter endvidere tanken at føre al tidsskriftadgang gennem proxyen for at få et enkelt konsolideret log-punkt, som basis for en ny præcisere og forlagsuafhængig tidsskriftstatistik (evt. i samarbejde med andre interesserede biblioteker) HBA HBA har kørt med proxy-systemet (EZproxy) siden april/maj 2002 og foretaget de nødvendige tilretninger af databaseoplysningerne hen ad vejen. LDAP systemet kom i drift i september Overførslen af studentermatriklen er også på plads LDAP-systemet opdateres automatisk med regelmæssige intervaller. Rutinerne i forbindelse med de ansatte er dog endnu ikke fuldstændige automatiserede, men dette forventes at blive tilfældet i forbindelse med oprettelse af lokal CampusNet matrikel, som også indeholder ansatte. Der har været adgang til HBA s proxysystem via DEFs tidsskriftlogin siden 18 oktober Der er krypteret adgangen i forbindelse med afgivelse af brugernavn/password fra slutbrugerne til HBA s LDAP-system. LDAP/proxy systemet er nu fuldstændig integreret i HBA s portal. HBA s LDAP-system opdateres med regelmæssige intervaller direkte fra Handelshøjskolens studentermatrikel. Projektrapport 15 LDAP-infrastruktur

16 Deltagelse i kommende driftsaftale HBA er meget villig til at deltage/bidrage til evt. kommende driftaftaler. Vi vil specielt være interesseret i at kunne trække på en traditionel form for support til LDAP systemet, og i mindre grad support til EZproxy. Vores behov for support til LDAP-systemet vil f.eks. være fejlfinding og afhjælpning af fejl. Udnyttelsesplan HBA vil sammen med SB deltage i udviklingen af DEFlån-direkte og LDAP. HBA har anskaffet MetaLib, som er en portal-løsning, der gør det muligt at søge i udvalgt information på tværs af søgeprotokoller, formater og materialetyper fra en standardiseret brugergrænseflade. I den forbindelse forventer HBA at anvende LDAP-systemet til autentifikation af brugerne (studerende/ansatte på Handelshøjskolen). Derudover vil LDAP-systemet kunne tænkt anvendt i forbindelse med andre kommende behov for autentifikation af lokale brugere (studerende/ansatte). KB Vi tog LDAP, proxy mv. i produktion i juli måned Vores proxy/ldap-løsning kører nu i produktion, for så vidt angår adgang via vores egne kataloger, REX og Elektra. Adgangsstyringen til de enkelte ressourcer sker på grund af licensforhold på fakultetsniveau. Det specielle ved KB's løsning er at vores proxy ikke er en EZProxy, men derimod er baseret på Richard Goerwitz' libproxy og benytter libproxys integrerede autentifikationssystem - BrownTicket. Vi har derfor været nødt til at udvikle egne rutiner til integrationen med deftid. LDAP-serveren er samme OpenLDAP som de øvrige institutioner benytter. Vores proxy/ldap-løsning kører nu i produktion, for så vidt angår adgang via vores egne kataloger, REX og Elektra. Adgangsstyringen til de enkelte ressourcer sker på grund af licensforhold på fakultetsniveau. Vi har haft et samarbejde med Københavns Universitet om samkøring med matriklen. I dag får vi daglige opdateringer fra Universitetet. Brugerdata stammer fra samkøring mellem vores lånerregistrant i bibliotekssystemet REX og data fra KU's matrikel, herunder fakultetstilhørsforhold. P.t. rummer matriklen ikke oplysninger om ansatte, så her baserer vi os alene på lånerregistranten. Ldaps-kommunikationen med deftid er aftestet, og er p.t. nået langt i arbejdet med at modificere BrownTicket-autentifikationssystemet, så vi kanslippe brugerne fra deftid ind uden at de skal (re)autentificere sig lokalt. Herefter vil grundlaget også være på plads for en single-sign-on løsning for de brugere, som kommer via KU's portal, ".ku" Deltagelse i kommende driftsaftale Vi har i sagens natur intet ønske om serviceaftaler vedrørende drift af denne løsning. Projektrapport 16 LDAP-infrastruktur

17 Udnyttelsesplan Vi har planer om specielt at anvende LDAP infrastrukturen i forbindelse med udvikling af nye publikumsorienterede tilbud i første omgang sandsynligvis i forbindelse med vores publikumspc'ere. RUB RUb er pr. 1. december 2002 kørende i drift med den i projektet beskrevne fjernadgang til næsten alle elektroniske tidsskrifter og bibliografiske databaser, som biblioteket har tegnet licensadgang til. Der mangler dog stadig adgang til ganske få (8-10) ressourcer, som i sig selv kræver login og som ikke hidtil har kunnet håndteres i den etablerede EZproxy løsning. Den lokale EZproxy-server er konfigureret således, at bibliotekets elektroniske ressourcer tilgås via login på denne. Login bliver authentificeret via Universitetets (RUC s) matrikeldatabase. Bibliotekets Ldap-database er reelt lig med RUC-matriklens Ldap-database. Tilgang til alle bibliotekets elektroniske ressourcer foregår gennem den etablerede proxyserver. Alle ressourcer peger på proxy-serveren: tidsskrifter fra katalogen og øvrige elektroniske ressourcer (databaser m.v.) fra bibliotekets hjemmeside. Hvis proxy-serveren er nede/ude af drift vil der ikke være adgang til de elektroniske ressourcer, hverken eksternt eller internt på campus. Der efterlyses en løsning på dette problem. Der er endnu enkelte mangler i/krav til bibliotekets installation, som i samarbejde med RUC vil blive imødekommet indenfor ganske kort tid: Der vil blive etableret en krypteret linje/certifikat mellem bibliotekets proxyserver og RUC s Ldap-server i starten af Der vil blive etableret en krypteret linje mellem brugerens browser og bibliotekets proxy-login snarest, enten ved en snarlig overgang til vers. 2.0 af EZproxy eller ved en omsætning af single sign-on til RUC s ressourcer herunder bibliotekets EZproxy. Certifikat er bestilt gennem RUC Datalogi. Ingen af de nævnte forhold påvirker dog den etablerede adgang for brugeren. RUb har, som påpeget ved flere lejligheder, stadig betænkelighed ved at åbne for login til bibliotekets elektroniske tidsskrifter via DEF s tidsskriftvejviser. RUb benytter brugerdata hentet direkte i RUC s matrikeldata og der vil med den nuværende løsning med afgivelse af logon/password på 3. parts server (DEF) være en åbning for hacking af særdeles personlige studenter- og forskerdata. RUC har overfor biblioteket tilkendegivet, at man finder dette særdeles problematisk, specielt når der kan findes andre brugbare løsninger, som giver mulighed for at et system kan checke en brugers autenticitet uden at få kendskab til vedkommendes password. Spørgsmålet i denne sammenhæng er, om vi nødvendigvis skal benytte den højteknologiske løsning med adgang direkte til DEF s titelliste eller om der i første omgang (og Projektrapport 17 LDAP-infrastruktur

18 indtil accept af den ønskede direkte adgang kan imødekommes fra RUb/RUC) kan gives adgang ved tilbagekøring til bibliotekets proxy via RUC s authorisations-server? Deltagelse i kommende driftsaftale RUb vil naturligvis være interesseret i et fortsat samarbejde om dette projekt. Der er endnu en del - i hvert fald for RUb uafklarede elementer i projektet, som skal belyses og sættes på plads: Der bør sikres en alert -facilitet blandt projektets deltagere, således at der kan ske en hurtig og ens opdatering af URL er ved leverandøreres serverskift og andre datamæssige forstyrrelser. Der bør sikres en versions-sikkerhed i projektet, således at alle de involverede biblioteker så vidt muligt benytter samme version af proxy-software (EZproxy) og der bør i den sammenhæng sikres, at ikke alle biblioteker behøver at teste nye versioner, men efter aftale uddelegerer sådant arbejde. Det vides således på nuværende tidspunkt, at AUB allerede benytter version 2.0 af EZproxy, SB aftester versionen, mens alle øvrige biblioteker (ekskl. KB) stadig benytter vers. 1.4g. Den omtalte manglende sikkerhed på DEF s server (til tidsskriftvejviseren) bør behandles seriøst og alternative løsninger bør undersøges, således at de biblioteker, hvis moderinstitutioner er bekymret for matrikeldataenes tilgængelighed, kan deltage på fuldt niveau. De opstillede sikkerhedsregler er for så vidt udmærkede, men praksis skal naturligvis følge. Hvordan sikres adgang til ressourcer, hvis proxy-server er ude af drift? Hvorvidt der skal etableres en egentlig fælles support for de deltagende biblioteker mod betaling vil RUb ikke tage stilling til på nuværende tidspunkt. Det vil under alle omstændigheder kræve en plan for indhold og eventuelle beløbsrammer. Imidlertid skal vi ikke lægge skjul på, at vi ikke har fundet det nuværende samarbejde i dels udviklergruppen og dels projektgruppen for optimalt. Der har været for lidt dokumentation på og orientering om de forskellige løsninger, der har været etableret undervejs, hvilket har kunnet give anledning til nogen usikkerhed og muligvis også tidsspilde lokalt ved valg af forkerte implementeringsveje. En videreførsel af projekthjemmeside og listserver vil være absolut relevant, men såvel ideer og erfaringer skal viderebringes i langt større omfang end hidtil. Udnyttelsesplan På RUb vil vi med et forholdsvist kort tidsperspektiv kunne se en række muligheder for forskellige adgange/authentificeringsopslag via Ldap-basen (med matrikeldata): Betalingsprint/printfacilitering (i fællesskab med RUC). Adgang til forskningspublicering/dokumentserver. Der benyttes allerede autoriseret brugernavn/password til adgang for bærbare computere på biblioteket (V-LAN), men dette kan udbygges til en egentlig authentificering med printmulighed etc. styret af Ldap-databasen, hvilket ikke forekommer p.t. Authentificering ved brug af DEFlån direkte. Projektrapport 18 LDAP-infrastruktur

19 Alt i alt har RUb været tilfreds med resultatet af deltagelsen i Ldap-projektet: der er etableret en alternativ (og nemmere) fjernadgang end den hidtil benyttede Dial-in og der har været gjort gode erfaringer med den anvendte teknologi. Imidlertid er det vores opfattelse, at det kendte hul i sikkerheden i den såkaldte DEF-nøgle giver anledning til at revurdere og forbedre løsningen. Dermed være ikke sagt, at denne del af projektet har været en fiasko: tværtimod var det meningen med projektet at afprøve netop anvendelsen og sikkerheden på dette felt. SDUB D åbnede Syddansk Universitetsbibliotek for fjernadgang til elektroniske tidsskrifter og databaser for studerende og ansatte på Syddansk Universitet og Odense Universitetshospital. D blev der åbnet for fjernadgang gennem DEF-portalen. Bibliotekets LDAP-server opdateres dagligt med oplysninger om de studerende fra universitetsmatriklen. Da Syddansk Universitet ikke på nuværende tidspunkt har en central database med oplysninger om de ansatte, hentes oplysninger om disse fra bibliotekets lånerbase. Også denne opdatering sker dagligt. Syddansk Universitet har planer om at etablere et personale system. Når det er etableret, vil det være et naturligt sted at hente opdateringerne til bibliotekets LDAP. Deltagelse i kommende driftsaftale SDUB finder, at et fortsat samarbejde omkring den etablerede løsninger er vigtig, og vil derfor gerne deltage i et sådant samarbejde. Udveksling af erfaringer omkring drift, implementering af nye versioner og nye udnyttelsesområder mv. bør løbende finde sted. Udnyttelsesplan Udover at styre adgangen til elektroniske tidsskrifter og databaser har Syddansk Universitetsbibliotek planer om at anvende LDAP-serveren til at styre tilkobling af brugernes bærbare PC'er til bibliotekets net. Biblioteket deltager i et projekt om etablering af trådløs net, som skal give brugere i forskellige områder på universitetet adgang til nettet fra egne bærbare PC'er. Der eksperimenteres pt. med etablering af et sådan net i dele af bibliotekets publikumsområder, i kantiner og lignende områder, hvor de studerende opholder sig. I den sammenhæng tænkes bibliotekets LDAP anvendt til autentifikation af brugerne inden tilkobling til nettet. Den IP-uafhængige adgang til elektroniske tidsskrifter og baser har været en stor succes blandt Syddansk Universitets ansatte og studerende. SDUB har fået mange positive tilkendegivelser fra brugerne. Projektrapport 19 LDAP-infrastruktur

20 RISØ Verisign/https er installeret og autentificering fra lokal OPAC (samt naturligvis fra deff.dk) er implementeret. Lokalt er der tale om en testversion som dog omfatter alle tidsskrifter og alle brugere. At vi stadig lokalt anvender en testversion er betinget af følgende: Den lokale implementering af Verisign har været problematisk og i konfigurationsmæssig henseende mere krævende end først antaget. Vi har valgt at afvente en endelig institutionel afklaring vedr. anvendelsen af eventuelle personfølsomme brugeroplysninger i LDAP-basen inden en lokal markedsføring af løsningen finder sted. En afklaring er nu sket i relation til brugeroplysningerne i LDAP-basen: Risø vil som en rent midlertidig løsning anvende administrativt medarbejder-id som login og fødselsdato som password. I løbet af januar 2003 vil en anden login-procedure blive udviklet, baseret på initial login (medarbejder-id) og prompt for nyt password. Baggrunden for at udvikle den brugerdefinerede password-procedure er naturligvis vores ønske om i størst muligt omfang at minimere risikoen for uautoriseret adgang. Konceptet lokalt er det samme som på deff.dk dvs. brugeren søger de relevante poster frem i en database, i dette tilfælde basen ROAR. Der afkræves login/password såfremt anvendelsen sker fra en pc uden for Risøs IP-range og det rekvirerede tidsskrift er licensbelagt. Som ovennævnt er det i sidste uge lykkedes at installere Verisign/https lokalt og den i sikkerhedsmæssig henseende fulde løsning er dermed implementeret. Det har fra projektets start været hensigten at foretage autentificering direkte op imod vores Active Directory. Risø arbejdede frem til september efter denne løsningsmodel som nu af sikkerhedsmæssige hensyn har vist sig ikke at være realiserbar.vi håber dog stadig på længere sigt at kunne etablere en integration med Active Directory og en løsning baseret på Smartcards overvejes. Indtil videre vil LDAP-basen indeholde brugerdata fra Risø s administrative system (SAP). En rutine vil blive etableret med henblik månedligt udtræk fra SAP og efterfølgende load i LDAP-basen Deltagelse i kommende driftsaftale Web-site med relevant dokumentation herunder proxykonfiguration, Hotline afregnet efter den enkelte deltagers forbrug dvs. en klippekort-ordning. Udnyttelsesplan Stedsuafhængig adgang til licenserede elektroniske tidsskrifter har hele tiden været, og er stadig, udgangspunktet for Risøs anvendelse af Ezproxy/LDAP-løsningen jf. projektaftalen. SB Projektrapport 20 LDAP-infrastruktur

21 Installationen hos SB har været i drift siden juni Al adgang til de elektroniske tidsskrifter sker gennem proxyen. Brugerdata kopieres løbende fra brugerregisteret i bibliotekskatalogen idet der her er tilknyttet de relevante kategorier: AU-studerende, AU-ansat, etc. som er styrende for adgangen til de elektroniske tidsskrifter. Der er dog et problem med aktualiteten af disse data, da der ikke er en løbende kontrol af fx studietilhørsforhold. SB har aktuelle planer om samordning mellem SB-brugerregister og matriklen således at korrekt information om studietilhørsforhold løbende sikres. Det er opnået enighed med universitetsadministrationen om dette, og ordningen forventes indført i foråret 2003 i forbindelse med indførelse af et elektronisk brugerregistreringssystem ved selvbetjening. Herefter vil sygesikringskortet være lånerkort (i det omfang der er brug for et sådant). I registreringsprocessen etableres forbindelse til en ldap-base stillet til rådighed af universitetsadministrationen og der sikres en årlig verifikationsmulighed. Deltagelse i kommende driftsaftale Såfremt der er tilstrækkelig interesse blandt deltagerne, er SB indstillet på efter aftale at videreføre ldap-websiten, mailinglisten, og en form for support. Udnyttelsesplan SB ønsker at udnytte LDAP-systemet/DEF-nøglen i samarbejdet mellem de danske forskningsbiblioteker. Mulige anvendelser er tilkobling af bærbare i serviceområder og andre adgange for fremmede lånere til ressourcer på SB fx digitale ressourcer hvor SB bevaringsforpligtelsen og mulighed for at stille materialet til rådighed for udvalgte brugere. SB anvender desuden resultatet af projektet til at levere en serviceløsning til de biblioteker som ikke selv ønsker at køre en ldap- og proxyservice (den såkaldte base13 service). Pt. er der tilmeldt ca. 20 biblioteker til denne service. SB mener den opnåede ip-uafhængige adgang til elektroniske tidsskrifter har været en så stor succes at det i sig selv har retfærdiggjort projektet. På den anden side kunne en sådan løsning godt være etableret under anvendelse af en mindre generel løsning og færre ressourcer, end det er tilfældet. En fuld udnyttelse af projektinvesteringen vil først finde sted når der etableres en egentlig autorisationskontrol fx i samarbejde med databaseværterne, og når der bliver tale om anvendelser hvor brugerne reelt bevæger sig mere frit mellem forskningsbibliotekerne. Projektrapport 21 LDAP-infrastruktur

22 Økonomi Opstillingen viser den samlede projektbevilling fordelt på aktiviteter og partnere. Budget for LDAP-projektet Lønudgifter Mande- Ansøgt Egen- SB AUB CBS DTV DNLB DPB DVJB HBA KB RUB SDUB RISØ måneder beløb finansiering I alt Løsningskrav og fælles ramme Kompetanceopbygning 4, ,00 0,25 0,50 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 Udvikling DEF-nøglen iflg AAA 18, ,00 4,00 4,00 4,00 2,00 Active proxy 4, ,00 1,00 1,00 1,00 Support Installationspakke og udviklingssupport 4, ,00 2,00 Implementation DEF-nøglen iflg AAA 9, ,00 1,00 1,50 1,00 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 Active proxy 7, ,00 0,50 1,00 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 Test og drift Installation og afprøvning 4, ,00 0,25 0,50 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 0,25 Dataload og replikering 8, ,00 1,00 1,00 1,00 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 Resultatudnyttelse, spredning Tillægsprojekter 6, ,00 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 0,50 Administration Projektkoordination og rapportering 2, ,00 16,00 8,50 12,00 8,50 2,50 2,50 2,50 2,50 4,50 2,50 2,50 2,50 Lønudgifter i alt Øvrige projektudgifter Rejser, møder mv Eksterne konsulenter Programmel, udstyr mv Øvrige projektudgifter i alt I alt 67, Forklaringer til budget: tilskud Der regnes i mande-måneder (mm) løn 1 mm koster kr Den enkelte projektdeltager har selv ansvaret for at føre regnskab over de afholdte udgifter og de anvendte personressourcer. I henhold til DEFs bevillingsskrivelse udbetales projektbevillingen efter godkendelse af hver enkelt af 5 milepæle. I september 2002 godkendtes milepæl 4 og der er udbetalt i alt 80% af kontraktsummen til SB. I projektforløbet har partnerne besluttet at Statsbiblioteket anskaffede softwarelicenser til EZ- Proxy og til Verisign certifikater til alle der ønskede det og derefter modregnede udgifterne. Bevilling Egenfinansiering EzProxy Verisign Restbevilling SB AUB CBS DTV DNLB DPB DVJB HBA KB RUB SDUB RISØ Den enkelte deltager sender fakturaer eller overførselsanmodninger til Statsbiblioteket som derefter overfører beløbene. Til dato er alle overførselsanmodninger på 80% eller derunder blevet efterkommet, medens anmodninger om overførsler af totalbevillingen afventer godkendelsen af nærværende rapport som markerer projektets sidste milepæl. Projektrapport 22 LDAP-infrastruktur

23 Appendiks A Regler for DEF-nøglen 1. DEF-nøglen er realiseret gennem et samarbejde mellem 12 store danske forskningsbiblioteker i LDAP-projektet (Lightweight Directory Access Protocol) under DEF Danmarks Elektroniske Forskningsbibliotek. 2. Det 12 forskningsbiblioteker udpeger ud af deltagerkredsen en DEFnøgleadministrator. Denne rolle varetages indtil videre af Statsbiblioteket som kontraktansvarlig for LDAP-projektet. 3. Deltagere i DEF-nøglen er danske forskningsbiblioteker som anført i bilag 1. Deltagelse er frivillig. 4. Hvert deltagende forskningsbibliotek opbygger og vedligeholder en database over brugere. Brugerdatabasen stilles til rådighed for DEF-nøglen gennem en LDAP-struktur. 5. LDAP definitionen for den enkelte database skal følge skemadefinitionen anført i bilag 2. Det deltagende forskningsbibliotek har ansvaret for at indholdet af LDAP-databasen til enhver tid er korrekt. 6. Samtlige LDAP-databaser forbindes til et LDAP-netværk. Kommunikationen med og i LDAP-netværket foregår krypteret ved at samtlige servere udstyres med et internt certifikat som leveres og vedligeholdes af DEF-nøgleadministratoren. 7. LDAP-netværket udgør en autentifikationsstruktur, som kan anvendes af samtlige deltagende danske forskningsbiblioteker i rollen som serviceudbyder overfor de brugere som er optaget i en eller flere af LDAP-netværkets databaser. Herudover kan DEF og Biblioteksstyrelsen anvende strukturen som serviceudbyder af DEF-Portalen. 8. En serviceudbyder kan anvende DEF-nøglen til autentifikation af en bruger som ønsker at anvende en service hos udbyderen. 9. Autentifikationsprocessen mellem slutbrugerens browser og den portal hvor autentifikation (login) foregår skal ske krypteret ved at portalen er udstyret med et anerkendt certifikat. Serviceudbyderens portal skal desuden udstyres med LDAP-netværkets interne certifikat (jf. 6) til brug for krypteret kommunikation mellem portal og LDAPnetværket. 10. En serviceudbyder kan anvende de brugeroplysninger som LDAP-nettet leverer i forbindelse med at en bruger har foretaget en korrekt autentifikation (login). Serviceudbyderen må ikke anvende det afgivne password til andet end det af brugeren initierede opslag mod LDAP-netværket. Passwordet må aldrig lagres hos serviceudbyderen, heller ikke i logfiler. 11. DEF-nøglen sikrer alene den korrekte autentifikation af den bruger som identificerer sig via opslag i LDAP-netværket. De aftalemæssige forhold i forbindelse brugerens anvendelse af services hos serviceudbyderen er DEF-nøglen uvedkommende og alene en sag mellem brugeren og serviceudbyderen. Projektrapport 23 LDAP-infrastruktur