Uni-C NÃ¸glerapport 1999 - DEFF

More documents

Recommendations

Info

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.¡ ¢ £ ¤ ¥ ¦ § ¨ § ©
Page 1 and 2: DEF-nøglenForslag til realisering
Page 3 and 4: 1 Introduktion 1Indhold1 Introdukti
Page 5 and 6: 1 Introduktion 31 IntroduktionI den
Page 7 and 8: 1 Introduktion 57. Adgangsrettighed
Page 9 and 10: 2 Anvendelse af on-line ressourcer
Page 11 and 12: 2 Anvendelse af on-line ressourcer
Page 13 and 14: 3 Begreber og protokoller 113.1.1 A
Page 15 and 16: 3 Begreber og protokoller 13Ofte be
Page 17 and 18: 3 Begreber og protokoller 15Et ekse
Page 19 and 20: 3 Begreber og protokoller 171. Aute
Page 21 and 22: 4 Mulige løsningskomponenter 194 M
Page 23 and 24: 4 Mulige løsningskomponenter 21•
Page 25: 4 Mulige løsningskomponenter 234.6
Page 29 and 30: 5 Systemmodel 275 SystemmodelI dett
Page 31 and 32: 5 Systemmodel 29gang til DEF, og hv
Page 33 and 34: 5 Systemmodel 31• Den skal læse
Page 35 and 36: 5 Systemmodel 33tilpasninger og int
Page 37 and 38: 6 Opsamling 35realiseres i meget h
Page 39 and 40: 6 Opsamling 37xy'en - hvorfor denne
Page 41 and 42: PIRAEUSISOS - product overviewISOST
Page 43 and 44: 2. Business Issues and SolutionsA n
Page 45 and 46: identifier; ~ E-mail address; ~ Con
Page 47 and 48: many layers as there are in the hie
Page 49 and 50: Centralized security framework for
Page 51 and 52: AuthAPIAuthAPI allows you to build
Page 53: DEF Nøglen. Implementation med dis

Uni-C NÃ¸glerapport 1999 - DEFF

Create successful ePaper yourself

Delete template?

Save as template?