Uni-C Nøglerapport 1999 - DEFF

DEF-nøglenForslag til realisering af fælles brugervalideringtil DEF-tjenester© UNI•C August 1999

DEF-nøglenForslag til realisering af fælles brugervalidering til DEF-tjenester©UNI•C August 1999Version 1.1Af Erik Bertelsen, Anders BandholmK:\ENH\MM\SBT\3039 defnøgle\DEF-Nøgle-Rapport.doc

1 Introduktion 1Indhold1 Introduktion ................................................................................ 31.1 Undersøgelsens baggrund og formål.................................. 31.2 Undersøgelsens indhold ..................................................... 31.3 Ønsker til DEF-nøglen ........................................................ 42 Anvendelse af on-line ressourcer i DEF ..................................... 62.1 Bibliotekernes tjenester ...................................................... 62.2 Web-tjenester og andre tjenester på nettet ......................... 62.3 DEF-nøglen ........................................................................ 73 Begreber og protokoller............................................................ 103.1 AAA .................................................................................. 103.2 Client-server begrebet ...................................................... 133.3 Cookies ............................................................................ 153.4 Certifikater ........................................................................ 153.5 Proxy-løsningen................................................................ 163.6 LDAP ................................................................................ 184 Mulige løsningskomponenter ................................................... 194.1 Cookies ............................................................................ 194.2 Digitale certifikater ............................................................ 204.3 Proxy ................................................................................ 214.4 LDAP ................................................................................ 224.5 SkoDa............................................................................... 224.6 ISOS/Athens..................................................................... 234.7 IBM SecureWay Policy Director........................................ 234.8 Delkonklusioner ................................................................ 245 Systemmodel ........................................................................... 275.1 DEF-nøglen i en proxy-løsning ......................................... 275.2 Den decentraliserede model ............................................. 28¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

1 Introduktion 25.3 Den centrale model........................................................... 295.4 Sammenligning af de to modeller...................................... 316 Opsamling................................................................................ 346.1 Hovedkonklusioner ........................................................... 346.2 Omkostninger ................................................................... 357 Bilag......................................................................................... 38¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

1 Introduktion 31 IntroduktionI denne rapport præsenterer vi nogle anbefalinger til etablering af DEF-nøglen,dvs. en samlet adgangskontrol til de Web-ressourcer, som DEF-bibliotekerne tilbyderderes samlede brugerskare.Efter en beskrivelse af rapportens baggrund (kap. 1) og forskningsbibliotekernestilbud 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 baseretpå nogle konklusioner i kap. 4. Endelig gives nogle samlede anbefalinger ikap. 6.1.1 Undersøgelsens baggrund og formålUndersøgelsen skal med udgangspunkt i tidligere udarbejdede rapporter give DEFet beslutningsgrundlag for, hvordan man ønsker at implementere en for brugernesammenhængende adgangskontrol (DEF-Nøglen) til ressourcer tilbudt via DEF.Denne rapportering er foretaget af UNI•C i maj og juni 1999 baseret på foreliggenderapport og notater, møder i DEF-nøglegruppen, samt interviews med repræsentanterfor 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 DEFtjenesterkun skal identificere sig en gang, og således at bibliotekerne får de nødvendigeoplysninger til den økonomiske håndtering, samt til ekspedition af papirbaserededokumenter.1.2 Undersøgelsens indholdIfølge aftalen om denne udredning skal rapporteringen omfatte følgende:1. Hvilke tekniske muligheder er der for at realisere en løsning, der opfylder dekonceptuelle krav? Det skal således undersøges, hvilke eksisterende metoderog værktøjer, der kan anvendes til at realisere DEF-nøglen, og hvilken yderligereudvikling, 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 mereenkel løsning til en komplet, og hvordan. – Der er et presserende behov forat få en styring af adgang til fx elektroniske fuldtekster. En trinvis realiseringaf DEF-nøglen kan tage udgangspunkt i opfyldelsen af dette behov. - Der skalredegøres for tidsrammerne for virkeliggørelsen af de løsninger, der foreslås.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

1 Introduktion 43. 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, oghvad der eventuelt skal til af ekstra investeringer. – Som et særligt problemskal det udredes, hvordan små forskningsbiblioteker med beskedent eget ITudstyrkan deltage i en sådan fælles brugeradministration.4. Der ønskes så vidt muligt et økonomisk overslag over omkostningerne ved deforeslåede løsninger.1.3 Ønsker til DEF-nøglenAdgangen 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 udarbejdetaf Karl Krarup:1. DEF-nøglen bygger på et fælles format, som på sikker måde identificerer brugerenog giver:brugerens institutionelle tilhørsforhold, kategori af brugerrettighed, sompågældende institution meddeler,DEF kategori, som bestemmer adgang til DEF ressourcer i henhold til aftalermellem 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 fxberoende på samarbejdsaftaler mellem to eller flere institutioner.De enkelte centre og biblioteker fastlægger selv adgangsrettigheder med relationtil DEF-nøglens brugerkategorier for de informationsressourcer, som pågældendecenter selv giver adgang til direkte eller indirekte.2. Adgang til DEF-ressourcer skal kunne ske vha. DEF nøglen uanset brugerensarbejdssted 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. registreringensker decentralt i overensstemmelse med gældende format og fælles anerkendteadgangskategorier.5. Den udstedende institution kan bruge DEF-nøglen på samme måde, som denaktuelle lokale brugerregistering og dermed afgrænse adgang til betalingsbaserederessourcer som kun er betalt for brugere med tilknytning til pågældendeinstitution/campus/bibliotek.6. Fastlæggelsen af adgangsrettigheder beror på centret selv, de bevillingsmæssigeforudsætninger og kontraktforhold knyttet til de enkelte informationsressourcer.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

1 Introduktion 57. Adgangsrettigheder på de enkelte centre beskrevet ved brugerkategori og institutionstilknytningskal være offentligt tilgængelige på centrets web.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

2 Anvendelse af on-line ressourcer i DEF 62 Anvendelse af on-line ressourcer i DEFHer beskriver vi nogle anvendelsesscenarier og nogle forudsætninger, hvorpå forslagettil DEF-nøglen bygger.DEF-samarbejdet er et samarbejde mellem forskningsbibliotekerne i Danmark, ogi første omgang ser vi på de 12 ”store” forskningsbiblioteker, deres brugere ogderes tjenester. Samarbejdet skal efterfølgende kunne udbygges til at dække enbetydeligt større del af forskningsbibliotekerne, og desuden skal samarbejdet medandre bibliotekstyper og tjenesteudbydere i Danmark samt med biblioteker i udlandetogså passe ind i modellen.2.1 Bibliotekernes tjenesterForskningsbibliotekerne udbyder forskellige typer tjenester, som skal integreres iDEF, 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 formidlesgennem biblioteket.• Endvidere kan netværkstjenesterne anvendes til at formidle tjenester, som ikkei sig selv formidles via nettet, fx bestilling af dokumenter, der skal sendesmed posten eller bringes til brugeren.Ud fra de gennemførte interviews danner der sig et billede af, at en del af bibliotekernei fremtiden selv vil udbyde færre on-line tjenester end i dag, idet disse oftevil blive formidlet af bibliotekerne direkte fra leverandørerne af disse tjenester.Dette billede suppleres ved, at der på enkelte biblioteker og andre institutionertilbydes nye elektroniske tjenester, fx artikeldatabaser (som DADS) og Webindekser.2.2 Web-tjenester og andre tjenester på nettetDet er også vigtigt for etableringen af et samlet udbud af netværkstjenester, somforventes 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 7browser som klientprogrammellet i kommunikationen med servere, og hvor vianvender http som bæreprotokol på nettet. Derfor behandler vi ikke de af bibliotekernesnetværkstjenester, som i dag formidles vha. telnet-protokollen. Vi går herud fra, at disse – typisk ældre – tjenester vil blive afløst af Web-baserede tjenesteri fremtiden, og at de derfor ikke vil indgå i den fremtidige DEF-løsning.Desuden findes der et antal andre netværksprotokoller, som bibliotekerne senerekan overveje betydningen af som protokoller mellem slutbrugerarbejdspladserneog det forreste ”lag” af servere. Her kan vi nævne protokoller som Z39.50, somhelt klart har en væsentlig rolle at spille i servernettet bag de Web-servere, somhar den direkte forbindelse med brugerne, men hvis rolle i den direkte klientkommunikationikke er helt så oplagt.2.3 DEF-nøglenEn del af bibliotekernes netværkstjenester vil være frit tilgængelige for alle, medensandre kræver, at brugeren har identificeret sig over for systemet og at denneidentifikation anvendes til at beslutte, om brugeren har adgang. Metoden til atgennemføre denne identifikation og validering kalder vi DEF-nøglen.Fra nogle sider fremføres det, at mange netværkssessioner med DEF kun vil resulterei søgning i og visning af dokumenter, som er frit tilgængelige for alle. Deter her et åbent spørgsmål, om brugere af DEF skal validere sig ved starten af enDEF-session og måske dermed kunne nyde godt af en personlig startside i portaleneller andre personligt definerede opsætninger, eller om brugeren først skalafkræ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 ressourcerhos bibliotekerne, men forudses også anvendt til at validere adgangen til at modtageikke-digitale tjenester, fx bestilling af fjernlån og fremsendelse af kopier aftidsskriftartikler.2.3.1 BrugerkategorierNår en bruger er defineret som bruger af ét bibliotek, vil denne brugeridentifikationogså via DEF-nøglen kunne anvendes til at tillade brugeren adgang til tjenesterhos andre biblioteker, som indgår i DEF-netværket.Det forventes, at hvert deltagende bibliotek vil dele sine brugere op i et mindreantal 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 deenkelte 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 kategorierbehøver således ikke at afspejle de kategorier direkte, som anvendes i de lokale bibliotekssystemer.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

2 Anvendelse af on-line ressourcer i DEF 8verede biblioteker forventer vi ikke, at alle bibliotekerne vil anvende de sammekategorier, og systemet skal derfor kunne håndtere, at hvert bibliotek selv definerersine egne kategorier.Afhængigt af kategorien af tjenesterne og af de indgåede aftaler, vil det tjenesteudbydendebibliotek i en del tilfælde kunne afgøre adgangsvalideringen på basisaf oplysninger om brugerens hjemmebibliotek og brugerkategori uden at skulledifferentiere 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 udfra en anden kategori end den i øjeblikket aktive.2.3.2 Adgangskontrol og betalingI denne rapport beskriver vi primært anvendelse af brugervalidering og dermed afDEF-nøglen som en metode til at identificere brugeren og til at afgøre, om brugerenhar adgang til en given ressource. Hvis anvendelsen af disse ressourcer udløseren forbrugsafhængig betaling, kan DEF-nøglen (udvides til at) anvendes til atgenerere 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 vilvære tilgængelige på fastprisvilkår (herunder gratis) og hvor mange, som skalafregnes efter aktuelt forbrug.2.3.3 Single Sign-onDEF-nøglen er et forsøg på at realisere den mekanisme, som andetsteds også bliverkaldt Single Sign-on.I denne rapport benyttes begrebet Single Sign-on kun om rigtig eller en kompletSingle Sign-on, som vi forstår som en mekanisme, hvor brugeren kun identificerersig én gang i en netværkssession, selv om den omfatter kommunikation med flereservere, evt. fordelt på flere institutioner. Single Sign-on i denne betydning kanselvfølgelig kun etableres mellem samarbejdende tjenesteudbydere, men DEF erjo netop et eksempel på et sådant samarbejde. Se afsnit 3.1.4 for en uddybelse afbegrebet 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 ogsoftware.• 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 AdgangskontrolteknikkerI biblioteksverdenen er IP-nummerbaseret validering meget udbredt i dag, da dentilbyder et sikkerhedsniveau, som er acceptabelt for informationsudbyderne, fxforlag. Denne valideringsform er dog meget ufleksibel, idet den ikke tillader enperson at anvende bibliotekstjenesterne fra andre fysiske steder end de, hvis IPnumreer på positivlisten – bl.a. er adgang fra hjemmet oftest blokeret.Det er et krav fra DEF, at adgangskontrollen fremover baserer sig på identifikationaf personen uafhængigt af vedkommendes placering, og derfor fokuserer vipå brugernavnsvalidering, og IP-nummerbaseret validering indgår ikke i denoverordnede definition af DEF-nøglen. Dog kan vi forvente, at den del af de lokalesystemer fortsat vil anvende IP-nummerbaseret validering lokalt.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 103 Begreber og protokollerFor 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æssigtgrundlag at vurdere disse konklusioner ud fra.I dette kapitel beskriver vi nogle begreber, standarder og protokoller, som er relevantefor at konstruere DEF-nøglen.3.1 AAAI forbindelse med adgangskontrol til netværksressourcer er der 3 begreber, som eri fokus (her angivet med de engelske termer):• Authentication• Authorisation• AccountingSamlet kendes disse begreber også som AAA (”Triple-A”) 2 . I denne rapport brugervi denne betegnelse for de tilhørende begreber, men ikke som identifikation afkonkrete produkter. I denne rapport beskæftiger vi os især med de to første afA’erne, dvs. Authentication og Authorisation, men vi anvender alligevel dengængse term AAA, også selv om ikke alle 3 A-begreber er relevante i den givnesammenhæng.Disse begreber er de bærende begreber, når vi skal definere DEF-nøglen og densanvendelse. 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ænkervi på autentificerings- og/eller autorisationsservere, uanset om de er distribueredeeller 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 dissespørgsmål dukke op igen og være væsentlige for vurderingen af de forskelligemodeller.2 Det kan nævnes, at IETF (som er det forum, hvor de fleste Internet-standarder er udviklet) haretableret en AAA-arbejdsgruppe, som arbejder med at afklare begreberne og evt. definere protokollertil generel håndtering af AAA-problematikkerne. Denne gruppe har i juni 1999 produceretet arbejdsdokument (”work in progress”) under titlen ”AAA Authorization Architecture and Requirements”.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 113.1.1 AuthenticationDet helt basale begreb for at realisere DEF-nøglen er Authentication, på halvgodtdansk: autentificering. Kernen i dette begreb er, at brugeren identificerer sig overfor 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 oplysekodeord (password) eller PIN-kode.Autentificering af brugeren kan foregå på flere måder, men hvis sikkerheden forkorrekt 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 realisereauthorisation eller accounting.3.1.1.1 Brugernavne og kodeordSikkerhedsniveauet i denne teknik afhænger i høj grad af, om brugerne er omhyggeligemed 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ærligthøjt sikkerhedsniveau er krævet, må andre teknikker tages i anvendelse.Anvendelse af brugernavne og kodeord er bl.a. problematisk, hvis det er muligtfor uautoriserede personer at aflytte netværkstrafikken, hvorfor der kan være etargument for, at de sendes over krypterede netværksforbindelser, hvilket i Websammenhængkan være anvendelse af SSL 3 , som har været og er den mest udbredtestandard 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 ressourcerpå serveren kan kræve brugeren autentificeret med brugernavn og kodeord.For brugeren ses dette ved, at browseren viser en dialogboks, hvor brugeren skalangive sit brugernavn og kodeord. Hvorledes serveren kontrollerer gyldigheden afdet oplyste brugernavn og kodeord er ikke specificeret som en del af BasicAuthentication. 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 Webservereunderstø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 sikkerkommunikation mellem browsere og Web-servere. SSL giver kryptering af datatransmissionensamt autentificering af serveren (og evt. klienten).¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 12Basic Authentication virker kun over for en enkelt server (ved skift til en ny serverkommer der altid en ny brugernavnsdialog), og derfor er den primært relevanti 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å andreoplysninger om brugeren op i den tilhørende brugerdatabase eller AA-server (fxkategori(er) eller forsendelsesadresse).3.1.1.2 Stærk autentificeringEn anden måde at autentificere brugeren på bygger på digitale certifikater. Dettekaldes undertiden stærk autentificering. Det digitale certifikat indeholder en identifikationaf brugeren samt evt. øvrige oplysninger. Det hele er underskrevet digitaltaf en certificeringsmyndighed. Ud over besiddelse af certifikatet, skal brugerennormalt 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 anvendedette certifikat fra andre maskiner, hvis certifikatet installeres der.En sikrere måde at opbevare certifikatet på er at placere det på et magnet- ellerchipkort, idet brugeren så dels skal besidde dette kort og samtidig kende kodeordetfor at kunne anvende certifikatet. I denne situation kan man ikke bruge (en kopiaf) en andens chipkort uden også at kende kodeordet. Det største og umiddelbartblokerende problem ved denne metode er, at den kræver hardwareudstyr installereti alle maskiner, hvorfra brugerne ønsker at anvende systemerne.3.1.2 AuthorisationNår en bruger er blevet autentificeret over for et system (en server), kan denneserver efterfølgende anvende den autentificerede identitet til at afgøre, hvorvidt oghvilken adgang, brugeren har til givne ressourcer på serveren. Denne proces kaldesauthorisation.Sådanne autorisationer kan implementeres meget bredt eller meget specifikt overflere dimensioner:• Alle brugere har adgang til en given ressource, specifikke navngivne brugerehar 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 heltned 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 13Ofte beskrives autorisationsmekanismen i form af autorisationspolitikker, somigen er opbygget af såkaldte Access Control Lists (ACL). En sådan ACL beståroverordnet 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ærskilteautorisationsservere, som evt. betjener flere servere.3.1.3 AccountingAccounting er det at opsamle statistikker om brugernes autentificerede eller anonymeanvendelse af systemerne, som kan danne grundlag for forbrugsopgørelserog dermed beregning af betalingsgrundlaget for tjenesten.Accounting behandles ikke i nærmere detalje i denne rapport, og en implementationheraf vil ske i de enkelte systemer under indtryk af anvendelsesaftalernemellem bibliotekerne.3.1.4 Single Sign-onVed Single Sign-on forstår vi i denne rapport det, at en bruger kun skal identificeresig (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 deltagendeinstitutioner.Formålet med DEF-nøglen er kort sagt at kunne realisere en Single Sign-on overfor 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. Idenne 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 brugerenskal have oprettet et nyt brugernavn med kodeord, når han eller hun ønsker atanvende en ny tjeneste.3.2 Client-server begrebetVi anvender begreberne klient og server gentagne gange i denne rapport som betegnelsefor 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, fxandre Web-servere, databaseservere mm.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 14Nå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) ogden 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 servicesProxy 2Server1Proxy 1ForresteservereProxy nServer2Server4Server3Ofte vil de servere, som fungerer som servere over for de forreste servere ikketillade kommunikation direkte fra brugerne og deres browsere. Ansvaret for atautentificere brugerens adgang ligger hos den forreste server (der derfor ofte, menikke altid vil fungere som en proxy), og de bagvedliggende servere stoler på atdenne 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 afviserklientforespørgsler fra alle andre. Dette kan også være med til at etablere servicespå systemer, som ikke selv kan implementere den ønskede autentificering.Et vigtig konsekvens af at anvende client-serverteknikker i flere lag er, at selv ombrugerens arbejdsstation kun anvender en browser til at nå de forreste servere(http), kan disse henvende sig til bagvedliggende servere med samme eller medandre protokoller. På tegningen ovenfor vil kommunikationen mellem brugerenog Proxy 1 og mellem Proxy 1 og Server 2 måske være med http, medens protokollenmellem Server 2 og Server 3 kan være noget andet (fx Z39.50 ellerLDAP). 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 brugerenvil få præsenteret direkte eller indirekte, og hvilke, der kun har interne tjenester.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 15Et eksempel kan være, at Server 4 kun fungerer som AAA-server, medens de øvrigebagvedliggende 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 yderligereoplysninger om brugerne, end de allerede måtte have i form af DEF-nøgleneller 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 debrugere, hvis oplysninger, de bestyrer. Sådanne AAA-services etableres for alle debiblioteker, som indgår i DEF-samarbejdet. Dette bevirker, at oplysningerne ombrugerne vedligeholdes i disse servere (som evt. kan være en del af de egentligebibliotekssystemer) lokalt for hvert enkelt bibliotek. Mindre biblioteker, som ikkeselv ønsker eller kan drive denne tjeneste kan evt. få den leveret af andre bibliotekereller institutioner i DEF-samarbejde.Vi beskriver her ikke i detaljer, hvilke oplysninger, disse AAA-servere kan tilbydetil andre servere inden eller uden for det pågældende bibliotek, og dette forholdkan reguleres af en blanding af tekniske krav og administrative aftaler bibliotekerneimellem.3.3 CookiesI web-sammenhæng er en cookie en lille stump data, som en server kan sende tilen browser, og som browseren efterfølgende sender uændret med i alle efterfølgendehenvendelser til samme eller i visse situationer til andre servere. Indholdetaf cookien vælges af serveren, der også sætter nogle retningslinier for, hvor længeklienten skal opbevare og fremsende den pågældende cookie, og hvem den skalsendes 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 CertifikaterModerne browsere understøtter sikker (krypteret) kommunikation via SSLstandarden,og i den forbindelse er det nødvendigt for (primært servere) at kunnebevise deres identitet, og ægtheden (egentlig ejerskabet af) deres offentlige krypteringsnøgle.Men som en del af SSL-standarden er der også udviklet mulighedenfor, 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 brugerensvalg – præsenteres for en vilkårlig anden server. Certifikater ser ud til atvære godt understøttet af browserne (dog ikke på helt samme måde), således atbrowseren mere eller mindre automatisk kan generere et nøglepar, sende den offentligenøgle til en server, få et underskrevet certifikat tilbage, og automatiskinstallere dette i browserens ”certifikat-database”.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 16Selvom moderne browsere altså understøtter certifikater, ser det ud til, at de gørdet på en lidt forskellig måde, således at certifikater til brug i de forskelligebrowsere skal laves på hver sin måde. Der findes dog eksempler på servere, somkan lave certifikater til en række forskellige browsere (fxhttp://www.thawte.com/).3.5 Proxy-løsningenDenne løsningsmodel bygger på, at al adgang til tjenesterne sker gennem noglesåkaldte proxy-servere, jf. nedenstående figur.Proxy 2Proxy 3Proxy ndef.dtv.dkProxy 1Figur 1. Proxy-modellenDEFserverDEFserverDEFserverDEFserviceDEFserverdef.dtv.dk/dtvkat/søg.htmlkat.dtv.dk/søg.html (user=17, pw=xx)def.dtv.dk/sol/sma/søg.htmlxxx.sb.aau.dk/sma/søg.html (bruger-id)Brugerid:uder=zz, pw=wwuser=dtv/17, pw=xxuser=dtv, pw=yyBrugeren sidder ved sin arbejdsplads, som kan være på arbejdspladsen, hjemme,på rejsen eller på biblioteket. Brugeren ønsker at anvende tjenester, som udbydesaf en eller flere DEF-servere.I denne model har brugeren ikke direkte adgang til den egentlige tjenestebærendeserver (som er placeret inde i cirklen på figuren), idet det ser ud som om tjenestenudbydes på proxy-serveren. Der kan være en eller flere proxy-servere, som allehar samme funktionalitet. For en given session foregår al kommunikation mellembrugerens arbejdspladsmaskine og DEF-serverne gennem den samme proxy, ogderfor 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 dennehar følgende funktioner:¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

3 Begreber og protokoller 171. Autentificering. Brugerne logger ind på proxy’en, og proxy’en stiller oplysningerom denne validering til rådighed for de bagvedliggende servere, sombærer de egentlige tjenester. Da al kommunikation mellem brugerens maskineog DEF-serverne foregår gennem proxy’en, kan Basic Authentication anvendes.En forskel fra anvendelsen af Basic Authentication for en enkelt serverer, 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’enomskriver URL’er til sig selv til nye URL’er til de ”rigtige” servere ogsender brugerens forespørgsel videre til disse servere.3. Videresende Web-sider fra serverne til brugerne. Under denne videresendelseskal 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 enbagvedliggende server, skal den om fornødent også sende valideringsoplysningervidere til pågældende server. Dette kan dreje sig om de oprindeligelogin-oplysninger fra brugerens egen session med proxy’en eller om omskrevnelogin-oplysninger, der fx blot indeholder biblioteks-id, evt. med brugerkategori.Dette kan baseres på oplysninger i proxy’en selv eller ved opslagi en autorisationsservice.Punkt 2 og 3 herover svarer til de opgaver, som en almindelig Web-proxy har, ogdet har lagt navn til hele løsningsmodellen. Det bemærkes dog, at i denne modeler proxy’en aktiv i den forstand, at den manipulerer både Web-forespørgsler og deresulterende svar. Den er altså ikke en traditionel transparent proxy, og den skalikke lægges ind i brugerens browseropsætning som generel proxy.Hvis en server i DEF har brug for yderligere oplysninger om en bruger, fx enpostadresse, kan serveren hente disse oplysninger hos enten proxy-serveren elleren AAA-server.3.5.1 Variationer af Proxy-modellenHerover har vi beskrevet proxy-løsningen i sin ”rene” udgave, hvor al kommunikationmellem brugerne og serverne sker gennem én proxy. Hvis serverne er satop, 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 deenkelte servere ikke selv har ansvaret for at autentificere brugerne. Når det kommertil at afgøre, om brugerne skal have adgang til de enkelte ressourcer, har mani princippet valget mellem at lade denne kontrol foregå i de enkelte servere, eller iproxy’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 18Hvis et bibliotek har tjenester, som ikke kræver adgangskontrol, og hvis disseligger på servere, som udelukkende har sådanne tjenester, behøver kommunikationenikke 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 – skaltjenesterne på denne server konfigureres, således at konflikter og omgåelser afsikkerheden ikke er mulige, fx ved at alle henvisninger til kontrollerede tjenestersker via links gennem proxy’en.3.6 LDAPLDAP – Light-weight Directory Access Protocol – er en internetstandard, der idag 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 ogoplysninger om fysiske objekter (fx personer og bygninger) og begrebsmæssigeobjekter (fx services eller rettigheder) . I en LDAP-database kan der være forskelligeobjekttyper, hver med sine attributter. De enkelte poster er navngivet med etsåkaldt Distinguished Name, der er opbygget hierarkisk, fx efter en organisatoriskstruktur. 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 datavedligeholdes i en LDAP-struktureret database (server) og om den netværksprotokol,hvormed en klient slår oplysninger op i et directory (uanset om dataene vedligeholdesi selve LDAP-serveren).¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 194 Mulige løsningskomponenterI dette kapitel beskriver vi, hvorledes nogle af de begreber, som er introduceret iforrige kapitel, kan anvendes til at realisere DEF-nøglen.Vi beskriver senere i kapitlet nogle af de eksisterende systemer, som i dag anvendestil at realisere DEF-nøgle-lignende funktioner helt eller delvist for forskelligebrugermiljøer i og uden for biblioteksverdenen. Denne oversigt er langt fra kompletmen tjener først og fremmest til at illustrere, at der findes programmel påmarkedet, som er relevant for denne type systemer.Endelig slutter vi kapitlet med at fremdrage nogle delkonklusioner, som er med tilat forklare den systemmodel, som vi senere beskriver.4.1 Cookies4.1.1 Cookies som DEF-nøglerI DEF-sammenhæng er det interessante ved cookies, at de – under visse omstændigheder– kan defineres (”sættes”) af en server, men sendes tilbage til alle andreservere i samme DNS-domæne, fx under deflink.dk-domænet, jf. den nuværendeadresse på DEF-portalen. Man kan derfor forestille sig, at DEF-nøglen implementeresved, at brugeren fra sit hjemmebibliotek eller autentificerende server fårudstedt en cookie, som indeholder en (evt. midlertidig) identifikation samt en digitalunderskrift på gyldigheden af nøglen – kort sagt skriver udstederen af cookienunder på, at brugeren er autentificeret som DEF-bruger, og at hjemmebiblioteketkan udlevere yderligere oplysninger om brugeren, hvis det er nødvendigt.Herved bliver cookien som sådan til DEF-nøglen, og den indeholder oplysningerom hjemmebibliotek, brugerkategori og evt. selve brugernavnet. Servere, som påbasis af denne cookie har brug for (og lov til at få) yderligere oplysninger om brugeren,må så på anden vis sende en forespørgsel til den AAA-server, som bestyrerden pågældende brugerdatabase. Denne forespørgsel kan evt. foretages medLDAP. Ægtheden og fortroligheden af oplysningerne i en cookie, der anvendes pådenne måde, kan sikres ved teknikker til kryptering og digitale signaturer.Da cookies ikke er en standardiseret metode til validering/adgangskontrol, vil detogså være nødvendigt at udvikle nogle cookie-baserede AAA-moduler, som skalinstalleres på de enkelte servere. Hvis en server ikke tillader den form for tilpasning,kan man evt. sætte en lokal proxy foran.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 204.1.2 Problemer i anvendelse af CookiesDer hersker en del bekymring om cookies, fordi de typisk i browsernes standardopsætningbliver accepteret automatisk, og dermed ”bag om ryggen” på brugeren.På den måde får websites en mulighed for at genkende brugeren, og tilbydeen personlig tilpasning – men også en mulighed for at holde detaljeret øje medbrugerens handlinger på serveren, og da en cookie kan sættes til at have en langudløbstid, kan man tegne en præcis karakteristik af brugerens handlinger over tid.Umiddelbart synes bekymringen for cookies at være overdreven, da den omtaltekortlægning af brugerens handlinger også er mulig bl.a. ved at analysere webserverenslog-filer.I DEF-sammenhæng er det derfor vigtigt at gøre sig klart, at visse brugere vil ønskeat køre uden at browseren accepterer cookies. Det kan være muligt at vælge enimplementering af DEF-nøglen, som virker strømlinet med cookies, men som ikkevirker så strømlinet uden cookies (måske skal man logge ind ved serverskift).Derimod er det næppe acceptabelt at designe en løsning, som slet ikke kan anvendesaf brugere, som afviser cookies.4.2 Digitale certifikater4.2.1 Midlertidige certifikater som DEF-nøglerPå lignende måde, som beskrevet ovenfor i afsnittet om cookies, kan certifikatetanvendes til at realisere DEF-nøglen, idet det indeholder en identifikation af brugeren.I DEF-sammenhæng kunne man forestille sig, at brugeren efter autentificering hossit hjemmebibliotek, får udleveret et midlertidigt certifikat til sin browser, somdernæst kan videregive det til DEF-serverne. Har brugeren flere certifikater, fårbrugeren – i følge dokumentationen – valget mellem, hvilket certifikat man ønskerat anvende over for en given server. På serverne er det muligt at forlange, at enbruger er autentificeret ved et certifikat, og dernæst kan autorisationer basere sigpå oplysninger indeholdt i certifikatet eller ved opslag i en AA-server.En klar fordel ved brugen af certifikater er, at de er en del af SSL-specifikationen,og at en række (de fleste) Web-servere understøtter denne teknik, og i et eller andetomfang er i stand til at udtrykke regler om adgang i termer af oplysninger indeholdti certifikatet.Ideen med at benytte midlertidige certifikater har dog en række problemer:• Til anvendelsen af certifikatet er knyttet en privat krypteringsnøgle, som mannormalt skal passe meget på. Browseren vil derfor stærkt anbefale, at mansætter et password på sin certifikat-database.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 21• Hvis brugeren sætter et password, skal det angives (næsten), hver gang etcertifikat skal anvendes, og hvis det sker på en PC på en læsesal, vil efterfølgendebrugere ikke kunne anvende PC’en, da de jo ikke kender kodeordet.• Da brugen af certifikater normalt er knyttet til sikkerhedsfunktioner, vilbrowseren på alle måder forsøge at beskytte certifikater og nøgler mod uautoriseretadgang, og det er derfor ikke muligt at lave ordentlige genveje, der påen eller anden måde undviger de mange dialogbokse.• De midlertidige certifikater giver ikke den stærke autentificering som depermanente, idet de jo ”kun” anvendes til at bekræfte et brugernavnskodeordsbaseretlogin over for de øvrige servere i DEF.Kort sagt er det vanskeligt at lave en enkel og transparent løsning for brugerne,baseret på midlertidige certifikater. Men hvis disse besværligheder accepteres somnødvendige, kan det være en mulig løsning med dagens tilgængelige software.4.2.2 Permanente certifikater som DEF-nøglerPå den anden side er der så mange fordele ved certifikater, at det bestemt er enmulighed at benytte permanente certifikater – men det kræver, at brugeren har enlet måde at medbringe den private del af certifikatet. Her anvendes de permanentecertifikater til autentificering og autorisation som de midlertidige.Den ”rigtige” løsning synes at være at have certifikater og nøgler gemt i etsmartcard, som kan aflæses ved alle terminaler. En interessant mulighed i fremtiden.4.3 ProxyProxy-løsningen er interessant for DEF, fordi den bygger på kendt teknologi, ogfordi den rent faktisk gør det muligt at realisere Single Sign-on.Selvom DEF-nøglen med brugerkategori osv. ikke materialiseres for brugeren, serdet funktionelt ud, som om den var udleveret til brugeren. Hver gang proxy’eneller en bagvedliggende server har brug for oplysninger om brugeren, kan disseoplysninger hentes hos en AA-service baseret på de login-informationer, som brugerenhar indtastet.Prisen for at opnå dette er til gengæld, at al nettrafikken til de adgangskontrollerendetjenester går gennem proxy’en. Hvis der skal etableres flere proxy’er, vil detvære hensigtsmæssigt at kræve, at de bygger på samme systemplatform (operativsystem,mv.), især da de forventes etableret som selvstændige maskiner.Afhængigt af om adgangskontrollen til de enkelte tjenester placeres på tjenestensegen server eller i proxy’en, vil eksisterende servere i et vist omfang kunne kørevidere uændrede eller med mindre tilpasninger, hvilket kan være vigtigt for serverebaseret på proprietære applikationer.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 22Hvis en server har ressourcer, som kræver autorisation, både indgår i DEF-nettetog tilbyder lokale brugere sine tjenester, er det op til den selv at sikre, at det totalesystems sikkerhedsmæssige integritet ikke brydes.4.4 LDAPVi forudser ikke LDAP anvendt direkte i kommunikationen mellem brugernesmaskiner og de forreste servere og/eller proxy’er, jf. figuren på side 13. Derimodser vi en rolle for LDAP som den ikke-proprietære protokol, der kan anvendesmellem DEF’s servere indbyrdes til at udveksle AAA-relaterede oplysninger, bådemellem dataserverne og AAA-serverne og mellem AAA-serverne og de bagvedliggendeadministrative systemer.Med LDAP kan man dels implementere brugernavns- og kodeordskontrollen vedlogin (autentificering), men også efterfølgende opslag for at finde yderligere oplysningerom brugeren efter behov, herunder både de oplysninger, som indgårdirekte i DEF-nøglen, men også yderligere oplysninger, hvis dette er nødvendigt.Hvis der fx laves et logisk set samlet directory over DEF-brugere, kan dette vedligeholdesdecentralt for hvert deltagende bibliotek.Tilsvarende kan man anvende et LDAP-directory til at opbevare de politikker mv.,som udgør autorisationssystemet.4.5 SkoDaSkoDa er det korte navn for ”Skolernes Databaseservice”, som i en del år har leveretdatabase-adgang fra danske skoler til en række danske og internationale databaser.Når SkoDa er interessant i denne sammenhæng, er det fordi SkoDa har enrække fællestræk med ønskerne i DEF, men også fordi SkoDa benytter sig af denteknik, som vi omtaler som ”proxy-modellen”.SkoDa er en nettjeneste over for undervisningssektoren, der via såvel telnet somweb giver adgang til en række vidt forskellige nettjenester (Britannica Online,Polinfo, DanBIB, DMI vejrradar m.fl.). Over for disse nettjenester har SkoDa kunet enkelt eller få brugerid/passwords, medens hver bruger har ét brugerid/pass–word, der identificerer vedkommende over for SkoDa.Baseret på en relativt simpel algoritme får brugeren kun adgang til de tjenester,som hans abonnement dækker.Adgangen til tjenesterne skabes ved, at al brugerens trafik til den pågældende tjenestebliver dirigeret gennem én central server, som lader et proxy-program foretagede nødvendige omskrivninger af trafikken til og fra brugeren.I dag har ca. 1500 institutioner med i gennemsnit 300 brugere tegnet abonnementpå systemet. Selvom al trafik fra alle brugere af systemet således går igennem denrelativt lille server, er der ikke performanceproblemer på proxy-delen af SkoDa.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 234.6 ISOS/AthensBrugernes tilladelser og brugerid/password registreres i en central server (AccessManagement System), som dog til en vis grad kan decentraliseres – først ogfremmest er administrationen af privilegier hierarkisk, i den forstand, at man kanuddele rettigheder til en entitet – fx et bibliotek – som så kan videredelegere rettighederne.Systemet implementerer et Single Account system, og den store styrke ligger i, attilladelserne til adgang til materiale på den enkelte server kan administreres megetdetaljeret.Systemet benytter sig af server-plugins (i ISOS-terminologien kaldt agenter), derkommunikerer med den centrale tilladelsesdatabase via en protokol, der ikke erredegjort nærmere for.Figur 2. ISOS Princip-skitse4.7 IBM SecureWay Policy DirectorSystemet består af en central database i et proprietært format, en proxy, der giverbrugerne afgang til de enkelte services (via web, telnet og andre "forlæns" TCPforbindelser).Proxy'en (WebSeal) kan give brugerne adgang på baggrund af basic-authorizationog senere certifikater. Kommunikationen mellem denne og databasen sker vha. enDCE/Kerberos protokol, men hverken klienter eller servere skal brugeDCE/Kerberos.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 24IBM har et policy-statement om understøttelse af LDAP på tilladelsesdatabasen,men det er ikke en realitet lige nu. Hvis vi også vil have LDAP, skal vi selv lavesådan en database, som så føder den tilladelsesdatabase, der styrer systemet.SPD består af flere produkter fra IBM og andre leverandører. Bl.a. indeholder denWebSeal, som ser ud til at kunne udgøre en central proxy. WebSeal bygger påfirewall-teknologi.Proxy’en kan med SPD slå op i Policy Director (et andet produkt i SPDporteføljen)og validere adgang til web-ressourcer, både på serverniveau, menogså adgang til enkelte dokumenter og søgefunktioner. Policy Director kan ogsåkonfigureres til at tillade anonym adgang til visse ressourcer i baggrundsserverne(dvs. uden login). Policy Director kan for hver baggrundsservice afbilde brugernavnpå proxy’en (dvs. brugerens login-navn) til nyt brugernavn hos baggrundsserveren(fx brugernavn=’SB-kat4’).Beskrivelser af ISOS og IBM-systemet er vedlagt som bilag.4.8 DelkonklusionerI dette afsnit drager vi på basis af diskussionerne tidligere i kapitlet nogle delkonklusioner,som er med til at begrunde den systemmodel, som vi foreslår i næstekapitel, og afslutningsvis tabulerer vi nogle nøgleegenskaber ved de beskrevnekørende systemer.4.8.1 CookiesCookie-løsningen er interessant, fordi den kan flytte et sign-on fra en server til enanden, og fordi den kan gøre det uden brugerindgreb og uden, at det opdages.Vi mener også, at cookie-løsningen kan implementeres, men det er svært at se,hvordan det kan lade sig gøre uden at involvere en eller anden form for proxyteknik.Vores konklusion vedr. cookies er derfor:• Der stilles for store krav til servernes dns-navngivning.• Vi kan næppe overbevise de brugere, som nægter at acceptere cookies.Cookies afskaffer ikke behovet for proxies som man kunne have håbet.4.8.2 CertifikaterCertifikater har mange fordele over for cookies:• De kan problemfrit benyttes på tværs af servere.• De er knyttet til SSL, som praktisk talt alle webservere understøtter.• På den enkelte webserver kan man sandsynligvis styre adgangen til ressourcerbaseret på elementer fra certifikatet.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 25• De er godt støttet af moderne browsere, der let kan bringes til at arbejde medcertifikater.Men desværre er ulemperne signifikante:• Certifikater kræver, at brugeren ved, hvad der foregår, og kender til de sikkerhedsaspekter,der indgår.• Midlertidige certifikater kræver ligeså meget af brugeren som permanente.• Midlertidige certifikater er ikke nær så transparente, som man kunne ønskesig.Certifikatløsningen er sandsynligvis fremtidens løsning, når der bliver etableret eninfrastruktur med permanente certifikater samt en mulighed for at bære dem rundt.Samtidig er sikkerheden større end ved brugernavn/password, fordi den bygger pånoget man har (certifikatet, fx på et chipkort) og noget man ved (fx password ellerpin-kode).4.8.3 Proxy-løsningenVi står tilbage med proxy-løsningen som kerneelementet i den mest realistiskeløsning. Fordelene ved denne løsning er:• Proxy-løsningen ser ud til, at den rent faktisk kan realisere en Single Sign-on,idet browserne kun ser en server.• Der er tale om kendt teknologi, der findes i en række systemer – fx nogle afde ovenfor beskrevne systemer og fra firewalls.• En proxy-løsning kombineret med en AAA-funktion (se kapitel 5 nedenfor)giver gode muligheder for at komme i gang hurtigt uden at gribe nævneværdigtind i de deltagende servere.Der er dog også nogle svagheder:• Proxy’en kan blive en flaskehals, men det kan i givet fald afhjælpes ved atreplikere den.• Erfaringen viser, at det ikke er nogen simpel sag at skrive en generel proxy afdenne type. Ofte vil man derfor ved egenudvikling skrive den specifikt opmod de bagvedliggende systemer, og det vil derfor kræve vedligehold og tilpasning,hvis et af de bagvedliggende systemer ændres.4.8.4 Sammenligning af eksisterende systemerHer er en meget skematisk sammenligning af de færdige systemer. Formålet meddenne opstilling er ikke umiddelbart at udgøre et beslutningsgrundlag for at foretrækkeden ene frem for den anden, men at fremhæve nogle nøglepunkter, somhører med i en endelig vurdering.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

4 Mulige løsningskomponenter 26Produkt SkoDa ISOS IBM PolicyDirectorTelnet-adgang Ja Ja JaWeb-adgang Ja Ja JaSingle Account Nej Ja JaSingle Sign-on Ja Nej 4 Ja4.8.5 OpsamlingSom konklusion på dette kapitel kommer vi frem til, at for at realisere DEFnøgleninden for en kort tidshorisont, må vi konstruere et system, der baserer sigpå proxy-modellen, hvor proxy’en er et filter for al kommunikationen mellembrugeren og de bagvedliggende systemer. I næste kapitel skitseres nogle alternativemuligheder for at realisere en sådan løsning. Proxy-modellen vælges primært,fordi den indtil videre ser ud til at være den eneste løsning, som giver en egentligSingle Sign-on-funktionalitet. Om muligt bør den konkrete løsning/produktvalgforetages, således at det vil tillade en eventuel fremtidig overgang til anvendelseaf digitale certifikater.Vi kan også konstatere, at ved realiseringen af en sådan løsning er der mulighedfor egenudvikling af nogle eller alle komponenter i en sådan løsning, men der erogså produkter på markedet, som kan implementere store dele af kravene til DEFnøglen.4 Ikke uden speciel proxy som leverandøren hævder er i produktion ved et universitet i Sydney,men som de ikke er vendt tilbage med referencer på.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 275 SystemmodelI dette afsnit beskriver vi den overordnede model for det system, som vi forudseranvendt til at realisere DEF-nøglen. Baseret på beskrivelserne og konklusionerne ikapitel 4 beskriver vi her en løsningsmodel, som tager udgangspunkt i proxyteknikken.Efter en indledende beskrivelse af kernen af denne løsningstype beskriver vi tokonkrete løsningsmodeller, som begge bygger på proxy-løsningen, og afslutningsvisforetager vi så en sammenligning af disse to modeller.5.1 DEF-nøglen i en proxy-løsningVi foreslår at realisere Single Sign-on-komponenten i DEF-nøglen ved at anvendeen stram proxy-løsning, hvor al kommunikation mellem brugeren og DEFservernegår gennem en aktiv proxy som tidligere beskrevet. Herved opnår vi atkunne realisere Single Sign-on vha. Basic Authentication, idet det for brugeren serud, som om al kommunikation foregår med proxy’en.Dette er et bærende element i begge de nedenfor skitserede systemmodeller, selvom de adskiller sig ved om alle brugere anvender den samme proxy.DEF-nøglen realiseres ved, at brugeren 5 logger ind hos proxy’en ved at oplyse sitbrugernavn/lånernummer og kodeord. I den decentrale model er brugerens bibliotekgivet ved den anvendte proxy, medens brugeren i den centrale model oplyseren sammenskrivning af biblioteksidentifikation og brugernavn/lånernummer. Ibegge modeller kender proxy’en derfor brugerens bibliotekstilhørsforhold og lokalebrugernavn/lånernummer og disse oplysninger kombineret med DEF-kategoriudgør så DEF-nøglen, som anvendes i kommunikationen mellem proxy’en og debagvedliggende indholdsleverende servere. I denne løsning er der heller et tekniskkrav til, at bibliotekerne samkører/ensretter deres brugerdatabaser før de kan deltagei DEF, idet brugeridentifikationen udgøres af kombinationen af bibliotek oglokal låneridentifikation.5 Når vi her snakker om en bruger, tænker vi på en person, som er registreret som låner hos etbestemt bibliotek. Når vi i det følgende anvender begrebet ”bibliotekets brugere”, mener vi heltkonkret de brugere, som er registreret hos pågældende bibliotek, uafhængigt af, om dette bibliotekemnemæssigt eller organisatorisk har et tæt eller løst tilhørsforhold til brugeren. Hvis en person erregistreret som brugere/låner hos flere biblioteker, optræder vedkommende i forhold til nærværenderapport som flere brugere, hvor systemerne omkring DEF-nøglen ikke nødvendigvis ved, at densamme person står bag flere forskellige brugerregistreringer.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 285.2 Den decentraliserede modelPå et af møderne i DEF-nøglegruppen blev følgende mulige systemmodel fremlagt:Bibliotek A, brugerensProxy medautentificering:NettetBibliotek B’s servicesModellen er tegnet assymetrisk i figuren herover, men i praksis vil der findes sådanneAuthentification-proxy’er for hvert bibliotek, hvis brugere skal have ad-InformationsserveremedautoriseringBrugerarbejdspladser:I denne model er der en proxy-server på hvert bibliotek, som anvendes af samtligebibliotekets egne brugere. Brugerne anvender DEF gennem deres eget biblioteksproxy, også selv om de er placeret uden for bibliotekets eget område, uanset omde befinder sig på bibliotekets (eller moderinstitutionens) net, hos et andet bibliotekeller ude i det generelle Internet (illustreret ved de 3 arbejdsstationer i skemaet).Denne proxy varetager Authentication-funktionen for bibliotekets brugere, ogdermed behøver den kun at kende bibliotekets egne brugere og afhængigt af detkonkrete softwarevalg og konfigurering kan autentificering evt. foretages ved etdirekte opslag i bibliotekssystemets lånerdatabase.Når brugerne ønsker at anvende nettjenester hos et andet bibliotek (Bibliotek B ifiguren), henvender de sig vha. deres browser til deres eget biblioteks proxy, derlaver gennemstilling til B’s servere med de konverteringer af URL’er og brugernavne,som tidligere er skitseret som proxy’ens opgaver.Det er nu de enkelte tjenestebærende servere hos B, der modtager opkald via A’sproxy, som skal udføre Authorization-funktionen, dvs. kontrollere, at den af A’sproxy autentificerede brugere har adgang til at anvende de ønskede ressourcer. Bkan eventuelt centralisere denne kontrol ved at sætte endnu en proxy foran sineservere. I denne model er det altså de servere (eller biblioteker), som har ressourcerne,der selv autoriserer brugernes adgang hertil.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 29gang til DEF, og hver af disse proxy’er skal kende de tjenesteudbydere, hvis services,de skal stille igennem til. De fleste biblioteker vil altså optræde både i rollensom A og som B på figuren over for hinanden. Endvidere kan modellen anvendesfor tjenesteudbydere ud over bibliotekerne, der så kun vil optræde i B-rollen på figuren. I DEF-sammenhæng kan vi forvente, at de tolv store forskningsbibliotekeretablerer aftaler og forbindelser med hinanden, således at de allekan optræde i A- og i B-rollen over for de øvrige.Mindre biblioteker, som ikke etablerer sig med egen proxy, kan tilsluttes dennemodel, hvis der etableres en autentificerings-proxy til at identificere deres brugereog stille igennem til de servere, som brugerne har behov for at anvende. En sådanautentificerings-proxy kan placeres hos et af de øvrige biblioteker eller hos en 3.parts tjenesteudbyder.Motivationen for denne model er, at kommunikation mellem ét DEF-biblioteksbrugere og tjenester hos et andet bibliotek vil være mulig, blot de to bibliotekersservere og net samt forbindelsen fra brugeren via hjemmebiblioteket til serverbiblioteketer funktionelle. Endvidere kan to biblioteker etablere de fornødne aftalerog infrastruktur uafhængigt af de øvrige biblioteker.5.3 Den centrale modelDenne model beskrives ud fra følgende figur:BrugerarbejdspladserneEt centraltsted i nettetService hos bibliotek AProxy:Service hos bibliotek BAAA-server:Adm. vedl.På et centralt sted i nettet placeres en fælles proxy, der anvendes af samtlige DEFbrugere(evt. pånær brugere, der lokalt kører mod eget bibliotek). Desuden placeresden samlede Authentication- og Authorization-service netværksmæssigt tæt pådenne proxy. Om disse placeres på 1 eller flere servere er mindre betydende, detvigtige er, at de optræder som en samlet service over for omverdenen. En place-¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 30ring tæt på det trafikmæssige centrum i det danske Internet (især DEF-nettet, dvs.Forskningsnettet) er at foretrække. Hvis trafikbelastning eller andre behov engangnødvendiggør det, kan den samlede proxy og AAA-tjeneste evt. replikeres på andrelokationer.Pilene i figuren antyder kommunikationsvejene, der i hovedtræk er:• Brugerne ønsker at anvende en DEF-tjeneste og henvender sig til en URL fordenne tjeneste på proxy’en.• Proxy’en validerer brugerens login-oplysninger ved at slå op i Authentication-tjenestenpå AAA-serveren.• Proxy’en autoriserer den autentificerede brugers adgang til den ønskede tjenesteved at slå op i Authorization-serveren.• Hvis adgangen autoriseres, sender proxy’en forespørgslen videre til denegentlige dataserver, modtager svaret og returnerer det tilbage til den oprindeligebruger under udførelse af de omskrivninger, som proxy’en nu skal gørefor at gennemføre sin proxy-funktion.• Hvis adgangen til en tjeneste ikke autoriseres fuldstændigt af Authorizationservicen,kan den server, som udbyder tjenesten, selv autorisere adgangen,evt. ved opslag i Authorization-tjenesten som skitseret for B-serveren i figuren.Det vil bl.a. afhænge af kompleksitet af anvendelsesaftalerne mellembibliotekerne og af servernes behov om yderligere oplysninger om den enkeltebruger, hvorvidt nogle servere selv har behov for at autorisere adgangentil deres ressourcer, eller om det overkommeligt kan beskrives i AAAtjenesten.Ud over de løbende kommunikationer foranlediget af brugernes aktiviteter pånettet, vil AAA-serveren også have behov for at opdatere de databaser, som regulererAuthentication og Authorization. Dette kan ske ved, at AAA-serveren forespørgerhos de deltagende bibliotekers systemer, om der er opdateringer af de administrativedata, eller bibliotekernes administrative systemer kan selv tage initiativtil at overføre ændrede data til AAA-serveren.Det fundamentale princip i denne model er, at den software, som implementererAuthentication og Authorization samt proxy-funktionen kun skal installeres étsted for at være tilgængeligt for alle brugere og alle tjenester. Der er stadig behovfor at lave løsninger, som tilpasses de enkelte bibliotekers behov for at overføre deadministrative data, og for de services, som selv har behov for at slå op i AAAservicen,skal applikationerne på disse servere have AAA-opslagsmodulet integreret.Ved at have en AAA-tjeneste, letter vi migreringen, idet¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 31• Den skal læse brugerdata fra de forskellige bibliotekssystemer, dvs. 4-5 systemer.• Baggrundsserverne skal kun implementere én protokol til at slå op i AAAtjenesten,i stedet for at kunne risikere at henvende sig til 12 bibliotekers forskelligesystemer. Selv om vi dikterer LDAP, skal vi stadig afvente, at hvertbibliotek implementer LDAP og den fælles directory-struktur, før de kan slåop hos hinanden.En baggrundsserver med en eksisterende brugerbase kan fortsætte med at køresom selvstændig server, men også samtidigt indgå i den nye løsning, blot ved attilføje nye brugernavne, som afspejler DEF-kategorierne hos de enkelte biblioteker.Dette er meget vigtigt for en hurtig igangsættelse af projektet.5.4 Sammenligning af de to modellerVi vil her opstille nogle sammenligningspunkter mellem den decentrale og dencentrale model for DEF-nøglen.Decentrale modelCentrale modelFælles udvikling af proxy ogAAA-funktionerFælles drift af proxy ogAAA-funktionerModifikationer af tjenestebærendeservereURL’er på netressourcerens for alle brugereAAA kører integreret iOPAC-systemerneAutentificerings- og autorisationsdelenaf AAAtjenestensamletStøttes af kommerciellesystemerMulig, ikke krævetNejJaNej, kun inden for sammeproxyMåske, afhænger af lokaleforholdNejFor en del af de enkeltekomponenters vedkommende,men integrationen foretageslokaltJaJaMåske nogle, næppe alleJaNejJaJa, AAA-tjenesten kan købeshos flere leverandører,evt. integreret med proxyfunktionen.Vedligeholdelsenaf administrative dataskal formentlig tilpasses afDEF og/eller de enkeltebiblioteker. Leverandøreneller bibliotekerne kan havebehov for at udvikle/tilpasseAAA-moduler, der anvendesi lokale servere¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 32Tillader egenudviklingTillader løbende ibrugtagenEn samlet driftsorganisationmed ansvaret for drift ogtilgængelighed af proxy ogAAA-serviceMulighed for bilaterale aftalerom autorisationJa, mange enkeltmodulerskal udvikles eller tilpasseslokalt. Evt. kan et grundlagudvikles fælles og tilpassestil de lokale systemerJa, når et bibliotek har sinegen proxy klar, kan derlaves aftaler og forbindelsertil hvert bibliotek, hvis serviceser klar hertilNej, hvert bibliotek står fordriften af egen proxy ogegne servereJaJaFørst skal den centrale proxyog AAA-service etableres.Herefter kan de enkeltebiblioteker tilkoble deresbrugere og/eller servicesJa, men de egentlige serveredrives stadig lokalt hosdet enkelte bibliotekJaSom det ses, kan begge modeller tilsyneladende realisere DEF-nøglen, men de harforskellige egenskaber, både teknisk og administrativt. Følgende punkter er ogsåmed til at karakterisere modellerne men passer ikke ind i skemaet herover.I den centrale løsning køres hele AAA-tjenesten på én platform (evt. klonet afperformancemæssige årsager). I den decentrale løsning kan man vælge at implementerede autentificerende proxy’er baseret på samme software- og hardwaregrundlag,men dette er ikke en forudsætning. Tilsvarende kan man vælge et fællesgrundlag for autorisationstjenesten.Den decentrale løsning kan påbegynde sin drift, når blot to biblioteker har deresaftaler og tilhørende systemer på plads, medens den centrale løsning forudsætter,at de centrale komponenter etableres fra starten.Uanset om modellerne baseres på indkøbte eller egenudviklede systemer, vil detalt andet lige være lettere at vurdere og følge op på omkostninger og tidsplanerved den centrale løsning, idet der indgår færre softwarekomponenter. Ved opgraderingaf systemerne er det også mere overskueligt at skulle opgradere ét samletsystem end at skulle opgradere et system, der kører hos 12 eller flere driftsorganisationer,og som måske bygger på forskellige hardware- og softwareplatforme.Hvis der satses på egenudvikling, vil især den decentrale model tillade en megetdetaljeret tilpasning til bibliotekets egne systemer, men så vil det til gengæld kunneblive sværere for bibliotekerne at opgradere til nye krav til DEF-nøglen, sommuligvis kræver nye versioner af dele af softwaren.Hvis der satses på at købe et samlet system, vil det kunne lade sig gøre både forden centrale og for den decentrale model, men vi forventer, at der skal laves større¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

5 Systemmodel 33tilpasninger og integrationsprojekter for at realisere den decentrale end den centraleløsning.Ved at basere sig på et kommercielt tilbud, er der større chance for, at leverandørervil videreudvikle systemet til at imødekomme fremtidens behov med et centraltsystem, medens egenudvikling formentlig betyder, at der er behov for, atDEF og/eller de enkelte biblioteker løbende har udviklingsaktiviteter i gang mht.DEF-nøglen, også efter at systemet er sat i drift.Teknisk set kan den decentrale løsning implementeres med samme sikkerhedsniveausom den centrale, men i praksis kan man ved en decentral drift risikere, at enbrist i AAA-tjenesten på et bibliotek (i tjenesten selv eller i det underliggendeoperativsystem) får sikkerhedsmæssige konsekvenser for brugere eller tjenesterfra andre biblioteker. En brist i en central AAA-tjeneste vil nok få større konsekvenser,men her forventer vi, at der skal være en driftsorganisation, som hurtigtvil kunne tage hånd om sådanne problemer.Endelig kan vi bemærke, at der også kan tænkes mellemløsninger, fx en løsning,hvor autentificeringen foretages af decentrale autentificerings-servere som i dendecentrale model, men hvor autorisationen foretages centralt som i den centralemodel.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

6 Opsamling 346 OpsamlingVi har i denne rapport opridset nogle centrale begreber i forbindelse med DEFnøglen:• Single Sign-on.• Autentification, Authorisation, AAA.• Proxy.• Central/decentral kontrol.I dette kapitel forsøger vi at opsamle de væsentlige konklusioner, både med hensyntil systemløsningen og til økonomien.6.1 HovedkonklusionerVi har i kapitel 5 skitseret et grundlag og to systemmodeller for at etablere DEFnøglen.På basis af disse modeller opstiller vi her nogle hovedkonklusioner:• Single Sign-on realiseres baseret på proxy-funktion.• Ud fra et teknisk synspunkt mener vi, at både den centrale og den decentralemodel kan realisere DEF-nøglen.• I valget mellem den centrale og den decentrale model lægger vi især vægt på,at systemet organiseres på en sådan måde, at det fungerer som et sammenhængendehele i forhold til AAA-funktionerne, også selvom bibliotekerne ikkekan opdatere software samtidigt og at de måske ikke alle vil have sammeressourcer og motivation til at vedligeholde AAA-politikkerne stramt og konsistentmed hinanden. Hvis DEF-tjenesterne ud over at bygge på bilateraleaftaler bibliotekerne imellem også kommer til af omfatte nationale aftaler,f.eks. nationale licenser, der på tværs af bibliotekerne giver alle brugere af engiven klassifikation adgang til bestemte dokumenter eller tjenester, vil detogså være vigtigt af have et centralt element i autorisationssystemet, såledesat de nationale licenser og adgangspolitikker kan defineres og kontrolleres.• En løsning baseret på et kommercielt produkt ser ud til give det mest overskueligeomkostningsniveau for etableringen af DEF-nøglen. Her tænker vibåde på direkte omkostninger og på den fornødne mandtidsinvestering, bådetil implementering, idriftsættelse og løbende vedligeholdelse.• Vi foretrækker den centrale løsning med en samlet autentificerings- og autorisationstjenestefremfor den decentrale, fordi vi mener, at det er lettere atvedligeholde og administrere. Vi peger også på denne løsning, fordi den kan¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

6 Opsamling 35realiseres i meget høj grad baseret på eksisterende produkter, her eksemplificeretmed fx IBM SecureWay Policy Director, men flere produkter vil formentligkunne løse opgaven.• Også den decentrale model vil være mulig, men her forventer vi en størreegenindsats enten ved implementering af systemets komponenter eller vedintegration af komponenter fra flere leverandører, der dog evt. modsvares afmindre direkte omkostninger til anskaffelser. Forudsætningen for, at vi kananbefale denne model er, at der laves en fælles kravspecifikation og evt. vælgesen fælles systemplatform for AAA-tjenesterne for at sikre interoperationog fremme muligheden for anvendelse af fælles softwarekomponenter.• En glidende overgang fra enkeltstående systemer til systemer, der indgår i etintegreret hele, ser ud til at være mulig for begge modeller.6.2 OmkostningerDen foreslåede model kan som skitseret implementeres på mindst 3 måder:1. man indkøber et færdigt system2. man køber en færdig policy manager, og egenudvikler eller tilpasser en proxy-løsning3. man bygger alle komponenter selvHvis vi starter med at se på de kommercielle systemer, må vi konstatere, at bådeISOS og IBM-systemet har listepriser, der er meget høje (og IBM endog væsentligdyrere end ISOS). Meget tyder dog på, at der kan forhandles bedre priser.Hvor meget det kommercielle system kan forhandles ned i pris kan af gode grundeikke estimeres. Vi kan her blot konstatere, at erfaring viser, at begge de to nævnteforhandlere er meget interesseret i at få erfaringer og derfor er meget villige til atindgå eksempelvis i udviklingssamarbejde. Uden nogen form for garanti vil viestimere, at systemerne kan anskaffes for et sted mellem ½ og 1 mio. kr. Hertilskal lægges den nødvendige lokale udvikling. Selv om et færdigt IBM systemanskaffes, vil det være nødvendigt at udvikle de nødvendige rutiner, som muliggøren automatisk opdatering af den centrale policy manager baseret på de deltagendebibliotekers databaser. Et estimat af den nødvendige indsats er ½-1 mandmånedpr. deltagende bibliotek til at implementere interfacet til autentificeringssystemetog en lignende indsats til autorisationssystemet.Typisk er vedligeholdelsesudgifter 20% af anskaffelsesprisen, dvs. ca. 100-200.000 kr. pr. år. Hertil kommer udgiften på hvert af de deltagende biblioteker.Et groft estimat er, at det kræver 0,1 mandår pr. år. Omkostningen afhænger naturligvisaf, hvor mange uafhængige services, som tilbydes DEF. Indsatsen kanderfor nemt blive højere.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

6 Opsamling 36Vælger man egenudvikling, vil vi ikke forvente, at den samlede udviklingsudgiftvil være billigere, snarere tværtimod. Det skal her nævnes, at en række universiteteri USA har lavet en beregning over at etablere et certifikatbaseret fællesauthentication system 6 . Forprojektet havde et budget på $250.000.Vælger man egenudvikling, skal man gøre sig visse ting klart:Udviklingsstrategi – her tænkes specielt på valget af løsningsmodel central, decentral,hybrid (decentral authentication, central authorisation). Her vil ikke bliveargumenteret for løsningsmodel ud fra tekniske kriterier men ud fra organisatoriskeog vedligeholdelsesmæssige kriterier.Central:Vælges den centrale model, kræves en central organisation, som kan drive ogvedligeholde systemet. Herudover kræves, at den nødvendige ekspertise er til stedepå bibliotekerne til at udvikle det nødvendige software til at "fodre" det centralesystem.Et skøn er, at det kræver ½ mandår centralt og 0,1 mandår på hvert deltagendebibliotek at vedligeholde systemet. Indsatsen på de deltagende biblioteker er densamme som i "købe"modellen.Vælges den centrale løsning, kræves ingen basal koordinering mellem biblitekerne.Det vil dog stadig være nødvendigt med en form for koordinering af, hvordanekstra oplysninger (eksempelvis addresser) kan opnås på de enkelte biblioteker.Decentral:Vælges den decentrale løsning, kræves en central organisatorisk enhed, som varetagerkoordineringen af de forskellige systemer. Hvert af de deltagende bibliotekerpåtager sig et større ansvar for, at helheden fungerer.Vælges denne model skal man regne med 1/4 mandår pr. deltagende biblioteksamt et lignende beløb til den centrale administration.Hybrid:Ud fra et organisatorisk synpunkt virker hybridløsningen mest attraktiv. Her stårhvert bibliotek for at vedligeholde deres egen proxy, hvorimod authorisation politikkernevedligeholdes centralt. Det er disse politikker, som er den primære rollehos den centrale administrative instans under den decentrale model. Det virkerderfor naturligt, at disse også implementeres centralt. De hænger naturligvis tætsammen med de kategorier, som defineres i forbindelse med authentication i pro-6 Se fx Inter-CIC Authentication and Authorization Pilot (ICAAP) Final Report på http://wwwsnap.it-services.nwu.edu/CICRPG/ICAAP_FR.htmog Business Plan Local Authentication withX.509 Certificates Project (LAXCP) på http://www-snap.itservices.nwu.edu/CICRPG/Bus%20Plan%20LAXCP.htm.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

6 Opsamling 37xy'en - hvorfor denne model også kræver en del administrativ koordinering af dedeltagende biblioteker.Denne model kræver, at de deltagende biblioteker opbygger og vedligeholder dennødvendige proxy med authentication som en integreret del af deres bibliotekssystem.Et overslag over vedligeholdelsesudgifterne i denne løsning er ca. 0,4 mandår tilden centrale instans og ca. 0,2 mandår pr. deltagende bibliotek.Det skal understreges, at ovenstående er meget grove overslag. Ganges tallenemed antal deltagende biblioteker, og lægges det hele sammen, er der en tendenstil, at den centrale løsning er billigere i årlig vedligeholdelse. Dette forventes atvære tilfældet, idet processen er simplere. Sker en opdatering/ændring på et bibliotek,vil det i den centrale model kræve ændring et sted, hvorimod det, afhængigaf karakteren, kræver ændring i et (hvis det er relateret til lånerdatabasen) elleralle (hvis det er kategorierne) andre systemer.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

7 Bilag 387 BilagHer følger 3 bilag:En produktbeskrivelse for ISOS.En produktbeskrivelse for IBM Secureway Policy Director.En supplerende tegning, der har været præsenteret på et møde med DEFnøglegruppensom illustration af den decentrale proxymodel.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©

PIRAEUSISOS – product overviewISOSThe unique tool set to provide solutions to major challenges in themanagement and control of authenticated access to global informationsources.07/01/99

ForewordThe global Information Society is approaching with bewildering speed. Electronictrading is creating a revolution in global business that is unprecedented. Theeconomic implications around the world are difficult to predict, but will be immenseand far reaching.Data, information, and knowledge are all now widely available across globalnetworks, within corporations, between corporations, and publicly accessible.Effective management and control of access to valuable information poses aformidable challenge, which is faced by every major corporation around the world.This global challenge can be met successfully and cost-effectively by the applicationof ISOS based solutions.With ISOS Piraeus has a world leading product in the area of managingauthenticated access to networked databases and information services The producthas been in operation in the UK for over four years in a very large scale, complexenvironment. It is also being piloted in a number of other sites outside the UK. Thereis a very high level of interest in ISOS around the world including the US. It is alsoclear that ISOS is positioned to become a major tool in the booming Internet baseddevelopments in Electronic Commerce1. IntroductionCurrent and relevant information ‘at the fingertips’ is a powerful business enabler.This has long been a vision, but with the advent of the all-pervasive Internet and themore controlled use of Intranets and Extranets the vision is rapidly becoming areality. But how do you control access to invaluable corporate data both within yourorganisation and when sharing with business partners – customers, clients, suppliers,- who may also be competitors in other markets?The rapid and continuing drive into electronic trading and e-commerce has ledbusiness to adopt piecemeal solutions to access control, or worse to ignore theproblem and take risks. This has lead to individuals in organisations at all levels ofseniority to need multiple and different keys (passwords and individual identifiers) inorder to access disparate sets of information.There is a solution that removes this complexity and leaves the individual with justone single name and password to sign on to all corporate systems to which access ispermitted. The level of access to individual systems is also controlled according tothe profile (and thus the permissions to access) of the specific individual.Moreover this is done in a secure, flexible way, which is based on standardcommodity Information and Communications Technology (ICT) products, works withall the major system platforms, and which is scalable up to several million individualusers.This solution is ISOS.

2. Business Issues and SolutionsA number of large corporate organisations have been utilising the benefits of theInternet and Intranet technology for some time now. Many information sharinginitiatives have begun in individual departments, or in subsidiary companies or havebeen introduced as a consequence of mergers or take-overs. The net effect of this isthat effective information sharing across a large and probably global organisation canprove at best cumbersome and inefficient, with executives needing to remembermany different passwords and identifiers. ISOS provides an integrating mechanismwhich allows staff to access all permissible information sets, wherever in the worldthey are located, and to whatever level of detail to which they are entitled, with asingle user identifier and password.At the other end of the business scale the Small and Medium size Enterprises(SMEs) can gain enormous leverage and business benefit from intelligent use of theInternet and associated technologies. ISOS can provide the larger SME with theability to control access to its E-commerce web based catalogues and databasesaccording to the business profile of its customers or clients. ISOS can also assist withthe management of the E-commerce supply chain. For the smaller SME ISOS couldbe used to facilitate shared provision of E-commerce services eg in support of theDTI regional initiatives in the UKThe public sector often has information provision problems that are very similarlogistically to those of large corporate organisations. Again ISOS can play a majorrole in facilitating the controlled access to public information and services bymembers of the public and other organisations according to each users rights andprivileges. ISOS is already established and serving around 2 million users in the UKUniversity sector, and there is a very high level of interest from academia around theglobe. A number of National Libraries are already expressing specific and activeinterest in ISOS. Other sectors where there is already considerable interest andpotential include general libraries, police services, and health services. In the UK thegovernments initiatives with the Information Society; ‘government.direct’; digitalcities; University for Industry; the Government Secure Internet; and of course e-commerce all offer potential for ISOS applications.Data Service Providers (DSPs) also provide a market opportunity. Publishers ofprofessional and technical material responding to the challenge of convergence andproviding their products over the Internet, need a means of controlling access,monitoring usage and billing their customers. ISOS already provides access controland usage monitoring and the raw material for billing purposes. DSPs are alreadysigning up for ISOS and many more have registered their interest.Internet Service Providers also offer substantial opportunities for ISOS. A coordinatedservice for small DSPs is one possibility already being explored, but therewill be many others as the markets mature.2

3. Product OverviewThe ISOS software provides a flexible and scalable means of controlling accessacross an open or private communications network to multiple sources of informationby a wide range of individual users. The information resource may range from acomplete suite of self-contained databases down to individual pages on the Web.The information resources can also reside on a multiplicity of disparate host systems,but access by the individual user to all resources available to that user is by way of a“single sign-on”. Access can be provided at the individual level or users may begrouped together.When a user attempts to access an information source through ISOS a check isperformed against the master database cluster which holds the permissions to use.The user is prompted for a (single) user-name and password, and provided this isvalid the user is allowed access to the information as defined by the registeredpermissions.The registration and administration of access permissions for a given user, or groupof users can be devolved in the manner most appropriate to the organisation usingISOS. Once the user’s status has been established the relevant access permissionsare registered with the system and access control is automatically managed by thesystem. Whilst control is logically applied centrally, the master control database canbe dynamically replicated around the enterprise for both resilience and performance.ISOS is supported on a fully distributed architecture in which host systems, databaseservers, and workstations can be located anywhere on the network. Accessvalidations are passed between host systems and the master registration databasesusing Internet protocols, with the information encrypted for security. ISOS is notrestricted to text data, but can be extended to control access to the whole range ofmedia types including audio and video services.4. Product Details4.1 Architecture4.1.1 There are three components forming the ISOS system:- the master controldatabase; the access management system; and the resource specific agents. Theconfiguration of the components within the system can be extremely flexible, with theemphasis on reliability or performance or both. The components may exist on thesame system, or any element may exist on any number of separate systems,optionally using replication for resilience. Moreover there may be any number ofresource specific agents, which might exist on any number of separate systems.Communication between systems supporting components of ISOS use a TCP/IPbased network. This may be the Internet, a private network, or a combination of thetwo.4.1.2 The master control database holds the permissions and access rights for all theusers against a table of all the resources available across the network. This databasemay be replicated across a number of servers as appropriate to provide resilienceand improved performance. This element of the ISOS system is currentlyimplemented using SYBASE, which has good facilities for replication andperformance, but in future releases other SQL-compliant databases may besupported. For each user account the database holds the following information:- ~User-name and password; ~ Zero or more IP addresses from which the user-name isvalid; ~ Zero or more resources to which the user-name is allowed access; ~ Group3

identifier; ~ E-mail address; ~ Contact details; ~ Password expiry date; ~ Accountexpiry date; ~ User profile.4.1.3 The access management system is activated whenever a user wishes toaccess information resources. It receives requests from all the relevant resourceagents, and validates the users access rights. Each access to each resource fromeach user is validated individually against the database. In addition, all of theaccesses are logged, which provides a full security audit trail. The log can alsoprovide a history of accesses and this can provide valuable information on resourceusage and access patterns. This log can also provide the basis for charging foraccess to selected information. As with the master database the ‘central’ securitysystem may be replicated for resilience and scalability. Normally the replicas will existon separate distinct, distributed systems that communicate securely across the IPUsersAMS serverWWW client telnet WindowsISOSAMSserverRDBMSNetworkInformation(WWW) serverISOS AgentSecureAuthenticationUnprotectedDocumentsData-serviceProtectedbased network.4.1.4 The resource agents are specific to the resource or service that is beingprotected, and normally there is one agent on each host system that containsprotected resources. In this context a resource is loosely defined as a collection ofone or more documents and identified in an Access Control List (ACL). On a hostsystem that contains a number of resources, each resource is individually identifiedby name. Documents can be allocated to one or more resources, and once allocatedto a resource are protected by the ISOS system. Documents not allocated to aresource are not protected and can be accessed by anyone. The agent intercepts arequest for access to a resource and the access is referred to the central securitysystem for authorisation. Based on the response the user is either allowed access orprompted for a valid user-name and password that will allow access. The agenttechnology can be integrated into the “front end” of an existing system relativelyeasily using either a ‘C’ or ‘C++’ language API. This allows ISOS technology to beused to protect existing resources with little or no impact on the user interface. Theinterface to the central system is via a web server agent or an API, which againallows for easy expansion and enhancement to other technologies.4

4.2 SecurityClearly, the ISOS system will be nothing if it is not secure. There are a number ofmeasures included in the system to increase security, which include:1. Each username, in addition to the password, can have a list of IP addresses fromwhich it is valid. This means that some or all of the users of the system can befixed to a particular PC to access ISOS-protected resources. In this way, thepotential for a user to be impersonated is greatly reduced. However, for greaterflexibility, if the list of IP addresses is zero length, then the user is not restricted toany IP address.2. A username with access to the site administration pages must be restricted toone and only one IP address.3. All passwords used in the system will have an expiry date and time. Once apassword has expired, only an administrator with control over the account canreset the password.4. Each username will also have an expiry date and time, which could, but neednot, be the same as the password expiry date and time. Once a user account hasexpired, it cannot be used, and a new account must be created. A user will beautomatically notified by e-mail before the account expires.5. All communication across a network between components of the ISOS system isencrypted.6. All administration changes across a network use the Secure Sockets Layer(SSL).4.3 Resilience and ScalabilityTo provide resilience and scalability, both the central security system and thedatabase on which it relies can be replicated. This means there can be multiplereplicas of all ISOS components on distinct, distributed systems, which communicatewith each other across an IP-based network.4.4 User Administration - RegistrationUser Registration facilities are provided through Web forms that link back to thecentral database, in other words, another protected resource similar to any other Webpage. The communication with the central database takes place over a secure linkusing the Secure Sockets Layer (SSL).Each organisation has its one or more administrators who are given access to theUser Registration Forms. When registering users the administrators allocate accessrights, which of course could also allow access to the User Registration Form. In thisway, multiple levels of user registration and administration can be accommodated.Resource access rights may be delegated or denied to lower level users. Becauseaccess rights may be inherited, access control is entirely configurable by higher leveladministrators.User accounts can be administered by more than one administrator, who can modifyaccount details, and the resources to which the user has access. An administratorwho can modify another administrator’s user account can also modify all useraccounts controlled by that administrator. This control extends right down through as5

many layers as there are in the hierarchy. However, an administrator cannot allocateaccess rights to a resource to which they do not have access themselves.Administrators are configured within the system as users, albeit users with access toprivileged resources. As such, they can access all the resources controlled by theISOS system, subject to having the correct permissions.In order to simplify administration, users can be allocated to groups. All users within agroup can be allocated the same basic rights using a template. Once set up, allchanges to the template affect all users in the group. Similarly, if a group is deleted,all the users in a group are deleted.6

4.5 User Administration – Usage StatisticsEvery access to every resource protected by ISOS is logged in the Usage LogDatabase. This Usage Log contains the username, resource name and time-stamp.The usage statistics are available in “real-time” using a Web page. Like the UserRegistration Forms described above, the Usage Statistics pages are a resourceprotected by ISOS. Access to these forms is normally allocated to site administrators.The hierarchy in place for user administration is in place for usage statistics. At eachlevel in the control structure an administrator can see the usage statistics for allcontrolled users. The usage statistics provide the basis for charging, at various levelsand rates, for the use of selected services.Future DirectionsISOS is already a well-established and robust product and has been providing a distinctand valuable service for over four years. However the product will continue to bedeveloped as the demands of the market grow. Early extensions under activeconsideration include:- the addition of strong authentication using tokens, and/or smartcards; integration with document management; extended Internet access control; and theintegration with other security systems by extending the ISOS database to containadditional user information.The flexible architecture of ISOS together with its scalability and portability makes anideal vehicle for a solution today with scope to grow with the market for years to come.7

Centralized security framework for your e-businessIBM SecureWay Policy DirectorHighlightsIBM ® SecureWay ® Policy Director includesthe following components:Provides access control toWeb objectsAdds centralized security toyour existing Web and TCP/IPapplicationsEnables replication and loadbalancingProvides a consistent, manageableaccess control policyOffers extensible authenticationand authorizationDelivers secure remote accessand personalized accessOffers one-time authenticationcapability with access to multipleWeb resourcesHelps reduce administrationcostsSupports public key infrastructure(PKI)Meets Year 2000 readinessrequirements 1• Policy Director WebSEAL ®• Policy Director AuthAPI • Policy Director CORBA Security• Policy Director NetSEAL • Policy Director management consolePolicy Authorization FrameworkPolicy DirectorWebSEALWeb securityPolicy DirectorAuth APIPolicy DirectorCORBASecurityPolicy DirectorNetSEALApplication VPNAuthentication Authentication AuthenticationThird-partyWeb serverCustomapplicationThird-partyORBTCP/IPapplicationBrowserwith SSLNetSEATNetSEATBack-endsystemsPolicy Director can streamline your security management and provide long-term cost reductions.

Make corporate resources available securely on the InternetPolicy Director supports defining andcoordinating security policy across:SecureWay Policy DirectorA good security system starts with awell-structured security policy. If you’vepurchased security software solutionsfrom multiple suppliers like most companiestoday, you end up bearing the cost oftrying to integrate these solutions toimplement the security policy you’vedeveloped. Often, they can’t beintegrated.Policy Director is the central control pointfor SecureWay FirstSecure, IBM’s singleintegrated solution for your e-businesssecurity needs. Policy Director is designedto unite core security technologies –intrusion detection, antivirus, hardenedboundary protection, including contentfiltering and a public key infrastructure(PKI) – around common security policies.This can reduce implementation time andmanagement complexity, thereby helpingto lower the total cost of secure computing.Centralizing your security policy enablesyou to easily update or modify it withouthaving to use various product-specificconfiguration consoles. At the PolicyDirector console, you can set policy thatestablishes user credentials and authorizesusers based on those credentials.This determines what kind of access theyhave to Web applications and resources.Users can be placed in groups, which canbe the basis for user authorization.Enterprise Web servers and the browsersthat access themPolicy Director provides support forauthentication of specific users through auser ID and password, Kerberos credentialsor client-side certificates. Accesscontrol can be set to specific URLs, filesor common gateway interface (CGI)programs on the Web server.New applications written to the PolicyDirector Authorization APIPolicy Director includes an authorizationAPI that allows an enterprise to efficientlysupport access control to Web objects,including HTML pages, graphics, CGIprograms, Java applications anddatabase queries.Client/server TCP/IP applicationsPolicy Director provides support forauthentication of specific users through auser ID and password and Kerberoscredentials. It establishes an applicationvirtual private network (VPN) between theclient and server to protect data transmissionover public networks.Policy Director includes the followingcomponents.WebSEALWebSEAL is independent of networktopology and location, meaning securitycredentials are based on who your useris, not where your user is. It allows you togive users access to only the sensitiveinformation they need. Your users willhave a single sign-on to all Web resources,including back-end servers andWeb-enabled applications. WebSEALmanages all your third-party Web servers,allowing you to centrally control all yourWeb resources as a single, logical Webspace and enabling servers to be movedwithout users having to relearn serveraddresses.By performing intelligent load balancingover replicated servers, WebSEAL letsyour organization scale its deployment ofservers without increasing managementoverhead. It also provides a fail-overcapability, enabling Policy Director toautomatically switch to a backup Webserver. WebSEAL is designed to work withthe Tivoli ® Global Sign-On product toextend the enterprise level single sign-onthat Global Sign-On offers.

AuthAPIAuthAPI allows you to build Policy Directorsecurity and authorization directly intoyour corporate applications, helpingreduce application development time andcost. By taking advantage of this, you canhave your network managed centrally byPolicy Director, which can significantlyreduce the total cost of ownership and thelikelihood of security breaches. AuthAPIgives you access to an applicationindependentsecurity and authorizationframework so you won’t need to writeauthorization code for each application.You can use the full power of the PolicyDirector authorization and securityservices directly in your applications.Using AuthAPI, you can customize yourusers’ network views to match their accessprivileges and create customized menusbased on authorization information.CORBA SecurityPolicy Director can add data integrity,privacy and authorization to existingCORBA installations. Using CORBASecurity 2 (which is planned to be availableas an enhancement in 1999), yourorganization should be able to managesecurity for its CORBA environmentthrough the same console used to secureand manage Web, TCP/IP and othernetwork resources. Through its support ofLevel 2 objects, Policy Director can bemore tightly integrated with CORBAapplications, allowing them to participatein authorization decisions. CORBAapplications can query Policy Director todetermine whether a user can perform arequested action or to obtain informationneeded to make a decision. The InpriseVisibroker object request broker (ORB)will be initially supported.NetSEALNetSEAL is the secure network solutionthat enables your organization toauthorize and secure traditional Internetservices, such as TN3270, Telnet and FTP,as well as third-party applications, suchas database systems, network managementtools and ORBs. NetSEAL alsoenables you to extend access to in-houseapplications with authorization. Securitycredentials are based on who – not where– your user is. NetSEAL can be centrallymanaged for the entire enterprise andconfigured to complement and extendyour existing firewall product.Management consoleManagement console is a graphicalJava application used to securelymanage the various Policy Directorcomponents. The console allows you toadd and delete users or groups and applyaccess controls using access control lists(ACLs) to objects.Policy Director and SecureWayBoundary Server workingtogetherSecureWay Boundary Server bringsbroad security solutions to help protectyour business assets. When you useSecureWay Boundary Server with PolicyDirector, SecureWay Boundary Servercan provide an extranet security frameworkto enable your company to connectto business partners, customers andremote employees over the Internet.Part of the total IBM integratedsecurity solutionPolicy Director is a component of IBMSecureWay FirstSecure, deliveringcomprehensive security solutions thatenable e-business.Policy Director is available separately oras part of SecureWay FirstSecure.For more informationTo find out more about IBM SecureWayPolicy Director, visit our Web site at:www.ibm.com/software/security/policy

SecureWay Policy Director at a glancePlatforms supported • IBM RISC System/6000 ®• Sun SPARC• Intel ® x86 or Pentium ®Operating systems• IBM AIX ® 4.3 or higher• Solaris 2.5.1• Microsoft ® Windows NT ® 4.0Client platforms • Windows ® 95 or Windows 98• Windows NT 4.0• X/MotifDisk spaceMemory• 50MB• 64MB© International Business Machines Corporation 1999IBM CorporationDepartment VK4A3039 Cornwallis RoadResearch Triangle Park, NC 27709Produced in the United States of America3-99All Rights ReservedAIX, the e-business logo, IBM, RISC System/6000 andSecureWay are trademarks of International BusinessMachines Corporation in the United States, othercountries or both.Tivoli is a trademark of Tivoli Systems Inc. in the UnitedStates, other countries or both.AuthAPI, NetSEAL, NetSEAT and WebSEAL aretrademarks of DASCOM, Inc.Intel and Pentium are trademarks of Intel Corporation inthe United States, other countries or both.Microsoft, Windows and Windows NT are trademarksof Microsoft Corporation in the United States, othercountries or both.Java and all Java-based trademarks and logos aretrademarks of Sun Microsystems, Inc. in the UnitedStates, other countries or both.Other company, product and service names may betrademarks or service marks of others.1Year 2000 ready means that the IBM product, whenused in accordance with IBM-associated documentation,is capable of correctly processing, providing and/or receiving the date data within and between thetwentieth and twenty-first centuries, provided that allproducts (for example, hardware, software andfirmware) used with the IBM product properlyexchange accurate date data with it.2All statements regarding IBM future direction or intentare subject to change or withdrawal without notice andrepresent goals and objectives only.Printed in the United States on recycled papercontaining 10% recovered post-consumer fiber.G325-3890-00

DEF Nøglen. Implementation med distribuerede proxy servereBibliotek AFællesDEFproxy oglånerdatabasefor mindre bibl.Låner DBProxyData service DBACDataServiceCenterData service DBProxyACLåner DBACProxyData service DBLåner DBBibliotek B¡ ¢ £ ¤ ¥ ¤ ¦ £ £ £ProxyDEF bruger, registreret ved et (eller flere)af DEFs biblioteker. Via DEF eller lokalportal ledes brugeren til bibliotekets proxy,der anmoder om brugernavn og password.Bibliotekets DEF proxy, der formidlerbrugerens validering ift lånerdatabasen ogdernæst formidler kommunikationen medde eksterne DEF data service udbydere,idet disse oplyses om biblioteks-ID, bruger-ID og bibliotekets eksterne brugerkatagori(en forenklende mapning af den internebrugerkategori og (spærrings)status ).Biblioteket garanterer for de brugere, detlader kommunikere via sin proxy server.For korrektheden af brugerkategorien iftindgåede aftaler og for betaling af evtyderligere transaktionsrelaterede udgifter.Låner DBACData serviceDBBibliotekets lånerdatabase, typisk en del afbibliotekssystemet. Heri vedligeholdes brugernavn,password,adresseoplysninger, internbrugerkategori og (spærrings)status og lignendebiblioteksparametre. Basen har et realtimeinterface til proxy serverens opslag.En udbudt DEF data service med tilhørendeadgangskontrol (AC). Ved digitale serviceskontrolleres blot kombinationen af biblioteks-ID og brugerkategori mod den lokale tabelover indgåede serviceaftaler med bibliotekerne.Ved papirbaserede services anvendes bruger-ID til identifikation i en indirekte fjernlånstransaktioneller til at hente yderligere låneroplysningervia DEF proxy opslag i lånerdatabasenmhp et direkte udlån til brugeren.