Scenarier for DEF Nøglens implementering - oplæg til prototype- og specifikationsarbejdet

Transkript

1 Scenarier for DEF Nøglens implementering - oplæg til prototype- og specifikationsarbejdet Danmarks Elektroniske Forskningsbibliotek DEF Nøglegruppen København, juli 2000

2 Oversigt Indholdsfortegnelse 1. Introduktion - baggrund og formål - landskab og definitioner 2. DEF-landskabet og -arkitekturen - forhold til de øvrige dele af DEF-infrastrukturen 3. Implementeringsmodeller - Web-proxy-modellen - Z-gate-modellen - Hybrid-modellen 4. Adgangsstyringsmodeller - Brugerkategori-modellen - Ressource-ID-modellen 5. Det digitale scenarie - adgang til digital information på nettet 6. Det trykte scenarie - adgang til trykt information via digitale metadata 7. Sammenhæng med bibliotekernes brugerdatar - krav til standardisering/harmonisering - krav til kvalitet og ajourføring 8. Opsummering - praktisk implementering DEF

3 1. Introduktion 1. Introduktion Forord Denne rapport tager udgangspunkt i følgende: DEF Hovedprojekter 1999: Projekt DEF Nøglen. IT12-note af DEF-Nøglen. Forslag til realisering af fælles brugervalidering til DEF-tjenester, UNI-C s rapport til DEF Nøglegruppen, August 1999 Teknisk resume af DEF-nøglerapporten, UNI-C, DEF Nøglegruppens indstilling af DEF Nøglegruppens undersøgelse af bibliotekernes brugerdatar De efterfølgende drøftelser på DEF Nøglegruppens møder Formål DEF-nøgleprojektets formål er at etablere en single sign-on løsning for alle DEF s brugere: der rer sig på bibliotekernes allerede eksisterende brugerdatar der er uafhængig af brugerens fysiske opholdssted (IP adresse) der kan anvendes ved alle DEF-tjenester, digitale som trykte der tilbyder en ægte single sign-on, hvor brugeren kun identificerer sig én gang i en netværkssession, selv om den omfatter flere servere, evt. fra flere institutioner I opfølgning af UNI-C s rapport og Nøglegruppens indstilling og efterfølgende drøftelser herom, forsøger denne rapport at konkretisere et sådant administrativt system: der benytter sig af login-ret autentificering af brugerne der er en distribueret løsning i overensstemmelse med DEF konceptet der knytter sig til og udnytter bibliotekernes brugerdatar der kan drives af enkeltbiblioteker såvel som af fællesoperatører, der driver systemet for flere (typisk mindre) biblioteker der tager hensyn til og udnytter den øvrige DEF infrastruktur, således som den har udviklet sig siden februar Hovedroller I et sådan system er der tale om to hovedroller: 1. Informationsudbyder En datavært, et digitalt bibliotek, et fysisk bibliotek med digital katalog, etc. 2. Adgangsformidler Et bibliotek med dets tilhørende brugere, et servicecenter for flere biblioteker (typisk mindre) med deres tilhørende brugere, en fritstående formidler af informationsadgang til erhvervslivet eller ethvert andet brugersegment, etc. Enhver partner kan i praksis vælge at spille den ene, den anden eller begge roller. Men, da rollerne spilles hver for sig, vil det være en hensigtsmæssig og forsvarlig forenkling at analysere scenarier, hvor partnerne spiller een rolle hver. DEF

4 1. Introduktion Hovedkomponenter Teknisk set foregår samspillet mellem de to logiske hovedkomponenter: 1. Adgangsformidlerens autentificeringsgate, hvorigennem alle brugere sendes videre til informationsudbyderne. Denne komponent autentificerer brugeren i forhold til informationsudbyderne ved at a) Checke brugerens login i forhold til egen brugerdata (typisk lånerdatan i et bibliotekssystem) og indhente de for DEF Nøglen nødvendige oplysninger b) Inddrage DEF Nøglen i brugerens kommunikation med udbyderne 2. Informationsudbyderens autorisationsgate. Udbyderens kommunikationspunkt i forhold til DEF landskabet. Denne komponent analyserer alle modtagne forespørgsler ved at se på: a) hvem der (netværksmæssigt) er afsenderen, dvs. hvilken DEF partner der formidler adgang b) hvilke rettigheder den medsendte DEF Nøgle giver brugeren, dvs. hvilke bagvedliggende services, der skal åbnes op for. Dette betyder at den kritiske datakommunikation mellem DEF landskabets organisationer netværksmæssigt er lagt i meget veldefinerede rammer. Der vil udelukkende være tale om, at et begrænset antal autentificeringsgates kommunikerer med et ligeledes begrænset antal autorisationsgates. Begge disse antal vil højst være lig med antallet af deltagende biblioteker og højst sandsynligt betydeligt mindre, jvf. bl.a. den regionale koncentration, der har fundet sted på bibliotekssystemområdet. Det kontrollerede landskab af indbyrdes registrerede gateways Autentificer. Autorisations Autentificer. Autorisations Autentificer. Autorisations Autentificer. Autorisations DEF

5 1. Introduktion Landskabet set fra en informationsudbyders synspunkt 3 adgangsformidlere Autentificer. 1 informationsudbyder Service Autentificer. Autorisations Service Trykte samlinger Service Autentificer. Informationsudbyderen kommunikerer teknisk gennem sin autorisationsgate med et overskueligt antal velkendte autentificeringsgates (i diagrammet er vist tre). Dette forenkler sikkerhedsproblematikken, da informationsudbyderen f.eks. kan sætte sin gate op til kun at ville snakke med disse (tre) maskiner på nettet. For udbyderen vil det ofte være væsentligt at kunne dokumentere en høj grad af sikkerhed overfor forlæggere og andre copyrightholdere. Den videre kommunikation med de talrige brugere og de administrative relationer til disse er overladt til (de tre) adgangsformidlere med deres autentificeringsgates og belaster således ikke informationsudbyderen, hvis administrative relationer begrænser sig til de adgangsformidlere, vedkommende har indgået aftale med. Denne model kan siges at være analog med bibliotekernes traditionelle fjernlån (inter-library loan) indkøb gennem indkøbsforeninger I forbindelse med ekspedition af lån eller fotokopi af trykt materiale kan autorisationsgaten endvidere sende forespørgsler til autentificeringsgaten, for at få fulde adresseoplysninger, hvis forsendelsen skal foregå direkte til brugeren. DEF

6 1. Introduktion Landskabet set fra en adgangsformidlers synspunkt 3 informationsudbydere Service Autorisations Service 1 adgangsformidler Service Service Autentificer. Autorisations Service Trykte samlinger Service Service Autorisations Service Trykte samlinger Service Brugere kommunikerer via deres adgangsformidlers autentificeringsgate med de informationsudbydere, som adgangsformidleren har tegnet aftale med. Disse aftaler kan enten åbne adgang til en service for alle adgangsformidlerens brugere uden forskel eller kun for visse grupper (kategorier) af brugere. I det første tilfælde behøver udbyderen blot at forvisse sig om at det er den rette autentificeringsgate, der kommunikeres med, i det andet må udbyderen i tillæg have mulighed for at vurdere den individuelle brugers rettigheder. Adgangsformidlerne vil i kraft af, at al kommunikation til eksterne udbydere går gennem deres autentificeringsgates, have gode muligheder for at lave statistik over, hvem der bruger hvad, hvornår og hvor længe, etc. En sådan statistik vil naturligvis være af stor betydning for formidlerne, der årligt eller oftere skal revidere de indkøbte adgangsarrangementer. DEF

7 2. DEF-landskabet 2. DEF-landskabet og -arkitekturen De to øvrige DEF infrastruktur-projekter, DEF Portal og DEF Katalog, dækker teknisk set over et antal Z39.50 servere med datar for henholdsvis portal-metadata og bibliotekskataloger m.v. samt et antal Web-Z39.50 gateways, der implementerer brugerservices i form af søge/browse-tjenester oven på disse dataservere. Herved dannes følgende landskab: Vejviser Web-Z Vejviser Fagportal Fagportal Web-Z Fag Portal Bibliogr databas Web-Z Fag Portal Katalog Katalog Web-Z Web-Z Bibl katalog Bibl katalog Bibl katalog Trykt saml. Trykt saml. Trykt saml. Brugere kommunikerer ved hjælp af deres web-browsere med et antal web-servere, der udbyder en række services (vejviser, fagportaler, katalog, osv.). Disse services rer sig alle på Z39.50-datar, der udbydes på web via Web-Z39.50 gateways. Herved bliver der grundlæggende tale om tre tekniske lag forbundet af to forskellige netværksprotokoller: Web browser HTTP Z39.50 Web-Z way Dette svarer til DEF Nøglens tre organisatoriske lag og roller: Brugere, Adgangsformidlere og Informationsudbydere. Spørgsmålet er så, hvorledes man bedst implementerer DEF Nøglen i dette landskab? DEF

8 3. Implementeringsmodeller 3. Implementeringsmodeller To modeller for implementering af DEF Nøgle funktionerne byder sig til den ene i to varianter: Web-proxy-modellen Z-gate-modellen Z-gate-plus-modellen (hybrid-modellen) De to modeller adskiller sig, som navnene antyder, ved grundlæggende at re sig på henholdsvis web-proxy-gateway-teknologi og web-z39.50-gateway-teknologi. I alle tilfælde gælder det, at implementationerne kan drives fuldt distribueret, hvor hver partner driver sin egen autentificerings- eller autorisationsfunktion, eller med et større eller mindre islæt af samdrift, f.eks. i form af en fællesoperatør, der driver autentificeringsfunktionen for en række biblioteker. Web-proxy-modellen Bibl. syst em Bruger DB Web browser HTTP Web proxy m/autentificering HTTP Web-Z way m/autorisation Z39.50 Sessions tabel Log Rettigheds tabel Log Denne model introducerer en web-proxy i HTTP kommunikationen. Denne proxy sørger dels for autentificering af brugerne og dels for omskrivning af alle modtagne web-sider. Proxyen kommunikerer på brugernes vegne med de forskellige Web-Z gateways, der varetager autorisationopgaven for de bagvedliggende Z-servere. Det er således nødvendigt at fastholde proxyen som mellemstation for brugerens kommunikation igennem hele brugerens session med en given web-server (Web-Z gateway). For at opnå dette skal proxyen læse alle de modtagne web-sider og omskrive alle links (URL er) til at pege tilbage på proxyen, og derefter sende de redigerede sider til brugeren. Dette kan f.eks. være en link af typen vis de næste 10 poster eller bestil fotokopi. (Web-proxy-modellen er mere udførligt beskrevet i UNI- C-rapportens afsnit 3.5, 4.3 og 5.) En af udfordringerne er at sikre, at brugerne ledes hen til den rette web-proxy. Hvis brugeren finder den eksterne service omtalt på adgangsformidlerens egne web-sider, er der intet problem. Den tilbudte link vil simpelthen pege på servicens proxyspejlbillede på adgangsformidlerens web-proxy. Hvis brugeren finder servicen omtalt i DEF

9 3. Implementeringsmodeller en DEF portal eller hos udbyderen selv, er det mindre enkelt at sikre den rette omdirigering. Hvis DEF portalen eller udbyderen tilbyder en liste med links til de adgangsformidlere, der har købt adgang til servicen, skal brugeren blot klikke det rette navn for at komme til sin egen adgangsformidlers web-proxy-spejlbillede af servicen. I sin egenskab af autentificeringsgate kommunikerer proxyen med de relevante bibliotekssystemer (eller snarere deres brugerdatar) for at validere brugernes login og indhente oplysninger til Nøglen. Ligeledes holdes der regnskab med de aktive sessioner, således at brugernes login kan have en vis gyldighed og ikke behøver at gentages inden for denne. Endvidere må man forvente, at trafikken gennem gaten logges, af hensyn til statistik, evt. kontrol af informationsudbyderes transaktionsbestemte opkrævninger og evt. fakturering af brugerne i henhold til forbrug. Tilsvarende logges der ved informationsudbyderens Web-Z gateway, der er tillagt autorisationopgaven og derfor rummer rettighedstabellen, der definerer de forskellige brugerkategoriers adgang til de forskellige services (datar), der udbydes. Denne model vil umiddelbart være mindre effektiv, hvis de fleste ressourcer fortsat ligger på Z39.50 servere, idet den introducerer en ekstra mellemstation i kommunikationen. Omvendt har den sin force i situationer, hvor kun et fåtal ressourcer ligger på Z-servere, og der ikke er noget behov for at samsøge de web-server rede ressourcer. Z-gate-modellen Bibl. syst em Bruger DB Web browser HTTP Web-Z way Z39.50 m/autentificering m/autorisation Sessions tabel Log Rettigheds tabel Log Denne model tilføjer autentificeringsopgaven til Web-Z39.50 gatewayen og autorisationsopgaven til Z39.50-serverne. Herved holdes antallet af stationer i netværkskommunikationen på samme niveau, hvilket alt andet lige er ensbetydende med en bedre præstation. Imidlertid er flere elektroniske tidsskrifts- og referencedatar ikke Z39.50 klar på nuværende tidspunkt og det er uafklaret om der kan skrives et Z39.50 interface til dem, ligesom der kan komme services til, som det vil være svært/umuligt at give et Z interface DEF

10 3. Implementeringsmodeller For søgetjenester med et struktureret web-brugerinterface er det muligt at etablere en Z39.50-gateway, der omsætter søgetjenestens web-brugerinterface til en Z service. Dette kan gøres ved direkte afkodning af web-brugerinterfacets skærmbilleder (kaldet screen scraping) eller på basis af bilaterale aftaler om URL-syntax og evt grafikfri, velstrukturerede HTML-sider med udviklerne af web-søgetjenesten (en form for pseudo-protokol i stil med DanWeb). Sådanne omsætninger af web-grænseflader til Z39.50 har den yderligere fordel, at de pågældende datar får samme brugergrænseflade som de direkte Z-rede og tilmed kan samsøges med disse. Autentificeringen er i denne model ligeledes ret på opslag i det af brugeren valgte biblioteks brugerdata, hvorved Web-Z wayen kan validere brugerens logindata (brugernavn/pasord) samt modtage oplysning om evt. spærring samt de øvrige nøgleoplysninger såsom kategori. Forholdene omkring sessionsregnskab og logning er ligeledes de samme som i Web-proxy-modellen. Koblingen af autentificeringen til Web-Z wayen er en stærk trend i en række danske og internationale projekter og systemer. Endvidere åbner modellen væsentlige muligheder for bibliotekssystemleverandørerne, der typisk allerede har integreret en Z39.50 klientfunktion i deres pakker, der naturligvis også inkluderer brugerdatar og login-rutiner, hvorved den nødvendige udviklingsindsats for fuldt at fungere i DEF Nøgle sammenhæng bliver mindre. Autorisationen afviger i sig selv ikke fra Web-proxy-modellen, men kan (på sigt) drage fordel af Z39.50 protokollens faciliteter for AAA (Authentification, Authorization & Accounting). Da Z-gate-modellen først sent er indgået i udvalgets diskussioner og derfor ikke er beskrevet i UNI-C s rapport, gives der nedenfor lidt yderligere detaljer. Man kan forestille sig at autentificeringsdialogen er ens for alle DEF partnere, dvs et skærmbillede af følgende principielle tilsnit: Velkommen til XUBs gateway til Danmarks Elektroniske Forskningsbibliotek Som anonym gæst hos XUB Din computers IP adresse vil afgøre hvad du får adgang til START Som registreret bruger Bibl/Univ Bruger Pasord Xkøbing Universit. START DEF

11 3. Implementeringsmodeller Dette vil sige, at brugeren efter valg af bibliotek og indtastning af brugernavn/pasord cleares i forhold til den respektive brugerdata og overføres til den respektive Web- Z gateway. Dette kan implementeres ved at de forskellige autentificeringsgateways kender hinanden og overfører indlognings forespørgsler til hinanden, når den af brugeren valgte adgangsformidler (bibliotek, universitet e.l.) ikke er tilknyttet den aktuelle gateway. Uni/Bib A Uni/Bib B Bruger DB Autentificering Autentificering Bruger DB Web-Z gateway Web-Z gateway En given autentificeringsgateway kan endvidere betjene flere adgangsformidlere, idet den kan slå op i flere brugerdatar og kan viderestille til flere forskellige Web-Z gateways eller flere forskellige konfigureringer af samme. Bruger DB Uni/Bib C Autentificering Uni/Bib D Bruger DB C Web-Z gateway D Web-Z gateway Nedenfor vises et mere udfoldet eksempel på Z-gate-modellen. Som det fremgår udmærker modellen sig også ved at afgrænsningen af de tre roller: brugere, adgangsformidlere og informationsudbydere, fuldstændigt er i overensstemmelse med afgrænsningen af de tre tekniske lag: Web-browser, Web-Z-gateway og Z-server. DEF

12 3. Implementeringsmodeller Z39.50 gateway ret arkitektur Brugere Adgangsformidlere Informationsudbydere Bruger Bruger Bruger DB DB DB m/autor Trykte saml. Autentifi- A A Web-Z A Autentifi- A Autentifi- cering Web-Z cering Web-Z gateway gatewa cering gatewa y y m/autor m/autor m/autor Trykte saml. Z to? gateway m/autor??? Brugerne vælger bibliotek og logger ind med brugernavn/pasord via autentificeringsgaten, der validerer ved opslag i det valgte biblioteks lånerdata. Brugere kommer herefter til bibliotekets Web-Z gateway, sat op med Z-server adgang i overensstemmelse med brugerens eller brugergruppens rettigheder. Brugeren kan herefter (sam)søge i alle de Z-datar, gatewayen er konfigureret med, hvis de pågældende Z-serveres autorisationsfunktion åbner for det pågældende biblioteks gateway. Nogle af disse datar kan tænkes at være bragt ind i Z-universet via en Z Web gateway, der afkoder de pågældende datars web-interface (ved hjælp af screen scraping eller bilateralt aftalt pseudo protokol (se øverst side 10)). DEF

13 3. Implementeringsmodeller Hybrid-modellen Hvis man forventer, at der til det nuværende DEF landskab skal føjes web-ressourcer uden eget Z39.50 interface, må man overveje om disse ressourcer: kan stilles til rådighed uden om DEF Nøglens adgangskontrol, dvs via direkte forbindelse til web-browseren (måske typisk løsning for simple web-sites, der ikke ønskes integreret med DEF s søgetjenester) kan stilles til rådighed via en gateway der forbinder Z med den givne proprietære protokol (incl. screen-scraping). Denne gateway udbyder så ressourcen med Z- protokol (måske typisk for søgetjenester, der ønskes integreret med DEF s egne) absolut kræver anvendelse af DEF Nøglens adgangskontrol, uden at kunne integreres via en Z-? gateway. Det første tilfælde kan håndteres af enhver model, da der jo blot er tale om at definere et givet web-site ud af DEF Nøgle sfæren noget der givet vil være behov for i enhver løsning. Det andet tilfælde er udmærket håndteret af Z-gate-modellen, mens man i det sidste tilfælde må overveje en udbygning af Z-gate-modellen med en supplerende webproxy funktion og dermed en ny hybrid model. Web browser HTTP HTTP Bibl. syst Bruger DB Autentificering Web Proxy Web-Z way HTTP Z39.50 Web server uden for Nøgle Web server m/autorisation m/autorisation Sessions tabel Log Z39.50 Z gate med autor. Web serv NB: Til hver af serverne med autorisationsfunktion hører der såvel rettighedtabel som log af pladshensyn er disse imidlertid ikke indtegnet. Denne model er således ret på en integration af autentificeringsfunktionen med såvel en Web-proxy som en Web-Z gateway. Web-proxyen bringes kun i spil, når der skal kommunikeres med Web-sites, der ikke kan integreres via Z Herved introducerer modellen intet tab i effektivitet eller funktionalitet, men løser det eventuelle problem med adgang til ressourcer, der skal Nøgle-intergreres, men ikke kan Z- integreres. Der er her tale om en udbygning af den rene Z-gate-model, en Z-gate-plus-model, der naturligvis øger den samlede tekniske kompleksitet, men den kan implementeres med klar afgrænsning til den forventede Z-rede hovedvej. Herved kan web-proxy en ses som en tilbygning, hvis omkostninger skal sættes i forhold til vigtigheden af integrationen af disse eventuelle ellers-ikke-integrerbare-ressourcer. I organisatorisk sammenhæng har hybrid-modellen grundliggende samme egenskaber som Z-gate-modellen. DEF

14 3. Implementeringsmodeller Hybrid arkitektur (Z-gate-plus) Brugere Adgangsformidlere Informationsudbydere W server m/autor Bruger Bruger DB Bruger DB DB W server m/autor m/autor Trykte saml. Web proxy Autentifi- A A Autentifi- A A Autentificering Web-Z cering Web-Z Web-Z gatewa cering gatewa gateway y y m/autor Trykte saml. Z to? gateway m/autor??? Som ved den rene Z-gate-model vælger brugerne bibliotek (universitet eller lignende adgangsformidler) og logger ind med brugernavn/pasord via autentificeringsgaten, der validerer ved opslag i det valgte biblioteks lånerdata. Brugere må herefter vælge om de vil i kontakt med de samsøgbare tjenester via Web-Z gatewayen eller i kontakt med en af Web-proxyens web-sites. Denne valgsituation skal selvfølgelig præsenteres med en ikke-teknisk brugergrænseflade, fokuseret på informationsindholdet. Vælger brugeren Web-proxy adgang, må brugeren dernæst vælge det interessante Web-site (antagelig fra en liste af sådanne tilpasset brugerens eller brugergruppens rettigheder) og kan da interagere med dette, med proxyen arbejdende transparent i baggrunden. Vælger brugeren Web-Z adgang, kommer brugeren til bibliotekets Web-Z gateway, sat op med Z-server adgang i overensstemmelse med brugerens eller brugergruppens rettigheder. Brugeren kan herefter browse eller (sam)søge i alle de Z-datar, gatewayen er konfigureret med. DEF

15 4. Adgangsstyringsmodeller 4. Adgangsstyringsmodeller Selve adgangsstyringen kan etableres på to måder: A. Brugerkategori-modellen, der rer sig på et sæt standardiserede brugerkategorier, som alle adgangsformidlere opdeler deres brugere i, og som alle informationsudbydere accepterer som grundlag for aftaler om ressourceadgang. B. Ressource-ID-modellen, der rer sig på etableringen af unikke ID-numre for alle informationsressourcer og på adgangsformidlernes tildeling af disse IDnumre til de enkelte brugere som nøgler til de pågældende ressourcer. De to modeller tager altså henholdsvis udgangspunkt i en standardiseret kategorisering af brugerne og i en fælles liste over informationsressourcer og deres ID-numre. En væsentlig parameter i valget mellem de to metoder er følgelig det forventede antal brugerkategorier respektive ressource-id er samt omfanget af den nødvendige indsats for at etablere disse. Endelig vil det også være muligt at operere med begge modeller samtidigt, omend dette vil forøge implementeringsomkostningerne tilsvarende. Ad. A. Brugerkategori-modellen: Autentificering Brugerens logindata valideres ved opslag i det specificerede biblioteks brugerdata, hvor det desuden kan checkes, om brugeren skulle være spærret. De for DEF Nøglen nødvendige oplysninger indhentes fra brugerdatan. Det drejer sig typisk om nedenstående, hvor visse elementer dog kun spiller en rolle i forbindelse med adgang til trykte informationsressourcer, mens de to sidste er de essentielle for brugerkategori-modellen: Nøglens dataelementer Eksempel 1. Bibliotekskode XUB (eller BS nr) 2. Brugers ID heha 3. Brugers password xxxxxxxxxxx 4. Spærrekode 0 5. Brugers navn Henrik Hansen 6. Brugers post-adresse Borgerdiget 42B st.th Roskilde 7. Brugers -adresse henrik32@image.dk 8. National brugerkategori DEF Lokal brugerkategori XUB09 DEF

16 4. Adgangsstyringsmodeller 1. Bibliotekskode Dette er identifikationen af det bibliotek, brugeren er logget ind hos, og som udstyrer brugeren med rettigheder. Bibliotekskoden skal endvidere fungere som låneridentifikation, når der bestilles formidlede lån (fjernlån) fra et andet bibliotek. Biblioteksstyrelsens biblioteksnumre skulle have den egenskab, at alle udlånende biblioteker accepterer dem som låneridentifikation, hvorfor de i givet fald vil være at foretrække. 2. Brugers ID Dette er brugerens identifikation hos indlogningsbiblioteket. Den er kun direkte påkrævet i forbindelse med direkte lån af trykt materiale. Den må dog anses for interessant for alle informationsudbyderne, idet den vil give disse mulighed for at udføre stikprøvekontrol af adgangsformidlernes tildeling af rettigheder til de enkelte brugere. Alternativt kan den sendes videre i en scramblet form, der beskytter CPR-nr og andre sensitive indentifikationstyper, uden at miste muligheden for præcis stikprøvekontrol. 3. Brugers password Dette dataelement er udelukkende til brug for gateway en og videresendes ikke. Bruges kun til at validere brugerens indtastning i forbindelse med login. 4. Spærrekode Dette dataelement er ligeledes udelukkende til brug for gateway en og sendes heller ikke videre til informationsudbyderne. Spærrekoder anvendes til at signalere midlertidige indskrænkninger i en brugers rettigheder f.eks. i forbindelse med forsømmelighed ved aflevering af udlånte objekter eller betaling af restancer. Definition af et muligt sæt fælles spærrekodeværdier udestår (f.eks. 0=Ingen spærring, 1=Fuld spærring, 2=Spærring for lån, 3=Spærring for digital adgang, etc). 5. Brugers navn Er udelukkende påkrævet i forbindelse med post-adressering af trykt materiale, der er lånt via formidler, men som skal sendes direkte. 6. Brugers post-adresse Er udelukkende påkrævet i forbindelse med post-adressering af trykt materiale, der er lånt via formidler, men som skal sendes direkte. 7. Brugers -adresse Er udelukkende påkrævet i forbindelse med -notificering af trykt materiale, der er lånt via formidler, men som skal sendes direkte. 8. National brugerkategori Den nationalt aftalte kategorisering af brugere forenkler indgåelse og administration af aftaler mellem formidlere og udbydere specielt i forbindelse med nationale licenser. Endvidere vil den antagelig kunne løse de fleste behov i forbindelse med DEF partnernes bi- eller multilaterale forhandlinger om adgang til informationsservices. DEF

17 4. Adgangsstyringsmodeller Den vil antagelig operere med kategorier for personer som: - [Ansat ved ] - [Studerende ved ] - [Privatperson] hvor repræsenterer et institutionsnavn fra en officiel DEF liste over forsknings- og undervisningsinstitutioner, og kategorier for institutioner som: - [Offentligt forskningsbibliotek] - [Offentligt folkebibliotek] - [Anden offentlig institution] - [Andre institutioner, organisationer, virksomheder] Dette vil resultere i et samlet antal kategorier, der svarer til fire gange antallet af forsknings- og undervisningsinstitutioner på listen, og som let kan nå op på flere tusinde. 9. Lokal brugerkategori Denne tjener udelukkende det formål, at tillade DEF partnerne individuelt at definere andre kategorier end de nationale, eventuelt med en supplerende (eller alternativ) opdelingslogik. Dette kan være nødvendigt i bilaterale adgangsarrangementer, der ikke kan udtrykkes med de nationale kategorier. Ad. A. Brugerkategori-modellen: Autorisation Autorisationen rer sig på aftaler indgået mellem adgangsformidler og informationsudbyder om adgang til en eller flere informationsudbyderens services for alle eller visse kategorier af adgangsformidlerens brugere. Disse aftaler er registreret i en rettighedstabel i informationsudbyderens autorisationsfunktion. Principielt er rettighedstabellen af nedenstående tilsnit, hvor hver celle rummer et ja eller nej til adgang til den pågældende service for den pågældende brugergruppe: Brugerkategori Service 01 Service 02 Service 03 Service 04 Service 05 Service 06 Service 07 Service 08 Service 09 Service DEF0001 DEF0002 DEF0003 DEF0004 DEF XUB01 XUB02 XUB YUB01 YUB02 YUB Principiel layout af rettighedstabel for en enkelt informationsudbyder DEF

18 4. Adgangsstyringsmodeller Som tidligere nævnt har autorisationen to niveauer: For det første informationsudbyderens afgørelse af, hvorvidt der overhovedet skal kommunikeres med den pågældende adgangsformidlers gateway antagelig realiseret på basis af IP kontrol. For det andet afgørelsen af, hvorvidt den pågældende brugerkategori skal have adgang til den ønskede service. Hvis adgangsformidlerens gateway selv er i stand til at tilpasse sig de forskellige brugerkategoriers rettigheder og dermed udelukke uautoriseret adgang, kan informationsudbyderen vælge at nøjes med det første niveau af autorisation, hvilket vil nedbringe implementerings- og driftsomkostningerne væsentligt. Under alle omstændigheder må informationsudbyderen have tillid til, at adgangsformidleren kategoriserer de enkelte brugere korrekt. Denne tillid kan evt. underbygges af adgangen til af fortage/bestille stikprøvekontrol af den adgangsskabende kategorisering. Ad. B. Ressource-ID-modellen 1. Informationsudbyderne registrerer deres services/ressourcer hos en central instans (som DEF Sekretariatet idag) der tildeler hver service/ressource et unikt ressource- ID. F.eks. tildeles INSPEC datan siden 1970 hos DTV det unikke ressource-id DEF0092. Den registrerende instans publicerer en løbende opdateret liste over services/ressourcer og deres respektive ressource-id er, f.eks. via en webside. Service/ressource Specifikation Udbyder Ressource-ID INSPEC DTV DEF0092 Artikeln DBC DEF0093 Denne webside vil således udgøre et fuldstændigt katalog over de services/ressourcer, der udbydes til DEF s brugere via deres adgangsformidlere og under Nøgle-kontrol. Dette åbner blandt andet mulighed for, at motiverede adgangsformidlere (f.eks. partnere i et forhandlings-konsortium) kan aggregere deres benyttelsesstatistik på basis af ressource-id. 2. Informationsudbyderne kan eventuelt liste på deres web-sites hvilke adgangsformidlere, der har adgang til de enkelte services/ressourcer og for hvilke udsnit af deres brugere. Ressource-ID Service/ressource Formidler Omfang DEF0093 Artikeln AUB Alle AUC ansatte DEF0093 Artikeln KB Alle KU studerende I så fald kan man forestille sig at der kan linkes via ressource-id en fra den ovennævnte centrale webside til den relevante del af den pågældede udbyders web-side Det er dog vigtigt at fremhæve, at denne aktivitet fra informationsudbydernes side ingenlunde er nødvendig for adgangsstyringen og kan udelades for at sænke DEF

19 4. Adgangsstyringsmodeller tærsklen for informationsudbyderne.. 3. Da adgangen til en given service/ressource vil være betinget af, at brugeren er udstyret med den respektive ressource-id, bliver det herefter adgangsformidlerens opgave at sikre at brugerne tildeles de rette ressource-id er. (Hver ID er reelt en nøgle til en specifik registreret ressource, hver bruger udstyres således med et større eller mindre nøgleknippe.) Den enkelte adgangsformidler kan gøre dette ved at: Udvide den nuværende brugerdata med et gentageligt felt til ressource-id er Udvikle en lokal regel hvorefter ressource-id er automatisk kan tildeles de eksisterende brugere på basis af oplysninger i brugerdatans øvrige felter Supplere (eller erstatte) den automatiske tildeling med manuelle rettelser/tildelinger Indføre tildeling af ressource-id er i standardprocedurerne omkring brugeroprettelse Vedligeholde tildelingen af ressource-id er ved hjælp af opdateringsrutiner, der opererer automatisk på basis af oplysninger i brugerdatans øvrige felter (Dette ligner andet eksisterende husholdningsarbejde omkring brugerdatar) 4. Alternativt kan tildelingen af ressource-id er overlades til DEF Nøgle way ens autentificeringsmodul, der så må tildele ID er on-the-fly på basis af en beslutningstabel. Dette vil dog fjerne mulighederne for individuel tilretning. Eventuelt kan en hybrid model etableres, hvor tabelopslag giver de grundlæggende rettigheder (ressource-id er) og yderligere rettigheder hentes fra et manuelt opdateret felt i brugerdatan. 5. De enkelte adgangsformidlere kan via et website informere informationsudbyderne om hvorledes de tildeler ressource-id er til deres brugere: Antallet af brugere per ressource-id Regler omkring tildeling af de enkelte ressource-id til brugerne Herved kan informationsudbyderne informere sig om adgangsformidlernes forvaltning af den indbyrdes aftale om informationsadgang for bestemte brugergrupper. 6. Når en bruger logger ind på way en etableres brugerens nøgleknippe (sortiment af ressource-id er) ved opslag i den specificerede brugerdata. Dette sker enten ved direkte opslag eller via en mapning af brugerdatadata til ressource-id er. Dette nøgleknippe bestemmer udseendet af way brugergrænsefladen og dermed hvilke services/ressourcer brugeren tilbydes adgang til. Denne model føjer altså følgende to dataelementer til Nøglen: Nøglens dataelementer Eksempel 10. National ressource-id DEF Lokal ressource-id XUB07 DEF

20 5. Digitalt scenarie 5. Det digitale scenarie Det digitale scenarie, dvs. brugernes adgang til fuldt digitaliserede informationsressourcer, er allerede beskrevet implicit i foranstående gennemgang af implementerings- og adgangsstyrings-modeller. Scenariet, hvor altså såvel metadata som fuldtekst er elektronisk tilgængelig på nettet, kan realiseres af alle de tre nævnte implementeringsmodeller. De Z-rede modeller vil dog have de allerede nævnte fortrin med hensyn til harmonisering af brugergrænsefladen og samsøgning af datar. Hvad angår adgangsstyringsmodeller gælder det ligeledes, at begge vil kunne anvendes, mens den ene synes fordelagtig i implementeringsmæssig henseende. Ressource-ID-modellen tillader en hurtigere igangsætning af DEF Nøglen, idet den ikke forudsætter en global enighed om brugerkategoriernes definition Man foregriber ikke den fremtidige definition af adgangsvilkår ved at fryse sig fast til én definition af brugerkategorier Man undgår et stort og tungt vedligeholdeligt system af brugerkategorier f.eks institutioner/firmaer indenfor forskning og undervisning vil resultere i 4500 brugerkategorier (institutionen/firmaet selv, ansatte ved, studerende ved) er 1500 nok? hvor ofte er der opdateringer til et sådant organisatorisk landskab? Systemet kan sættes i drift så snart 1 informationsudbyder har registreret 1 service og 1 adgangsformidler har tildelt de relevante brugere en nøgle (ressource-id) til den registrerede service. Med andre ord, behøver alle ikke at vente på alle. Til gengæld kan denne model have svagheder, hvis der ønskes en brugerkategoriopdelt forbrugsstatistik f.eks benyttelsen af tidsskrifttitler fordelt på lokale brugerkategorier. Hvis en sådan statistik skal udarbejdes af informationsudbyderen, skal denne informeres om den enkelte brugers lokale kategori. Dette kan i ressource-id-modellen gøres ved at transmittere den lokale brugerkategori til udbyderen i henhold til en bilateral aftale. DEF