31. oktober 2005 FORANALYSERAPPORT EduMedia Online adgang til forsknings- og undervisningsrelevant videomateriale Om rapporten Rapporten falder i to dele: Første del af rapporten opsummerer hhv. formål, mål og succeskriterier for det samlede projekt, målgrupperne, de vigtigste funktionelle og tekniske krav til systemet, ligesom den skitserer en løsningsmodel, opdeling i delprojekter, økonomi og businesscase. Opsummeringen af er foretaget på baggrund af de analyser, som fem arbejdsgrupper under EduMedia-projektet har udarbejdet. Arbejdsgrupperne var nedsat til at komme med analyser, anbefalinger og eventuelle konceptforslag omkring 1) etablering af en egnet autentifikations- og autorisationsmekanisme, 2) systemarkitektur og uploadog out put formater, 3) brugsscenarier/brugerbehov, 4) juridiske problemfelter ifm. den skitserede infrastruktur, samt 5) metadatering/ registrering af materiale og udveksling af metadata. Anden del udgøres af analyserne, de respektive arbejdsgrupper har leveret inkl. eventuelle anbefalinger og konceptforslag (en oversigt over arbejdsgruppernes sammensætning samt analyserne er bragt som bilag). Indhold Indledning...1 Formål...1 Mål...1 Målgruppe...2 Afgrænsning...2 Businesscase...2 Skitseret løsning...2 Vigtigste krav...3 Opdeling i delprojekter og faser...3 Økonomi for næste fase...4 Overordnet tids- og aktivitetsplan...5 Bilag 1. Oversigt over sammensætningen af EduMedia arbejdsgrupperne 2. EduMedia AAI 3. EduMedia arkitektur og formater 4. EduMedia brugsscenerier 5. EduMedia jura 6. EduMedia metadata 0
INDLEDNING I dag anvender de færreste DEFF/FSK-brugere digital video oa. audiovisuelle ressourcer over Internettet ifm. undervisning, forskning og formidling. Væsentlige årsager hertil er, at der ikke findes nogen samlet indgang til en kritisk masse af ressourcer, hvor man kan søge på og finde relevante materialer, og at distributionen er teknisk krævende dels rent praktisk og dels juridisk ifht. at sikre ophavsretlige interesser. Hvis brugen af audiovisuelle ressourcer skal fremmes, er der er derfor brug for en infrastruktur, der kan gøre det lettere at bruge og distribuere audiovisuelle ressourcer. EduMedia-projektet er et forsøg på en sådan infrastruktur, som på en let og sikker måde giver brugerne mulighed for at tilgå og distribuere beskyttede audiovisuelle ressourcer, primært video, via Internettet. En fælles, robust og brugercenteret infrastruktur som EduMedia forventes derudover at give en bedre basis for aftaleindgåelse omkring adgang til/brug af audiovisuelt indhold med hhv. rettighedshaverorganisationer og semi-kommercielle organisationer, såsom public service institutioner og undervisningsforlag, end initiativer blandt de enkelte organisationer/institutioner. Infrastrukturen vil, når der er fundet en forretningsmodel, blive stillet til rådighed for alle institutioner og organisationer under DEFF og FSK. FORMÅL At etablere en webbaseret infrastruktur som på et praktisk og teknisk støtter brugerne i at distribuere og anvende videobaserede ressourcer ifm. deres forskning, undervisning og formidling, og som samtidigt giver adgang til en langt større mængde af de audiovisuelle ressourcer, der findes i danske biblioteks- og kulturarkiver som DR og Statsbiblioteket, end hidtil muligt pga. tekniske og ophavsretlige barrierer. MÅL At etablere en webbaseret infrastruktur baseret på internationale standarder, som på en let og sikker måde giver brugere indforskrevet ved danske universiteter hhv. adgang til og mulighed for at distribuere beskyttet audiovisuelt materiale via streaming teknologi. Delmål og succeskriterier: 1. At etablere en infrastruktur, som baseret på en autentificering og autorisation af brugeren, kan give adgang til audiovisuelle materialer, der af ophavsretlige eller andre grunde ikke kan være offentlig tilgængelig. v1: Infrastrukturen skal kunne autentificere og autorisere op mod den danske del af EduRoam/RADIUS-hierakiet. 2. At indgå aftaler om udvalgte fagligt relevante audiovisuelle materialer i høj kvalitet fra DR og SB oa. nationale og udenlandske videoarkiver mhp. tilgængeliggørelse via EduMedia. v1: Det har ikke været muligt at sætte et eksakt tal på endnu, men såvel SB som DR ønsker at tilgængeliggøre store mængder materialer. 3. At give brugerne mulighed for at distribuere egenproduceret materiale i et eller flere formater, herunder mulighed for at ingeste/uploade/submitte i som minimum ét højkvalitetsformat til automatisk transcoding til præsentationsformater. v1: Materiale skal kunne ingestes i DV og MPEG2, og streames i hhv. Windows Media, Real Media, QuickTime og MPEG4 (ISMA + 3GPP). 4. At give brugerne mulighed for at uploade og afvikle det audiovisuelle materiale på et repræsentativt udvalg af operativsystemer. v1: Upload og afvikling skal kunne ske på Windows XP/2000, MacOS 10+ og Linux. 5. Med udgangspunkt i den udviklede demo at analysere på, hvilke værktøjer brugerne har behov for i relation til at arbejde med det streamede audiovisuelle materiale. v1: Mindst ét værktøj skal være implementeret. 1
MÅLGRUPPE Primære målgruppe: Forskere, undervisere, studerende m.fl. ved institutionerne under DEFF og FSK. Denne brugergruppe skal ved log in via webgrænsefladen (webportal) have mulighed for at uploade, lagre og arbejde med audiovisuelt materiale, samt at distribuere dette. Sekundær målgruppe: I det omfang ophavsretlige mv. forhold tillader det, er ambitionen at tilgængeliggøre indholdet for den generelle offentlighed. Tilgængeliggørelse betyder her, at brugergruppen udelukkende har mulighed for at afvikle/se clearet indhold. AFGRÆNSNING Udgangspunktet for EduMedia v. 1 er de audiovisuelle materialer, men af hensyn til de fremtidige udviklingsmuligheder for infrastrukturen, skal der som noget af det første i udviklingsfasen tages stilling til hvilke andre materiale- og dokumenttyper, der evt. skal kunne håndtere på længere sigt. BUSINESSCASE En fælles, robust og brugercenteret infrastruktur som den beskrevne forventes at forbedre brugernes adgang til audiovisuelt materiale og dermed fremme spredningen, udvekslingen og anvendelsen af disse værdifulde ressourcer at øge fokus på potentialerne i at bruge de audiovisuelle medier frem for på teknologien og ressourcerne, det ellers ville være nødvendigt at investere at have større gennemslagskraft ift. at fremme brugen af audiovisuelle ressourcer end spredte initiativer blandt de enkelte organisationer/institutioner at forbedre mulighederne for at indgå aftaler med rettighedshaverorganisationer, semi-kommercielle organisationer, fx public service institutioner og undervisningsforlag, om indhold. SKITSERET LØSNING 2
Ovenstående skitse viser projektets delsystemer og deres samspil med omverdenen. EduMedia forventes at blive udviklet i hhv. en version 1 og en version 2. Førstnævnte baseres på adgangskontrol vha. Eduroam 1 og sidstnævnte baseres på den kommende fælles AA-infrastruktur, AAI-DK. Der tages udgangspunkt i DRs asset management system, men arbejdes hen mod en open source repository arkitektur (Fedora) for version 2, der skalerer bedre ift. fremtidige behov. VIGTIGSTE KRAV Systemet skal overholde internationale standarder for metadatering, udveksling og transport af metadata. anvende en mekanisme til autentifikation og autorisation, der sikrer at 1)autentifikationen så vidt muligt foregår lokalt på brugerens egen institution, 2) materiale på EduMedia sikres mod uautoriseret adgang og distribution, og 3)autorisationsmodellen er så fleksibel som mulig. understøtte distribueret storage og streaming, og i forbindelse med sidstnævnte at distribution sker i et eller flere af de til enhver tid gængse streaming formater understøtte en lang række forskellige brugsscenarier, afhængig af om leverandøren er en professionel leverandør, en enkelt forsker eller et institutional repository, og tilsvarende af om brugeren er en registreret bruger eller ej, og hvorvidt brugeren tilgår materialet direkte eller gennem en webservice requestor som fx en institutions egen hjemmeside eller LMS. understøtte: 1) søgning i materialerne, 2) associering af video med andre materialer og 3) funktionaliteter, der gør det muligt at arbejde med materialet, fx annotere være designet sådan at, brugerne får en forståelse for de juridiske problemstillinger, deres handlinger medfører og det ansvar, de har i den forbindelse. Teknisk skal systemet laves sådan, at lovbrud tydeligt forudsætter både misbrug af system og aftalebrud. OPDELING I DELPROJEKTER OG FASER Delprojekterne/aktiviteterne omfatter primært: Tilretning af DR asset management system, som bl.a. udvides med følgende moduler jf ovenstående illustration: 1. Ingest 2. Validering 3. Transcoding 4. Lokalisation 5. Præsentation 6. Logning 7. AAA 8. Metadatahøstning 9. Metadatastyring 10. Brugerværktøjer Analyse af brugerbehov ifm. at arbejde med audiovisuelt materiale mhp. udvikling af infrastrukturens funktionalitet Fastlæggelse og dokumentation af interne procedurer for overvågning og evt. fjernelse af indhold. Udarbejdelse af formularer, standardaftaler oa. juridiske foranstaltninger, herunder Forhandlinger med Copy-Dan og evt. andre rettighedshaverorganisationer. Udformning af fremtidig drifts- og forretningsmodel. Ansvaret for udførelsen af opgaverne fremgår af omstående budget. 1 EduRoam er en autentifikationsinfrastruktur, der giver brugere Internetadgang, når de besøger andre institutioner i ind- og udland. Ifm. Rektorkollegiets projekt Digital Forvaltning udrulles EduRoam til alle danske universiteter. 3
ØKONOMI FOR NÆSTE FASE Udgifter FSK DR SB Projektet Egenudg. Ansøgt Egenudg. Ansøgt Egenudg. Ansøgt Egenudg. Ansøgt Løn Projektledelse 500.000 500.000 0 Teknisk koordinering 125.000 125.000 0 Teknisk projektledelse 43.000 51.000 10.000 10.000 178.000 61.000 Udvikling: Asset Management tilr. 167.000 197.000 167.000 197.000 Ingest (1) 43.000 51.000 43.000 51.000 Validering (2) 43.000 51.000 43.000 51.000 Transcoding (3) 86.000 101.000 86.000 101.000 Lokalisation (4) 42000 42000 42.000 42.000 Præsentation (5) 42.000 86.000 101.000 86.000 143.000 Logning (6) 42.000 0 42.000 AAA (7) 42.000 0 42.000 Metadatahøstning (8) 32.000 32.000 32.000 32.000 Metadatastyring (9) 43.000 51.000 43.000 51.000 Brugerværktøjer (10) 0 0 Front end design 41.000 48.000 41.000 48.000 Fedora-udvikling 83.000 83.000 83.000 83.000 Lønudgifter i alt 625.000 126.000 552.000 651.000 167.000 167.000 1.344.000 944.000 Hardware Servere 90.000 90.000 90.000 90.000 2 TB disk array 40.000 40.000 40.000 40.000 Support/vedligehold 80.000 80.000 0 Hardware i alt 210.000 130.000 0 0 0 0 210.000 130.000 Software Mediehåndteringssystem 1.820.000 1.820.000 0 Jobhåndteringssystem 130.000 130.000 Webapplikation 650.000 650.000 Operativsystemer 10.000 10.000 0 Serverlicenser 214.000 214.000 0 Webstatistikværktøj 10.000 0 10.000 Support/vedligehold 100.000 100.000 0 Software i alt 324.000 10.000 2.600.000 2.924.000 10.000 Øvrige udgifter Advokatbistand 200.000 0 200.000 Usability 63.000 0 63.000 Formidling 10.000 0 10.000 Transport 45.000 0 45.000 Konferencer mv. 10.000 0 10.000 Øvrige udgifter i alt 0 328.000 0 328.000 Samlede udgifter 1.159.000 594.000 3.152.000 651.000 167.000 167.000 4.478.000 1.412.000 Et mandeår er sat til 500.000 kr. inkl. overhead. 4
OVERORDNET TIDS- OG AKTIVITETSPLAN 1. kvartal 2. kvartal 3. kvartal 4. kvartal Analyse og design Modul 1-10 Metadataskema og profiler Koncept for Fedora repository Udvikling og implementering Software install Hardware setup Tilretning af DR asset management system Migrering af FSK streaming- og webserver setup Etablering af databaser Modul 1-10 Webservice Udvikling af Fedora repository Test og tilretning Test af demo mhp. specificering af værktøjer/funktionalitet (modul 10) Usability på lokalisation og præsentation Test af asset management og webservice Test af modul 1-10 Tilretning asset management og webservice Test af Fedora repository Tilretning af af modul 1-10 Øvrige aktiviteter Udkast til standardaftaler til ikke-professionelle indholdsleverandører Indledende forhandlinger med Copy-Dan oa. andre rettighedshaverorgani sationer Godkendelse af standardaftaler (advokatbistand) Procedurer for overvågning fastlægges Forretningsmodel udarbejdes Etablering af aftaler om indhold Clearing af indhold Brugerdokumentation udarbejdes Materiale til markedsføring af projektet Evaluering Ansøgning fase III 5
Bilag 1 Oversigt over arbejdsgrupper og deltagere. AAI Allan Dukat, UNI-C Dan Mønster, UNI-C David Simonsen, UNI-C Jacob Gadegaard Bendixen, SB Steen Lindén, UNI-C Arkitektur og formater Birte Christensen-Dalsgaard, SB Dan Mønster, UNI-C Ivan Dehn, DR Mads Brydegaard, DR Brugsscenarier Diba Markus, KSF Helle Meldgaard, UNI-C Henning Olesen, SB Marianne Georgsen, E-learning Lab, AAU Tobias Golodnoff, DR Jura Birgitte Bollerup Jacobsen, DR Tobias Golodnoff, DR Harald von Heimcrone, SB (vejledning og sparring) Metadata Dan Mønster, UNI-C Elsebeth Kirring, SB Ivan Dehn, DR 1 af 1
Bilag 2 EduMedia AAI Oktober 2005 Dan Mønster, UNI-C BAGGRUND Denne rapport præsenterer EduMedia projektets AAI-arbejdsgruppes resultater. Arbejdsgruppens mandat lød på at identificere mulige autentifikations- og autorisationsmodeller til anvendelse i EduMedia projektet. Desuden blev gruppen bedt om at se på hvilke oplysninger, der bør, og må logges om brugerne og deres brug af tjenesten. Denne del er kun summarisk behandlet, da medlemmerne i gruppen ikke besidder den nødvendige indsigt i de juridiske aspekter. MÅL Målet med AAI-gruppens arbejde har primært været at finde den optimale mekanisme til autentifikation og autorisation, der sikrer at autentifikationen så vidt muligt foregår lokalt på brugerens egen institution at materiale på EduMedia sikres mod uautoriseret adgang at autorisationsmodellen er så fleksibel som muligt KONKLUSIONER OG ANBEFALINGER Da der ikke pt eksisterer en samlet fødereret autentifikations- og autorisationsinfrastruktur (AAI) for de højere uddannelses- og forskningsinstitutioner i Danmark, vil EduMedia, indtil en sådan infrastruktur er etableret, skulle anvende en anden AAI-mekanisme. Det er gruppens anbefaling, at EduMedia på kort sigt anvender den danske del af EduRoam hierarkiet til autentifikation, mens autorisation håndteres som en del af EduMedia. For at opnå en tilstrækkelig beskyttelse af materialet i EduMedia anbefaler gruppen, at autorisation skal foregå både på webserver og streamingserver. Hvis der kun autoriseres mellem brugerens webbrowser og en EduMedia webserver, vil det være muligt, at opsnappe en URL til streaming og i bedste fald afspille den uden at være autoriseret, men i værste fald at optage streamen til en fil, der derefter vil kunne distribueres. Gruppen har fundet, at det er muligt at lave plugin-moduler til de mest gængse streamingservere, der muliggør denne form for autorisation. Dette gælder specifikt RealNetworks Helix Universal Server, Microsoft Windows Media Services, Apple QuickTime Streaming Server og Darwin Streaming Server. Gruppen har endnu ikke undersøgt hvorvidt det samme gælder andre relevante servere som fx. Macromedia Flash Media Server. Fælles for de undersøgte server er det, at de alle anvender Real Time Streaming Protocol (RTSP) til kommunikation mellem klient og server. Det er også muligt at anvende Digital Rights Management (DRM) til at beskytte materialet mod uautoriseret brug, men der findes ingen DRM standard, som kan benyttes på tværs af formater og platforme, og det vil gøre adgangen til materialet vanskeligere for brugeren. Det er derfor gruppens vurdering at autorisation på både webog streaming server vil give en tilstrækkelig beskyttelse af materialet, og at der derfor ikke er grund til at anvende DRM. 1 af 15
Anbefalet løsning på kort sigt Bilag 2 AAI-gruppen anbefaler, at EduMedia på kort sigt anvender EduRoam som basis for autentifikation af brugere, mens autorisation håndteres af EduMedia selv baseret på brugernes EduRoam identitet (brugernavn). EduRoam-projektet giver akademiske brugere primært i Europa men på sigt også på globalt plan adgang til nettet, når de besøger andre institutioner som deltager i EduRoam. Autentifikation af brugere i EduRoam sker mellem brugeren og dennes hjeminstitution gennem et hierarki af RADIUS servere. EduRoam er et internationalt projekt, som er startet af TERENA, men som nu også finansieres gennem det fælleseuropæiske GÉANT2 projekt, og med deltagelse af lande uden for Europa. I Danmark står Forskningsnettet for driften af den nationale top-level RADIUS server, og projektet er støttet af Rektorkollegiets projekt Digital Forvaltning. På længere sigt vil der sandsynligvis blive indført krav om, at autentifikationen i EduRoam udelukkende baseres på IEEE 802.1X, hvilket dermed udelukker brug af en webbaseret autentifikationsmekanisme, som jo er det EduMedia vil skulle benytte. Det formodes dog, at der inden for en overskuelig fremtid stadig vil være mulighed for at anvende webbaseret autentifikation i EduRoam, og at EduMedia inden der lukkes for denne type autentifikation, vil være overgået til en anden autentifikationsmekanisme (jvf. næste afsnit). Anbefalet løsning på længere sigt Det er ikke muligt, at anbefale en bestemt løsning på længere sigt, men vi kan pege på nogle konkrete udviklinger, som peger i retning af en fremtidig model for en fælles autentifikations- og autorisationsinfrastruktur for danske institutioner inden for højere uddannelse og forskning (dvs. primært universiteterne). I USA udvikles og anvendes Shibboleth af Internet2 projektet, og det må formodes at stort set alle amerikanske universiteter vil anvende Shibboleth til autentifikation og autorisation både internt, på tværs af institutionern og ifm. eksterne tjenesteudbydere som fx. forlag. I Europa har det schweiziske forskningsnet SWITCH baseret den nationale AA infrastruktur SWITCHaai på Shibboleth. I Danmark har især DEFF arbejdet med Shibboleth, bl.a. ifm. abonnement på elektroniske tidsskrifter. Rektorkollegiet har med projektet Digital Forvaltning et delprojekt, der har til formål at se på muligheden for at definere fælles gruppe- og rollebegreber, som vil kunne anvendes som basis for en fremtidig autorisationsmodel. Rektorkollegiet har for nyligt desuden taget initiativ til, at der etableres en fælles dansk AA infrastruktur. Dette projekt går under navnet AAI DK og har deltagelse fra både Rektorkollegiets IKT-udvalg og DEFF. Det er med al sandsynlighed dette projekt, som kommer til at definere den fremtidige fødererede AAI for det højere uddannelsesområde i Danmark. EduMedia er en vigtig case i arbejdet med AAI DK og anbefalingen for EduMedias AAI-gruppe er at EduMedia arbejder tæt sammen med AAI DK projektet og overgår til denne nye AAI så snart som det er praktisk muligt. Det formodes at AAI DK projektets løsning vil blive baseret på Shibboleth, da Shibboleth på globalt plan er det største af sin art. BESKRIVELSE AF MULIGE LØSNINGER PÅ AAI-INFRASTRUKTUR I dette afsnit vil det blive beskrevet i lidt større teknisk detalje hvorledes man kan anvende hhv. EduRoam og Shibboleth som AAI ifm. EduMediaprojektet. Gennemgangen af EduRoam er mere detaljeret, men dette er mest af hensyn til ikke at overbelaste læseren med en masse detaljer omkring Shibboleth, da dette ikke umiddelbart står overfor at skulle implementeres ifm. EduMedia. Til gengeæld er det vigtigt at vise, at Shibboleth passer ind i den valgte arkitektur for EduMedia, og at det er muligt at foretage et skift fra EduRoam til Shibboleth når og hvis dette bliver muligt. 2 af 15
EduRoam Bilag 2 EduRoam er udviklet til at give brugere adgang til nettet, når de bevæger sig mellem forskellige institutioner. EduRoam er baseret på et internationalt hierarki af RADIUS servere, med en top level country server i hvert land. Således har Danmark sin egen top level country server, som Forskningsnettet driver. Under denne er tilknyttet de enkelte institutioners RADIUS servere. Dette hierarki af RADIUS servere anvendes til at autentificere brugere, som ønsker at få adgang til nettet (typisk via et trådløst net). Men samme mekanisme kan anvendes til at give adgang til applikationer som fx. EduMedia. I EduRoam er der ikke nogen overførsel af attributter, der kan anvendes til at kvalificere autorisationen af brugeren. Der er to problemer med anvendelsen af EduRoam: 1. Brugeren skal afgive sit brugernavn og pasord til en EduRoam server, hvor det i princippet vil kunne læses inden det sendes gennem RADIUS hierarkiet til brugerens hjeminstitution. 2. EduRoam giver ikke mulighed for at overføre attributter mellem hjeminstitution og EduMedia. Autorisationen må derfor alene foretages på baggrund af brugerens identitet eller institutionstilhørsforhold. Beskrivelse af autentificering og autorisation baseret på EduRoam For at anvende EduRoam til at autentificere brugere til EduMedia er det nødvendigt, at sikre sig, at brugeren ikke skal afgive sit brugernavn og password til EduMedia men kun til EduRoam, som er et kendt system, som brugerne må formodes at kende og stole på. Løsningen som er skitseret her tager højde for dette, og er baseret på den løsning som UNI-C anvender, for at give tredjepart adgang til at kunne autentificere (og til dels autorisere) brugere via UNI-Login som trækker på UNI-C's brugerdatabase for grundskole- og gymnasieområdet. Metoden er baseret på, at der mellem tjenesteudbyderen (EduMedia) og autentifikationstjenesten (EduRoam) på forhånd er udvekslet en fælles hemmelig nøgle. Denne nøgle bruges til at kryptere information kodet i de URLer, der anvendes, når brugeren redirrigeres mellem tjensteudbyder og autentifikationstjeneste. Detaljerne er gengivet i figur 1og 2, og vil blive gennemgået i det følgende. Figurerne viser skematisk den kommunikation, der foregår mellem brugeren (repræsenteret ved klienten som består af browser og player), EduMedia og EduRoam. Det er værd at bemærke, at der ikke foregår nogen direkte kommunikation mellem EduMedia og EduRoam. Al kommunikation foregår gennem klienten via overførsel af information i URLen. Kommunikationen mellem klienten og EduMedia foregår dels som kommunikation mellem klientens browser og en EduMedia webserver (som afvikler søgning, fremfinding og præsentation) og dels som kommunikation mellem klientens player og en EduMedia streaming server. Kommunikationen mellem klienten og EduRoam foregår udelukkende mellem klientens web browser og EduRoam login serveren. Denne del af kommunikationen foregår naturligvis krypteret (SSL). De EduMedia- og EduRoam-servere der kommunikerer direkte med klienten har ligeledes kommunikation med andre servere for at autentificere og autorisere brugeren. Denne kommunikation er vist, men hovedvægten er lagt på den del af kommunikationen, der foregår med klienten. Derfor er den resterende del af kommunikationen ikke vist nær så detaljeret. 3 af 15
Bilag 2 Figur 1: EduRoam som autentifikationsmekanisme for EduMedia 4 af 15
Bilag 2 I det følgende vil kommunikationen i et typisk forløb blive gennemgået. Vi følger kommunikationen, fra det øjeblik hvor brugeren klikker på et link, der starter afspilningen af en video fra EduMedias arkiv, til det øjeblik hvor videoen kan ses i brugerens player. Tallene henviser til numrene i cirkler på figur 1 og pilenes numre i figur 2. 1. Som udgangspunkt er brugeren ikke logget ind (autentificeret), men udfører en request, der såfremt brugeren er berettiget til det, resulterer i afspilningen af materiale fra EduMedia. 2. Da brugeren endnu ikke er autentificeret svarer EduMedia webserveren med svarkode 302 (FOUND) som indeholder en redirect URL, der henviser til EduRoam. 3. Brugerens browser sender nu en forespørgsel til EduRoam login serveren 4. som svarer tilbage med en HTML form, som brugeren udfylder med sit brugernavn og password. 5. De udfyldte data sendes fra brugerens browser til EduRoam login serveren. Denne del af kommunikationen er krypteret med SSL (https). 6. EduRoam login serveren sender nu en autentifikationsforespørgsel til den danske top level RADIUS server i EduRoam hierarkiet 7. Ud fra brugernavnet afgøres hvilken institution brugeren kommer fra, og forespørgslen sendes videre til hjeminstitutionens RADIUS server 8. som svarer tilbage til top level RADIUS serveren 9. som igen svarer tilbage til EduRoam login serveren. 10. Denne udsteder nu en login cookie, som har en gyldighed på nogle timer eller til browseren lukkes og der svares tilbage med svarkode 302 (FOUND) og en redirect location, der peger tilbage på den oprindelige EduMedia URL (eller en fast aftalt URL). Login serveren udsteder en (krypteret) authentication ticket baseret på et tidsstempel, brugerens identitet og den fælles hemmelighed. Denne authentication ticket sættes som en query string på URLen der redirrigeres til. 11. Brugerens browser sender nu på ny en request til EduMedia webserveren med den URL, som indeholder den krypterede authentication ticket. Den krypterede authentication ticket afkodes ved hjælp af den fælles hemmelighed, og det checkes, om den stadig er gyldig (ud fra tidsstemplet). Er dette tilfældet, logges brugeren ind i EduMedia (der udstedes en login cookie). 12. Webserveren sender en forespørgsel til en EduMedia autorisationsserver indeholdende bruger ID og asset ID på den asset, der ønskes afspillet. 13. Autorisationsserveren svarer tilbage med besked om hvorvidt brugeren har ret til at se den valgte asset, hvilket vi her antager er tilfældet. Der udstedes en grant ticket, som giver ret til én afspilning af den valgte asset inden for et bestemt tidsrum. 14. Webserveren genererer en URL til den valgte præsentationsfil og påhæfter samtidig URLen den grant ticket, som blev udstedt af autorisationsserveren. 15. URLen gives videre til en player eller player plug-in 16. Playeren (fx. RealPlayer/Windows Media Player/QuickTime Player) sender en RTSP DESCRIBE request til en EduMedia streaming server. 17. En autorisationsplugin i streamingserveren parser URLen og udtrækker den medsendte grant ticket, som anvendes til en forespørgsel til autorisationsserveren. 5 af 15
Bilag 2 18. Autorisationsserveren svarer tilbage med besked om at brugeren er autoriseret til at se den valgte asset. 19. Streamingserveren svarer tilbage til playeren med en beskrivelse af den valgte præsentationsfil. 20. Playeren sender en SETUP forespørgsel til streamingserveren indeholdende protokol og klientportnummer. 21. Serveren svarer tilbage med information om serverport. 22. Playeren sender en PLAY request. 23. Serveren svarer OK. 24. Serveren starter afspilning af RTP stream på de forhandlede porte. Figur 2: Autentifikation med EduRoam Da brugeren nu er logget ind (der er udstedt en login cookie af EduMedia) er det ved næste forespørgsel kun nødvendigt at udføre punkterne 11 24. Besøger brugeren en anden tjeneste, som anvender EduRoam til autentifikation, er det heller ikke nødvendigt at logge ind her, da EduRoam login serveren ligeledes har udstedt en login cookie. Samme beskrivelse som ovenfor er gengivet i Appendix 1, hvor der også er medtaget et pseudotransskript af dele af kommunikationen mellem klient og servere. 6 af 15
Granularitet i autorisation baseret på EduRoam Bilag 2 De brugernavne der anvendes i den danske del af EduRoam RADIUS hierarkiet, er udformet som e-mail adresser på formen: bruger@institut.institution.dk Det vil derfor være muligt at understøtte en simpel form for autorisation baseret på en autentificeret brugers brugernavn. Vi kan altså autorisere brugere som individer baseret på deres fulde brugernavn eller som grupper baseret på deres tilhørsforhold. Der er i grove træk følgende muligheder for at gruppere brugerne: 1. Alle brugere 2. Alle autentificerede brugere 3. Alle autentificerede brugere fra et bestemt domæne (f.eks. alle fra au.dk) 4. Alle autentificerede brugere fra et bestemt underdomæne (f.eks. alle fra imv.au.dk) 5. Autentificerede enkeltbrugere eller grupper heraf (f.eks. Peter@imv.au.dk og Ole@imm.dtu.dk) Dette er naturligvis en meget grovkornet autorisationsmodel, idet vi ikke kender nogen af brugernes roller (er brugeren fx. studerende eller forsker)?. Men det giver dog indholdsleverandørerne et vist spillerum til at afgrænse adgangen til deres materiale til specifikke brugergrupper baseret på institutionstilhørsforhold (som fx alle de institutioner der abonnerer på en bestemt leverandørs indhold) eller i særlige tilfælde (grupper af) enkeltbrugere (som fx. materiale som kun skal tilgængeliggøres for studerende på et bestemt kursus). Shibboleth Shibboleth er udviklet af det amerikanske Internet2 projekt, og det løser netop den problemstilling som EduMedia-projektet står over for ifm. autentificering og autorisation af brugere, nemlig at en ekstern tjenesteudbyder (i dette tilfælde EduMedia) kan få verificeret hvorvidt en bruger kommer fra en given institution, og i det omfang brugeren eller dennes institution selv tillader endvidere kan få yderligere oplysninger om brugeren (attributter). Shibboleth udmærker sig ved, at brugeren ikke skal afgive sine akkreditiver til tredje part, men udelukkende til sin egen hjeminstitution. Brugeren eller institutionen definerer så selv en politik for hvilke attributter der kan frigives til hver enkelt tjenesteudbyder. Shibboleth giver altså brugeren mulighed for ét sted at administrere sin digitale identitet, som kan anvendes til mange forskellige tjenester såvel inden for hans egen institution som fra eksterne tjenesteudbydere. Udover tjenesteudbyderen og hjeminstitutionen inkluderer Shibboleths arkitektur også en såkaldt Where Are You From (WAYF) server. WAYF serveren er bindeled mellem tjenesteudbyderen og brugerens hjeminstitution, men den er ikke involveret i autentifikation eller autorisation den er hjælper udelukkende til med at identificere brugerens hjeminstitution. Dette er en af de markante forskelle fra EduRoam-modellen hvor brugerens akkrditiver afgives til Eduroam login-serveren og transporteres til hjeminstitutionen gennem RADIUS hierarkiet. Beskrivelse af autentifikation og autorisation baseret på Shibboleth I det følgende vil kommunikationen mellem klienten, EduMedia, WAYF serveren og brugerens hjeminstitution blive gennemgået. Detaljeringsgraden er ikke så høj som i gennemgangen af EduRoam, da det primære formål med nærværende gennemgang ikke er at give en præcis opskrift på hvorledes autentifikation og autorisation foregår, men blot at vise, at det kan lade sig gøre og i grove træk hvordan. Det er også nyttigt, at sammenligne de to metoder, da det kan give en idé om hvilke ligheder og forskelle der er mellem de to metoder en relevant øvelse taget i betragtning at der sandsynligvis vil ske et skifte fra EduRoam- til Shibboleth-baseret autentifikation og autorisation. 7 af 15
Bilag 2 Figur 3: Autentifikation og autorisation med Shibboleth Tallene nedenfor refererer til de nummererede pile i figur 3. 1. Som udgangspunkt er brugeren ikke logget ind (autentificeret). Brugerens browser udfører en request, der såfremt brugeren er berettiget til det, i sidste ende resulterer i afspilningen af materiale fra EduMedia. 2. Da brugeren ikke er logget ind, og da systemet ikke kender brugerens hjeminstitution redirriger webserveren til en WAYF server. 3. WAYF serveren præsenterer brugeren for en liste, hvor brugeren vælger sin hjeminstitution. WAYF serveren sætter en cookie i brugerens browser, så brugeren ikke behøver, at vælge sin hjeminstitution næste gang en tjeneste redirrigerer til WAYF serveren. 4. WAYF serveren redirrigerer brugeren til hjeminstitutionens hande server. 5. Da brugeren endnu ikke har autentificeret sig med hjeminstitutionens single-sign-on (SSO) system redirrigerer handle serveren til SSO serveren. 6. Brugeren autentificerer sig overfor SSO serveren, som trækker på data fra en authentication authority, der er den autoritative kilde til brugerens akkreditiver. 8 af 15
7. SSO serveren udsteder en login cookie, og redirrigerer brugeren tilbage til handle serveren. Bilag 2 8. Da brugeren nu er autentificeret af hjeminstitutionens SSO system udsteder handle serveren et handle og redirrigerer brugeren tilbage til EduMedia. 9. Baseret på det udstedet handle sender webserveren nu en autorisationsforespørgsel til EduMedia s autorisationsserver. 10. EduMedias autorisationsserver anvender nu det handle, som blev modtaget af brugeren, til at sende en attributforespørgsel til brugerens hjeminstitutions attribute authority. Denne forespørgsel kan relatere til brugerens tilhørsforhold til institutionen eller om brugerens rolle (fx. om der er tale om en studerende, en ph.d. studerende eller en forsker). Hjeminstitutionens attribute authority verificerer EduMedia autorisationsserverens identitet ved hjælp af dennes server certifikat. 11. Hjeminstitutionens attribute authority verificerer med handle serveren at det handle, der anvendes i attributforespørgslen er gyldigt. 12. Hjeminstitutionens attribute authority konsulterer retningslinjerne for frigivelse af attributter (attribute release policy) og sender i positivt fald de forespurgte attributter til EduMedias autorisationsserver. 13. EduMedias autorisationserver afgør på baggrund af de modtagne attributter hvorvidt brugeren kan få adgang til det forespurgte indhold. I positivt fald sendes en bekræftelse til EduMedia webserveren, og der udstedes en grant ticket, som giver ret til en afspilning af den valgte asset inden for et bestemt tidsrum. 14. Webserveren svarer tilbage til brugerens webbrowser med en URL til den forespurgte mediefil. Denne URL, som indeholder den udstedte grant ticket, videregives til brugerens media player, som sender en forespørgsel til en EduMedia streamingserver som kan levere mediefilen. Da brugeren nu er autentificeret sætter EduMedia webserveren en login cookie. 15. Et autorisationsmodul i streamingserveren sender en forespørgsel til autorisationsserveren med den grant ticket som indgår i den anvendte URL. Autorisationsserveren bekræfter at den anvendte grant ticket er gyldig. 16. Kommunikationen mellem media player og streaming server fortsætter nu på normal vis, 17. og streamingserveren påbegynder streaming af mediefilen. Ved efterfølgende forespørgsler på indhold fra EduMedia vil brugeren kun skulle kommunikere med EduMedia webserveren og streamingserveren, da webserveren har sat en session cookie. Alle efterfølgende forespørgsler på indhold vil naturligvis skulle autoriseres, så pkt 9 17 vil blive gennemført hver gang (dog sandsynligvis uden at skulle rekvirere de samme attributter mere end en gang per session). LOGNING Logning af brugernes aktiviteter er ønskelige med henblik på at kunne 1. Levere statistik om brugen af systemet Til indholdsleverandørerne Til systemejerne 9 af 15
Bilag 2 2. Forbedre brugerbetjeningen, f.eks. gennem Collaborative filtering (andre der har set denne video, har også set ) Forbedring af funktionalitet og udbygning af indhold med baggrund i faktisk observeret brug 3. Beskytte rettighedshavernes rettigheder (kunne tilbageføre ulovlige handlinger til den/de person(er), der har udført dem) 4. Overbevise indholdsleverandører og rettighedshavere om, at der er styr på hvorledes materiale distibueres via systemet Logning til disse forskellige formål bør som udgangspunkt udføres uafhængigt af hinanden, da det er forskellige krav, der styrer hvorledes data indsamles, opbevares og slettes. F.eks. er det persondatalovgivningen, der afgør hvordan og hvor længe personhenførbare oplysninger skal opbevares. Det er vigtigt, at afgøre hvorvidt de oplysninger der logges, lagres på en form der gør, at de kan henføres til en bestemt person, eller om de lagres på anonymiseret form. Brugernes krav på anonymitet og den gældende lovgivning vil her afgøre, hvorvidt det ene eller det andet er tilfældet. Dette skal forstås således, at dersom der ikke er krav om, at en oplysning skal være personhenførbar, så skal den lagres på anonymiseret form, således at vi i videst muligt omfang respekterer brugernes ret til anonymitet. Logning af aktiviteter vil foregå forskellige steder i systemet. Således vil logning af søgninger og fremvisninger finde sted i præsentationsmodulet, mens logning af hvilke filer en (ikke professionel) leverandør uploader finde sted i ingestmodulet. Datakilder til logning kan være systemprogrammel (ingestmodul, AAA-modul, præsentationsmodul) eller eksterne kilder (webserver log, streamingserver log). Logning til statistik Til brug for statistik er det ønskeligt at opsamle oplysninger på anonymiseret form til at kunne producere følgende statistikker: Overordnet for systemet: 1. Antal assets i systemet 2. Antal registrerede brugere 3. Antal besøgende (registrerede/annonyme) 4. Antal søgninger/fremfindinger 5. Antal fremvisninger 6. Samlet fremvisningstid (persontimer) 7. Antal bytes streamet (total, middel, maks) 8. Antal fremvisninger fordelt på format og klientplatform Til brug for 1 og 2 kræves blot en daglig logning af disse tal. Til brug for 3 kan man for registrerede brugere lade autentifikationsmekanismen logge hvergang en bruger autentificeres. For anonyme brugere kan man evt. lade en cookie afgøre hvor mange unikke anonyme brugere man får besøg af og logge hvert besøg af en unik anonym bruger. Alternativt kan man benytte webserverens access log til dette formål. Hvis EduMedia anvendes som en webservice fra et Learning Management System eller en ekstern web site, så vil det være vanskeligt (eller endda umuligt) at få denne information. Til brug for 4 og 5 kræves blot at præsentationsmodulet logger disse oplysninger. Oplysningerne til brug for 6, 7 og 8 skal hentes fra streamingserverens logfiler, som typisk logger information om de enkelte afspilninger. 10 af 15
Leverandørerne kan have en interesse i at få adgang til følgende oplysninger: Bilag 2 1. Antal fremfindiger (hits) per asset og totalt 2. Antal fremvisninger per asset og totalt 3. Antal fremvisninger fordelt på format, klientplatform og båndbredde per asset og totalt Informationerne til brug for 1 og 2 kan logges fra præsentationsmodulet. Informationerne til brug for 3 skal logges fra streamingserveren. Logning til brugerbetjening Der er to forskellige formål med at logge oplysninger om brug af systemet med henblik på at understøtte brugerbetjeningen: Dynamisk collaborative filtering af søgeresultater Periodisk gennemgang af brugen af systemet Det første formål spiller så kraftigt sammen med præsentationsmodulet at det nærmest må anses for at være en integreret del heraf. Det vil derfor ikke blive behandlet yderligere her. Det andet formål kan delvist tilgodeses i de statistikker, der er nævnt i forrige afsnit. Udover disse er der muligvis brug for andre data som f.eks. 1. Hyppigst forekommende søgeord 2. Hyppigst forekommende søgeord i søgninger uden resultat 3. Fordeling mellem format og båndbredde på fremviste assets 4. Hyppigst forekommende fejlmeddelelser Data til brug for 1 og 2 skal logges i præsentationsmodulet. Data til brug for 3 skal logges på streamingserveren. Data til brug for 4 skal indsamles, fra alle de steder hvor systemets komponenter logger fejlmeddelelser. Det kan overvejes om der skal logges til én central lokalitet for at gøre denne indsamling lettere og den efterfølgende behandling nemmere at automatisere. Logning til beskyttelse af rettigheder Både indholdsleverandører og rettighedshavere til det materiale, som distribueres via EduMedia, har krav på, at vi tager de nødvendige skridt til at sikre at materiale, som ikke er til fri distribution, ikke kan ses af andre end autentificerede og autoriserede brugere. For at godtgøre at dette er tilfældet, skal enhver afspilning af beskyttet indhold foregå på en sådan måde, at det kan godtgøres, at der er tale om en autentificeret og autoriseret bruger. Det er ikke nødvendigt at logge afspilningen og/eller brugerens identitet (eller handle) for at opnå dette. Det kan dog være nødvendigt at logge disse data, for at kunne afsløre misbrug som følge af stjålne akkreditiver. En sådan logning skal, hvis den finder sted, selvfølgelig foregå i overensstemmelse med gældende lovgivning på området. En anden problemstilling opstår hvis en indholdsleverandør (formodentligt uforvarende) tilgængeliggør materiale som krænker tredjeparts rettigheder, eller på anden måde overtræder gældende lovgivning ved at tilgængeliggøre materialet. Dette kan fx. skyldes at der indgår materiale hvor rettighederne ikke er clearede. For at imødegå dette, bør der logges mest mulig information ifm. upload og ingest af medier til systemet. Dette inkluderer: 1. Leverandørens bruger ID 2. IP nummer på systemet der uploades fra 3. Asset ID på mediefilen 4. Dato og klokkeslet 11 af 15
REFERENCER EduRoam: http://www.eduroam.org, http://www.eduroam.dk Bilag 2 TERENA: http://www.terena.nl GÉANT2: http://www.geant2.net, http://www.geant2.net/server/show/nav.758 Internet2: http://www.internet2.edu/ Shibboleth: http://shibboleth.internet2.edu/ SWITCHaai: http://www.switch.ch/aai/ UNI-Login: http://www.uni-c.dk/produkter/undervisning/unilogin/ APPENDIX 1. PSEUDOTRANSSKRIPT AF KLIENT-SERVER KOMMUNIKATION IFM. AUTENTIFIKATION MED EDUROAM I dette appendix gengivess et pseudotransskript af kommunikationen mellem klientens webbrowser og media player og hhv. EduMedias webserver og streamingserver. Tallene refererer til pilene i figur 1 og 2. Kun de relevante dele af kommunikationen er medtaget. 1. Som udgangspunkt er brugeren ikke logget ind (autentificeret), men udfører en request, der såfremt brugeren er berettiget til det, i sidste ende resulterer i afspilningen af materiale fra EduMedia. GET /asset?presentationid=ahr0cdovl2fnzw50lmryawwuzgsvywdlbnqvc3r5bguvc2tvbguvrgv myxvsdc5hc3b4 HTTP/1.0 2. Da brugeren endnu ikke er autentificeret svarer EduMedia webserveren med svarkode 302 (FOUND) som indeholder en redirect URL, der henviser til EduRoam. HTTP/1.1 302 Found Location: https://login.eduroam.dk/edumedia/edumedia.cgi?presentationid=ahr0cdovl2fnzw5 0LmRyaWwuZGsvYWdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4 3. Brugerens browser sender nu en forespørgsel til EduRoam login serveren 4. som svarer tilbage med en HTML form, som brugeren udfylder med sit brugernavn og password. <form name="query" method="post" action="https://login.eduroam.dk/edumedia/edumedia.cgi" enctype="application/x-www-form-urlencoded"> <p> <label for="brugernavn"> Brugernavn: </label> <input id="brugernavn" type="text" name="user" maxlength="14" value="" > <label for="kode"> Adgangskode: </label> <input id="kode" type="password" name="pass"> <p> 12 af 15
</p> </form> <input class="knap" type="submit" name="submit" value="log in" > Bilag 2 5. De udfyldte data sendes fra brugerens browser til EduRoam login serveren. Denne del af kommunikationen er krypteret med SSL (https). 6. EduRoam login serveren sender nu en autentifikationsforespørgsel til den danske top level RADIUS server i EduRoam hierarkiet 7. Ud fra brugernavnet afgøres hvilken institution brugeren kommer fra, og forespørgslen sendes videre til hjeminstitutionens RADIUS server 8. som svarer tilbage til top level RADIUS serveren 9. som igen svarer tilbage til EduRoam login serveren. 10. Denne udsteder nu en login cookie, som har en gyldighed på nogle timer eller til browseren lukkes og der svares tilbage med svarkode 302 (FOUND) og en redirect location, der peger tilbage på den oprindelige EduMedia URL (eller en fast aftalt URL). Login serveren udsteder en (krypteret) authentication ticket baseret på et tidsstempel, brugerens identitet og den fælles hemmelighed. Denne authentication ticket sættes som en query string på URLen der redirrigeres til. HTTP/1.1 302 Found Location: http://www.edumedia.dk/asset?presentationid=ahr0cdovl2fnzw50lmryawwuzgsvywdlb nqvc3r5bguvc2tvbguvrgvmyxvsdc5hc3b4×tamp=20050908163325&user=testuser&au th=ab7aee3a65a9fb3365da72d7c906a962 11. Brugerens browser sender nu på ny en request til EduMedia webserveren med den URL, som indeholder den krypterede authentication ticket. Den krypterede authentication ticket afkodes ved hjælp af den fælles hemmelighed, og det checkes, om den stadig er gyldig (ud fra tidsstemplet). Er dette tilfældet, logges brugeren ind i EduMedia (der udstedes en login cookie). 12. Webserveren sender en forespørgsel til en EduMedia autorisationsserver indeholdende bruger ID og asset ID på den asset, der ønskes afspillet. 13. Autorisationsserveren svarer tilbage med besked om hvorvidt brugeren har ret til at se den valgte asset, hvilket vi her antager er tilfældet. Der udstedes en grant ticket, som giver ret til én afspilning af den valgte asset inden for et bestemt tidsrum. 14. Webserveren genererer en URL til den valgte præsentationsfil og påhæfter samtidig URLen den grant ticket, som blev udstedt af autorisationsserveren. 15. URLen gives videre til en player eller player plug-in 16. Playeren (RealPlayer/Windows Media Player/QuickTime Player) sender en RTSP DESCRIBE request til en EduMedia streaming server. DESCRIBE rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198 RTSP/1.0 CSeq: 2 Accept: application/sdp User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (linux-2.2-libc6- gcc32-i586) 13 af 15
Bilag 2 Session: 1251543571-1 Require: com.real.retain-entity-for-setup Bandwidth: 10485800 Language: en-us RegionData: 0 ClientID: Linux_2.6_10.0.0.0_play32_RN01_EN_586 GUID: 00000000-0000-0000-0000-000000000000 SupportsMaximumASMBandwidth: 1 Cookie: cbid=gffjhhiljgekhidmeoooppgqlrjrktlufkjjkidljgmkklplnnloopkqrofsptnudkfgjmjl PlayerCookie: cbid 17. En autorisationsplugin i streamingserveren parser URLen og udtrækker den medsendte grant ticket, som anvendes til en forespørgsel til autorisationsserveren. 18. Autorisationsserveren svarer tilbage med besked om at brugeren er autoriseret til at se den valgte asset. 19. Streamingserveren svarer tilbage til playeren med en beskrivelse af den valgte præsentationsfil. RTSP/1.0 200 OK CSeq: 2 Date: Thu, 08 Sep 2005 17:04:59 GMT Last-Modified: Tue, 05 Jul 2005 13:56:30 GMT Content-base: rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198 ETag: 1251543571-1 Session: 1251543571-1 Content-type: application/sdp Content-length: 4958 <SDP file content> 20. Playeren sender en SETUP forespørgsel til streamingserveren indeholdende protokol og klientportnummer. SETUP rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198/streamid=0 RTSP/1.0 CSeq: 3 RealChallenge2: f0eb0979ce393e4a285467bcfcfa90de01d0a8e3, sd=f0c326f9 RDTFeatureLevel: 2 Transport: x-real-rdt/mcast;client_port=6970;mode=play,x-realrdt/udp;client_port=6970;mode=play,x-pntng/udp;client_port=6970;mode=play,rtp/avp;unicast;client_port=6970-6971;mode=play,x-pn-tng/tcp;mode=play,x-realrdt/tcp;mode=play,rtp/avp/tcp;unicast;mode=play User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (linux-2.2-libc6- gcc32-i586) If-Match: 1251543571-1 Cookie: cbid=gffjhhiljgekhidmeoooppgqlrjrktlufkjjkidljgmkklplnnloopkqrofsptnudkfgjmjl 14 af 15
21. Serveren svarer tilbage med information om serverport. Bilag 2 RTSP/1.0 200 OK CSeq: 4 Date: Thu, 08 Sep 2005 17:05:00 GMT Session: 1251543571-1 RDTFeatureLevel: 2 Transport: x-real-rdt/udp;client_port=6970;server_port=22312 SET_PARAMETER rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198 RTSP/1.0 CSeq: 5 Subscribe: stream=0;rule=8,stream=0;rule=9,stream=1;rule=9,stream=1;rule=10 Session: 1251543571-1 RTSP/1.0 200 OK CSeq: 5 Date: Thu, 08 Sep 2005 17:05:00 GMT Session: 1251543571-1 SET_PARAMETER rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198 RTSP/1.0 CSeq: 6 SetDeliveryBandwidth: Bandwidth=2800000;BackOff=0 Session: 1251543571-1 22. Playeren sender en PLAY request. PLAY rtsp://stream1.edumedia.dk:554/assets/protected/ahr0cdovl2fnzw50lmryawwuzgsvy WdlbnQvc3R5bGUvc2tvbGUvRGVmYXVsdC5hc3B4.rm?identity=d2711c36375bfa9860339f4ee b0ce198 RTSP/1.0 CSeq: 7 User-Agent: RealMedia Player (HelixDNAClient)/10.0.0.0 (linux-2.2-libc6- gcc32-i586) Session: 1251543571-1 Range: npt=0-510.920000 23. Serveren svarer OK. RTSP/1.0 200 OK CSeq: 6 Date: Thu, 08 Sep 2005 17:05:00 GMT Session: 1251543571-1 24. Serveren starter afspilning af RTP stream på de forhandlede porte. 15 af 15
Bilag 3 EduMedia arkitektur og formater Oktober 2005 Dan Mønster, UNI-C MÅL Arbejdsgruppen havde to hovedopgaver: 1. Fastlægge den overordnede systemarkitektur for EduMedia 2. Se på hvilke formater, der kan anvendes til ingest, arkivering og streaming. BESKRIVELSE AF SYSTEMARKITEKTUR Systemarkitekturen er blevet beskrevet hovedsageligt gennem diagrammer, og den er relateret både til DEFF 3-lagsmodellen og til Open Archival Information System refrencemodellen (OAIS modellen). Der er identificeret en læng række delfunktionaliteter/moduler i projektet samt deres indbyrdes afhængigheder. Figur 1 viser et meget overordnet syn på nogle af de forskellige moduler, men for overskuelighedens skyld er der ikke medtaget nogen afhængigheder. Denne fremstilling er løst modelleret efter OAIS modellen. Figur 1: Overordnet arkitektur for EduMedia 1 af 3
Bilag 3 Arkitekturen understøtter en lang række forskellige brugsscenarier, afhængig af om leverandøren er en professionel leverandør, en enkelt forsker eller et institutional repository og tilsvarende af om brugeren er en registreret bruger eller ej og hvorvidt brugeren tilgår materialet direkte eller gennem etnwebservice requestor som fx en institutions egen hjemmeside eller LMS. Et eksempel på et brugsscenarie er vist i figur 2. Figur 2: En bruger med abonnement får adgang til DRs materiale gennem EduMedia FORMATER I diskussionen af formater skelnes der mellem formater til input (upload/ingenst/submission), arkivering og præsentation (streaming). Kriterierne for udvælgelsen af hvilke formater, der skal anvendes til de tre formål er helt forskellige: Inputformater Arkivformatet Præsentationsformater vælges ud fra dels hvad vi teknisk set kan håndtere at ingeste, dels hvad der er bekvemt for leverandørerne at levere i, og dels hvad der giver en acceptabel kvalitet. Iputformater kan fx være DV og MPEG-2, men afhængig af den valgte komprimering også AVI, WMV, QuickTime, eller MPEG-4. vil sandsynligvis blive en eller flere bestemte MPEG-2 profiler, som endnu ikke er fastlagt (fx én profil til SD materiale og én profil til HD materiale). kan være RealMedia, WindowsMedia, QuickTime, ISMA MPEG-4, 3GPP MPEG-4, Flash Video, MPEG-1 mv. Et af principperne bag EduMedias arkitektur er, at systemet så vidt muligt skal være uafhængigt af præsentationsformatet. Sammenhængen mellem input-, arkiv- og præsentationsfiler er vist i figur 3. 2 af 3